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