[Info-vax] Looking into C-include files on VMS

[John Wallace]

On Nov 5, 8:40 pm, koeh... at eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <2a6df317-bf45-452c-82aa-28c1e9001... at m38g2000yqd.googlegroups.com>, John Wallace <johnwalla... at yahoo.co.uk> writes:
>
>
>
> > I suspect (but cannot 100% confirm) that you are on the right track
> > here. Long before the days of VMS Posix, e.g. in the mid 1980s there
> > was VAX DEC/Shell (which I forgot to mention previously) as an
> > alternate CLI instead of DCL. Then there was VMS Posix, again with its
> > own CLI. Wollongong's Eunice had its own CLI but I can't remember
> > whether that used the UAF CLI entry or not (don't *want* to remember
> > Eunice).
>
>    Did Eunice actually provide a CLI, or just a csh that you could
>    start from login.com?
>
>    Also, in early releases, you could use actual MCR as your CLI,
>    instead of just as a command in DCL.

Did Eunice provide a UAF-style login CLI? I'm not sure. I'm tempted to
say it did, but it is a long time ago (nearly thirty years since I
used it last) and it is a piece of software which was a very mixed bag
whose exact details I've mostly forgotten about - interesting concept,
amazing it managed to do what it did, but in reality the results and
usefulness were not so good for what I was doing, to the extent that
it was more productive to find ways to avoid Eunice than it was to use
Eunice.

The initial idea had been that Eunice would help simplify software
development for a non-trivial piece of software, a bit like we are
talking about right here, though a rather different piece of software
(a process automation package) and without the arbitrarily long list
of target environments. As it turned out, having looked at all the
available options *before* starting serious design and coding, and
having seen how slowly Eunice performed its miracles, we decided it
would be much much preferable to restrict the application's OS
interfaces to the small subset which was going to be reasonably
portable across the relevant environments - VMS V3/V4, System V Unix
on MC68K, BSD/SysV hybrid Unix on Gould SEL UTX/32, and the chosen
embedded M68K OS used for the run time target. Direct access to the OS
without going via the portability layer was generally prohibited, but
everything we needed was available one way or another - shared memory,
inter-process comms, networking, etc. This was in the "UNIX wars" days
when BSD and System V couldn't even agree on the number of parameters
to open() a file.

Once you've made the decision to restrict the OS interface, life
becomes relatively simple in portability terms. You put a thin layer
under the app on top of the OS to provide OS API independence for the
app and also to build your own implementation of any necessary
facilities not immediately provided by the underlying OS.

That ended up with Eunice (a BSD 4.1 derivative) being left a bit
irrelevant - it was mostly used as an occasional filler in e.g. when
we needed to quickly check a BSD behaviour without having access to an
SEL machine.

MCR as a VMS CLI wasn't something I ever played with either. Call me a
heretic, but I was quite happy to lose MCR on moving from RSX11D to
IAS, and didn't miss it much on VMS either.

hth
John