[Info-vax] VMS porting/rewrite, was: Re: [OT] Wirth style languages, was: Re: Obscure Ada compiler vendors?

[Stephen Hoffman]

On 2013-04-10 16:49:35 +0000, Simon Clubley said:

> The only thing I've ever seen a ACP used for on VMS is for tape drives
> and I've never even come across any public documentation which would
> allow me to write one of those.

F11BXQP ("the XQP") arrived at V4, and that replaced the F11BACP 
Files-11 ACP from earlier versions.

LD has an ACP, and there's an old ZEACP.  VMS has several other ACPs around.

I've written several ACPs.   There's an ACP overview here: 
<http://labs.hoffmanlabs.com/node/213>

There's no DEC/Compaq/HP documentation for ACPs, though Jamie 
Hanrahan's VMS Advanced Device Driver Techniques (1988) book did 
include a reasonable description of what was then involved.  I acquired 
a copy of that about a month after I'd written my first ACP, and having 
figured this out from MTAACP.  Jamie got it right, though I do recall 
noticing a very few and minor mistakes.  (Caveat: do not look at the 
DECnet ACP as your first ACP template.  Your head may explode.  But I 
digress.)

There's no generic way to get your own ACP loaded and going within 
OpenVMS, if you're doing something slightly different from how the file 
system expects an ACP to work.   MOUNT has various assumptions — and 
those didn't hold for the ACPs I was writing — which led to a custom 
"mount" command.

That "mount" command work is also where I first figured out how to do 
this stuff: <http://labs.hoffmanlabs.com/node/803>, as using a DECterm 
brought a debug version of the ACP online easily.  Which was leagues 
past debugging in XDELTA.  But I digress.

There's no documentation and no support for tying into the VMS file 
system stack, either.  What the NFS client does is undocumented.

Back-tracking to the "porting" or "rewriting" of OpenVMS discussion, 
the current file system and parts of the I/O system are limited to 
32-bit values for block addresses, which means either bigger block 
sizes (to IDEMA "long sector" 4096-byte blocks, for instance) or 
promoting those longwords to quadwords all over the place in the file 
system and kernel and drivers, or disk partitioning, or (more likely) 
all of these  Doing either a port or an rewrite while keeping 32-bit 
addresses and 512 byte sectors and no partitioning support would be 
problematic as disks increase in capacity.  Related: 
<http://labs.hoffmanlabs.com/node/284>



-- 
Pure Personal Opinion | HoffmanLabs LLC