Alan Ackerman
2006-03-09 06:35:35 UTC
I didn't see any response to your post here, and only a little on the Linux-390 list.
The catch is that fork() under CMS is not a true fork. It basically only works if fork() is followed
very soon by exec(). The recommendation is that you replace fork() with spawn(). That would be
difficult if you don't have source. If you want SSH for CMS, I think you'll need source, not modules
copied from USS.
If I remember correctly, a true fork() would require CP support to create a new address space for
the child process -- CMS currently supports only one address space (not counting data spaces).
From
z/VM
OpenExtensions Callable Services Reference
Version 5 Release 1.0
Document Number SC24-6105-00
...
2.30 fork (BPX1FRK) -- Create a New Process
...
Note: The OpenExtensions implementation of the fork (BPX1FRK) service has some limitations not
found in other implementations (see "Characteristics and Restrictions"). In certain situations, you
may need to modify your application to accommodate these limitations. To avoid the limitations of
fork (BPX1FRK), you should consider modifying your application to use spawn (BPX1SPN). For
information about converting fork() usage in a C/C++ program to spawn(), see the z/VM: CMS
Application Development Guide.
...
Characteristics and Restrictions
1. You must issue the CMS command OPENVM SET FORK ON before running an application
that uses the fork() function. If the CMS FORK flag is not turned on, the application will receive a
return value of -1, a return code of ENOSYS, and a reason code of JRFunctNotSupported.
2. You must run the application as a POSIX(ON) application. If this flag is not turned on,
the application will receive a return value of -1, a return code of ENOSYS, and a reason code of
JRFunctNotSupported.
3. The child process is not allowed to issue an exit() call or to call any function that will
invoke exit() before the child process issues the exec() function. Any attempt to exit the child
process before the exec() is issued will result in a X'AE5' abnormal end code.
4. The child process is not allowed to issue any function that will cause the child process
to be blocked (for example, a pipe read() or a pause()), before the child issues the exec() function.
Any attempt to exit the child process before the exec() is issued will result in a X'AE6' abnormal
end code.
5. Any local variables in the application that are changed in the child process before the
exec() is issued will be changed in the parent process as well. This is because the child and parent
processes are still using the same program storage. The exec() function causes the child process
to begin using its own program storage.
6. Any global or environment variables in the application that are changed in the child
process before the exec() is issued will be changed in the parent process as well. This is because
the child and parent processes are still using the same program storage. The exec() function
causes the child process to begin using its own program storage.
The catch is that fork() under CMS is not a true fork. It basically only works if fork() is followed
very soon by exec(). The recommendation is that you replace fork() with spawn(). That would be
difficult if you don't have source. If you want SSH for CMS, I think you'll need source, not modules
copied from USS.
If I remember correctly, a true fork() would require CP support to create a new address space for
the child process -- CMS currently supports only one address space (not counting data spaces).
From
z/VM
OpenExtensions Callable Services Reference
Version 5 Release 1.0
Document Number SC24-6105-00
...
2.30 fork (BPX1FRK) -- Create a New Process
...
Note: The OpenExtensions implementation of the fork (BPX1FRK) service has some limitations not
found in other implementations (see "Characteristics and Restrictions"). In certain situations, you
may need to modify your application to accommodate these limitations. To avoid the limitations of
fork (BPX1FRK), you should consider modifying your application to use spawn (BPX1SPN). For
information about converting fork() usage in a C/C++ program to spawn(), see the z/VM: CMS
Application Development Guide.
...
Characteristics and Restrictions
1. You must issue the CMS command OPENVM SET FORK ON before running an application
that uses the fork() function. If the CMS FORK flag is not turned on, the application will receive a
return value of -1, a return code of ENOSYS, and a reason code of JRFunctNotSupported.
2. You must run the application as a POSIX(ON) application. If this flag is not turned on,
the application will receive a return value of -1, a return code of ENOSYS, and a reason code of
JRFunctNotSupported.
3. The child process is not allowed to issue an exit() call or to call any function that will
invoke exit() before the child process issues the exec() function. Any attempt to exit the child
process before the exec() is issued will result in a X'AE5' abnormal end code.
4. The child process is not allowed to issue any function that will cause the child process
to be blocked (for example, a pipe read() or a pause()), before the child issues the exec() function.
Any attempt to exit the child process before the exec() is issued will result in a X'AE6' abnormal
end code.
5. Any local variables in the application that are changed in the child process before the
exec() is issued will be changed in the parent process as well. This is because the child and parent
processes are still using the same program storage. The exec() function causes the child process
to begin using its own program storage.
6. Any global or environment variables in the application that are changed in the child
process before the exec() is issued will be changed in the parent process as well. This is because
the child and parent processes are still using the same program storage. The exec() function
causes the child process to begin using its own program storage.
I sent the following to the LINUX-390 list.
Thought y'all here might also be interested.
(And forgive me, I know there is some overlap.)
I don't remember where Leland posted he experiences with
z/OS (USS) binaries running on CMS (OpenVM). What it here?
Because it's not all that relevant to Linux, except for the
human interest ... er, uh ... academic interest of that story.
PuTTY?
We don't need no steenkin PuTTY!
We CMSers!
-- R;
==============Thought y'all here might also be interested.
(And forgive me, I know there is some overlap.)
I don't remember where Leland posted he experiences with
z/OS (USS) binaries running on CMS (OpenVM). What it here?
Because it's not all that relevant to Linux, except for the
human interest ... er, uh ... academic interest of that story.
PuTTY?
We don't need no steenkin PuTTY!
We CMSers!
-- R;
Remember when Leland was compiling things on z/OS (USS) and then
copying the binaries to CMS (OpenVM)? They ran without further effort.
Very nice ... some collab work betweek POK and Endicott (or maybe
all LE magic? I don't know).
We're in deep need of an SSH client for CMS. So I copied
/usr/bin/ssh from one of our z/OS systems and dropped it into OpenVM.
Lo and behold it does execute! Wants to fork, which is OFF by default.
SET FORK ON lets it do that, but it ABENDs immediately. Turns out
it is trying to seed the pseudo random number generator and punting
to a helper app which is causing crashing. (Another executable
copied from USS, but does not fly.)
I tried to fudge it with a quickly hacked helper (spitting out
static seed content, just to get it running). This got SSH further,
but still not all the way there.
I'm excited!!
We do need an SSH server for VM (CMS),
but we need an SSH client even more: need it for automation.
We also need SCP, which drives SSH under the covers
and no doubt plays the fork() game. [sigh]
-- R;
===========================================================copying the binaries to CMS (OpenVM)? They ran without further effort.
Very nice ... some collab work betweek POK and Endicott (or maybe
all LE magic? I don't know).
We're in deep need of an SSH client for CMS. So I copied
/usr/bin/ssh from one of our z/OS systems and dropped it into OpenVM.
Lo and behold it does execute! Wants to fork, which is OFF by default.
SET FORK ON lets it do that, but it ABENDs immediately. Turns out
it is trying to seed the pseudo random number generator and punting
to a helper app which is causing crashing. (Another executable
copied from USS, but does not fly.)
I tried to fudge it with a quickly hacked helper (spitting out
static seed content, just to get it running). This got SSH further,
but still not all the way there.
I'm excited!!
We do need an SSH server for VM (CMS),
but we need an SSH client even more: need it for automation.
We also need SCP, which drives SSH under the covers
and no doubt plays the fork() game. [sigh]
-- R;