[Info-vax] Reimplementing VMS, was: Re: OT: Oracle vs. Google re: Java

[Paul Sture]

On 2016-05-31, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2016-05-30, Paul Sture <nospam at sture.ch> wrote:
>> On 2016-05-30, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> This does assume however that you only wanted some level of
>>> compatibility against the public VMS APIs and VMS look and feel and were
>>> not interested in compatibility against the internal undocumented APIs
>>> and structures.
>>
>> With structures, things like item lists spring to mind.  Do you
>> deliberately avoid using them (except in public API shims) to ensure
>> things are different underneath?  Dunno the answer to that one.
>>
>
> Item list structures are documented in public manuals so they are
> fair game IMHO. If only the names and not the values for what you
> place in the fields are in the public manuals then you would have
> to assign new values but that's about it.

Digressing here, but that brings back memories of calling system
services from COBOL in the VMS V2.n era.  The COBOL standard at the time
didn't allow global variables, and the COBOL compilers didn't provide
system headers, so you had to define the values manually.

Aware that the values *could*[1] change from one release of VMS to
another, I wrote some DCL which generated COBOL definitions by
extraction the macro headers and massaging those, with the intention of
running that after any VMS upgrade.  The native COBOL compiler which
arrived with V3 did support global variables; we could now use a simple
bit of macro to stick those into a global variable structure and link
with the main program.  A simple recompile and link would pick any
changed values up, no source code fixing required.

[1] I never came across values which did change with VMS releases, but
they could have done.

> The kind of thing I was thinking of would be trying to implement a
> VMS compatible ACP interface. As the required information is not public
> knowledge you might be on seriously dodgy ground trying to delve deep
> enough into VMS to obtain the information needed because you would
> probably have to consult the VMS sources.

It's a tricky area.  As I understand it, both Samba and the Windows
utilities provided by the Sysinterals folks were done by reverse
engineering of the form which I wouldn't have been comfortable doing
with VMS or its (DEC) layered products.

> OTOH, you would be crazy to want to reimplement a VMS compatible ACP
> mechanism instead of just throwing the whole thing away and doing it
> in a different and far cleaner way.

:-)

> For example, in a rewritten VMS you would have modular filesystem
> and device drivers which could be inserted into and removed at will
> from the kernel during system operation. For those drivers which still
> required a process context for some reason, you could implement a new
> fully documented user mode driver mechanism from the ground up which
> gave you ACP style functionality but which used a newly designed API.

Unloadable drivers.  Yes please. :-)

> The same is true for the kernel internals in general BTW. While you
> absolutely would keep all the user visible VMS specific functionality
> (the DLM, user privileges, ACLs, ODS-2/5, etc) the details of the
> kernel would look very different. For example, you would structure it
> into generic functionality and architecture specific functionality to
> make it easy to port.
>
>> Off the top of my head my most common uses of item lists have been in
>> conjunction with $getjpi, $getdvi, $getqui and $qio (and their -w
>> variants). If the underlying structures are radically different *I'd* be
>> happy to adopt completely new APIs for the functionality those provided;
>> others might not of course.
>>
>
> I'm torn on $getqui() and friends. OTOH, you still need a procedural
> mechanism so you could use it with traditional languages ...

The sheer amount of options available with $getqui() is daunting for
the typical applications programmer; they should be concentrating on
the business logic rather than getting so involved at this level.

The simple answer there is to provide a few high level routines (e.g.
"submit", "print" and so on) for the applications programmer.  Hide the
nitty gritty from the applications folks, while still providing
technically able customers to delve deeper should they wish.

> ... but OTOH there's serious potential here for a far cleaner OO
> interface in languages which support such concepts. You could for
> example pull back an immutable collection of objects in one go and
> then iterate over them.

The idea of getting a consistent immutable snapshot of, for example the
current processes and their states is appealing.

> I'm also uncomfortable with the user-visible complexity of RMS
> programming; the blocks should be an implementation decision, not
> a user interface mechanism. There should be an abstraction mechanism
> around the blocks which allows you to ask for operations to be
> performed on them.

Agreed. Something as simple as setting the mass-insert bit for an
indexed file load exposes you to that lot. It really shouldn't be
so complex.

-- 
There are two hard things in computer science, and they are cache invalidation,
naming, and off-by-one errors.