Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Envionment variables?
105 views
Skip to first unread message
Paul Gilmartin
Dec 2, 2016, 4:49:13 PM12/2/16
to
(Sent earlier to ISPF-L by mistake. Should have gone here.)
Is it possible to set environment variables in a dubbed TSO address space?
There are several that might be useful: TZ, LC_ALL, ALL_PROXY, ...
I know the Rexx environment function is unavailable without the OMVS
function package. Would a C program work?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Is it possible to set environment variables in a dubbed TSO address space?
There are several that might be useful: TZ, LC_ALL, ALL_PROXY, ...
I know the Rexx environment function is unavailable without the OMVS
function package. Would a C program work?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
Dec 2, 2016, 5:15:17 PM12/2/16
to
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'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.
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
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
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'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.
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
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Paul Gilmartin
Dec 2, 2016, 5:57:13 PM12/2/16
to
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.
>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'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.
>
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
>
Our apologies...
The content you are trying to access is not available. Please try again later.
Thanks,
John McKown
Dec 2, 2016, 6:10:39 PM12/2/16
to
On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin <
0000000433f0781...@listserv.ua.edu> wrote:
> >
> 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're a UNIX person, Gil. Have you tried:
0000000433f0781...@listserv.ua.edu> wrote:
> >
> 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.
>
>
CALL BPXWUNIX("TZ=CST6CD6 pax -v ...", ...)
If you're using BPXWUNIX(), it invokes the standard UNIX shell via: /bin/sh
-c '....' and so just prefix the actual command with the environment
variables you want to modify for that command. If you want to do that a lot
in a REXX program, then:
EnvVars="TZ=CST6CDT HOME=/tmp X=z "
...
UnixCommand="some command with parms"
CALL BPXWUNIX(Envvars||" "||UnixCommand, ...)
--
Heisenberg may have been here.
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
Kirk Wolf
Dec 2, 2016, 6:11:55 PM12/2/16
to
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.
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.
Paul Gilmartin
Dec 2, 2016, 6:36:41 PM12/2/16
to
On Fri, 2 Dec 2016 17:11:42 -0600, Kirk Wolf wrote:
>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?
>
Yup. It's right there in the title bar, in small dark grey (about shade 15 of 50)
>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?
>
letters on a black background. "not available. Please try again later" is a
funny IBM-ish way to tell the user that login is required.
>FWIW, here is some info from the RFE:
>
environment early in m session. "Inherit from init" is a slippery
concept for spaces that are not descendants of init.
Thinking about LOGON, is there a way to list the procedures available
to me? To be useful this information must be available before the
procedure is executed. I could imagine entering "*" as the procedure
and, once my password is accepted, being presented a selection list.
-- gil
Paul Gilmartin
Dec 2, 2016, 6:43:49 PM12/2/16
to
On Fri, 2 Dec 2016 17:10:27 -0600, John McKown wrote:
>On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin wrote:
>
>> 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.
>>
the command line with TZ=...? Much worse, to embed it in scripts I share with my
co-workers in Australia?
I'm sure it would work, but not the answer I'm looking for.
Thanks,
>On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin wrote:
>
>> 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're a UNIX person, Gil. Have you tried:
>
>CALL BPXWUNIX("TZ=CST6CD6 pax -v ...", ...)
>
No! Would you advise a UNIX person to preface every shell command entered from
>
>CALL BPXWUNIX("TZ=CST6CD6 pax -v ...", ...)
>
the command line with TZ=...? Much worse, to embed it in scripts I share with my
co-workers in Australia?
I'm sure it would work, but not the answer I'm looking for.
Thanks,
Kirk Wolf
Dec 2, 2016, 6:58:18 PM12/2/16
to
Why slippery? In Unix/Linux, all processes inherit their environment from
the init process.
All you would need to do is to customize /etc/init.options and z/OS would
behave the same so that blind-dubbed processes would have a reasonable
starting environment variable set.
the init process.
All you would need to do is to customize /etc/init.options and z/OS would
behave the same so that blind-dubbed processes would have a reasonable
starting environment variable set.
Alan Young
Dec 2, 2016, 7:02:37 PM12/2/16
to
Paul Gilmartin wrote:
> On Fri, 2 Dec 2016 17:10:27 -0600, John McKown wrote:
>
>
>> On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin wrote:
>>
>>
>>> 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're a UNIX person, Gil. Have you tried:
>>
>> CALL BPXWUNIX("TZ=CST6CD6 pax -v ...", ...)
>>
>>
> No! Would you advise a UNIX person to preface every shell command entered from
> the command line with TZ=...? Much worse, to embed it in scripts I share with my
> co-workers in Australia?
>
> I'm sure it would work, but not the answer I'm looking for.
>
> Thanks,
> gil
>
Are you starting TSO with the tso or tsocmd shell commands or by some
> On Fri, 2 Dec 2016 17:10:27 -0600, John McKown wrote:
>
>
>> On Fri, Dec 2, 2016 at 4:57 PM, Paul Gilmartin wrote:
>>
>>
>>> 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're a UNIX person, Gil. Have you tried:
>>
>> CALL BPXWUNIX("TZ=CST6CD6 pax -v ...", ...)
>>
>>
> No! Would you advise a UNIX person to preface every shell command entered from
> the command line with TZ=...? Much worse, to embed it in scripts I share with my
> co-workers in Australia?
>
> I'm sure it would work, but not the answer I'm looking for.
>
> Thanks,
> gil
>
other means? If you are using the shell command, maybe you can (ab)use
the TSOALLOC allocation option to allocate a CEEOPTS DD that points to a
file/dataset with the statements and see if it is honored.
Alan
Paul Gilmartin
Dec 2, 2016, 8:59:14 PM12/2/16
to
On Fri, 2 Dec 2016 17:02:10 -0700, Alan Young wrote:
>
>Are you starting TSO with the tso or tsocmd shell commands or by some
>other means? If you are using the shell command, maybe you can (ab)use
>
Actually, logging in with a 3270. Believe it or not, that's still supported.
>
>Are you starting TSO with the tso or tsocmd shell commands or by some
>other means? If you are using the shell command, maybe you can (ab)use
>
>the TSOALLOC allocation option to allocate a CEEOPTS DD that points to a
>file/dataset with the statements and see if it is honored.
>
by child processes, and there's no need to go through the CEEOPTS
mickeymouse. I think.
On Fri, 2 Dec 2016 17:56:16 -0600, Kirk Wolf wrote:
>Why slippery? In Unix/Linux, all processes inherit their environment from
>the init process.
>All you would need to do is to customize /etc/init.options and z/OS would
>behave the same so that blind-dubbed processes would have a reasonable
>starting environment variable set.
>
dubbed TSO process, and its parent is init (1).
But what about my co-workers in Australia? How can they, if they choose,
set TZ for their TSO process to something other than that in /etc/init.options
as they can do in ~/.profile for shell processes.
The documentation in:
z/OS 2.1.0
z/OS Language Environment
z/OS Language Environment Programming Reference
Language Environment runtime options
Using the Language Environment runtime options
ENVAR
is dreadful! It says:
...
Is specified as name=value, where name and value are sequences of characters that do not contain null bytes or equal signs. The string name is an environment variable, and value is its value.
Blanks are significant in both the name= and the value characters. You can enclose string in either single or double quotation marks to distinguish it from other strings. You can specify multiple environment variables, separating the name=value pairs with commas. Quotation marks are required when specifying multiple variables.
It does not say how to code values that may contain quotation marks or apostrophes.
I tried one. At startup, an error message flashes by and vanishes, too fast to read.
-- gil
Tony Harminc
Dec 2, 2016, 9:00:27 PM12/2/16
to
On 2 December 2016 at 18:36, Paul Gilmartin <
friendly letters to login with my (very un-special, anyone-can-get-one)
IBMid. I did so and, albeit after some gratuitous flashing and scrolling,
got the RFE text.
FireFox 50.0.2 on Windows in a Private Browsing window with both Adblock
Plus and Ghostery set pretty strictly. (Strictly enough that I have to
relax things in order to get KC to show more than a blank page.)
Tony H.
0000000433f0781...@listserv.ua.edu> wrote:
> >Maybe you have to logon to RFE first to follow the link?
> >
> Yup. It's right there in the title bar, in small dark grey (about shade
> 15 of 50)
> letters on a black background. "not available. Please try again later"
> is a
> funny IBM-ish way to tell the user that login is required.
I went to the supplied URL and it prompted me in reasonably large and
> >Maybe you have to logon to RFE first to follow the link?
> >
> Yup. It's right there in the title bar, in small dark grey (about shade
> 15 of 50)
> letters on a black background. "not available. Please try again later"
> is a
> funny IBM-ish way to tell the user that login is required.
friendly letters to login with my (very un-special, anyone-can-get-one)
IBMid. I did so and, albeit after some gratuitous flashing and scrolling,
got the RFE text.
FireFox 50.0.2 on Windows in a Private Browsing window with both Adblock
Plus and Ghostery set pretty strictly. (Strictly enough that I have to
relax things in order to get KC to show more than a blank page.)
Tony H.
Paul Gilmartin
Dec 2, 2016, 9:41:40 PM12/2/16
to
On Fri, 2 Dec 2016 19:59:05 -0600, Paul Gilmartin wrote:
> ...
be on DASD, and I don't know where else UNIX files would be kept.
It says RECFM must be F or FB. It states no requirement on LRECL. I'll press my
luck some other day.
A nonsense environment variable I define in CEEOPTS is inherited by OMVS.
TZ, however, is overridden by the value presumably in /etc/init.options.
The TZ in CEEOPTS seems to be ignored in TSO.
You're on the right track with your RFE. /etc/init.options should be read by
PID 1 and overridden in any process where it appears in CEEOPTS or .profile.
What's a "enclave"?
-- gil
> ...
>I tried one. At startup, an error message flashes by and vanishes, too fast to read.
>
Ah! It won't accept a UNIX file. The only rule that seems to apply is that it must
>
be on DASD, and I don't know where else UNIX files would be kept.
It says RECFM must be F or FB. It states no requirement on LRECL. I'll press my
luck some other day.
A nonsense environment variable I define in CEEOPTS is inherited by OMVS.
TZ, however, is overridden by the value presumably in /etc/init.options.
The TZ in CEEOPTS seems to be ignored in TSO.
You're on the right track with your RFE. /etc/init.options should be read by
PID 1 and overridden in any process where it appears in CEEOPTS or .profile.
What's a "enclave"?
-- gil
Tony Harminc
Dec 2, 2016, 9:57:45 PM12/2/16
to
On 2 December 2016 at 21:41, Paul Gilmartin <
Heh... It has two meanings on z/OS: LE has enclaves, and WLM has enclaves.
They appear to be unrelated. Probably you've encountered mention of the LE
kind.
Tony H.
Heh... It has two meanings on z/OS: LE has enclaves, and WLM has enclaves.
They appear to be unrelated. Probably you've encountered mention of the LE
kind.
Tony H.
Paul Gilmartin
Dec 2, 2016, 10:00:42 PM12/2/16
to
On Fri, 2 Dec 2016 19:59:05 -0600, Paul Gilmartin wrote:
>
>
>The documentation in:
> z/OS 2.1.0
>z/OS Language Environment
>z/OS Language Environment Programming Reference
>Language Environment runtime options
>Using the Language Environment runtime options
>ENVAR
>is dreadful! It says:
> ...
>Is specified as name=value, where name and value are sequences of characters that do not contain null bytes or equal signs. The string name is an environment variable, and value is its value.
>
>Blanks are significant in both the name= and the value characters. You can enclose string in either single or double quotation marks to distinguish it from other strings. You can specify multiple environment variables, separating the name=value pairs with commas. Quotation marks are required when specifying multiple variables.
>
OK. Code the required quotation marks:
> z/OS 2.1.0
>z/OS Language Environment
>z/OS Language Environment Programming Reference
>Language Environment runtime options
>Using the Language Environment runtime options
>ENVAR
>is dreadful! It says:
> ...
>Is specified as name=value, where name and value are sequences of characters that do not contain null bytes or equal signs. The string name is an environment variable, and value is its value.
>
>Blanks are significant in both the name= and the value characters. You can enclose string in either single or double quotation marks to distinguish it from other strings. You can specify multiple environment variables, separating the name=value pairs with commas. Quotation marks are required when specifying multiple variables.
>
say BPXWDYN( 'alloc dd(CEEOPTS) new recfm(F,B) reuse msg(WTP)' )
L.1 = 'ENVAR(TZ="EST5EDT",TESTIT="Wombat")'
address 'MVS' 'EXECIO 1 DISKW CEEOPTS (finis stem L.'
Dammit! The quotation marks become part of the value:
user@OS/390.25.00: echo $TESTIT
"Wombat"
user@OS/390.25.00: echo $TZ
MST7MDT
-- gil
0 new messages