Discussion:
Command Procedure Pipe output to a variable
Add Reply
HCorte
2021-08-31 09:49:45 UTC
Reply
Permalink
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
2021-08-31 10:43:29 UTC
Reply
Permalink
Post by HCorte
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?
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
HCorte
2021-08-31 11:05:17 UTC
Reply
Permalink
Post by ***@pitbulluk.org
Post by HCorte
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?
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?
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
2021-08-31 11:30:46 UTC
Reply
Permalink
Post by HCorte
Post by ***@pitbulluk.org
Post by HCorte
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?
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?
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.
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.
MG
2021-08-31 10:57:26 UTC
Reply
Permalink
Post by HCorte
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?
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
Jim
2021-08-31 12:11:59 UTC
Reply
Permalink
Post by HCorte
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?
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
V***@SendSpamHere.ORG
2021-08-31 12:33:42 UTC
Reply
Permalink
Post by Jim
Post by HCorte
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?
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
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
2021-08-31 15:41:58 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
$ 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
V***@SendSpamHere.ORG
2021-08-31 19:47:31 UTC
Reply
Permalink
Post by MG
Post by V***@SendSpamHere.ORG
$ 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/
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Phillip Helbig (undress to reply)
2021-08-31 20:01:36 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
Post by MG
Post by V***@SendSpamHere.ORG
$ 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])
V***@SendSpamHere.ORG
2021-08-31 22:05:28 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by V***@SendSpamHere.ORG
Post by MG
Post by V***@SendSpamHere.ORG
$ 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
Requested script (helpgate) not found in htbin directory (www_root:[bin])
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.
Jon Pinkley
2021-09-01 23:09:17 UTC
Reply
Permalink
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.
V***@SendSpamHere.ORG
2021-09-02 00:35:54 UTC
Reply
Permalink
Post by Jon Pinkley
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.
Post by Jon Pinkley
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$ 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.
Thanks for your extolling words.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
MG
2021-09-02 09:51:20 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
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
V***@SendSpamHere.ORG
2021-09-02 13:54:32 UTC
Reply
Permalink
Post by MG
Post by V***@SendSpamHere.ORG
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?
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- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
MG
2021-09-02 23:16:01 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
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
V***@SendSpamHere.ORG
2021-09-02 14:11:31 UTC
Reply
Permalink
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
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.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Dave Froble
2021-09-02 14:12:47 UTC
Reply
Permalink
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
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-02 14:18:45 UTC
Reply
Permalink
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
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
Arne Vajhøj
2021-09-02 18:03:55 UTC
Reply
Permalink
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
Stephen Hoffman
2021-09-02 16:01:40 UTC
Reply
Permalink
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
Dave Froble
2021-09-02 22:39:12 UTC
Reply
Permalink
Post by Stephen Hoffman
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?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
V***@SendSpamHere.ORG
2021-09-03 20:41:46 UTC
Reply
Permalink
Post by Dave Froble
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?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Dave Froble
2021-09-03 21:33:21 UTC
Reply
Permalink
Post by Dave Froble
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?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-09-03 21:36:58 UTC
Reply
Permalink
Post by Dave Froble
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".
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-09-06 12:24:37 UTC
Reply
Permalink
Post by Dave Froble
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...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Scott Dorsey
2021-09-06 14:52:04 UTC
Reply
Permalink
Post by Simon Clubley
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.
Post by Simon Clubley
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."
Arne Vajhøj
2021-09-06 23:38:38 UTC
Reply
Permalink
Post by Scott Dorsey
Post by Simon Clubley
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.
Post by Simon Clubley
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.
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
2021-09-07 01:57:51 UTC
Reply
Permalink
Post by Arne Vajhøj
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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2021-09-07 12:37:54 UTC
Reply
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
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.
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
Dave Froble
2021-09-06 14:55:38 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
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 ...
Post by Simon Clubley
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?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
V***@SendSpamHere.ORG
2021-09-07 13:19:48 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
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 ...
Post by Simon Clubley
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.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Simon Clubley
2021-09-07 17:58:10 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-09-07 20:55:18 UTC
Reply
Permalink
Post by Simon Clubley
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
Dave Froble
2021-09-08 07:05:16 UTC
Reply
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
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 ...
Post by Simon Clubley
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?
Post by Simon Clubley
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?
Post by Simon Clubley
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.
Post by Simon Clubley
Everyone else manages to solve data sharing
problems using secure techniques available on those other platforms.
If they need to, sure.
Post by Simon Clubley
If VMS doesn't have those secure options, then that's a failing in VMS.
Omission, not failing ...
Post by Simon Clubley
BTW, record access is a feature that is a unique VMS requirement.
Yep, we got it, and you don't. Eat your heart out ...
Post by Simon Clubley
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.
Post by Simon Clubley
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.
Post by Simon Clubley
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.
Post by Simon Clubley
Telling everyone
else to stand still so that VMS can still play is not a viable approach.
Who is telling anyone to stand still?
Post by Simon Clubley
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?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-09-08 12:20:21 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
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.
Post by Dave Froble
Post by Simon Clubley
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.
Post by Dave Froble
Post by Simon Clubley
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.
Post by Dave Froble
Post by Simon Clubley
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.
Post by Dave Froble
Post by Simon Clubley
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 ? :-)
Post by Dave Froble
Post by Simon Clubley
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.
Post by Dave Froble
Post by Simon Clubley
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.
Post by Dave Froble
Post by Simon Clubley
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
V***@SendSpamHere.ORG
2021-09-07 23:36:28 UTC
Reply
Permalink
Post by Simon Clubley
Post by V***@SendSpamHere.ORG
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.
Thank you for proving my point.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Phillip Helbig (undress to reply)
2021-09-07 16:16:29 UTC
Reply
Permalink
Post by V***@SendSpamHere.ORG
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
2021-09-07 18:03:44 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by V***@SendSpamHere.ORG
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... :-)

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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2021-09-07 18:14:14 UTC
Reply
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Post by V***@SendSpamHere.ORG
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? :-)
Post by Simon Clubley
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
MG
2021-08-31 15:48:19 UTC
Reply
Permalink
Post by Jim
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
2021-08-31 16:26:38 UTC
Reply
Permalink
Post by MG
Post by Jim
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
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
2021-08-31 16:41:07 UTC
Reply
Permalink
Thanks @Jim works like a charm
Jim
2021-08-31 17:00:02 UTC
Reply
Permalink
Post by ***@pitbulluk.org
Post by MG
Post by Jim
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
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
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.
Hein RMS van den Heuvel
2021-09-05 00:57:18 UTC
Reply
Permalink
Post by HCorte
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
Loading...