On 2017-08-26, at 23:28, Alan Altmark wrote:
>
> Unlike z/OS, the POSIX environment in CMS is integrated; it's not a
> separate subsystem.
>
I'm not sure how this matters. For example, in z/OS JES is a
separate(?) subsystem, but it feels integrated.
> With an appropriate stage, the PIPE command can get
> to any part of CMS. Specifically, those stages can call the BPX1 CSLs to
> do whatever you want.
>
I don't know the initialism CSL. Please explain.
> Google is your friend. There appears to be a gcc port (gccmvs) that works
> on CMS. There is also a C compiler available from Dignus.
>
>> Are there Pipelines drivers for POSIX sockets?
>
> What do you mean by "POSIX sockets"? If you mean AF_UNIX, then no, I
> don't think anyone has written anything for them. If you mean AF_INET,
> then see TCPCLIENT and TCPLISTEN.
>
Too late at night. I intended "descriptor" when I wrote "socket".
File descriptors, as created by BPX1OPN:
https://www.ibm.com/support/knowledgecenter/SSB27U_6.2.0/com.ibm.zvm.v620.dmsp1/opn.htm
or BPX1PIP:
https://www.ibm.com/support/knowledgecenter/SSB27U_6.2.0/com.ibm.zvm.v620.dmsp1/pip.htm#pip
The latter is interesting: the Users Guide point out that the "file"
descriptors associated with an unnamed pipe do not refer to any object
in the file system.
So: are there Pipelines drivers for file descriptors? z/OS, Solaris, Linux,
MacOS, ... have "file descriptor files":
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/filedesc.htm
"... This might be useful for a program that expects a file name for output,
but you might want it to write its output to stdout instead."
I see nothing similar in the CMS Users Guide. A file descriptor file
provides a handle whereby a Pipelines BFS driver could access a descriptor
as a character special file.
For example, the command:
pax -w directory/path
writes an archive to stdout (1) and a listing of files to stderr (2).
Is there a way to encapsulate or interface this to a CMS Pipelines
stages so stdout goes to the primary input stream and stderr to the
secondary input stream? (If I've overlooked that OpenExtensions
supports file descriptor files, that's the answer. It might require
a bit of plumbing, as z/OS does.)
How do I invoke the BPX1* facilities under OpenExtensions? In z/OS
it's marvelously simple. For example:
address SYSCALL pipe stem.
calls BPX1PIP and assigns the generated descriptors to stem.1 and stem.2.
The SYSCALL command environment is available under TSO, IRXJCL, and OMVS;
probably many others. I don't know that SYSCALL exists under CMS.
> The 'storage' stage in Pipes can also access memory directly.
>
Is this related to the BPX1* interface?
-- gil
