PI62507: CURRENTLY PRF DOESN?T RETRY DLI JOBS IF THEY ABENDED, REGARDLESSOF AUTOBKO VALUE AND WHETHER BACKOUT IS REQUIRED OR NOT

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Currently PRF doesn?t retry DLI jobs if they abended, regardless
  of AUTOBKO value and whether backout is required or not.
  However, if BBO was disabled via a DD, abended DLI job is
  automatically retried.
  Help panel IRTZ8000 says that only BMPs should be retried.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Users of Program Restart Facility V2R2.  *
  ****************************************************************
  * PROBLEM DESCRIPTION: PRF-controlled DLI/DBB jobs should not  *
  *                      normally be allowed to go through       *
  *                      reattach processing because this would  *
  *                      result in invalid recovery logs. In the *
  *                      one case where PRF-controlled DLI/DBB   *
  *                      jobs are allowed to go through reattach *
  *                      processing, PRF does not perform the    *
  *                      reattach processing unless batch        *
  *                      backout functionality has been          *
  *                      disabled. If batch backout              *
  *                      functionality is disabled, PRF will     *
  *                      ignore the CMPCBKOK and CMPCBKER        *
  *                      specifications.                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When batch backout processing is disabled in a PRF-controlled
  DLI/DBB job, and abend retry is active for the job, PRF
  re-attach processing can take place if the PRF job abends with
  one of the abend codes that exist in the abend retry table for
  the job. Re-attach processing should never occur for a DLI/DBB
  job unless RDORETRY processing is active for the job. This is
  because the current architecture of PRF only allows for a single
  allocation of the IMS logs for the job step. Any attempt to
  perform re-attach processing would result in the re-attached
  process overlaying the IMS log from the previous process. In the
  one case where re-attach processing in a DLI/DBB environment can
  safely take place, PRF does not allow re-attach processing to
  occur unless batch backout processing has been explicitly
  disabled for the job step.
  
  When PRF is completely disabled by the EXCLUDE=YES parameter, or
  by the presence of a DD name from the exclusion DD name table,
  messages are issued so that the user can verify the presence of
  PRF and why the job was excluded from PRF processing. In the
  case where the IRT$IGNR DD statement is present in the job step,
  no indication is made that PRF is present, or that PRF was
  disabled.
  
  When batch backout processing is disabled in a PRF-controlled
  DLI/DBB job, PRF will ignore the job's CMPCBKOK/CMPCBKER
  specifications on abend, and will cause the job to abend with
  the originating abend code instead.
  

Problem conclusion

• The Program Restart Facility restart logic has been modified
  to not allow DLI/DBB jobs to go through re-attach processing
  unless RDORETRY processing is active for the job.
  
  When the IRT$IGNR DD statement is present in a job step, an
  IRT316I message will be generated to verify that PRF was
  present, and that it was inactivated for the job step.
  
  PRF will no longer ignore the CMPCBKOK/CMPCBKER specifications
  in a DLI/DBB job unless the following situation arises: If a job
  abends in such a way that ESTAE recovery routines cannot attempt
  retry processing, an attempt to change the originating abend
  code would fail. This situation can arise, for instance, in the
  case of an OS CANCEL of the job in question.
  

Temporary fix

Comments

APAR Information

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

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

  UI38848

Modules/Macros

• IRTOPG1  IRTOPJ1  IRTPRE00 IRTRCC00 IRTUPX00
  IRTZF113
  

Fix information

• Fixed component name

  IMS PGM RESTART

• Fixed component ID

  5655E1400

Applicable component levels

• R220 PSY UI38848

     UP16/06/24 P F606

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.