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

You're not convincing much dude on a User Space to control semi-static
reference values like I'm thinking. Although the IPL consideration is
something .... I'm guessing the variables would stay there though.
There's been one defined on DEVMAC for a long time..ICU_DATA =
'/QIBM/ProdData/OS400/icu/data'. 
I don't have a clue what it's for, but it's persistant and I know DEVMAC
has bounced several times and this value is still there. Evidence but
not proof, eh?

I'll pass along the ideas to the rest of my critical analysis team (you
know the crew) and see what they think. I'm still leaning toward the
environment variables though (btw I learned about manipulating them from
an article by Bob Cozzi, and from what I've seen he knows a thing or two
:-)

Sunday sounds like an option. I can either beat you at pool, or you can
try to drive User Spaces home if you want. Shoot me an email at home and
we'll check schedules. Can't tonight, leaving at noon for an appointment
at home that can't be missed.

ttyl

Jim

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


Hi again Jim

seems to me a user space is better if the values are required to be 
persistent; I would expect that the environment variables would need 
to be set somewhere, maybe at best at IPL - which means you need 
somewhere to retrieve them from...

I like the indirection factor as well, but a user space works good 
for this stuff. You can easily knock up a command to mimic the 
behaviour of the WRKENVVAR command. Using a combination of a 
WRK<something> command and a RTV<something> command will achieve what 
you want. For the WRK command you need to investigate a Prompt 
override program. You guys already do this for the RTVIASPA command - 
why do it another different way ?

I generally use an External data structure to document the layout and 
impose structure but it is hardly a requirement - just a preference.

Re the beer: I'm up for a beer tomorrow night if you're interested, 
otherwise Sunday may be a chance.

Regards
Evan Harris

At 12:52 p.m. 22/09/2005, you wrote:
>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