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

[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.