APAR status
Closed as canceled.
Error description
**************************************************************** COMPID 568540801 569517611 565515800 PREV=II04954 NEXT=II12561 **************************************************************** ******************** JANUARY 10, 2002 ************************* RETAIN INFORMATION ITEMS WILL NO LONGER BE USED TO DOCUMENT COMMON USER ERROR INFORMATION. THE NEW PROCESS WILL RELAY THIS INFORMATION VIA THE SUPPORT PAGE WITHIN THE IMS HOME WEBSITE AT "HTTP://WWW.IBM.COM/IMS" CLICK ON THE "SUPPORT" KEYWORD IN THE LEFT MENU AREA. *************************************************************** THIS APAR IS BEING CREATED TO ASSIST LVL1/LVL2 AND CUSTOMERS IN DIAGNOSING CUSTOMER PROBLEMS, WITHIN IMS, THAT ARE NOT APARABLE PROBLEMS SUCH AS USER ERRORS. THE GOAL IS THAT ANYONE WORKING ON ONE OF THESE COMMON PROBLEMS WILL NOT HAVE TO 'RE-INVENT THE WHEEL'. THERE IS A SIMILAR APAR FOR THE IMS SUB-COMPONENTS, (DC, DATA BASE, ETC.). ALL PROBLEM DESCRIPTIONS SHOULD BE AS BRIEF AS POSSIBLE. ALL PROBLEMS SHOULD BE NUMBERED AND SHOULD LIST THE APPLICABLE RELEASE LEVELS, REQUIRED MAINTENANCE, AND KNOWN RESOLUTION. additional keywords: infoapar db dbinfoapar infoapardb -------------- PROBLEM INDEX -------------------------------- 1.IMS STATUSAI, no MSGDFS0730I - B&B IMF 3.2 installed PG. E 1 2.STATUSAO, MULTIVOLUME OSAM DATA SET - OK IN BATCH PG. E 2 3.Hang on HSM migrated dataset during allocation/open PG. E 3 4.MSGCAS0076E RECORD LENGTH UNDERFLOW from DFSURG10 PG. E 3 5.MSGDFS0921I doing ACBGEN PG. E 4 6.RSR TRACKING ABENDU0380 RC01 INVALID AWE FUNCTION PG. E 5 7.CHANGES TO GSAM DB RECOVERY AFTER B37 ERRORS PG. E 6 8.BMC PCP HISAM Logical Parent counter verses Logical PG. E 8 Child count do not match after deletes performed. 9.DLI abend0c4 or abend806 after abend737-04 and PG. E 9 abend314-04. 10.DLI abend0c4 after MSGIEC027I, abend737, MSGIEC0211I,PG. E11 abend314, MSGDFS0730 A,10,99, abendu0254. 11.Various errors using SMS function RLS for VSAM PG. E14 12.Status$1/$1 Status Code PG. E18 13.E2D9100C on restart of GSAM on V6 using V5 log PG. E16 14.MSGDFS0730I O,A8 after /ERE OVERRIDE PG. E16 15.ABEND0DB Seq. Buffering and OSAM CF DATA CACHING PG. E18 16.ABEND878 DLI and DFS0730I O,88 from BMP(s) PG. E18 17.DLS address space abends16e RC10 when BMP allocates databases. PG. E19 18.IEW2456E 9207 SYMBOL DFSNNCC UNRESOLVED. PG. E20 19.Abend0C6 DFSECP20 label EC2XCINV R15='FFFFFFFF' PG. E21 20.Getting DFS3389I, DFS039I RC16-80,then abendu0039 PG. E23 21.Archive getting IEF861I, IEF863I, & IEF099I PG. E24 22.Concurrent Batch Backout jobs PG. E28 23.IMS not support PDS Extented (PDSE) formtted datasets PG. E29 24.Read-only DBCTL DL/I region ABENDU0080 R2=A1500001 PG. E30 25.MSGDFS0730I V,18 & MSGIEC070I 211-212 PG. E31 XX.FUTURE UPDATES WILL BE MADE WITHIN THE IBM SUPPORT WEBSITE AT "WWW.IBM.COM/IMS". THE SUPPORT OPTION IS ON THE LEFT MENU. (January 10, 2002) -----------END- PROBLEM INDEX --------------------------------
Local fix
Problem summary
=====================UPDATE BY KEN FRIESEN============06/01/98= 1.IMS applications get error STATUSAI/AI STATUS CODE when allocating an OSAM Database. There are no MSGDFS730I or any MVS allocation error messages. The problem has been reported under IMS Full Function, CICS/DBCTL, and in IMS BMPs. Verify IMF presence by checking SCDMNTR0 pointing to IMF IMEMNTRn instead of DFSMNTR0. Also, in the savearea flow B&B IMF module has been identified, IMEOPCLn, where n=7 for IMS 4.1 n=8 for IMS 5.1 and n=9 for IMS 6.1. The resolution is to contact B&B IMF support and request fix BPI7322 to resolve this error in IMF 3.2. =====================UPDATE BY KEN FRIESEN============06/01/98= 2. CANNOT ACCESS SOME OSAM SETS ONLINE. GET AO STATUS CODE/STATUSAO. WE CAN HOWEVER ACCESS THESE DATA SETS FROM BATCH. A CHECK OF THE DCB SHOWED BIT DCBDUMMY ON IN DCBIND0, WHICH USUALLY INDICATES A DD DUMMY DATA SET, THIS WAS NOT THE CASE FOR THIS PROBLEM. THE ALLOCATION MESSAGE IEF237I IS PRESENT FOR ALL THE VOLUMES EXCEPT THE FIRST. HOWEVER, THE IEF285I MESSAGE IS PRESENT FOR ALL VOLUMES OF THE DATASET. THIS PROBLEM IS CORRECTED BY OW22321. =====================UPDATE BY Rick Crandall==========07/22/98= 3.Hang during allocation and/or open on HSM migrated DB. MsgDFS2495I was issued, but no MSGDFS2478I is recieved. One possible module flow is: DFSSMIC0 >> DFSSMSC0 >> DFSDBLM0 >> DFSDBAU0 >> DFSGDSNM >> DFSMDA10 >> DFSISERW. Caused by error in DFSHSM, fixed by APAR OW31892. ================== Added by Ken Friesen 03/26/98============= 4.In the SORT portion of Prefix Resolution DFSURG10 fails with RC=16 and produces MSGCAS0076E RECORD LENGTH UNDERFLOW. The cause of this problem is the use of an OEM Sort which has a system default of NO RECORD PADDING for variable blocked records. The underflow occurs because the X'10' record is shorter than the sort field length specified in the SORT FIELDS= parameter. To correct this you can either change the NO PADDING default in the sort or eliminate the DFSURG10 step in the reorg process and run the sort as stand-alone. Use the SORT FIELDS= statement from the SYSPRINT of the failing DFSURG10 step. After running Sort as stand-alone, you can continue with the rest of the IMS utility steps. =========================ADD 09/29/1998 By Ken Friesen ======= 5.MSGDFS0921I doing ACBGEN. RESLIB is managed by OEM product QUICK FETCH. Removing QUICK FETCH control of RESLIB resolved this problem. additional messages DFS0921I or MSGDFS0921I, . DFS0587I or MSGDFS0587I. Quick Fetch (QFETCH) is also know to cause an ABEND0C4 (S0C4) in ACBGEN utility module DFSDLBL0 or DFSDBL00 because R2 is bad. QFETCH should be disabled for the PSBLIB, DBDLIB and ACBLIB data sets. Also see MVS INFOAPAR II11171 for an error caused by modul es starting with PM. =====================UPDATE BY KEN FRIESEN============10/04/98= 6.RSR TRACKING IMS FAILED WITH ABENDU0380 RC01 (INVALID AWE FUNCTION CODE) IN DFSLRARP. FUNCTION X'0067' AWLGFRID (INVALID DS DETECTED BY RDR). AFTER TRK IMS HAD ALLOCATED A TRK-SLDS, THE CUSTOMER DELETED THIS DATA SET WHILE STILL ALLOCATED. AT THE TIME TRK IMS HAD NOT CLOSED AND EOF HAD NOT BEEN WRITTEN FOR THE TRK-SLDS. THUS, UNUSED SPACE WAS RELEASED. THIS IS A USER ERROR AND A CHECK SHOULD DONE TO DETERMINE WHAT HAPPENED TO THE TRK-SLDS. =====================UPDATE BY KEN FRIESEN============10/04/98= 7.CHANGES TO GSAM DB RECOVERY PROCESS WHEN ABENDSB37 (SB37) OCCURS ON A MULTI-VOLUME GSAM DATA SET. A LOOP HOLE WAS CLOSED IN DFSMS VIA MAINNTENANCE OW26283. THIS UPDATE DOCUMENTS CHANGES TO DOC APARS PN60290 AND PN74302. DURING THE RECOVERY PROCESS OF AN ABENDB37 ON A GSAM DB. WHEN CHANGING THE RECFM BACK TO ITS ORIGINAL VALUE THE FOLLOWING MSGIEB317I RC12 IS RECEIVED WHEN SYSUT1 DD DUMMY IS CODED IN AN IEBGENER JOB. ADDITIONS TO DOC APAR PN60290 ITEM #2: MSGIEB317I RC12 CAN BE IGNORED. THE RECFM WAS CHANGED TO THE VALUE SPECIFIED IN RECFM= PARAMETER ON THE SYSUT1 DD. THE UPDATE TO PN74302 IS TO ALSO REFERENCE II11174 FOR ADDITIONAL INFORMATION. =====================UPDATE BY KEN FRIESEN============11/23/98= 8.BMC Pointer Check Plus (PCP), version 3.3.01 maintenance level 2/27/98. Has a documented HISAM restriction. In the PCP manual on page 1-12 as the program can analyze a HISAM database accurately ONLY if no delete activity has occurred since the database was loaded because IMS does not flag for deletion all the dependent segments of a deleted segment and PCP does not process a database in hierarchical sequenctial order. If PCP is run after deletes have been performed then the logical parent counter for the logical children and the number of actual logical children do not match leading one to think thereis an error. =======================Add by Ken Friesen ==========11/24/98== 9-This is a problem with B&B STOP-X37, also known as PROSMS,in open/close/eov for OSAM DBs. The DLI address space failures can be an abend0c4 or an abend806. Ths customer should contact B&B (soon to be BMC) for a resolution. The messages in the job log look like this (message have been truncated): IEC027I 737-04,IFG0554P,IMSTDLS,IMSTDLS,DXPBFP00,0C52,IPLBBB,XPIM2.DXPBF IEC211I 314-04,IFG0200V,IMSTDLS,IMSTDLS,DXPBFP00,0C52,IPLBBB,XPIM2.DXPBF CSV003I REQUESTED MODULE IGG019.. NOT FOUND CSV028I ABEND806-04 JOBNAME=IMSTDLS STEPNAME=IMSTDLS DFS629I IMS DLI TCB ABEND - SYS 806 IMST DFS629I PSW AT ERROR = 070C1000 8120ABDE IMST DFS629I MODID = UNKNOWN EPA = UNKNOWN IMST DFS629I R0-3 00001C00 84806000 00FD3A40 00000010 IMST DFS629I R4-7 000000FF 008FFB18 00000004 0000000C IMST (aben806, abend314, abend737, abend0c4, IEC027I, MSGIEC027I, IEC211I, MSGIEC211I). Addition symptoms: MSGDFS0842I, DFS0842I, abendu0844, u844, u0844, abendu0845, u845, u0845. RSN5, RSN05. After the IEC027I-abend737 & IEC211I-abend314 you see in syslog: DFS0842I OSAM DATA SET CANNOT BE EXTENDED, REASON=5, DBDNAME= Reason code 5 says: LCREAT30 An attempt to get another extent for the data set via the OSAM end-of-volume routine failed. The data set could not be enlarged and another extent could not be allocated. When contacting Boole + Babbage request zap for (PTF PR352PG8) Additional B&B fixes identified PR352PHF and PR351PCA (if not then try PR352PCA). ======================Added by Ken Friesen==========11/24/98== 10. The incorrect allocation of an OSAM database can cause the following symtpoms during OPEN/CLOSE/EOV processing: IEC027I 737-04,IFG0194D,IDS0XC07,IMS,PXC07P00,06D1,DB6I14,DB.P.S0.PXC07P IEC211I 314-04,IFG0200V,IDS0XC07,IMS,PXC07P00,06D1,DB6I14,DB.P.S0.PXC07P DFS0695I OSAM OPEN INTERCEPT,ABEND=314-04,DDN=PXC07P00 +DFS0730I UNABLE TO OPEN DATA SET WITH DDNAME PXC07P00 FOR REAS A,10,99 DATA +DFS629I IMS BATCH REGION ABEND- IMS 0254 IMS0 When the OSAM access method opens a multi-volume dataset for update processing, it will gather all of the extents for the data set by issuing an internal EOV call and then issue an OBTAIN to get the datasets extent value on each volume. This problem is caused because there has been no physical space allocated on volume xxxxxx although there is catalog/jcl entries for the volumes. The recommended method for pre-allocating OSAM Multi-volume datasets can be found in the IMS Database Administration Guide Chapter 12, under... Allocating OSAM datase (abend0c4, abend314, abend737, abendu0254, MSGDFS0730I,DFS0730I, rca rsn10, A,10,99) ======= Update by Rick Crandall 4/1/1999 =================== 11.IMS current versions (V5,V6) do -not- support SMS function RLS for VSAM. If a VSAM dataset in use by IMS is also opened by a non-IMS user as an RLS dataset, then various errors can result. (CICS users may make thiserror from our experience). Errors include:ABEND0C4 in IDAVRR10 due to mismatched keys while SMF records are being processed. ======= Update by Rod Murchison 5/21/1999 =================== 12. STATUS$1/$1 STATUS CODE. A "$1" status code is returned by a Sterling product called Vision 80 when it detects that a DB refeernced by a PCB cannot be found. ======= Update by Rick Crandall 6/17/1999 =================== 13. AbendU0102 E2D9100C on restart of GSAM on V6 using V5 log. This is due to the change in the header length for UTC times. The change causes offsets to the PCB to become invalid. Restart of abended transactions across versions is not supported. The recommended method is to quiesce IMS activity prior to bringing up IMS on the new release. ======= Update by Rod Murchison 6/09/1999 =================== 14. MSGDFS0730I O,A8 and MSGIEC161I are received after restart of IMS using /ERE OVERRIDE. When the IMS CTL region fails on ABEND878, ABEND40D, or terminates at EOM, the IMS ESTAE may not be able to get control and notify the DBRC and DLISAS regions that the CTL has failed. If this happens, the DLI and DBRC regions will remain active when CTL goes down. The DLI region will retain the allocation of the databases leading to the DFS0730I message. The 'left over' DBRC and DLISAS regions should be terminated. ==================== Added by Ken Friesen ====== 07/07/1999=== 15.When using Sequential Buffering (SB) and the Coupling Facility (CF) for OSAM Data Caching, a restriction exists that the OSAM DB block size definition must be a multiple of 256 bytes (decimal). Failing to do so can result in ABEND0DB (S0DB, ABENDS0DB) PIC15 from the CF. This condition exists even if the IMS system using SB is accessing the database in read-only mode. ==================== Added by Ken Friesen ====== 07/28/1999=== 16. IMS BMPs get msgDFS0730I RCO88 (O,88, RCO, RSN88) not enough virtual storage to open a DB. Subsequently DLI (DLS) abends with abend878 (S878, abends878). IPCS LOGDATA shows for the DLI address space that the abend occurred in load module ACF99SVC csect ACF99INT. The SVC 78 occurs in module CTSAPI26+x'A0. The CA fix is LO43981 and is associated with the ETF/A interface.Temp fix is to shutdown ETF/A until fix is installed. This fix also corrects a storage creap problem. =====================UPDATE BY KEN FRIESEN============08/03/99= 17.A BMP starts and goes to allocate data bases.The IMS DLS (DLI)address space abends16E RC10 (S16E RC 10). The abend occurs when DFSAOSF0 issued a DEBCHK after label OSAMDEB. The following messages are on the MVS console log: ACF91EED - ACF2/IFG0553X, CONTROL BLOCK ERROR (MSGACF91EED) DUMPID=xxx REQUESTED BY JOB (DLI address space name) DUMP TITLE=ACF91EED - ACF2/IFG0553X, CONTROL BLOCK ERROR Contact CA for ACF2 fix LO35205. =====================UPDATE BY Rick Crandall==========08/05/99= 18.MSGIEW2456E 9207 SYMBOL DFSNNCC UNRESOLVED. This is an application linkage error and can occur for two general cases... - The internal linkage does not match the external because the application needs to be reassembled and linked. - The external linkage is not correct. This can often be resolved by providing an explicit INCLUDE for the missing member in the jobstep. =====================UPDATE BY Rick Crandall==========08/13/99= 19.Abend0C6 DFSECP20 label EC2XCINV R15='FFFFFFFF' This occurs during a call to perform a CHKP after BMC product ARC has been terminated normally or abnormally, and the user's application ESTAE causes processing to continue as described by BMC below... "This is normally what we do when the users estae gets control and refuses to abend... The users estae gets driven - The arc environment truly has been terminated. In order to ensure that we encounter no problems at a later stage if the users estae routine decides to continue this application, we set an address for the ckpt routine to FFFFFFFF. This will ensure that when the application issues another checkpoint (after the arc environment has terminated) then the S0C6 will occur. If we did not do this then the user app would continue and happily issue ckpts until say another more fatal abend occurred." "The bottom line is ... - don't set an estae environment when you are running a ckpt restart product like us and then intercept abends and expect everything to be aok." =====================UPDATE BY Ken Friesen============08/18/99= 20. When running with FDBR (FDR) the following is encountered. DFS3389I MISMATCH - OSAM CF NAME ++ ++ IMSVOSAM DFS039I IRLM IDENTIFY REQUEST FAILED, RC=16-80. DFS629I IMS RST TCB ABEND - IMS 0039 DFS629I PSW AT ERROR = 477C1000 80206104 DFS629I MODID = IDENTRTN EPA = 00205CC6 Have them check there FDBR options specified in DFSFDRxx. (MSGDFS339I, MSGDFS039I, U0039, ABENDU039, ABENDU39). ================ Added By Ken Friesen ===============08/22/99 21. IMS archive job get the following messages: The DBCTL is active with olds 00 thru 05 allocated in the control region JCL with DISP=SHR. When the automatic switch olds occurs (ARC=01 parameter in DFSPBxxx)for DFSOLP00 and DFSOLS00 the following situation occurs: 1- In the /DIS OLDS, OLP00 and OLS00 are with NEEDED STATUS. 2- The ARCHJCL job is submited and the /DIS OLDS shows the SCHEDULLED status for OLP00 and OLS00. 3- The MVS SYSLOG shows: IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO IMSARCH IEF863I DSN = IMS.OLP00 IEF099I JOB IMSARCHD WAITING FOR DATA SETS 4- The MVS command D GRS,C shows that the IMS control region is allocating the OLP00 and OLS00 with EXCLUSIVE status and the archive job is in WAITING status with SHR intention. This also occurs with the OLDs dynamically allocated Removing OEM product BMC (B&B) SPACEVIEW from the environment resolved the problem. SPACEVIEW is the new version of PROSMS. BYPASS this problem with the auto=00 parm and the following: /DIS OLDS (olds 00 needed) /STO OLDS 00 /DIS OLDS (olds 00 stopped and 01 in use) /RMG DBRC='ARCHIVE' wait time /DIS OLDS (olds 00 available/stopped) /STA OLDS 00 /DIS OLDS (olds 00 available) =====================UPDATE BY Rod Murchison==========10/08/99= 22. Concurrent Batch Backout jobs can be run as long as the following two conditions are met: A) All logs are on DASD (not tape) with DISP=SHR B) You do *NOT* attempt to concurrently backout 2 PSBs that use the same database NOTE: Neither backout nor DBRC will provide protection if you do try to backout two PSBs that use the same DB concurrently and you are exposed to the possiblity of database corruption. It is the user's responsibility to ensure that there is no concurrent backout on PSBs using the same database. ===================== Ken Friesen =============== 04/24/2000 == 23.At this time; all versions of IMS do not support PDS Extented PDSE) format for any PDS/PO library except PGMLIB. The releases that do not support PDSEs are but not limited to IMS V7, V6, V5. Per the IMS Developers, the only IMS library that can be a PDSE is the user's application library, PGMLIB. Other IMS load libraries cannot for a couple of reasons.The main reason is that IMS branch enters Fetch for loading its code and control blocks. IMS GETMAINs storage from specific subpools and loads these control blocks into that storage. The second reason is that IMS maintains BLDL information in storage for periods of time and cannot tolerate reorganization of the partitioned dataset(s) while holding this information internally Both of these techniques enhance the performance of IMS. ==================== Charles Jones ============== 07/18/2000 === 24. Read-only DBCTL DL/I region ABENDU0080 R2=A1500001 Abend issued from DFSAOSF0. 2nd & 4th bytes of R2 are important. The 4th byte of register 2 in the abend SVRB registers contain a failure code. The second byte of register 2 contains a value corresponding to the failing process. The x'50' indicates a termination error, and the x'01' indicates termination is due to an IMODULE GETMAIN error for CSA shortage. See label OTRMAB01. The reason for this error is a CSA shortage, which means IMS is just the victim of a general system wide shortage, in this case from SP=129. A system analysis should be done to determine what is using up CSA without freeing it.
Problem conclusion
Temporary fix
Comments
Close INFO APAR to allow PIN updates.
APAR Information
APAR number
II11174
Reported component name
PB LIB INFO ITE
Reported component ID
INFOPBLIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1998-04-13
Closed date
1998-07-22
Last modified date
2002-01-11
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
[{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEPEK","label":"Db2 for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Document Information
Modified date:
11 January 2002