II02516: VARIOUS PROBLEMS CAN OCCUR WHEN SZERO=NO IS CODED ON THE ATTACH MACRO. ISPF SPLIT SCREEN VSAMINFO

APAR status

• Closed as canceled.

Error description

• Various unpredictable results can occur when SZERO=NO is coded
  for an ATTACH macro in the VSAM environment.  The VSAM Admin-
  stration Guide, under the topic "SUBTASK SHARING" states:
  
     "If the ATTACH macro is used to create a new task that will
      be processing a shared dataset, allow the ATTACH keyword
      SZERO to default to YES or code SZERO=YES."
  
  Sharing subpool 0 comes to play in this scenerio because all
  VSAM needs subtasks to share subpool 0 (SP0).
  
  NOTE: THIS INFORMATION PER 'SUBTASK SHARING' CAN NOW BE
        FOUND IN THE DFSMS/mvs 'USING DATA SETS' MANUAL
        SC26492200 CHAP12 PAGE158
  
  ****************************************************************
  * MOST COMMON SYMPTOMS:                                        *
  ****************************************************************
  The most common symptoms of this problem occur as intermittent
  ABEND0C4's in VSAM Open and Close modules. IDA0192A and IDA0200T
  are the most frequently seen modules.  Various FREEMAIN errors
  can also occur at close time if the close is issued from a
  different TCB than the TCB that did the Open.
    ABEND378 rc14 rsn14 in IDA0200T IDA0200B
    ABEND0C4 PIC10 IDA0192S SMF ISPTASK
    ABEND0C4 PIC11 IDA0200B AMB is freed
    ABEND0C4 PIC11 IDA0200B because some of the PLH's, BUFC's or
      IOMB's are freed.
    ABEND0C4 PIC11 IDA0192B AMDSB is freed
  *
  Often the ABEND0C4 will occur after an ABEND13E.  Unfortunately,
  the detach SVC3E may have scrolled out of the system trace by
  the time the ABEND0C4 dump is taken.
  *
    The ABEND0C4 is caused by a program interrupt, code of 11,
  (PIC11) usually because the failing instruction is trying to
  access a PLH or IOMB.  It can also abend trying to access any
  VSAM control block built in sp0 or sp250 (these are the subpools
  that RTM will freemain at the time of the detach) such as the
  BUFC header, BSPH, BUFC, AMDSB, ARDB etc.
    Often the problem is encountered when running TSO,
  but any program using the ATTACH macro can cause this problem.
  *
  Note: In IDA0192A, the problem is usually seen around offset
  x'55E' where REG5 is loaded from REG1 to loop thru the PLH's.
  In IDA0200T, the problem is very similar, where REG5 is used to
  access the PLH and the storage is no longer available.
  When the ABEND0C4 occurs in IDA0200B, it is usually because
  the AMBL is still on the AMBL chain, but the AMB has been
  freed.
  
  ****************************************************************
  * KNOWN CAUSERS OF THE PROBLEM                                 *
  ****************************************************************
  A split screen under ISPF or IPCS is the most common cause of
  the problem.  Some of the older APARs that describe the problem
  are OZ56516 and OZ60996.  But as APAR OZ66402 states, this is a
  PERMANENT RESTRICTION.  There are also OEM products, used for
  browsing VSAM dataset, that cause this problem when used under
  split screen.
  
  ADDITIONAL KEYWORDS:
  5752SC1DE 566528418 566529518 566528451 566528452 5695DF106
  JDM1113 JDM1141 JDM1134 JDM1136 JDM1137 JDM1139 JDP3310
  JDM1145 HDQ1102 JDQ1110 HDP1102 JDP1110 JDP1111 HDP3320
  HDP2240 R240 HDP3330 R330   JDZ1110 R110 HDZ11B0 R1B0
  HDZ11C0 R1C0 HDZ11D0 R1D0 HDZ11E0 R1E0 HDZ11F0 R1F0 HDZ11G0 R1G0
  

Local fix

• Code SZERO=YES when attaching a TCB or code enough strings and
  buffers (STRNO BUFNI BUFND) on the initial Open to make sure
  that DYNAMIC STRING ADDITION is never invoked under a subtask.
  

Problem summary

Problem conclusion

Temporary fix

Comments

• VSAMINFO: SEE ISPF OZ66402  ALSO SEE OY18692
            ATTACH SVC42 (0A2A)
  

APAR Information

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

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

Fix information

Applicable component levels