enq on a dataset and kill the userid

neerajpeddu · Posted: Fri Feb 13, 2009 1:17 am

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.

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.

neerajpeddu · Posted: Fri Feb 13, 2009 8:19 am

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.

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.

neerajpeddu · Posted: Sat Feb 14, 2009 12:52 am

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.

Peter Poole · New User Joined: 07 Jan 2009 Posts: 50 Location: Scotland

Good luck! Let us know how the story ends

Cheers.

expat · Posted: Sat Feb 14, 2009 2:24 pm

I don't suppose that killing the user rather than the userid would work

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!

Terry Heinze · Posted: Sun Feb 15, 2009 10:07 pm

Expat,
That was my thought too. "The software isn't complete until the last user is dead."

Pedro · Posted: Sun Feb 15, 2009 10:29 pm

If you are getting CONSOLE authority, you might as well just issue DISPLAY GRS command to list contention information.

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.

dick scherrer · Posted: Mon Feb 16, 2009 6:53 am

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. . .

expat · Posted: Mon Feb 16, 2009 2:42 pm

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

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?

Peter Poole · New User Joined: 07 Jan 2009 Posts: 50 Location: Scotland

neerajpeddu · Posted: Fri Jun 12, 2009 5:55 pm

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

neerajpeddu · Posted: Fri Jun 12, 2009 5:59 pm

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

dick scherrer · Posted: Sat Jun 13, 2009 5:29 am

Thanks for the follow-up - hopefully, the year will pass quickly with no more of these "adventures". . .

d