II14218: OEM BUGS IN DFSMS DATA MANAGEMENT - OPEN/CLOSE/EOV, PDSE, ACCESS METHODS, CMM, CVAF, DADSM SEE CONTINUATION II14411

APAR status

• INTRAN

Error description

• This info APAR lists known third-party (OEM) problems in DFSMS
  data management components: non-VSAM o/c/eov, sequential access
  methods, CMM, PDSE, HFS, CVAF, and DADSM.  Where possible,
  OEM fix numbers are listed.  It is by no means a complete list.
  ---------------------------------------------------------------
  #1
  DS1LSTAR may be zeroes or a downlevel value after a full-volume
  or incremental backup under FDR/ABR.  This can happen for a
  sequential or partitioned data set.  For a multi-volume data set
  only one volume may be affected.  This can happen either on
  ABRINSTANT backup (SNAP, SPLIT, CONSPLIT, PSPLIT, or FCOPY) or
  on convential backup direct to tape or dasd.  This can only
  happend under program FDRABR, not under programs FDR or FDRDSF.
  This problem occurs even though ABR holds an ENQ or RESERVE on
  SYSVTOC, because OPEN/CLOSE/EOV does not issue a RESERVE on
  SYSVTOC when updating a DSCB.  The problem can occur when the
  application writing the data is running and ABR is backing up
  the volume at the same time.  At the end of the backup, ABR
  reads the F1DSCB and rewrites it to turn of the update bit
  (DS1DSCHA, DS1IND02) and to set ABR indicators in bytes 103 and
  104.  The following sequence can occur:
    - ABR reads the format 1 DSCB with the old DS1LSTAR value
    - In the application, EOV or CLOSE writes the DSCB with the
      new DS1LSTAR value
    - ABR rewrites the DSCB with the update bit off and the ABR
      indicators set, but with the old DS1LSTAR value
  The problem is very rare, because it can only happen if ABR and
  CLOSE or EOV attempt to update a DSCB at exactly the same time.
  The problem can be prevented by the user requesting data set
  level serialization in ABR.  This can be done by specifying
  DSNENQ=USE and ENQERR=BYPASS, and optionally ENQERR=NO.  Contact
  Innovation for details.
  For a sequential data set (PS), the old value to which the
  DS1LSTAR is reset is usually zero (except for DISP=MOD). Reports
  and displays such as ISMF, DCOLLECT and ISPF option 3.4 will
  show 0% used when there is in fact data on the volume.
  TSO functions such as ISPF Browse and Edit will say the data set
  is empty.  Batch jobs that just OPEN the data set with SAM
  will read and process the data correctly but programs such as
  SORT that issue OBTAIN and check the DS1LSTAR before OPEN
  will treat the data set (or the volume of the multi-volume data
  set) as empty.  No error messages or ABENDs will be issued.
  For a partitioned data set (PDS), the old value to which the
  DS1LSTAR is reset is the end of the previous member.  The
  member(s) that were written in this use of the data set will
  be overlaid the next time members are written.
  ----------------------------------------------------------------
  #2
  IEC999I IFG0RR0A IEC999I IFG0202L
  ABEND0C4 after processing in EMC's Softworks module PSPCLX30.
  EMC reports this:
  On examining the system log and reviewing the relevant sections
  of PSP code once more, it appears this problem was caused by
  the customer performing a DISABLE with REFRESH on PSP while the
  failing job was in progress. Ordinarily, this would not be a
  cause for concern; however, since STOPX37 activated for that
  step, this required that PSP update its file mask table.
  The DISABLE with REFRESH caused a number of PSP modules
  to be deleted from CSA and their associated storage freed,
  which accounted for the supposed overlay that I thought I had
  found with respect to PSPOPX30. The address for PSPNMK30 is
  stored as a VCON in PSPCOM30 along with the addresses of a few
  other PSP modules. As PSPCOM30 is non-reentrant and is kept in
  the user private area, there is no way to update the VCONs
  within it when a REFRESH occurs (the update is made only when
  the first OPEN occurs in a given job step for which PSP is
  active). The VCON for PSPNMK30 being residual under these
  circumstances, PSPCLX30 treated it as valid and so branched
  to a section of code that no longer existed in that location.
  Customers who encounter this situation may simply rerun the
  failing job as this customer did or temporarily quiesce the
  initiators on the affected operating system while the
  DISABLE/ENABLE process is performed.
  ----------------------------------------------------------------
  #3
  During HSM RECYCLE processing, a shutdown is issued for HSM.
  The following messages are received :
     DIF02600-A SPACE RECOVERY SYSTEM HAS BEEN STOPPED
     DIF02600-A DYNAMIC INSTALL FACILITY HAS BEEN STOPPED
     IEC999I IFG0204A, ...........
     ARC0003I ARCRCYDS TASK ABENDED, CODE 840C4000 IN 824
     ARC0003I(CONT.)MODULE UNKNOWN AT OFFSET 0000,STORAGE LOCATION
  The 0C4 abend occurs when IFG0204A had xferred control to
  IFG0204J who is now trying to return back to IFG0204A, whose
  vcon address points to storage that is either no longer valid or
  available.  The problem is caused by the timing sequence in
  which DIF is terminated during the shutdown. The workaround
  suggested by DTS is to bring down HSM before terminating the
  DTS products.  The DIF task should be stopped using a Z command
  instead of the SHUTDOWN command. There is also a zap from DTS
  that can be implemented to increase the WAIT time before it
  does the freemain. The DTS ticket # is DTS41226.  Please
  contact DTS for more info.
  ----------------------------------------------------------------
  #4
  EOV MODULE IFG0553F OVERLAID WITH DATA
  Flash Nbr: 2006-1267
  
  PURPOSE OF THIS MEMO:
  To notify sites running CA Vantage v11.5 SOS release level AB or
  vendor level SP0 that when running on z/OS 1.7 that the Raid
  Manager component may cause storage overlays requiring an ipl.
  
  REQUIRED CORRECTIVE ACTION:
  Review information below and install CA Vantage 11.5 SP2 or
  above - SOS release level AC.
  
  SPECIFIC INFORMATION:
  This is specific to z/OS 1.7 only - not reported on z/OS 1.4.
  
  Batch jobs executing various programs (WAAPDSUT, SYNCSORT,
  application PGMs, etc.) fail with S0C7 abends when processing
  multi-volume real tape datasets. Abends occurring in IGC0005E
  CSECT IFG0553F due to a 128-byte storage overlay.
  
  In another instance the overlay impacted a CA commons services
  module in CSA and many CA products would abend with a S0C4
  (CA VIEW, DELIVER, SYSVIEW, etc). The overlay data is the same
  in both cases - it looks to be DASD node descriptor data from
  some AMDAHL DASD.
  
  In both cases some products took errors and had to have
  repairs performed and the ipl to clear the storage overlay.
  (ie. CA Datacom, CA11, SAMS Vantage svc dump)
  ----------------------------------------------------------------
  #5
  ADRDSSU DUMP/RESTORE process is resetting the FORMAT-1 DSCB
  DS1REFD (Date Last Reference) field for PDSE data sets.
    The root cause was traced to the CA CA-DISK product. This
  product has an OPEN SVC that must be bypassed for DFSMS DFDSS
  processing.
    The problem can be rectified by modifying the CA-DISK
  ADSOPPGM SCRNLIST table to exclude calling the OPEN SVC for
  programs that begin with ADR.  12/13/06 PDSE RPK
  ---------------------------------------------------------------
  #6
  Copying PDSE datasets from one volume to another using ADRDSSU
  fails with following messages :
  ADR440E (003)-RALLC(02),
   UNEXPECTED RETURN CODE FROM REALLOC MACRO: 000000C8,
   WHILE PROCESSING DATA SET
  ADR472E (003)-NEWDS(11),
   UNABLE TO SELECT A TARGET VOLUME FOR DATA SET
  IEC614I CREATE FAILED - RC 200,
   DIAGNOSTIC INFORMATION IS (0446C008)
  The format 1 dscb extent area was being overlayed by DTS
  and resolved by DTS fix # DTS41233 .
  ----------------------------------------------------------------
  #7
  ABEND0C4 IFG0202K
    ABEND0C4 occurs in IFG0202K + x'A2E' trying to reset the
    DCBTIOT field.  R2 at this point in the code, is supposed
    to contain a 24 bit mode DCB address.  R2 is actually a
    31 bit address that points to an MMIB.  Breaking Event
    Address for this 0C4 shows BMC's XBM2CCRW routine was
    last in control and frontending Media Manager.
    BMC provided fix BPE0183 for XBM V5.4
  ----------------------------------------------------------------
  #8
  IEC999I IFG019CA ABEND0C4 USING VTS
  0C4 was actually in CA module TMSOCEPR P5XD394 04/15/05 09.15.
  CA provided the following fix information :
  DESCRIPTION: When captured UCBs are protected, tape jobs abend
  with S0C4-4. Within the IECIOSxx memberSYS1.PARMLIB, the default
  for CAPTUCB is PROTECT=YES with z/OS 1.7. With this default
  setting, any attempt to modify a captured UCB will abend.
  CIRCUMVENTION/PROPER HANDLING: Disable captured UCB
  protection until this fix can be installed.
  ----------------------------------------------------------------
  #9
  COMPID=DF115,CSECT=IGWLXFRL+0000,DATE=04/10/06,MAINTID= NONE
  ,ABND=0C4,RC=00000000,RSN=00000011
  S0C4 PIC11 in IGWLHA30+145E HDZ1180 base level
  This appears to be a problem with relocation of 64-bit 8-byte
  ADCONs .
  Problem is in CA-Quickfetch.  CA fix is QO82736
  06/07/2007 - Previous info from CA indicated that QO82736 was
  the fix. Now, CA says there is a TESTFIX T458368 which will fix
  this problem. It has not been published yet but when it is it
  will be assigned a QOxxxxx number. A handful of CA clients have
  applied this fix with good success.
  PDSE Quickfetch S0C4 0C4 Computer Associates
  ----------------------------------------------------------------
  #10
  Following errors received when processing tapes using STK 9840A
  & 9840B tape drives in 3590 mode
  IOS000I 40DD,8B,IOE,02,0200,,**,,ITCXS62X
   004910D050205451 2402FF300000C1F4 C1F4F9F9F1F20290
  4104230127511010
   UNSUPPORTED FORMAT
  IEC512I I/O ERR 40DD,      ,NL,
  IEC502E R 40DD,,     ,NL,
  IEC501A M 40DD,PRIVAT,SL,COMP,
  The IEC512I I/O error is detected because the sense returned
  from the hardware does not indicate there is volid in sense
  data.  As a result, Open doesn't proceed in retrieving the
  volser information from the sense data.  STK provided
  microcode patch for the 9840A/B code which resolved the
  problem.  Contact STK for official fix information.
  ----------------------------------------------------------------
  #11
  ABEND214 RC10 using SYNCSORT
    IEC537I BLOCK COUNTS: DEVICE count always greater than DCB.
    Problem resolved by SYNCSORT apars for ver 1.1D TPF 3.
    They are SY61083 , SY61471 and SY60170 .
    For ver 1.2 TPF2.3 , the fixes are built in .
  ----------------------------------------------------------------
  #12
  PDSE corruption due to OEM vendor product RTD moving PDSE data
  set extents. Problem occurs with the implementation of PDSE
  Buffer Beyond Close. Reported PDSE corruption includes
  RSN050A0046 and RSN150BC008. Contact OEM vendor for RTD
  r6.2.0.C product upgrade.
  ----------------------------------------------------------------
  #13
  ABEND0C4 in IAM0192A (IFG0192A) because during OPEN, IAM
  detects that the BIM support bit is set in the IAM GLOBAL
  Options Table. When this is set, they look to see if we have
  the address of BIM interface modules. In this case there
  where no BIM interface modules, so seting the GLOBAL OPTIONS
  to DEFAULT (no BIM) resolved the problem
  ----------------------------------------------------------------
  #14
  IEC141I ABEND013 RC48 REUSING DCBS WITH PAV DEVICES
    Syncsort fix EW6515-0 resolves the problem.
  ----------------------------------------------------------------
  #15
  IEC145I 413-34 IFG0194F using VOLREF
    ABEND413 RC34 occurs when using DEVSUP in IEASYS00 with
  VOLNSNS=YES to use tapes that were previously 256-track as
  scratch on 128-track devices . LABEL=(1,SL) is relabeled
  successfully.  The next step does a referback the first step
  via VOL=(,RETAIN,REF=*.STEP01.SYSUT2),LABEL=(2,SL) and
  receives the 413-34 due to jfcbvolser being blanks as seen in
              IEF285I   VOL SER NOS=_______.    << blanks
  Problem was resolved by CA-DYNAM/TLMS fix QO85613 for
  TLMS R11.5.  This fix is part of the SP01 maintenance tape.
  ----------------------------------------------------------------
  #16
  Loop in IGWLGSUB on ENQUEUE to the major name SYSZIGW0. SYSTRACE
  shows repeative SVC38 entries. Client executing in a monoplex
  with PDSESHARING(EXTENDED), GRS=NONE and CA-MIM environment.
    OEM vendor fix QO95647 resolves this issue. OEM reported
  additional symptom of S213 RC70. (ABEND213 MII RC=70)
  

Local fix

• See continuation info apar II14411
  

Problem summary

Problem conclusion

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:

Fix information

Applicable component levels