IBM Support

PM70978: DSP1175E WHEN UPGRADE RECON IN IMSPLEX ENVIRONMENT WITH PARALLELRECON ACCESS ENABLED

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • This problem occurred in IMSplex environment with PRA enabled.
    When user issued the CHANGE.RECON UPGRADE command via batch
    job to upgrade the RECON, the online DBRC region detected a
    mismatch when it try to allocate the new COPY1 and COPY2 RECON
    data sets, then failed by message DSP1175E.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of IMS V12 planning to upgrade a   *
    *                 IMS 10 or IMS 11 RECON data set with         *
    *                 Parallel RECON access enabled.               *
    ****************************************************************
    * PROBLEM DESCRIPTION: MSGDSP1175E occured in online DBRC      *
    *                      region after an attempt to upgrade      *
    *                      a version 11 RECON failed when PRA      *
    *                      was enabled.                            *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    The original problem occurs because the RECON
    upgrade job encountered a VSAM access error that normally
    would be handled by the DBRC PRA retry processed.  The upgrade
    logic did not have retry handling and stopped the upgrade
    process. Also, because retry was not handled properly,
    the upgrade job passed RECON2 and RECON1 as the COPY1/COPY2
    datasets on the end-quiesce while the header extension
    state of these data sets indicated that RECON1 was good and
    RECON2 was bad.
    When it passed this information to the quiesced DBRCs,
    those DBRCs could not match the same configuration as they
    detected that RECON2 was bad. This resulted in the
    DSP1175E message.
    .
    The underlying issue is that the upgrade process is getting
    TVS locks during the upgrade process.  Depending on what
    records need changes during the upgrade, this could mean a
    large amount of locks are held.
    Not only can this fill the TVS lock structure, but is also slow
    and unnecessary.  Since the upgrade job owns the RECON
    under a DBRC quiesce, there is no need to do any locking.
    

Problem conclusion

  • GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    When PRA is enabled, if  an upgrade is done, rather than
    process the upgrade in RLS mode where locks are obtained,
    the RECONs will be closed and reopened in LSR mode during the
    upgrade process. This will be quicker and will be able to
    use the same error handling logic as when an upgrade is
    done without PRA enabled.
    
    DSPDSS01 - Add support to reopen both RECONs in a given mode
    for an OPEN or CLOSE function.
    
    DSPDSS30 - Add logic to NOT set the header extension open count
    to RIOX_OPCT if processing upgrade of a PRA enabled RECON.
    RIOX_OPCT is a timestamp for PRA and the header extension count
    should not be set to a timestamp value, but needs to retain
    the open count instead.
    
    DSPUCONS - Add constants to use to specify which RECONs to
    reopen.
    DSPURIR  - Add ChangeAccess routine that will setup to
    invoke the closeopen function in DSPDSS01.
    
    DSPURI00 - If doing upgrade and PRA is enabled, setup for
    LSR and then switch access mode to LSR prior to proceeding
    with the upgrade specific processing.  If the new steps
    fail, return RC=12 to the caller, reopening in RLS mode
    if needed.
    
    DSPURI01 - If PRA had been enabled prior to the upgrade process,
    invoke ChangeAccess to set the RECON access to RLS.
    
    DSPURI30 - Fix bug resulting in early end-quiesce for upgrade
    compare.
    
    DSPURU30 - DSPURU30 - fix problem of nest locates
    potential overwriting buffers
    
    
    DSPVFILE - add filpraupg flag
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM70978

  • Reported component name

    IMS V12

  • Reported component ID

    5635A0300

  • Reported release

    200

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-08-15

  • Closed date

    2012-11-27

  • Last modified date

    2013-01-02

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK83788

Modules/Macros

  •    DSPDSS01 DSPDSS30 DSPURIR  DSPURI00 DSPURI01
    DSPURI30 DSPURU30
    

Fix information

  • Fixed component name

    IMS V12

  • Fixed component ID

    5635A0300

Applicable component levels

  • R200 PSY UK83788

       UP12/12/06 P F212

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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Platform":[{"code":"PF054","label":"z Systems"}],"Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 December 2020