I didn't see any response to your post here, and only a little on the Lin
ux-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 s
pawn(). 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 c
ounting 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 spa
wn (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 JRFunct
NotSupported.
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 ENOSY
S, and a reason code of
JRFunctNotSupported.
3. The child process is not allowed to issue an exit() call or to
ca
ll any function that will
invoke exit() before the child process issues the exec() function. Any at
tempt 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 re
sult in a X'AE6' abnormal
end code.
5. Any local variables in the application that are changed in the
ch
ild process before the
exec() is issued will be changed in the parent process as well. This is b
ecause the child and parent
processes are still using the same program storage. The exec() function c
auses the child process
to begin using its own program storage.
6. Any global or environment variables in the application that are
c
hanged 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.
On Thu, 23 Feb 2006 21:35:06 -0500, Rick Troth <[EMAIL PROTECTED]> wrote:
>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;
>
>On Thu, 23 Feb 2006, Rick Troth wrote:
>
>> Remember when Leland was compiling things on z/OS (USS) and then
>> copying the binaries to CMS (OpenVM)? They ran without further effor
t.
>> 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 defau
lt.
>> 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;
>>
>========================
=========================
==========
==============
