Wierd, I just loaded the RFE before posting, and loaded it again just now.

Maybe you have to logon to RFE first to follow the link?

FWIW, here is some info from the RFE:

Description:Please provide options -    a global default in BPXPRMxx and
user level option in user's OMVS segment for a "blind dubbed" process to
inherit its environment from the "init" process (PID 1).

Currently, an address space that is not started by USS Logon or fork or
exec can "dub" and become a Unix process simply by using a Unix callable
service (aka "blind dubbing").    When this happens, it does not inhert
from (its ppid is not) the init process.      It does not inherit the
default environment from init as configured in /etc/init.options.
 Environment variables such as TZ, the umask etc then need to be configured
for each and every dubbed process.      How many customers are required to
configure the TZ environment variable in dozens of individual jobs?      It
is silly beyond comprehension.

Use case:Dozens of started tasks, such as Websphere, CICS, IMS, etc, etc,
that use Unix are currently required to duplicately configure system
default environment variables (such as TZ, default umask) inidividually.
       A globl BPXPRM option would allow all such "blind dubbed" jobs to
inherit their environments.      If the global option was not enabled, an
individual user could enable this option in the OMVS segment for that
userid.    This is consistent with all other UNIX implementations that I am
aware of.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin <
[email protected]> wrote:

> On Fri, 2 Dec 2016 16:15:05 -0600, Kirk Wolf wrote:
>
> >You can definitely set them by using setenv() from a C program, even if
> the
> >C program gets dubbed in a job step (i.e., not run from a z/OS UNIX
> shell).
> >
> >I've done this before in the TSO logon proc:
> >
> >//CEEOPTS DD *
> > ENVAR("XXX=YYY")
> > ...
> >//*
> >
> I suspect this works only on the EXEC statement; I can't DYNALLOC it later.
> I'd be delighted to be shown wrong.
>
> I'm not authorized to modify "the" TSO logon proc.
>
> >I'm not sure that this helps for a dubbed non-LE program though.     My
> use
> >was with headless CEATSO address spaces, where I was launching a LE
> program
> >using  a headless ISPSTART PGM(xxxx) TSO command.     ENVAR LE options
> >probably only get picked up when an LE environment program is started.
> >
> I have, for example an EXEC/Macro that invokes "pax -v" to display a
> detailed
> directory of a pax.Z archive.  Invoked from a shell, it displays contents
> with
> local time; from ISPF DSLIST, UTC.  If TZ were available it would work
> alike
> in both environments.
>
> >You might want to look at this RFE (and vote for it) since it probably
> >addresses the common needs in a more general way:
> >
> >https://www.ibm.com/developerworks/rfe/execute?
> use_case=viewRfe&CR_ID=59716
> >
> which, not astonishingly, is telling me:
>     Our apologies...
>     The content you are trying to access is not available. Please try
> again later.
>
> Thanks,
> gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to