Command Procedure Pipe output to a variable

952 views
Skip to first unread message

HCorte

unread,
Aug 31, 2021, 5:49:46 AMAug 31
to
Implementing a command procedure that first obtains the device allocated to a process for example purposes called YYYYYY.

How to output the results of (SEARCH SYS$INPUT "Devices allocated") to the variable DEVICEAUX tried (READ SYS$PIPE DEVICEAUX) but with no success.

$ pipe SH PROCESS YYYYYY | SEARCH SYS$INPUT "Devices allocated" | (READ SYS$PIPE DEVICEAUX)
$ WRITE SYS$OUTPUT DEVICEAUX
$ DEVICE_AUX = F$EDIT(F$ELEMENT(1, ":", TEST),"TRIM")
$ WRITE SYS$OUTPUT DEVICE_AUX

can make it work to write to a file
$ pipe SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" > DEVICEAUX.DAT

but would prefer to avoid having to write and read from file if possible, also in command procedure should alls use SYS$PIPE instead of SYS$INPUT?

cao...@pitbulluk.org

unread,
Aug 31, 2021, 6:43:30 AMAug 31
to
The search will only ever return the device name of the most recently allocated device to the process YYYYYY, which will most likely be your pipe device MPAx: because the devices are listed on separate lines.
DEVICEAUX is set in the context of the subprocess created by the pipe so the main process running the script will never see it.

What is the problem you are trying to solve?

Keith

MG

unread,
Aug 31, 2021, 6:58:04 AMAug 31
to
This is a recurring question and I think just about anyone getting
started with DCL wondered about this at some point in time.

I'm afraid that there's little to nothing 'natively' in DCL (except
of course lexicals) like you'd have in e.g. *n*x Bourne shell, besides
writing to a (temporary) file and. But, besides that, for the rest
nothing but hacks and workarounds that typically involve writing an
external program that can be called to receive the piped data and
write it to one or more symbols. (The latter is what I did myself,
with some varying results.)

- MG

HCorte

unread,
Aug 31, 2021, 7:05:19 AMAug 31
to
> Keithremote

Thanks Keith then for now gona go with the solution of writing to a file, in this case for this process the list of devices will alls be one and don't expect to be more. This Devices allocated will serve for matching for the command (sh network "tcp/ip" /full) the column Device_socket and retrieve the value/ip in column Remote Host.

cao...@pitbulluk.org

unread,
Aug 31, 2021, 7:30:47 AMAug 31
to
There may be an ACP style I/O function you can do to query the list of open connections and what processes are connected to them. I vaguely recall doing something similar a long time ago with DECnet and its NETACP. You could also possibly listen for audit or alarm events for network logins and grab the data that way - you'd get the source and the process ID involved. Just a thought.

Jim

unread,
Aug 31, 2021, 8:12:00 AMAug 31
to
Maybe pass the value of the SEARCH output back to the parent process using a job logical name...

$ pipe/nosymbol/nological -
show process YYYYYY | -
search sys$pipe "Devices allocated:" | -
( read sys$pipe x ; define/job x &x )
$ device_aux = f$element(1,":",f$edit(f$trnlnm("x","lnm$job"),"collapse"))
$ deassign/job x
$ show symbol device_aux

VAXman-

unread,
Aug 31, 2021, 8:33:45 AMAug 31
to
Or.., get and install my SYMBOL utility, and then it's simply:

$ PIPE SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" | SYMBOL/SET/QUOTE DEVICEAUX

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

I speak to machines with the voice of humanity.

MG

unread,
Aug 31, 2021, 11:42:04 AMAug 31
to
On 31-Aug-2021 14:33, VAX...@SendSpamHere.ORG wrote:
> Or.., get and install my SYMBOL utility, and then it's simply:
>
> $ PIPE SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" | SYMBOL/SET/QUOTE DEVICEAUX

Where to get it? I'm curious to see how it functions, especially
compared to what I made myself once.

- MG



MG

unread,
Aug 31, 2021, 11:50:03 AMAug 31
to
On 31-Aug-2021 14:11, Jim wrote:
> Maybe pass the value of the SEARCH output back to the parent process using a job logical name...
>
> $ pipe/nosymbol/nological -
> show process YYYYYY | -
> search sys$pipe "Devices allocated:" | -
> ( read sys$pipe x ; define/job x &x )
> $ device_aux = f$element(1,":",f$edit(f$trnlnm("x","lnm$job"),"collapse"))
> $ deassign/job x
> $ show symbol device_aux

Interesting workaround.

- MG

cao...@pitbulluk.org

unread,
Aug 31, 2021, 12:26:39 PMAug 31
to
Chances are though, you will still only get a node$MPAx: device back because it'll be the first listed after 'Devices allocated:' thanks to the PIPE command

HCorte

unread,
Aug 31, 2021, 12:41:08 PMAug 31
to
Thanks @Jim works like a charm

Jim

unread,
Aug 31, 2021, 1:00:03 PMAug 31
to
True if process YYYYYY is the process executing the commands... but. presumably it is not as the OP would not likely have included the process name on the SHOW PROCESS command if target was self.

VAXman-

unread,
Aug 31, 2021, 3:47:34 PMAug 31
to

Phillip Helbig (undress to reply)

unread,
Aug 31, 2021, 4:01:42 PMAug 31
to
In article <00B68207...@SendSpamHere.ORG>, VAXman-
@SendSpamHere.ORG writes:

> In article <nnd$5c212734$469a7dc0@eef88cb4a2fe519b>, MG <marc...@SPAMxs4all.nl> writes:
> >On 31-Aug-2021 14:33, VAX...@SendSpamHere.ORG wrote:
> >> Or.., get and install my SYMBOL utility, and then it's simply:
> >>
> >> $ PIPE SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" | SYMBOL/SET/QUOTE DEVICEAUX
> >
> >Where to get it? I'm curious to see how it functions, especially
> >compared to what I made myself once.
>
> http://tmesis.com/symbol/

Nice that the page is visible a) in http and b) in Lynx. However, the
link to the online help doesn't work:

Requested script (helpgate) not found in htbin directory (www_root:[bin])

VAXman-

unread,
Aug 31, 2021, 6:05:33 PMAug 31
to
Download and install SYMBOL. You can then read the help. In the interim, I'll
look into why the 'helpgate' is failing.

Jon Pinkley

unread,
Sep 1, 2021, 7:09:18 PMSep 1
to
On Tuesday, August 31, 2021 at 6:05:33 PM UTC-4, VAXman- wrote:

> Download and install SYMBOL. You can then read the help. In the interim, I'll
> look into why the 'helpgate' is failing.
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>
> I speak to machines with the voice of humanity.

As someone that has used TMESIS SYMBOL for more than 25 years, on VAX, Alpha
and Itanium, I will say it is well worth installing it. It's incredibly flexible and useful
for many things. You can see all scope levels of DCL symbols, the global plus 32
local scope levels (0-31), and with appropriate privilege, you can see the dcl symbols
(and procedures) being used by other processes, even processes on other cluster nodes.

If makes debugging batch jobs much easier, because you are able to see the
"dcl variables" in use.

And in addition to reading DCL symbols, you can also set them, a feature that can
be useful to affect a running batch job.

Symbol can also be used to "return" a value to a local DCL symbol in the scope of
the invoker, using symbol /set/local/depth=-1

example: (this may be hard to follow, if you haven't played with DCL scoping)

HP$ show symbol symbol
SYMBOL == "$SYS$SYSDEVICE:[SYMBOL]SYMBOL"
HP$ symbol symbol
[-] SYMBOL == "$SYS$SYSDEVICE:[SYMBOL]SYMBOL"
HP$ write sys$output f$environment("depth")
0
$ abc = "def"
HP$ sho symbol /local abc
ABC = "def"
HP$ @tt
HP$ write sys$output f$environment("depth")
1
_HP$ symbol/show/local/depth=-1
[0] ABC = "def"
_HP$ show symbol /local abc
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
_HP$ show symbol abc
ABC = "def"
_HP$ abc = "xyz"
_HP$ sho sym abc
ABC = "xyz"
_HP$ symbol/show abc
[0] ABC = "def"
[1] ABC = "xyz"
_HP$ symbol/set/local/depth=-1 abc "ghi"
_HP$ sho sym abc
ABC = "xyz"
_HP$ symbol/show abc
[0] ABC = "ghi"
[1] ABC = "xyz"
_HP$ symbol/show/local/depth=-1
[0] ABC = "ghi"
_HP$ exit
HP$ write sys$output f$environment("depth")
0
HP$ sho symbol abc
ABC = "ghi"
HP$ sho symbol /local abc
ABC = "ghi"
HP$

In a command procedure it can even be used to see "who called me", a useful feature
when you are trying to determine what is using a command procedure.

$ symbol/show=(nosymbol,procedure) ! provide a call "traceback"

The point is, SYMBOL can do much more than the specific thing Brian explained.

Highly recommended.

VAXman-

unread,
Sep 1, 2021, 8:36:00 PMSep 1
to
In article <36dd9084-f7f4-4316...@googlegroups.com>, Jon Pinkley <jon.p...@gmail.com> writes:
>On Tuesday, August 31, 2021 at 6:05:33 PM UTC-4, VAXman- wrote:
>
>> Download and install SYMBOL. You can then read the help. In the interim, I'll
>> look into why the 'helpgate' is failing.
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
>>
>> I speak to machines with the voice of humanity.
>
>As someone that has used TMESIS SYMBOL for more than 25 years, on VAX, Alpha
>and Itanium, I will say it is well worth installing it. It's incredibly flexible and useful
>for many things. You can see all scope levels of DCL symbols, the global plus 32
>local scope levels (0-31), and with appropriate privilege, you can see the dcl symbols
>(and procedures) being used by other processes, even processes on other cluster nodes.
>
>If makes debugging batch jobs much easier, because you are able to see the
>"dcl variables" in use.

You ought to be using my DCL debugger to debug your batch job DCL. With it, you
can single step your DCL procedures and you have SYMBOL-like features and so much
more.
Thanks for your extolling words.

MG

unread,
Sep 2, 2021, 5:54:04 AMSep 2
to
On 31-Aug-2021 21:47, VAX...@SendSpamHere.ORG wrote:
> http://tmesis.com/symbol/

Thanks, but I see it's issued as an installation kit, so I can't use
it on DECUServe, since I don't have installation privileges/rights on
there, nor a VMS system of my own. (I'm waiting until the x86 version
of VMS appears for that and for the rest use DECUServe for my needs.)

Is there perhaps also a ‘portable’ version available, somehow; or do
you know if DECUServe was ever granted hobbyist licensing rights to
run it non-commercially, so to speak?

- MG

HCorte

unread,
Sep 2, 2021, 9:33:31 AMSep 2
to
One more question finished the command procedure, know whanted to pass a variable/symbol to a program in fortran.
Posted the question in "comp.lang.fortran" but forgoted to specify in the initial inquiry/question that was using OpenVMS.

One suggestion was to use "EXECUTE_COMMAND_LINE" that from what could tell its specific to Unix, and also "popen" from what could get also Unix specific is there a equivalent for OpenVMS?

$ FORTRAN /VERSION
HP Fortran V8.2-104939-50H96

$ SHOW SYSTEM
OpenVMS V8.4

VAXman-

unread,
Sep 2, 2021, 9:54:35 AMSep 2
to
SYMBOL is installed on Eisner (aka DECUServe), so you can use it there to
your heart's content.

DCLdebug is also installed on Eisner. Have fun.

VAXman-

unread,
Sep 2, 2021, 10:11:34 AMSep 2
to
There are several ways.

You could employ the CLI$ routines and your own command definition (.CLD).

... or...

You could place the value in a DCL symbol and then, in your program, call
LIB$GET_SYMBOL.

... or...

You could also use LIB$GET_FOREIGN or LIB$GET_INPUT to obtain a value for
use in your program.

... or...

Not knowing your Fortran program, you could also use a Fortran READ. If
it's in a DCL procedure, $ DEFINE/USER SYS$INPUT SYS$COMMAND just before
you run your Fortran program.

Dave Froble

unread,
Sep 2, 2021, 10:15:56 AMSep 2
to
If I understand your question, perhaps LIB$SPAWN is what you're looking for.

Or, to get the value of a symbol, use LIB$GETSYMBOL.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Arne Vajhøj

unread,
Sep 2, 2021, 10:18:50 AMSep 2
to
On 9/2/2021 9:33 AM, HCorte wrote:
You need to pass from DCL to Fortran?

If DCL get info and then run Fortran program there
are plenty of options:
- call Fortran program with argument
- set symbol and let Fortran call LIB$GET_SYMBOL
- define logical in process table and let Fortran call SYS$TRNLNM

If DCL and Fortran are running in different processes
then:
- define logical in job/group table and let Fortran call SYS$TRNLNM

Arne

HCorte

unread,
Sep 2, 2021, 11:36:59 AMSep 2
to
Thanks thats whant I needed, gona use LIB$SPAWN to run my command procedure and after get the symbol use LIB$GET_SYMBOL as suggested.

Stephen Hoffman

unread,
Sep 2, 2021, 12:01:43 PMSep 2
to
On 2021-09-02 13:33:29 +0000, HCorte said:

> One more question finished the command procedure, know whanted to pass
> a variable/symbol to a program in fortran.

DCL commonly uses symbols, and logical names, and files. DECnet is also
easy, IP and SSL/TLS connections lack good support.

For Fortran, reading values from DCL symbols (lib$get_symbol),
translating values from logical names (lib$get_logical), reading the
data from the command input (works when in command procedures), reading
the input from a file (generic Fortran file I/O, or using RMS from
Fortran), reading the input from the DCL output directly, and reading
the input from a network link (DECnet, as DCL doesn't play well with
UDP, TCP, SSL/TLS), etc.

Same as usual for reading input with any other Fortran programs on OpenVMS.

Here, lib$get_symbol and lib$get_logical calls are probably the most
direct path, though I'd be tempted to use a file (possibly with
delete-on-close disposition), given you're seemingly working with a
list, and given the available Fortran sequential file I/O support.

Biggest issue with Fortran for some of these cases tends to be parsing
data, as Fortran doesn't handle variable-length data all that well.

The Fortran user's manual is probably a good starting point for
learning about your options and alternatives when using Fortran on
OpenVMS:
https://vmssoftware.com/docs/VSI_FORTRAN_USER.pdf

As it can be inferred you're not completely comfortable with OpenVMS
and particularly with OpenVMS programming, some other documentation:
https://vmssoftware.com/docs/VSI_USERS_MANUAL.pdf
https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_I.pdf
https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_II.pdf

And since I've filled this reply with RTL calls, and this in
conjunction with the Fortran user's manual (above):
https://vmssoftware.com/docs/VSI_RTL_LIB$_MANUAL.pdf

> Posted the question in "comp.lang.fortran" but forgoted to specify in
> the initial inquiry/question that was using OpenVMS.
>
> One suggestion was to use "EXECUTE_COMMAND_LINE" that from what could
> tell its specific to Unix, and also "popen" from what could get also
> Unix specific is there a equivalent for OpenVMS?

If you're invoking the procedure directly—and I'm still not entirely
clear about what this whole thread is trying to achieve—then calling
lib$spawn is one possibility, though there are others.

> $ FORTRAN /VERSION
> HP Fortran V8.2-104939-50H96
>
> $ SHOW SYSTEM
> OpenVMS V8.4

That's all past a dozen years old, and the HP/HPE OpenVMS versions are
no longer receiving patches.

V8.4-2L1 (Alpha EV56 and older), V8.4-2L2, (Alpha EV6 and EV7), and
V8.4-2L3 (Itanium) are current, as is VSI Fortran V8.3-3.



--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

unread,
Sep 2, 2021, 1:43:53 PMSep 2
to
On 2021-09-02, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2021-09-02 13:33:29 +0000, HCorte said:
>
>> One more question finished the command procedure, know whanted to pass
>> a variable/symbol to a program in fortran.
>
> DCL commonly uses symbols, and logical names, and files. DECnet is also
> easy, IP and SSL/TLS connections lack good support.
>

Where is Stephen and what have you done with him ? :-)

Did anyone else notice that this imposter is recommending the OP
consider using DECnet ? :-)

Simon.

PS: $ set response/mode=good_natured just in case it is required. :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Arne Vajhøj

unread,
Sep 2, 2021, 2:04:00 PMSep 2
to
On 9/2/2021 11:36 AM, HCorte wrote:
> Thanks thats whant I needed, gona use LIB$SPAWN to run my command procedure and after get the symbol use LIB$GET_SYMBOL as suggested.

I think you will need logical!

$ type tf1.com
$ z == "ABC"
$ exit
$ type tf1.for
program tf1
character*256 s
integer*4 slen
call lib$spawn('@tf1')
call lib$get_symbol('z', s, slen)
write(*,*) s(1:slen)
end
$ for tf1
$ link tf1
$ run tf1
$ z == "ABC"
$ exit

$ type tf2.com
$ def/nolog/job z "ABC"
$ exit
$ type tf2.for
program tf2
character*256 s
integer*4 slen
call lib$spawn('@tf2')
call lib$get_logical('Z', s, slen)
write(*,*) s(1:slen)
end
$ for tf2
$ link tf2
$ run tf2
$ def/nolog/job z "ABC"
$ exit
ABC

Arne


Dave Froble

unread,
Sep 2, 2021, 6:42:14 PMSep 2
to
On 9/2/2021 1:43 PM, Simon Clubley wrote:
> On 2021-09-02, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>> On 2021-09-02 13:33:29 +0000, HCorte said:
>>
>>> One more question finished the command procedure, know whanted to pass
>>> a variable/symbol to a program in fortran.
>>
>> DCL commonly uses symbols, and logical names, and files. DECnet is also
>> easy, IP and SSL/TLS connections lack good support.
>>
>
> Where is Stephen and what have you done with him ? :-)
>
> Did anyone else notice that this imposter is recommending the OP
> consider using DECnet ? :-)
>
> Simon.
>
> PS: $ set response/mode=good_natured just in case it is required. :-)
>

DECnet has it's uses. If it works, work it ...

DECnet also has it's deficiencies.

Simon has his deficiencies.

Does Simon have any uses?

Dave Blorphy

unread,
Sep 2, 2021, 7:12:53 PMSep 2
to
On Thursday, September 2, 2021 at 11:36:59 AM UTC-4, HCorte wrote:
> Thanks thats whant I needed, gona use LIB$SPAWN to run my command procedure and after get the symbol use LIB$GET_SYMBOL as suggested.
Re-Read Arne's response.
DCL symbols are process local. By the time your program regains control after
the lib$spawn, (unless you specified nowait), the process that created the DCL
symbol will be gone, and with it the symbol. And lib$get_symbol can't obtain
DCL symbols from another process, even if the process was still there.
There are other mechanisms that could work, but before going further, what
problem are you trying to solve, and why do you think this is solution to the problem.
See https://xyproblem.info/

MG

unread,
Sep 2, 2021, 7:18:04 PMSep 2
to
On 02-Sep-2021 15:54, VAX...@SendSpamHere.ORG wrote:
> SYMBOL is installed on Eisner (aka DECUServe), so you can use it there to
> your heart's content.
>
> DCLdebug is also installed on Eisner. Have fun.

Thank you and that's fascinating actually, I actually came across
"SYMBOL" before (when I was looking through the 'global' symbol
definitions), then ran it briefly. At the time I didn't realize
that you made it and I looked at it earlier and I must say it's
very nice and useful.

VSI ought to consider contacting you in order to propose and then
to hopefully reach some kind of deal to be able to integrate your
program into the base VMS operating system, a bit like what
happened with the LD driver at some point.

- MG

Simon Clubley

unread,
Sep 3, 2021, 2:30:35 PMSep 3
to
On 2021-09-02, Dave Froble <da...@tsoft-inc.com> wrote:
>
> DECnet has it's uses. If it works, work it ...
>
> DECnet also has it's deficiencies.
>
> Simon has his deficiencies.
>
> Does Simon have any uses?
>

Well, Simon certainly thinks so. :-)

In the 1980s, DECnet's good points outweighed its bad points.

In the changed world of 2021, that is no longer true.

Simon.

VAXman-

unread,
Sep 3, 2021, 4:41:54 PMSep 3
to
In article <sgtpk8$cjn$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-09-02, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> DECnet has it's uses. If it works, work it ...
>>
>> DECnet also has it's deficiencies.
>>
>> Simon has his deficiencies.
>>
>> Does Simon have any uses?
>>
>
>Well, Simon certainly thinks so. :-)
>
>In the 1980s, DECnet's good points outweighed its bad points.
>
>In the changed world of 2021, that is no longer true.

Good points that haven't been outweighed...

When will TCP/IP support record access?

When will TCP/IP support $@<node>::<device>:[<directory>]<filename>.COM?

Dave Froble

unread,
Sep 3, 2021, 5:35:48 PMSep 3
to
On 9/3/2021 2:30 PM, Simon Clubley wrote:
> On 2021-09-02, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> DECnet has it's uses. If it works, work it ...
>>
>> DECnet also has it's deficiencies.
>>
>> Simon has his deficiencies.
>>
>> Does Simon have any uses?
>>
>
> Well, Simon certainly thinks so. :-)
>
> In the 1980s, DECnet's good points outweighed its bad points.
>
> In the changed world of 2021, that is no longer true.
>
> Simon.
>

Doesn't that sort of depend on what one wishes to use it for?

Dave Froble

unread,
Sep 3, 2021, 5:39:26 PMSep 3
to
On 9/3/2021 2:30 PM, Simon Clubley wrote:
> On 2021-09-02, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> DECnet has it's uses. If it works, work it ...
>>
>> DECnet also has it's deficiencies.
>>
>> Simon has his deficiencies.
>>
>> Does Simon have any uses?
>>
>
> Well, Simon certainly thinks so. :-)
>
> In the 1980s, DECnet's good points outweighed its bad points.
>
> In the changed world of 2021, that is no longer true.
>
> Simon.
>

Might I suggest that DECnet is as good as it's ever been. What you're
calling "bad points" is more like an omission than a bad point.

Name one thing on this planet that has "everything".

Hein RMS van den Heuvel

unread,
Sep 4, 2021, 8:57:20 PMSep 4
to
On Tuesday, August 31, 2021 at 5:49:46 AM UTC-4, HCorte wrote:
> Implementing a command procedure that first obtains the device allocated to a process for example purposes called YYYYYY.
>
> How to output the results of (SEARCH SYS$INPUT "Devices allocated") to the variable DEVICEAUX tried (READ SYS$PIPE DEVICEAUX) but with no success.
>
> $ pipe SH PROCESS YYYYYY | SEARCH SYS$INPUT "Devices allocated" | (READ SYS$PIPE DEVICEAUX)
> $ WRITE SYS$OUTPUT DEVICEAUX
> $ DEVICE_AUX = F$EDIT(F$ELEMENT(1, ":", TEST),"TRIM")
> $ WRITE SYS$OUTPUT DEVICE_AUX
>
> can make it work to write to a file
> $ pipe SH PROCESS SCMLCOMOLM | SEARCH SYS$PIPE "Devices allocated" > DEVICEAUX.DAT
>
> but would prefer to avoid having to write and read from file if possible, also in command procedure should alls use SYS$PIPE instead of SYS$INPUT?

Eisner - HTTP$SERVER

$ perl -e "for (qx(show proc /id=00078E34)) { push @dev,$1 if / (\w+\d+):$/} print join q(,),@dev "
EWA133,BG25512,BG25513,BG25514, ....

or

$ perl -e "for (qx(show proc /id=00078E34)) { push @dev,$1 if / (\w+\d+):$/} $ENV{test} = join q(,),@dev "
$ show log test
"TEST" = "EWA133,BG25512,BG25513,BG25514, ... " (LNM$PROCESS_TABLE)

Narration:

-e = "execute following string as Perl program"

for ( ... ) { ... } = loop over output from whatever is delivered between parens into default variable $_ and execute block each time.
qx = execute in sub-process, delivering to output lines to for loop
block:
push array, element $1
IFF
there is a match ( /.../ ) in value of default variable $_
ON a space (paren to start remembering into $1) followed by some word chars and some numbers (stop remembering) and a colon at end-of-line.
end block
end loop
q(,) = single quoted string = non-interpolated string holding a comma ! Could have used qq(,) as wel for double quoted - no difference in this case.

set associative array ENV (which maps only Logicals and Symbols) element 'test' to become all devices names joined, separated with a comma between each.

Enjoy,
Hein


Simon Clubley

unread,
Sep 6, 2021, 8:24:39 AMSep 6
to
On 2021-09-03, Dave Froble <da...@tsoft-inc.com> wrote:
> On 9/3/2021 2:30 PM, Simon Clubley wrote:
>>
>> In the 1980s, DECnet's good points outweighed its bad points.
>>
>> In the changed world of 2021, that is no longer true.
>>
>
> Might I suggest that DECnet is as good as it's ever been. What you're
> calling "bad points" is more like an omission than a bad point.
>

The world changed David, but DECnet did not.

Just one example: the implementation of proxies in DECnet opens up
a _massive_ security hole in today's world as DECnet was designed
in a world where you assumed 100% trust in the network and in all
the devices attached to it.

This is because there are no shared secrets or certificates between
the nodes which have proxies between them so it is trivial for someone
with any access to the network to impersonate a DECnet node, if they
manage to disable the real node (to avoid conflicting MAC addresses
and to avoid responses from the real node) or if the real node is not
online all the time.

The idea that a machine can impersonate a server simply by using the
same network address without needing any other information such as
certificates or shared secrets is unacceptable today.

Outside of that, DECnet itself is about as secure as Telnet or plain
FTP and we all know how those two protocols are regarded on internal
networks these days...

Scott Dorsey

unread,
Sep 6, 2021, 10:52:07 AMSep 6
to
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>Just one example: the implementation of proxies in DECnet opens up
>a _massive_ security hole in today's world as DECnet was designed
>in a world where you assumed 100% trust in the network and in all
>the devices attached to it.

There are still plenty of networks where you can make that assumption.
The internet is not one. But not everything is the internet, no matter
how hard the "cloud people" try to make everyone think it is.

A lot of bad things happened in the opening of the internet when protocols
designed that way suddenly had to be used over untrusted links. Even worse
stuff happened to the telephone network when SS7 was extended onto untrusted
links. But not all networks have untrusted links.

>The idea that a machine can impersonate a server simply by using the
>same network address without needing any other information such as
>certificates or shared secrets is unacceptable today.

It's certainly unacceptable on the internet, but not everything is the
internet.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Dave Froble

unread,
Sep 6, 2021, 10:58:22 AMSep 6
to
On 9/6/2021 8:24 AM, Simon Clubley wrote:
> On 2021-09-03, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 9/3/2021 2:30 PM, Simon Clubley wrote:
>>>
>>> In the 1980s, DECnet's good points outweighed its bad points.
>>>
>>> In the changed world of 2021, that is no longer true.
>>>
>>
>> Might I suggest that DECnet is as good as it's ever been. What you're
>> calling "bad points" is more like an omission than a bad point.
>>
>
> The world changed David, but DECnet did not.

Yeah, that's right, so? Sort of what I wrote ...

> Just one example: the implementation of proxies in DECnet opens up
> a _massive_ security hole in today's world as DECnet was designed
> in a world where you assumed 100% trust in the network and in all
> the devices attached to it.
>
> This is because there are no shared secrets or certificates between
> the nodes which have proxies between them so it is trivial for someone
> with any access to the network to impersonate a DECnet node, if they
> manage to disable the real node (to avoid conflicting MAC addresses
> and to avoid responses from the real node) or if the real node is not
> online all the time.
>
> The idea that a machine can impersonate a server simply by using the
> same network address without needing any other information such as
> certificates or shared secrets is unacceptable today.
>
> Outside of that, DECnet itself is about as secure as Telnet or plain
> FTP and we all know how those two protocols are regarded on internal
> networks these days...

As I wrote, an omission.

Do you have all that stuff as boilerplate somewhere, so you can cut n
paste every day or two?

Arne Vajhøj

unread,
Sep 6, 2021, 7:38:42 PMSep 6
to
There are lots of networks where outsider hackers do not have
access.

But when you start worrying about insider hackers then it becomes
more problematic.

Arne




Scott Dorsey

unread,
Sep 6, 2021, 9:57:54 PMSep 6
to
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>
>There are lots of networks where outsider hackers do not have
>access.
>
>But when you start worrying about insider hackers then it becomes
>more problematic.

The problem is that, although internal network encryption and data
compartmentalization can help a little bit against internal attacks,
in the end it almost always breaks down.

There is really very little that anyone can do about internal attacks
other than to pay their employees well and treat them with respect.
Surprisingly, a lot of companies find these two things nearly impossible
to implement.

Arne Vajhøj

unread,
Sep 7, 2021, 8:37:56 AMSep 7
to
It is difficulty to protect against insiders, but I do not see that as
a valid excuse for not adding some measures.

Just imagine the argument "It is difficult to protect against insiders
so we we are OK with all VMS users having SETPRV".

Nobody would buy that.

My biggest concern with the focus on plain text passwords and
non authenticating network protocols is what that focus could
have been used on instead.

If prioritizing between that stuff and let us say application
security and third party software patching, then that stuff is
less important.

The problem is that it is way easier to focus on that stuff.

Arne

VAXman-

unread,
Sep 7, 2021, 9:19:51 AMSep 7
to
In article <sh5aab$7ko$1...@dont-email.me>, Dave Froble <da...@tsoft-inc.com> writes:
>On 9/6/2021 8:24 AM, Simon Clubley wrote:
>> On 2021-09-03, Dave Froble <da...@tsoft-inc.com> wrote:
>>> On 9/3/2021 2:30 PM, Simon Clubley wrote:
>>>>
>>>> In the 1980s, DECnet's good points outweighed its bad points.
>>>>
>>>> In the changed world of 2021, that is no longer true.
>>>>
>>>
>>> Might I suggest that DECnet is as good as it's ever been. What you're
>>> calling "bad points" is more like an omission than a bad point.
>>>
>>
>> The world changed David, but DECnet did not.
>
>Yeah, that's right, so? Sort of what I wrote ...
>
>> Just one example: the implementation of proxies in DECnet opens up
>> a _massive_ security hole in today's world as DECnet was designed
>> in a world where you assumed 100% trust in the network and in all
>> the devices attached to it.
>>
>> This is because there are no shared secrets or certificates between
>> the nodes which have proxies between them so it is trivial for someone
>> with any access to the network to impersonate a DECnet node, if they
>> manage to disable the real node (to avoid conflicting MAC addresses
>> and to avoid responses from the real node) or if the real node is not
>> online all the time.
>>
>> The idea that a machine can impersonate a server simply by using the
>> same network address without needing any other information such as
>> certificates or shared secrets is unacceptable today.
>>
>> Outside of that, DECnet itself is about as secure as Telnet or plain
>> FTP and we all know how those two protocols are regarded on internal
>> networks these days...
>
>As I wrote, an omission.
>
>Do you have all that stuff as boilerplate somewhere, so you can cut n
>paste every day or two?

My buddy Simon has completely ignored my comments on record oriented access
over DECnet. I believe he speaks and types only to hear and read himself.

Phillip Helbig (undress to reply)

unread,
Sep 7, 2021, 12:16:33 PMSep 7
to
In article <00B68751...@SendSpamHere.ORG>, VAXman-
@SendSpamHere.ORG writes:

> My buddy Simon has completely ignored my comments on record oriented access
> over DECnet. I believe he speaks and types only to hear and read himself.

I remember a game called Simon Says. :-)

Simon Clubley

unread,
Sep 7, 2021, 1:58:13 PMSep 7
to
On 2021-09-07, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>
> My buddy Simon has completely ignored my comments on record oriented access
> over DECnet. I believe he speaks and types only to hear and read himself.
>

As you should well know Brian, using an insecure protocol in an insecure
environment just because of a certain feature is utterly irresponsible
from a security point of view.

This isn't even appropriate any more for protocols that offer major
unique functionality such as VMS clusters. Why do you think VSI,
with everything else they need to do, are investing time and effort
into adding a secure layer to the clustering protocol ?

No, you should look for alternatives or find a different way to do
things. That's why telnet is banned (for example) and ssh is enforced
on many networks today. Everyone else manages to solve data sharing
problems using secure techniques available on those other platforms.
If VMS doesn't have those secure options, then that's a failing in VMS.

BTW, record access is a feature that is a unique VMS requirement. You could
try the VMS versions of NFS which supports the storing of VMS attributes.
However, do any of the VMS NFS implementations support the NFS 4 protocol
with secure links ?

As for file sharing in general, other people do it by using clustering
protocols, remotely mounting filesystems or just copying the files.
Examples include NFS, Samba, and GFS2.

Linux has also recently acquired the ability to mount filesystems over
SSH, but you are unlikely to ever see that in VMS due to VMS's utter
inability to support userspace filesystems.

Times have changed and VMS needs to keep up with those times if it
is to remain usable in many of today's environments. Telling everyone
else to stand still so that VMS can still play is not a viable approach.

One final question: If DAP would be so wonderful to the world in general,
then why isn't there a TCP/IP version of DAP ? (WebDAV doesn't really
count IMHO unless it's moved on recently). There's a standardised TCP/IP
version of every other application protocol.

Simon Clubley

unread,
Sep 7, 2021, 2:03:46 PMSep 7
to
Hey! You are the guy who refuses to use anything other than a LK
keyboard and claims to have stockpiled decades worth of replacements
because he's so stuck in his ways. :-)

You are also the guy who still thinks that VMS workstations are a
viable desktop computer... :-)

I, OTOH, actively look at new ideas to see if they have any good parts
to them that I can use or if they are just a fad that will die off within
a couple of years...

Bill Gunshannon

unread,
Sep 7, 2021, 2:14:18 PMSep 7
to
On 9/7/21 2:03 PM, Simon Clubley wrote:
> On 2021-09-07, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>> In article <00B68751...@SendSpamHere.ORG>, VAXman-
>> @SendSpamHere.ORG writes:
>>
>>> My buddy Simon has completely ignored my comments on record oriented access
>>> over DECnet. I believe he speaks and types only to hear and read himself.
>>
>> I remember a game called Simon Says. :-)
>>
>
> Hey! You are the guy who refuses to use anything other than a LK
> keyboard and claims to have stockpiled decades worth of replacements
> because he's so stuck in his ways. :-)
>
> You are also the guy who still thinks that VMS workstations are a
> viable desktop computer... :-)

What's wrong with that? :-)

>
> I, OTOH, actively look at new ideas to see if they have any good parts
> to them that I can use or if they are just a fad that will die off within
> a couple of years...
>
> Simon.
>

bill

Stephen Hoffman

unread,
Sep 7, 2021, 4:40:41 PMSep 7
to
On 2021-09-07 17:58:10 +0000, Simon Clubley said:

> One final question: If DAP would be so wonderful to the world in
> general, then why isn't there a TCP/IP version of DAP ? (WebDAV doesn't
> really count IMHO unless it's moved on recently). There's a
> standardised TCP/IP version of every other application protocol.

The FAL/DAP analog is called ODBC, and the ODBC CLI API.

libferris (inactive) has the sorts of features that FAL/DAP might have
had added, after substantial new development work. Or Plan 9, the Unix
analog to what DEC MICA was to OpenVMS, of course.

For those not needing ODBC or libferris or ilk, SMB and other shares
meet the requirements for many if not most users.

VSI could certainly provide an ODBC client within RMS and an ODBC
server akin to the DECnet FAL server. Or could route DAP over IP
SSL/TLS if they were inclined. (Though IP integration on OpenVMS is
weak, and SSL/TLS weaker.) Or the flexibility of something like the
libferris FUSE. Having an SMB client would be nice, as many sites have
substantial investments in SMB servers. But I digress.

Last substantive IP integration work I can recall was with OpenVMS
V6.2, and work on a DECnet migration path has been sparse. DECnet was
mostly-feature-frozen a ~quarter-century ago, too.

But if you're on an old and unsupported OpenVMS version and with old
and unsupported tools and doing unsupported things such as parsing
command output from DCL for an absent $getjpi feature, security is
seemingly well down on the list of development considerations.

Coincidentally, Brian worked on part of an ODBC product allowing access
into RMS files, IIRC.

And apropos of little else here, OpenSSL 3.0.0 (not to be confused with
SSLv3) is now available. And the Windows Registry FUSE Filesystem
(winregfs) is kinda cute.

Arne Vajhøj

unread,
Sep 7, 2021, 4:55:19 PMSep 7
to
On 9/7/2021 4:40 PM, Stephen Hoffman wrote:
> On 2021-09-07 17:58:10 +0000, Simon Clubley said:
>
>> One final question: If DAP would be so wonderful to the world in
>> general, then why isn't there a TCP/IP version of DAP ? (WebDAV
>> doesn't really count IMHO unless it's moved on recently). There's a
>> standardised TCP/IP version of every other application protocol.
>
> The FAL/DAP analog is called ODBC, and the ODBC CLI API.
>
> libferris (inactive) has the sorts of features that FAL/DAP might have
> had added, after substantial new development work.  Or Plan 9, the Unix
> analog to what DEC MICA was to OpenVMS, of course.
>
> For those not needing ODBC or libferris or ilk, SMB and other shares
> meet the requirements for many if not most users.
>
> VSI could certainly provide an ODBC client within RMS and an ODBC server
> akin to the DECnet FAL server. Or could route DAP over IP SSL/TLS if
> they were inclined. (Though IP integration on OpenVMS is weak, and
> SSL/TLS weaker.) Or the flexibility of something like the libferris
> FUSE. Having an SMB client would be nice, as many sites have substantial
> investments in SMB servers. But I digress.

ODBC is a relational database API and pretty far from
DECnet file access in my opinion. ODBC to an index-sequential
file makes sense and I believe that such exist. But the
data model for a sequential files does not match with ODBC.

If write access to a sequential file is needed then I think
alternatives would be SMB mount or NFS mount. Read access
could be provided by one of the common file download protocols.

Arne

Stephen Hoffman

unread,
Sep 7, 2021, 5:51:59 PMSep 7
to
On 2021-09-07 20:55:18 +0000, Arne Vajh j said:

> On 9/7/2021 4:40 PM, Stephen Hoffman wrote:
>> On 2021-09-07 17:58:10 +0000, Simon Clubley said:
>>
>>> One final question: If DAP would be so wonderful to the world in
>>> general, then why isn't there a TCP/IP version of DAP ? (WebDAV doesn't
>>> really count IMHO unless it's moved on recently). There's a
>>> standardised TCP/IP version of every other application protocol.
>>
>> The FAL/DAP analog is called ODBC, and the ODBC CLI API.
>>
>> libferris (inactive) has the sorts of features that FAL/DAP might have
>> had added, after substantial new development work.  Or Plan 9, the Unix
>> analog to what DEC MICA was to OpenVMS, of course.
>>
>> For those not needing ODBC or libferris or ilk, SMB and other shares
>> meet the requirements for many if not most users.
>>
>> VSI could certainly provide an ODBC client within RMS and an ODBC
>> server akin to the DECnet FAL server. Or could route DAP over IP
>> SSL/TLS if they were inclined. (Though IP integration on OpenVMS is
>> weak, and SSL/TLS weaker.) Or the flexibility of something like the
>> libferris FUSE. Having an SMB client would be nice, as many sites have
>> substantial investments in SMB servers. But I digress.
>
> ODBC is a relational database API and pretty far from DECnet file
> access in my opinion.


I recall similar discussions with someone of the opinion that there was
a functional difference between NTDS† and NFS, me then and still being
of the opinion that NTDS was a proper subset of what an NFS server can
provide.

Here, NOSQL RMS databases can be remotely accessed by key (whether a
"real" key or synthetic) within hypothetically-integrated ODBC support,
the same as database records can be accessed by database index.

Apps using the RMS APIs would be oblivious of ODBC or of some SSL/TLS
DAP connection, too.

(Not that I've expended appreciable effort remotely accessing
individual records in a sequential file via DECnet in far too many
years. Or much effort with DECnet, for that matter. I have used DECnet
a few times, when I needed to remotely bounce the IP stack, and with no
iLO access available. New app work involving DECnet FAL/DAP, not so
much.)

I just don't see the RMS NOSQL formats as being particularly useful for
substantive new development work, either. Where I am using those NOSQL
RMS file formats is largely due to gaps in feature availability within
OpenVMS.

And as mentioned above, I wouldn't mind an SMB client for OpenVMS. A
client for WebDAV, too.


†NTDS: Windows NT Disk Services, part of OpenVMS NT Affinity, another
forerunner of SMB.

VAXman-

unread,
Sep 7, 2021, 7:36:31 PMSep 7
to
In article <sh897i$sek$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-09-07, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>>
>> My buddy Simon has completely ignored my comments on record oriented access
>> over DECnet. I believe he speaks and types only to hear and read himself.
>>
>
>One final question: If DAP would be so wonderful to the world in general,
>then why isn't there a TCP/IP version of DAP ? (WebDAV doesn't really
>count IMHO unless it's moved on recently). There's a standardised TCP/IP
>version of every other application protocol.
>
>Simon.

Thank you for proving my point.

Dave Froble

unread,
Sep 8, 2021, 3:07:26 AMSep 8
to
On 9/7/2021 1:58 PM, Simon Clubley wrote:
> On 2021-09-07, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>>
>> My buddy Simon has completely ignored my comments on record oriented access
>> over DECnet. I believe he speaks and types only to hear and read himself.
>>
>
> As you should well know Brian, using an insecure protocol in an insecure
> environment just because of a certain feature is utterly irresponsible
> from a security point of view.

Ayep! It's boilerplate ...

> This isn't even appropriate any more for protocols that offer major
> unique functionality such as VMS clusters. Why do you think VSI,
> with everything else they need to do, are investing time and effort
> into adding a secure layer to the clustering protocol ?

Appropriate depends on usage, right?

> No, you should look for alternatives or find a different way to do
> things.

Why? If the usage doesn't have downsides, then why not use it?

> That's why telnet is banned (for example) and ssh is enforced
> on many networks today.

Where outside security is required, sure. Otherwise, Telnet works just
fine.

> Everyone else manages to solve data sharing
> problems using secure techniques available on those other platforms.

If they need to, sure.

> If VMS doesn't have those secure options, then that's a failing in VMS.

Omission, not failing ...

> BTW, record access is a feature that is a unique VMS requirement.

Yep, we got it, and you don't. Eat your heart out ...

> You could
> try the VMS versions of NFS which supports the storing of VMS attributes.
> However, do any of the VMS NFS implementations support the NFS 4 protocol
> with secure links ?
>
> As for file sharing in general, other people do it by using clustering
> protocols, remotely mounting filesystems or just copying the files.
> Examples include NFS, Samba, and GFS2.

Don't like them.

> Linux has also recently acquired the ability to mount filesystems over
> SSH, but you are unlikely to ever see that in VMS due to VMS's utter
> inability to support userspace filesystems.

Don't like Linux.

> Times have changed and VMS needs to keep up with those times if it
> is to remain usable in many of today's environments.

Nothing is usable everywhere.

> Telling everyone
> else to stand still so that VMS can still play is not a viable approach.

Who is telling anyone to stand still?

> One final question: If DAP would be so wonderful to the world in general,
> then why isn't there a TCP/IP version of DAP ? (WebDAV doesn't really
> count IMHO unless it's moved on recently). There's a standardised TCP/IP
> version of every other application protocol.

Perhaps some don't realize what they are missing?

Simon Clubley

unread,
Sep 8, 2021, 8:20:24 AMSep 8
to
On 2021-09-08, Dave Froble <da...@tsoft-inc.com> wrote:
> On 9/7/2021 1:58 PM, Simon Clubley wrote:
>> On 2021-09-07, VAXman- @SendSpamHere.ORG <VAX...@SendSpamHere.ORG> wrote:
>>>
>>> My buddy Simon has completely ignored my comments on record oriented access
>>> over DECnet. I believe he speaks and types only to hear and read himself.
>>>
>>
>> As you should well know Brian, using an insecure protocol in an insecure
>> environment just because of a certain feature is utterly irresponsible
>> from a security point of view.
>
> Ayep! It's boilerplate ...
>

No. It's saying the things that need to be said.

>> This isn't even appropriate any more for protocols that offer major
>> unique functionality such as VMS clusters. Why do you think VSI,
>> with everything else they need to do, are investing time and effort
>> into adding a secure layer to the clustering protocol ?
>
> Appropriate depends on usage, right?
>

No. It also depends on environment.

>> No, you should look for alternatives or find a different way to do
>> things.
>
> Why? If the usage doesn't have downsides, then why not use it?
>

Downsides increase over time, if something remains static while everything
else changes around it.

>> That's why telnet is banned (for example) and ssh is enforced
>> on many networks today.
>
> Where outside security is required, sure. Otherwise, Telnet works just
> fine.
>

Telnet is banned on many internal networks these days when the target
is an internal server. If you don't understand why, then you don't
understand the problem.

>> You could
>> try the VMS versions of NFS which supports the storing of VMS attributes.
>> However, do any of the VMS NFS implementations support the NFS 4 protocol
>> with secure links ?
>>
>> As for file sharing in general, other people do it by using clustering
>> protocols, remotely mounting filesystems or just copying the files.
>> Examples include NFS, Samba, and GFS2.
>
> Don't like them.
>

Would you prefer to go back to the days of UUCP links ? :-)

>> Linux has also recently acquired the ability to mount filesystems over
>> SSH, but you are unlikely to ever see that in VMS due to VMS's utter
>> inability to support userspace filesystems.
>
> Don't like Linux.
>

Very short sighted. There are things which have been added to Linux
to address current security issues that VMS could well do with.

>> Times have changed and VMS needs to keep up with those times if it
>> is to remain usable in many of today's environments.
>
> Nothing is usable everywhere.
>

If VMS is to remain viable, it needs to be usable in today's world.

>> Telling everyone
>> else to stand still so that VMS can still play is not a viable approach.
>
> Who is telling anyone to stand still?
>

Everytime someone says a 30-year-old network security model in VMS
is still viable for use on networks today.

Lawrence D’Oliveiro

unread,
Sep 22, 2021, 3:59:19 AMSep 22
to
On Wednesday, September 8, 2021 at 5:58:13 AM UTC+12, Simon Clubley wrote:
> Linux has also recently acquired the ability to mount filesystems over
> SSH, but you are unlikely to ever see that in VMS due to VMS's utter
> inability to support userspace filesystems.

I think how that actually works is that Linux has long implemented filesystems through a VFS indirection layer, which is how it’s able to handle all kinds of different volume formats (e.g. DOS FAT, ISO 9660, Apple HFS+, Windows NTFS, old IRIX XFS, MINIX etc). But these would normally all require in-kernel drivers. So FUSE (“Filesystem in Userspace”) implements a single generic in-kernel filesystem driver on top of VFS, that offers an API to userland processes. And this is used by a whole bunch of additional packages like sshfs, mtpfs, winregfs etc. In fact, the FUSE version of NTFS is actually more full-featured than the kernel version.

Simon Clubley

unread,
Sep 22, 2021, 8:40:58 AMSep 22
to
On 2021-09-22, Lawrence D?Oliveiro <lawren...@gmail.com> wrote:
> On Wednesday, September 8, 2021 at 5:58:13 AM UTC+12, Simon Clubley wrote:
>> Linux has also recently acquired the ability to mount filesystems over
>> SSH, but you are unlikely to ever see that in VMS due to VMS's utter
>> inability to support userspace filesystems.
>
> I think how that actually works is that Linux has long implemented filesystems through a VFS indirection layer, which is how it?s able to handle all kinds of different volume formats (e.g. DOS FAT, ISO 9660, Apple HFS+, Windows NTFS, old IRIX XFS, MINIX etc). But these would normally all require in-kernel drivers. So FUSE (?Filesystem in Userspace?) implements a single generic in-kernel filesystem driver on top of VFS, that offers an API to userland processes. And this is used by a whole bunch of additional packages like sshfs, mtpfs, winregfs etc. In fact, the FUSE version of NTFS is actually more full-featured than the kernel version.

Yes, that's how it works.

VMS has absolutely nothing like the FUSE support Linux does.

It does have ACPs to handle some _devices_ in process context, but they
are nothing like FUSE and ACPs are very ugly to implement anyway.
Also, good luck finding any public documentation for writing an ACP.

VMS doesn't even have anything like the filesystem kernel plugin modules
that you see in Linux and elsewhere. The VMS architecture simply isn't
setup to support anything like that.

BTW, did you know that once you load a device driver into VMS, you
can't even remove it unlike what you can do elsewhere ?

abrsvc

unread,
Sep 22, 2021, 11:44:20 AMSep 22
to

>
> BTW, did you know that once you load a device driver into VMS, you
> can't even remove it unlike what you can do elsewhere ?
> Simon.

The above statement is not 100% true. There are some drivers that can be unloaded. Granted these are few, but the mechanism is there, but rarely used.

Stephen Hoffman

unread,
Sep 22, 2021, 1:13:27 PMSep 22
to
On 2021-09-22 15:44:18 +0000, abrsvc said:

>> BTW, did you know that once you load a device driver into VMS, you
>> can't even remove it unlike what you can do elsewhere ?
>
> The above statement is not 100% true. There are some drivers that can
> be unloaded. Granted these are few, but the mechanism is there, but
> rarely used.

AFAIK, there's no supported means to remove an OpenVMS device driver.

It is possible to remove device units for template devices. But that
does not remove the device driver.

And it was possible—though AFAIK now entirely unsupported—to code a
device driver to tolerate re-loading with SYSGEN RELOAD. Usually.

There might once have been some UNLOAD hooks around.

AFAIK, there's no API to quiesce an OpenVMS driver and to allow the
driver to complete or to cancel its pending I/O operations and to
deallocate resources.

Semi-related alternatives from elsewhere:

Linux added no-reboot support for patching a while back. Search targets
for different Linux distros include LivePatch, Kpatch, Ksplice, Kgraft,
KernelCare.

kexec replaces the running kernel with a different kernel, a form of
rebooting without a trip through the console.

Various hypervisors can fail over to a second hypervisor host
dynamically, though it remains to be seen if that will work with
OpenVMS on x86-64, or with clustered OpenVMS hosts on x86-64.

Simon Clubley

unread,
Sep 22, 2021, 1:16:24 PMSep 22
to
Excellent Dan. For Alpha what is the unload command I use and where
is this documented ? How exactly does this command trigger the execution
of unload code in the driver so the driver can clean up its resource
use prior to the final unload ?

Also, do you happen to know why, when I have mentioned this in the past,
I was told it wasn't possible ?

Thanks,

abrsvc

unread,
Sep 22, 2021, 1:22:12 PMSep 22
to
I don't have a recent example as I have not been involved of late with drivers. However, the ability is there if the driver is written to handle it. I never said that any of the standard drivers supplied as part of OpenVMS could do this as I am not aware of one that can. However, making a statement that this is not possible is in fact, false. There have been drivers in the past that could be unloaded and I am sure that one could be written today that could as well.

Simon Clubley

unread,
Sep 22, 2021, 1:33:42 PMSep 22
to
On 2021-09-22, abrsvc <dansabr...@yahoo.com> wrote:
> I don't have a recent example as I have not been involved of late with drivers. However, the ability is there if the driver is written to handle it. I never said that any of the standard drivers supplied as part of OpenVMS could do this as I am not aware of one that can. However, making a statement that this is not possible is in fact, false. There have been drivers in the past that could be unloaded and I am sure that one could be written today that could as well.

Actually, I'm talking about support in VMS for such a feature, not
whether it is in the standard drivers or not.

Back when I was writing drivers on Alpha VMS as part of hobby projects,
I would have loved the ability to do that, but I was told here that it
wasn't possible.

I was told that VAX/VMS had some basic form of unload or reload capability
but even that limited capability was not included in later versions of VMS.

Stephen Hoffman

unread,
Sep 22, 2021, 1:43:54 PMSep 22
to
On 2021-09-22 12:40:57 +0000, Simon Clubley said:

> It does have ACPs to handle some _devices_ in process context, but they
> are nothing like FUSE and ACPs are very ugly to implement anyway.
> Also, good luck finding any public documentation for writing an ACP.

I've written a number of ACPs. They're not ~too bad. Some of the
debugging tips I've posed over the years arise from debugging ACPs.

What little ACP doc is available (the VMS Advanced Driver Techniques
book, etc) alone won't get you past writing your own MOUNT though.

Both for mounting your non-file-structured devices, and for use with
different file systems.

In various ways, assumptions in MOUNT are tied more deeply into the
file system than is the design of the ACP APIs.

HCorte

unread,
Oct 1, 2021, 12:10:31 PMOct 1