And ..... Here is the answer -
Many thanks to Patrick Fourny
Pasted from MPE/iX 5.5 Express Communicator 3
PAUSE Enhancement
Syntax
PAUSE [num_seconds] [[;JOB=]jobid] [[;INTERVAL=]interval_secs]
[;EXIST | WAIT | NOTEXIST]
The PAUSE command allows the current task to be suspended or "sleep" for
a specified number of seconds. PAUSE now supports sleeping until one or
more jobs reach a certain state. For example, a script can pause while
selected jobs or sessions are executing (EXIST). Or, a job can sleep
while another job is suspended or waiting (WAIT), and as soon as the job
starts executing or terminates the pause completes. A session can pause
while no jobs exist (NOTEXIST) and wake up as soon as the first job is
launched.
In its simplest form, the PAUSE command sleeps for num_seconds, or less
if Break is pressed. In this simple case no jobid is specified and all
other command arguments are ignored. If the jobid parameter is
specified, then interval_secs and the remaining command parameters have
meaning. When jobid is supplied, PAUSE typically sleeps until the jobs
or sessions matching jobid have terminated.
Options.
EXIST (default) means to pause while all jobs and sessions matching
jobid exist. These jobs can be scheduled, waiting,
executing, etc.; but, as long as the system's global job
table (JMAT) contains an entry for any of the selected jobs
and sessions, the PAUSE command will continue to sleep.
WAIT means to pause while the selected job or jobs are waiting.
As soon as all the matching jobs are no longer waiting
(meaning all the job states are no longer "introduced,"
"waiting," or "scheduled") the pause ends. The life cycle of
a job is typically:
[sched or waiting->] intro-> initializing-> exec-> [susp->
exec->] terminate.
Waiting jobs are considered all job states left of and
excluding "initializing." Non-waiting jobs are all jobs right
of and including "initializing."
NOTEXIST means to pause while the matching job or jobs do not exist.
As soon as any jobs matching jobid exist (in any state) the
pause completes. PAUSE might miss finding very fast jobs.
This is particularly true for a match on a single job/session
number. A more practical use might be:
PAUSE job=@J;notexist
which means to sleep while no jobs exist. As soon as the
first job is streamed the above pause stops.
Collectively EXIST, WAIT and NOTEXIST are referred to as the
"while_state," since PAUSE sleeps "while" the specified state condition
is true.
Parameters
num_ if num_seconds is specified without jobid, PAUSE sleeps for
seconds that many seconds, or until the process issuing the pause is
interrupted by the break signal.
If jobid is also supplied then num_seconds has a different
meaning. In this case it indicates the maximum duration for
the PAUSE command, such that PAUSE should continue while the
selected jobs are in their "while_state" or when num_seconds
has expired, WHICHEVER IS SHORTEST. Thus, num_seconds
represents the maximum length of the pause. If PAUSE
completes but the one or more jobs are still in their "while
state" a CIWARN is reported. Note: to pause while a job is
in its "while_state" or until num_seconds has expired,
whichever is LONGEST, execute the following two commands:
PAUSE x
PAUSE job=y ;z
If after X seconds job Y is still in state Z, then the second
PAUSE continues while state Z applies. On the other hand, if
after X seconds job Y is not in state Z then the pause is
complete.
jobid can be one of:
[#]Jnnn, [#]Snnn, [jobname,]user.acct, @, @J, @S.
Note if jobname is included then the jobid must be quoted
since the comma is a command token delimiter.
If the JOB= parameter is specified then PAUSE sleeps while
jobid is in its "while_state." jobid can be an executing,
waiting, scheduled job, or a session. jobid can also name
many jobs or sessions. Wildcarding is supported, and a
non-wildcarded "[jname,]user.acct" can match several jobs or
sessions. The job name can be "," or "@," to match all jobs
or sessions without a job name. When more than one job or
session matches jobid, PAUSE sleeps while all matching jobs
are in their "while_state." If the job executing PAUSE
matches jobid it will not be selected.
interval_ if specified, PAUSE sleeps for this many seconds between
secs attempts to see if jobid is still in its "while_state."
Otherwise, PAUSE sleeps a variable amount of seconds
depending on the job state and the number of previous times a
particular job has been polled. This computed method favors
executing jobs that terminate quickly.
Examples
The following pauses while job #J20 is in any of the JOB states such as
INTRO, SCHED, EXEC, etc. until the job terminates:
:PAUSE JOB=#J20;EXIST
The following pauses while job #J24 is in INTRO, WAIT, or SCHED state.
Pause ends when #J24 is no longer in any of these states.
:PAUSE JOB=#J24;WAIT
Seamus Browne a écrit dans le message <[log in to unmask]>...
>I have a job (JMAINJOB)
>that is streamed every weekday night AT =23:00.
>
>This brings down the network to log everyone off
>Then does a STORE @[log in to unmask]@
>
>Brings up the network services JINETD, FTP, ODBC.
>Then runs a separate job (JWEEKDAY)
>to run several other jobs (say JOB1, JOB2 etc.)
>
>and sets itself to run again AT=23:00.
>That works fine.
>
>Without going into too much detail ...
>I would like to specify in the JWEEKDAY job that
>JOB1 should terminate before JOB2 be allowed to start
>and son on for JOB3 and JOB4 etc.
>
>These are the options I have considered:
>1. Figure out how long JOB1 takes to run and put an AT on
>on JOB2 making it not start till the JOB1 has finished.
>I don't like this option because the duration of any job is not really
fixed
>and will vary with the size of my database.
>
>2. Daisy-chain all the jobs from one to another so that
>JOB1 would finish by streaming JOB2.
>JOB2 would finish by streamingJOB3 etc ...
>Don't like that either because
>a) I would like to be able to add or delete jobs to the JWEEKDAY
>job without having to care about which order they are in and
>b) if any job in the chain flushed for any reason,
>the remaining jobs in the chain would be lost.
>
>3. Last option was to set the JOBLIMIT to 4 so as to allow
> 1. Network services (JINETD)
> 2. FTP - and -
> 3. ODBC
>to run with just one other job.
>Thus JOB2 could not start unless JOB1 had finished etc.
>Sounds OK but I can't get the LIMIT command to work inside a job.
>I get error messages telling me to use the ALLOW command.
>When I modify the JOB card to MANAGER.SYS and
>insert the ALLOW command I get more messages
>saying I will need to ALLOW the ALLOW command.
>
>
>So my questions are :
>1. Which is the best option?
>2. If it is the LIMIT option then how do I allow it in a job?
>3. Does anyone have any other suggestions?
>
>Thanks in advance.
>Seamus BROWNE
>[log in to unmask]
>
>
>
>
>
>
>
|
