Missing "exported" variable

[Ulrich Schmidt]

Hello,
I'm running the job:
//START1 EXEC DTLSPAWN,
// CMD='/u/lsy/int/u005078/test.sh'
//STDENV DD PATH='/u/lsy/int/u005078/stdenv',
// PATHOPTS=(ORDONLY)

test.sh contains:
#!/bin/sh
echo ">"${JAVA_HOME}"<"
echo ">"${CLASSPATH}"<"

stdenv contains:
CLASSPATH=${JAVA_HOME}/lib:${JAVA_HOME}/lib/ext:
export CLASSPATH=${CLASSPATH}

as a result I get (STDOUT):
><
>${JAVA_HOME}/lib:${JAVA_HOME}/lib/ext:<

Where is the variable JAVA_HOME exported by /etc/profile. It isn't there, even if I insert ". /etc/profile" before the CLASSPATH-Statement in STDENV.

This is just the other way round as BPXBATCH. BPXBATCH only delivers the variables /etc/profile - that means the CLASSPATH is unmodified by STDENV.

Do you have an idea how to deal with this?

brdgs,
Ulrich Schmidt

[Ulrich Schmidt]

>>....
>> BPXBATCH only delivers the variables /etc/profile - that means the >> CLASSPATH is unmodified by STDENV.
>>.....

Sorry,

wanted to say: This is just the other way round as BPXBATCH. BPXBATCH only delivers the variables set by /etc/profile ...

brdgs,
Ulrich Schmidt

[Ulrich Schmidt]

When running it this way, it behaves like BPXBATCH:
//START1 EXEC DTLSPAWN
//STDIN DD DATA,DLM='$$'
/u/lsy/int/u005078/test.sh
$$
//STDENV DD PATH='/u/lsy/int/u005078/stdenv',PATHOPTS=(ORDONLY)

That means the exported CLASSPATH from STDENV is not used but the exported values from /etc/profile.

When changing stdenv to this:
SETPATH=set/a/path
export EXPPATH=export/a/path
CLASSPATH=${JAVA_HOME}/lib:${JAVA_HOME}/lib/ext:

and the script to:
#!/bin/sh
echo ">"${JAVA_HOME}"<"
echo ">"${CLASSPATH}"<"
echo ">"${SETPATH}"<"
echo ">"${EXPPATH}"<"

The result is:
>/usr/lpp/java/J6.0<
>/usr/lpp/java/J6.0/lib/tools.jar:/us....................
>set/a/path<
><

What I can get out of this:
1. STDENV does not allow for export of variables (see EXPPATH)
2. STDENV does not allow for change of already exported variables (see CLASSPATH - it's not exported in this case but the values set be /etc/profile are still used)

Especially the second one is a problem; I need to modify CLASSPATH and dont' want to do this in the script.
And I would prefer to be able to invoke script from EXEC-Statement rather than from STDIN-DD. I would like to run this as STC.

Ulrich

[dovetail]

Let me describe how it works, and hopefully that will answer your questions.


1) LE will read //STDENV before the DTLSPAWN program gets control. It will set environment variables, but it will NOT do any substitution (resolve any variables). You can only have lines in that have "var=value", and not commands.

2) DTLSPAWN then will set any environment variables that are specified on the CMD (PARM). Example:

// EXEC DTLSPAWN,CMD='var1=val1 var2=val2'
//STDIN DD *
echo var1=$var1 var2=$var2
//

3) DTLSPAWN will then start the command, if specified, or a login shell if no command was specified. So, if you do:

// EXEC DTLSPAWN,CMD='/my/command'

it will run it, but without a login shell so /etc/profile and ~/.profile will not run. If you want a login shell, you can do this:

// EXEC DTLSPAWN,CMD='/bin/sh -L -c /my/command'

Or, this:

// EXEC DTLSPAWN
//STDIN DD *
/my/command
//


A significant difference between DTLSPAWN and BPXBATCH is that DTLSPAWN will run the command (or default login shell if not command given) in the same address space. This allows you to have commands that use DDs, etc.

I hope that this has answered your questions, if not, please follow up with another.

Thanks,
Kirk Wolf

[Ulrich Schmidt]

Thank you very much. It clarifies something.
For the task we meant to use this we are starting several STCs. Some on behalf of JZOS and some are triggered to run drectly as scripts though it internally starts a JVM. As the script runs some logic we cannot use JZOS for this. But we would like to use the same STDENV to avoid duplicate specification of $APPLHOME, oder $CLASSPATH and so on.
I need to think how to solve this without redundancy.
Thanks,
Ulrich Schmidt

[dovetail]

I see the confusion - the STDENV DD for DTLSPAWN is only processed by LE as var=value, wherease the JZOS launcher uses it as a real shell script.

For DTLSPAWN, if your "stdenv" script is actually a shell script, then you might consider just dotting it in.

Also - why wouldn't you be able to use the JZOS launcher and put logic in the STDENV shell script?

[Ulrich Schmidt]

The invoked java programs read this way (I show it, I don't know how to name it):

java some.class "argument" <<!
string
string
string
!

How could I do this with JZOS?

Ulrich Schmidt

[dovetail]

For the JZOS launcher, the stdenv shell script can set the variable "JZOS_MAIN_ARGS" to any arguments that you want to pass to the java program.

[Ulrich Schmidt]

Those strings are redirections of commands. The class can be started ineractivly (Putty) and the user is prompted for directives/input. To use args[] instead would need to change program - this is not possible.
Thanks,
Ulrich Schmidt