Sadly it was predictable that this topic would vector in this direction :-)

I'll defer to IBM to explain where the documentation is wrt whether
 /bin/sh spawns vs forks and how it is affected by _BPX_SHAREAS,
_BPX_SPAWN_SCRIPT, pipecurrent, etc.

What I can tell you is that for commands a and b that are not built-ins:

a | b

will spawn both a and b.  Depending on _BPX_SHAREAS you will get "local"
spawn if a bunch of conditions are met.  See BPX1SPN doc for the best
details on when a spawn with be "local".

I believe "pipecurrent" affects what happens when b is a built-in or
something that needs a subshell

Believe me that I have beat my head on this topic much more than writing
the IAZSYMBL wrapper itself !

trust me on what works:

> set -o pipecurrent  # needed since read and . are built-ins
> jessym A | read -r myA    # get one variable
> jessym -x | . /dev/fd0    # get all JES symbols and export them

... and that most other attempts to do the equivalent won't work. (consider
this as a time-sucking challenge :-)

remember what is needed:

1) jessym needs to run in the current address space.  JES Symbols are not
inherited by forked OMVS AS

2) the shell variable(s) should be set in the current shell, and not a
subshell

PS> If anyone has V2R1 and would like to test a beta version of jessym,
please let me know.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Wed, Oct 23, 2013 at 7:23 PM, Paul Gilmartin <paulgboul...@aim.com>wrote:

> On Wed, 23 Oct 2013 14:09:45 -0500, Kirk Wolf wrote:
> >
> >(*Note*: in the following examples, shell input is bold and follows "> ".
> > Also: you need  "set -o pipecurrent" when piping jessym output into
> "read"
> >or "." )
> >    ...
> >*> set -o pipecurrent *
> >*> jessym A | read -r myvar*
> >*> echo $myvar*
> >B
> >
> Now, you've got me started.  From:
>
>     Title: z/OS V1R13.0 UNIX System Services Command Reference
>     Document Number: SA22-7802-14
>
>     SHEX Shell execution environments
>
>     ... Each command in a pipeline (such as "command | command") runs in a
> child shell
>     environment, unless the pipecurrent shell option is in effect. If
> pipecurrent is set on
>     (with set -o pipecurrent or set -P), then the last command of the
> pipeline is executed
>     in the current shell environment. ...
>
> Doesn't this mean that the left list of a pipeline will always run in a
> child shell
> environment (therefore a separate address space?), regardless of
> pipecurrent,
> and that JES symbols of the parent shell will not be available in that
> child shell
> environment?
>
> -- 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

Reply via email to