"John Reagan" <***@hp.com> wrote in message news:z0oFh.600$%***@news.cpqcorp.net...
<snip>
Post by John ReaganSeems to be that MicroVMS was more of a packaging concept.
<snip>
Indeed.
From my end-user point of view, one of the nicest things about MicroVMS was
the radically different documentation. VMS's traditional documentation was
guaranteed to cover anything you were ever likely to know, and a shelf-full
of stuff you probably wouldn't ever need, but to achieve anything useful
you'd often need a desktop's worth of full size manuals. MicroVMS
documentation had a different approach, one which I liked; as I recall, all
the commonly used stuff was covered in a couple of relatively small manuals,
which were often task-oriented rather than the reference-oriented style of
most of the VMS docs.
Wrt VAXELN: If there are specific VAXELN questions to be answered, I may
have a go, but my VAXELN experience started around V4 so I'm not in a good
position to say much about history, other than the usual widely known
stuff - VAXELN was a host/target toolset for relatively lightweight but
potentially sophisticated VAX-based real-time applications. It intentionally
does not attempt to provide VMS-like design concepts (eg VAXELN doesn't have
ASTs). Unusually for the time, VAXELN had transparent networking built in
for inter-process communication, and it also had a concept equivalent to
what became known as "threads". Many popular VAXes and devices were
supported on the target system.
Initially only Pascal was supported (initially not VAX Pascal but an
ELN-specific version). Additional languages were added over time, and in
particular comprehensive Ada support was available (working with the same
fine VMS debugger that VMS folks were used to, rather than the previous
VAXELN-specific debugger). C and Fortran were probably supported too (you
could certainly make them work). Some of the language-specific stuff would
have been done by people who may still read this newsgroup.
Later versions of VAXELN had decent X-windows support (client, server, or
both), a capability which was used in some of DEC's VAX-based Xwindows
terminals and in the ELN Window System.
An optional add-on to VAXELN was a relational database API, Rdb/ELN, which
was basically (as the name implies) RdB for VAXELN.
Another optional add-on to VAXELN was a source distribution of the VAXELN
runtime, which would reveal lots of details of how the stuff worked. The
VAXELN source kit wasn't on the Condist CDs and as far as I know not many
people had one.
Basic VAXELN documentation included a "VAXELN Technical Summary" and
"Introduction To VAXELN" which might be helpful here, depending on what the
"history" exercise hopes to achieve. The "Introduction" was part of the
online docs and so should be on a VAX Consolidated Documentation CD from the
relevant era, not sure about the "Technical Summary". Google finds an
"Introduction" at
http://www.sysworks.com.au/disk$cddoc04jan11/decw$book/aa%2djl11d%2d01%5f%5f
a01%5fb2.p5.decw$book#1
Another relevant piece of documentation might be the excellent VAX Realtime
User's Guide, EK-VAXRT-UG001 (1986!) which covers using VAX for realtime
applications on both VMS and VAXELN, in some considerable depth. Not
immediately locatable online.
VAXELN is the kind of thing that ought to have had a Digital Technical
Journal article (or several) written about it but I don't recall any; anyone
got a comprehensive DTJ index e.g. was there an index on the DTJ CD from the
VMS boot camp, does it include any VAXELN articles?
VAXELN was never ported to Alpha. For Alpha, DEC chose to "partner" with
Wind River Systems to have WRS's VxWorks ported to Alpha, with support for a
small number of OEM-specific board-level Alpha products and a tiny subset of
WRS's mainstream VxWorks supported boards. A documented and supported
"VAXELN API layer for VxWorks" was offered to (allegedly) simplify migration
of applications (so long as they were written in C). But with VxWorks hosted
on Unix vs VAXELN hosted on VMS, and with almost no commonality between the
two products' architectures except claimed support for a variety of Posix
APIs , anything non-trivial simply wasn't sensibly portable between the two
environments, and a re-design would almost certainly be a more sensible
option. Some customers needing the power of Alpha in the context of
real-time systems chose to use DEC OSF/1 (or Tru64 or whatever it was called
at the time its respectable RT stuff came out) instead of VxWorks, subject
to practicality constraints (like having a disk available).
It's no secret where one of the original VAXELN architects ended up, right -
taking some VAXELN concepts, putting some PC-friendly stuff around them, and
labelling the result Windows NT ? I don't know where the remaining VAXELN
team ended up - they were sold off from Compaq when Digital's OEM+Realtime
group were sold to SMART Modular Technology and I lost track of them after
that (I believe that at one point some of the OEM+RT group ended up being
owned by Motorola...). Some folks are still using VAXELN but they tend to be
a bit "niche", and you won't often read about it. It's often the kind of
stuff that goes in and then "just works" for years.
Hth
John