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

VAXman- at SendSpamHere.ORG VAXman- at SendSpamHere.ORG
Tue Apr 9 11:51:45 EDT 2013


In article <kk1cg8$8tu$1 at dont-email.me>, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
>On 2013-04-09 12:43:17 +0000,   VAXman-  @SendSpamHere.ORG said:
>
>> You don't like a particular command or utility, write your own.  You can
>> replace these things just as easily.  Saying that it is not easy to do on
>> VMS means you shouldn't be a part of the project trying to do so. ;)
>
>Is it possible to create a CLI?  Sure.  SMOP.
>
>Writing a CLI is not documented by HP, AFAIK.
>
>There's some info on the activation path and related in the IDSM, and 
>the rest of what you need is in the OpenVMS source code.
>
>> There is nothing sacred or special
>> about a CLI on VMS.  Of course, if you're still expecting to use any DCL
>> constructs, then you'll have to provide that in your CLI.  Sheesh, talk
>> about mythconceptions.  Hint: Shareable image; entry point at 0!  'Nuff
>> said.
>
>There's also fielding the incoming sys$cli requests from programs, and 
>a few other details such as properly contending with a spawn request 
>and particularly when you're spawning a different CLI.  Some doc on how 
>to debug your new CLI would be helpful.  Maybe a CLI example would be 
>nice, too.

Oh, you want to use the existing VMS utilities? :)  I did put some minimal
SYS$CLI (CHMS R9) comments/documentation in some of my DCL utilities.  It's
not anything too difficult to figure out.  If supporting the existing DCL
interfaces is needed, then mapping the existing DCL image and augmenting it
is probably the way to go.  It's what I've done with my DCL debugger.  It
was also necessitated by wanting the existing DCL behavior and processing.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.



More information about the Info-vax mailing list