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

APAR status

• INTRAN

Error description

• 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, CMM.  Where possible, OEM fix
  numbers are listed.  It is by no means a complete list.
  .
  ABEND0F4 RC24 RSN13030401
  CONTROL-M from 4th DIMENSION SOFWARE vendor
  OEM ( CONTROL-M V400 ) fix : BI0492 fixed the abend0F4
  and also corrected ABEND0c4 pc11 in IEFJRASP. The
  problem was an overlayed affinity number in HL3B PDSE
  latch causing a compare failure and abend0F4.
  DW 03/26/98 ....
  .
  Abend 213 RC3C ABEND213
   When using a PDSE for program object output of assembler H.
   Product is PDSMAN from Legent, who provided formal fix. The
   fix number is #712-64.      12/27/93  (fix # added 3/21/94)
  .
  Incorrout reading PDSE
   When running ESA 430 and using PDSEs as SYSIN input for a
   SAS jobstream, SAS does not read in any data as input.
   Fix number is #7095.  12/8/93
  .
  MSGIEF238D Allocation Recovery RC0220 RC220 DARC220 for volume
   serial volser @ZSAM@ due to bad install of Sterling's SHRINK
  .
  MSGIEW2005S ABEND0C4 RC16 83FF0C40
   Attempts to bind a large overlay program receives ABEND0C4.
   If the program is linked using the linkage editor, the program
   links without error.  The problem was with how CA's LAM
   librarian manages the datasets.  If the librarian is removed,
   the loadmod is created w/o error.  CA fix GO13414 12/8/93
  .
  MSGAMB114I CSECT name associated with an IDR entry cannot be
   found.  The customer had a library that he copies using IEBCOPY
   COPYMOD. OEM product Endeavor puts a footprint into the member.
   After the member is copied and an AMBLIST is run, MSGAMB114I is
   received.  If AMBLIST is run against the member before the
   COPYMOD, the job runs fine.  Contact Endeavor for fix.  12/8/93
  .
  MSGIEW4005 ABEND106 RC0E RSN28
   The problem was with Legent's HYBERBUF product.  PTF number is
   64700.  a MSGICE039A may also be received.  12/8/93
  .
  DFSMS R110 ABEND106 RC28 MSGIEW4005I RC0E & RSN 20 or
  DFP ABEND106 RC0E RC20 RSN20
   Problem with PDSMAN fixed by the following Legent fixes:
   54862 ID 7.11-04      63676 ID 7.12-43  65700 ID 7.12-74
   Version 7.13 has the fix in it.
   *** NOTE: 7.12-43 does not relate to SMS 1.1 problem
  .
  MSGIEC507D on temporary datasets
   IEC507D was received on temp datasets even though no expiration
   date was specified.  The problem was with some incorrectly set
   parameters to the Pooldasd product (Empact Software) that
   allowed it to modify the JCL and set RETPD=0 on temporary file
   allocations.  The customer reset his parameters, and the
   problem was resolved.  12/8/93
  .
  ABEND315 IEFQB551
   Module IGG021AB was passing a bad SVA to SWAREQ.  Problem was
   with PDSMAN (who frontends BLDL and STOW).  Fix # 22342. 12/8/9
  .
  D/T3480 or D/T3490 POD display has the word DISASTER
   POD displays DISASTER instead of the volser.  Problem caused by
   CA1 Rel 5.0 w/ ESA 4.3. Fix # PID GI13563 and PUT 9308. 12/8/93
  .
  MSGIEC999I IFG0196V
   ABEND0C4 actually occurred in a CA-ACF2 module ACF8EVA0 +x'4F2'
   when opening a VTAM ACB.  Their fix number is CO94401.  11/5/93
  .
  MSGIEC512I LABEL ERROR (LBL ERR)
   After 9302 maintenance, SL tape could not be changed to NL and
   and repeatedly received MSGIEC704A followed by MSGIEC512I LBL
   ERR until job was cancelled. The problem was w/ CA's TLMS hooks
   in the NL processing code in IFG0194K and the wrong usermod
   (H9304B2) was provided.  Correct usermod is H93A4B2.  11/5/93
  .
  ABENDE00 ABEND073 ABEND0C4
   ABENDE00 (an ABEND0C4 occurred while processing i/o) followed
   by ABEND073 RSN28 in IOSVSSCQ (indicates that the requester
   CMF wanted a lock he didn't have authority)  Previous abends
   were a result of an ABEND0C4 in CX10HMOV (CMF module by Boole
   and Babbage).  Problem is more prevalent in multiprocessor
   environments and fixed by service level BPM4414.  11/5/93
  .
  ABEND0C4 IGG019CW
   Abend was occurring at +x'262' into IGG019CW at UY78128 on
   instruction 92035000.  Reg5 is bad.  The problem was with
   CA-OPTIMIZER module CAOCDYNA which was altering the ICB chain
   pointer incorrectly.  Fixes: APAR GO14200, PTF GA14200 11/5/93
  .
  ABEND0C6 IFG0194K
   Abend was occurring at +x'DC2' (UY94834) attempting execute
   '3F7E' which is in the middle of instruction 'D505 41FA 3F7E'.
   TLMS had a bad zap.  The bad zap/usermod was H93A5F2. 10/14/93
  .
  ABEND0C4 PIC11 IGC00020
   Abend was occurring at +x'1F2' on instruction 9122B008 when
   accessing the DEB.  The parameter list passed to CLOSE did not
   have the last entry indicator bit on which caused CLOSE to
   process an eyecatcher as a DCB. The program that passed the
   plist was XMTCFRET, part of the KNET/TCIP product from GULF
   COMPUTERS (formerly Spartacus). 2-byte zap given. 10/14/93
  .
  No wait for reply to MSGIEC704A
   The WTOR for MSGIEC704A is issued, but the job does not wait
   for the reply to the message and continues processing.  Problem
   started occurring after going to MVS 4.3.  The problem was with
   CA-TMS.  Fixes are: GO13786, GO13787, and GO13788.  10/14/93
  .
  Wait in IGG019AR +x'52'
   The wait was occurring compiling COBOL programs with the CA
   OPTIMIZER product.  CA indicated that when the pds they are
   trying to write to gets full, then the optimizer will go into
   a wait state until it is cancelled.  Compressing the pds
   bypasses the problem.  No fix number given. 9/13/93
  .
  ABEND0C4 IGG020FC MSGIEC999I
   ABEND0C4 was actually occurring in a Shrink (Sterling software)
   module called VPE.  The problem had to do with Shrink's
   interfacing with Legent's Express Delivery product (an RMDS-
   like product which frontends SVC26).  Shrink was overlaying
   reg14 in its SVC intercept routine.  The bypass is to have
   Shrink install its hooks before Express Delivery does.
   The long-term resolution is to upgrade to release 463 (R463) or
   higher of Shrink.  9/13/93  updated R463 info 1/12/94
  .
  MSGIEC537I ABEND237 RC0C MSGIEC023I or MSGIEC210I ABEND214 RC10
   The blockcount mismatch was showing a large discrepancy between
   the device and dcb counts with the device count always being
   much less.  It turns out that one system was causing the tape
   to rewind while another was outputting to it.  MIM was being
   used for cross-system serialization.  The problem was that the
   HCD definition of the tape drives was as dynamic devices which
   MIM does not recognize and therefore does not manage them.
   Legent recommends that the devices be defined as static until a
   newer software level w/ dynamic support becomes avail. 9/13/93
  .
  MSGCSV011I ABEND106 RC0F RSN40
   The problem was caused by a CA product call LOOK that was
   intercepting the directory information and passing it back to
   the LOAD SVC.  Fix number is GA02608.  8/9/93
  .
  FMT1 +x'4E': Products previously known to update this byte:
   1) DMS/OS - Sterling
   2) ABR    - Innovation
   3) UCC3   - CA
   4) ASM2   - CA 8/9/93
      ASM2   - CA 2/22/94
      Reported incorrout in FMT1 DSCB.  An
      IEHLIST LISTVTOC generates incorrout in
      the Volume Serial# field for non-SMS
      PS dataset.
  .
  CVAF RC04 or MSGIDC3009I RC168 RSN02 IGG0CLEP
   A customer was getting an RC04 VTOC ERROR on return from
   SVC139 using ISPF 3.4 to specifically list datasets on a
   certain volume.  It turns out the volser was placed in a
   DUMYVOLS list by POOLDASD (Empact Software) causing it to
   be unavailable. No fix number given.  8/9/93
  .
  MSGARC0200I Recycle or autobackup hangs on tape mount
   The problem occurred when using DFHSM and when their type '18'
   volume security and verification DCB exit was not being called
   by IFG0552B.  Symptoms similar to OY54493.  Bypassing of the
   exit was caused by a CA-1 (also TLMS) hook at one of the two
   branches which call the exit.  This branch was only being
   invoked when a 3490 Format Incompatible tape was mounted.
   CA recommends installing PTF for OY57794 (which hits IFG0552B)
   with their corresponding zaps for this level.  8/9/93
  .
  ABEND30A RC14 MSGIEA705I w/ IEBGENER to copy GDG files to DASD
   Problem was caused by a CA-TMS APAR that caused IGG0191C to
   getmain storage in key0.  When CA fix T1R1291 was removed, the
   problem went away.          7/20/93
  .
  MSGIEC023I ABEND237 RC0C
   The blockcount mismatch was occurring on STK d/t3480 that were
   shared across systems.  The problem was with STK microcode on
   the 4480 mod20 controllers.  The microcode fix # was Version 1
   LEVEL X.9.4 w/ X indicating the controller model 1 or 2. 5/7/93
  .
  Double MSGIEC704A
   Duplicate IEC704A messages were received w/ VOLID facility to
   rewrite 36-track tapes in 18-track format.  The first IEC704A
   did not allow a reply & scrolled off the console.  Problem was
   w/ CA-TMS WTO interface. DFSMS/MVS 110, fix # T1R1292.  5/7/93
  .
  ABEND0C4 IGC00020
   An ABEND0C4 occurred in IGC00020 at +x'CC' when accessing the
   DDname in the DCB.  The DCB had been freed prior to CLOSE
   getting control.  Contact Syncsort for fix EW4196-0 Rel3.5
   prior to the 3.5D/TPF3 level only.
  .
  ABEND637 RC54 MSGIEC026I IEC026I or ABEND613 RC1C MSGIEC147I
   At R110, ABEND637-54 received when going to multiple tape
   volumes along w/ MSGIEE763I CBRLLACS CODE = 180183,
   MSGCBR4000I LACS MOUNT FAILURE,  MSGCBR4131I WTO FAILURE.
   Problem was with CA-TMS's WTO interface.  Fix # T5XD336.
   4/26/93.  At R1B0, ABEND613-1C w/ same messages was fixed
   by going from 9203 - 9406 CA-TMS maintenance.  10/27/95
   maintenance resolved the problem.         10/27/95
  .
  ABEND0C4 IFG0RR0A
   Abend was in module TSSFSB (Top Secret security product) at
   +x'36C' on instruction 50C070E0.  Fix number is 1561.  3/31/93
  .
  MSGIEC999I ABEND0C4 indicating IFG0200Y
   Abending PSW actually points to a CA module called TMSDATE.
   The fix number is CO57076.  3/29/93
  .
  ABEND0C4 in IGC00020 at +x'6A2' closing a VTAM dataset
   Reg15 contained 55555555 which was supposed to be the user DCB
   address.  The product causing the problem was TEMPUS.
   No fix number available.  3/29/93
  .
  Incorrout: FMT1 created even though not enough space on volume.
   A dataset gets allocated even though there was not enough space
   on the volume, but the FMT1 DSCB shows no allocated tracks.
   The problem was caused by STOPX37 by Empact Software which was
   working as designed but could be stopped from intercepting this
   situation by adding a "jobtype tsu statement". 3/3/93
  .
  ABEND0C4 IFG0552B +x'3A2' at UY86466
   The problem occurred when running DFSMS/MVS 1.1.  It was caused
   by a Computer Associates TMS usermod at level TC96005 and was
   resolved by "level 99, Delta name TMD99535".  3/3/93
  .
  ABENDF82 ABENDD23
   A Racheck macro was issued from Top Secret module TSSFR00
   followed by an SVC35 issued from TSSKSEC.  The parameter list
   for the SVC35 was overlaid with "TSS/VCO LIBRARY LOCATE ERROR".
   The problem is fixed by Top Secret fix # 1901.  2/2/93
  .
  MSGIEC030I ABENDB37 RC04 IFG0554T on SMS multivolume dataset
   An SMS-managed dataset was not extending to a second volume and
   instead got the B37-04.  A trace showed that IFG0554P did not
   call SMS to update the volsers in the JFCB.  The problem is
   fixed by STOPX37 (Empact Software) fix # X3700406.  2/2/93
  .
  ABEND0C1 when EOV returns to caller
   See OY55056 and OY48457.  When using Legent's TPX product,
   an ABEND0C1 occurred when EOV returned to the caller using the
   wrong set of registers.  TPX's SYNAD routine was incorrectly
   issuing a CHECK macro.  Fixes are: for TPX 3.0: TM30545 on
   tape TM93011.  For TPX 3.5: TM35066 w/ base release.  1/15/93
  .
  MSGIEC141I ABEND013 RC64
   Abend occurred on a sortwork concatenation w/ a DUMMY DD card.
   The problem was that a DUMMY DD was accessed using EXCP.
   Contact Syncsort concerning EW3938 for Rel 3.4 only.  1/15/93
  .
  ABEND0C4 in ACF9CDEF due to 31-bit ACEE address
    Fix TA1175a
  .
  MSGISPG095 - 'INCONSISTENT BLOCKSIZES, FIRST LIBRARY MUST
   HAVE THE LARGEST BLOCKSIZE.' for CBIPO dialogs
   Message caused by PDSMAN, no fix number known for PDSMAN.
   Using IEBCOPY will fix problem.
  .
  NOT GETTING SYSTEM SPECIFIC ALIASES on CBIPO job
   Caused by PDSMAN.  Use IEBCOPY
  .
  During SMP/E APPLY, customer received PDSMAN messages:
   FCO767W - XXXXXXX updated but not alias, YYYYY not in output
             member
   FCO769W - YYYYY will have no owning member
   PDSMAN updated the ALIAS and not the MEMBER, causing the ALIAS
   to be orphaned from the MEMBER even though the library claimed
   it had an alias.  IEBCOPY does not recognize aliases and is
   working as designed. Other messages: MSGGIM40901E, MSGGIM40901S
   Fixes:  711-38, 712-31, and 712-41(end entry)
  .
  MSGIEC070I RC34 RSN204 (RC204)- STOPX37 ptf X3734P29  (end)
  .
  ABEND378 RC24 IFG0202K
   Following a DEBCHK (SVC x'75'), an application program issues
   a close and attempts to freemain an invalid length of storage.
   The deb prefix does not contain the address of the deb
   extension.  CA VSAM transparency product fix is GO22213.
   (additional symptoms)
   ABEND0F4 with invalid DSSB reason code rsn5A010008
   occurred in CMM close rtn IGWMDSST +'B40' ( UW18625 R1B0 )
   because the input DSSB pointer at 009A3D90
   does not begin with "IGWDSSB".  The DSSB pool resides
   in ELSQA subpool 215 SP215 .  Address 009A3D90 is not in ELSQA.
   The DSSB pointer points to a TCB for the same job that 0F4'd
   and last RBINTCOD ='0075' ( DEBCHK ).  The 1st 0F4 in IGWMDSST
   occurred at 05:35:53 and logrec indicates the same job received
   an ABEND0C4 in IFG0202K at 05:36:20 when IFG0202K removes
   the DEB from the DEB chain during CLOSE.  The batch job that
   failed is using CA's VSAM transparency product.
                                                     MW - 11/16/95
  

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