VMS - How to pass parameters to to an executable through DCL script

[Sk Noorul Hassan]

Hi,

I have got one executable(i.e. run mc$img:xx.exe)which asks few parameter values during the execution. Now I want to automate the entire thing through a DCL script to run in a batch job every hour.

Please suggest.

[labadie_1]

Hello

Your script shoud begin with

$! get the name of the proc file
$ self = F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
$ subm/after="+01:00:00" 'self /que=xxx...
$ ! then run your .exe and pass the parameters

[Sk Noorul Hassan]

I mean, how to pass the parameteres to the executable inside a dcl script?

[Jan van den Ende]

Hassan,

that depends on HOW the exe expects he params!

But an educated guess:
_IF_ the exe reads from standard input (SYS$INPUT), then

(beware of line wrapping!)
.
.
$ define/user SYS$INPUT SYS$COMMAND ! equate the command stream to the inputdevice for the duration of ONE image
$ run mc$img:xx
1st param
2nd param
3rd param
.
.
$ ! (any line starting with $ ends inout, and is the next DCL command)

be aware that _NO_ value substitution is done during parameter reading! If that is needed, a temporary COM file needs to be generated & @-ed.
-- Or the image must be able to take in parameters from the command line, in which case more info about the source of it is needed.

hth

Proost.

Have one on me.

jpe

[Jan van den Ende]

Hassan,

one more thing.

To get the parameters INTO the batch job, add
/PARAMS=(1st,[2nd],[3rd,[...]]]]
to the SUBMIT command.
And if you use the param-per-line mechanism I gave before, you DEFINITELY need the temporary COM file mechanism!

Proost.

Have one on me.

jpe

[Jess Goodman]

Jan wrote:
>$ define/user SYS$INPUT SYS$COMMAND ! equate the command stream to the inputdevice for the duration of ONE image
>$ run mc$img:xx
>1st param
>2nd param
>3rd param

Hassan,

Jan mis-spoke. Do NOT use:
$ define/user SYS$INPUT SYS$COMMAND
in a batch file. If the program is reading input from standard input (SYS$INPUT on VMS) just use the lines that come after it.

Basically lines that begin with a $ character are interpreted by DCL, but if a program is run than any lines after the $ line that runs the program (not counting a - continuation line) are passed as input to the program. The next line that begins with a $ ends the program input (if the program tries to read more lines it gets end-of-file).

It's also possible that your program will parse its parameters from a command line. If so to use a command line you can do:

$ MCR mc$img:xx.exe param1 param2 param3

which works the same interactively or in a batch job.

[Jon Pinkley]

RE:"Please suggest"

Download

http://h71000.www7.hp.com/doc/731FINAL/DOCUMENTATION/PDF/OVMS_731_USERS.PDF

and at least skim chapters 13-16.

If you do programming in a compiled language, you should also grab the programming concepts documenttion:

http://h71000.www7.hp.com/doc/82FINAL/5841/aa-rnshd-te.PDF
http://h71000.www7.hp.com/doc/82final/5841/aa-pv67h-tk.PDF

If you are responsible for the system, you should know what is in the system manager's essentials:

ftp://ftp.hp.com/pub/openvms/doc/AA-PV5MJ-TK.PDF

and have the second volume on hand for reference.

http://h71000.www7.hp.com/doc/82FINAL/aa-pv5nj-tk/aa-pv5nj-tk.PDF

++++++++++++++++++++++

If you want more focused answers, please show us an example of what types of parameters the xx.exe is asking.

Normally, I think of parameters as something that is passed to the program without being prompted. For example the name of a user you want to see info about

$ show user system

That is relatively easy to do in a command procedure.

$! myshowuser.com
$! wrapper for show user
$! p1 parameter for user
$ show user 'p1' ! this substitues the first param passed to myshowuser.com
$ exit

This example is not very useful, since it adds no functionality, but it is just to demonstate a point.

Now the two following commands will do the
same thing:

$ @myshowuser system
$ show user system

However, you suggest that you really are referring to something the program is prompting the user for.

As Jan van den Ende stated, you can create an "answer file" that will be used as answers to the prompts the program generates.

However, be aware that it the questions can change based on the previous answers given, then that method will not work in the general case. It is essentially like running the program and then typing in all the answers into the typeahead buffer.

An example of what won't work: Suppose xx.exe asks for a quantity, and someone enters "j45". If the program was written with the expectation that there was a person entering the data, the appropriate action is to tell the user that "j45" isn't an acceptable answer for a quantity, and to reprompt the user for the correct answer.

If you are running from batch, you will need to make sure what is provided in the answer file is valid so that will not occur.

A harder problem is a program that asks different questions based on previous answers. If you can't predict the questions, you can't predict the correct response.

Is the mc$img:xx.exe a program written by someone in your company that you have the source code for? If so the program can be written in a way that it will accept command line parameters, which in general are much easier to deal with from DCL.

Jon

[Jan van den Ende]

Jess wrote

>>>
Jan mis-spoke. Do NOT use:
$ define/user SYS$INPUT SYS$COMMAND
in a batch file.
<<<

Jeah.
My first answer was perhaps written a little bit too hastily. I SAW the "automate", but overlooked the "in a batch job".

That definition applies when input is expected from the input stream, but is to be redirected to be taken from the highest level control device (which interactively is the terminal, and in batch is the primary command file)

So sorry, it will not happen again (until next time)

Proost.

Have one on me.

jpe

[GuentherF]

You have to do it via an intermediate script:

$ open/write temp temp.com
$ write temp "$ RUN myProgram"
$ write temp "param_1_value"
$ write temp "param_n_value"
$ close temp
$ @temp
$ delete temp.com;

/Guenther

[Richard J Maher]

Hi,

Also on offer: lib$get_foreign, and creating your own CLD file / DCL verbs.

Cheers Richard Maher

[Willem Grooters]

Depending how the program gets its parameters, it could be useful to define a 'foreighn command' to start the executable and pass parameters in the same line:

$ xx :== run mc$img:xx.exe
$ xx p1 p2 p3

When the parameters are derived from some system data or parameters passed to the procedure, these will be substituted provided you used the right syntax:

$ xx 'p1' 'p2' 'p3'

(if neither of these contain spaces, or lower case text that needs to be preserved lowercase. Otherwise encluse such a parameter in double quotes like this:

$ xx "''p1'" 'p2' 'p3'

if p1 is such a parameter)

[Jan van den Ende]

Re Willem:

>>>
$ xx :== run mc$img:xx.exe
$ xx p1 p2 p3
<<<

That will NOT work!
You will have to invoke MCR for this

$ xx :== MCR mc$img:xx

(or, the alternate syntax for the same)

$ xx :== $mc$img:xx

But mind, for this to function the xx source code must have command line handling, in a way that Richard Maher describes.
Which may well be the case, so it IS worth the try!

hth

Proost.

Have one on me.

jpe

[debu_17]

If the source code of the executable u have , can be edited, the robust method for getting the parametrs into it may be;

1. in dcl create a named file in the native directory of the executable.
2. write the parameters to the named file, may be a nn.txt or nn.dat file.
this could be thru a script, which asks for the parametrs using "dcl == inquire statement"
3. in the excutable read the named file nn.dat as the input parameter source, (include some parameter validation)
4. when the executable exits, ensure tht u delete the nn.dat file., else u will create
m versions of the file created for each run.

if u can give more details about the way ur executable ingests the params, it would help.

[Jon Pinkley]

RE:debu_17's recommendation of creating a parameter file.

I don't see any significant advantage to this over the creation of a temporary command file as has already been suggested.

Another issue is that as described, it seems that the executable will be looking for a fixed file name to be created in the directory that the executable exists in? Fixed file names cause problems with concurrent use. It would be better to just use a name like "PARAM_FILE" and have the command file define param_file with the file specification of the specific instance. And I would definitely not put the parameter file in a shared directory with world write access.

If you are going to modify the program, use lib$get_foreign, the CLI$ routines or if written in c, the argc, argv constructs to allow the parameters to be passed on the command line. This has many advantages over temporary files. It makes it much easier to pass information in, since DCL symbol substitution will work, you don't have to worry about temporary file name collision (so concurrency is no problem), file cleanup, protection, etc. etc.

And use "read/prompt" instead of "inquire" when prompting for input from DCL. In my opinion, the DCL INQUIRE command should never be used.

Jon

[Hein van den Heuvel]

The generated temp command or output file as outlined is probably the way to go.

But sometime feeding new commands in a pipe is a nice way to go, using SPAWN perhaps.
Or PERL.

Here is a silly example

------------ test.pl ----------
@disks = reverse sort grep /:/, qx(show device dk); # Just a silly way to get lines with devices

$cmd = "dfu"; # just an example

open CMD,"|$cmd" or die "Could not open pipe into $cmd\n$!";
for (@disks) {
$disk = (split)[0]; # grab the disk name from the line
print CMD "report $disk\n"; # feed into command.
sleep 5; # wait a while.
}
--------------------------

So the example just picks one line from a list of devices and feeds it into a DFU program once every 5 second.

But it could just as easily feed multiple lines, dynamically created from file or directory contents in a reporting tools every hour.

Of course such approach would keep a process alive, waiting for input.
A self-re-sumbitting batch job uses no resources while waiting.

Both methods have their uses.

Cheers,
Hein.

[Sk Noorul Hassan]

Hi all,

Thanks for your help.