ca.portal.admin

Retrieve lpar name from ADS dialog

Discussion created by ca.portal.admin on Jun 13, 2008
Latest reply on Jun 13, 2008 by ca.portal.admin
Hello list,

We have three CVs with the same CV number running on three different
lpars. In an ADS dialog we want to test which lpar the CV is running
on.

Is there a way to retrieve the lpar name from an ADS dialog?
Alternatively can this be done from an assembler program?

Thanks for any help!

Hans Olav Kongelf
EDB Business Partner AS
Oslo, Norway
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Retrieve LPAR name from ADS dialog
"Hans,

Here is food for thought. If you rely on the LPAR name for
differentiation and you decide to move things around in the future you
will have to change your ADS dialog to recognize the new LPAR names.
Consider an approach that allows you, the DBA, to tag each CV or
database with an ID. Here is my initial thought.

1: Add an OOAK record to your schema containing two fields; a calc key
(always set to 1), and an ""ID"" field
that will be used to identify this particular copy of the database.
If you have many databases in a CV
and you want to set the value at the CV level, put the OOAK record in
only one of the databases.
If you do this, the lookup program will need to bind its own run unit
to this particular database.

2: Write a simple batch COBOL program to store an ID string or number in
the
OOAK record (i.e. DEVELOPMENT, TEST, QA, DIASTER BACKUP, PRODUCTION,
DIVISION2, GEOLOCATION, etc.), whatever is appropriate.

3: Run the program to set the ID whenever you replace or refresh a CV,
or need to tag a database for any reason.

4: Write a callable subroutine to retrieve the ID and alter your
application programs to call it as needed.

This could become expensive, if this call will be made in high
volumes and you choose to store the ID in
a dictionary or a separate database, because you will be binding run
units for each call. In this
case have the subroutine cache the ID value in memory. This way it
will only need to BIND a run unit
once per CV startup, or batch job. If you go this route, the
subroutine will need to know whether it
is running in CV or batch mode. We can send you example code in this
regard.

Using this, or a similar approach, will allow you to move various
versions of the database anywhere you like and the application will know
what to do based on the ID you set and not the one set by a system
programmer.

Hope this helps,

Tom Hebert
ObjEx, Inc.
+1 908-813-2866

Outcomes