Using 2E we are looking to switch from DDS/COBOL to SQL/RPGILE. Is there a reason for the max 4 (6 incl, prefix) field name length?

[SEAN BILLSON]

We have undertaken a mammoth project to switch and convince management that we are moving to a language/tool that is still being developed by IBM, that we can utilise via user source. 

I expected a lot of work but why is there still a RPG field name length restriction when RPGILE can handle up to 4096 length?
If we move to RPGILE we will need to rename over 4000 fields to fit the **** restrictions. However editing the source (after generation) I can expand the name length and the function compiles correctly. But this is a terrible workaround when we have over 3000 functions to convert.

Has anyone undertaken this task before and are there any suggestions to reducing this overhead of renaming all the fields longer than 4 characters?

Sean.

[Eamonn Foley]

So as luck would have it, I'm going through the same scenario as you.  The bad news is that there is no easy way to rename the fields nor does the 2e generator support natively using RPGLE long field names.  The RP4 generator is more of an bolt on than a true generator.  It really doesn't really do anything (I discovered this when I built support for variable length fields).

So one of the reasons we moved from Cobol to RPGLE was similar to yours, switching to a language/tool that is still supported and enhanced on a regular basis.  Now we got lucky as were also going refactor the model anyway (for so many reasons).  This allowed us to rebuild the model from scratch solving the renaming issue.  It did mean we would be rebuilding all the functions but given the age of the model (went live in 2008) it was better then trying to correct everything in-place.  You may want to investigate an option like this.  

I have a couple of questions:

1. Are you doing a straight convert from DDS/Cobol to SQL/RPGLE?
2. Are you only dealing with changing DB fields or do you have all the fields to rename?
3. A big reason fields were renamed for us was because almost all the reporting was done in native code (shudder), is this a similar issue?
4. I will assume you have already done due diligence on user source, if not I suggest getting on top of that as well, don't forget DDS source and CL programs that may have RCVF.

I'm going to be covering our experience on this process at the plex2e conference.  

[SEAN BILLSON]

Eamonn.

The 2E dev team did confirm that the RP4 **** is actually a RPG to RP4 converter, which is why the naming restrictions are still in place.

The 2E to RP4 **** is now in their backlog and being worked on, along with 27X132 device design editing.

We have committed (to our management) a 16 month turnaround to get the system up and running with our, unchanged, core functionality but updating 25+ year old database (went live in 1995) field length restrictions that are soon going to cause issues.

Because of this, we have scrapped our RPGLE goals and as we have too many fields that need impl. names to be reduced. Once the new RP4 **** is in a future release we may look to go this way given that it is easier for CBLILE to call RPGLE, meaning we could switch over a batch of functionality at a time. 

The SQL update for our database allows us to extend field lengths and for new interface systems to view meaningful names when fetching/updating data from our tables while older queries (etc...) can still use the Impl. names.

To answer your questions:

1. Given the number of fields we would need to change we have now gone from DDS/Cobol to SQL/CBL ILE.
2. We would have renamed all fields, not just DB. 
3. Ours is all 2E generated.
4. Yes, we were willing to recode all our COBOL USRSRC/PGM to RPGLE.

Sean.