OA32551: Spool browse errors due to changing buffer size **APAR IN ERROR-SEE OA34563

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• As part of spool browsing, errors may occur if JES2 reads a
  buffer and later encounters the same buffer -AND- the second
  instance has changed in size as discussed in the scenarios
  below.
  
  ANALYSIS:
    Scenario 1
  The size of the buffer has changed due to transitioning between
  a z/OS 1.11 member(s) -AND- pre-z/OS 1.11 member(s).  A TSOuser
  browsing an active job can encounter SDSF error message 'SPOOL
  DATA ERROR' if:
  The job being browsed converted on a pre-z/OS 1.11 member
  -AND-
  The same job executes on a z/OS 1.11 member (or vice versa)
  
    Scenario 2
  The size of the buffer has changed due to JES2 reading the
  in-storage copy first, and then reading the same buffer from
  spool and finding it is smaller (regressed in size).   When
  browsing an active job (not release specific), it is
  possible that the in-storage copy has not yet been written to
  spool; thus, JES2 finds a regressed buffer on spool.  As
  such, pointers in the control block such as BFDLOC may be
  incorrect positioned leading to various errors such as abend0C4.
  
  
  EXTERNAL SYMPTOMS:
  When attempted to browse an active job, the TSO user will
  encounter errors such as SDSF 'SPOOL ERROR' or abend0C4.
  
  This APAR also addresses a situation where EOF may be repeatedly
  returned through the spool data set browse GET interface without
  issuing a POINT.
  
  
  KNOWN IMPACT:
  After encountering the 'SPOOL ERROR', the job output being
  browsed will appear incomplete/missing.  Once the job terminates
  the complete output will be able to be viewed.
  
  Symptoms may vary. An overlay of UCB's or other storage is
  possible resulting in IOS abends.
  
  
  VERIFICATION STEPS:
  1> BFDLOC is incorrectly positioned - that is, not pointing to
     the end of buffer or the next record.
  2> PSW *may* point to seq# 06057000 in HASCHAM
  3> For scenario 1:
     A> Active job being browsed converted on pre-z11 member and
        executed on a z11 member (or vice versa)
     B> TSOuser encounters 'SPOOL ERROR' messsage A> SDSF trace
        of the error shows failing GET RPLFDBK = 0C0204
     C> GTF SB trace through HASCPHAM routine PROTSRB shows two
        calls for the same failing UBF.
     D> The second time through PROTSRB, the UBF has changed in
        size (no new records added, but the existing record $LRC
        and $SCR has increased/decreased in size).
  3> For scenario 2:
     A> Abend0C4 occurs in HASCHAM when attempting to read a
        buffer.
     B> Systrace shows (with a short time span) a buffer was
        previously read via a PROTSRB and then reread via an I/O
        from spool
  

Local fix

• If scenario 1:
  Ensure jobs convert and execute on a JES2 member of the same
  level by utilizing SYSAFF parm
  
  If scenario 2:
  None
  
  ------------------------
  
  CAPTUCB protection should be turned on to prevent additional
  fallout resulting from overlaid UCBs
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of HJE7740, HJE7750, HJE7760 and   *
  *                 HJE7770.                                     *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABEND0C4, IOS abend, or SDSF error      *
  *                      message 'SPOOL ERROR' encountered while *
  *                      browsing a SPOOL dataset.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  I/O errors are returned when SPOOL data set browse is used to
  access the JESMSGLG or JESYSMSG data set for a job that is in
  execution.  The problem occurs if the job has not completed at
  least one step and the level of JES2 member where the job is
  executing is HJE7760 or later and the level of JES2 member where
  the job got converted is HJE7750 or earlier (or vice-versa).
  Buffers written to SPOOL by HJE7750 and earlier have a shorter
  prefix (SCR) than those written by HJE7760 and later.  This
  difference can cause SPOOL browse to lose orientation for data
  in the buffer, causing the I/O error.  ABENDS0C4 may be
  encountered while browsing a JESMSGLG or a JESYSMSG dataset that
  is being actively written to, in a MAS with all same level
  members.  After scheduling SRBs to get the updated in-storage
  buffer, a SPOOL I/O or an additional SRB is done to get the
  updated buffer.  If the buffer is also being written to SPOOL
  multiple times and the write to SPOOL is delayed we might have a
  situation where there are two pending writes of the same buffer
  in different stages on the queue.  An I/O read in this scenario
  can result in acquiring a spooled buffer that has less data than
  the previously obtained buffer.  BFDLOC can be incorrectly
  positioned and result in ABEND0C4.
  

Problem conclusion

• *****************
  * APAR IN ERROR *
  * SEE OA34563   *
  *****************
  TYPE/RESTART(WARM) IPL/REQUIRED(YES) CLPA(YES)
  .
  CLPA is needed only if HASCxxxx modules currently reside in
  the pageable link pack area (PLPA).
  .
  **********************************************************
  *                                                        *
  *  You may continue to experience this problem until all *
  *  members of the MAS have this fix applied.             *
  *                                                        *
  **********************************************************
  
  Code is added in HASCPHAM to validate the current pointer into a
  buffer (BFDLOC) when a buffer is re-read from SPOOL or obtained
  via SRB from an active address space.  If the size of the prefix
  (SCR) has changed from what was previously read, the buffer
  pointer is re-computed.
  
  Documentation hold for OA32551:
  The information in the following manuals/publications is
   missing:
   1.z/OS V1R9   MVS System Codes    SA22-7626-16
   2.z/OS V1R10  MVS System Codes    SA22-7626-18
   3.z/OS V1R11  MVS System Codes    SA22-7626-20
   4.z/OS V1R12  MVS System Codes    SA22-7626-22
  
   Following will be added in 2.0 System completion codes
   under 2.34 02A
  
   00000014
      HASP access method found a bad BFDLOC value during GET
      processing.
  
   Updates will only be made to the 'MVS System Codes' manual
   in future MVS releases.
  
  Searchable keywords  R11COEXS/K R12COEXS/K R13COEXS/K
  
  APAR OA32551 prereq's (and sup's) for FMID HJE7740:
  Pre's: CA25320 CA27313
  
  APAR OA32551 prereq's (and sup's) for FMID HJE7750:
  Pre's: DA25320 DA27313
  
  APAR OA32551 prereq's (and sup's) for FMID HJE7760:
  Pre's: EA28535 EA25320 EA29470 EA30118
  
  APAR OA32551 prereq's (and sup's) for FMID HJE7770:
  Pre's: * NONE *
  KEYWORDS: ZOS0201C/K ZOS0202C/K
  

Temporary fix

• *********
                      * HIPER *
                      *********
  *** * TEMPORARY FIX MAY BE OBTAINED FROM DLL OR INFO/ACCESS ****
  ******************* OA32551  DECK AVAILABLE ********************
  

Comments

• ×**** PE10/10/13 PTF IN ERROR. SEE APAR OA34563  FOR DESCRIPTION
  

APAR Information

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

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

  UA56737 UA56738 UA56739 UA56740

Modules/Macros

• $BUFFER  $HASPEQU $OFFSTBL HASCHAM  HASCOFST
  HASCPHAM HASCUBSR
  

Fix information

• Fixed component name

  JES2

• Fixed component ID

  5752SC1BH

Applicable component levels

• R740 PSY UA56737

     UP10/09/23 P F009 Ž

• R750 PSY UA56738

     UP10/09/23 P F009 Ž

• R760 PSY UA56739

     UP10/09/23 P F009 Ž

• R770 PSY UA56740

     UP10/09/23 P F009 Ž

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.