Page 1 of 1
USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Thu Aug 12, 2021 7:11 pm
by Md.Imtiaz
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?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Thu Aug 12, 2021 7:14 pm
by Md.Imtiaz
There is another interesting thing the VSAM in question does not have a INDEX part:
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
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Thu Aug 12, 2021 10:43 pm
by Robert Sample
There is another interesting thing the VSAM in question does not have a INDEX part:
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.
it shows that one of the VSAM dataset is being used.
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.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Fri Aug 13, 2021 4:33 pm
by Md.Imtiaz
What are the SHAREOPTIONS for the data set?
How do I identify about that?
DISP=SHR is used for this file in the Job which abended.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Fri Aug 13, 2021 4:39 pm
by Md.Imtiaz
I relooked at your question and found that this is the DELETE/DEFINE for VSAM:
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))
That means SHAREOPTIONS is 2.
Is there any other way to know about the VSAM information apart from looking its DEFINE?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Fri Aug 13, 2021 11:26 pm
by Robert Sample
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).
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Sat Aug 14, 2021 1:26 am
by Md.Imtiaz
Thanks Robert
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 ***
Posted: Sat Aug 14, 2021 1:27 am
by Md.Imtiaz
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.
Thank you. LC works great.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Sat Aug 14, 2021 1:40 am
by Md.Imtiaz
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).
That means we need to use DISP=OLD in both the jobs?
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Sat Aug 14, 2021 7:28 am
by Robert Sample
how would we know it was in contention with which job or CICS program?
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.
That means we need to use DISP=OLD in both the jobs?
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.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Sun Aug 15, 2021 12:30 pm
by DB2 Guy
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 ***
Posted: Wed Aug 18, 2021 6:50 pm
by Geetu
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 ***
Posted: Fri Aug 20, 2021 6:58 pm
by Md.Imtiaz
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?
That is why I think what Robert is telling is the best approach.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Tue Sep 14, 2021 9:12 am
by Geetu
We used scheduling changes for the final solution.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Tue Sep 14, 2021 7:03 pm
by Robert Sample
I'm glad to hear you got it resolved.
Re: USD025SS Failing every day with CC 00012 ** CRITICAL PATH ***
Posted: Sun Oct 10, 2021 8:49 am
by Geetu
Thanks for all the help
