HELP: Need to persuade regarding II->IV conversion

[R.Daugherty]

Beats the terse approach, such as "Tell me how convert RPGII to RPGIV." One caveat. The standard "conversion" to RPG IV will retain your RPG II code pretty much as is. I was on a job interview a couple of years ago with a Fortune 500, and the gist of the interview was the manager gave me a program compile listing and asked if I understood it. It was RPG IV, I could see various system headings that indicated that. But it was completely RPG II, level break logic, left hand indicators, I file specs, and so on. I told him I had written one small level break report program one day long ago, and that was 18 years ago. And I laughed because I thought he was joking. But he wasn't. So this Fortune 500 has critical RPG II programs "converted" to RPG IV that they don't want to rewrite because it works. I would say write new programs in RPG IV but I wouldn't rewrite your existing programs for an equivalent replacement. Not unless you have some time on your hands... rd

[Guest.Visitor]

I TOTALLY agree with Ralph. Further more: Questions (First): Does "he" continue to code in RPGII OR are you two just maintaining the code? Has this guy been under a rock for the last 10 years? What evidence have you been able to provide to management that change is necessary? (or does management already realize the mistake in allowing one person to control the IS development)Are you planning on analyzing the "whole" application structure and remove duplicated code along the way (can you procedures and service programs)? What about the database? Is it a "flat file" system? Just the leap in technology alone is enough reason to make the migration, so to speak. Actually, you are facing a complete rebuild if you do it the most correct way. RPGII code written using RPG II methods are ancient. (A new coat of paint on a 1962 Ford does not make it any more that it is...WORN OUT) No "conversion" will do you any good. A complete rebuild is really the best (and only) option. Hummm, I would push for web enabling everything I could as part of the justification. Frankly, I am jealous of you. It has been years since I have been involved in a complete re-engineering project. Good Luck.

[Guest.Visitor]

I totally agree with Ralph and Bentley. There is way more involved in just converting from using the RPGII compiler to the RPG IV compiler. That can be done with conversion tools. The real benefit is using the DB2 native database, and modular code that service programs, BIFs, and subprocedures allow you to do. Doing the analysis for that part would take awhile, but would be worth it. You will also most likely save by implementing LFs or SQL in place of work file creation and using #GSORT. I do, however, agree with part of your co-worker's situation regarding the cycle (I learned the iSeries from a S/36 RPG II background, and did not learn the S/38). I would use the cycle for batch work involving number crunching to summarize data at specific levels. There is nothing better that the cycle to do that. I still do not see the point of manually coding level breaks in RPG code just to bypass the cycle. I agree that the cycle does reduce the amount of code, and do still use it. There have been times quite recently, where I have converted RPGIII code with manually coded level breaks back to using the cycle with level breaks. The program performs flawlessly. I agree that less code is (in this case) better, as it is less for me to debug when something goes awry. I would not use the cycle for screen / interactive programs (it can be done, but it is not intuitive). I have even used the cycle with free formatted code. The cycle is not that hard to understand. All the cycle is is having the RPG program control the file I/O instead of you having to control it using READs. The main file that drives the program is the Primary file. You tell the system in the "I" specs what fields you want it to 'watch' for changes. When those fields change those "L" indicators get turned on for one pass of the cycle. In the "C" specs, starting at column #9 you code those "L" indicators to condition what you want the system to as a beginning process when the values change. Two examples are: resetting counters / accumulators and getting information for the new group (i.e. group decription fields). In the "C" specs in columns 7 and 8 is where you code the logic to happen when the last record in the group is read. Normally you put EXSRs here to have the system do control processing, such as adding the totals for the batch into an accumulator or counter variable for summary processing. You can use "LR" to have the system do things when the last record is read (maybe close files, or start another job). In the "O" specs, the "T" lines correspond to what the system would do in terms of output when the group changes when the last record in the group is read (maybe print out group totals). If you define a "D" line conditioned by the "L" indicator, it tells the system what to do at the beginning of when a new group is encountered (maybe print a group description). I know this is somewhat simplistic, but I hope it helps. Doug

[Jeff Crosby]

ebbhitch wrote: > Hello everyone, > Here is my situation [forgive the length] I too agree with what's been written. There are a couple of 3rd party converters. I used this one: http://www.prodatacomputer.com/cvt.htm and it was _definitely_ worth the money. There is nothing like taking a program you're intimately familiar with and converting it to RPGIV. I was all RPGIII at that point, so I don't know if it works with RPGII though. And this was prior to freeform, which I now use exclusively. There is another converter on the market, I believe, but I can't remember who has it. Ah! here's the other one: http://www.linomasoftware.com/products/rpgtoolbox I have no experience with it, however. -Jeff

[ebbhitch]

Hello, He is still actively coding in RPG II. There is and always will be a list of projects for the system. There is also a list of ideas that I have for things that would be nice to develop for the system, but just aren't possible at this point, due to my own lack of experience/knowledge at the moment in combination with the S/36 environment. Management is aware that we need to plan ahead and not have the entire business on one person and that is a large reason why I came to the company.

I would love to be able to rework the code as a whole to streamline it into RPG IV, but I don't know how willing our programmer would be to take that on all at once at this stage. Is it possible to "convert" to RPGIV and get us into the native environment and then a little later streamline the code? All files are internally defined flat files, yes. I may be new to this language, but that already frustrates me to no end.

Basically I understand that the technology advancement is a great reason to upgrade, but I'm dealing with someone who's mindset is "It's not broken, don't fix it. I don't see the technology as being enough of a reason right now. I can do what I need to do." So I'm trying to find another way to present the idea to him in a way that might be persuasive. Ultimately, no, it's not his call. Management can say 'well this is how it has to be. Do it.' and it could just come to that. But politically it's much easier on the entire process if he is on board and at least can agree on some level, even if it isn't his preference. As the newbie to the language, I don't feel I have much to stand on (even though I really positive I'm right on this) as I understand I'll come across as the outsider.

Just continuing to research and gather information in the meantime. Thanks! Liz

[David Abramowitz]

A couple of notes (opinions) about RPG II conversions:

[*]To make it easier, programs should be first converted to RPG III.[*]Batch programs convert without too many problems.[*]It is not necessary to rewrite batch programs in order to convert them. RPG III and RPG IV will still accept internalized files. You can take care of that later.[*]Interactive programs are a pain. Most will have to be redesigned. It is often better to redesign, and rewrite the program from scratch rather than convert in place.[*]Watch out for invalid data. Spaces in zoned decimal fields have no effect on an RPG II program execution, but will make a native program blow sky high.[/list]There are other gotchas, but you will find them out as you go along. Dave

[R.Khoury]

Here's my two cents. I have a few clients that run in the 36EE and things do work. I converted the files to external DDS (new files, indices are created via SQL), so I could use SQL, QMQRYs, and Query. New pgms and major mods I do in RPGIV, CLLE, using service pgms, subprocedures, etc. The previous responses regarding conversions make sense; they're not going to re-write the logic, they'll just convert the syntax so you're only slightly better off. I didn't go that route. My opinion on most old code is not that it doesn't work, it's that there's little or no documentation to explain why it does what it does. I still struggle with this on an almost daily basis (if I ever track down those programmers...). So converting code you don't understand just makes for modern code that's also not understandable. Like someone said, a new paint job won't make it better - or as we use to say, "if it don't go, chrome it". A pretty, shiny program isn't what you want, you want maintainable, understandable code that functions well. Enough from me.

[bharder@nlrha.ab.ca]

Although normally I would be all for a conversion to RPG IV, in this case I'm not sure that's the best approach. The problem here, as I see it, is that the existing system is ancient and could well be extensive too. There's so much that needs addressing, where do you start? How do you keep momentum on a conversion going? Is there any reasonable prospect of ever finishing? Honestly, the original progammer's reluctance to change is just the tip of the iceberg. Even that should be a warning signal though. My gut feeling is, put the entire system into maintenance mode. Start building a proposal to purchase a commercially available package. You'll get farther and much faster too. It's a better use of your company's time and money. Well, even if nothing comes of it, here's just a few benefits to RPG IV (in principal only--others have noted the shortcomings of simple syntactical conversions). 1). Externally described files. What we now call a true database, so data is accessed via field names, not positional values defined by the accessing program; 2). Vastly more self-descriptive code. Verbs (operators), nouns (field names), everything is generally longer and has better names. Support for mixed case coding too, which is far easier to read; 3). Multi-language linking capabilities, via ILE; 4). Greatly reduced dependance upon indicators. In fact, you can get indicator use down to zero if you wish. Indicators are lousy because their names do not "indicate" their function. Also, the classic RPG II logic trap is, "what does it mean when indicators 16, 25, 43, 71 and 92 are all On?" 5). Opportunites for modular code are much greater. True subprocedures with variable scoping, service programs, the list goes on and on; 6). Far better fundamental data type support. Support for nulls, for date fields, for many standardized ANSI fields like various binary fields and the like. The bottom line is that you can call many standardized C functions that are widely available; 7). Direct support for SQL. Nuff said there; 8). Support for either fixed format or free format code, at your option; 9). The RPG IV language is modern and fully supported. That means you can get courses, bug fixes, knowledgebases, web assistance, talent, the list is huge. RPG II is terribly limited on all those fronts. There's more, I just can't think of it all right now. The list of advantages is amazingly long.

[R.Daugherty]

Some things to realize, Liz. - It is not the code that he thinks isn't broken, it's the RPGII programming process. But in contending that, he is putting too much emphasis on the cycle and not enough on the infrastructure that plugs and plays with everything outside of the cycle. - An equivalent in RPG III/400/IV is not more understandable at face value. It would just be lots and lots of IF statements duplicating the cycle logic. if L1 = *on is not fundamentally more understandable than an L1 conditioning indicator on the left side. It is the comments that explain why something is being done that makes code understandable, and they are there or not there in RPGII or RPGIV. Given the above and his health condition, I would recommend that he continue enhancing RPGII programs, but to schedule time for him to add extensive commenting explaining what various sections of the program are doing and how they interact with other logic. What are assumptions, what are prereqs, what are post-reqs, what is assumed to be set, and what is being set. I would also have him use the automatic converter and get it to RPGIV as is, then gradually externally define all the database files and replace the I specs. Then I would rewrite logic in interactive programs as logic in service program subprocedures that can be called by interactive or CGI web programs to process displays. That should keep both of you busy for awhile doing your own things. rd

[nandelin]

What about Brian's suggestion that the company begin looking for a commercially available package to replace the home grown package? It's often more economical, and may be better for the company, but in-house developers normally cringe at the thought. It's not just replacing software. It often means replacing in-house developers, or at least scaling back their responsibilities. In 1989 I began working for a company that relied entirely on RPGII and the S/36 environment. However just before I arrived, one of the other developers who was leaving, had already created DDS specs and externally described files, which didn't have much adverse effect on existing programs, which used internally described files. I just began incrementally replacing existing applications, using RPGIII and a more modular architecture, which was easier to maintain. You might consider doing the same, except going strait to RPGIV and free form, for new applications, as well as incrementally replacing existing applications. Nathan M. Andelin