II13050: OEM BUGS IN DFSMS DATA MANAGEMENT - OPEN/CLOSE/EOV, ACCESS METHODS, PDSE, HFS, CMM, CVAF, DADSM

APAR status

• INTRAN

Error description

• This information APAR is a continuation of II12279 and is
  continued in II14706
  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
  Cobol program fails with the following under OS/390 2.10 :
  +ULTI002MA SP30599Q,XNNERROR,REPORT00,XNNERROR,PGMSNB,Ext,Oldblk
       ->  Newblk=27940,Input ,
           SP3.EDD.WKFL.COEDD103.REPORT00
  +ULTI003MA SP30599Q,XNNERROR,REPORT00,XNNERROR,PGMSNB,Ext,Blksiz
       -> ,Bufnum=00005,Input ,
           SP3.EDD.WKFL.COEDD103.REPORT00
  IEC020I 001-4,SP30599Q,XNNERROR,REPORT00,0D0F,PGM09R,
  IEC020I SP3.EDD.WKFL.COEDD103.REPORT00
  IEC020I DCB EROPT=ABE OR AN INVALID CODE, AND/OR NO SYNAD EXIT
  +CEE0374C CONDITION = CEE3250C TOKEN = 00040CB2 61C3C5C5 0000000
            WHILE RUNNING PROGRAM IGG019AQ
  Under LE 1.5, the first step of a program created a dataset with
  an lrecl from which an optimum blocksize was calculated.
  The subsequent job step adds on to the data set.
  Under R703, the blocksize does not get optimized.
    Ultimizer identified a change related to their product on
  OS/390 2.10 and provided the following replacement modules.
   ULTIC00   R200      09/10/01  16.56
   ULTI010   R310      10/18/01  08.32
   ULTI020   R310      10/02/01  09.55
   ULTI100   R200/M00  10/02/01  09.5
  ----------------------------------------------------------------
  #2
  ABEND0C4 in IFG0194F or IFG0198N using CA7 OEM product because
  the psw is in 24-bit mode when it should be in 31-bit mode.
  Fix is an ACF2 APAR LO81983.
  ----------------------------------------------------------------
  #3
  PARTITIONED DATA SETS DON'T GET BACKED UP WITH CA-DISK PRODUCT
    PDS datasets that have been edited via ISPF don't get backed
  because the DS1IND02 bit is not on in the DS1DSIND flag in the
  dscb to indicate data set was opened for other than input since
  last backup copy.  As a result, the CHG IND indicator in ISMF
  doesn't get turned on.  If the PDS is edited outside ISPF,
  DS1IND02 is updated correctly.
    CA-DISK (formerly known as DMS from Sterling Software) uses
  4 USERMODs to zap the OPEN SVC modules (IFG0194A, IGC0001I,
  IGGDADSM, IGC00020).  Their purpose is to not update the mod bit
  if the accessing module is a CA-DISK module.  The #2 USERMOD
  (hitting IGC0001I @ DFP level HDZ11F0) had a bug that resulted
  in the mod bit not getting updated for PDS datasets
  CA provided a corrected SVC zap which resolved the problem.
  ----------------------------------------------------------------
  #4
  ZERO BLOCKSIZE WRITTEN OUT TO DASD WHEN DISP=SHR OS/390 2.10
    In the first step, IEFBR14 is used to pre-allocate a dataset
  with only an lrec specified on the jcl.  In the second step,
  the data set is opened and closed.  The open causes the system
  to derive an optimum blocksize based on the provided lrecl.
  This data set is then passed to DFSORT.
    On OS/390 2.10, DFSORT processes the data ok and ends with
  CC=00 if the data set is accessed w/ disp=old in the 2nd step.
  If the data set is accessed with disp=shr, DFSORT ends w/ CC=16
  because the dscb blocksize written out is zero.
    On OS/390 2.6, DFSORT is able to process the data set
  regardless of the DISP being OLD or SHR.
    IFG0196W is the Open module which calls CVAF to write out the
  updated dscb.  CA had a bad zap to IFG0196W for their DMS
  product which NOPed out a LR 14,12 ( 18EC) at offset AC2 in
  module IFG0196W.  This caused the wrong values to be passed to
  CVAF and resulted in an incorrect FMT1 DSCB to be written out.
  CA provided fix DMS0002 .
  ----------------------------------------------------------------
  #5
  PSE FILES CREATED BY SYNCORT CANNOT BE READ BY QSAM OR BSAM
    BSAM / QSAM encounters io errors when reading multivolume
  physical sequential extended ( striped ) files created by
  Syncsort when the first volume has 1 extent (no secondaries)
  and the file spills onto a second volume with extents.
  SYNCSORT provided the following fix :
  ++APAR(SY53890).
  ++VER(Z038) FMID(BSSI037) PRE(TY20037).
  ++ZAP(QKXCIOI).
  ----------------------------------------------------------------
  #6
  JFCB to DSCB merge appears to not take place.  Job opens an
  existing data set for output, modifies the RECFM, BLKSIZE and
  LRECL.  The new values do not get written back to DASD.  When
  they open the data set later, the old values are still there.
  Cause of the problem was a bad zap to IFG0196W.  CA SAMS DISK
  has a hook in IFG0196W, the user somehow inadvertently modified
  the usermod so it was incorrect.  If using SAMS DISK, please
  ensure the usermod is installed and updated according to
  vendor specifications.                 jbo  01/11/30
  ----------------------------------------------------------------
  #7
  ABEND0C4 in IFGDEBCK+'242' because DEBT is overlaid with hex
  blanks.  DEBT was overlaid by ACF2 module ACF00ECL.  Customer
  found that the problem was caused by an incorrect installation
  procedure when upgrading to OS390 2.10
                                           jbo  01/07/02
  ----------------------------------------------------------------
  #8
  IEC155I 240-10 IGC0006D READING FILE
    ABEND240 RC10 is detected because the address of the jfcb
  provided via the type 07 jfcb exit is not valid.
  The issuer of the RDJFCB was from a program called JFCBINFO.
  The problem was resolved after reassembling user module
  JFCBINFO with OS/390 2.10 macros .
  ----------------------------------------------------------------
  #9
  ABEND0C4 in IFG0202L accessing TIOT entry that is above the
  line but IFG0202L is processing in 24bit mode.  Also issued was
  IEC999I IFGOTC0A,IFG0202L.
  Customer found that ACF2 fix #LO81983 -REL 6.3 MVS resolved the
  problem.  Description on coverletter:
  "  AN S0C4 ABEND MAY OCCUR IN MODULE IFG0198N+256 DURING
  DATASET OPEN. MODULE IFG019RA ISSUES A BASSM 14,15 TO ACF9E9TR
  (ACTING AS THE OPEN TRACE ROUTINE). ACF9E9TR RETURNS WITH BR 14
  INSTEAD OF BSM 0,14. IFG0198N EVENTUALLY TAKES THE ABEND TRYING
  TO REFERENCE A 31-BIT STORAGE LOCATION IN AMODE(24). "
  This is for acf/2 version 6.3.
  ----------------------------------------------------------------
  #10
  IEC999I Secloada IEC614I Rename failed diag code 0408012c
    IDCAMS ALTER NEWNAME of a non sms managed vsam ksds results in
    the base cluster being successfully renamed but the data and
    index components receive the following errors :
    IEC999I Secloada
    IEC614I Rename failed - rc 008,
    diagnostic information is (0408012c)
    A trap on the IEC999I message revealed an 0C4 in open module
    IFG0195V at offset x'4F0' which is in the middle of a LOAD
    instruction.  An inhouse usermod ++USERMOD(PS01608) which hit
  IFG0195V had a REP statement causing the branch to the invalid
  instruction.  Modifying the usermod REP statement from
  REP 0168 47F034EE to REP 0168 47F034EC fixed the problem.
  ---------------------------------------------------------------
  #11
    Abend0c1 in ISRSCAN upon return from an SVC37 when Endevor
  compile is running.  Endevor does SVC screening of SVC 37 and
  when it returns to the caller has changed RBOPSW and the
  registers.  Additional symptoms can be abend0c6 and abend0c4
  in ISRSCAN.
  Fixes are B3902C P002837 and O002659 from Endevor
  svb 04/09/02
  ----------------------------------------------------------------
  #12
  IMS DLI region shutting down goes into a loopwhen job
      re-issues CLOSE svc for PMO data set.
      Problem was caused by PMO hook inSVC screening,
      it was screening for PMO libraries being closed.
  Text of incident provided by CA :
      Fix will be created for the PMO 4.3 level for the SVC 20
      looping condition experienced by job VEN316A.
      In reviewing the dump, the DCB passed in the CLOSE SVC call
      is a DCB that was created by PMO.  In some circumstances
      where PMO is involved in processing a BLDL where we are not
      managing all the libraries in the concatenation, PMO will
      create a copy of the DCB and DEB (with a shortened length)
      and re-issue the BLDL.  The BLDL being issued by DFSRTM00
      is using the PMO DCB copy that is still on the DEB chain.
      Our BLDL front-end code establishes a FESTAE to clean up
      these DCB/DEB copies if an abend were to occur, but
      apparently DFSRTM00 is getting control and cleaning up
      any open DCBs before PMO's FESTAE does.  PMO's CLOSE SVC
      intercept contains code to zero out R15 and return to the
      caller when the DCB passed to CLOSE is identified as
      PMO's DCB copy (with the 'PMO?' at DCB-4).  This code in
      PMO's CLOSE intercept has existed since 1988 and was
      added to correct a possible S0C4 abend during CLOSE when
      the issuer's address space was cancelled.  A possible
      temporary circumvention may be to put any unmanaged
      libraries in job VEN316A under PMO's management to avoid
      PMO creating the DCB/DEB copies.
      Please contact CA for complete fix information.
  ----------------------------------------------------------------
  #13
  ABEND0C4 IFG0552B IFG019CA
    Logrec indicates the failing module name as IFG0552B but the
    0C4 is actually in CA-1 (TMS) module TMSOCEPR + 1FC4 .
    FAILING INSTRUCTION TEXT: 100CBFE7 E0159140 E00247E0
    The failing instruction is a TM 9140E002.  The storage in R14
    is NOT available.  Apply CA-1 (TMS) ptf QO12696 along with
    its superceding ptf QO15202 .
  ----------------------------------------------------------------
  #14
  Attempting to delete a PDSE data set, receive:
  IEC331I 042-006(043D57D3),CTS4075 ,DM100ATS,SCRT,IGG0CLH0
  IEC331I VOL,SMP103,NAME,PPI00000.L1.LMP.LOADLIB.SCR
  IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS
  (043D57D3),DM100ATS,SMP103,PPI00000.L1.LMP.LOADLIB.SCR
  Dataset was found to be under the management of QFETCH from
  Computer Associates.
  Symptom was resolved via fix QF25102 solution 152 release 2.5.
  JCB 05/16/2002
  ----------------------------------------------------------------
  #15
  Abend800 rsn1 after upgrading to z/OS (any release)
  abend800 rsn1 occurs due to an abend0c4 pic11 during recovery
  from an abend18a rsn35000301 attempting to do a PAGEFIX of the
  buffer address in a read data CCW.  The buffer length is
  x'1b58' and buffer address is 30045.  The abend occurs because
  the buffer spans a page and the second page is not gotten.
  The issuer of the BDAM read is V3TSKFIO +x'b1a'.
  Fix from Sterling (Vector Sort) is V3K30320.
  ----------------------------------------------------------------
  #16
  IEC149I ABEND 813-04 IFG0195H READING MULTIVOLUME TAPES
    Data set name in the HDR1 that gets passed to the DSNAME CHECK
  routine was being changed by the File Validation Exit from CA .
  When the modified HDR1 is checked against what really is in the
  tape label, the mismatch results in an abend813 rc04.
  The problem was caused by CA's FILEV exit.
  CA provided USERMOD T5XD273 .  QO39908 for CA release 5.2
  IEC149I 813-04 IFG0195H processing an ANSI label tape
    Open correctly translates the ascii hdr1 label to ebcidic
  but upon control back from the CA's file validation exit,
  one byte of the dsname was changed from a '40' to a '50' which
  resulted in the 813-04.  Problem is resolved by CA usermod
  P5XD268 against module TMS0CEPR.
  ----------------------------------------------------------------
  #17
  IEC512i LBL error is issued when an operator mounts the wrong
  tape for a specific mount request.  However the mounted tape
  is not rejected and is relabelled to the volser of the volume
  that is requested.  O/C/EOV trace shows that IFG019LA is
  returning rc04 indicating the exit may have turned off any
  anomaly conditions and the system should accept the tape that
  is mounted if the exit authorized destruction of the tape
  (TEPM+x'11 TEPAOKDES bit is on x'0f').  IFG019LA is owned by
  Zara.
  PTF T130A042 for Zara 1.3 resolved the problem.
  ----------------------------------------------------------------
  #18
  ABENDA0A RC18 DUE TO CLOSE BEING ISSUED WHILE ACTIVE I/O
   CLOSE is issued by application and a BDAM WRITE is issued while
   the DCB is in process of being closed.  Access Method Close
   executor module IGG0201Y gets called and an IOB is needed but
   still active from the BDAM WRITE request.  IGG0201Y issues the
   freemain because the DCB is being closed.  The FREEMAIN from
   IGG0201Y fails due to IOB still being pagefixed from the active
   BDAM WRITE request.  Problem was resolved by CA fix # QO19926 .
  ----------------------------------------------------------------
  #19
  MSGBPXF135E RC9D RSN5B200109 along with ABEND0F4 S0F4
  RC24 RSN5B0D0101 received when copying an HFS dataset
  via FDRABR oem utility.
  Resolved by specifying HFS=QUIESCE as input to FDRABR.
  ----------------------------------------------------------------
  #20
  IEC999I IFG0RR0A IFG0RR0E INIT WORK AREA dump title
    Failing instruction was a CLC D52B 1000 6000 within
  oem module with eyecatchers of VDSPRE00 VDSQSRCH VAMLVUT .
  CA provided ptfs QO15842 and QO17687 with a pre-req of
  maintenance level is SP5 for CA-Allocate product
  (formally known as VAM).
  ----------------------------------------------------------------
  #21
  Abend0b0-08 in IFG019RAwith CA product BrightStore
    An ABEND0B0 RC08 is received when using CA product
  called BrightStore to create new files on tape.
  The product is a Linux backup facility that uses TMS
  as a controlling database.  The 0B0 abend is received
  due to a zero SVA being passed to SWA manager from module
  IFG019RD.  The problem was caused by a CA parm being
  overlayed and was fixed by CA.  Please contact CA for
  details.          10/3/02
  ----------------------------------------------------------------
  #22
  Dumps generated with following dump title:
   TITLE=COMPID=DF104,CSECT=IGWMSMF +0000,DATE=04/16/00,
   MAINTID= NONE,ABND=0F8,C=00000000,RSN=00000014
  The ABEND0F8 RC14 is detected when a routine with EUT FRRs
  issues an SVC.  The SVC was issued by STK module
  EXPR/RTMUPRFU83 ( EXPR / RTMUPRFU83 ). Problems did not
  recur after the EXPR product was deleted from the system.
                  10/31/02
  ----------------------------------------------------------------
  #23
  abendd23 rsn10040002 in IGCT005C when attempting to do a read
  to an ADABAS BDAM dataset.  We should not even be in this code.
  ADABAS fix is AO712067.  12/05/02
  #24 SMFTYPE42 subtype21 records not cut when deleting PDS or
  PDSE member.  Problem is with PDSMAN option FASTSTOW=Y which
  bypasses the STOW.  Specify FASTSTOW=N in PDSMINIT.
  

Local fix

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