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.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Wednesday, December 05, 2007 8:21 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: getenv/putenv APIs
Thanks Scott. I will give this a try. I was doing some reading and thinking
overnight on environment variables. From what I have read the environment
variables are job specific and unlike the *LDA they are not replicated to a
submitted job. So environment variables would be a good way to pass data
between programs within on job but it would not be a way to collect a bunch
of run time options for a report and then submit a job to run the report
which would pick up those environment variables and use them. But then maybe
in V6R1 when there is the ability to span a thread off an RPG application
SBMJOB might be a thing of the past. In the mean time, can you think of any
way that the interactive jobs environment could be replicated to a submitted
job?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, December 05, 2007 5:19 AM
To: Midrange Systems Technical Discussion
Subject: Re: getenv/putenv APIs
Hello,
Thanks Scott, I would be interested in seeing how to do this. I am on
V5R4 and using ILE RPG . . .
It's really pretty simple if you're familiar with pointers. The system
stores environment variables as null-terminated strings (that is, C
style strings). There's a pointer that's exported from one of the C
runtime service programs called 'environ'. This pointer points to an
array of pointers. The array is variable-length. It consists of
pointers that point to environment variables, and the array is
terminated when an address is *NULL.
So if your job has 3 environment variables set, you'd have this:
ptr(1) = first env var.
ptr(2) = second env var.
ptr(3) = third env var
ptr(4) = *NULL.
Basically, you use *NULL to detect when you're at the end of the array.
Each environment variable is (as I mentioned) a null-terminated (i.e.
x'00' terminated) C-style string. It consists of the variable name, an
equal sign, and the variable's value.
So if you have a variable named 'LANG' that is set to
/QSYS.LIB/EN_US.LOCALE then in memory it looks like this:
LANG=/QSYS.LIB/EN_US.LOCALE<00>
Where <00> signifies the x'00' (null) terminator.
To deal with this in ILE RPG you have to do the following:
a) Include BNDDIR('QC2LE') to allow access to the ILE C runtime.
b) Use import('environ') to get the pointer to the array.
c) Base an array of pointers on the 'environ' pointer.
d) Loop through the array of pointers, looking for *NULL.
e) For each one that's not null, use the %STR() BIF to convert the
C-style string to an RPG varying string.
f) If need be, scan for = to separate the variable from the value.
Here's an RPG proof-of-concept program that just reads the list of
variables and prints them to a program-described printer file. This
might be a bad example since it chops off the variable name at 30
characters and the value at 100 characters (they can potentially be
longer than that) but I had to shorten them to fit in a typical printer
record. If you weren't printing them, you'd want to make the 'VAR' and
'VALUE' variables larger, and you'd probably want them to be VARYING as
well...
Anyway, enough babble... here's the code:
H DFTACTGRP(*NO) BNDDIR('QC2LE')
FQSYSPRT O F 132 PRINTER
D environ s * import('environ')
D env s * dim(32767)
D based(environ)
D x s 10i 0
D pos s 10i 0
D whole s 65535a varying
D var s 30a
D value s 100a
/free
for x = 1 to %elem(env);
if (env(x) = *null);
leave;
endif;
whole = %str(env(x));
var = '';
value = '';
pos = %scan('=': %str(env(x)) );
if (pos>1);
var = %subst(whole:1:pos-1);
endif;
if (pos < %len(whole));
value = %subst(whole:pos+1);
endif;
except;
endfor;
*inlr = *on;
/end-free
OQSYSPRT E
O Var
O Value +2
--
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
