• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Help with RPG II Programs

    November 1, 2002 Timothy Prickett Morgan

    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

    Sponsored By
    inFORM DECISIONS

    ELIMINATE THE COSTS OF PRE-PRINTED FORMS, LABOR AND POSTAGE WITH
    inFORM Decisions iDocs™ ‘Suite’

    iSeries based e-Forms, e-Checks, e-Mail, e-FAX, and Document Retrieval from the Web are available as individual modules or as a complete e-Document processing ‘Suite’.

    Click to Download the Complete Suite or Individual Modules today
    www.inFORMDecisions.com

    or call (800) 858-5544

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: mgo_rc, Volume 2, Number 84 -- November 1, 2002

    Sponsored by
    Midrange Dynamics North America

    Accelerate Change & Integration on IBM i

    Good change management unites IBM i and open systems development for productive collaboration. Developers work with their preferred tools and IDEs. Ultimate version control and traceability mean fast bug fixes and less stress. Rollback to a stable version in seconds.

    Change management gives managers, operations teams, and auditors the visibility they need, and developers can focus on what they like best: building great applications.

    Learn More

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    SQL’s One-Row, One-Column Table Reader Feedback and Insights: We Want More RPG

    Leave a Reply Cancel reply

MGO Volume: 2 Issue: 84

This Issue Sponsored By

    Table of Contents

    • Reader Feedback and Insights: Not All Hex Dumps Are Created Equal
    • Help with RPG II Programs
    • You Can’t Get There from Here

    Content archive

    • The Four Hundred
    • Four Hundred Stuff
    • Four Hundred Guru

    Recent Posts

    • To Comfort The Afflicted And Afflict The Comfortable
    • How FalconStor Is Reinventing Itself, And Why IBM Noticed
    • Guru: When Procedure Driven RPG Really Works
    • Vendors Fill In The Gaps With IBM’s New MFA Solution
    • IBM i PTF Guide, Volume 27, Number 27
    • With Power11, Power Systems “Go To Eleven”
    • With Subscription Price, IBM i P20 And P30 Tiers Get Bigger Bundles
    • Izzi Buys CNX, Eyes Valence Port To System Z
    • IBM i Shops “Attacking” Security Concerns, Study Shows
    • IBM i PTF Guide, Volume 27, Number 26

    Subscribe

    To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

    Pages

    • About Us
    • Contact
    • Contributors
    • Four Hundred Monitor
    • IBM i PTF Guide
    • Media Kit
    • Subscribe

    Search

    Copyright © 2025 IT Jungle