Re: The RCLSTG mystery... -- MIDRANGE-L

We keep a history of RCLSTG times:
Model       Date of       Disk   RCLSTG
of          Downtime      (MB)   HH:MM 
system                                 
40S-2109    1998-09-18   7,086     1:05
400-2132    1998-09-18   8,038     1:26
50S-2121    1998-09-18   8,038     1:00
9402-E04    1998-09-18   1,978       35
600-2134    1998-09-18  12,058     2:51
510-2143    1998-09-18  38,035     2:37
200-2030    1998-09-18   3,934     1:25
S20-2166    1998-09-18  45,009       37
400-2130    1998-09-18   5,099     1:23
S20-2163    1998-09-18  89,052        -
400-2132    1998-09-18  19,067     3:26
170-2160    1998-09-18  12,058     1:06
600-2134    1998-08-21  12,058     2:01
400-2132    1998-08-21   6,016     1:39
400-2132    1998-08-21   7,086     1:48
600-2136    1998-08-21  18,048     1:11
30S-2412    1998-07-24  19,806     4:48

We skip running the RCLSTG on the S20-2163 (the programmers machine).  The last 
time we ran it, it took over 10 hours.  The above contains all of our 18 
AS/400's except one in Canada.




acentea@forzani.com on 10/01/98 11:12:33 AM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Subject:        Re: The RCLSTG mystery...

<HTML>
Dan Rasch wrote:
<BLOCKQUOTE TYPE=CITE>What does RCLSTG accomplish, and is there a method
to predict it's outcome? ( ... )</BLOCKQUOTE>

<UL>RCLSTG targets the logical level, not the physical one as Microsoft
SCANDISK does on PC's. It isolates damaged and lost objects and tries to
recover them.

<P>It's a good tool since on a big system it's tricky to predict how many
damaged objects you may encounter. It should be a must for heavy journalized
systems, since many damaged objects regard the receivers.

<P>RCLSTG touches ownership and addressability too. A power failure or
an abnormal *IMMED job end can leave traces. If an *AUTL remains damaged
the real adresability of an object is affected, since a lot of information
gather to define it ( *AUTL, *USRPRF, *OBJD, ... ). The RCLSTG will do
a RCLAUTL that can enlighten or solve the bug. Not owned objects are sent
to QDFTOWN.

<P>You may have other lost objects. Make a RTVDSKINF then a PRTDSKINF.
Page 1 gives you ' OBJ NOT IN A LIBRARY ' information. Page 3 gives you
estimated space gain after RCLSTG.

<P>You have a DTAARA somewhere in QUSRSYS ( QSYS ? ) to pick up information
about your system's last RCLSTG, to estimate the time effort. IBM docs
must explain somewhere the structure of this DTAARA.

<P>Damaged objects are sent to LIB ( QRCL ). Study them, restore useful
ones and delete the others. If the size of those objects is significant,
RCLSTG can indeed improve the % of used storage. If nobody cleaned QRCL
after several RCLSTG, it's size could be increased. See in page 3 of PRTDSKINF
the actual size of your QRCL lib. Follow the rules from the books : Sys
Oper, Basic Backup &amp; Basic Security if you need recovery.

<P>Be sure to have enough auxiliary storage for swapping operations internal
to RCLSTG.

<P>Personally I use it every three months, as you also did. On all CISC
&amp; RISC machines I met it ran no more than four hours, but the system
must be restricted so it requires ... another lost week-end if you are
in charge ...</UL>

<UL>For a storage gain if you use big outputs, also consider RCLSPLSTG.
On old systems with little maintenance it will help.
<BR>&nbsp;</UL>
Andre
<BR>_________________________
<BR>acentea@forzani.com
<BR>centea@dsuper.net</HTML>

+---
| 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
+---