Re: Analysing DSPLOG to CFG

Al,

 You can do this by reading all the qhst* files that exists in QSYS.

Pete

---------------------------- Original Message ----------------------------
Subject: Analysing DSPLOG to CFG
From:    "Al Mac" <macwheel99@xxxxxxxxxxx>
Date:    Sun, December 11, 2005 8:57 pm
To:      midrange-l@xxxxxxxxxxxx
--------------------------------------------------------------------------

> I am not as skilled as you guys on spectrum of topics, because I am a jack
> of all trades, jedi master of only some, so like to work with various
> capabilities for multiple applications to get more familiar with what can
> be done.  I have an idea for a potential solution to multiple challenges,
> but I an unsure of all the pieces.  I do most of my programming nowadays
> in
> RPG/400 with embedded SQL, and occasionally Query/400 work files (because
> speed of implementation is lightning fast compared to other approaches).
>
> I'd like to read current DSPLOG info into a program, obtain selected
> messages, extract security and performance tracking info:
>
> CPF1124 Sign-on/Job Start or CPF1164 Job Ends
> * Layout of this in WRKMSGF QCFPMSG
> ** Hey, that's a message object ... can a program access it like we access
> a physical file?
> ** Can some program, with overlays, access prior QHST-whatever or is
> current QHST a different object type requiring a different program?
> * I not want to read the whole thing, perhaps different programs extract
> info to check out different things.
> ** Can embedded SQL grab just those selected message lines, when there's
> variable field positioning, due to uncertain lengths of parameters?.
> *** I want the SQL to dump what's with those message lines into a data
> structure, then RPG test particular fields for certain content matches.
>
> I envisage different program variants
> * Who is using main console for tasks that should be QINTER? ... get times
> to match with performance sluggishness
> * JOBQ tasks taking entirely too long to execute, other than those I
> already know about
> ** I have identified some long running jobs, massaged the programs, made
> significant improvements in their performance.
> * Security interest in identifying user-id sign-on from site other than
> user true location.
> *** e.g. same person appears to be signed on simultaneously from multiple
> cities (either they sign on and never sign off, or too many people are
> using their password)
> *** e.g. trainee memorizes password of visitor showing how to do stuff,
> then goes exploring beyond what we intended them to get into.
> *** e.g. some co-worker has deduced one of the QIBM passwords, so time to
> change that password again.
> *** e.g. security-wise person notes last time the AS/400 thinks they
> signed
> on was much more recent than their human memory, need to document from
> where their ghost signed on, in addition to changing password.
> ** when subsystem QINTER in message CPF1124 sign-on, seek programmable
> equivalent of WRKCFGSTS *DEV then "The Workstation ID used" (get from
> CPF1124) to get at F14 5 F11 what CTL Controller is that work station
> attached to (Local, Virtual, or which Remote Site).
> *** First few letters of our remote site controllers naming are named
> after
> the particular site.
> *** What's the utility to get that? RTVCFGSTS or some API?
> **** I am not at all skilled with API/400
>
> -
> Al Macintyre  http://www.ryze.com/go/Al9Mac
> BPCS/400 Computer Janitor ... see
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>