PM78953: IMU NOT CREATING REPORT FILE &FILE

A fix is available

Subscribe

You can track all active APARs for this component.

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.



Rate this page:

(0 users)Average rating

Document information


More support for:

Migration Utility for z/OS
Migration Utility

Software version:

320

Reference #:

PM78953

Modified date:

2013-05-06

Translate my page

Machine Translation

Content navigation