Re: Help w/ AS/400 power crash -- MIDRANGE-L

I suppose that an empty QUSRSYS/QRCLSTG data area means that RCLSTG has never
been run on this box (or on the current VR)?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

RCLSTG does not occur with each IPL.  RCLSTG is a special process that
fixes internal relationships between objects in the system.  Theoretically,
you should never have to do this, but in reality, the system does abend
occasionally.  (Most frequently in V3R1, but the system has been quite
stable since then.)

When the system does abend, this is what fixes most things.

The length of time requires is very system specific.  There is a data area,
QRCLSTG in QUSRSYS , that shows the starting and ending times of the last
RCLSTG with starting and ending times.  Make sure that this data area shows
the time of your operation on your system (the system name is shown on line
3), because when this library is shipped by IBM, it shows the RCLSTG
timings on the system in Rochester that was used to build your system.  IBM
says that this is not a bug, although I disagree.

Al



Al Barsa, Jr.
Barsa Consulting Group, LLC

400>390

914-251-1234
914-251-9406 fax

http://www.barsaconsulting.com
http://www.taatool.com







                    D.BALE@handleman.co

                    m                          To:     MIDRANGE-L@midrange.com

                    Sent by:                   cc:

                    owner-midrange-l@mi        Subject:     Re: Help w/ AS/400
 power crash
                    drange.com





                    04/12/01 03:52 PM

                    Please respond to

                    MIDRANGE-L









I am fairly certain that RCLSTG does not occur automatically with IPL.
Someone else can confirm/deny.

Re: the DSPLOG filtering...  I am, in a word (errrr, 2 words), too lazy.
Poring through page after page of useless junk...  I noticed drool down the
front of my shirt yesterday as I woke up from doing this.

*PRTWRAP does not print second-level text.

The problem with selecting the message IDs to show is that I don't
necessarily
know which message IDs I should be selecting.  I would much rather *OMIT
selected IDs that I *know* I don't need to see.  Yes, I can copy/paste
message
IDs from one session to another.  Even if I wanted to go through *that*
trouble (remember I said I was lazy?), the problem with that is that
sometimes
the second-level text has data passed to it that won't show by doing a
DSPMSGD
CPFnnnn.

There oughtta be a tool...  (I'm checking out one that Todd Kidwell sent.)

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------
>  Someone else mentioned running RCLSTG.
>  Would that show up in the system log if it had been run?

Perhaps I have a misconception here ... I thought RCLSTG was included in an
IPL.
I do an IPL about once a month for a number of reasons, and DSPSYSSTS
before
& after shows that we buy several percentage points of disk space in the
process, to which I attribute our humongous reports, that come & go with
regularity.

>  Too bad there isn't better filtering available on the DSPLOG command,
like
to
>  EXCLUDE certain message IDs.  Is there an API available to read through
the
>  system log, with the goal of being able to use F1 to get at second-level
>  message text?

Have you tried print wrap?  You get more info but I find regular print to
be
more readable.

Just in case you overlooked a nuance?
You do know that with DSPLOG on screen you can cursor a line & F1 more info
there.
You do know that DSPLOG can go to spool then from there to DB, such as a
source member for ease of edit chopping out the irrelevancies & searching
for
key words.
You do know that you do not have to go to the message source to get the
message then 2nd level ... you can key on command line to display the
message
file story on message of your choice & drill from there.
You do know that there is a RTV to get at the message source & 2nd level
detail, so if you had a list of errors in your DB from DSPLOG distilled
....
but I suspect what you will be finding is a small range of error messages
repeated frequently on a large number of objects.

I just don't know off hand the precise commands to do some of this because
I
am either at my home PC or at the 400 at work - not both at same time.

I suspect that someone at a PC might be able to cut & paste the message ID
from DSPLOG & put that in another session where you identifying messages
you
want the full details on.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---






+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---