Batch Job Prompts - Novice Question

[Tony Marron]

Hi,

When submitting a batch job that includes a call to another DCL routine that needs operator responses (i.e. Y or N to proceed)the batch job hangs as it doedn't recognise the input I have built into the routine.

I know that there is a command that will let me do this but I cannot find it anywhere in help or my user guide.

Thanks and apologies for asking 'eediot' questions.

[Hoff]

Batch jobs do not generally prompt for input, they often collect the required information as part of the initial processing (some DCL runs, collects the requisite data, and passes it in via /PARAMETER or via file, and then issues the SUBMIT), but you can choose to use the REQUEST /REPLY command to gain (limited) input from system operators.

A system operator (REPLY /ENABLE, et al) can then use REPLY /TO=n to complete the prompt operation (or REPLY /ABORT), where n is the number of the request that was generated by REQUEST /REPLY

The underlying sys$sndopr system service mechanism has additional features (it can get a string back from the operator; see what BACKUP does in this area by using that), but these strings have not been propagated up to DCL and passed back via symbol AFAIK. (A little compiled code could make your own REQUEST /REPLY image using sys$sndopr and lib$set_symbol; that wouldn't be more than an hour of coding and testing time at the outside.)

[Hein van den Heuvel]

Hello Tony,

The answer depends a little on the method used to trigger the response and whether you want a live response or not.

Hoff addressed the case of a real answer being needed.

I suspect you are dealing with a simple setup where a fixed "yes" is all that is needed. For that you might just be able to follow the call to nested procure by a data line. You might need to diddle th logical names for SYS$INPUT.
Here is something silly which works for me...


$ create outer_test.com
$ @inner_test.com
yessirreee
$ exit
^Z
$ create inner_test.com
$ inquire answer "Yes or no"
$ write sys$output "The answer was: ", answer
$exit
^Z
$ subm outer_test.com
Job OUTER_TEST (queue SYS$BATCH, entry 71) started on SYS$BATCH
$ typ outer_test.log

The answer was: YESSIRREEE
HEIN job terminated at 16-FEB-2008 10:29:04.37

Hein.

[Robert Gezelter]

Tony,

Hoff and Hein have answered different questions. From my perspective, on re-reading your posting, I am not sure which reflects your situation.

If you are asking for the operator to intervene, as in "Please mount the correct tape", then Hoff 's answer is correct.

If you are trying to get a series of inputs from the command file, I agree with Hein, except that my preference is to generate a temporary data file during an interactive setup script, and then pass the name of the file as one of the parameters on the SUBMIT command (e.g., SUBMIT/PARAM=("") ).

Then, I can simply OPEN/READ on the temporary file and use READ statements to process it.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Clarifying my earlier reply, the two paths are via File or via SUBMIT /PARAMETER from a "wrapping" procedure that starts this off.

Or via OPCOM and a system operator:

REQUEST /REPLY "Do you want to play a game?"

and then a REPLY /TO or a REPLY /ABORT from an operator.

The other option is via shared logical name, or via some procedure or tool that creates a file after the fact, and for which the procedure polls, and waits for. Or you could submit the second-level job or task into a hibernation state or into a process suspension, and then release it, or delete it.

Based on the "should I proceed?" interpretation, the REQUEST is probably the easiest path forward.

If you choose the REQUEST /REPLY path, do ensure you test for the case when no operator is enabled when you issue the REQUEST /REPLY, as you'll get a status back from that indicating no operators are around. (The continue and the abort also return $STATUS values here.) This no-operators case is a common failure, but it's one that's not necessarily immediately obvious; it's a case that might not show up in basic testing.

[Doug Phillips]

If the batch mode response and action you want is constant, you could make the prompt conditional in the "called" DCL routine" using the f$mode lexical.

Look at how f$mode is used in some of the .com files in sys$startup:

$ search sys$startup:*.com f$mode

If the response is variable, then Hoff, Hein and Robert have given you some great answers.

[Doug Phillips]

Sorry, I just couldn't resist posting this as an example of how to unix-ify a simple DCL command, from TCPIP$STARTUP.COM

$ if $mode().eqs.$edit("interactive","upcase")

or am I the only one who thinks that's funny?

[Jon Pinkley]

Tony,

Can you show us what you are doing and what isn't working? I.e. can you create a simple reproducer? Otherwise we are just guessing what you mean by "operator responses" and how those operator responses are being accepted.

Jon

[Hein van den Heuvel]

Doug,

>> $ if $mode().eqs.$edit("interactive","upcase")
>> or am I the only one who thinks that's funny?

Good catch! Made me smile. Totally sick.
The other way around would only be silly:

$ if "INTERACTIVE".eqs.f$edit(f$mode(),"upcase")


Tony,

Do you have control over the called routine? Can you change it? If you can, then indeed it would be better to teach it how not to ask instead of learning how to answer.
Tools for that would eb the F$MODE() suggested, and testing for the existing of a (global) application symbol or logical:
$ IF "".eqs.F$TYPE(your_globlal)
$ THEN ... use it
$ ELSE ... INQUIRE (or better: READ/PROMPT)
Replace F$TYPE by F$TRNLNM for logicals.

Cheers,
Hein.

[Hoff]

Also check some of the *.TEMPLATE files, as that's where I'd tweaked some of the DCL structures. (The *.COM files carry over when upgrading; they're not modified.) sys$startup:sylogin.template uses "$ Goto MODE_'F$MODE()", which is a slightly different way to deal with this processing than the "$ if $mode() .eqs. f$edit("interactive", "upcase")" chuckle.