REXX to release hold jobs from SDSF

kalyanbrata.dhar · New User Joined: 02 Sep 2008 Posts: 13 Location: Kolkata

Hi All,

I am not sure if this is at all feasible or not. However, I am describing my requirement here:

Problem:-
My users submit jobs from online system (CICS). Jobs come to hold in sdsf. We manually release the jobs. The JCl are created while they are submitting the jobs. Suppose, they have submitted 50 jobs named as #TEST1, #TEST2, #TEST3... and so on. So, all the jobs will be starting with #TEST. And, let say, #TEST jobs will trigger #NEXT jobs as #NEXT1, #NEXT2, #NEXT3.... Waht we do now, we release #TEST1 first, and wait till completion of #NEXT1 (triggerred by #TEST1), once #NEXT1 is completed we release the next #TEST job and so on. We release from SDSF input queue by putting 'a' as line command of the left column of the job.

Plan
What I was wondering is, first we will take all the #TEST job names in a PS. Then a rexx code will pick up the first job from the ps and will go to sdsf input queue and release the first one. then it will wait till the completion of #NEXT job. Once #NEXT ic completed, it will release the second one and so on.

Please note that, we do not have access to modify the job jcl.

Help in this regard will be highly appreciated.

Thanks
Kalyan

Robert Sample · Posted: Thu Mar 25, 2010 6:23 pm

What research have you done already? What version of z/OS are you running?

A forum search on rexx AND sdsf returned 141 hits. Have you reviewed them for relevance?

kalyanbrata.dhar · New User Joined: 02 Sep 2008 Posts: 13 Location: Kolkata

z/OS 1.09.00

Well, I have tried to find the solution in other forums. But did not get any suitable for mine...

Robert Sample · Posted: Thu Mar 25, 2010 7:10 pm

Some of the 141 hits on this forum talk specifically about z/OS 1.9 and SDSF access via REXX. Click on the Search button above and proceed from there.

expat · Posted: Thu Mar 25, 2010 7:20 pm

Can I ask why the jobs are submitted in HOLD status ?

kalyanbrata.dhar · New User Joined: 02 Sep 2008 Posts: 13 Location: Kolkata

Well, the users submit several thousands jobs from online system. If those are not at hold, all will start running at a time and system will be blown up.. Also, database get stucked. Thats why, to increase the cpu and db performance, we decided to keep the submitted jobs on hold. Earlier, they used to run the jobs directly (no hold situation) and had faced terrific system bottlenecking issues. There are several business users, and they do not have access to check what is the system usage. So, they used to submit the jobs before they leave, and all jobs used to fight for system resources. Last year in busy business season, we have decided not allow the users to run directly, rather they can submit tags on hold only. By introducing this process, we were really good for the system and bottlenecking issue was reduced a lot.
Now, we are in another problem, that we need to release the jobs manually. We have CA7 installed for our shop. But we are not able to handle these cics submitted jobs from CA7. What most we can do, we can define some other program to check and release the jobs and this program can be controlled forom ca7.

Please let me know, if I am able to explain you.

gcicchet · Posted: Fri Mar 26, 2010 10:38 am

Hi,

you can always have dedicated initiators to control the flow of the jobs.

You can then stop and start them as you wish.

I don't know CA7, but other scheduling tools are able to monitor/track external jobs and control when the jobs can run, how many can run and whether they are successful or not.

For this reason we purposely have jobs submitted with a TYPRUN=HOLD and released by the scheduling tool when all dependencies, resources have been met.

Gerry

dick scherrer · Posted: Fri Mar 26, 2010 10:41 am

Hello,

One thing you could do to reduce the "all will start running at a time and system will be blown up.. Also, database get stucked. " situation would be to submit all of these jobs in a CLASS that only had a few initiators available/active.

Another would be to submit these jobs with a common (or very few) jobnames so that they would run serially rather than concurently.

Something that some of my clients have done is to queue requests to run jobs rather than submitting the jobs directly. Periodically a job is submitted via the schedule to read the queue and submit the next queued request.

kalyanbrata.dhar · New User Joined: 02 Sep 2008 Posts: 13 Location: Kolkata

"all of these jobs in a CLASS that only had a few initiators available/active"

We already have this set up. Problem is, different business groups have been assigned different classes and even though they submit each one for every class the system is at high use.

"Another would be to submit these jobs with a common (or very few) jobnames so that they would run serially rather than concurently. "

This could be the best possible solution, but we can not change in this way. Reason is, when the business users submit the jobs, the jcl get created on fly, and the job names are created including the group identifier names and in a random manner. Suppaose, one group has been assigned a tag id 8A-8G. The jobs names will look like anything from 8A - 8G, i.e. #EXP8A, #EXP8B and so on. So SDFS will not consider them. I tried to make this as a solution, but users do not want this as a solution as it will losse the identity of different business groups.

kalyanbrata.dhar · New User Joined: 02 Sep 2008 Posts: 13 Location: Kolkata

@gcicchet

"you can always have dedicated initiators to control the flow of the jobs."

This is what we are doing right now. But when the number of jobs submitted inthousands and number of classes assigned to different users group are different, these solution requires lots of manual efort.

"Something that some of my clients have done is to queue requests to run jobs rather than submitting the jobs directly. Periodically a job is submitted via the schedule to read the queue and submit the next queued request."

Are you handling the jobs (typrun=hold), whose member names are not fixed? If so, then can you please guide me how have done this? Forget about CA7, lmost all scheduler tools are logically same.

"I don't know CA7, but other scheduling tools are able to monitor/track external jobs and control when the jobs can run, how many can run and whether they are successful or not. "

Well, CA7 is capable of monitoring the external jobs, specially those which are running at SDSF, but through a window set up. This set up do not give more control when they are in input queue of sdsf.

dick scherrer · Posted: Fri Mar 26, 2010 7:16 pm

Hello,

Suggest someone more senior (manager/director/whatever) get people to make a short-term decision and a long-term direction. To say "it doesn't work" and "we can't change the way it works" will not work well for anyone.

However; this will probably not move forward if only users and technicians participate.

Or the rather horrible choice can be made to hire somone full-time who will do nothing but monitor these jobs and manage the thruput.