Doubt regd Job submission thru REXX 
Author Message
 Doubt regd Job submission thru REXX

Hi,

Could anyone solve the following problem I am having:

I have some 2000 jobs to submit through my own TSO ID. I set up a JCL
which would submit the jobs sequentially one at a time, ie; the 2nd
job would be submitted only after the 1st job has run to completion
and so on. The JCL is as follows :

//TSOXXXXQ JOB (2121400), 'COPYIN', CLASS=Q, MSGCLASS=X, MSGLEVEL=
(1,1),
// TIME=1440, NOTIFY=TSOXXXX
//*
//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//PLIDUMP DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
 EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP285DP)' EXEC
 EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP300WP)' EXEC
 EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP410MP)' EXEC
        :
        :
        :
/*
//SYSIN DD DUMMY
//*

The above JCL is supposed to submit the jobs
IOP285DP,IOP300WP,IOP410MP and so on, sequentially one after the
other.TSOREPO.PDS.EXEC(SB1) is a REXX program which submits the jobs
given as argument. But when I submit the above JCL, all the jobs are
simultaneously submitted, so the queue is flooded with some 2000 jobs
instead of one at a time.

Also note that all these 2000 jobs have the same job card name ie;
TSOXXXXY.

Can anyone help me out with this problem?
Thanks in advance
Arun



Mon, 13 Dec 2004 01:24:39 GMT  
 Doubt regd Job submission thru REXX
Why not set the programs into seperate steps and check the return code to
continue to the next step

Chris


Quote:
> Hi,

> Could anyone solve the following problem I am having:

> I have some 2000 jobs to submit through my own TSO ID. I set up a JCL
> which would submit the jobs sequentially one at a time, ie; the 2nd
> job would be submitted only after the 1st job has run to completion
> and so on. The JCL is as follows :

> //TSOXXXXQ JOB (2121400), 'COPYIN', CLASS=Q, MSGCLASS=X, MSGLEVEL=
> (1,1),
> // TIME=1440, NOTIFY=TSOXXXX
> //*
> //STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
> //SYSPRINT DD SYSOUT=*
> //SYSTSPRT DD SYSOUT=*
> //PLIDUMP DD SYSOUT=*
> //SYSUDUMP DD SYSOUT=*
> //SYSTSIN DD *
>  EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP285DP)' EXEC
>  EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP300WP)' EXEC
>  EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP410MP)' EXEC
> :
> :
> :
> /*
> //SYSIN DD DUMMY
> //*

> The above JCL is supposed to submit the jobs
> IOP285DP,IOP300WP,IOP410MP and so on, sequentially one after the
> other.TSOREPO.PDS.EXEC(SB1) is a REXX program which submits the jobs
> given as argument. But when I submit the above JCL, all the jobs are
> simultaneously submitted, so the queue is flooded with some 2000 jobs
> instead of one at a time.

> Also note that all these 2000 jobs have the same job card name ie;
> TSOXXXXY.

> Can anyone help me out with this problem?
> Thanks in advance
> Arun



Mon, 13 Dec 2004 02:17:52 GMT  
 Doubt regd Job submission thru REXX
If they all have the same job card, then they >will< run sequentially.

Since you don't seem to be checking for return or completion codes, you are - in
effect - achieving what you set out to do.

Of course, your Operations Manager is probably not too happen about the drain on
that particular JES initiator.

Suggest you call your Command Center and let them know that you plan to do
this...

Larry Kahm



Mon, 13 Dec 2004 02:18:35 GMT  
 Doubt regd Job submission thru REXX


Quote:
>Hi,

>Could anyone solve the following problem I am having:

>I have some 2000 jobs to submit through my own TSO ID. I set up a JCL
>which would submit the jobs sequentially one at a time, ie; the 2nd
>job would be submitted only after the 1st job has run to completion
>and so on. The JCL is as follows :

>//TSOXXXXQ JOB (2121400), 'COPYIN', CLASS=Q, MSGCLASS=X, MSGLEVEL=
>(1,1),
>// TIME=1440, NOTIFY=TSOXXXX
>//*
>//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
>//SYSPRINT DD SYSOUT=*
>//SYSTSPRT DD SYSOUT=*
>//PLIDUMP DD SYSOUT=*
>//SYSUDUMP DD SYSOUT=*
>//SYSTSIN DD *
> EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP285DP)' EXEC
> EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP300WP)' EXEC
> EX 'TSOREPO.PDS.EXEC(SB1)' 'TSOREPO.ENDVWK.JCL(IOP410MP)' EXEC
>    :
>    :
>    :
>/*
>//SYSIN DD DUMMY
>//*

>The above JCL is supposed to submit the jobs
>IOP285DP,IOP300WP,IOP410MP and so on, sequentially one after the
>other.TSOREPO.PDS.EXEC(SB1) is a REXX program which submits the jobs
>given as argument. But when I submit the above JCL, all the jobs are
>simultaneously submitted, so the queue is flooded with some 2000 jobs
>instead of one at a time.

>Also note that all these 2000 jobs have the same job card name ie;
>TSOXXXXY.

>Can anyone help me out with this problem?
>Thanks in advance
>Arun

The submit process completes when the job has been received by JES.
Consequently, you will execute the next SYSTSIN statement before the
job even starts, let alone finishes.

You could modify SB1 to capture the job number of the job being
submitted and then invoke SDSF to determine if the job is on the
output queue.  SB1 would repeatedly ask this question until it was
true and then return so you could submit the next job.  However, this
TSO job would be competing for system resources and slowing everything
else down.

Another approach would be to do away with your central submitting job
and have each job submit its successor as a last step.  You can do
this with a simple IEBGENER step.

By giving all the jobs the same name, you have guaranteed that they
will execute single stream and in sequence.  It is true that you
submit them rapidly but jobs awaiting execution consume very little
resources.  Why is it important how they are submitted as opposed to
how they are executed?

<<Remove the del for email>>



Mon, 13 Dec 2004 10:45:56 GMT  
 Doubt regd Job submission thru REXX
If they all have the same job card, then they >will< run sequentially.
Since you don't seem to be checking for return or completion codes,
you are - in effect - achieving what you set out to do. Of course,
your Operations Manager is probably not too happen about the drain on
that particular JES initiator. Suggest you call your Command Center
and let them know that you plan to do this...  Larry Kahm

**************************************************************************
Thank you guys for your advice, but I still have one problem...

When I submit say 5 jobs, all of them show up in SDSF as follows:

-----------------------------------------------------------------------
JOBNAME  JobID          Owner    Prty Queue   C  Pos  SAff      ASys Status
TSOABCDY JOB05676 TSOABCD  6 EXECUTION  R       SYSX  SYSX      
TSOABCDY JOB05673 TSOABCD  6 EXECUTION  R       SYSX       DUP  
TSOABCDY JOB05675 TSOABCD  6 EXECUTION  R       SYSX       DUP  
TSOABCDY JOB05677 TSOABCD  6 EXECUTION  R       SYSX       DUP  
TSOABCDY JOB05686 TSOABCD  6 EXECUTION  R       SYSX       DUP  
-----------------------------------------------------------------------

So when I submit 2000 jobs thru the above program, all of them appear
in the SDSF immedialtely. So in effect I have 2000 jobs vying for the
single JES initiator which I am using for all the 2000 jobs. I do not
want this to happen. Since the above prog uses a rexx prog(SB1) to
submit these jobs, the rexx program submits a job and does not wait
for it to complete before going on to the next one. Is there any way
to make this happen, so that I have only one job in the SDSF queue at
any given time?

Thanks in advance
ARUN



Mon, 13 Dec 2004 11:24:44 GMT  
 Doubt regd Job submission thru REXX


Quote:
> Is there any way to make this happen, so that I have only one job in
> the SDSF queue at any given time?

yes, as people have said.

You either put a step at the end of each job which runs the submit
process for the next job [this is simple, easy to understand, and
unlikely to go wrong]

or, you run some external process which monitors job-end and submits the
next job [this is more complicated, and likely to consume a lot of cpu -
it's quite likely that if you do it badly your ops staff or systems
programmers will cancel it]

But WHY do this?   There's nothing wrong with having all the jobs in the
input queue.  It's what JES is designed to do.  Remember it is a QUEUE.
And if your jobs are in that queue then when one ends the next one will
start as soon as it reached the top of the queue, but if you submit a new
job then it will join the end of the queue and it will be a lot longer
till it gets to start.  

If you want more than one job to be able to run at a time, use more than
one jobname - then if you have - say - 3 jobnames, any three could run at
once (assuming enough initiators).  Of course your jobs might not be able
to run in parallel.

None of this has anything to do with rexx, though if you have to write a
set of jobs where each submits the next one a rexx exec will help create
the jobstreams, I suppose.

--
Jeremy C B Nicoll - my opinions are my own.



Mon, 13 Dec 2004 21:59:28 GMT  
 Doubt regd Job submission thru REXX
Thanks guys for your excellent advice. Four points:

1)      As I mentioned, my initial code did submit all the 2000 jobs with
the same job card and initiator simultaneously. This was unacceptable
to the operator who said that he did not want 2000 jobs flooding his
queues and so he cancelled the jobs. Also my friend said that 2000
jobs in the queue will eat up spool memory and this will prevent other
jobs from being submitted even if they have different job cards and
initiators. Is this true?

2)      So I had no other option other than submit one job at a time. I
modified the rexx program SB1 in the submitting jcl to do the
following:
        a)      get job's DSN thru argument
        b)      OUTWRAP into variable VAR1.
        c)      submit job
        d)      Get JOBNAME(JOBID) from VAR1.1
        e)      OUTWRAP into variable VAR2.
        f)      Poll status of JOBNAME(JOBID)
        G)      Search for 'EXEC' in VAR2.1
        f)      Keep polling status of job until u don't find the 'EXEC'& if u
find it, break out of loop.
        I know, this is a lousy programming logic and the submitting JCL will
be in execution for a day or so until all the jobs run, consuming
valuble CPU time.

3)      The idea suggested by Barry, where each job submits its successor
seems a great idea. But the problem is, all the 2000 jobs are
generated by some other job over which I have no modification rights.
To overcome this I came up with the following logic:

        SEQ_FILE1 : contains the names of all the jobs eg:
T.TEST.TESTJOBS(JOB1)

        REXX1:

        A) Read the first line in SEQ_FILE1 and get the first <job-name>
        B) Delete the first line in SEQ_FILE1.
        C) Copy all lines in <job-name> into a temporary member, say
T.TEMP.MEMBER(SUBJOB).
        D) Add a last IKJEFT01 step in T.TEMP.MEMBER(SUBJOB) to call REXX1.
        E) Submit T.TEMP.MEMBER(SUBJOB).

        The above logic will make a recursive loop and the programs get
submitted sequentially until all there are no more lines in
SEQ_FILE1.

4)      Is the above logic good? Will using IEBGENER make this simpler or
does it follow a totally diff logic? Can you explain your IEBGENER
logic to me Barry?

Thanks in advance,
Arun



Tue, 14 Dec 2004 11:42:52 GMT  
 Doubt regd Job submission thru REXX
OK, I've seen several responses to your original post and have read through your
latest explanation.

So here's my "killer" question - the one I just know I should >never< ask:  WHY
are you submitting 2000 batch jobs under your TSO user ID?

(Never mind the unstated questions:  Where is the output of these jobs going?
Who is going to look through the results? Does your TSO ID even have the rights
to access all of the files that are used in the batch jobs?  If your operator is
concerned about the abuse of the JES spool, is anyone in Storage Services
concerned about the requirements of the DASD pool?)

If you >really< need to submit 2000 batch jobs, contact your Operations
Scheduling department. Have them set up a test schedule - where all of the jobs
are single-threaded based on the predecessor's successful completion code.  At
least the results will be monitored (and officially sanctioned by your
organization).  Then, all of the Operations staff can supply the appropriate
resources to solve whatever it is you are trying to accomplish.

I think this really isn't a REXX issue...

Larry Kahm



Tue, 14 Dec 2004 20:48:09 GMT  
 Doubt regd Job submission thru REXX


Quote:
> Thanks guys for your excellent advice. Four points:
> 1) As I mentioned, my initial code did submit all the 2000 jobs with
> the same job card and initiator simultaneously. This was unacceptable
> to the operator who said that he did not want 2000 jobs flooding his
> queues and so he cancelled the jobs.

It's possibly up to your management to convince ops that the jobs are
necessary, assuming that they are necessary.  I also wonder about 2000
jobs - it's a hell of a lot.

Quote:
> Also my friend said that 2000 jobs in the queue will eat up spool
> memory and this will prevent other jobs from being submitted even if
> they have different job cards and initiators. Is this true?

Well all jobs take up space, of course.  20000 jobs will take up 2000
instances of the JES "slot" control block (whose name I can't remember)
and that might be a problem.  There are jes operator commands that would
show if that was a problem and indeed if the size of the jcl in each job
was a problem.  On the whole though I'd have thought this would not be a
problem in most sites.

Quote:
> f) Poll status of JOBNAME(JOBID)

If I were in OPS in your site I would cancel the TSI userid or program
doing the polling.  It's very likely that that process will waste more
cpu than the jobs will consume.

Quote:
> 3) The idea suggested by Barry, where each job submits its successor
> seems a great idea. But the problem is, all the 2000 jobs are
> generated by some other job over which I have no modification rights.

The trouble with this sort of statement is that it is taking you days to
find a way to run th jobs, and that being so it should be possibe to get
the jobs altered to make running them simpler.

Like someone else who posted I don't understand how you can have so many
jobs - especially if they have some sort of "production" status, having
to be run outwith the control of your production scheduling dept.

The sort of problem you have here really should have been discussed with
your own OPS, sysprogs etc.

IEBGENER

I've not seen "barry's" suggestion.  Possibly he suggested iebgenering
the jcl to a DD defined as sysout with INTRDR on it?  If that's so, it
isn't IEBENER that's significant.  Job submission (whether via SUBMIT or
something else) always results in jcl being written to an INTRDR.  That's
how it works.

--
Jeremy C B Nicoll - my opinions are my own.



Wed, 15 Dec 2004 05:58:16 GMT  
 Doubt regd Job submission thru REXX

Quote:

> OK, I've seen several responses to your original post and have read through your
> latest explanation.

> So here's my "killer" question - the one I just know I should >never< ask:  WHY
> are you submitting 2000 batch jobs under your TSO user ID?

To answer your first question Larry, all these jobs are refresh jobs.
At the beginning of each week, I have to run a dozen import jobs which
scan the endevor through its vendor provided interface and create
refresh jobs for all JCLs, cobol, copybooks, dclgens, cntlcards, etc.
The total number of refresh jobs i need to run amount to infact
atleast 6000!!!. JCL refreshes alone amount to around 2000. These jobs
update special DB2 tables. A web(Java) application uses some data
models to interpret these tables and any developer without any
knowledge of QUERYing can find out the elements involved in an
Application or system.

I was given this project only last week (the process I have stated
above where a program submits the job and keeps polling the status has
been process followed so far by the guy whoz been doing this before)

Special security and access permissions were given to my TSO ID, so I
wont be getting it cancelled :-)

Quote:
> (Never mind the unstated questions:  Where is the output of these jobs going?
> Who is going to look through the results? Does your TSO ID even have the rights
> to access all of the files that are used in the batch jobs?  If your operator is
> concerned about the abuse of the JES spool, is anyone in Storage Services
> concerned about the requirements of the DASD pool?)

> If you >really< need to submit 2000 batch jobs, contact your Operations
> Scheduling department. Have them set up a test schedule - where all of the jobs
> are single-threaded based on the predecessor's successful completion code.  At
> least the results will be monitored (and officially sanctioned by your
> organization).  Then, all of the Operations staff can supply the appropriate
> resources to solve whatever it is you are trying to accomplish.

> I think this really isn't a REXX issue...

> Larry Kahm



Wed, 15 Dec 2004 11:05:55 GMT  
 Doubt regd Job submission thru REXX
Thanks for the additional background information - it really helps.

So let me understand this:

A weekly job goes through your Endevor SCM to locate and list components that
have been modified or added.

That job creates a "refresh" job for each component to update some "special" DB2
data base.

After the DB2 tables are updated, application programmers can invoke a java
application using a browser to view the information about the components and
their relationships.

Arun, this sure sounds a lot like IBM's WebSphere Studio Asset Analyzer
(although it is probably a very early version).

And, if that's the case, you really should contact IBM for support - that's what
your license allows.

The process you describe may have been streamlined quite a bit because Version 2
Release 1 of WS SAA was released just this week.  For more information take a
look at http://www-3.ibm.com/software/ad/wsaa/.

If you can't get help fast enough, you - and your management - should set up a
meeting with your site's Operations group to discuss these requirements.  At the
least, they may be able to set up a special initiator for your weekly jobs; you
could continue to submit them single-threaded the way you do now.  There is a
command in SDSF that allows you to exclude items from the display, if they don't
want to see it.

I hope that helps!

(And as a personal plug, I will be writing an article about this product for a
future issue of Technical Support magazine.)

Larry Kahm

/ps/

I worked with IBM Global Services on a predecessor of WS SAA (known as the RA
tool) and built an interface to support Serena's Change Man SCM.  IIRC, if 600
COBOL programs were changed or added during a week, then at least 900 batch jobs
were submitted on Monday morning to perform some kind of analysis prior to
loading the data base.  At first, they were under someone's ID (probably mine).
Eventually the application was "productionized" and placed under OPC control.



Wed, 15 Dec 2004 19:54:50 GMT  
 Doubt regd Job submission thru REXX



Quote:
> > OK, I've seen several responses to your original post and have read
> > through your latest explanation.

> > So here's my "killer" question - the one I just know I should >never<
> > ask: WHY are you submitting 2000 batch jobs under your TSO user ID?
> To answer your first question Larry, all these jobs are refresh jobs.
> At the beginning of each week, I have to run a dozen import jobs which
> scan the endevor through its vendor provided interface and create
> refresh jobs for all JCLs, cobol, copybooks, dclgens, cntlcards, etc.

[snip]

Actually none of this answers why all these jobs have to be run by your
TSO id.  The whole process should be run in batch under a production
schedule, surely.  What happens if you don't come to work?

--
Jeremy C B Nicoll - my opinions are my own.



Thu, 16 Dec 2004 01:17:38 GMT  
 Doubt regd Job submission thru REXX


Quote:
>If they all have the same job card, then they >will< run
>sequentially.

No. Even if you know for a fact that he is running JES2, that is still
not a given.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Thu, 16 Dec 2004 09:44:09 GMT  
 Doubt regd Job submission thru REXX


Quote:
>Could anyone solve the following problem I am having:

1. Your question has nothing to do with REXX

2. Neither the JCL nor the data that you show do what you say.
   You call SB1 multiple times, but there is nothing to suggest that
   SB1 waits for job completion.

3. You show a call to REXX or CLIST code, but do not show the
   actual code. From what you posted I couldn't even tell whether
   SB1 actually posts anything.

You would be much better off asking in, e.g., IBM-MAIN, JES2-L. In
general, when you are dealing with multiple jobs with dependencies you
should be talking to your support staff about what sort of software is
available to automate things. If you are running JES3, look at DFC. If
you have scheduling software installed, get the jobs submitted through
that.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2, Team OS/2, Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Thu, 16 Dec 2004 09:53:34 GMT  
 Doubt regd Job submission thru REXX

Quote:
> Arun, this sure sounds a lot like IBM's WebSphere Studio Asset Analyzer
> (although it is probably a very early version).

You are right Larry, about what you stated above, but the product is
not Websphere SAA. The Web front application is Datashopper and
Repository is modelled on Platinum Repository model. I myself don't
know the specifics since I am new to this project, but I am learning
about it.

Anyway, thanks for the advise, I have lots of information from this
posting to find a way out of this messy problem.

Arun



Thu, 16 Dec 2004 15:21:29 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How do I iterate thru files in REXX

2. execute rexx scrpts thru telnetpm

3. How to access OS/2 Background thru REXX

4. VAST JOBS $ VAST JOBS $ VAST JOBS $ VAST JOBS $ VAST JOBS

5. Regd, Future of Ada...

6. Question regd Symbolics and Instreams

7. regd TCL_Main

8. need help regd fork in tcl.

9. JOB ADA JOB ADA JOB ADA JOB ADA

10. "VisualAge-Immediate Contract-Mutiple-MD-VA",md.jobs,va.jobs,dc.jobs

11. PL1 JOBS PL/I Jobs PL/1 JOBS

12. PL/I Jobs PL/1 Jobs PL1 Jobs

 

 
Powered by phpBB® Forum Software