(just a drive by as I only rarely read these anymore) Cough, cough hack hack hack.
Rick Troth and I went all through this back in '97/98. A true fork requires DAT ON support which CMS doesn't (well didn't then, and I doubt it now) do. Why not just write a service command to run from a linux instance to your CMS ID through IUCV? -- TWZ On Thu, 09 Mar 2006 00:35:35 -0600 Alan Ackerman <[EMAIL PROTECTED]> wrote: > 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; > >> > >======================== > ========================= > ========== > ==============
