I've been working on updating the open source Regina Rexx interpreter to revive the native support it has for VMS, and I have a question about how best to create a mailbox/pipe for sending multiple DCL commands to a spawned subprocess via SYS$INPUT.

Regina tries to execute anything it doesn't recognize as a system command. I've adapted the UNIX version of the code, which uses fork()/exec*(), to instead use vfork(). That code works fine for .EXE files, but it doesn't work for running arbitrary DCL commands (there's a long "vms.rexx" test script that I'm trying to run that's filled with them), so I had to revive some code in the Regina port to use lib$spawn() instead. Here's my latest version of the relevant file, after I removed several functions to create input and output mailboxes:

https://github.com/jhamby/vms-regina/blob/jhamby/vms-fixes/vmscmd.c

I created a short AST to call on subprocess completion that closes the output stream, if it's redirected, after writing an EOF to it, which I discovered was necessary in order for the UNIX poll()-based code that feeds inputs and outputs into Regina to work. Otherwise it didn't receive any output from the DCL command. So that takes care of the output (it'd be nice if I could set SYS$ERROR separately from SYS$OUTPUT, but it's not a big deal).

The problem I have now is that, on the input side, calling getname() to get the mailbox name of a created pipe() to pass as SYS$INPUT in my lib$spawn() call works for one command, but not when I try to send multiple "\n" separated commands. I have the DECC$ feature flags set to enable stream-oriented pipes without carriage control, and I suspect that carriage control is part of the problem, because the error output I'm getting from DCL is the same as if the two lines of DCL commands were jammed together with no separation.

But I've tried disabling DECC$STREAM_PIPE and DECC$POPEN_NO_CRLF_REC_ATTR, which were both enabled, and that didn't make any difference. I've tried "\r\n" instead of "\n", but I suspect that I need to do something else as well, perhaps writing each line using a separate write() call?

What would be the best way for me to set up a pipe to use for the subprocess's input that I can use to send multiple lines to DCL from my code? Is it possible to use pipe() like I'm doing now, or do I have to call $crembx() myself in order to create a non-stream mailbox? Once I've created the mailbox, what's the recommended strategy for writing individual lines (from C)?

Additional detail: where I'm stuck in the vms.rexx test script is that it's sending multiple commands via redirected SYS$INPUT with the DCL command "set def nl:" The Rexx command, with redirection, looks like:

'LIFO> set def nl: >FIFO'

I can feed one additional DCL command via SYS$INPUT from the Rexx queue, but no more. I assume that since the test script did work at some point in the distant past, that this must be a valid way to send multiple commands to DCL, so I'm hoping that the only detail that I'm missing is how to set up and write to a pipe in the proper VMS style so that DCL will accept and recognize separate lines of input. Right now I'm getting a DCL error that's the same as if the two lines had been concatenated together with no newline separator ("%DCL-W-UNDSYM, undefined symbol - check validity and spelling \SYS$OUTPUT\").

Any suggestions would save me a great deal of trial and error. I've been trying to learn as *little* as possible about VMS record-oriented mailboxes, but I think this is one case where the UNIX stream style won't work. Thanks in advance!

Jake

In article <0e1b38a1-fdc0-4ac3-b6f7-acfa2198dbc1n@googlegroups.com>, Jake Hamby <jake.hamby@gmail.com> writes:
>I've been working on updating the open source Regina Rexx interpreter to re=
>vive the native support it has for VMS, and I have a question about how bes=
>t to create a mailbox/pipe for sending multiple DCL commands to a spawned s=
>ubprocess via SYS$INPUT.
>
>Regina tries to execute anything it doesn't recognize as a system command. =
>I've adapted the UNIX version of the code, which uses fork()/exec*(), to in=
>stead use vfork(). That code works fine for .EXE files, but it doesn't work=
> for running arbitrary DCL commands (there's a long "vms.rexx" test script =
>that I'm trying to run that's filled with them), so I had to revive some co=
>de in the Regina port to use lib$spawn() instead. Here's my latest version =
>of the relevant file, after I removed several functions to create input and=
> output mailboxes:
>
>https://github.com/jhamby/vms-regina/blob/jhamby/vms-fixes/vmscmd.c
>
>I created a short AST to call on subprocess completion that closes the outp=
>ut stream, if it's redirected, after writing an EOF to it, which I discover=
>ed was necessary in order for the UNIX poll()-based code that feeds inputs =
>and outputs into Regina to work. Otherwise it didn't receive any output fro=
>m the DCL command. So that takes care of the output (it'd be nice if I coul=
>d set SYS$ERROR separately from SYS$OUTPUT, but it's not a big deal).
>
>The problem I have now is that, on the input side, calling getname() to get=
> the mailbox name of a created pipe() to pass as SYS$INPUT in my lib$spawn(=
>) call works for one command, but not when I try to send multiple "\n" sepa=
>rated commands. I have the DECC$ feature flags set to enable stream-oriente=
>d pipes without carriage control, and I suspect that carriage control is pa=
>rt of the problem, because the error output I'm getting from DCL is the sam=
>e as if the two lines of DCL commands were jammed together with no separati=
>on.

ROTFLMFAO!

$ CRLF[0,16]=%x0A0D
$ COMMAND:="SHOW DEFAULT"
$ SPAWN 'COMMAND
%DCL-S-SPAWNED, process SYSTEM_14176 spawned
%DCL-S-ATTACHED, terminal now attached to process SYSTEM_14176
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]
%DCL-S-RETURNED, control returned to process SYSTEM
$ COMMAND:="SHOW DEFAULT''CRLF'SET DEFAULT SYS$SYSTEM''CRLF'SHOW DEFAULT"
$ SPAWN 'COMMAND
%DCL-S-SPAWNED, process SYSTEM_34737 spawned
%DCL-S-ATTACHED, terminal now attached to process SYSTEM_34737
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\DEFAULT
SET\
%DCL-S-RETURNED, control returned to process SYSTEM
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling

In other words, it won't work! You need to approach multiple command in
a different way because the input is record oriented. Now, watch this:

$ CREATE/MAILBOX SUBPROC$INPUT
$ SPAWN/NOWAIT/INPUT=SUBPROC$INPUT
%DCL-S-SPAWNED, process SYSTEM_58103 spawned
$ OPEN/WRITE CMD SUBPROC$INPUT
$ WRITE CMD "SHOW DEFAULT"
SYS$SYSROOT:[SYSMGR]
= SYS$SYSROOT:[SYSMGR]
= SYS$COMMON:[SYSMGR]
$ WRITE CMD SUBPROC$INPUT
$ WRITE CMD "SET DEFAULT SYS$SYSTEM" !<-- there's no output from command
$ WRITE CMD "SHOW DEFAULT"
SYS$SYSROOT:[SYSEXE]
= SYS$SYSROOT:[SYSEXE]
= SYS$COMMON:[SYSEXE]
$ WRITE CMD "LOGOUT/FULL"
SYSTEM job terminated at 24-MAY-2022 07:34:26.87

Accounting information:
Buffered I/O count: 244 Peak working set size: 2288
Direct I/O count: 0 Peak virtual size: 172560
Page faults: 125 Mounted volumes: 0
Charged CPU time: 0 00:00:00.03 Elapsed time: 0 00:07:45.54

>But I've tried disabling DECC$STREAM_PIPE and DECC$POPEN_NO_CRLF_REC_ATTR, =
>which were both enabled, and that didn't make any difference. I've tried "\=
>r\n" instead of "\n", but I suspect that I need to do something else as wel=
>l, perhaps writing each line using a separate write() call?

SEE ABOVE!

>What would be the best way for me to set up a pipe to use for the subproces=
>s's input that I can use to send multiple lines to DCL from my code? Is it =
>possible to use pipe() like I'm doing now, or do I have to call $crembx() m=
>yself in order to create a non-stream mailbox? Once I've created the mailbo=
>x, what's the recommended strategy for writing individual lines (from C)?

SEE ABOVE!

>Additional detail: where I'm stuck in the vms.rexx test script is that it's=
> sending multiple commands via redirected SYS$INPUT with the DCL command "s=
>et def nl:" The Rexx command, with redirection, looks like:
>
>'LIFO> set def nl: >FIFO'
>
>I can feed one additional DCL command via SYS$INPUT from the Rexx queue, bu=
>t no more. I assume that since the test script did work at some point in th=
>e distant past, that this must be a valid way to send multiple commands to =
>DCL, so I'm hoping that the only detail that I'm missing is how to set up a=
>nd write to a pipe in the proper VMS style so that DCL will accept and reco=
>gnize separate lines of input. Right now I'm getting a DCL error that's the=
> same as if the two lines had been concatenated together with no newline se=
>parator ("%DCL-W-UNDSYM, undefined symbol - check validity and spelling \SY=
>S$OUTPUT\").
>
>Any suggestions would save me a great deal of trial and error. I've been tr=
>ying to learn as *little* as possible about VMS record-oriented mailboxes, =
>but I think this is one case where the UNIX stream style won't work. Thanks=
> in advance!

IF you are expecting ANYTHING you sent to the SUBPROCESS to affect the process
in which you are running your Rexx, you will be greatly disappointed. Look at
my DCL example. The subprocess default was set to SYS$SYSTEM but the process
which spawned the subproces remains unaffected in its current default. If the
Rexx commands in your Rexx 'script' affecting the current process, you will be
rather disappointed in the outcome sending its DCL commands to a subprocess.

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

I speak to machines with the voice of humanity.

On 5/23/22 9:54 PM, Jake Hamby wrote:

> The problem I have now is that, on the input side, calling getname()
> to get the mailbox name of a created pipe() to pass as SYS$INPUT in my
> lib$spawn() call works for one command, but not when I try to send
> multiple "\n" separated commands. I have the DECC$ feature flags set to
> enable stream-oriented pipes without carriage control, and I suspect
> that carriage control is part of the problem, because the error output
> I'm getting from DCL is the same as if the two lines of DCL commands
> were jammed together with no separation.

Try sending the commands in separate writes with an fsync() in the
writer on the pipe's file descriptor after each command. On the CRTL's
mailbox-based pipes, that will give you a new record in the mailbox
regardless of whatever stream emulation is set. I'm not sure this will
solve your problem, but it's the first thing that occurred to me to try.

On 5/23/2022 10:54 PM, Jake Hamby wrote:
> I've been working on updating the open source Regina Rexx interpreter
> to revive the native support it has for VMS, and I have a question
> about how best to create a mailbox/pipe for sending multiple DCL
> commands to a spawned subprocess via SYS$INPUT.
>
> Regina tries to execute anything it doesn't recognize as a system
> command. I've adapted the UNIX version of the code, which uses
> fork()/exec*(), to instead use vfork(). That code works fine for .EXE
> files, but it doesn't work for running arbitrary DCL commands
> (there's a long "vms.rexx" test script that I'm trying to run that's
> filled with them), so I had to revive some code in the Regina port to
> use lib$spawn() instead. Here's my latest version of the relevant
> file, after I removed several functions to create input and output
> mailboxes:
>
> https://github.com/jhamby/vms-regina/blob/jhamby/vms-fixes/vmscmd.c
>
> I created a short AST to call on subprocess completion that closes
> the output stream, if it's redirected, after writing an EOF to it,
> which I discovered was necessary in order for the UNIX poll()-based
> code that feeds inputs and outputs into Regina to work. Otherwise it
> didn't receive any output from the DCL command. So that takes care of
> the output (it'd be nice if I could set SYS$ERROR separately from
> SYS$OUTPUT, but it's not a big deal).
>
> The problem I have now is that, on the input side, calling getname()
> to get the mailbox name of a created pipe() to pass as SYS$INPUT in
> my lib$spawn() call works for one command, but not when I try to send
> multiple "\n" separated commands. I have the DECC$ feature flags set
> to enable stream-oriented pipes without carriage control, and I
> suspect that carriage control is part of the problem, because the
> error output I'm getting from DCL is the same as if the two lines of
> DCL commands were jammed together with no separation.
>
> But I've tried disabling DECC$STREAM_PIPE and
> DECC$POPEN_NO_CRLF_REC_ATTR, which were both enabled, and that didn't
> make any difference. I've tried "\r\n" instead of "\n", but I suspect
> that I need to do something else as well, perhaps writing each line
> using a separate write() call?
>
> What would be the best way for me to set up a pipe to use for the
> subprocess's input that I can use to send multiple lines to DCL from
> my code? Is it possible to use pipe() like I'm doing now, or do I
> have to call $crembx() myself in order to create a non-stream
> mailbox? Once I've created the mailbox, what's the recommended
> strategy for writing individual lines (from C)?
>
> Additional detail: where I'm stuck in the vms.rexx test script is
> that it's sending multiple commands via redirected SYS$INPUT with the
> DCL command "set def nl:" The Rexx command, with redirection, looks
> like:
>
> 'LIFO> set def nl: >FIFO'
>
> I can feed one additional DCL command via SYS$INPUT from the Rexx
> queue, but no more. I assume that since the test script did work at
> some point in the distant past, that this must be a valid way to send
> multiple commands to DCL, so I'm hoping that the only detail that I'm
> missing is how to set up and write to a pipe in the proper VMS style
> so that DCL will accept and recognize separate lines of input. Right
> now I'm getting a DCL error that's the same as if the two lines had
> been concatenated together with no newline separator ("%DCL-W-UNDSYM,
> undefined symbol - check validity and spelling \SYS$OUTPUT\").
>
> Any suggestions would save me a great deal of trial and error. I've
> been trying to learn as *little* as possible about VMS
> record-oriented mailboxes, but I think this is one case where the
> UNIX stream style won't work. Thanks in advance!

I don't have an explanation for your specific problem.

But my experience is that LIB$SPANW is problematic for general
DCL commands - it is much better to create a pseudo terminal
(ptd$ functions).

Arne

In article <628d6de1$0$699$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>On 5/23/2022 10:54 PM, Jake Hamby wrote:
>> I've been working on updating the open source Regina Rexx interpreter
>> to revive the native support it has for VMS, and I have a question
>> about how best to create a mailbox/pipe for sending multiple DCL
>> commands to a spawned subprocess via SYS$INPUT.
>>
>> Regina tries to execute anything it doesn't recognize as a system
>> command. I've adapted the UNIX version of the code, which uses
>> fork()/exec*(), to instead use vfork(). That code works fine for .EXE
>> files, but it doesn't work for running arbitrary DCL commands
>> (there's a long "vms.rexx" test script that I'm trying to run that's
>> filled with them), so I had to revive some code in the Regina port to
>> use lib$spawn() instead. Here's my latest version of the relevant
>> file, after I removed several functions to create input and output
>> mailboxes:
>>
>> https://github.com/jhamby/vms-regina/blob/jhamby/vms-fixes/vmscmd.c
>>
>> I created a short AST to call on subprocess completion that closes
>> the output stream, if it's redirected, after writing an EOF to it,
>> which I discovered was necessary in order for the UNIX poll()-based
>> code that feeds inputs and outputs into Regina to work. Otherwise it
>> didn't receive any output from the DCL command. So that takes care of
>> the output (it'd be nice if I could set SYS$ERROR separately from
>> SYS$OUTPUT, but it's not a big deal).
>>
>> The problem I have now is that, on the input side, calling getname()
>> to get the mailbox name of a created pipe() to pass as SYS$INPUT in
>> my lib$spawn() call works for one command, but not when I try to send
>> multiple "\n" separated commands. I have the DECC$ feature flags set
>> to enable stream-oriented pipes without carriage control, and I
>> suspect that carriage control is part of the problem, because the
>> error output I'm getting from DCL is the same as if the two lines of
>> DCL commands were jammed together with no separation.
>>
>> But I've tried disabling DECC$STREAM_PIPE and
>> DECC$POPEN_NO_CRLF_REC_ATTR, which were both enabled, and that didn't
>> make any difference. I've tried "\r\n" instead of "\n", but I suspect
>> that I need to do something else as well, perhaps writing each line
>> using a separate write() call?
>>
>> What would be the best way for me to set up a pipe to use for the
>> subprocess's input that I can use to send multiple lines to DCL from
>> my code? Is it possible to use pipe() like I'm doing now, or do I
>> have to call $crembx() myself in order to create a non-stream
>> mailbox? Once I've created the mailbox, what's the recommended
>> strategy for writing individual lines (from C)?
>>
>> Additional detail: where I'm stuck in the vms.rexx test script is
>> that it's sending multiple commands via redirected SYS$INPUT with the
>> DCL command "set def nl:" The Rexx command, with redirection, looks
>> like:
>>
>> 'LIFO> set def nl: >FIFO'
>>
>> I can feed one additional DCL command via SYS$INPUT from the Rexx
>> queue, but no more. I assume that since the test script did work at
>> some point in the distant past, that this must be a valid way to send
>> multiple commands to DCL, so I'm hoping that the only detail that I'm
>> missing is how to set up and write to a pipe in the proper VMS style
>> so that DCL will accept and recognize separate lines of input. Right
>> now I'm getting a DCL error that's the same as if the two lines had
>> been concatenated together with no newline separator ("%DCL-W-UNDSYM,
>> undefined symbol - check validity and spelling \SYS$OUTPUT\").
>>
>> Any suggestions would save me a great deal of trial and error. I've
>> been trying to learn as *little* as possible about VMS
>> record-oriented mailboxes, but I think this is one case where the
>> UNIX stream style won't work. Thanks in advance!
>
>I don't have an explanation for your specific problem.
>
>But my experience is that LIB$SPANW is problematic for general
>DCL commands - it is much better to create a pseudo terminal
>(ptd$ functions).

LIB$SPAWN isn't a problem. I outlined what he needs to do to issue more
than one command. However, those commands are executed in a sub-process,
not in the main/master process. The results of many of the DCL commands
may leave this fellow scratching his head because he doesn't understand
the process/sub-process relationship.

Pseudo-terminals, in this case, will suffer the same afflictions. To do
it right, the commands should execute in the process but that can not be
while his Rexx interpreter is executing.

Many years ago there was a company (Argent, IIRC) that sold a DCL debug-
ger. It was written in C and read a .COM file passing its commands on
to LIB$SPAWN. Context wrong and many lexicals return results that were
sub-process based, not the main/master process. Then I wrote my debug-
ger, the debugger control process is a separate process and the DCL, in
a command procedure or and the command prompt, executes in the process
where they are issued. The debugger process, communicates the DCL, the
command interpeter running in Supervisor mode. Everything you'd expect
the commands to do are done correctly because they're running within the
process context of issue. If you're going to do it, do it right! ;)

Neither of your suggestions will work for something like this:

$ REXX my-rexx-script
blah
blah
blah
do_DCL (XYZZY=="It's magic!")
blah
blah
blah
exit/quit/end/whatever-terminates-REXX
$ SHOW SYMBOL XYZZY
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
$

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

I speak to machines with the voice of humanity.

On 5/25/2022 9:11 AM, VAXman-@SendSpamHere.ORG wrote:
> In article <628d6de1$0$699$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> I don't have an explanation for your specific problem.
>>
>> But my experience is that LIB$SPANW is problematic for general
>> DCL commands - it is much better to create a pseudo terminal
>> (ptd$ functions).
>
> LIB$SPAWN isn't a problem.

It can be if the commands require a real terminal.

> I outlined what he needs to do to issue more
> than one command. However, those commands are executed in a sub-process,
> not in the main/master process. The results of many of the DCL commands
> may leave this fellow scratching his head because he doesn't understand
> the process/sub-process relationship.
>
> Pseudo-terminals, in this case, will suffer the same afflictions. To do
> it right, the commands should execute in the process but that can not be
> while his Rexx interpreter is executing.

Whatever DCL is done should be considered its own context and
symbols etc. only available for other DCL commands executed
in that context.

It is a restriction, but the feature may still be useful.

Arne

On Wednesday, May 25, 2022 at 7:12:59 AM UTC-7, VAXman- wrote:
> LIB$SPAWN isn't a problem. I outlined what he needs to do to issue more
> than one command. However, those commands are executed in a sub-process,
> not in the main/master process. The results of many of the DCL commands
> may leave this fellow scratching his head because he doesn't understand
> the process/sub-process relationship.
>
> Pseudo-terminals, in this case, will suffer the same afflictions. To do
> it right, the commands should execute in the process but that can not be
> while his Rexx interpreter is executing.

I think that what you suggested will probably work for me. I'll test it out tonight. I actually *do* want to run the commands in a subprocess and not in the main process to have a permanent effect.

The reason is that what the large vms.rexx test script does is issue many DCL commands, mostly SHOW, in a subprocess, in order to compare the results that DCL prints to SYS$OUTPUT on the running system to the results of its own implementations of the major F$ lexical functions. So the commands are intended to have no permanent effects and are only being run for their outputs. Issuing multiple commands at once is more a case of laziness on the script author that I wanted to support.

You make an excellent point that calling DCL commands from Rexx isn't going to be the same as running a DCL script, and that lack of functionality is definitely a weakness of the current set of VMS-specific functions implemented by the previous coders to work on Regina. The only "set" function is F$SETPRV(), but, as you know better than I, the F$ lexicals aren't the way you define symbols and logicals from DCL, and therefore there is no way to do that from Regina right now.

This was at the back of my mind, but your comments have got me to realize that it'd be a good idea for me to add LIB$GET_LOGICAL(), LIB$SET_LOGICAL(), LIB$GET_SYMBOL(), and LIB$SET_SYMBOL() functions to Regina to match the RTL functions. That should fill the feature gap nicely, and I won't have to come up with my own API.

Thanks for the suggestions!

On Wednesday, May 25, 2022 at 7:12:59 AM UTC-7, VAXman- wrote:
>
> Neither of your suggestions will work for something like this:
>
> $ REXX my-rexx-script
> blah
> blah
> blah
> do_DCL (XYZZY=="It's magic!")
> blah
> blah
> blah
> exit/quit/end/whatever-terminates-REXX
> $ SHOW SYMBOL XYZZY
> %DCL-W-UNDSYM, undefined symbol - check validity and spelling

As I wrote in my other post, that's not what I was trying to get working, but the fact that you jumped to that use case reminded me that Regina *is* currently missing a way to get/set VMS symbols and logicals, likely because the previous authors spent their time writing implementations of the F$ lexicals and didn't get around to anything else.

I'll probably add four new builtin functions for VMS like:

SET_SYMBOL("XYZZY", "It's magic!", "LOCAL")
answer = GET_SYMBOL("MEANING_OF_LIFE")
SET_LOGICAL("LOG123", full_drive_name, "CONCEALED")
gamedir = GET_LOGICAL("GAMEDIR")

I'll have to think a bit about the API, but I'm pretty sure that having an optional third argument to set LOCAL vs. GLOBAL and for /TRANS=CONCEALED logicals should be sufficient to cover the use cases. Rexx, like DCL, is very string-oriented, and it supports functions that take a variable number of arguments.

Jake

On Wednesday, May 25, 2022 at 6:30:18 PM UTC-7, Jake Hamby wrote:
>
> I'll probably add four new builtin functions for VMS like:
>
> SET_SYMBOL("XYZZY", "It's magic!", "LOCAL")
> answer = GET_SYMBOL("MEANING_OF_LIFE")
> SET_LOGICAL("LOG123", full_drive_name, "CONCEALED")
> gamedir = GET_LOGICAL("GAMEDIR")

Following up: I wasn't able to successfully feed multiple DCL commands as input on a pipe after executing an original dummy command, so I decided to keep everything the way it was (although my extra EOF write to the output pipe turned out to be unnecessary; I only needed to hold the FD open and close it on subprocess exit to write the EOF), because I don't want to hurt the performance of using the LIFO and FIFO redirection features of Regina for streaming data to/from UNIX subprocesses.

Also, it was very easy for me to change a few lines in the "vms.rexx" test script to execute the DCL commands one at a time, instead of pushing them on a stack and feeding them all at once into a single DCL subprocess (although it would've been faster to execute if I could've gotten that to work easily).

BTW, Rexx is blindingly fast compared to DCL on an old VAX. I can get over 700,000 REXX clauses per second on the 667 MHz Alpha, which is plenty for any script I could possibly write, while I recently found an old Hunter Goatley article that I recently posted to his website, showing how he wrote a MACRO program to replace his LOGIN.COM script to save a few clock cycles by calling LIB$SET_SYMBOL() and LIB$SET_LOGICAL() and setting key definitions directly. It's hard to put myself in the frame of mind to where it'd be worth assembling and linking a new version of a LOGIN.EXE to save a few cycles parsing my LOGIN.COM.

https://hunter.goatley.com/vax-professional-articles/vax-pro-08/

In that same spirit, I'd hope to avoid having to call DCL in order for Rexx to do anything it could do for itself. Sadly, there are a few gaps that I don't know how to accomplish from VMS documented APIs (and neither could the previous authors):

F$ENVIRONMENT()
F$VERIFY()
F$GETQUI("DISPLAY_FILE", "FILE_DEVICE", ...)
F$GETQUI("DISPLAY_FILE", "FILE_DID", ...)
F$GETSYI() for "FREE_PAGES", "MODIFIED_PAGES", "NPAGED_*", "PAGED_*", "TOTAL_PAGES", "USED_PAGES"

I'm also curious if the "STORED_SEMANTICS" file attribute is worth supporting in F$FILE_ATTRIBUTES(). What programs ever used the "compound document stored semantics" feature? Is it obsolete now, like the VAX vector processor-related items?

Regards,
Jake

On Thursday, May 26, 2022 at 1:34:58 PM UTC-7, Jake Hamby wrote:
> while I recently found an old Hunter Goatley article that I recently posted to his website

to avoid any possible confusion, I meant to write that I recently found an article that he recently posted to his website. I don't run Hunter Goatley's website. :)

On 5/26/2022 4:34 PM, Jake Hamby wrote:
> In that same spirit, I'd hope to avoid having to call DCL in order
> for Rexx to do anything it could do for itself. Sadly, there are a
> few gaps that I don't know how to accomplish from VMS documented APIs
> (and neither could the previous authors):
> F$ENVIRONMENT()

Some items would not be applicable for REXX.

"DEFAULT" is easy.

A few items can probably be found in somewhere in P1 or S0 space.

> F$VERIFY()

Not applicable I would say.

> F$GETQUI("DISPLAY_FILE", "FILE_DEVICE", ...)
> F$GETQUI("DISPLAY_FILE", "FILE_DID", ...)

SYS$GETQUIW with QUI$DISPLAY_FILE and QUI$_FILE_SPECIFICATION and
then some RMS calls should be able to get that.

> F$GETSYI() for "FREE_PAGES", "MODIFIED_PAGES", "NPAGED_*", "PAGED_*", "TOTAL_PAGES", "USED_PAGES"

"TOTAL_PAGES" should be SYI$_MEMSIZE

but the rest indeed look missing.

Arne

On 5/26/22 3:34 PM, Jake Hamby wrote:

> In that same spirit, I'd hope to avoid having to call DCL in order
> for Rexx to do anything it could do for itself. Sadly, there are a few gaps
> that I don't know how to accomplish from VMS documented APIs (and
> neither could the previous authors):
>
> F$ENVIRONMENT()
> F$VERIFY()

What could it possibly mean to set the DCL command environment or to set
or get the DCL command verification bit without running DCL?

> F$GETQUI("DISPLAY_FILE", "FILE_DEVICE", ...)
> F$GETQUI("DISPLAY_FILE", "FILE_DID", ...)
> F$GETSYI() for "FREE_PAGES", "MODIFIED_PAGES", "NPAGED_*", "PAGED_*", "TOTAL_PAGES", "USED_PAGES"

So the problem is not with the service calls but just these particular
item codes? They don't look like documented item codes, so either the
DCL lexical functions are using undocumented item codes, or are
performing some additional computation and/or operation on returned
values. I've never done it but my guess would be that the page count
stuff involves computations derived by working from intimate knowledge
of VMS memory handling and internal nomenclature. The computations
*might* be in the ISDM, but that's just a guess as it's a book I've
never had access to. The queue stuff is probably just calling
SYS$GETQUI with QUI$_DISPLAY_FILE and QUI$_FILE_SPECIFCATION and then
parsing the returned file spec to get the DID and DEVICE.

On Thursday, May 26, 2022 at 6:56:53 PM UTC-7, Craig A. Berry wrote:
> On 5/26/22 3:34 PM, Jake Hamby wrote:
>
> >
> > F$ENVIRONMENT()
> > F$VERIFY()
> What could it possibly mean to set the DCL command environment or to set
> or get the DCL command verification bit without running DCL?

Right, that's why I'm not going to bother to implement them. I just mentioned them for completeness because the previous author had an F$VERIFY command in the built-ins list, commented out. Makes no sense for Rexx, you're right.

> > F$GETQUI("DISPLAY_FILE", "FILE_DEVICE", ...)
> > F$GETQUI("DISPLAY_FILE", "FILE_DID", ...)
> > F$GETSYI() for "FREE_PAGES", "MODIFIED_PAGES", "NPAGED_*", "PAGED_*", "TOTAL_PAGES", "USED_PAGES"
> So the problem is not with the service calls but just these particular
> item codes? They don't look like documented item codes, so either the
> DCL lexical functions are using undocumented item codes, or are
> performing some additional computation and/or operation on returned
> values. I've never done it but my guess would be that the page count
> stuff involves computations derived by working from intimate knowledge
> of VMS memory handling and internal nomenclature. The computations
> *might* be in the ISDM, but that's just a guess as it's a book I've
> never had access to. The queue stuff is probably just calling
> SYS$GETQUI with QUI$_DISPLAY_FILE and QUI$_FILE_SPECIFCATION and then
> parsing the returned file spec to get the DID and DEVICE.

Yeah, it's just a few particular item codes that the previous author didn't implement, that I only mention out of completeness.

I discovered a few interesting undocumented codes, like F$GETDVI(device, "SSD_LIFE_REMAINING") and "SSD_USAGE_REMAINING". They both return -1 for me, but I thought I'd add them to the list, just in case they work somewhere.

Jake