RE: Environment variables and IASP's on the I-Series -- MIDRANGE-L

My intention is to hold certain variables that will be global for all of
our boxes.
These variable will hold the (mostly) permanent locations for certain
message files, message queues, etc.

I'm already using a module to retrieve the values - so that will be
application independent.

Simple example:
I often need to parse out the full message text of a message with
parameters. This requires knowing the location of the message file where
the message is (CPF's are in QCPFMSG, RNQ's are in QRNXMSG, etc.) I
don't want to hard code these locations. Another need is the name of
certain message queues that will hold debug information. I don't want to
hard code those either. So I have the following environment variables:

CPF_MSG_LOC = QSYS/QCPFMSG
RNQ_MSG_LOC = QSYS/QRNXMSG
ERR_MSGQ = *LIBL/FDM_ERRMSG

And I have a module to retrieve the location based on the variable. I
like this kind of indirection.

Why not user spaces or data areas?

An extra object to move around. 
An extra object to get trashed.
Data areas often get corrupted (as in un-structured. Messy. Etc)
Commands already built in for WRKENVVAR and such.
The data will not change very often - so it just feels better with
environment variables to me.

The variables will (should) always be the same on all machines.

Specifically about the IASP's - I need an understanding considering our
failover capacities. You know those details of course.

Thanks for the input.

Let me know when you're up for a beer ;-)

Jim



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, 22 September 2005 12:36
To: Midrange Systems Technical Discussion
Subject: Re: Environment variables and IASP's on the I-Series


Hi Jim

Nice to see you on this list (at last !)

You might want to think about what level of the application the 
variables are for before you decide on the most appropriate medium. I 
am guessing that environment variables will be sharable across 
multiple database instances as from what I understand they live at 
the file system/operating system level. If the data that you want to 
pass around is application or database specific (which relates to 
your use of IASP's) then you may not want to be able share the data 
at this level.

When I have this kind of requirement I like to have a user space or a 
data area where I can store the data in a structure way and use a 
service program or RTV command to return the data I need when I need 
it. this makes it easy to change the container holding the data or 
the structure of the data without affecting any programs accessing 
the data because the access to the required data has been 
externalised. This works well if you are doing something like 
maintaining state or allowing multiple jobs to see what the status of 
a process is.

If the data is per-job related this may be too much overhead and a 
table might be better, but table records have a habit of hanging 
around whereas a user space created in QTEMP automatically goes away 
at end of job, which can be kind of handy.

Some food for thought anyway.

Regards
Evan Harris

At 12:06 p.m. 22/09/2005, you wrote:
>We're considering holding some information in environment variables for
>use on our I-Series instead of passing such data between programs.
>
>Firstly, I don't see a lot of reference about environment variables. Is
>there any reason why they are not often used?
>
>Secondly, I'm curious where the variables live. We utilize multiple
>IASP's - and I'm trying to find out if each IASP gets it's own
>environment space or if such variables are held in SysSpace.
>
>Any help would be appreciated.
>
>James P. Wiant
>jim.wiant@xxxxxxxxxxxxxxxx
>
>
>'Imagination is more important than knowledge'
>Albert Einstein