Re: SBMJOB and CPYENVVAR parameter

I suspect that no CPYENVVAR parameter was added to RRTJOB [and probably TFRBCHJOB] in order that they remain historically simple; i.e. extra capabilities, those always existing and those added to the SBMJOB, have never appeared on either of the other commands. I suspect that no copy of the environment variables is made for a new routing step [presumably neither to a transferred batch job], may be consistent with the concept that a new routing step [and transferred batch job] must reestablish any allocated resources; e.g. the expectation is that the new step must issue new ADDEVNVAR to make them available in the new routing step, just as such jobs would need to do new opens, locks, etc.. Possibly however, failure to copy the environment variables to make them available for the new routing step was simply an oversight. Apparently nobody trying to depend on those variables has reported their loss in that scenario, or IBM has failed to externalize that in a searchable KB or docs, or I am incapable of properly searching & finding any reference :-)

If operating properly, it sure would be nice if the command documentation\help-text would explicitly refer to the "environment variables" beyond just "any objects allocated in the previous routing step are deallocated and any open files are closed. If the objects or files are needed in the new routing step, they must be allocated or opened again." The problem with "allocated" is its potential double meaning, as both "locks" and preparing any other various resources which could include environment variables. I think the current text implies only locks, but I am not sure. Seems reasonable to open a defect PMR to get some documentation stating the intended result; e.g. an APAR opened and closed, even with "permanent restriction", thus documented by IBM that environment variables will not be available in a new routing step [or transferred batch job]. I doubt that there would be any change to the existing function because a change to always make the variables available would be an incompatible change, and to make the variables optionally available [effectively & appropriately] requires adding a parameter to the command. Approaching the issue as a documentation issue, for example requesting an update to the infocenter\help-text via "electronic reader comment card" would effect similar, but doing so would not imply any desire for the functionality to exist... if someone felt the environment variables should be available; i.e. just suggesting that the documentation is simply lacking any note of the current experienced outcome, expresses acceptance of the way it works.

Regards, Chuck

Dean Eshleman wrote:

I did a little more digging to see if I could figure out why the
routing data made a difference. It turns out that the last thing
the routing program for the compile preprocessor does is a
"RRTJOB RTGDTA(QCMDB)" command. I didn't write the routing
program, so I don't know if there is a better way to do it or
not. Anyhow, after reading the help on this command, I'm
assuming this is why the *JOB level environment variable is lost.
Does that make sense? Maybe this is a bug in the RRTJOB command.
You would probably know that better than I.

On Thu, 10 Dec 2009 14:27:18 -0800 CRPence wrote:

Dean.Eshleman wrote:

Problem solved! Another developer here tried to do this and
it worked for them. Then, I remembered that the routing data
on the job description I was using was setup to use a compile
preprocessor. When I switched to a different job description
that had the normal routing data (QCMDI), then it worked as
expected. To bad I didn't think of that sooner.

So there is a documented restriction on the feature of the CPYENVVAR(*YES) for SBMJOB, that the routing must use
RTGDTA(QCMDI) or perhaps that QCMD is the request processor?
That would seem like a pretty huge unstated limitation on a
feature that is generically described as determining "whether
the environment variables from the submitting job are copied to
the new job." The control is at the point of submission, so
why would the point of entry per routing have any relevance as
to the availability of that data? I would consider the
condition of the "copied" data being unavailable in the "new
job" to be a defect; i.e. they were not really copied.