Copyright 1993-2016 by Kevin G. Barkes

All rights reserved. This article may be duplicated or
redistributed provided no alterations of any kind are
made to this file.

This edition of DCL Dialogue is sponsored by Networking
Dynamics, developers and marketers of productivity software
for OpenVMS systems. Contact our website
www.networkingdynamics.com to download free demos of
our software and see how you will save time, money and
raise productivity! Be sure to mention DCL Dialogue!

DCL DIALOGUE
April, 1993

No Fooling: Compiled DCL, uDCL for MS-DOS
              

By Kevin G. Barkes

Considering the month, I guess I should preface things by
reassuring you this isn't an April Fool's column, even
though subjects like compiled DCL and DCL on PCs sound like
appropriate candidates for reader leg-pulling.

CLOSE TO THE MARK. We've talked about Channel Island
Software's DCL to Fortran Precompiler (DCP) before, but the
official release of Version 2.0 of the product requires
particular attention.

The latest release of DCP includes support for most
interpretive functions, such as runtime-generated symbols.
This additional functionality eliminates one of the biggest
restrictions with earlier iterations of the product, and is
one of the features which significantly reduces the amount
of "tweaking" necessary to get DCP to process your .COM
files.

The need for DEC's Fortran compiler in order to use DCP
isn't as onerous as it sounds. You don't really need to know
anything about Fortran to use the product, and the language
is about the least expensive one available from DEC.

Creating an executable image from a command procedure is a
simple three-step process: have DCP translate the .COM file
(up to 10,000 lines) into Fortran code, compile the code and
link it. The result is an .EXE than runs up to 10 times
faster than the original .COM procedure did under DCL.

Converting .COM files into .EXEs is a very effective way to
improve system security. Users can't TYPE or modify the
.EXEs. And instead of having to grant elevated privileges or
set up special accounts so a user can execute .COMs which
perform queue maintenance or other potentially privileged
operations, the .COM file can be converted to an .EXE and
installed with whatever privileges are required. The
elevated privileges remain in effect only during the
execution of the program. The same is true for programs
executed from an installed DCP-generated image via spawning.

DCP 2.0 is probably the closest we'll ever get to compiled
DCL, and it's well worth consideration.

As a footnote, it should be pointed out that translation
into a compilable language isn't the only way to create
.EXEs for interpreted code. Ergodic Systems, which markets
the somewhat arcane MACRO SPITBOL string processing
language, will probably eliminate the need of invoking its
interpreter in the next major release of the language by
allowing users to generate .EXEs with the SPITBOL
interpreter built into the image. This increases the
.EXE size, of course, but does make SPITBOL programs
transportable to systems not having the interpreter online.

*****

FREEWARE JEWEL - Although he wrote it "just for fun", Michel
Valentin's uDCL is a neat piece of work. It does a pretty
fair job of emulating the most-used DCL commands under
MS-DOS; he calls it a "small, DCL-like command interpreter".
It's available on my SYS$OUTPUT BBS system and on the VAX
Forum on CompuServe.

"You may use it as a command shell if you need some features
lacking in MS-DOS (like COPY/SINCE or DEL/CONF)", Michel
notes. "You may also use it if you want to build procedure
files in a more powerful language than batch."

While it has nowhere near the features of commercial VMS
emulation products (like Boston Business Computing's
excellent VCL), it works acceptably well and is an
interesting diversion. Maybe you can use it to convince the
folks who sign the checks that a commercial DCL emulator on
your PC could be a performance booster.

Unfortunately, the only address given for Michel is a
FidoNet node in Europe that doesn't appear in the most
recent nodelist I have available. If anyone knows how to
contact him, drop me a line. Michel said he'd consider
enhancing uDCL if he received sufficient positive feedback.

*****

SOLUTIONS AND SEMANTICS: The frequently-asked question of
the month is why a program which RUNs fine when executed
interactively fails when used with the /DETACHED, /DELAY,
/INTERVAL, /SCHEDULE or /UIC qualifiers to the command.

RUN, when used without the above qualifiers, is actually the
RUN IMAGE command. Add one of them, though, and the command
becomes the RUN PROCESS command. When RUN PROCESS is
invoked, RUN creates either a subprocess of the calling
process or, if /UIC or /DETACHED is used (and the user has
the necessary privileges), a detached process.

The gotcha is that when the system creates the new process,
it doesn't provide it with a copy of a command line
interpreter (CLI), typically DCL.

If you look at the failing program, you'll probably see that
somewhere in the code there's a call to spawn a subprocess
to execute a DCL command. Programmers will frequently use
this approach because it's fast, easy to set up, and avoids
the headache of structuring system service call arguments.
Yes, it's inelegant. But we're talking real-world here.
Quick hacks are sometimes required. And once something is in
place and working fine, it's often difficult to get the
necessary official blessing to expend the time necessary to
"legitimize" the code.

Anyway, since the process didn't have the DCL CLI mapped
into it when it was created, it can't execute any DCL
commands. Try it, and kaboom- the image exits and the
process dies.

The workaround is to run the system login image,
LOGINOUT.EXE, and have it execute your .EXE from a .COM
file.

There was some banter on the Internet a few months back
about whether this method was "blessed" by Digital. Consider
the following, from the startup file for DEC's DSNlink:

$ run sys$system:loginout.exe -
 /detach -
 /priority='f$getsyi("defpri") -
 /ast_limit = 500 -
 /buffer_limit = 100000 -
 /nodump - 
 /enqueue_limit = 200 -
 /error = dsn$logs:dsn$network.log -
 /extent = 1024 -
 /file_limit = 200 -
 /input = dsn$system:dsn$run_network.com -
 /io_buffered = 300 -
 /io_direct = 300 -
 /job_table_quota = 4096 -
 /maximum_working_set = 750 -
 /output = dsn$logs:dsn$network.log -
 /page_file = 32000 -
 /privileges = (all) -
 /process_name = "DSNlink Startup" -
 /queue_limit = 250 -
 /subprocess_limit = 32 -
 /working_set_size = 200

A quick SEARCH of the system disk unconvered other
DEC-supplied procedures using the LOGINOUT method:

SYS$STARTUP:VMS$BASEENVIRON-050_SMISERVER.COM
SYS$EXAMPLES:MSCPMOUNT.COM
SYS$EXAMPLES:SUBMON.COM
SYS$MANAGER:DECW$STARTSERVER.COM

And consider the following from the DCL Dictionary's
description of the /AUTHORIZE qualifier to RUN:

"When the image to be executed is the system login image
(LOGINOUT.EXE), this qualifier searches the user
authorization file (UAF) to validate a detached process."

So, while LOGINOUT may not be clearly documented anywhere,
it is obviously supported and used by DEC. It's sorta like
church bingo, I guess. It may not be "officially"
sanctioned, but no public official in his or her right mind
would shut one down, especially when the local police chief
buys a card or two every Tuesday night.

*****

NO MORE: Egads... over 400 sets of tapes and still counting.
A reminder that the free tape offer mentioned in the
December '92 issue has expired. The demand from the mention
here and on my BBS system was overwhelming, literally. The
files are still available, but I've had to impose a small
handling fee to help cover expenses. Send a self-addressed,
stamped envelope to the address below for details.

*****

IN THE MAILBOX: Thanks to Marv Pribble, Ken Hinkle, John J.
Hinkamp, Bret D. Wortman, Timothy S. Myatt and Keith A.
Schneider for sharing their code and comments. And speaking
of mailboxes, please make sure you use the address at the
end of the column when sending me anything. Mail sent to DEC
Pro's main office in Horsham, PA is delayed because of the
required rerouting.

**********************
Kevin G. Barkes is an independent consultant who sometimes
feels like he's diagonally parked in a parallel universe.
(He stole the quote from a BBS message tagline.) Kevin lurks
on comp.os.vms and can be reached at kgbarkes@gmail.com.