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.

[Tony Marron]

Hi Folks,

Thanks for all the responses - I got a lot more knowledge out of that......

Here is an example of the code from a batch job that call a DCL 'MM$LOAD:LOAD' routine that requires responses. I have commented out the prompts from the script :-


$ @mm$load:load
$! SCHEMA?
mandb
$! VERSION (Vn.n)?
11.4
$! AREA?
0
$! DATABASE DEVICE AND DIRECTORY?
dra2:[manman.mandb100]
$! FILENAME TO LOAD FROM?
mm$load:man0x0unl.dat
$!

Hope that helps clarify what we are trying to do - I'll try a few of the suggestions now.

Tony.

[The Brit]

Looking at this, my first inclination would be to modify the batch job to be;

$ @mm$load:load
mandb
11.4
0
dra2:[manman.mandb100]
mm$load:man0x0unl.dat
$!

Tell me that you tried this!

Dave

(and for that matter, any other options you tried)

[Jan van den Ende]

Tony,

$ SUBMIT mm$load:load -
/Params=("mandb","11.4","0","dra2:[manman.mandb100]","mm$load:man0x0unl.dat")

... and modify LOAD.COM such, that if P1 through P5 are ,nes, "", then do NOT ask that question, but inset the valu.

PS. As an aside: you abstracted mm$load to be wherever the logical name points.
_DO_ put in the effort to do similar for [manman.mandb100].

If you EVER upgrade you disk subsystem (or move to another computer), changing a few LNMs is SOOOO much easier and leass error-prone than finding and replacing EVERY disk reference!

hth

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Tony,

You still did not tell us how MM$LOAD.COM obtains the input.
READ or INQUIRE?
SYS$INPUT or SYS$COMMAND?

The solution I mentioned earlier, and which was essentially repeated by the Brit, works in batch but does not work both interactively as well as in batch.

Maybe I'm having a bad day and overlooking something simple but it is actually tricky to feed an inner command file data provided by the outter.... interactively.

The thing is that normally a such inner script would read the data from the command file itself, not from 'one level up'.

I ended up needing a pipe to do this interactively
------ test.com ----
$create tmp.tmp
yessirreee
aap
noot
mies
teun
$!does not work: $ pipe @inner < tmp.tmp
$!works
$pipe type tmp.tmp | @inner
$delete tmp.tmp.*
$ exit




$! ------ inner.com --------
$ show logical sys$input
$ show logical sys$command
$ old = ""
$loop:
$ inquire answer "answers"
$ ! yikes
$ write sys$output "The answer was: ", answer
$ if answer.eqs.old then exit 40
$ old = answer
$ goto loop
$done:
$exit '$status

$ type outer_pipe.log
:
"SYS$INPUT" = "_EISNER$DRA3:" (LNM$PROCESS_TABLE)
"SYS$COMMAND" = "_EISNER$MPA682:" (LNM$PROCESS_TABLE)
The answer was: YESSIRREEE
The answer was: AAP
The answer was: NOOT
The answer was: MIES
The answer was: TEUN
The answer was:
The answer was:
%SYSTEM-W-ABORT, abort
HEIN job terminated at 18-FEB-2008 14:16:58.80

This will work fine for an exact match of input data lines and inquiry commands, but here in the loop it shows something I find odd. At the end of the data, there is no EOF raised, just a blank lined returned.
This seems broken to me (Alpha 8.3).


Here is the reason I asked for the exact input method. If I make a seemingly trivial change in the inner.com from "inquery" to "read/prompt sys$input" and try we get:


$! ---- inner.com with read instead of inquire ----
$ show logical sys$input
$ show logical sys$command
$ old = ""
$loop:
$ read sys$input /prompt="answers" answer
$ ! yikes
$ write sys$output "The answer was: ", answer
$ if answer.eqs.old then exit 40
$ old = answer
$ goto loop
$done:
$exit '$status

$ typ outer.log
:
"SYS$INPUT" = "_EISNER$DRA3:" (LNM$PROCESS_TABLE)
"SYS$COMMAND" = "_EISNER$DRA3:" (LNM$PROCESS_TABLE)
The answer was: $ ! yikes
The answer was: $ ! yikes
%SYSTEM-W-ABORT, abort

Now change the sys$input to sys$command, and the result becomes:

The answer was: mies
The answer was: teun
The answer was: $exit
%RMS-E-EOF, end of file detected

So I got the data, and I got the EOF, but I also got a line starting with $. We (me!) would hope that any $ line would terminate the data lines (unless $DECK/DOLLARS is in effect.)

Hope this did not confuse too much!

Enjoy!
Hein.