**URGENT**Global variable & Service Programs

[tomliotta]

HOW can I make the value of this global variable available in both service programs(the value of Z is changed in program A only) ?? Urgent help PLssssssssssssss

A few days old, but one more alternative...

I once needed to pass a "parameter value" from PgmA down to some PgmD, but couldn't chance changing interfaces in intermediate PgmB, PgmC and/or whatever else might get stuck in between. After quite a bit of thought, I eventually realized that putenv()--Change or Add Environment Variable and getenv()--Get Value of Environment Variable worked exactly as I needed.

Values could be created and retrieved as needed. They're named values, so uniqueness can be controlled. The putenv/getenv APIs/procs already exist, so it's not even really necessary to create your own; but it's certainly possible to do so if you want to wrap in more robust or specific code.

[Barbara Morris]

Good point about environment variables, Tom. The names aren't limited to 10 characters like objects are, so the names can be as specific as needed.

The values of the environment variables can even be copied to a submitted job by specifying CPYENVVAR(*YES) on the SBMJOB.

[EmmanuelW1]

Barbara wrote: "The values of the environment variables can even be copied to a submitted job by specifying CPYENVVAR(*YES) on the SBMJOB."

Which I took to mean that my assertion that LDA is the only temporary structure that can be shared between jobs was wrong...and I guess it is wrong.

But, whereas with the LDA, the batch job receiving the copy of the interactive job's LDA contents can use that information via RTVDTAARA, is this possible with environment variables? If so, how would you do that? (None of the following seem to be it:
Commands
1. Add Environment Variable ADDENVVAR
2. Change Environment Variable CHGENVVAR
3. Remove Environment Variable RMVENVVAR
4. Work with Environment Var WRKENVVAR)

Cheers,

Emmanuel

[Barbara Morris]

You use the getenv() API to retrieve the value of an environment variable. Here's a little program that gets the name of an environment variable as a parameter, and displays the value of the environment variable. (I just used a length of 50 so I could use DSPLY. In real life, the value of an environment variable isn't limited to 50. I don't know what the limit is, if there ever is a limit.)

Notice that the value of the environment variable is a null-terminated string. So you probably couldn't put a data structure into an environment variable, unless there were no packed fields, integer fields, float fields, varying-length fields, or pointers, all of which often contain x'00'.

dcl-pi *n;
   whichEnvvar char(32) const;
end-pi;
dcl-pr getenv pointer extproc(*dclcase);
   envvarName pointer value options(*string);
end-pr;
dcl-s envvar pointer;
dcl-s envvarVal varchar(50);

envvar = getenv(%trim(whichEnvvar));
if envvar <> *NULL;
   envvarVal = %str(envvar : 50);
else;
   envvarVal = 'No such envvar';
endif;
dsply envvarVal;
return;

==> addenvvar abc value('This is envvar abc')
==> call mypgm 'abc'
DSPLY  This is envvar abc

[EmmanuelW1]

Barbara,

Thanks for the example - I've filed it away for the day I abandon LDA :-). Maybe 01/01/18...

Cheers,

Emmanuel

[Scott Klement]

IMHO, using LDA is a really bad idea. I don't know how many hours and hours I've spent troubleshooting headaches because two programs just happened to use the same area of the LDA, and the problem never surfaces until a user happens to run these particular two programs back-to-back. LDA is an absolute nightmare. Yes, it made sense in the 1970's when you needed a little bit of memory you could work with between punch card stacks... but, good grief, PLEASE don't use it in the 1990's and later!!

Environment variables, like Barbara's example are a really easy solution.

Or, if you prefer to avoid APIs like getenv(), you could simply create a regular (non-LDA) data area in QTEMP and read it using RPG's built-in support for data areas. Use a different named data area for each variable you want, and it's very similar to environment variables.

[EmmanuelW1]

Scott wrote: "Or, if you prefer to avoid APIs like getenv(), you could simply create a regular (non-LDA) data area in QTEMP..."

I think that misses the point of using LDA - unlike QTEMP, the contents of LDA can be transferred from an interactive session to a batch job submitted from that session. For that functionality, using QTEMP wouldn't cut it.

Sorry that it's caused you headaches!

Cheers,

Emmanuel

[Scott Klement]

Then use an environment variable.