VMS: logicals UNIX: links, but...

[T. J. Thompson]

In article <810035 at hpsemc.HP.COM>, gph at hpsemc.HP.COM (Paul Houtz) writes:
> chris at mimsy.UUCP (Chris Torek) writes:
> >In article <475 at caldwr.UUCP> rfinch at caldwr.UUCP (Ralph Finch) writes:
> >>We run models, and often want to run the same model, simultaneously,
> >>in the same directory, with two different input files, and produce two
> >>corresponding output files.
> >
> >Instead of using `logicals' or links or symlinks or . . ., just:
> >
> >	model < input1 > output1 &
> >	model < input2 > output2 &
> 
>    The solutions you recommend are workable in only the simplest 
> situation.  If you have a system that uses many programs interacting
> with many different data files or data bases, this approach is not
> practical.

The UNIX paradigm is for programs taking input from several files to
have these enumerated on the command line, or listed in a file.
Programs generating several output streams choose output files names
which are:
- constructed to be unique (temp files);
- simple transforms of input file names (cc -c x.c --> x.o);
- specified via command line options (cc -o x x.c);
- (other strategies i have overlooked or not encountered).

>    If you ask me, this is a another area where UNIX is deficient.  Once
> you get used to being able to move large complex systems that use hundreds
> of files around at will, as you can on VMS and even MPE systems, you run 
> run into significant problems on UNIX.
[...]
>    By specifying a simple target file name, such as "journ_entries" or
> "time_card_edited", you can make a command file that puts logicals in
> place to point all these files at the appropriate directories.

Programs that read and write ``known'' filenames like this are simply
mis-designed. This practice is a relic of JCL. It is assumed that there
will only be one instance of the ``job'' at a time, and that the user
will tolerate tedious job preparation procedures. Now it is true that
some UNIX programs nonetheless do have built-in file names
(yacc, for example; i know not why).
It is still a bad design practice.

> If you 
> need to run the program multiple times, or against different data (say
> test data versus real data) or if you need to run a benchmark and have
> multiple instances of the software running at the same time, it becomes
> VERY difficult on UNIX.

I have some experience with ``large complex systems'' under VMS, with
attendant command files to set hundreds of logicals. The exercise of
changing the files for some of the programs is fraught with error and
frustration, because it is never obvious which programs use which files.

I suspect that most programs using built-in names on UNIX were ported
(or reimplemented) from some JCL-like system, with no appreciation of
the above-mentioned paradigm. For UNIX programs respecting the paradigm,
retargetting the I/O to different files is trivial.

> [...]
>    A good example is a program that creates a report destined for a 
> printer named, for example "edit.listing".  One may not like the fact
> that a "named file" is used instead of stdout, but many such programs
> exist in the real world.

Many? On UNIX? Not in my experience.

> So what do you do to run 20 of these programs 
> simultaneously?  On a 20 user system, you may have to.   The only way 
> I know of is to change the program to make it write to stdout.

As it should have been in the first place.

> This 
> isn't too bad if it's only one file, but what if that same program 
> reads from 10 files that are unique to each user?

Use command line arguments!

> Here's a real world
> example:   many businesses run 2 or 3 general ledgers at the same time.
> They would probably want to use the same objects, but run them against
> different files.   They would probably all run at the same time at 
> say, month-end?

See above.
-- 
     ||  // // ,'/~~\'   T. J. Thompson              uunet!watmath!mks!tj
    /||/// //|' `\\\     Mortice Kern Systems Inc.         (519) 884-2251
   / | //_// ||\___/     35 King St. N., Waterloo, Ont., Can. N2J 2W9
O_/                                long time(); /* know C */