From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: Running LOGINOUT
Date: 5 Jan 93 13:31:23 GMT
Distribution: world
Organization: The Internet


	[On the issue of whether running LOGINOUT to map a CLI is supported,
	Steve Lionel writes:]
	There actually is documentation of the use of LOGINOUT with
	RUN/DETACH; in the VMS V5.0 manual set, it's on page DCL-392 of the
	DCL Dictionary in the description of the /AUTHORIZE qualifier to RUN.
	It says:

		When the image to be executed is the system login image 
		(LOGINOUT.EXE), ...

	This implies to me that it is a supported use to specify LOGINOUT.EXE
	as the image name.  However, I say this on my own behalf and not as an
	employee of Digital.

I would call this barely on the edge of supported.  This information is hidden
within the documentation of a qualifier that need not be specified when
running LOGINOUT - and it actually says just that!

If you check the documentation for $CREPRC, which RUN/DETACH eventually uses
to create the new process, you find very much the same kind of partial
documentation.  The table of stsflg values (page SYS-98 in the V5.0 book)
mentions running LOGINOUT as part of the documentation of the NOUAF bit, which
corresponds to the /AUTHORIZE (well, /NOAUTHORIZE!) qualifier, as well as in
the documentation of the INTER and NOPASSWORD flags.  However, at the end
of the table we find:

    Note that the options PRC$M_BATCH, PRC$M_INTER, PRC$M_UAF, PRC$M_NETWRK,
    and PRC$M_NOPASSWORD are intended for use by DIGITAL software.  Complete
    documentation of the possible ramifications of their use is not provided.

Is that documented/supported or not?

There's a further reference to LOGINOUT in the last paragraph of the Descrip-
tion section:

    A created process is unable to run an image that calls the Run-Time
    Library procedure LIB$DO_COMMAND unless the process was created with
    the image argument specifying SYS$SYSTEM:LOGINOUT.EXE ... [which]
    causes a command language interpreter to be mapped into the created
    process....

Again, hints at documentation/support, but just barely.  (Actually, this is
a very strange paragraph.  Why does it focus on LIB$DO_COMMAND?  There are
several other CLI callbacks.)

			      Still, I am not aware of any intention to
	declare this usage as "unsupported"

It would be nice if it were decently documented, rather than being hinted at.
In general, it's clear in VMS when something is documented/supported, and
when it just happens to work.  I can think of no other example in which the
VMS documentation tip-toes around the edges but is unwilling to really
commit itself.  There's a big difference between "if you DON'T run LOGINOUT,
you can't use LIB$DO_COMMAND" (hint, hint - but if you do it you MAY be on
your own) and the direct "run LOGINOUT to cause a CLI to be mapped".

On this matter, the VMS documentation just doesn't reach it's usual levels.
(It reminds me of some of my favorite Unix documentation, where I can, for
example, show you examples of flag values for system calls that are documented
ONLY in the error messages:  "This error is returned if such-and-so occured
and you didn't specify the this-and-that flag."  The "this-and-that" flag is
mentioned nowhere else.)

					    and am also unaware of any new
	feature coming in V6.0 that would replace this (and I think I would
	know if there were.)

Well, that's good to hear!  VMS development should understand that, whether
THEY think this technique is officially supported or not, the documentation
at the very least strongly hints that it is, and MANY people rely on it.

							-- Jerry

Newsgroups: comp.os.vms