Re: Getting storage info from multiple LPARs -- MIDRANGE-L

I've been on the platform quite some time too. My 40th anniversary with
this company is next year. I cannot recall the last time I put a RPG
program into production. I'm more of a 'systems' guy now. Nowadays when I
even think of writing a CLP I'm more inclined to use a stored procedure
instead. SQL is the reason. I've gotten comfortable enough with them that
I see no reason why to try to shoehorn SQL into CL.

On Mon, Feb 24, 2025 at 5:49 PM Kelley Shaddrick <KShaddrick@xxxxxxxxx>
wrote:

Hi Dan,

Thanks for the info, greatly appreciated. While I've been on the iSeries
longer than I care to admit (I'm in more of a hardware role now), I haven't
worked with stored procedures, so a new adventure. I have a couple of
hundred LPARs that I want to gather info on without having to sign into
each one of them. I'd like to run it the process maybe once a week and have
the info available to the other tech support folks.

Thanks,

Kelley

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Dan
Bale
Sent: Monday, February 24, 2025 4:08 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Getting storage info from multiple LPARs

Three-part naming is the secret sauce. I have a table on the host system
called, wait for it, LPARS, and it has a record for each system, including
the host. In addition to the system name, it includes a sequence number
used for sorting the results that get pasted into a spreadsheet. So, in my
stored procedure, I loop through the LPARS table, then prepend the system
name to '.QSYS2.ASPINFO' (or any other SQL service I'm using).

When I first started in this role a year ago, our twice weekly "admin
checks" called on the on-call person to sign on to every LPAR and run a
series of commands to collect info that would be pasted into the
spreadsheet. (The ASP_INFO query replaced TAATOOL's WRKASP.) We have
enough active LPARs that it would take 2 - 3 hours to do all those checks
"manually". Now, with the stored procedures, I can open up a script, "Run
all", do some other task for 30 minutes, come back, and paste results to
the spreadsheet.

Based on your OP, Vern identified the service more appropriate for your
needs, QSYS2.SYSTEM_STATUS_INFO. We needed to track changes at the ASP
level, thus, we use QSYS2.ASPINFO.

- Dan Bale

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Vern Hamberg via MIDRANGE-L
Sent: Monday, February 24, 2025 4:22 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Subject: Re: Getting storage info from multiple LPARs

Hi Kelley

It depends on what you need - I suggest QSYS2.SYSTEM_STATUS_INFO SQL
service - documentation says this is like WRKSYSSTS - Dan's suggestion,
QSSY2.ASP_INFO - is more like WRKCFGSTS, the documentation page says.

I like the idea of a stored procedure - I wonder if it might not be able
to use 3-part naming - lparname.qsys2.asp_info or
lparname.qsys2.system_status_info = whichever you need - I believe the
output from another LPAR will be presented on the system where run these
services.

Maybe see about getting system names from something - maybe there is a
service to get network names or RDB names - then combine that with the
3-part naming. I'm just speculating, as I've not had to do some of these
things yet.

--

*Regards*

*Vern Hamberg*

<cid:part1.dyaLL7jP.wGBZ0LZ9@centurylink.net>

On 2/24/2025 2:05 PM, Dan Bale wrote:

I'm aware of a few options.

1. IBM's Administration Runtime Expert (ARE); I am still in the process

of learning this one, so I can't offer any how-to's.

2. If you have DDM configured to reach all of your LPARs from one box,

you can write a stored procedure to run a query on each system and insert
the results into a local table. I currently use an IBM i service,
qsys2.asp_info, to return information from all of our LPARs to one system.
This is probably the one you should look into.

- Dan Bale

-----Original Message-----
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Kelley Shaddrick
Sent: Monday, February 24, 2025 1:55 PM
To:MIDRANGE-L@xxxxxxxxxxxxxxxxxx
Subject: Getting storage info from multiple LPARs

Hi all,

My environment has several servers (Power 8, 9, and 10) with several

LPARs per server. Is there a tool or perhaps a remote command I can use to
get storage information from each LPAR without having to log into each one
manually and do a WRKSYSSTS? Ideally, I'd like the tool/command to be
resident on one LPAR and to query all the other LPARs (once a day, once a
week?) and store the data in a file for display. Any thoughts?

Thanks,

Kelley

*** CONFIDENTIALITY NOTICE: The information contained in this
communication may be confidential, and is intended only for the use of the
recipients named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution, or
copying of this communication, or any of its contents, is strictly
prohibited. If you have received this communication in error, please return
it to the sender immediately and delete the original message and any copy
of it from your computer system. If you have any questions concerning this
message, please contact the sender. ***
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.