S0C4 x'4' abend while reading VSAM KSDS file
in [Cobol]
|
From: vbarathee on 19 Jun 2008 01:31 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: Arnold Trembley on 19 Jun 2008 02:35 vbarathee(a)gmail.com wrote: > 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 I am confused. You say the program abends when it calls the ILBOWAT wait routine (an obsolete OS/VS COBOL library routine), and also abends exactly when it tries to read the VSAM file randomly. You also include diagnostics for a VSAM file status error code of '23' (Record not found). You also seem to get an error message indicating a S0C4 abend in a COBOL II library routine named IGZCXFR at displacement X'280'. But you also have a CEE3204S message, which suggests your COBOL program is running with LE (Language Environment), rather than COBOL II runtime libraries. VSAM shareoptions (3,3) will be very slow. You may want to try shareoptions (2,2) to improve performance. This should be safe for your batch program, since it only reads the file and never updates it. The COBOL file status code of 23 probably applies to the last VSAM I/O, and I suspect is unrelated to the S0C4 abend. The other messages imply that your VSAM file has been accessed thousands of times before this abend occurred. Are you running your batch COBOL program with COBOL II runtime libraries searched before Language Environment libraries? That might cause this kind of problem. In any event, it appears the real S0C4 abend is in IGZCXFR. Could you provide a brief COBOL source code sample that includes the procedure division statement executing when the abend occurs? You can use your condensed listing to associate displacement +000545C4 to the COBOL line number within the DSCB6100 program, if your compile listing includes either the "Condensed List" or the disassembly listing. Once you have located the failing COBOL statement, you should look at all data areas referenced by that statement to see if any of them could be in protected storage, such as FD buffers no longer addressable or data items in Linkage section or passed to a called subprogram. You might also want to find out why you are calling a COBOL II library routine instead of an LE (CEE) library routine. It would help if you generated the disassembly listing with the LIST option to see what the failing COBOL statement is actually doing. With kindest regards, -- http://arnold.trembley.home.att.net/
From: SkippyPB on 19 Jun 2008 11:19 On Thu, 19 Jun 2008 06:35:54 GMT, Arnold Trembley <arnold.trembley(a)worldnet.att.net> wrote: >vbarathee(a)gmail.com wrote: >> 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 > > >I am confused. You say the program abends when it calls the ILBOWAT >wait routine (an obsolete OS/VS COBOL library routine), and also >abends exactly when it tries to read the VSAM file randomly. You also >include diagnostics for a VSAM file status error code of '23' (Record >not found). > >You also seem to get an error message indicating a S0C4 abend in a >COBOL II library routine named IGZCXFR at displacement X'280'. But >you also have a CEE3204S message, which suggests your COBOL program is >running with LE (Language Environment), rather than COBOL II runtime >libraries. > IGZCXFR is a Cobol LE routine that handles I/O declarative transfer, if that is of any help. Do you have a proper error handling routine when you get a not found condition on the key read? Are you using Declaratives? >VSAM shareoptions (3,3) will be very slow. You may want to try >shareoptions (2,2) to improve performance. This should be safe for >your batch program, since it only reads the file and never updates it. > >The COBOL file status code of 23 probably applies to the last VSAM >I/O, and I suspect is unrelated to the S0C4 abend. The other messages >imply that your VSAM file has been accessed thousands of times before >this abend occurred. > >Are you running your batch COBOL program with COBOL II runtime >libraries searched before Language Environment libraries? That might >cause this kind of problem. > >In any event, it appears the real S0C4 abend is in IGZCXFR. > >Could you provide a brief COBOL source code sample that includes the >procedure division statement executing when the abend occurs? You can >use your condensed listing to associate displacement +000545C4 to the >COBOL line number within the DSCB6100 program, if your compile listing >includes either the "Condensed List" or the disassembly listing. > >Once you have located the failing COBOL statement, you should look at >all data areas referenced by that statement to see if any of them >could be in protected storage, such as FD buffers no longer >addressable or data items in Linkage section or passed to a called >subprogram. You might also want to find out why you are calling a >COBOL II library routine instead of an LE (CEE) library routine. > >It would help if you generated the disassembly listing with the LIST >option to see what the failing COBOL statement is actually doing. > >With kindest regards, Regards, //// (o o) -oOO--(_)--OOo- "If you think dogs can't count, try putting three dog biscuits in your pocket and then give him only two of them." -- Phil Pastoret ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: Anonymous on 19 Jun 2008 11:46 In article <12uk5412pnfcmn4r5n8nre57v93qum111c(a)4ax.com>, SkippyPB <swiegand(a)nospam.neo.rr.com> wrote: >On Thu, 19 Jun 2008 06:35:54 GMT, Arnold Trembley ><arnold.trembley(a)worldnet.att.net> wrote: > >>vbarathee(a)gmail.com wrote: >>> hi all , >>> >>> Hope someone can resolve my clarifications on cobol , please find >>> below the scenario, [snip] >>> 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. [snip] >>You also seem to get an error message indicating a S0C4 abend in a >>COBOL II library routine named IGZCXFR at displacement X'280'. But >>you also have a CEE3204S message, which suggests your COBOL program is >>running with LE (Language Environment), rather than COBOL II runtime >>libraries. >> > >IGZCXFR is a Cobol LE routine that handles I/O declarative transfer, >if that is of any help. For lo, there is nothing new under the sun... in 1997 Mr Trembley and I discussed a problem similar to this in the comp.software.year-2000 newsgroup. From the description the Original Poster gave it is sounding like a process has outgrown its original scope and someone's trying an 'all ya gotta do is' solution. DD
From: Vince Coen on 19 Jun 2008 15:41
Hello vbarathee! 19 Jun 08 06:31, you wrote to All: v> The VSAM file was defined in Online region , but no job or region v> would update or access the file at the time of run. The share option v> for VSAM was (3,3) and no RLS option was used. Small point, does the file exist with data? If not are you using the OPTIONAL on select? Vince |