VMS: logicals UNIX: links, but...

[Richard A. O'Keefe]

In article <810036 at hpsemc.HP.COM> gph at hpsemc.HP.COM (Paul Houtz) writes:
>ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>I take leave to doubt this.  It has always been good style in UNIX
>>for programs to read from standard input and write to standard output,
>
>Okay, let me put it to you from my perspective.   I AGREE with you if
>you are talking about programs that are designed on a Unix system.
>However, I work in a center who's main focus is to port software from
>non-unix platforms to unix.   Now, none of these software packages are
>designed on unix systems.   Therefore, they aren't designed to write
>to stdout, because there ain't any stdout.
>
>There are far more applications running on IBM, VMS, MPE, etc., platforms
>than unix. 

I don't know about MPE.  I don't even know what the initials mean.
But what on earth do you think SYSOUT and SYSPRINT are in MVS if not
equivalents of standard output?  And what is SYSIN but an equivalent
of standard input?  Having
	//SYSOUT  DD  (DSN='FOO.BAZ',DISP=MOD)
in a JCL deck is just like doing
	some-command >>foo.baz
in a UNIX shell.

And what on earth do you think the logical names SYS$INPUT, SYS$OUTPUT,
and so on are in VMS?  The VAX-11 C compiler thinks they are stdin, stdout,
and so on.  Both C and PL/I provide you with a way of obtaining input from
a "standard" source (which is bound in the environment of the program's
caller) and sending output to a "standard" sink (similarly bound) without
mentioning the ``name'' of the file at all.  (printf() in C, PUT LIST or
PUT EDIT in PL/I.)

If you have source, all the editing it takes is this:

	#include <stdio.h>

	FILE *envopen(envname, access)
	    char *envname, *access;
	    {
		extern char *getenv();
		char *filename = getenv(envname);

		if (filename == NULL) return NULL;
		return fopen(filename, access);
	    }

Then replace the misbegotton fopen(...) calls by envopen(...).
Any company which is porting a program from some operating system to UNIX
and cannot take the trouble to include a 6-line function to take care of
this problem is such a lousy bunch of incompetents that this is the least
of your worries.

>All of those systems allow
>you to associate a LOGICAL or VIRTUAL file name with a PHYSICAL file name.

So does UNIX.  The method is called "environment variables".  It is very
very easy to use.

>Companies
>have enormous investments in this software, and they don't wan't to change
>source or go to enormous trouble to modify JCL to get to unix.

Come now, next thing you'll say that "sh" statements should start with //.
Look, I've watched people try to port VMS programs to MVS.  Not a pretty
sight.  I've got more news for you:  IBM have *two* important operating
systems for the /370 range (there are more).  They are MVS and CMS.

	MVS	has no equivalent of VMS logical file names.
		It *does* have an equivalent of environment variables
		(namely, DD definitions).

	CMS	has no equivalent of VMS logical file names.
		It *does* have an equivalent of environment variables
		(several, in fact: REXX variables and GLOBALV among them).
		It also simulates MVS DD definitions with FILEDEF cards,
		but they are *not* VMS-style logical file names.

The distinction I am trying to draw is this:  in UNIX, or in CMS, or in
MVS if you have a routine which opens a file by its DSNAME, when you
specify a file name in a program, that is *exactly* the file you get,
not a file with some other name.  The scheme is

	"environment" --> "file name" --> file
	getenv, DD,	  open, fopen,    (VTOC, directories)
	GLOBALV, ...	  dsna, ...	  
	   ^		  ^
	   +--------------+-------- programs can enter at either point

If a CMS program has a hard-wired file name in it, such as
	'LATEX PROFILE A1'
for argument's sake, there is no way of mapping that name to something else,
and CMS users do not expect there to be one.

I'd also like to cite the Burroughs B6700 MCP (the last version I used
was III.0).  In that operating system, a program declared a file like this:
	FILE MYDICT(TITLE = "(CCC002S)DICTIONARY/BASE ON MYPACK", ...);
There are two things named here, the file interface block (called MYDICT),
and the file it refers to (/mypack/ccc002s/dictionary/base, as it were).
In a shell script (WFL program), you can say
	RUN MYPROG; FILE MYDICT(TITLE = "(MAT212X)DICTIONARY/REVISED");
In effect, the "internal name" MYDICT acts like an MVS DDNAME, and you
can over-ride default information in the program in the shell script.
But the program gets another chance:  if you say
	MYDICT.TITLE := "(CCC002S)DICTIONARY/BASE ON MYPACK";
in the program, that over-rides what the shell script may have specified,
and there is absolutely nothing that a shell script or any other environment
can do about this.

In summary, UNIX, CMS, MVS, and MCP have *two* kinds of names:
	file names, and file name names.
The means whereby the mapping from file name names is maintained differ
between the systems, but the essential idea is the same, and in none of
then can the environment alter the meaning of a file name, only the
binding of a file name name.

The exception is not UNIX, it is VMS.  VMS mingles file names and file
name names (logical names) in one confused mess.  For example, it is
possible to create a file in VMS, write to it, close it, then use the
identical same sequence of characters (with *no* intervening change to
the logical name tables) to request that a file be opened for input,
and get a different file!

>Are you 
>so sure there are no conceptual problems in using unix?  How about 
>aliases?

UNIX has no aliases.  There is *NO* kernel support for aliases whatsoever.
They are a feature of the C shell.  I write Bourne shell scripts.  If you
call a program using exec(), you do not see aliases.

>Finally, when I hear people tell me that unix SHOULDN'T do something, I 
>wonder just who is playing God.  It sounds like a circular argument.  
>Are you saying that Unix shouldn't do it because it isn't a good thing,
>or are you saying that it isn't a good thing because Unix doesn't do it?

Let me make my position perfectly plain.
(1) Every operating system should provide some means whereby the caller
    of a program may provide an association between tokens used by a
    program and actual files which those tokens are to refer to.
	***UNIX DOES THIS***
(2) Since any number of programs may use the same token for different
    purposes, it is important that it should be easy to make this association
    on a call-by-call basis.
	***UNIX DOES THIS***
(3) Conversely, some tokens may be regarded as "well known", so it should
    be possible to make the association on a relatively permanent basis.
	***UNIX DOES THIS***
(4) It is important that a program should be able to contain some form of
    reference to a file which is immune to sabotage by malicious users.
	***UNIX DOES THIS*** (only the super-user can chroot())
(5) To encourage the porting of programs, it should be easy to open a
    file using a token to refer to its name.
	***UNIX DOES THIS*** (see envopen() above)

I *do* most vehemently state that UNIX should not copy VMS's "logical name"
mess.  I think I am finally beginning to understand ADA.  VMS's logical
names are still too hard for me.  (It may be the documentation at fault.)
It is superflous to do so, because UNIX ***ALREADY*** provides all the
tools you need to handle the file name name approach in PRECISELY the way
that you do it under CMS.

If there are programs offered for sale under UNIX which have hardwired
file names in them which the user has legitimate reason to rebind, the
reason for this is that the developers or porters of the program either
were incompetent or just didn't give a damn.  It is *EASY* for them to
let you bind file name names to file names in the environment.