USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Hi,
We have a Job USD025SS, which abends with CC 00012. Upon checking upon it shows that one of the VSAM dataset is being used. When we try to find the job or user accessing the dataset, we can't find it but when we try to exeute the Job from abended step, it works. What can we do to mitigate it?
We have a Job USD025SS, which abends with CC 00012. Upon checking upon it shows that one of the VSAM dataset is being used. When we try to find the job or user accessing the dataset, we can't find it but when we try to exeute the Job from abended step, it works. What can we do to mitigate it?
Last edited by Md.Imtiaz on Thu Aug 12, 2021 7:14 pm, edited 1 time in total.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
There is another interesting thing the VSAM in question does not have a INDEX part:
*DSLIST -DSLIST
Code: Select all
Menu Options View Utilities Compilers Help
------------------------------------------------------------------------------
DSLIST - Data Sets Matching V.PR50.VSAMDT Row 1 of 2
Command ===> Scroll ===> CSR
Command - Enter "/" to select action Message Volume
-------------------------------------------------------------------------------
V.PR50.VSAMDT *VSAM*
V.PR50.VSAMDT.DATA PVS127+
***************************** End of Data Set list ****************************
*DSLIST -DSLIST
*DSLIST -DSLIST
- Robert Sample
- Global Moderator
- Posts: 1903
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
This is not actually an interesting thing. There are different types of VSAM data sets (ESDS, RRDS, KSDS, LDS) and an ESDS in particular does NOT have an index component. So you've probably got a VSAM ESDS data set you're looking at.There is another interesting thing the VSAM in question does not have a INDEX part:
What are the SHAREOPTIONS for the data set? Is the data set JCL reference DISP=OLD or DISP=SHR? These questions could indicate where your problem is.it shows that one of the VSAM dataset is being used.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
How do I identify about that?What are the SHAREOPTIONS for the data set?
DISP=SHR is used for this file in the Job which abended.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
I relooked at your question and found that this is the DELETE/DEFINE for VSAM:
That means SHAREOPTIONS is 2.
Is there any other way to know about the VSAM information apart from looking its DEFINE?
Code: Select all
--+----1----+----2----+----3----+----4----+----5----+
DELETE-
V.PR50.VSAMDT-
PURGE
DEFINE CLUSTER(NAME(V.PR50.VSAMDT)CYL(100 20)-
RECORDSIZE(040 1020)-
SHR(2)-
UNIQUE-
NONINDEXED)-
DATA(NAME(V.PR50.VSAMDT.DATA)CISZ(4096))
Is there any other way to know about the VSAM information apart from looking its DEFINE?
- Robert Sample
- Global Moderator
- Posts: 1903
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
If you execute IDCAMS, you can specify LISTCAT to view the definition of a VSAM data set. If you go to option 3.4 of ISPF and use LC on the data name in the list, you can get the same information. The NONINDEXED in the DEFINE means that it is an ESDS and not a KSDS.
The SHAREOPTIONS value gives the cross-region value for jobs running in a single z/OS image, while the second value (if specified -- if not specified, no cross-system access is allowed) gives the cross-system value for jobs running on other z/OS images in the SYSPLEX. SHR(2) which is what you have, with DISP=SHR in the JCL, means you are NOT asking for exclusive access to the data set to write records, so you're pretty much guaranteed to get the problem you see. When writing to a VSAM data set, DISP=OLD in the JCL prevents other jobs / users from accessing the data set while your job is using it. Before you make this change, though, you need to verify what other job(s) are accessing the data set as well since your job cannot begin executing (either the job or that step depending on which JES you use) until you can have exclusive access to it. This may delay your job and potentially impact the overall batch window processing.
SHAREOPTIONS are important when one (or more) jobs can be writing to a VSAM data set while one or more other jobs are reading it at the same time. For example, job A reads key 10000 from a KSDS, updates it, and writes it back to the VSAM data set. At the same time, job B reads key 10000 from the KSDS. Without concurrency control, job B may read the record before job A writes it back to the VSAM and hence retrieved old data. There are multiple ways to deal with this issue; DISP=OLD in the JCL is the easiest. With DISP=OLD, job B won't be allowed to execute until job A is complete (or job A won't be allowed to start until job B is complete; it depends upon which job started first).
The SHAREOPTIONS value gives the cross-region value for jobs running in a single z/OS image, while the second value (if specified -- if not specified, no cross-system access is allowed) gives the cross-system value for jobs running on other z/OS images in the SYSPLEX. SHR(2) which is what you have, with DISP=SHR in the JCL, means you are NOT asking for exclusive access to the data set to write records, so you're pretty much guaranteed to get the problem you see. When writing to a VSAM data set, DISP=OLD in the JCL prevents other jobs / users from accessing the data set while your job is using it. Before you make this change, though, you need to verify what other job(s) are accessing the data set as well since your job cannot begin executing (either the job or that step depending on which JES you use) until you can have exclusive access to it. This may delay your job and potentially impact the overall batch window processing.
SHAREOPTIONS are important when one (or more) jobs can be writing to a VSAM data set while one or more other jobs are reading it at the same time. For example, job A reads key 10000 from a KSDS, updates it, and writes it back to the VSAM data set. At the same time, job B reads key 10000 from the KSDS. Without concurrency control, job B may read the record before job A writes it back to the VSAM and hence retrieved old data. There are multiple ways to deal with this issue; DISP=OLD in the JCL is the easiest. With DISP=OLD, job B won't be allowed to execute until job A is complete (or job A won't be allowed to start until job B is complete; it depends upon which job started first).
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Thanks Robert
The job has the folloing message, how would we know it was in contention with which job or CICS program?
The job has the folloing message, how would we know it was in contention with which job or CICS program?
Code: Select all
Display Filter View Print Options Search Help
-------------------------------------------------------------------------------
SDSF OUTPUT DISPLAY USD025SS JOB32517 DSID 102 LINE CHARS 'V.PR50.VSAMDT' F
COMMAND INPUT ===> SCROLL ===> CSR
V.PR50.VSAMDT- 000000
PURGE 000000
0IKJ56241I DATA SET V.PR50.VSAMDT NOT ALLOCATED
IKJ56241I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
IDC0551I ** ENTRY V.PR50.VSAMDT NOT DELETED
0IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8
0
DEFINE CLUSTER(NAME(V.PR50.VSAMDT)CYL(100 20)- LLV0109
RECORDSIZE(040 1020)- MCV9701
SHR(2)- 000000
UNIQUE-
NONINDEXED)- LLV0109
DATA(NAME(V.PR50.VSAMDT.DATA)CISZ(4096)) 000000
0IGD17101I DATA SET V.PR50.VSAMDT
NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET
V.PR50.VSAMDT
0IDC3013I DUPLICATE DATA SET NAME
DSLIST *SDSF DSLIST -SDSF
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Thank you. LC works great.Robert Sample wrote: ↑Fri Aug 13, 2021 11:26 pm If you execute IDCAMS, you can specify LISTCAT to view the definition of a VSAM data set. If you go to option 3.4 of ISPF and use LC on the data name in the list, you can get the same information. The NONINDEXED in the DEFINE means that it is an ESDS and not a KSDS.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
That means we need to use DISP=OLD in both the jobs?SHAREOPTIONS are important when one (or more) jobs can be writing to a VSAM data set while one or more other jobs are reading it at the same time. For example, job A reads key 10000 from a KSDS, updates it, and writes it back to the VSAM data set. At the same time, job B reads key 10000 from the KSDS. Without concurrency control, job B may read the record before job A writes it back to the VSAM and hence retrieved old data. There are multiple ways to deal with this issue; DISP=OLD in the JCL is the easiest. With DISP=OLD, job B won't be allowed to execute until job A is complete (or job A won't be allowed to start until job B is complete; it depends upon which job started first).
- Robert Sample
- Global Moderator
- Posts: 1903
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
If you have console access, you can use command D GRS,C to display contention for data sets. If you don't have console access, you'll need to ask your site support group.how would we know it was in contention with which job or CICS program?
Do both jobs write to the VSAM data set? If so, you should have DISP=OLD on both jobs. If not, the job that writes to the VSAM data set should have DISP=OLD while jobs that just read from it can use DISP=SHR.That means we need to use DISP=OLD in both the jobs?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Robert has an excellent explanation, however, why not use the scheduling software to create dependency of jobs on each other?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
I think scheduling software can work BUT if the two jobs are not dependent on each other, apart from using the same file then is it good to DISP=OLD or scheduling software? Will it not confuse in future impact analysis that why these two jobs are dependent of each other?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
That is why I think what Robert is telling is the best approach.Geetu wrote: ↑Wed Aug 18, 2021 6:50 pm I think scheduling software can work BUT if the two jobs are not dependent on each other, apart from using the same file then is it good to DISP=OLD or scheduling software? Will it not confuse in future impact analysis that why these two jobs are dependent of each other?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
We used scheduling changes for the final solution.
- Robert Sample
- Global Moderator
- Posts: 1903
- Joined: Fri Jun 28, 2013 1:22 am
- Location: Dubuque Iowa
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
I'm glad to hear you got it resolved.
Create an account or sign in to join the discussion
You need to be a member in order to post a reply
Create an account
Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute