Upgrade from Gen 7.6 to 8.6 for IMS block mode applications using MFS.
Using CSE to generate code and z/OS IT to install it.
Some IMS application screens are displaying corrupted.
Two applications - tested and validated at r7.6 - have now been upgraded to r8.6, regenerated and rebuilt and re-deployed into the existing IMS regions.
There have been no changes to the applications as part of the upgrade; there have been no changes to the environment as part of the upgrade apart from the replacement of r7.6 runtime libraries with r8.6 runtime libraries, and swap of r7.6 statically linked modules for r8.6 dynamically linked modules.
The first of the two applications displays and processes fine.
The second application shows the main menu displayed fine but then the flow to sub-menus (proc->proc) appears to corrupt the screens at which point all subsequent interaction (function keys) fails.
Example showing corrupt lower rows:
Have investigated the complete build process from model configurations, to generation options, to build profiles and rebuilt the entire application twice - same results. These are the same configurations, options and profiles used to build both applications. This is what's confusing - no change to models, or environment between versions. Same build process used for both applications. One's working fine and one is most definitely not.
Release : 8.6
Component : Gen Run Time, Blockmode, IMS.
In Gen 7.6, the customer was using site-specific DEVICE TYPES and had not brought those reconfigurations forward to Gen 8.6
All IMS Screens must be regenerated with Gen 8.6 and reinstalled into IMS.
Under Gen 8.6:
- To alter the default DEVICE TYPE used for MFS screen generations, two configuration changes are required on CSE and z/OS IT (see Additional Information below)
- Regenerate all application code on the CSE and install using the z/OS IT
- Install generated MFS control block code into IMS. NOTE: It is required that this step is still done, even if the screens have not changed during the Gen upgrade or the device type has not been changed from the default.
MFS Device settings:
NOTE: For this particular example, the default "3270,2" needed to be changed to "3270-A02". However, that requirement may vary.
Client Server Encyclopedia Construction Client: Terminal Characteristics > Modify MVS MFS Devices
1. The "Gen?" flag controls which devices code will be generated for.
2. Per Toolset MFS Device Configuration Dialog the "Extended Attributes" flag on the device overrides the "Extended Attribute Support" parameter setting in the Business System Environment parameters - that also applies to the CSE.
3. Viewing the MFS Devices will automatically create a copy of the file "%Gen86%\CSE\bin\ief3303.dat" in directory "C:\ProgramData\CA\Gen 8.6\cfg\CSE\" (assuming the file does not already exist). The file "C:\ProgramData\CA\Gen 8.6\cfg\CSE\ief3303.dat" is then used whenever custom changes are made and is used at generation time.
Running "TSO %ITSYSADM" Option 3/Option 5 (MVS/IT IMS variables) shows the current default MFS device type: Configuring z/OS Implementation Toolset > Build Parameter files, SQL, and JCL > Display System Information
The default value can be changed in z/OS IT PARMLIB member TIRMFS.
In Gen 8.0 there was a change to use PARMLIB.
The PARMLIB member TIRMFS is created at install time.
The CLIST library CEHBCLS0 member TIRCFIGS calls CLIST TIRMFS which uses the info in PARMLIB member TIRMFS to set the TIRIMFSD variable.
So PARMLIB member TIRMFS is where any changes from the default need to be made.
Install MFS control block code into IMS:
Define IMS Block Mode Applications