Re: Spawned Address Space Control in tcsh shell
I think of UNIX exec() as the closest thing to MVS XCTL. IMHO, no. exec() is equivalent to end of job step A and start of job step B. You cannot allocate memory before the exec() and pass it to the program invoked by exec(). You can, however, with XCTL. But UNIX processes are different; the parent can do the UNIX classic fork() followed by exec() done by the new child, [snip] There is nothing like this in the case of MVS TCBs. Leaving local spawn()ed processes away and talking only about fork()/exec(). When comparing the UNIX fork()/exec() combination to MVS, I think more of address space A doing an ASCRE to start address space B. While fork() is a non-priviledged function, ASCRE needs authorization. But I was just comparing what it technically does. There is nothing like fork() in MVS regarding the copy part of fork(). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Wed, 8 Jan 2014 23:01:56 -0800, Henry Willard wrote: I believe init (pid 1) becomes the parent. ... I stand corrected, according to experiment with all of OS X, Linux, Solaris, and z/OS. But still, it could provide a model for an alternative to orphans' ABENDing: if the parent ENDs, the initiator could adopt the children. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Thu, 9 Jan 2014 11:34:13 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 8 Jan 2014 23:01:56 -0800, Henry Willard wrote: I believe init (pid 1) becomes the parent. ... I stand corrected, according to experiment with all of OS X, Linux, Solaris, and z/OS. But still, it could provide a model for an alternative to orphans' ABENDing: if the parent ENDs, the initiator could adopt the children. It could have provided an alternative if, long ago, someone had thought of it. At this point, there is so much tied to the jobstep task that would be cleaned up by its ABENDing, that it would take a complete redesign of the system to allow anything like that. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
Maybe.. something like a new enque level that would allow for child to supercede a parent enque? On Jan 9, 2014 3:20 PM, Walt Farrell walt.farr...@gmail.com wrote: On Thu, 9 Jan 2014 11:34:13 -0600, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 8 Jan 2014 23:01:56 -0800, Henry Willard wrote: I believe init (pid 1) becomes the parent. ... I stand corrected, according to experiment with all of OS X, Linux, Solaris, and z/OS. But still, it could provide a model for an alternative to orphans' ABENDing: if the parent ENDs, the initiator could adopt the children. It could have provided an alternative if, long ago, someone had thought of it. At this point, there is so much tied to the jobstep task that would be cleaned up by its ABENDing, that it would take a complete redesign of the system to allow anything like that. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. But (as usual) that might just be my wrong-headed view of the situation. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Wednesday, January 08, 2014 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Spawned Address Space Control in tcsh shell Is there a specific reason (other than it being goofy) that the child could just become the parent? Some sort of percolation upward? Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Tue, Dec 31, 2013 at 2:18 PM, Tony Harminc t...@harminc.net wrote: On 31 December 2013 13:23, Paul Gilmartin paulgboul...@aim.com wrote: Most (?) of the complaints about (non-)shared areas stem from the non-propagation of DDNAMEs through fork(). Ain't gonna get better (NVFL, anyway). Because of ENQ conflicts between parent and child. Extend the ENQ scope to job rather than address space? NVFL, again. I could imagine: o A scheme where an allocation could be transferred from parent to child, freeing the ENQ in parent. o A server-client model in which the actual I/O is performed by the parent that performs the allocation, and the data passed to the child via sockets or POSIX pipes. Sort of like NFS, but it needs to be better than NFS. The likely problem is that - unlike the MVS subtasking model - in UNIX the parent process can go away leaving the child running. Would you leave the parent running just to handle the I/O work, or clean it up and transfer the ENQs and/or allocations to the child at that point, or just say Don't Do That, or...? Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On 8 January 2014 11:47, Farley, Peter x23353 peter.far...@broadridge.com wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. But (as usual) that might just be my wrong-headed view of the situation. I'm not so sure. While the implementors of z/OS UNIX have done a remarkable job of fusing MVS and UNIX behaviour, there are limits. I think of UNIX exec() as the closest thing to MVS XCTL. But UNIX processes are different; the parent can do the UNIX classic fork() followed by exec() done by the new child, or the similar spawn(), in each case leaving a parent and a child. Each can do their own thing (which could include further exec()s) for as long as they like, and then either can terminate independent of the other. While there may well be signals and default behaviours to worry about, the result can be that the child runs while the parent is gone. There is nothing like this in the case of MVS TCBs. If the parent ends, the child abends. Under some circumstances the abend can be caught, but life cannot continue without the parent. TonyH. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
One possibility is to use POSIX threading instead of ATTACH. POSIX threads all run in the same address space. And are actually implemented via TCBs. But there is no parent/child relationship between a thread and a separate thread which a given thread creates. The only special thread is the initial thread (called the IPT ). When it dies, then all the POSIX threads die. This is because that thread actually does all the ATTACHes. It is similar to how PL/I did it's multitasking. On Wed, Jan 8, 2014 at 12:20 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Wed, 8 Jan 2014 12:28:13 -0600, John McKown wrote: One possibility is to use POSIX threading instead of ATTACH. POSIX threads all run in the same address space. And are actually implemented via TCBs. But there is no parent/child relationship between a thread and a separate thread which a given thread creates. The only special thread is the initial thread (called the IPT ). When it dies, then all the POSIX threads die. This is because that thread actually does all the ATTACHes. It is similar to how PL/I did it's multitasking. It's interesting that you refer to PL/I in the past tense. But that may be a matter more of your personal history than of PL/I's. And, each thread could do its own I/O securely. Almost. There's still the problem of DDNAME contention. Damn! it would be so nice if ATTACH handled alternate DDNAME assignment rather than leaving it to the various utilities. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Jan 8, 2014, at 10:22 PM, Paul Gilmartin wrote: On SNIP-- And, each thread could do its own I/O securely. Almost. There's still the problem of DDNAME contention. Damn! it would be so nice if ATTACH handled alternate DDNAME assignment rather than leaving it to the various utilities. Paul: Its not so much attach its that the utilities expect a certain format of a list and you would break a lot of code if you were to change it this late in the game. Most (if not all) of the utilities are cast in stone. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On 1/8/14, 10:20 AM, Paul Gilmartin wrote: On Wed, 8 Jan 2014 11:47:58 -0500, Farley, Peter x23353 wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. Ummm... Not quite. *IX supports the scenario: a) Parent runs for a while, then fork()s child. b) Parent and child run concurrently and cooperatively for a while. c) Parent-goes-away-leaving-the-child-running. XCTL fails to support (b) because the parent goes away instantly. ATTACH fails to support (c) because the child can't outlive the parent. (But why not? Silly design. Perhaps none of the OS/360 designers were orphans, so the concept never occurred to them.) In *IX, if the parent goes away, the grandparent adopts the child. I believe init (pid 1) becomes the parent. It is not uncommon for a process to fork a child process and then the child to fork a grandchild after which the middle process exits leaving the grandchild under the care of init. This relieves the original process from dealing with wait or SIGCHLD at some later time. This was especially common when BSD and SYSVR4 Unix behaved differently in this area. Regards, Henry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Mon, 30 Dec 2013 19:03:38 -0800, Roger Steyn wrote: John , This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh.� Your are right . BPX_SHAREAS cannot be used for tcsh . It is documented in USS planning guide . _BPX_SHAREAS Specifies whether the spawned child process is to be run in a separate address space from the login shell's address space or in the same address space. Use _BPX_SHAREAS is to improve performance in the z/OS� shell. The spawn callable service uses _BPX_SHAREAS when creating child processes. Is there anything distinctive about tcsh? Wouldn't the same apply to bash, or ksh, or dash, or any shell a customer cared to install? I suppose what distingishes tcsh is that z/OS elects to supply it as a base function. That ought to make tcsh responsible for being _BPX_SHAREAS-savvy. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
This whole share areas thing is annoying at best. And confounding and time consuming at the worst. Has anyone at IBM thought of a way to actually fix this in a more functional way? Winning friends and influencing with my tactful opinions, *grin* Rob Schramm On Dec 31, 2013 8:21 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 30 Dec 2013 19:03:38 -0800, Roger Steyn wrote: John , This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh.� Your are right . BPX_SHAREAS cannot be used for tcsh . It is documented in USS planning guide . _BPX_SHAREAS Specifies whether the spawned child process is to be run in a separate address space from the login shell's address space or in the same address space. Use _BPX_SHAREAS is to improve performance in the z/OS� shell. The spawn callable service uses _BPX_SHAREAS when creating child processes. Is there anything distinctive about tcsh? Wouldn't the same apply to bash, or ksh, or dash, or any shell a customer cared to install? I suppose what distingishes tcsh is that z/OS elects to supply it as a base function. That ought to make tcsh responsible for being _BPX_SHAREAS-savvy. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
To be technical, /bin/sh isn't _BPX_SHAREAS aware. It uses spawn() rather than fork()/exec() in many cases. When using spawn(), _BPX_SHAREAS controls whether a local spawn is down. The best documentation on _BPX_SHAREAS is in the z/OS Unix Assembler Callable Services Guide - under BPX1SPN. AFAIK, tcsh doesn't use spawn(), so it can't local spawn processes into the same AS. I don't think that this is explicityly documented...maybe open a ETR if you want confirmation. It sounds like your problem with /bin/sh is with terminfo/termcap setup ? If you have configured your default shell to be tcsh, you can run a batch job with COZBATCH using a login /bin/sh shell - // EXEC PGM=COZBATCH,PARM='//bin/sh -L' (first slash is LEOPT sep) //STDIN DD * ... Kirk Wolf Dovetailed Technologies http://dovetail.com PS I use Gnome Terminal from my linux desktop with ssh for my z/OS shell sessions, and it works fine for me.I would love to have a modern bash port for z/OS, but without lots of porting work it would suffer the same problem as tcsh. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Tue, 31 Dec 2013 12:24:23 -0500, Rob Schramm wrote: This whole share areas thing is annoying at best. And confounding and time consuming at the worst. Has anyone at IBM thought of a way to actually fix this in a more functional way? Winning friends and influencing with my tactful opinions, *grin* Most (?) of the complaints about (non-)shared areas stem from the non-propagation of DDNAMEs through fork(). Ain't gonna get better (NVFL, anyway). Because of ENQ conflicts between parent and child. Extend the ENQ scope to job rather than address space? NVFL, again. I could imagine: o A scheme where an allocation could be transferred from parent to child, freeing the ENQ in parent. o A server-client model in which the actual I/O is performed by the parent that performs the allocation, and the data passed to the child via sockets or POSIX pipes. Sort of like NFS, but it needs to be better than NFS. On Tue, 31 Dec 2013 11:33:22 -0600, Kirk Wolf wrote: The best documentation on _BPX_SHAREAS is in the z/OS Unix Assembler Callable Services Guide - under BPX1SPN. AFAIK, tcsh doesn't use spawn(), so it can't local spawn processes into the same AS. I don't think that this is explicityly documented...maybe open a ETR if you want confirmation. And worse, there's a POSIX spawn which is not quite compatible with z/OS spawn. (z/OS is better because it didn't assume some of the design constraints of POSIX spawn.) It sounds like your problem with /bin/sh is with terminfo/termcap setup ? To whom was that followup addressed (you didn't quote the headers)? Is it possible that .login does some terminfo setup that is absent from the user's .profile? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On 31 December 2013 13:23, Paul Gilmartin paulgboul...@aim.com wrote: Most (?) of the complaints about (non-)shared areas stem from the non-propagation of DDNAMEs through fork(). Ain't gonna get better (NVFL, anyway). Because of ENQ conflicts between parent and child. Extend the ENQ scope to job rather than address space? NVFL, again. I could imagine: o A scheme where an allocation could be transferred from parent to child, freeing the ENQ in parent. o A server-client model in which the actual I/O is performed by the parent that performs the allocation, and the data passed to the child via sockets or POSIX pipes. Sort of like NFS, but it needs to be better than NFS. The likely problem is that - unlike the MVS subtasking model - in UNIX the parent process can go away leaving the child running. Would you leave the parent running just to handle the I/O work, or clean it up and transfer the ENQs and/or allocations to the child at that point, or just say Don't Do That, or...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Spawned Address Space Control in tcsh shell
I was trying to execute a batch cozsftp command using tcsh as the shell, and my dataset allocation (to send a file to an sftp server) kept on failing, either with an unable to stat DD, or when I attempted to allocate the dynamically allocate the dataset, that allocation failed due to it being already allocated elsewhere. Eventually I realized that the cozsftp command was being executed in another address space, but I was unable to figure out how to get tcsh to execute that command in the original address space. I eventually gave up and used the /bin/sh shell to run the batch job. Is there a magic spell to use with tcsh to have the cozsftp command execute in the same address space? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
This is my take on it. I am not an expert. Nor do I have access to the actual source code. I don't believe that tcsh will do what you want. My reasoning is below. In order to run a process in the same address space, the code must use the spawn() function. I base this assertion on http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB1C0/2.209 , point #8 in the Usage Notes. This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh. I note that the description of the fork() function does not mention _BPX_SHAREAS at all. I therefore conclude that a fork() will always result in a new address space. I note that the description of the execve() function says: The current process image is replaced with a new process image for the executable file to be run. That is, the old execution state ceases to exist. So if the tcsh did an execve() without the fork() in order to run in the same address space, the shell would exit after the command because the shell would have ceased to exist. In my mind, doing a exec() is much like doing an XCTL. You don't return from whence you came. I notice that on this page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA5C0/TCSHBUINONit states: When a command to be executed is found not to be a built-in command the tcsh shell attempts to execute the command via execve. Taking these things together, I have come to the conclusion that the tcsh shell _most likely_ invokes non-builtin commands in the original UNIX way. That is doing a fork() followed by an exec(). This removes the possibility of running cozsftp in the same physical address space as the shell. Any particular reason you wan to use tcsh? I'm just curious because I've never read anything nice about it. On Mon, Dec 30, 2013 at 7:19 AM, Mark Jacobs mark.jac...@custserv.comwrote: I was trying to execute a batch cozsftp command using tcsh as the shell, and my dataset allocation (to send a file to an sftp server) kept on failing, either with an unable to stat DD, or when I attempted to allocate the dynamically allocate the dataset, that allocation failed due to it being already allocated elsewhere. Eventually I realized that the cozsftp command was being executed in another address space, but I was unable to figure out how to get tcsh to execute that command in the original address space. I eventually gave up and used the /bin/sh shell to run the batch job. Is there a magic spell to use with tcsh to have the cozsftp command execute in the same address space? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
Thanks for the reply. I changed to tcsh since it seems to work better than /bin/sh when I ssh to OMVS from my FreeBSD 9.2 workstation. Mark Jacobs On 12/30/13 08:51, John McKown wrote: This is my take on it. I am not an expert. Nor do I have access to the actual source code. I don't believe that tcsh will do what you want. My reasoning is below. In order to run a process in the same address space, the code must use the spawn() function. I base this assertion on http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB1C0/2.209 , point #8 in the Usage Notes. This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh. I note that the description of the fork() function does not mention _BPX_SHAREAS at all. I therefore conclude that a fork() will always result in a new address space. I note that the description of the execve() function says: The current process image is replaced with a new process image for the executable file to be run. That is, the old execution state ceases to exist. So if the tcsh did an execve() without the fork() in order to run in the same address space, the shell would exit after the command because the shell would have ceased to exist. In my mind, doing a exec() is much like doing an XCTL. You don't return from whence you came. I notice that on this page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA5C0/TCSHBUINONit states: When a command to be executed is found not to be a built-in command the tcsh shell attempts to execute the command via execve. Taking these things together, I have come to the conclusion that the tcsh shell _most likely_ invokes non-builtin commands in the original UNIX way. That is doing a fork() followed by an exec(). This removes the possibility of running cozsftp in the same physical address space as the shell. Any particular reason you wan to use tcsh? I'm just curious because I've never read anything nice about it. On Mon, Dec 30, 2013 at 7:19 AM, Mark Jacobs mark.jac...@custserv.comwrote: I was trying to execute a batch cozsftp command using tcsh as the shell, and my dataset allocation (to send a file to an sftp server) kept on failing, either with an unable to stat DD, or when I attempted to allocate the dynamically allocate the dataset, that allocation failed due to it being already allocated elsewhere. Eventually I realized that the cozsftp command was being executed in another address space, but I was unable to figure out how to get tcsh to execute that command in the original address space. I eventually gave up and used the /bin/sh shell to run the batch job. Is there a magic spell to use with tcsh to have the cozsftp command execute in the same address space? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Mon, 30 Dec 2013 07:51:28 -0600, John McKown wrote: I note that the description of the fork() function does not mention _BPX_SHAREAS at all. I therefore conclude that a fork() will always result in a new address space. It must, in order that pointers in the child process space validly point to copies of structures in the parent process space. (Discounting the possibility that fork() might relocate such pointers.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On Mon, 30 Dec 2013 09:16:29 -0500, Mark Jacobs wrote: Thanks for the reply. I changed to tcsh since it seems to work better than /bin/sh when I ssh to OMVS from my FreeBSD 9.2 workstation. Examples? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
John , This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh. Your are right . BPX_SHAREAS cannot be used for tcsh . It is documented in USS planning guide . _BPX_SHAREAS Specifies whether the spawned child process is to be run in a separate address space from the login shell's address space or in the same address space. Use _BPX_SHAREAS is to improve performance in the z/OS® shell. The spawn callable service uses _BPX_SHAREAS when creating child processes. Restriction: If tcsh is your login shell, do not use BPX_SHAREAS. YES The child process is created on a subtask in the parent's address space. If the request cannot be honored, the child is created in another address space. NO The child process is created in a new address space. NO is the default. MUST The child process is created on a subtask in the parent's address space. If the request cannot be honored, the request will not complete. On Monday, December 30, 2013 7:23 PM, John McKown john.archie.mck...@gmail.com wrote: This is my take on it. I am not an expert. Nor do I have access to the actual source code. I don't believe that tcsh will do what you want. My reasoning is below. In order to run a process in the same address space, the code must use the spawn() function. I base this assertion on http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB1C0/2.209 , point #8 in the Usage Notes. This talks about the _BPX_SHAREAS environment variable. This environment variable is not mentioned anywhere in the documentation of tcsh. I note that the description of the fork() function does not mention _BPX_SHAREAS at all. I therefore conclude that a fork() will always result in a new address space. I note that the description of the execve() function says: The current process image is replaced with a new process image for the executable file to be run. That is, the old execution state ceases to exist. So if the tcsh did an execve() without the fork() in order to run in the same address space, the shell would exit after the command because the shell would have ceased to exist. In my mind, doing a exec() is much like doing an XCTL. You don't return from whence you came. I notice that on this page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZA5C0/TCSHBUINONit states: When a command to be executed is found not to be a built-in command the tcsh shell attempts to execute the command via execve. Taking these things together, I have come to the conclusion that the tcsh shell _most likely_ invokes non-builtin commands in the original UNIX way. That is doing a fork() followed by an exec(). This removes the possibility of running cozsftp in the same physical address space as the shell. Any particular reason you wan to use tcsh? I'm just curious because I've never read anything nice about it. On Mon, Dec 30, 2013 at 7:19 AM, Mark Jacobs mark.jac...@custserv.comwrote: I was trying to execute a batch cozsftp command using tcsh as the shell, and my dataset allocation (to send a file to an sftp server) kept on failing, either with an unable to stat DD, or when I attempted to allocate the dynamically allocate the dataset, that allocation failed due to it being already allocated elsewhere. Eventually I realized that the cozsftp command was being executed in another address space, but I was unable to figure out how to get tcsh to execute that command in the original address space. I eventually gave up and used the /bin/sh shell to run the batch job. Is there a magic spell to use with tcsh to have the cozsftp command execute in the same address space? -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
