[Info-vax] VMS Forever?

[G Cornelius]

Bill Gunshannon wrote:
> In article <gr0245$rh7$1 at south.jnrs.ja.net>,
> 	"Richard Brodie" <R.Brodie at rl.ac.uk> writes:
> 
>>"Bill Gunshannon" <billg999 at cs.uofs.edu> wrote in message 
>>news:73hefhFutmjfU2 at mid.individual.net...

>>>Not sure what that means.  What makes a program "native"?
>>
>>It's not a CLI, as the POSIX shell was. You can't run programs in it without
>>creating a new process, for example. 
> 
> 
> I guess I am out of my depth here, but what would have to be done to
> make it work right?  I mean, I am sure the real BASH Shell makes use
> of fork() which we know is not available on VMS.  Not sure what the
> alternative would be but is that what you mean?

Unlike RSX-11M, it was never fully documented in VMS how to write a
Command Line Interpreter.

Officially, there have been a few non-DCL CLI's, including, I
suppose, Posix and one or more of its predecessors.

The characteristics of a CLI are that it runs in an inner mode
(Supervisor), and remains more or less permanently in process virtual
memory.  It executes images in succession in user mode within
current process context and gains control on image exits, both
normal and abnormal.  It may or may not be doing anything useful
during image execution, although it at a minimum appears to
provide services such as LIB$SPAWN and LIB$GET_SYMBOL that are
CLI specific and callable from user mode.

Whether it makes sense to implement a Unix shell using this kind
of structure is another issue, but even when closely emulating
the corresponding Unix shell, especially in the use of subprocesses,
it may be helpful to have the CLI infrastructure to help make up for
any shortcomings that facilities like LIB$SPAWN have as replacements
for their Unix cousins.

George

> bill