When working with test programs in the Ideal environment, there are times when it is necessary to call a subprogram for different functions. It is important to ensure that the correct version of these programs is used, and there are differences between how PROD version programs call subprograms and how test version programs call them.
When the PROD version program is run, it will automatically pick up any other PROD version programs. As noted in the Administrating Ideal for Datacom page (Application Migration Considerations section), "When VER PROD is specified on the RUN command, Ideal goes directly to the object code and does not check the dictionary at all." Expanding on this, a PROD Version program calling a subprogram causes a request for the PROD object (or equivalent load module LMOD) without going to the Datadictionary to reconcile the version numbers. This is what sets PROD versions apart from the rest.
z/OS
Ideal
If you run a Program in TEST or LAST status, and if you enter a subprogram using PROD in the Resource section, there is a lookup in the Datadictionary for the PROD status program, and the PROD status is replaced with the absolute version number. Even if you duplicate a PROD status program to the next version, that new version will be in a TEST status, and it will resolve the Resource section entries to whatever is in the Datadictionary at that point. Then, when the program is compiled, you will be using the absolute version numbers, and any subsequent activity to the subprograms (to compile, or Mark to PROD, for example) will not update them in this main program.
For example, if you have Mainpgm (in TEST status), and it calls Subpgm, there are several different scenarios:
1. You create Mainpgm by Duplicating the current PROD version (e.g. 10) to the next version (11). Here, the Resource entry for Subpgm will contain the absolute version number of the PROD status entitiy (e.g., v20). If you compile this as it is without changes, you will replicate the production status behavior.
2. While you are waiting to make a change to Mainpgm, someone changes Subpgm (v21) and promotes it to PROD status, causing version 20 to be changed to HIST status. Now, Mainpgm still has Subpgm (v20) in its resource section. Any attempt to run Mainpgm will fail with an error:
FATAL ERROR OCCURRED
CLASS=SYS TYPE=USR RETURN CODE=12
DESCRIPTION: 1-IDAELPGM01E - PGM SUBPGM VER 20 must be in "TEST" or "PROD"
The change to Subpgm and promotion to PROD status does not change the absolute version number in the Resource section of Mainpgm, so your program as is will continue to try and use v20 as specified. Note that if you want to use your test version of Mainpgm with the previous version of Subpgm (v20), you will need to Duplicate version 20 to a new test version, and enter that version number in the Resource section of Mainpgm, since you cannot run with a History status version of the program.
3. While you are waiting to make a change to Mainpgm, someone changes Subpgm (v21) and promotes it to PROD status. Before making any other code changes, you can overtype the version for Subpgm in the Resource section of Mainpgm with either 21 (the new PROD version), or you can just overtype with "PROD" and the correct version will be obtained from the Datadictionary and used. You can then compile Mainpgm as usual, and your calls to Subpgm will use the current PROD status code.
This last scenario (#3, above) is the recommended approach if you desire to use the current PROD program. Of course, if you want to use any other version of Subpgm that might be in a TEST status due to changes, you would need to use that version number in your Resource section as usual.
To summarize, any time that your subprogram version changes, it is necessary to change the Resource section of your Main (or other calling programs) to reflect the correct version number for any subprograms, and then to recompile those calling programs.
As always, please contact Broadcom support for Ideal if you have further questions.