PM68788: PERFORM PURGE IS NOT HONORING THE STSTAT SETTING FOR NON-EDI DATA ADDED BY DT PROCESSING.

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Environment: WDI 3.3 for z/OS at current level running in batch
    
    PERFORM PURGE continues to re-mark transactions that have
    already been marked for purge. This pertains to records added
    from DT processing (ADF and XML).
    
    For example, ADF to EDI processing adds EDI side data and ADF
    side data to the store. The status is active as it has not yet
    date-expired. This would be a STSTAT(0).
    
    PERFORM PURGE WHERE HANDLE(*) STSTAT(0)
    
    This does what it should the first time, i.e. marks the EDI and
    ADF data accordingly as Purge - Marked by User.  However, when
    same command is re-run, it again marks the same ADF side data.
    While the EDI side of DT is not being re-marked, the ADF or XML
    side persists to be re-marked.
    
    Hence, it appears that PURGE is not honoring the STSTAT setting
    on the WHERE clause for non-EDI data added by Data
    Transformation processing.
    
    This is not an issue for Send/Receive map processing. This is
    working as expected.
    
    In high volume environments, re-marking for purge adds
    significant processing to the purge step overall.
    Keywords: purge purging purged transaction document store TS DS
    

Local fix

Problem summary

  • PERFORM PURGE continues to re-mark transactions that have
    already been marked for purge. This pertains to records added
    from DT processing (ADF and XML).
    For example, ADF to EDI processing adds EDI side data and ADF
    side data to the store. The status is active as it has not yet
    date-expired. This would be a STSTAT(0).
    PERFORM PURGE WHERE HANDLE(*) STSTAT(0)
    This does what it should the first time, i.e. marks the EDI and
    ADF data accordingly as Purge - Marked by User.  However, when
    same command is re-run, it again marks the same ADF side data.
    While the EDI side of DT is not being re-marked, the ADF or XML
    side persists to be re-marked.
    Hence, it appears that PURGE is not honoring the STSTAT setting
    on the WHERE clause for non-EDI data added by Data
    Transformation processing.
    This is not an issue for Send/Receive map processing. This is
    working as expected.
    In high volume environments, re-marking for purge adds
    significant processing to the purge step overall.
    

Problem conclusion

  • Some things noticed in evaluating the PURGE / REMOVE 1)
    performance degradation because each PURGE is remarking
    (updating)
    rows previously marked for purge 2) REMOVE doesn't recognize
    "purge-date expired" for Appl data and XML as it does for EDI
    data (S/R) in that EDI data doesn't need a PURGE to be
    run to have the expired rows removed.  3) the NUMDELS is not
    effective for Doc Store deletes; it works for the
    Tran Store deletes 4) With large numbers of rows in the DB,
    PURGE exhausts the DB buffers / storage and fails; rows updated
    are rolled back.  It would help to have a NUMUPDTS keyword on
    PURGE to COMMIT rows marked so that all updates are not lost and
    thus reduces rerun.  Presently, the HANDLE range is the
    primary way to reduce the numbers of rows processed at one time.
    5) Generally the performance of PURGE / REMOVE is slow and needs
    to be
    tuned since adding ADF and XML data.
    6) when processing a large number of rows, sometimes
    the handle values at the start of a prtfile report appear to
    be invalid, but correct at a later point in processing.  7) when
    dealing with ADF / XML handles in Doc Store, the processing
    was changed to match that of the EDI TS processing - in that
    rows with purge-date-exired status are not selected and not
    updated. They are removed with a PEROFRM REMOVE.
    The things changed with this PTR are:
    1) issue resolved
    2) issue resolved
    3) issue resolved
    4) issue resolved
    5) commits and avoiding remarking will improve peformance
    6) unable to reproduce
    7) issue resolved
    
    In summary, here are the issues and solutions with the Purge /
    Remove issues in the fix.  The below pertains to ADF and XML
    side of the
    Document Store.  1) PERFORM PURGE WHERE STSTAT(0)... , which
    indicates "Active" status on the PURGE, is re-marking (updating)
    transactions previously marked for
    purge.  This has been corrected to not mark them again.  2)
    PERFORM PURGE WHERE STSTAT(0)... does not filter out those that
    are already in a "Purge-date expired" status.  This has been
    corrected to not
    mark transactions that are already in an expired status.  3)
    REMOVE doesn't recognize "purge-date expired."  This has been
    corrected such that transactions no longer need to be marked by
    PURGE to have
    expired rows removed.  4) NUMDELS keyword is not effective for
    PERFORM REMOVE for Document Store deletes.  This has been
    corrected to commit based on NUMDELS parameter.
    Default is 100.  5) NUMUPDTS keyword has been enabled for
    PERFORM PURGE to commit marked
    transactions based on NUMUPDTS.  Default is 100.
    

Temporary fix

Comments

  • Applies to all WDI 3.3 platforms, part of SFP8
    

APAR Information

  • APAR number

    PM68788

  • Reported component name

    WEBS DI ZOS

  • Reported component ID

    5655I4003

  • Reported release

    330

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-07-12

  • Closed date

    2012-10-23

  • Last modified date

    2012-11-02

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

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

    UK81280

Modules/Macros

  • C        EDIDSDF  EDIDSGS  EDIDSRT  EDIDSS   EDIDSUSS EDIFFUS
    EDITSS   EDITSUS
    H        EDITSSI
    

Fix information

  • Fixed component name

    WEBS DI ZOS

  • Fixed component ID

    5655I4003

Applicable component levels

  • R330 PSY UK81280

       UP12/11/02 P F210

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:

z/OS family

Software version:

330

Reference #:

PM68788

Modified date:

2012-11-02

Translate my page

Machine Translation

Content navigation