info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Some sort of SLEEP function in REXX
249 views
Skip to first unread message
Bob Bridges
Aug 13, 2018, 12:54:19 PM8/13/18
to
I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
I can't write it up as one job, because they run on different LPARs.
I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
That's what I'm looking for, but if you think you see a better approach feel free.
---
Bob Bridges, cell 336 382-7313
robhb...@gmail.com
rbri...@InfoSecInc.com
/* No period of history has ever been great or ever can be that does not act on some sort of high, idealistic motives. Idealism in our time has been shoved aside, and we are paying the penalty for it. -from the "Dialogues of Alfred North Whitehead", 1944-01-13 */
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
I can't write it up as one job, because they run on different LPARs.
I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
That's what I'm looking for, but if you think you see a better approach feel free.
---
Bob Bridges, cell 336 382-7313
robhb...@gmail.com
rbri...@InfoSecInc.com
/* No period of history has ever been great or ever can be that does not act on some sort of high, idealistic motives. Idealism in our time has been shoved aside, and we are paying the penalty for it. -from the "Dialogues of Alfred North Whitehead", 1944-01-13 */
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
John McKown
Aug 13, 2018, 1:13:37 PM8/13/18
to
stdin.0=0
stdout.0=0
stderr.0=0
call bpxwunix("sleep 10s",stdin.,stdout.,stderr.)
REF:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/wunix.htm
or
/* REXX */
xx=syscalls('on')
if xx > 3 then do /* couldn't set up syscalls */
say "UNIX not available"
exit 16
end
seconds=10
address syscall "sleep (seconds)"
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx18.htm
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/slp.htm
>
> ---
> Bob Bridges, cell 336 382-7313
> robhb...@gmail.com
> rbri...@InfoSecInc.com
>
> /* No period of history has ever been great or ever can be that does not
> act on some sort of high, idealistic motives. Idealism in our time has
> been shoved aside, and we are paying the penalty for it. -from the
> "Dialogues of Alfred North Whitehead", 1944-01-13 */
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
> send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
>
Between infinite and short there is a big difference. -- G.H. Gonnet
Maranatha! <><
John McKown
Paul Gilmartin
Aug 13, 2018, 1:17:04 PM8/13/18
to
On 2018-08-13, at 10:53:55, Bob Bridges wrote:
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
Address SYSCALL sleep nnn /* Seconds */
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
"Not a good idea" is just a paraphrase of "NIH".
Can each job submit the next one via INTRDR?
Can every job end with an IEFBR14 COND=(0,LE) with a
DD DISP=OLD, all for the same data set (which needn't
even exist? This bogarts initiators but uses very few
CPU cycles.
-- gil
Bill Turner, WB4ALM
Aug 13, 2018, 1:23:22 PM8/13/18
to
any shared dasd? if so, just a common file that each LPAR would update.
If not, then have the LPAR specific job submit a second job that runs on
the "master LPAR" which can update a status file...
Or have the LPAR specific job transmit a datafile back to a "master"
location.
I used to do something like this 15 to 20 years ago, to verify "user
status" on each of 2 to 6 systems at each of 8 different physical locations.
When all files existed at the master location, a "combining" job was run
which also deleted the LPAR specfic files...
if the "master" location also has a job scheduling system, then it can
do some of the "hard work".
/s/ Bill Turner
If not, then have the LPAR specific job submit a second job that runs on
the "master LPAR" which can update a status file...
Or have the LPAR specific job transmit a datafile back to a "master"
location.
I used to do something like this 15 to 20 years ago, to verify "user
status" on each of 2 to 6 systems at each of 8 different physical locations.
When all files existed at the master location, a "combining" job was run
which also deleted the LPAR specfic files...
if the "master" location also has a job scheduling system, then it can
do some of the "hard work".
/s/ Bill Turner
Hamilton, Robert
Aug 13, 2018, 1:25:06 PM8/13/18
to
Or you could use System REXX, which also has a sleep function.
Run on one LPAR to submit the job and wait until it's finished, and then issue a System REXX operator command to run an exec on another LPAR, where you submit the job and wait for it to finish, and so forth. It can even be the same EXEC:
Something on LPAR kicks off the process with, say,
REXX01 TSSCZECH
TSSCZECH submits the job, waits for a while, checks that the job is completed, knows it's on LPAR 1, so it issues...
REXX02 TSSCZECH
Which submits the job, waits, knows it's on LPAR 2, issues...
REXX03 TSSCZECH
Which, knows what to do...
...
Finally, on LPAR 6, TSSCZECH knows there aren't any more LPARs, so it just exits gracefully.
Just another idea...
R;
Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
Confidentiality Notice: This electronic message transmission, including any attachment(s), may contain confidential, proprietary, or privileged information from CAS, a division of the American Chemical Society ("ACS"). If you have received this transmission in error, be advised that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited. Please destroy all copies of the message and contact the sender immediately by either replying to this message or calling 614-447-3600.
Run on one LPAR to submit the job and wait until it's finished, and then issue a System REXX operator command to run an exec on another LPAR, where you submit the job and wait for it to finish, and so forth. It can even be the same EXEC:
Something on LPAR kicks off the process with, say,
REXX01 TSSCZECH
TSSCZECH submits the job, waits for a while, checks that the job is completed, knows it's on LPAR 1, so it issues...
REXX02 TSSCZECH
Which submits the job, waits, knows it's on LPAR 2, issues...
REXX03 TSSCZECH
Which, knows what to do...
...
Finally, on LPAR 6, TSSCZECH knows there aren't any more LPARs, so it just exits gracefully.
Just another idea...
R;
Rob Hamilton
Infrastructure Engineer
Chemical Abstracts Service
Lizette Koehler
Aug 13, 2018, 1:29:46 PM8/13/18
to
If you are on JES2 and at z/OS V2.3 then there is a job scheduling feature in JES2. Not sure how it works, but might be helpful.
Second, check the CBTTAPE.ORG for scheduling processes. If you do not currently have a job scheduling product on your LPARs, then what you are doing will mostly work. By using a SLEEP function you are relying on the job to end when you expect it to end. There will be times when this will not be the case.
Is the TSS Database shared by all LPARs? Or is there a unique TSS DB for each LPAR? If unique, how does the current process degrade the response time to TSS?
Could you stagger the job submissions? Run one at 7am, one at 8am, one at 10am, one at noon and one at 2pm? Are there many changes to the TSS DB during the day? Do they all need to run at 7am?
Hope this helps
Lizette
Second, check the CBTTAPE.ORG for scheduling processes. If you do not currently have a job scheduling product on your LPARs, then what you are doing will mostly work. By using a SLEEP function you are relying on the job to end when you expect it to end. There will be times when this will not be the case.
Is the TSS Database shared by all LPARs? Or is there a unique TSS DB for each LPAR? If unique, how does the current process degrade the response time to TSS?
Could you stagger the job submissions? Run one at 7am, one at 8am, one at 10am, one at noon and one at 2pm? Are there many changes to the TSS DB during the day? Do they all need to run at 7am?
Hope this helps
Lizette
Seymour J Metz
Aug 13, 2018, 1:56:25 PM8/13/18
to
> "Not a good idea" is just a paraphrase of "NIH".
No. But it's not my dog.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Paul Gilmartin <PaulGB...@AIM.COM>
Sent: Monday, August 13, 2018 1:16 PM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] Some sort of SLEEP function in REXX
Seymour J Metz
Aug 13, 2018, 2:00:00 PM8/13/18
to
Can you have each job submit the next one?
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Bob Bridges <robhb...@gmail.com>
Sent: Monday, August 13, 2018 12:53 PM
To: TSO-...@vm.marist.edu
Subject: [TSO-REXX] Some sort of SLEEP function in REXX
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Bob Bridges <robhb...@gmail.com>
Sent: Monday, August 13, 2018 12:53 PM
To: TSO-...@vm.marist.edu
Subject: [TSO-REXX] Some sort of SLEEP function in REXX
Mickey Bee
Aug 13, 2018, 2:19:13 PM8/13/18
to
I have a job that hits 3 LPARS. In the JCL, I have 3 JOB cards, and each job
has a different /*ROUTE XEQ card to direct it to the appropriate LPAR. As
long as they are on the same physical machine, it runs like a charm.
Mickey
-----Original Message-----
From: Seymour J Metz
Sent: Monday, August 13, 2018 1:59 PM
To: TSO-...@VM.MARIST.EDU
has a different /*ROUTE XEQ card to direct it to the appropriate LPAR. As
long as they are on the same physical machine, it runs like a charm.
Mickey
-----Original Message-----
From: Seymour J Metz
Sent: Monday, August 13, 2018 1:59 PM
To: TSO-...@VM.MARIST.EDU
Seymour J Metz
Aug 13, 2018, 2:24:32 PM8/13/18
to
I thought that you wanted them to run one at a time.
Do you mean that 3 LPAR are in the same JESplex and have the same job name?
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Mickey Bee <mic...@COMCAST.NET>
Sent: Monday, August 13, 2018 2:19 PM
To: TSO-...@vm.marist.edu
Do you mean that 3 LPAR are in the same JESplex and have the same job name?
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Mickey Bee <mic...@COMCAST.NET>
Sent: Monday, August 13, 2018 2:19 PM
To: TSO-...@vm.marist.edu
Bernd Oppolzer
Aug 13, 2018, 6:06:51 PM8/13/18
to
I recently had a similar problem at my actual customer's site;
I wanted a VERY long running job to be controlled from outside;
it should do its work in small packages of contracts (it's an insurance
company), say 1000, and then wait for a certain time, so that the
CPU percentage will not be very high and the overall system thruput
will not suffer. The duration of the pauses was changed while the
job was running, depending on current load measurements. This worked
very good.
The program was written in PL/1, but PL/1 (as far as I saw) does not
have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
(less than 10 instructions), callable from PL/1 (and C etc.), which
implemented
the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
We completed the work in three days, the job ran (almost invisible) all day
long during day shift. It worked on almost 700.000 contracts.
Kind regards
Bernd
I wanted a VERY long running job to be controlled from outside;
it should do its work in small packages of contracts (it's an insurance
company), say 1000, and then wait for a certain time, so that the
CPU percentage will not be very high and the overall system thruput
will not suffer. The duration of the pauses was changed while the
job was running, depending on current load measurements. This worked
very good.
The program was written in PL/1, but PL/1 (as far as I saw) does not
have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
(less than 10 instructions), callable from PL/1 (and C etc.), which
implemented
the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
We completed the work in three days, the job ran (almost invisible) all day
long during day shift. It worked on almost 700.000 contracts.
Kind regards
Bernd
Paul Gilmartin
Aug 13, 2018, 6:13:38 PM8/13/18
to
On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>
> The program was written in PL/1, but PL/1 (as far as I saw) does not
> have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
> (less than 10 instructions), callable from PL/1 (and C etc.), which implemented
> the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
>
What about BPX1SLP?
>
> The program was written in PL/1, but PL/1 (as far as I saw) does not
> have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
> (less than 10 instructions), callable from PL/1 (and C etc.), which implemented
> the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
>
-- gil
Paul Gilmartin
Aug 13, 2018, 6:20:16 PM8/13/18
to
On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>
>
> I wanted a VERY long running job to be controlled from outside;
> it should do its work in small packages of contracts (it's an insurance
> company), say 1000, and then wait for a certain time, so that the
> CPU percentage will not be very high and the overall system thruput
> will not suffer. The duration of the pauses was changed while the
> job was running, depending on current load measurements. This worked
> very good.
>
Wouldn't it be best to adjust the dispatch priority of the job? CHAP? nice()?
> it should do its work in small packages of contracts (it's an insurance
> company), say 1000, and then wait for a certain time, so that the
> CPU percentage will not be very high and the overall system thruput
> will not suffer. The duration of the pauses was changed while the
> job was running, depending on current load measurements. This worked
> very good.
>
-- gil
Bernd Oppolzer
Aug 13, 2018, 6:24:37 PM8/13/18
to
Am 14.08.2018 um 00:13 schrieb Paul Gilmartin:
> On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>> The program was written in PL/1, but PL/1 (as far as I saw) does not
>> have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
>> (less than 10 instructions), callable from PL/1 (and C etc.), which implemented
>> the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
>>
> What about BPX1SLP?
>
> -- gil
>
I don't know this;
> On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>> The program was written in PL/1, but PL/1 (as far as I saw) does not
>> have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
>> (less than 10 instructions), callable from PL/1 (and C etc.), which implemented
>> the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
>>
> What about BPX1SLP?
>
> -- gil
>
does this require MVS-Unix?
My PL/1 programs are running as "classical" MVS batch jobs.
The PL/1 program used the C runtime to read data from a PDSE member
every time when the wait interval was over. From the PDSE member it read
the number of contracts left, the key where to start, the number of
contracts
to work on in the next work interval and the duration of the following
pause.
The number of contracts left and the key where to start were updated
at the end of the work interval.
Because the PDSE member was closed after reading and writing,
and because the C runtime - when specifying filenames on fopen() -
frees the dataset on fclose() etc., we could edit the member during
the pause and change - for example - the number of contracts for
the next work interval or the duration of the pause. This way it was
possible to control the behaviour of the job, while it was running.
Big fun :-)
Kind regards
Bernd
David W Noon
Aug 13, 2018, 6:29:22 PM8/13/18
to
On Tue, 14 Aug 2018 00:06:25 +0200, Bernd Oppolzer
(bernd.o...@T-ONLINE.DE) wrote about "Re: [TSO-REXX] Some sort of
SLEEP function in REXX" (in
<049878d0-3e54-1385...@t-online.de>):
[snip]
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david....@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
(bernd.o...@T-ONLINE.DE) wrote about "Re: [TSO-REXX] Some sort of
SLEEP function in REXX" (in
<049878d0-3e54-1385...@t-online.de>):
[snip]
> The program was written in PL/1, but PL/1 (as far as I saw) does not
> have a SLEEP function, too.
PL/I has the DELAY statement. It is a wrapper on STIMER WAIT.
> have a SLEEP function, too.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david....@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Bernd Oppolzer
Aug 13, 2018, 6:32:41 PM8/13/18
to
Am 14.08.2018 um 00:19 schrieb Paul Gilmartin:
> On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>> I wanted a VERY long running job to be controlled from outside;
>> it should do its work in small packages of contracts (it's an insurance
>> company), say 1000, and then wait for a certain time, so that the
>> CPU percentage will not be very high and the overall system thruput
>> will not suffer. The duration of the pauses was changed while the
>> job was running, depending on current load measurements. This worked
>> very good.
>>
> Wouldn't it be best to adjust the dispatch priority of the job? CHAP? nice()?
>
> -- gil
>
See other mail ...
> On 2018-08-13, at 16:06:25, Bernd Oppolzer wrote:
>> I wanted a VERY long running job to be controlled from outside;
>> it should do its work in small packages of contracts (it's an insurance
>> company), say 1000, and then wait for a certain time, so that the
>> CPU percentage will not be very high and the overall system thruput
>> will not suffer. The duration of the pauses was changed while the
>> job was running, depending on current load measurements. This worked
>> very good.
>>
> Wouldn't it be best to adjust the dispatch priority of the job? CHAP? nice()?
>
> -- gil
>
our method gave us much more control,
for example: we could let the job wait for 3 hours at a certain point in
time,
so that it didn't interfere with other jobs. After the 3 hours pause, it
restarted
and we then redefined the packages size and the pause interval (for the
night shift).
Part of the motivation was: it is not easy at our site to get an UNPLANNED
production job started, so it was necessary to do most of the work without
the need to submit many jobs. And: it was not possible to do the whole
work uncontrolled during day shift (too much load) or during night shift
(too long for one night shift). And we wanted to do it during day shift,
so that we could look at it.
Kind regards
Bernd
Bernd Oppolzer
Aug 13, 2018, 6:35:11 PM8/13/18
to
Oh, I must have missed this;
I only looked for BUILTIN functions or procedures :-(
not for statements ...
Anyway, the ASSEMBLER function only took me 10 minutes to write.
Kind regards
Bernd
Am 14.08.2018 um 00:29 schrieb David W Noon:
> On Tue, 14 Aug 2018 00:06:25 +0200, Bernd Oppolzer
> (bernd.o...@T-ONLINE.DE) wrote about "Re: [TSO-REXX] Some sort of
> SLEEP function in REXX" (in
> <049878d0-3e54-1385...@t-online.de>):
>
> [snip]
>> The program was written in PL/1, but PL/1 (as far as I saw) does not
>> have a SLEEP function, too.
> PL/I has the DELAY statement. It is a wrapper on STIMER WAIT.
I only looked for BUILTIN functions or procedures :-(
not for statements ...
Anyway, the ASSEMBLER function only took me 10 minutes to write.
Kind regards
Bernd
Am 14.08.2018 um 00:29 schrieb David W Noon:
> On Tue, 14 Aug 2018 00:06:25 +0200, Bernd Oppolzer
> (bernd.o...@T-ONLINE.DE) wrote about "Re: [TSO-REXX] Some sort of
> SLEEP function in REXX" (in
> <049878d0-3e54-1385...@t-online.de>):
>
> [snip]
>> The program was written in PL/1, but PL/1 (as far as I saw) does not
>> have a SLEEP function, too.
> PL/I has the DELAY statement. It is a wrapper on STIMER WAIT.
Paul Gilmartin
Aug 13, 2018, 6:41:40 PM8/13/18
to
On 2018-08-13, at 16:24:14, Bernd Oppolzer wrote:
>>>
>> What about BPX1SLP?
is lower thay you may expect, but sometimes higher than you wish.
David Noon appears to have the right answer.
> Because the PDSE member was closed after reading and writing,
> and because the C runtime - when specifying filenames on fopen() -
> frees the dataset on fclose() etc., we could edit the member during
> the pause and change - for example - the number of contracts for
> the next work interval or the duration of the pause. This way it was
> possible to control the behaviour of the job, while it was running.
>
ISPF Services provide member-level serialization, which sounds
appropriate for your need. But at the cost of dragging along the TSO TMP
and ISPF, and a major refracturing of your design.
-- gil
>>>
>> What about BPX1SLP?
>
> I don't know this;
> does this require MVS-Unix?
> My PL/1 programs are running as "classical" MVS batch jobs.
>
More likely to require LE than UNIX. The wall between "classical" and UNIX
> I don't know this;
> does this require MVS-Unix?
> My PL/1 programs are running as "classical" MVS batch jobs.
>
is lower thay you may expect, but sometimes higher than you wish.
David Noon appears to have the right answer.
> Because the PDSE member was closed after reading and writing,
> and because the C runtime - when specifying filenames on fopen() -
> frees the dataset on fclose() etc., we could edit the member during
> the pause and change - for example - the number of contracts for
> the next work interval or the duration of the pause. This way it was
> possible to control the behaviour of the job, while it was running.
>
appropriate for your need. But at the cost of dragging along the TSO TMP
and ISPF, and a major refracturing of your design.
-- gil
Bernd Oppolzer
Aug 13, 2018, 6:53:58 PM8/13/18
to
Am 14.08.2018 um 00:41 schrieb Paul Gilmartin:
>
>> Because the PDSE member was closed after reading and writing,
>> and because the C runtime - when specifying filenames on fopen() -
>> frees the dataset on fclose() etc., we could edit the member during
>> the pause and change - for example - the number of contracts for
>> the next work interval or the duration of the pause. This way it was
>> possible to control the behaviour of the job, while it was running.
>>
> ISPF Services provide member-level serialization, which sounds
> appropriate for your need. But at the cost of dragging along the TSO TMP
> and ISPF, and a major refracturing of your design.
>
> -- gil
>
This was in fact a one time job, and the design using the PDSE member
>
>> Because the PDSE member was closed after reading and writing,
>> and because the C runtime - when specifying filenames on fopen() -
>> frees the dataset on fclose() etc., we could edit the member during
>> the pause and change - for example - the number of contracts for
>> the next work interval or the duration of the pause. This way it was
>> possible to control the behaviour of the job, while it was running.
>>
> ISPF Services provide member-level serialization, which sounds
> appropriate for your need. But at the cost of dragging along the TSO TMP
> and ISPF, and a major refracturing of your design.
>
> -- gil
>
and the I/O functions of the C runtime is a little bit strange. With
PL/1 and
datasets known to JCL, this is not possible, because the datasets and
members
are ENQed during the whole lifetime of the job. Even C would not free the
dataset, if fopen using DD:xxxxxxxx parameters is used. But if you use C
fopen
and DSNs, C does some sort of DYNALLOC and uses another SYSxxxxx DDName
for every fopen.
If I've had more time, I would rather have written some sort of database
program,
where the control information is in a DB2 table. This is what we
normally do.
But in this case I tried to avoid this (creating DB2 tables needs
additional effort;
you have to specify the table in some design tools and then the admins have
to create the table for you ...).
In large companies "simple ways" to get the job done are often not allowed
or not possible ... at least not for "normal" developers.
Kind regards
Bernd
Rolf Drees
Aug 14, 2018, 2:17:45 AM8/14/18
to
Hello Bernd,
the SLEEP-function in PL/I is the DELAY-statement. For example:
'delay(1000)' let's the program sleep/wait for 1 second.
Kind regards
Rolf
Fiducia & GAD IT AG | www.fiduciagad.de
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Jens-Olaf Bartels, Martin Beyer,
Jörg Dreinhöfer, Birgit Frohnhoff, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann
the SLEEP-function in PL/I is the DELAY-statement. For example:
'delay(1000)' let's the program sleep/wait for 1 second.
Kind regards
Rolf
AG Frankfurt a. M. HRB 102381 | Sitz der Gesellschaft: Frankfurt a. M. | USt-IdNr. DE 143582320
Vorstand: Klaus-Peter Bruns (Vorsitzender), Jens-Olaf Bartels, Martin Beyer,
Jörg Dreinhöfer, Birgit Frohnhoff, Carsten Pfläging, Jörg Staff
Vorsitzender des Aufsichtsrats: Jürgen Brinkmann
Paul Gilmartin
Aug 14, 2018, 1:23:23 PM8/14/18
to
On 2018-08-13, at 16:53:43, Bernd Oppolzer wrote:
>
> This was in fact a one time job, and the design using the PDSE member
> and the I/O functions of the C runtime is a little bit strange. With PL/1 and
> datasets known to JCL, this is not possible, because the datasets and members
> are ENQed during the whole lifetime of the job. Even C would not free the
> dataset, if fopen using DD:xxxxxxxx parameters is used. But if you use C fopen
> and DSNs, C does some sort of DYNALLOC and uses another SYSxxxxx DDName
> for every fopen.
>
C and Rexx (and PL/1?) sorely need enhancements to use ISPF-style
>
> This was in fact a one time job, and the design using the PDSE member
> and the I/O functions of the C runtime is a little bit strange. With PL/1 and
> datasets known to JCL, this is not possible, because the datasets and members
> are ENQed during the whole lifetime of the job. Even C would not free the
> dataset, if fopen using DD:xxxxxxxx parameters is used. But if you use C fopen
> and DSNs, C does some sort of DYNALLOC and uses another SYSxxxxx DDName
> for every fopen.
>
member-level ENQs. FTP and NFS appear to do this very effectively.
Likewise, ISPF LMPUT should be enhanced to remove the requirement
for DISP=OLD when writing to a PDSE. PDSE performs its own,
better, serialization.
-- gil
Paul Gilmartin
Aug 15, 2018, 10:55:32 AM8/15/18
to
On 2018-08-13, at 11:13:11, John McKown wrote:
> On Mon, Aug 13, 2018 at 11:55 AM Bob Bridges wrote:
>
>> I did a little googling on this, and I found that when some newb asks
>> about a SLEEP command on the mainframe, everyone says "that's not a good
>> idea - why do you want to do it?" ...
>>
And yet, PL/I provides DELAY to do it.
> /* REXX */
> xx=syscalls('on')
> if xx > 3 then do /* couldn't set up syscalls */
> say "UNIX not available"
> exit 16
> end
> seconds=10
> address syscall "sleep (seconds)"
> ref:
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx18.htm
>
That "syscalls('on')" seems almost overkill. Does not RC (not RETVAL)
from "address SYSCALL 'sleep ...'" provide a "failure" indication
(perhaps RC=-3) that the command could not be issued?
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikja300/commnds.htm
-- gil
> On Mon, Aug 13, 2018 at 11:55 AM Bob Bridges wrote:
>
>> I did a little googling on this, and I found that when some newb asks
>> about a SLEEP command on the mainframe, everyone says "that's not a good
>>
And yet, PL/I provides DELAY to do it.
> /* REXX */
> xx=syscalls('on')
> if xx > 3 then do /* couldn't set up syscalls */
> say "UNIX not available"
> exit 16
> end
> seconds=10
> address syscall "sleep (seconds)"
> ref:
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx18.htm
>
from "address SYSCALL 'sleep ...'" provide a "failure" indication
(perhaps RC=-3) that the command could not be issued?
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikja300/commnds.htm
-- gil
Mickey Bee
Aug 15, 2018, 12:58:03 PM8/15/18
to
Yes
Mickey Bee
Aug 15, 2018, 1:02:16 PM8/15/18
to
and in Rexx, it is as follows
Call SYSCALLS('ON')
Address SYSCALL
"SLEEP" xxx /*where xxx is the number of seconds*/
Call SYSCALLS('OFF')
-----Original Message-----
From: Rolf Drees
Sent: Tuesday, August 14, 2018 2:17 AM
To: TSO-...@VM.MARIST.EDU
Call SYSCALLS('ON')
Address SYSCALL
"SLEEP" xxx /*where xxx is the number of seconds*/
Call SYSCALLS('OFF')
-----Original Message-----
From: Rolf Drees
Sent: Tuesday, August 14, 2018 2:17 AM
To: TSO-...@VM.MARIST.EDU
Paul Gilmartin
Aug 15, 2018, 3:11:16 PM8/15/18
to
On 2018-08-15, at 11:02:10, Mickey Bee wrote:
> and in Rexx, it is as follows
>
> Call SYSCALLS('ON')
> Address SYSCALL
> "SLEEP" xxx /*where xxx is the number of seconds*/
> Call SYSCALLS('OFF')
>
SYSCALLS('OFF') is not recommended. An expert says:
> and in Rexx, it is as follows
>
> Call SYSCALLS('ON')
> Address SYSCALL
> "SLEEP" xxx /*where xxx is the number of seconds*/
> Call SYSCALLS('OFF')
>
http://vm.marist.edu/htbin/wlvtype?MVS-OE.35369
From: William Schoen
Date: 2003 June 2 18:08:28 MDT
Subject: Re: SYSCALLS() Query?
I do not recommend using sycalls 'OFF'. It may clean up more than you want
yet not everything from syscalls 'ON'. ...
Do you know of any instance in which SYSCALLS('OFF') is beneficial?
-- gil
Bob Bridges
Aug 15, 2018, 3:28:49 PM8/15/18
to
Yeah, it's not where to put the data that's the problem. In fact we do have a HLQ that is shared on all LPARs, and that's where my routines put this data (whence the next routine fetches and combines it). The problem is that the processes must not run at the same time, even though they're on different LPARs. Someone else asked the Why? Question more directly later, so I'll answer it there.
Oh, wait, I see; you're thinking each job can fire off the next one, or maybe update a dataset that the master job can read (every 5 seconds, say) before triggering the next one. And come to think of it, I had occasion to write my first REXX process that communicates via IP; I could do it that way too.
The "master" LPAR, or at least the one I plan to run this from, is the sysprogs' sandbox; no scheduler there. But there are ideas here I might use, once I've tried out John McKown's suggested sleep functions. Thanks.
/* It is a good rule not to put too much confidence in experimental results until they have been confirmed by theory. -from XMITIP's Murphy list */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bill Turner, WB4ALM
Sent: Monday, August 13, 2018 13:23
any shared dasd? if so, just a common file that each LPAR would update.
If not, then have the LPAR specific job submit a second job that runs on
the "master LPAR" which can update a status file...
Or have the LPAR specific job transmit a datafile back to a "master"
location.
I used to do something like this 15 to 20 years ago, to verify "user
status" on each of 2 to 6 systems at each of 8 different physical locations.
When all files existed at the master location, a "combining" job was run
which also deleted the LPAR specfic files...
if the "master" location also has a job scheduling system, then it can
do some of the "hard work".
Oh, wait, I see; you're thinking each job can fire off the next one, or maybe update a dataset that the master job can read (every 5 seconds, say) before triggering the next one. And come to think of it, I had occasion to write my first REXX process that communicates via IP; I could do it that way too.
The "master" LPAR, or at least the one I plan to run this from, is the sysprogs' sandbox; no scheduler there. But there are ideas here I might use, once I've tried out John McKown's suggested sleep functions. Thanks.
/* It is a good rule not to put too much confidence in experimental results until they have been confirmed by theory. -from XMITIP's Murphy list */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bill Turner, WB4ALM
Sent: Monday, August 13, 2018 13:23
any shared dasd? if so, just a common file that each LPAR would update.
If not, then have the LPAR specific job submit a second job that runs on
the "master LPAR" which can update a status file...
Or have the LPAR specific job transmit a datafile back to a "master"
location.
I used to do something like this 15 to 20 years ago, to verify "user
status" on each of 2 to 6 systems at each of 8 different physical locations.
When all files existed at the master location, a "combining" job was run
which also deleted the LPAR specfic files...
if the "master" location also has a job scheduling system, then it can
do some of the "hard work".
--- On 08/13/2018 12:53 PM, Bob Bridges wrote:
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
> One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
>
> My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
>
> I can't write it up as one job, because they run on different LPARs.
>
> I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
>
> I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
>
> That's what I'm looking for, but if you think you see a better approach feel free.
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
> One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
>
> My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
>
> I can't write it up as one job, because they run on different LPARs.
>
> I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
>
> I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
>
> That's what I'm looking for, but if you think you see a better approach feel free.
Bob Bridges
Aug 15, 2018, 3:36:22 PM8/15/18
to
Each LPAR has its own TSS database, Lizette. The job causes problems when it runs on all six LPARs at once because the six LPARs are sharing just the one CPU, and since they're all talking to TSS they're all getting high priority. So six jobs each demanding lots of CPU cycles from one source - even though they're each getting info from a different database - are making it hard for anyone else to get its attention.
Or at least that result was reported to me by the sysprog; I inferred the part about each LPAR drawing from the same CPU. I'm not a systems guy myself (I came into security from the development side), so I may be describing it wrong, but it sounds reasonable to me.
/* Back in the old days, most families were close-knit. Grown children and their parents continued to live together, under the same roof, sometimes in the same small, crowded room, year in and year out, until they died, frequently by strangulation. -Dave Barry */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Lizette Koehler
Sent: Monday, August 13, 2018 13:30
If you are on JES2 and at z/OS V2.3 then there is a job scheduling feature in JES2. Not sure how it works, but might be helpful.
Second, check the CBTTAPE.ORG for scheduling processes. If you do not currently have a job scheduling product on your LPARs, then what you are doing will mostly work. By using a SLEEP function you are relying on the job to end when you expect it to end. There will be times when this will not be the case.
Is the TSS Database shared by all LPARs? Or is there a unique TSS DB for each LPAR? If unique, how does the current process degrade the response time to TSS?
Could you stagger the job submissions? Run one at 7am, one at 8am, one at 10am, one at noon and one at 2pm? Are there many changes to the TSS DB during the day? Do they all need to run at 7am?
Or at least that result was reported to me by the sysprog; I inferred the part about each LPAR drawing from the same CPU. I'm not a systems guy myself (I came into security from the development side), so I may be describing it wrong, but it sounds reasonable to me.
/* Back in the old days, most families were close-knit. Grown children and their parents continued to live together, under the same roof, sometimes in the same small, crowded room, year in and year out, until they died, frequently by strangulation. -Dave Barry */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Lizette Koehler
Sent: Monday, August 13, 2018 13:30
If you are on JES2 and at z/OS V2.3 then there is a job scheduling feature in JES2. Not sure how it works, but might be helpful.
Second, check the CBTTAPE.ORG for scheduling processes. If you do not currently have a job scheduling product on your LPARs, then what you are doing will mostly work. By using a SLEEP function you are relying on the job to end when you expect it to end. There will be times when this will not be the case.
Is the TSS Database shared by all LPARs? Or is there a unique TSS DB for each LPAR? If unique, how does the current process degrade the response time to TSS?
Could you stagger the job submissions? Run one at 7am, one at 8am, one at 10am, one at noon and one at 2pm? Are there many changes to the TSS DB during the day? Do they all need to run at 7am?
> -----Original Message-----
> From: Bob Bridges
> Sent: Monday, August 13, 2018 9:54 AM
>
> From: Bob Bridges
> Sent: Monday, August 13, 2018 9:54 AM
>
Bob Bridges
Aug 15, 2018, 3:42:02 PM8/15/18
to
No, you had it right, Shmuel; I just didn't spell out ~why~ the jobs must
run one at a time, and I think Mickey misread. Mickey, I did originally
have six jobs in one JCL member, each with its own /*ROUTE XEQ. It ran, but
what I didn't realize was that by running six TSS jobs at once I was slowing
down everyone else's response time every Monday morning.
From: Bob Bridges <robhb...@gmail.com>
run one at a time, and I think Mickey misread. Mickey, I did originally
have six jobs in one JCL member, each with its own /*ROUTE XEQ. It ran, but
what I didn't realize was that by running six TSS jobs at once I was slowing
down everyone else's response time every Monday morning.
/* It is a good rule not to put too much confidence in experimental results
until they have been confirmed by theory. -from XMITIP's Murphy list */
-----Original Message-----
until they have been confirmed by theory. -from XMITIP's Murphy list */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Seymour J Metz
Sent: Monday, August 13, 2018 14:24
I thought that you wanted them to run one at a time.
Do you mean that 3 LPAR are in the same JESplex and have the same job name?
Sent: Monday, August 13, 2018 14:24
I thought that you wanted them to run one at a time.
Do you mean that 3 LPAR are in the same JESplex and have the same job name?
________________________________________
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Mickey
Bee <mic...@COMCAST.NET>
Sent: Monday, August 13, 2018 2:19 PM
From: TSO REXX Discussion List <TSO-...@vm.marist.edu> on behalf of Mickey
Bee <mic...@COMCAST.NET>
Sent: Monday, August 13, 2018 2:19 PM
I have a job that hits 3 LPARS. In the JCL, I have 3 JOB cards, and each job
has a different /*ROUTE XEQ card to direct it to the appropriate LPAR. As
long as they are on the same physical machine, it runs like a charm.
________________________________________
has a different /*ROUTE XEQ card to direct it to the appropriate LPAR. As
long as they are on the same physical machine, it runs like a charm.
From: Bob Bridges <robhb...@gmail.com>
Sent: Monday, August 13, 2018 12:53 PM
Bob Bridges
Aug 15, 2018, 3:50:14 PM8/15/18
to
I've written in various assemblers (ok, two), one of them extensively. But I haven't yet written anything in HLASM; it's my next ambition, something I read up on occasionally as time allows. Not ready yet, though.
PL/1 is a wonderful language and for production utilities I'd resurrect my PL/1 skills in a heartbeat. Well, actually in a couple hundred-thousand heartbeats; it's been quite a few years, and I'd have to lay my hands on the compiler JCL and write a few simple programs first, as a refresher. But I was planning to do this in REXX, just because it's at hand.
You and a couple others here, though, have got me thinking: I wrote a socket handler in REXX a while ago, as part of a project that decided to go in a different direction. Maybe I start a batch master program that creates a socket, fires off the first job, and then waits listening at the socket; when the first job sends back a "completed" message to the socket, the master program fires off the next job, and so on, finally quitting when it's submitted the last one. As I recall, listening at the socket for incoming messages involves sleeping in its own way.
/* The cities are for money but the high-up hills are purely for the soul. -from _Galloway_ by Louis L'Amour */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bernd Oppolzer
Sent: Monday, August 13, 2018 18:06
I recently had a similar problem at my actual customer's site;
I wanted a VERY long running job to be controlled from outside;
it should do its work in small packages of contracts (it's an insurance
company), say 1000, and then wait for a certain time, so that the
CPU percentage will not be very high and the overall system thruput
will not suffer. The duration of the pauses was changed while the
job was running, depending on current load measurements. This worked
very good.
The program was written in PL/1, but PL/1 (as far as I saw) does not
have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
(less than 10 instructions), callable from PL/1 (and C etc.), which
implemented
the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
We completed the work in three days, the job ran (almost invisible) all day
long during day shift. It worked on almost 700.000 contracts.
PL/1 is a wonderful language and for production utilities I'd resurrect my PL/1 skills in a heartbeat. Well, actually in a couple hundred-thousand heartbeats; it's been quite a few years, and I'd have to lay my hands on the compiler JCL and write a few simple programs first, as a refresher. But I was planning to do this in REXX, just because it's at hand.
You and a couple others here, though, have got me thinking: I wrote a socket handler in REXX a while ago, as part of a project that decided to go in a different direction. Maybe I start a batch master program that creates a socket, fires off the first job, and then waits listening at the socket; when the first job sends back a "completed" message to the socket, the master program fires off the next job, and so on, finally quitting when it's submitted the last one. As I recall, listening at the socket for incoming messages involves sleeping in its own way.
/* The cities are for money but the high-up hills are purely for the soul. -from _Galloway_ by Louis L'Amour */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bernd Oppolzer
Sent: Monday, August 13, 2018 18:06
I recently had a similar problem at my actual customer's site;
I wanted a VERY long running job to be controlled from outside;
it should do its work in small packages of contracts (it's an insurance
company), say 1000, and then wait for a certain time, so that the
CPU percentage will not be very high and the overall system thruput
will not suffer. The duration of the pauses was changed while the
job was running, depending on current load measurements. This worked
very good.
The program was written in PL/1, but PL/1 (as far as I saw) does not
have a SLEEP function, too. So I wrote a very small ASSEMBLER subroutine
(less than 10 instructions), callable from PL/1 (and C etc.), which
implemented
the SLEEP function using STIMER WAIT (see MVS System Services, STIMER).
We completed the work in three days, the job ran (almost invisible) all day
long during day shift. It worked on almost 700.000 contracts.
--- Am 13.08.2018 um 18:53 schrieb Bob Bridges:
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
> One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
>
> My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
>
> I can't write it up as one job, because they run on different LPARs.
>
> I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
>
> I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
>
> That's what I'm looking for, but if you think you see a better approach feel free.
> I did a little googling on this, and I found that when some newb asks about a SLEEP command on the mainframe, everyone says "that's not a good idea - why do you want to do it?" and the conversation branches out from there and never gets back to the actual question. So I'm going to start by explaining the background, what I want to accomplish. That's the boring way, I realize; I'm sorry.
>
> One of my CA-TSS clients runs six LPARs. Every Monday I make a list of the IDs on each LPAR, and then combine the six lists into one for easy reference; that way no one has to log on to LPAR X to look up an ID there.
>
> My first step every Monday morning used to be to submit a JCL member that is actually six jobs; each one is routed to a different LPAR, where it asks TSS for a list of IDs. But TSS gets a high priority, and to have this job running on all six LPARs at once seriously hurt response time. My new process is to submit each of six jobs one at a time, wait until it's finished, submit the next one, wait some more... So I'd rather have an automated process to run those six jobs one at a time.
>
> I can't write it up as one job, because they run on different LPARs.
>
> I can't put it on the job scheduler, because not all the LPARs have a job scheduler.
>
> I'm pretty sure I ~can~ write a batch REXX that submits the collection job on LPAR 1, watches for it to complete, spawns the next job, and so on. But the only way I know how to do that is to use the TIME(E) function: Check to see whether the job is complete, if not wait another 2500 milliseconds, check again... For that I'm not really pausing, right? I mean, my job is still executing and using up CPU cycles. Isn't there some way to tell the system that it should put my job aside for <n> seconds, so I'm not wasting its attention?
>
> That's what I'm looking for, but if you think you see a better approach feel free.
Bob Bridges
Aug 15, 2018, 3:55:59 PM8/15/18
to
Thanks, John, I'll definitely check those out.
/* Beware of any Christian leader who does not walk with a limp. -Bob Mumford */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of John McKown
Sent: Monday, August 13, 2018 13:13
/* REXX */
stdin.0=0
stdout.0=0
stderr.0=0
call bpxwunix("sleep 10s",stdin.,stdout.,stderr.)
REF:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/wunix.htm
or
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/slp.htm
/* Beware of any Christian leader who does not walk with a limp. -Bob Mumford */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of John McKown
Sent: Monday, August 13, 2018 13:13
/* REXX */
stdin.0=0
stdout.0=0
stderr.0=0
call bpxwunix("sleep 10s",stdin.,stdout.,stderr.)
REF:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/wunix.htm
or
/* REXX */
xx=syscalls('on')
if xx > 3 then do /* couldn't set up syscalls */
say "UNIX not available"
exit 16
end
seconds=10
address syscall "sleep (seconds)"
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx18.htm
ref:
xx=syscalls('on')
if xx > 3 then do /* couldn't set up syscalls */
say "UNIX not available"
exit 16
end
seconds=10
address syscall "sleep (seconds)"
ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/bpx1rx18.htm
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb600/slp.htm
Bob Bridges
Aug 15, 2018, 4:00:22 PM8/15/18
to
I was never an operator so I'm chary about issuing operator commands; I'm afraid of botching something up. That's probably unnecessary; both my current clients regard the TSS admin (that's me) as equivalent to a sysprog, issue me sysprog access and assume I have sysprog knowledge and skills.
But I don't, so I approach the whole area with caution.
/* For Sale: Parachute. Only used once, never opened, small stain. */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Hamilton, Robert
Sent: Monday, August 13, 2018 13:25
Or you could use System REXX, which also has a sleep function.
Run on one LPAR to submit the job and wait until it's finished, and then issue a System REXX operator command to run an exec on another LPAR, where you submit the job and wait for it to finish, and so forth. It can even be the same EXEC:
Something on LPAR kicks off the process with, say,
REXX01 TSSCZECH
TSSCZECH submits the job, waits for a while, checks that the job is completed, knows it's on LPAR 1, so it issues...
REXX02 TSSCZECH
Which submits the job, waits, knows it's on LPAR 2, issues...
REXX03 TSSCZECH
Which, knows what to do...
...
Finally, on LPAR 6, TSSCZECH knows there aren't any more LPARs, so it just exits gracefully.
Just another idea...
But I don't, so I approach the whole area with caution.
/* For Sale: Parachute. Only used once, never opened, small stain. */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Hamilton, Robert
Sent: Monday, August 13, 2018 13:25
Or you could use System REXX, which also has a sleep function.
Run on one LPAR to submit the job and wait until it's finished, and then issue a System REXX operator command to run an exec on another LPAR, where you submit the job and wait for it to finish, and so forth. It can even be the same EXEC:
Something on LPAR kicks off the process with, say,
REXX01 TSSCZECH
TSSCZECH submits the job, waits for a while, checks that the job is completed, knows it's on LPAR 1, so it issues...
REXX02 TSSCZECH
Which submits the job, waits, knows it's on LPAR 2, issues...
REXX03 TSSCZECH
Which, knows what to do...
...
Finally, on LPAR 6, TSSCZECH knows there aren't any more LPARs, so it just exits gracefully.
Just another idea...
0 new messages