× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The data is very good - very high quality.  But, this pattern is wrong.
Disk allocations for permanent objects almost always follows the rule,
"lowest percentage used unit" so the new objects should have all gone to the
new drives.  The only exception to this rule _that I know of_ is journal
receivers at OS/400 release V4R3 and before.  This takes a while to explain
so I'll try to do it fast.  If that fails and you don't understand, I may
have to do it again.

V4R3 and before, journal receivers drives are assigned, at first V4R3 IPL,
to the 10 least busy drives on the system.  Receivers stay on those drives
until they overflow them.  I have seen the last 10 drives on the system with
5 times the IO blocks data rate and 30 percent more contents than the rest
of the drive population.  This particular system had about 205 disk arms.

I wonder if you deleted and restored a lot of libraries on the development
system.  If you deleted a lot of database objects, the QDBSRV tasks (that
maintain the SQL catalogue) had to delete a lot of table from the SQL
catalogue and record format data and all of that stuff gets journaled.  If
you added a bunch of database objects, the QDBSRV jobs insert the new stuff
into the catalogue and journal the results.  If you haven't detached the
receivers and deleted the old ones, they could take up a lot of space.

Having said all of this, do you have one drive that went from 80% to 99% or
did all the drives do this?  How many old drives are there?  How many new
drives are there?  Does the explanation above match any part of your
problem?

By the way, the journal receiver assignment rule changes in V4R4.

Now that I consider it, there are a couple of other things that I can think
of that go to the first arm - specifically load source data and main storage
dumps.

Tell me more!

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of
Contractor1@Parkdalemills.com
Sent: Thursday, September 07, 2000 10:15 AM
To: MIDRANGE-L@midrange.com
Subject: WrkSysSts



When I do a WrkSysSts and the F16 to look at the status of the DASD, How
reliable is this information?

The reason I as is that we've recently added some more disk to our
development box. A few days after the install I looked at the disk and the
old disk were at 88.8%. The new ones at 10%.  We've been moving a lot more
information to the development box now and the old disks are at 99.7+% and
the old ones are at 37%. I expected the new disks to go up, but not the old
ones. I'm wondering if I'm misinterpreting the WrkSysSts F16 display.

Patrick Conner
www.ConnecTown.com
(828) 244-0822


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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.