View previous topic :: View next topic
|
Author |
Message |
t5590ag
Active User
Joined: 21 May 2009 Posts: 139 Location: United States
|
|
|
|
Hi, I have a JCL which disables/closes a VSAM file and then tries to DELETE it. On some days it abends with below error -
IKJ56241I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
There is nothing abnormal in the syslogs which would show contention or anything. No other JCL/PARM uses the file we are trying to delete. And this does not abend every time.
Following are the steps in JCL -
U11RMS
AOWTOR which uses - SEMT SET FILE(FILENAME) CLO DIS
IDCAMS which tries to DELETE |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Possibility 1: the SEMT (sic) SET FILE(FILENAME) CLO DIS failed to either close or disable (or both) the file, and hence CICS still has it allocated / open.
Possibility 2: as soon as CICS deallocates the file, another job (batch or started task) allocates it.
Quote: |
No other JCL/PARM uses the file we are trying to delete. |
Uh-huh. There's no system back up of the high-level qualifier, or volume, that ever executes? There's no application back up for the data set? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
You are suggesting that the operating system has chosen to pick on your perfect JCL and Control Cards, out of all the jobsteps in the world, to lie?
Are you able to copy/paste this perfection from your emulator? We'd either all benefit from it, or spot what is wrong.
Out of interest, running what you have shown would not close the dataset to CICS, as Robert has already indicated. Let's speculate, just for fun, that operationally the dataset is mostly already closed by the time your JOB starts. Then the "SEMT" fails (and why would it not?) and someone does CEMT manually and kicks your step back in. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
You did not post enough info to debug the problem (*)
if sometimes it works and sometimes it does not
You have a timing problem
the delete/define runs before the cics command has done its work
(*) after seven years of hanging around You should know by now how to ask for help |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
"SEMT" is not an existing command, so the dataset will never be closed. |
|
Back to top |
|
|
t5590ag
Active User
Joined: 21 May 2009 Posts: 139 Location: United States
|
|
|
|
Bill Woodger wrote: |
You are suggesting that the operating system has chosen to pick on your perfect JCL and Control Cards, out of all the jobsteps in the world, to lie?
Are you able to copy/paste this perfection from your emulator? We'd either all benefit from it, or spot what is wrong.
Out of interest, running what you have shown would not close the dataset to CICS, as Robert has already indicated. Let's speculate, just for fun, that operationally the dataset is mostly already closed by the time your JOB starts. Then the "SEMT" fails (and why would it not?) and someone does CEMT manually and kicks your step back in. |
I am not suggesting that at all Bill. I am sure my JCL/PARM needs an enhancement to handle whatever is going on. Just need to know what other places I should go check to find the contention.
Below is a snippet form the log -
CICS log from a normal run, completes at 21.06.18.
Code: |
21.06.13 STC19365 +SEMT #JO00209R392 RESPONSE: NORMAL
21.06.13 STC19365 +SEMT SET FILE(MEXOUT9) CLO DIS RESPONSE: NORMAL
21.06.13 STC19365 +FIL(MEXOUT9 ) VSA CLO DIS REA BRO SHA
)
21.06.13 STC19365 + 1 RESOURCES PROCESSED.
21.06.18 STC19365 +SEMT #JO00209R396 RESPONSE: NORMAL
21.06.18 STC19365 +SEMT SET FILE(MEXOUT9) ENA RESPONSE: NORMAL
21.06.18 STC19365 +FIL(MEXOUT9 ) VSA CLO ENA REA BRO SHA
)
21.06.18 STC19365 + 1 RESOURCES PROCESSED.
21.15.38 STC19365 + 569
21.15.38 STC19365 OPS1000I
569 Openstatus( Open )
|
CICS log from abended run, abended at 21.05.41.
Code: |
21.05.37 STC19365 +SEMT #JO03468R976 RESPONSE: NORMAL
21.05.37 STC19365 +SEMT SET FILE(MEXOUT9) CLO DIS RESPONSE: NORMAL
21.05.37 STC19365 +FIL(MEXOUT9 ) VSA CLO DIS REA BRO SHA
)
21.05.37 STC19365 + 1 RESOURCES PROCESSED.
21.15.37 STC19365 + 757
21.15.37 STC19365 OPS1000I
757 Openstatus( Open )
21.15.37 STC19365 OPS1000I Openstatus( Open )
757 Pstype(Snps)
21.15.37 STC19365 OPS1000I Pstype(Snps)
|
i will gather MVS logs for JCL too. And please let me know what other info can I pull to get to the root cause of this. |
|
Back to top |
|
|
t5590ag
Active User
Joined: 21 May 2009 Posts: 139 Location: United States
|
|
|
|
Robert Sample wrote: |
Possibility 1: the SEMT (sic) SET FILE(FILENAME) CLO DIS failed to either close or disable (or both) the file, and hence CICS still has it allocated / open.
Possibility 2: as soon as CICS deallocates the file, another job (batch or started task) allocates it.
Quote: |
No other JCL/PARM uses the file we are trying to delete. |
Uh-huh. There's no system back up of the high-level qualifier, or volume, that ever executes? There's no application back up for the data set? |
I am going to look for the high-level qualifier usage. thanks Rob. |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
There is NO 'Rob' in this thread. Please show respect and name people as they name themselves on the forum. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
There's some code in a Rexx-like program. Can you show that? |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3048 Location: NYC,USA
|
|
|
|
This error is caused during the Delete of the VSAM file and you did not look for that event in the log and showing what's successfully executed which won't help.
Why not just put a DD statement in the job with DISP=OLD on that VSAM file? this will prevent it failing.
What does your support staff say's about this?
An IDCAMS DIAGNOSE may help. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
"SEMT" is not an existing command.
"OPS1000I" is not a CICS message, but an CA OPS/MVS® Event Management and Automation message.
So my guess is, that this is an inhouse automation utility and the showed log is not a CICS log but a CA OPS/MVS log.
Talk with your CA OPS/MVS support. |
|
Back to top |
|
|
|