A fix is available
APAR status
Closed as program error.
Error description
---------------------------------------------------------------- PMR 01127,370,000 - IMU Not creating REOPORT FILE &FILE Date reported: 11/13/2012 Severity: High Users Affected: All IMU users of MU V3.2 Problem Description: IMU does not create the file specified on the report statement via the FILE &file option parameter. Problem Summation IMU creates its own work file for spooling. The FILE &DDNAME on REPORT statement is ignored. Problem Conclusion: The EASYT007 macro was changed to use the FILE &DDNAME in the place of TEMPWKnn. The &DDNAME file is created even if there is no REPORT SEQUENCE statetment specified. RPTFILE=NATIVE/EASYT option was added to EZPARAMS/EASYTRAN options table so that existing users are not impacted by this change. where: RPTFILE=NATIVE Option ignores the FILE &DDNAME on the report statement. This is the default (the way IMU has been working). Existing users are not impaceted by this option. RPTFILE=EASYT Option accepts the FILE &DDNAME on the report statement. Existing users may be impacted, therefore it is suggested that this specific option is coded in the Easytrieve Plus program rather than the EZPARAMS default table. Example, the following can be placed at the top of the program after the PARM statement: * EASYTRAN: RPTFILE=EASYT * END-EASYTRAN New users of IMU can add the RPTFILE=EASYT option to the EZPARAMS default table. Caution: Coding RPTFILE=EASYT option will force MOVERPT=NATIVE option even if MOVRPT=EASYT is specified. This is done so that the record layout of FILE &FILE is built in the same sequence as coded on the report CONTROL, TITLE and LINE statements. The following macro were changed in FSOFT01.V2R3M0.SFSYFJCC EASYT007 - existing macro CCGSORT - existing macro EASYTRAN - existing macro EASYOVRD - existing macro ---------------------------------------------------------------- PMR 05832,004,000 - REPORT EVERY option not working with SEQUENCE option. Date reported: 11/30/2012 Severity: high Users Affected: All IMU users of MU V3.2 Problem Description: The EVERY REPORT statement option is not working when SEQUENCE is in use. Problem Summation The EVERY option logic is not generated when SEQUENCE is in use. It works when REPORT SEQUENCE is not specigfied. Problem Conclusion: The GENERATQ macro was changed to expand logic for EVERY when SEQUENCE is in use. Changed macros: FSOFT01.V3R2M0.SFSYFJCC GENERATQ - existing macro ---------------------------------------------------------------- PMR 35398,422,000 - S0C4 in Easytrieve program run under IMU caused by bad index Date reported: 10/31/2012 Severity: medium Users Affected: All IMU users of MU V3.2 Problem Description: Customer is getting SC04 abend on instruction that uses a two dimensional field. Problem Summation IMU defaults subscript to 1 when a field with two ore more dimensions is accessed with fewer subscript than implied by the field definition, and the parent group field is defined as an INDEXED field. Example, for field definition WZ-NAME2: WZ-NAME-ADDR W 411 A INDEX WZ-INDEX1 WZ-NAME2 WZ-NAME-ADDR 1 A OCCURS 411 WZ-NAME1 WZ-NAME-ADDR +361 50 A The instruction: MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB) Is generated as MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB, 1) When it should be MOVE 'xxxxxx' TO WZ-NAME2 (WZ-INDEX1-001, WZ-SUB) Note that reverse is functioning properly. Example: for field definition WZ-NAME2: WZ-NAME-ADDR W 411 A OCCURS 411 WZ-NAME2 WZ-NAME-ADDR 1 A INDEX WZ-INDEX1 WZ-NAME1 WZ-NAME-ADDR +361 50 A The instruction: MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB) Is generated correctly as: MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB, WZ-INDEX1-001) Problem Conclusion: INDEXUSE=NATIVE/EASYT EASYTRAN/EASYPARAMS option was added to avoid impact on the existing users. The EASYT007 macro was changed to do the following: For INDEXUSE=NATIVE, IMU will handle index the old way (as is doing it now). This is the default. For INDEXUSE=EASYT, IMU will recognize the missing index and merge it with the supplied subscript. Customer impact: The default of INDEXUSE=NATIVE is compatible with the existing code, therefore the existing custmers are not impacted. New IMU users who wish to take advantage of the INDEXUSE=EASYT option should add the INDEXUSE=EASYT option to the EZPARAMS default table before conversion starts. Otherwise, option can be added to selective programs by adding the following at the top of the EZT Plus source (but after the PARM statement): * EASYTRAN: INDEXUSE=EASYT * END-EASYTRAN The following macros were changed: FSOFT01.V3R2M0.SFSYFJCC EASYT007 - existing macro EASYTRAN - existing macro EASYOVRD - existing macro ---------------------------------------------------------------- New PMR - 45644,379,000 - Abend 0C9 rc9 in FSCCOBOL Date reported: 11/07/2012 Severity: High Users Affected: All IMU users of MU V3.2 Problem Description: User is getting ABEND 0C9 RC9 in FSCCOBOL (overflow exception) Problem Summation The problem occurs in FSSETA00 submodule when number larger than the maximum value of BL4 field is converted to binary format via CVB, i.e., a number > 2147483647. The problem was caused by the ADOIF in EASYT007 when &ZF3 variable contains value larger than 2147483647. The following instruction caused the error: ADOIF (&ZF3 GT 999999999).YERROR62 .FOR TWO BYTE FIELD Problem Conclusion: The FSSETA00 program was changed to test for maximum value before the CVB instruction is attempted. Also, the value in &ZF3 variable in EASYT007 is validated before the ADOIF is attempted. The following modules are impacted: FSOFT01.V3R2M0.SFSYFJCC EASYT007 - existing macro FSOFT01.V3R2M0.SFSYLOAD FSCCOBOL - existing program FSCCOB31 - existing program FSCASSEM - existing program XXCCOBOL - existing program ---------------------------------------------------------------- PMR 47976,379,000 Record length limited to 32k for VSAM files Date reported: 11/29/2012 Severity: High Users Affected: All IMU users of MU V3.2 Problem Description: IMU is flagging VSAM file definition with record length over 32k. Problem Summation There is a hard coded check in EASYT007 macro for record length of 32k. Problem Conclusion: The hard coded restriction was removed from EASYT007 for all VSAM files. Changed: FSOFT01.V3R2M0.SFSYFJCC EASYT007 - existing macro ----------------------------------------------------------------
Local fix
N/A
Problem summary
**************************************************************** * USERS AFFECTED: All IMU V3.2 users. * **************************************************************** * PROBLEM DESCRIPTION: 1. IMU does not create the file * * specified on the report statement * * via the FILE &file option parameter. * * * * 2. The EVERY REPORT statement option * * is not working when SEQUENCE is * * in use. * * * * 3. Customer is getting SC04 abend on * * instruction that uses a two * * dimensional field. * * * * 4. User is getting ABEND 0C9 RC9 in * * FSCCOBOL (overflow exception) * * * * 5. IMU is flagging VSAM file definition * * with record length ove 32k. * * * **************************************************************** * RECOMMENDATION: Apply the PTF. * **************************************************************** 1. IMU creates its own work file for spooling. The FILE &DDNAME on REPORT statement is ignored. 2. The EVERY option logic is not generated when SEQUENCE is in use. It works when REPORT SEQUENCE is not specigfied. 3. IMU defaults subscript to 1 when a field with two ore more dimensions is accessed with fewer subscript than implied by the field definition, and the parent group field is defined as an INDEXED field. Example, for field definition WZ-NAME2: WZ-NAME-ADDR W 411 A INDEX WZ-INDEX1 WZ-NAME2 WZ-NAME-ADDR 1 A OCCURS 411 WZ-NAME1 WZ-NAME-ADDR +361 50 A The instruction3 MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB) Is generated as MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB, 1) When it should be MOVE 'xxxxxx' TO WZ-NAME2 (WZ-INDEX1-001, WZ-SUB) Note that reverse is functioning properly. Example: for field definition WZ-NAME2: WZ-NAME-ADDR W 411 A OCCURS 411 WZ-NAME2 WZ-NAME-ADDR 1 A INDEX WZ-INDEX1 WZ-NAME1 WZ-NAME-ADDR +361 50 A The instruction: MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB) Is generated correctly as: MOVE 'xxxxxx' TO WZ-NAME2 (WZ-SUB, WZ-INDEX1-001) 4. The problem occurs in FSSETA00 submodule when number larger than the maximum value of BL4 field is converted to binary format via CVB, i.e., a number > 2147483647. The problem was caused by the ADOIF in EASYT007 when &ZF3 variable contains value larger than 2147483647. The following instruction caused the error: ADOIF (&ZF3 GT 999999999).YERROR62 .FOR TWO BYTE FIELD 5. There is a hard coded check in EASYT007 macro for record length of 32k.
Problem conclusion
1. The EASYT007 macro was changed to use the FILE &DDNAME in the place of TEMPWKnn. The &DDNAME file is created even if there is no REPORT SEQUENCE statetment specified. RPTFILE=NATIVE/EASYT option was added to EZPARAMS/EASYTRAN options table so that existing users are not impacted by this change. where: RPTFILE=NATIVE Option ignores the FILE &DDNAME on the report statement. This is the default (the way IMU has been working). Existing users are not impaceted by this option. RPTFILE=EASYT Option accepts the FILE &DDNAME on the report statement. Existing users may be impacted, therefore it is suggested that this specific option is coded in the Easytrieve Plus program rather than the EZPARAMS default table. Example, the following can be placed at the top of the program after the PARM statement: * EASYTRAN: RPTFILE=EASYT * END-EASYTRAN New users of IMU can add the RPTFILE=EASYT option to the EZPARAMS default table. Caution: Coding RPTFILE=EASYT option will force MOVERPT=NATIVE option even if MOVRPT=EASYT is specified. This is done so that the record layout of FILE &FILE is built in the same sequence as coded on the report CONTROL, TITLE and LINE statements. 2. The GENERATQ macro was changed to expand logic for EVERY when SEQUENCE is in use. 3. INDEXUSE=NATIVE/EASYT EASYTRAN/EASYPARAMS option was added to avoid impact on the existing users. The EASYT007 macro was changed to do the following: For INDEXUSE=NATIVE, IMU will handle index the old way (as is doing it now). This is the default. For INDEXUSE=EASYT, IMU will recognize the missing index and merge it with the supplied subscript. The default of INDEXUSE=NATIVE is compatible with the existing code, therefore the existing custmers are not impacted. New IMU users who wish to take advantage of the INDEXUSE=EASYT option should add the INDEXUSE=EASYT option to the EZPARAMS default table before conversion starts. Otherwise, option can be added to selective programs by adding the following at the top of the EZT Plus source (but after the PARM statement): * EASYTRAN: INDEXUSE=EASYT * END-EASYTRAN 4. The FSSETA00 program was changed to test for maximum value before the CVB instruction is attempted. Also, the value in &ZF3 variable in EASYT007 is validated before the ADOIF is attempted. 5. The hard coded restriction was removed from EASYT007 for all VSAM files.
Temporary fix
Comments
APAR Information
APAR number
PM78953
Reported component name
MIGRATION UTILI
Reported component ID
5697N4400
Reported release
320
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-12-11
Closed date
2013-02-06
Last modified date
2013-05-06
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK91448
Modules/Macros
FSYASSEM FSYCBQUE FSYCCBOL FSYCCB31 FSYCGSRT FSYESORD FSYETRAN FSYET007 FSYGRATQ FSYXCOBO
Fix information
Fixed component name
MIGRATION UTILI
Fixed component ID
5697N4400
Applicable component levels
R320 PSY UK91448
UP13/04/02 P F304
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSY4B9","label":"IBM Migration Utility for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"320","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
27 October 2020