Our head developers where just talking about this and came up with the same issue and the same solution. We talked about having a prefix on each variable that is the application it is for. So SRRENROLL_COPIES would be used by SRRENROLL report jobs and FORPAYCHECK_COPIES would be used by FORPAYCHECK. We also realized that cleanup of variables would be important. So the submitting job would need to set the variables, submit the batch job, delete the variables so if the user ran the same job twice during the same session the first jobs variables did not get submiited to the second requests job.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Wednesday, December 05, 2007 9:06 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: getenv/putenv APIs
From: Mike Cunningham
Very cool!!! I guess the documentation I found is out of date. It had said
that environment variables are not copied on a submitted job.
From: Crispin
Mike,
I've been looking at this for exactly the same reason. On the SBMJOB
command, have a look at the CPYENVVAR parameter. It will allow the
variables to be copied.
Crispin.
My only caveat on named properties vs. parameters is that you probably want
from the very beginning to have a good naming convention in place that
avoids collisions. It's a real pain when you have two programs in your
stream that use the same property name but need different values in it.
Printed report options are typical; one report needs two copies, the other
needs one. Both have a property "COPIES=". How do you specify it? Simple
prefixing is typically the way to get around this, even though it leads to
slightly more cumbersome property strings.
Joe
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
