II08762: OEM BUGS IN DFP DATA MANAGEMENT - O/C/EOV, ACCESS METHODS, PDSE,LINKEDIT, BINDER (ALSO II07757 II07438 II08212 II08264 II09608)

APAR status

• Closed as canceled.

Error description

• See also II08212 II07438 II07757 II08264 II08762 II09608 II10937
  This info APAR lists known third-party (OEM) problems in DFP
  data management components: non-VSAM o/c/eov, sequential access
  methods, linkage editor, PDSE and HFS.  Where possible,
  OEM fix numbers are listed.  It is by no means a complete list.
  .
  DADSM - Abend0C4 in IGG029CM +x'274' & possibly others.
    STOPX37 Release 3.5.4 does not provide the support for MVS 5.1
  and 4 digit UCB address.  Please apply Release 3.5.5 of STOPX37.
                                                     MHM 06/26/95
  .
  Unable to allocate HFS data set using IEFBR14.
  Customer is installing OpenMVS and following the TASKS
  in ESA Planning: OpenEdition MVS, SC23-3015,
  and at Task 8: Allocating the HFS Data Set,
  get msgIGD17040I during IEFBR14 job allocating the HFS data set:
    IGD17040I ERROR IN DADSM PROCESSING FOR DATA SET dsn
              HISTORIC RETURN CODE IS 200
              DIAGNOSTIC INFORMATION IS 044D5AF8
  Reason code 5AF8 means an ABEND occurred during CDM processing
  and syslog contains ABEND019 with dump title:
    COMP=DF115,CSECT=IGWDACRD+0000,MAINTID=NONE,
    ABND=019,RC=00000000,RSN=00000000
  The DFSMS 1.2 program directory says RACF 2.1 is required
  for OpenEdition and Task 6: Preparing for Security, says you can
  use an equivalent security product to handle OpenMVS security.
  In this case, the security product is TopSecret version 4.4
  from Computer Associates and CA says they have addressed this
  problem in TopSecret version 5.0 (currently in "beta" test
  with no release date).
  Top Secret version 4.4 does NOT support DSNTYPE=HFS.
                                        MW - 6/26/95
  .
  Receive msgBPXF020I rcA2 rsn5B3D0107 or internal error
  from HFS Adapter mount rtn GFUDMONT just after starting OMVS.
  Then get ABENDEC6 with same RC and RSN.  Also get ABEND0C4 in
  GFUDMONT +112 but GPRs are not GFUDMONT's and after applying
  OW24111, fixed the 0C4 but msgBPXF020I still occurs. The 0C4
  was in OEM CA TopSecret security product rtn IRRSXT00 +D2
  (version 5). Computer Associates recommends FIX # GO92587.
  CA also recommends minimum maint for Top Secret Version 5
  with OpenEdition OMVS (HFS) is 9605.
                                        MW - 9/29/97
  .
  When a PDSE is the first data set in ISPPLIB
  concatenation and PDSE is opened from ISPF via TSO
  logon proc and one of the panel members in the
  same PDSE is displayed and then PF3 from panel member
  and exit from ISPF causes ABEND0F4 in IGWLHRLS
  with rsn13040405 because an invalid lock token was input.
  Also get ABEND0F4 in IGWBDSL1 with rsn070A0021.
  The 0F4 errors do not occur if PDSE panel member
  is not displayed.
  This problem is also described in DFSMS apar OW09491.
  After installing OEM Program Management Optimizer PMO
  fix number 101344 described in QJ42938 from Legent/CA,
  no 0F4 error(s) occur when PDSE is the first data set
  in ISPPLIB concatenation.
  The Legent/CA description in QJ42938 is:
   "This optional zap causes PMO to not process BLDL
    or FIND request for a concatenation where a PDSE
    is the first data set in the concatenation."
  Still get the same 0F4 error(s) with fix number 101344
  from Legent/CA when PDSE is NOT the first data set in
  ISPPLIB concatenation and currently there is no Legent/CA fix.
                                        MW - 6/27/95
  When PDSE load library is placed in the middle
  of STEPLIB concatenation and OEM PMO product is used, get BLDL
  error message msgIEC909I 212-0:
   IEC909I 212-0  ,JJJSTC  ,JJJSTC  ,SYSDCB,0000000C,0F045AA1
  ( rsn0F045AA1 )
  The PMO fix from Legent for this problem is described in QJ42058
                                        MW - 7/21/95
  .
  Binder return code was not saved correctly to ECB when it
  was ATTACHed. Legent's PDSMAN changed the return code. The
  PTF number of the fix is 104304.       LJY  07/05/95
  .
  TAPE WRITTEN IN WRONG DENSITY
    With hardware genned for OPT1600 and DEN=3 specified in JCL,
    data was still written in 6250 bpi instead of 1600 bpi.
    JFCB contained X'C3' at end of allocation and beginning of
    OPEN.  IFG0194A should have gotten control to move in the
    density but LEGENT's EPIC load module TSIDOIM got control
    instead.  LEGENT APAR # TZ32472.
                                    QP 07/10/95
  .
     Indexed VTOC's DIRF bit is being turned on.
  CA's product ROSCOE is turning on the dirf bit and not
  turning it off.  They have a zap for Release 5.7 and 6.0.
                                              MHM 07/13/95
  
  During Volume switch if the dataset is allocated in AVGREC,
  a loop may occur.  In determining the number of blocks that
  will fit in a track, the average block length was used instead
  of the maximum blocksize.  STOPX37 modified DSR0140 to correct
  the field.  The ZAPID is SX355P21 (although there may be others
  to correct another problem related to this).  Applicable to
  STOPX37 versions 3.5.5 and 3.5.6.              MHM 07/24/95
  .
  TITLE=IEC999I IFG0RR0A,........,$DREWA  ,DB2PC   ,WORKAREA = xxx
         IEC999I (MSGIEC999I) ABEND0C4 RC10 in module IFG0RR0A
       after installing DFSMS maintenance. The error occurs
       when OEM (Change Man) trys to use DB2 compiler.
         The problem was with an OEM tape management system
       called ZARA from ALTAI.  It occurred because ZARA copies
       O/C/EOV modules from LPA to MLPA.  MLPA was not refreshed
       following the apply of the maintenance.       SH (7/25/95)
                   ------------
  PDS and PDSE concatenation (in that order) can cause COBOL
  compile error msgIGYLI0050-U "An Input/Output error occurred
  while reading a library member". The problem occurs when PDSMAN
  intercepts a FIND ( SVC18 ) request from COBOL, and changes
  it to a BLDL request.  A fix from Legent is PTF 104870  for
  PDSMAN Releases 7.20-7.22                           LAP 8/11/95
          --------------------
  Collecting SMF type42 records even when NOTYPE parm is specified
  in member SMFPRMxx ?  If yes and product CA90 from Legent is
  installed, they have an apar # GO50392 with a zap for CAIMB838
  for fmid CS91000 .   (See also next 2 lines.)       LAP 08/11/95
     CA's GO44513 is in error and causes SMFtype42 (SMF42) to be
  generated again.  Fix is T5ZS317.                  RHK  10/21/97
  .
  Job receives the following messages:
  IECTMS3 05D8,123456,is not scrtch (32)
  IEC502E R 5D8,123456,SL,ACC3A19,STEP1
  This job completes normally.
  The next job accessing VOLSER 123456 gets:
  IEF690I FOLLOWING VOLUMES UNAVAILABLE TO JOB2 STEP1  123456.
  IEF235D JOB2 STEP1 WAITING FOR VOLUMES.  TO CANCEL WAIT OR REPLY
  This job is unable to allocate VOLSER 123456 because the
  previous job still holds the SYSZVOLS enqueue on 123456.
  CA1 TMS provided fix numbers GO67173/GO67179.  Please contact
  CA for the most current information.
  Additional keywords: ENQUEUE ENQ DEQUEUE DEQ SYSZVOLS
  MSGIEF690I MSGIEF235E MSGIECTMS3 MSGIEC502E    jbv 09/11/95
  .
  IEC537I IEC210I ABEND214 RC10 IFG0200Y BLOCKCOUNT MISMATCH
    Block count mismatch writing tape output with SYNCSORT which
    uses EXCP to maintain their own blockcount.  Tapemap showed
    that the blockcount matched the DEVICE count so problem was w/
    SYNCSORT.  Apar is PW47050.  Contact vendor for current fix.
                         QP 10/02/95
  .
  ABEND0C4 IFG0196V FOLLOWED BY ABEND922
    0C4 was actually in ACF9096V.  Fixes are GO76255 AND GO48851.
                      BL 10/02/95
  .
  ABEND0C1 0C1 IFG0202K +X'3E8' SETLOCK ERROR
    This intentional abend occurs because the SETLOCK OBTAIN for
    the local lock failed.  The lock was already being held as
    indicated by the bit setting for the lock in the PSACLHS
    field (x'01') of the program interrupt.  This problem only
    occurs w/ maintenance level of CA90 is 9504 and is resolved
    by CA ptf G074577 .
                       QP 10/06/95
  .
  ABEND0C7 IN IFG0194K
    During EOV multivolume tape processing with BLP, an 0C7 is
    received in module IFG0554K.  CA fix number is T1R3527.
                                    BL 10/18/95
           -----------------------
  When OEM SAS ( SAS Institute ) batch job reads
  all 28,000 PDSE members sequentially, the batch job gets
  msgIRA103I SQA/ESQA HAS EXPANDED INTO CSA/ECSA.
  The production system where msgIRA103I occurred
  has 39.0 meg of ECSA and 22.6 meg of ESQA.
  When SAS batch job was cancelled, Omegamon showed ECSA usage
  stopped growing.
  Logrec showed ABEND0F4 in PDSE  GETMAIN rtn IGWFVGTM with
  reason code rsn2504C002 that means "out of ECSA storage".
  Omegamon showed ESQA/ECSA storage areas contain IGW structures.
  This problem is described in DFP APAR OY63961:
    Two new DFP external function have been created to reduce
    the number of concurrent connections to PDSE members.
    These functions are BLDL Noconnect and STOW Disconnect.
    ISPF and other applications that implement these functions
    can reduce the number of concurrent member connections,
    and consequently reduce ECSA storage usage.
  The NOCONNECT option of BLDL specifies that each PDSE member
  is not to be connected.
  SAS technical support says SAS processing was not changed
  for PDSEs and PDSEs are accessed the same as PDS, therefore,
  SAS processing also needs to implement BLDL NOCONNECT
  to reduce CSA storage usage when using PDSEs.
  .
  SAS defect# D0047994 was created for this problem.
  ( SAS problem# 4441074 )
  SAS said the requested change will be included in the next SAS
  release (7.0) that will be available in about a year.
  The changes may be shipped sooner depending on the number
  of SAS users that need this PDSE support.
                                                    MW - 12/11/95
                    -------------------------
  .
  IEC130I dsn DD STATEMENT MISSING w/ DSN containing garbage data
    IDCAMS job to delete / define an alternate index receives
    IEC130I w/ garbage data or blanks for the dataset name during
    the rebuild of the index.  Also received CASO049E MESSAGE
    DATASET ERROR from CA and message IDC2658I SORT PRODUCT FAILED
    with condition code 12.  CA's CASORT provided fix GO72782.
                                    QP 01/11/96
  ---
  ABEND0C4 in ACF9C000 + x'588'. MSGIEC614I RC16 diag info
  081600C4 and MSGIEC216I ABENDA14-04 IFG0202E were issued.
  This is a CA problem described by incident TA2577C and fixed
  by G083718.                LJY 01/29/96
  ..
  ABEND613 RC20 IGD306I UNEXPECTED ERROR DURING CBXLCS PROCESSING
  when running MAXSORT (from SYNCSORT) using ATL D/T3495 or
  D/T3494) for intermediate output tapes.  The problem is caused
  by an invalid paramater list passed to SMS for the tape volume
  record update.  IFG019RF passes 2 volsers (previous and
  current)  because we think the data set is multivolume when it
  is not. The JFCBVOLCNT shows 0100. This is fixed by EW47920 for
  Syncsort rel 3.5 and rel3.6.
                                          JBV 2/14/96
  .
  ABEND513 RC04 IEC146I DISP = MOD MODing onto to TAPE
    Duplicate version of IFG0194A in LPA called ACF9394A by ACF2
    was getting control but problem was actually w/ tape
    management product CONTROLT by New Dimensions.  Fix # BT00760.
  
  .
  IEC999I IFG0202K ABEND0C4 & IEA705I SYSTEM ABEND378 RC1C or RC24
    After upgrading from MVS/ESA 4.3 to 5.2.2, 0C4 in IFG0202K and
    ABEND378-1C are received with apar OW15640 applied.  OW15648
    resolves the 0C4 in IFG0202K, but the 378-1C is resolved by
    CA's DATACOM VSAM TRANSPARENCY fix : DBVT rel 2.2 solution 101
    The problem involved the change in the length of the DEBX from
    x'4C' to x'54' bytes as described in apar OW11906.  CA's fix
    will set the DEBX length to the correct length for the
    corresponding MVS/ESA release.
  Repeated IEC501A IEC502E messages processing NL tapes
    After a scratch tape is mounted, written on, & dismounted,
  another job calls for another scratch mount, but the tape
  is immediately dismounted with the IEC502E message always
  containing the volser of the tape that had been previously
  created.  The msgs IEC501A, TMS002, IEC502E are repeated
  and the same volser appears in the dismount messages even
  though different NL scratch tapes are actually mounted.
  CA's WTO ' IECTMS1 enter vsn ' message is also not issued as
  expected.  The problem was resolved with CA ptf GO85435 .
                                    QP 05/09/96
  .
  IEC999I IFG0RR0A ABEND0C4 IFG0196W
    ABEND0C4 was actually occurring in Top Secret module TSSFSB
    and was resolved by CA's Top Secret apar BC63501.
                                          qp 96/05/14
  ...
  ABEND0C4 in IEBPTPCH failing on 'bad' address in reg15,
  '00404040' when trying to go to the POINT/CONTROL routine for a
  LAM subsystem data set.  This address is obtained from the
  DCB+'54'. The incorrect value is loaded from LAM's (CA Library
  Manager) replacement of IGG019DK.  This has only failed when
  running DFSMS 130 with uw90232 applied and using
  CA1-Librarrian. CA Fix is GO-97070. ...
  .
  ABEND613 RC0C IEC147I with IEBGENER when creating multiple
    files on tape using volref.  Problem was caused by bad
    TLMS hook L2 in module IFG0196N for TLMS version 5.3
  .
  IEC028I ABEND837 RC08 EXTEND TO SCRATCH VOL AFTER OPEN INOUT
    The problem was caused by IFG0551F not passing control to
    IFG0552B to process the tape for output, because the eov
    tape output module id ( EOVOUTID ) in the workarea was
    not set up with IFG0552B, but instead contained IFG019CA,
    a CA module. CA provided the following usermods which resolved
    the problem:  T1R1372 T1R1374 with USERMOD Prereqs T1R1362
    T5XD564 T5XD531 and GO81049 in addition to the 9506 level
    maintenance tape for CA-1 .  A final apar was not yet
    available.
                                    QP 06/20/96
  .
  ABEND0C4 branching to low core after CLOSE IFG0200Z is
  given control back after SVC0. IFG0200Z is trying to pass
  control to IFG020CA but CA was not properly initialized so we
  branch to low core.  The external symptom was ABEND0C4 in
  ARCBUDS after HSM issued CLOSE from ARCTCLOS.
  CA fixes are G084734 and prereq G084698.  Contact CA for
  confirmation of fix numbers.            JBV 06/27/96
  .
  ABEND0C4 IFG0196T
    Job that backs up an oem database to tape receives an ABEND0C4
    with IEA995I No active module found IFG0196T, after the tape
    mount request is issued. The abend was actually in ACF2 module
    ACF9C000 and was resolved by ACF2 APARS GO79545 and GO83718 .
                                         QP 07/03/96
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• close for Internet viewing
  

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