Tweet
Does anyone have any facts and/or opinions on the best tool for converting from very old S/36 rpgII code to native? I would appreciate any suggestions.
-
-
Converting from S/36 to native
The fact is, you can convert RPG II code to RPG/400 code very easily. If you do not include native nicities, and do not plan on using externalized file definitions, batch programs may be converted simply by eliminating data in the header specs, and changing Chained and Demand files to Full Procedural files. Some gotchas:- }[*]Watch out for ADDROUT files, they can be difficult to work with.[*]Files defined as output must be created in advance. Change the "F" spec to output ADD, and include the ADD keyword for every "O" spec header record.[*]Blocking within "F" specs must be removed.[*]Specifying Random, or Limits must be removed when using Full Procedural files.[*]"L" printer specs are questionable.[*]On-line programs should be rethought.[/list]This is the quick and dirty approach. A better methodology would be to rethink the design of such programs, but time and budget limitations often do not permit this to occur. Dave
-
Converting from S/36 to native
Hi Lisa, Here's a link to MC's yellow pages: http://www.midrangecomputing.com/yel...link=Conversio n/Translation%20Tools I can't say good or bad things about any of them, but they are places to check. I would assume NEWS400 and/or searching http://www.as400.ibm.com would yield some others. I don't usually have much use for narrow experts, but in this case one would expect a lower cost, better result. If it doesn't work out that way for any reason, get back to me, I've done this sort of thing before. Best, Joe Sam Joe Sam Shirah Autumn Software Consulting/Development/Outsourcing Please Note New Email: jshirah@attglobal.net Visit our User Group at: http://www.jax400.comComment
-
Converting from S/36 to native
I have investigated several conversion tools as part of a migration from S/36 to AS/400 native. The RPG doesn't seem to be a problem and is fairly straight forward. None seem to do everything, but a few things to watch for are tools that don't rename the OCL as part of the OCL - CL conversion. Many times programmers named the OCL the same as the RPG program it called. It can cause problems and major manual work if the CL objects are not renemed. Some tools I looked at start with a dictionary or the creation of a dictionary to standardize field names and lead to the creation of physical files as the first step to externally described files. Other tools use that as an extra feature that is not required to convert the programs. The extra time to create external files is worth the effort, but it depends on the situation and the future direction of the IT. A idea of the commands used in the OCL is a good first step. Check for obscure or rarely used commands. Most tools only convert the commonly used. For example,WSU related commands or the use of ?CD?(return value) or ?CLIB(current library) were not converted. In addition, DFU and QRY were not converted by any of the tools I looked at. Some did give a list of the unconverted references or marked the resulting CL. Because of the time involved in a conversion, I recommend checking into the use of the SSP guest or the 36 environment on the AS/400. That will get you to a newer platform and provide a test environment along side of the production environment. We are currently looking for a tool to convert WSU programs to RPG II, III or native 400. If you come across anything in your search I would appreciate an email. lstevens@sigmadatainc.comComment
-
Converting from S/36 to native
TTBOMK conversion from WSU knows no automated path. Sorry for the bad news, DaveComment
Comment