[Info-vax] DCL and scripting

[Stephen Hoffman]

On 2018-12-12 13:38:41 +0000, Simon Clubley said:

> The biggest thing for me is that John doesn't seem to think there's a 
> major conceptual problem with inserting C code into DCL, even given 
> DCL's unique requirements.
> 
> If you can get C code into DCL, I wonder if that could be used to fix 
> up other DCL issues.

C is available in kernel mode, and using, the so-called kernel CRTL.  
Some C library functions are and others can be implemented in the 
kernel CRTL fairly easily, while other functions—typically thise 
involving system calls or RTL calls not directly available in kernel 
context—are much more difficult to provide in the kernel CRTL.  And 
those are usually omitted.

> For example, we know from previous discussions the line editing code in 
> the terminal driver is an unmaintainable mess, so we can't edit command 
> lines which are longer than the terminal width. Could the problem be 
> worked around (at least for DCL) by placing line editing code into DCL ?

DCL can't fix a terminal driver limit.

The terminal driver keeps one (non-wrapped) line around.  DCL already 
keeps the complete command line in its history, and works around the 
terminal driver limit.

As I've commented elsewhere, the changes permissible within the 
existing class and port terminal driver stack are constrained by the 
expectations of upward-compatibility.  It's difficult to retrofit 
changes into this and similar environments, as it's very easy to break 
(some) existing code with changes to documented or even to undocumented 
behavior.

What do I mean by this? I broke the test suite with a change to 
SYLOGIN.COM years ago; to the login terminal driver settings.  Somebody 
somewhere was going to be dependent on the old behavior, even though 
the new behavior made more sense in the then-current era.  Similarly 
and separately an aeon or two ago, OpenVMS changed the I/O completion 
processing to be asynchronous across multiple processors in an SMP 
configuration, and that change exposed latently-broken OpenVMS cpde and 
app code all over the place.  Both sets of changes was reverted.

The terminal driver environment could be well-served by a redesign and 
replacement.  Most systems have at most one or maybe two hardware 
serial lines and those now primarily relegated to server bring-up tasks 
and console tasks, and we can only expect traditional serial consoles 
to be replaced.  Other "serial" connections are USB, network or iLO.  
Keep the old terminal driver stack around pending app migrations, but 
get folks over to the new implementation.

Rewriting the terminal driver and/or the CLI environment?  I'd 
certainly like to see that and for various reasons, but I'd assume that 
there are few existing apps that would care about that, and there are 
other projects folks want more.  There's a port to complete, and a 
whole lot of other work pending.




-- 
Pure Personal Opinion | HoffmanLabs LLC