S0C4 x'4' abend while reading VSAM KSDS file
in [Cobol]
|
From: William M. Klein on 24 Jun 2008 15:33 I haven't read this thread yet, but has someone said: A) to call ILBOWAT0, you must compile the CALLING program with DATA(24) and B) That calls to ILBOWAT0 should now be replaced by calls to CEE3DLY, see: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3180/2.2.5.5 -- Bill Klein wmklein <at> ix.netcom.com <vbarathee(a)gmail.com> wrote in message news:a9a3f442-72d5-496f-be8c-3e361866b1d5(a)z72g2000hsb.googlegroups.com... hi all , Hope someone can resolve my clarifications on cobol , please find below the scenario, We have a batch job runs with two input files, one PS file and a VSAM KSDS file , we read the acct number from the PS file and check with KSDS file , we use the acct no as key and take details , then we write into MQ series . Also we have a wait time logic in the pgm which calls ILBOWAT module so that once the threshold reaches some 250,000 in MQ , all the jobs will wait for 180 secs and then it will continue writing into MQ. This program was a generic one and used by 10 split jobs running parallely in production , recently we added the VSAM file , previously the pgm had only PS file. Now the job is getting abend with S0C4 x'4' when it waits for the threshold limit and abends exactly when it tries to read the input VSAM file. The VSAM file was defined in Online region , but no job or region would update or access the file at the time of run. The share option for VSAM was (3,3) and no RLS option was used. Please find below abend code details , MQM-REASON-CODE: 000000000 MQ-TARGET-QUEUE : HNCDSCVR.LQ.FCMSLOW ************** CALL TO MQOPEN ***************** MQM-OBJECT-HANDLE: 000000001 MQM-REASON-CODE: 000000000 ### MQ DEPTH: 79481 RECORDS WRITTEN: 10001 02:32:22 ### MQ DEPTH: 159281 RECORDS WRITTEN: 20002 02:33:04 ### MQ DEPTH: 244216 RECORDS WRITTEN: 30003 02:33:33 ### MQ DEPTH: 327990 RECORDS WRITTEN: 40004 02:34:01 ### MQ DEPTH: 227646 RECORDS WRITTEN: 40004 02:37:01 CEE3204S The system detected a protection exception (System Completion Code=0C4). From compile unit DSCB6100 at entry point DSCB6100 at compile unit offset +000545C4 at entry offset +000545C4 at address 0005B904. 02.37.02 JOB02101 +IDI0001I Fault Analyzer V6R1M0 (PK29971 2006/08/24) invoked by IDIXDCAP using MVSP.FANALYZE.PARMLIB(IDICNF00) 02.37.03 JOB02101 +IDI0081I IEWBIND unusual condition INCLUDE DSCB6100 rc=3000526 02.37.19 JOB02101 +IDI0002I Module IGZCXFR offset X'280': Abend S0C4- X'4' (Protection Exception) 02.37.19 JOB02101 +IDI0003I Fault ID F04475 assigned in history file MVSP.FA.PROD.BATCH.HIST Fault analyzer details : File Name . . . . . . . . . : DSCCQUEU RT��� Data Set Name . . . . . . : DSCP.VO00P.CICS160I.DSCCQUEU �RT� 5 File Attributes . . . . . : ORGANIZATION=INDEXED VSAM, ACCESS MODE=RANDOM, �RT��� RECFM=FIXED �RT��� Last I/O Function . . . . : READ �RT��� Open Status . . . . . . . : INPUT RT��� File Status Code. . . . . : 23 �RT� 5 An attempt was made to randomly access a record �RT� 5 �RT� 5 that does not exist in the file, or a START or �RT� 5 �RT� 5 random READ statement was attempted on an optional �RT� 5 �RT input file that was not present. �RT �RT��� Return Code . . . . . . . : X'8' �RT��� Function Code . . . . . . : X'0' �RT��� Feedback Code . . . . . . : X'10' �RTass Record not found, or the RBA is not found in the �RTass �RT��� buffer pool. (If multiple RPL requests are issued �RT��� �RT��� for alternate indexes, getting return code �RT��� �RT��� 16(X'10') might mean a temporary situation where �RT��� �RT��� processing has not been completed on either the �RT��� �RT base cluster or the associated alternate indexes.) �RT The same code works fine when we use Dynamic access mode and a START verb before reading the VSAM file. We are able to track the pgm where it gets abend , but we are unable to locate the exact reason . The same code runs in testing environment fine if it is not going to wait time logic . Please let me know ur findings. Thanks Barathi.v
From: klshafer on 24 Jun 2008 15:59 On Jun 24, 3:33 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > I haven't read this thread yet, but has someone said: > > A) to call ILBOWAT0, you must compile the CALLING program with DATA(24) > and > B) That calls to ILBOWAT0 should now be replaced by calls to CEE3DLY, see: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3180/2... Hi, Bill, Our shop makes a CALL to ILBOABN0 to do a user-initiated abend. Is there an analogous CEE call that we should be making instead? Ken
From: klshafer on 24 Jun 2008 16:36 On Jun 24, 3:59 pm, "klsha...(a)att.net" <klsha...(a)att.net> wrote: > On Jun 24, 3:33 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> > wrote: > > > I haven't read this thread yet, but has someone said: > > > A) to call ILBOWAT0, you must compile the CALLING program with DATA(24) > > and > > B) That calls to ILBOWAT0 should now be replaced by calls to CEE3DLY, see: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3180/2... > > Hi, Bill, > > Our shop makes a CALL to ILBOABN0 to do a user-initiated abend. > > Is there an analogous CEE call that we should be making instead? > > Ken Oops, Mr. Klein has already answered this before, back in 2004... http://groups.google.com/group/comp.lang.cobol/browse_frm/thread/4a81304043a5b224/f1fefd05beba9bf2?tvc=1&q=abending#f1fefd05beba9bf2 Next time I should do a better search of "information assets" within CLC before posting a redundant question... Ken
From: William M. Klein on 24 Jun 2008 23:19 I still haven't read this entire thread but a few things seem clear (to me): 1) If you are still using calls to ILBOWAT0, then you need to be careful about AMODE and RMODE. The recommended way to do this is via a DYNAMIC call (CALL identifier) statement with an Enterprise COBOL program compiled with DATA(24). If you use a static call, then make certain you don't override the link-edit (binder) attributes and keep the entire load module "below the line". - Better yet, upgrade to CEE3DLY from ILBOWAT0. 2) The ANSI/ISO Standard has a rule that says you must have a file status field OR a declarative. IBM has an extension that says you don't need either. HOWEVER, if you have neither, then COBOL will ABEND when an unsuccessful (e.g. "23") status occurs. This seems to be happening here. Recommendation: - Add a file status (actually, also add a 2nd 6-byte file-status-2 field as defined in the LRM). - Check the file status after ALL I/O (including OPENs, START, READ) - If you are using data from the sequential file to look for a specific record in the VSAM file and you get a file status 23, make certain that you display what key value you tried using on the READ or START (with an indication of the length of the key used). -- Bill Klein wmklein <at> ix.netcom.com <vbarathee(a)gmail.com> wrote in message news:a9a3f442-72d5-496f-be8c-3e361866b1d5(a)z72g2000hsb.googlegroups.com... hi all , Hope someone can resolve my clarifications on cobol , please find below the scenario, We have a batch job runs with two input files, one PS file and a VSAM KSDS file , we read the acct number from the PS file and check with KSDS file , we use the acct no as key and take details , then we write into MQ series . Also we have a wait time logic in the pgm which calls ILBOWAT module so that once the threshold reaches some 250,000 in MQ , all the jobs will wait for 180 secs and then it will continue writing into MQ. This program was a generic one and used by 10 split jobs running parallely in production , recently we added the VSAM file , previously the pgm had only PS file. Now the job is getting abend with S0C4 x'4' when it waits for the threshold limit and abends exactly when it tries to read the input VSAM file. The VSAM file was defined in Online region , but no job or region would update or access the file at the time of run. The share option for VSAM was (3,3) and no RLS option was used. Please find below abend code details , MQM-REASON-CODE: 000000000 MQ-TARGET-QUEUE : HNCDSCVR.LQ.FCMSLOW ************** CALL TO MQOPEN ***************** MQM-OBJECT-HANDLE: 000000001 MQM-REASON-CODE: 000000000 ### MQ DEPTH: 79481 RECORDS WRITTEN: 10001 02:32:22 ### MQ DEPTH: 159281 RECORDS WRITTEN: 20002 02:33:04 ### MQ DEPTH: 244216 RECORDS WRITTEN: 30003 02:33:33 ### MQ DEPTH: 327990 RECORDS WRITTEN: 40004 02:34:01 ### MQ DEPTH: 227646 RECORDS WRITTEN: 40004 02:37:01 CEE3204S The system detected a protection exception (System Completion Code=0C4). From compile unit DSCB6100 at entry point DSCB6100 at compile unit offset +000545C4 at entry offset +000545C4 at address 0005B904. 02.37.02 JOB02101 +IDI0001I Fault Analyzer V6R1M0 (PK29971 2006/08/24) invoked by IDIXDCAP using MVSP.FANALYZE.PARMLIB(IDICNF00) 02.37.03 JOB02101 +IDI0081I IEWBIND unusual condition INCLUDE DSCB6100 rc=3000526 02.37.19 JOB02101 +IDI0002I Module IGZCXFR offset X'280': Abend S0C4- X'4' (Protection Exception) 02.37.19 JOB02101 +IDI0003I Fault ID F04475 assigned in history file MVSP.FA.PROD.BATCH.HIST Fault analyzer details : File Name . . . . . . . . . : DSCCQUEU RT��� Data Set Name . . . . . . : DSCP.VO00P.CICS160I.DSCCQUEU �RT� 5 File Attributes . . . . . : ORGANIZATION=INDEXED VSAM, ACCESS MODE=RANDOM, �RT��� RECFM=FIXED �RT��� Last I/O Function . . . . : READ �RT��� Open Status . . . . . . . : INPUT RT��� File Status Code. . . . . : 23 �RT� 5 An attempt was made to randomly access a record �RT� 5 �RT� 5 that does not exist in the file, or a START or �RT� 5 �RT� 5 random READ statement was attempted on an optional �RT� 5 �RT input file that was not present. �RT �RT��� Return Code . . . . . . . : X'8' �RT��� Function Code . . . . . . : X'0' �RT��� Feedback Code . . . . . . : X'10' �RTass Record not found, or the RBA is not found in the �RTass �RT��� buffer pool. (If multiple RPL requests are issued �RT��� �RT��� for alternate indexes, getting return code �RT��� �RT��� 16(X'10') might mean a temporary situation where �RT��� �RT��� processing has not been completed on either the �RT��� �RT base cluster or the associated alternate indexes.) �RT The same code works fine when we use Dynamic access mode and a START verb before reading the VSAM file. We are able to track the pgm where it gets abend , but we are unable to locate the exact reason . The same code runs in testing environment fine if it is not going to wait time logic . Please let me know ur findings. Thanks Barathi.v
From: William M. Klein on 24 Jun 2008 23:23
Your use of ILBOWAT0 is probably why you are getting S0C4 - you probably are NOT using the correct AM/RMODE and DATA options. -- Bill Klein wmklein <at> ix.netcom.com <vbarathee(a)gmail.com> wrote in message news:284af19c-3f88-4348-9e4a-2628dd841062(a)34g2000hsf.googlegroups.com... > Hi > > Give me some time to run the program without ILBOWATO module. > > The enhancement work came to us a month back. > > Could please explain me the reason behind why we need to run the > program without ILBOWATO , I'm sorry I'm confused. Bcoz the logic wud > change if we remove the traces of ILBOWATO . > > Regards, > barathi.v > |