|
|
|
|
|
       |
 |
|
|
 |
||
|
Help with RPG II Programs Hey, Ted: I know you and the other Guild Companies editors cover a lot of the new stuff in Midrange Guru, so you may not want to address my problem. I have never even seen a System/36, yet I have to maintain some old S/36 code. I am getting the hang of OCL, but trying to work with RPG II after years of RPG III and RPG IV is driving me nuts. The worst part of it is trying to keep up with so many indicators. Do you have any sage advice for me?
-- Brad My earliest production code was RPG II, and going back to work on that stuff is challenging, to say the least. I often rewrite parts of a program just to be able to understand it. Here are some ways I get rid of indicators. My favorite technique is to replace indicators with fields. In RPG III and IV, you can test an indicator using the *IN syntax. I do something similar in RPG II. I create one-byte fields of the form #INxx and load them with a 0 or 1, depending on the setting of an indicator: *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 * Original code C N25 MOVE *BLANK LOC C N25 Z-ADD0 P7 C N25 MOVE *BLANK BPART 4 C N25 EXCPTADDIT * Modified code C MOVE '0' #IN25 1 C 25 MOVE '1' #IN25 C #IN25 IFEQ '0' C MOVE *BLANK LOC C Z-ADD0 P7 C MOVE *BLANK BPART 4 C EXCPTADDIT C END Be careful when using this technique. Be sure that nothing in the conditioned calculations changes the conditioning indicator. The modified code in the following example is not equivalent to the original code, because the ADJUST subroutine modifies indicator 25: *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 * Original code C N25 MOVE *BLANK LOC C N25 EXSR ADJUST C N25 MOVE *BLANK BPART 4 C N25 EXCPTADDIT C** C ADJUST BEGSR C* C LOC COMP 'X' 25 * Modified code C MOVE '0' #IN25 1 C 25 MOVE '1' #IN25 C #IN25 IFEQ '0' C MOVE *BLANK LOC C EXSR ADJUST C MOVE *BLANK BPART 4 C EXCPTADDIT C END C** C ADJUST BEGSR C* C LOC COMP 'X' 25 C* A second technique that I have found helpful is to get rid of field indicators in input specs. It is usually not hard to replace these indicators with equivalent calculation specs: * Original code *. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 IVENMST NS 45 1 CA I 1 1 STATUS I 2 30CONUI I P 4 60VENDIN I 7 31 NAMEI I 32 56 ADD1I I 57 81 ADD2I 10 I 82 93 CITYI I 94 95 STATI I P 96 1000ZIPCI C 45 10 MOVE 2 CLASS * Modified code IVENMST NS 45 1 CA I 1 1 STATUS I 2 30CONUI I P 4 60VENDIN I 7 31 NAMEI I 32 56 ADD1I I 57 81 ADD2I I 82 93 CITYI I 94 95 STATI I P 96 1000ZIPCI C STATUS IFEQ 'A' C ADD2I IFEQ *BLANKS C MOVE 2 CLASS Here's a third technique that I have used a lot: Eliminate indicators from output specs. A left-handed output spec can often be changed to exception output. A right-handed output spec can often be changed to an unconditioned field that can be loaded in calculations: * Original code OOUT D 1 01 O BPART 24 O 25 27 '**' * Modified code C EDI IFEQ 'Y' C MOVE '**' STAT2 2 C ELSE C MOVE *BLANKS STAT2 C END OOUT D 1 01 O BPART 24 O STAT2 27 As you work on the program, review the cross-reference list on the compiler listings. It will show you where an indicator is used and whether the indicator is modified or just referenced. Don't be surprised to find indicators that are modified but never referenced. These can usually be removed. (However, don't remove indicators U1 through U8 because they can be set and tested outside the program.) Look for indicators that are used on one line and referenced only on the following line. These can be replaced with IFs. I don't need to tell you to be sure not to change the logic of the program. If you are careful, you should be able clean up the program while preserving the business logic. I have done a lot of this type of work, and in many cases, have been able to convert an old program to a native RPG III program after a good cleaning. I am amazed that there is still so much S/36 code running rock-solid, day-in and day-out (unlike a lot of modern software, including PC operating systems). Reliable and effective software is hard to come by. Keep improving that old code. -- Ted
|
Editors
Contact the Editors |
|
Last Updated: 11/01/02 Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |
inFORM DECISIONS