View previous topic :: View next topic
|
Author |
Message |
neerajpeddu
New User
Joined: 03 Feb 2006 Posts: 25 Location: Calgary, AB
|
|
|
|
I have a strange situation. In one of our jobs, we are updating a GDG (0 version) using a COBOL program (don't know why a new generation can not be created. that is how the system is). The problem is when some one is browsing the file (0 generation), while the job is trying to update the 0 generation, the job craps out giving a JCL Error. We tried disp=old and it did not work either. I assumed that disp=old will work but it seem to work for PDS or flat files but not GDG generations.
To prevent this issue, I was planning on writing a REXX program to find out who has an enqueue on the 0 generation of the GDG and send out a few TSO messages to the user id and within a minute or so if the user does not release the resource, kill the userid.
I was wondering if any one has done some thing like this before and if so, could you please share your knowledge on how this can be done and if there are any tips or tricks to do this.
Any help in this regard is greatly appreciated. Thank you very much in advance. |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
Killing userids sounds a bit draconian...
What does your COBOL program JCL look like and what JCL error(s) do you get?
Cheers. |
|
Back to top |
|
|
neerajpeddu
New User
Joined: 03 Feb 2006 Posts: 25 Location: Calgary, AB
|
|
|
|
Hi Peter, thanks for your response.
The JCL and program are normal. JCL has
//DDNAME DD DSN=A.B.C.D(0),DISP=SHR
COBOL Program opens this file in I-O mode.
When some one is browsing dataset 'A.B.C.D(0)' while the JCL tries to open in I-O mode, the JCL fails with the following reason.
'DATA SET RESERVATION UNSUCCESSFUL'
Usually when DISP=OLD is used, the job would not even start itself and console messages would be sent to the user holding the resource but that applies only to flat files and PDS's but not GDG. I believe that is because the full file name (including the generaton) is not resolved until the step starts executing.
I want to use a REXX program to identify who has an enqueue on 'A.B.C.D.GnnnnV00' and send messages similar to what happens when a user is browsing a flat file or a PDS while a batch job is trying to gain exclusive access on that particular PDS/flat file. Also, usually the console operator does cancel the user id's if the user is causing any delay to the production jobs. Also, optionally, I'd like to include that feature in my REXX program (The user may have stepped out of her/her desk for quiet some time). I understand that there is a feature in REXX that can be invoked to activate a console environment.
ADDRESS CONSOLE "system_command"
where the system_command is "c u=userid" to cancel a userid.
Please let me know if you have ever used this kind of feature. |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
Curious...
I'd suspect that whoever is browsing the dataset has actually managed to open it in update mode (Some third party products open with an update ACB even if you're only going to read)
Invoking the mighty power of Google shows us:
Info on REXX handling ENQ information can be found at:
www.sillysot.com/mvs/index.htm?queryenq.htm
Address console info, here:
www.mail-archive.com/ibm-main@bama.ua.edu/msg30068.html
You'll need to ensure that whatever userid your job runs under is authorised to issue CANCEL commands.
Cheers. |
|
Back to top |
|
|
neerajpeddu
New User
Joined: 03 Feb 2006 Posts: 25 Location: Calgary, AB
|
|
|
|
Excellent Peter, Thank you very much for your help. I found Doug Nadals' post earlier but was not able to find his code. One of his earlier posted links is no more available and I greatly appreciate the link you provided. That is a very good info.
I'm going to try it and see if it works.
I will be asking my RACF administrators to provide access to CONSOLE commands for my batch prod user id. It does not exist now and thank you for bringing that up.
Thank you for your help. |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
Good luck! Let us know how the story ends
Cheers. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
I don't suppose that killing the user rather than the userid would work |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
"Pour encourager les autres"?
Killing the user always helps. It's hiding the body that's a bitch....
Cheers! |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1248 Location: Richfield, MN, USA
|
|
|
|
Expat,
That was my thought too. "The software isn't complete until the last user is dead." |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2593 Location: Silicon Valley
|
|
|
|
If you are getting CONSOLE authority, you might as well just issue DISPLAY GRS command to list contention information. |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
Swings, roundabouts, infinite number of skinned users - I mean cats.
I don't think either solution is empirically 'better' enough to argue about it.
Cheers. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Ever the radical, (and i've many a holy shirt from the arrows/shots), i suggest discontinuing the update of generation(0) - or any other production qsam file. . . No matter that "it has always been done that way". . .
What business requirement might there be that would require this?
I do understand that there may be reluctance to change the process, but i also remember being asked at several sites how to recover from the file being destroyed (one of the neat things about being a migrant data worker is seeing an incredible number of ways to inflict self-damage). . . Multiple times, returning to the point of failure was not possible. . . Then the process was changed.
fwiw. . . |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8796 Location: Welsh Wales
|
|
|
|
Terry Heinze wrote: |
Expat,
That was my thought too. "The software isn't complete until the last user is dead." |
And never any user complaints |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
When the IT department says it's given an undertaking to the business, we're choosing our words carefully...
Updating a gen(0) file is indeed a bit odd. I'm curious that you've got people potentially browsing a production dataset through TSO too, but "there's nothing so bizarre that someone somewhere isn't running it live"
Cheers |
|
Back to top |
|
|
Kevin Santos
New User
Joined: 27 Jan 2009 Posts: 26 Location: toronto
|
|
|
|
This must be prevalent that would warrant writing a code to find and 'kill' the userid holding the resource. Anyway, I thought that browsing a dataset would not put an enqueue/hold on the file?
Either someone is always opening the file (PAYROLL ) in edit mode or the file is preallocated (DISP=OLD) somewhere? |
|
Back to top |
|
|
Peter Poole
New User
Joined: 07 Jan 2009 Posts: 50 Location: Scotland
|
|
|
|
Peter Poole wrote: |
I'd suspect that whoever is browsing the dataset has actually managed to open it in update mode (Some third party products open with an update ACB even if you're only going to read)
Cheers. |
|
|
Back to top |
|
|
neerajpeddu
New User
Joined: 03 Feb 2006 Posts: 25 Location: Calgary, AB
|
|
|
|
Thank you all for all your wonderful suggestions
Actually, we had to scrap that idea since we did not have the permissions to kill the user. Instead, we had to educate them not to be in the file. It has worked so far and hopefully will stay that way until a new user comes on board |
|
Back to top |
|
|
neerajpeddu
New User
Joined: 03 Feb 2006 Posts: 25 Location: Calgary, AB
|
|
|
|
Dick, On your note "i suggest discontinuing the update of generation(0) - or any other production qsam file. . . No matter that "it has always been done that way". ", I totally agree with you and completely understand the reasons why not to do it. Unfortunately, I have to echo your words that it always has been that way and there is no motivation/justification for the business to move away from it since the file span for this application is about a year from now |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Thanks for the follow-up - hopefully, the year will pass quickly with no more of these "adventures". . .
d |
|
Back to top |
|
|
|