(I apologize for the long post, but I wanted to give as much information
as possible. I am also resending this as my previous post went
missing).

We have a V6R1 system, with 635GB of storage and 6GB of memory. The
server currently acts as the High-Availability (HA) server, for a
production server (still on V5R4) with 635GB of storage, and 10GB of
memory.

We noticed lately that the HA server is constantly at 93-97% full, even
though the production server is sitting at 75% full.

========================================================================
Work with System Status

11/05/03
12:49:05
% CPU used . . . . . . . : 8.0 System ASP . . . . . . . :
635.0 G
% DB capability . . . . : 1.6 % system ASP used . . . :
93.5625
Elapsed time . . . . . . : 02:19:40 Total aux stg . . . . . :
635.0 G
Jobs in system . . . . . : 4204 Current unprotect used . :
4798 M
% perm addresses . . . . : .019 Maximum unprotect . . . :
4820 M
% temp addresses . . . . : .370

========================================================================

At first, we thought the problem might be related to journals
(high-availability uses journals extensively), but when we checked the
HA server, the journals were taking up less than 1GB of disk space.
When we compared the production libraries and the IFS on the HA server,
with what is sitting on the production server, they matched. We then
thought a reclaim storage will fix this, but it did not help. The
surprise came when we ran a RTVDSKINF, and it showed the following:

========================================================================
Total disk space on system in 1,000,000
bytes . . . . . . . . . . . . . . . . : 635085
Main storage size in megabytes . . . . . : 6076
% of Size in
Description Disk 1,000,000 bytes
User libraries 16.24 103111.20
User directories 55.90 355011.75
Folders and documents .00 .16
QSYS .38 2431.72
Other IBM libraries 1.46 9268.39
Licensed Internal Code 1.14 7258.73
Temporary space .64 4054.72
Unused space 6.61 41956.68
System internal objects .06 366.03
Objects not in a library .00 .00
TOTAL 82.43 523459.38
=======================================================================

Noticed the total? It shows 82%. We though maybe something locks when
the RTVDSKINF command runs, so we ended the system, started up just
QBATCH, and ran it again. Same result.

We then used DSPOBJD and IFSTOOL QRYIFSLIB, and the results came out to
about the same. When we did the calculations here:

Total storage - 635GB
Libraries (DSPOBJD) - 115GB
IFS - 329GB
Total Left: (635 - 115 - 329) = 191GB

Storage used according to WRKSYSSTS (93%)= 594GB Storage available -
(635 - 594) = 41GB

Clearly, we are missing a lot of storage here (41GB vs 190GB)

Out of desperation, I connected to the system and mapped the root drive
onto my PC, used a desktop utility to pull the stats for me on
everything under root (including QSYS.LIB) and finally got a
breakthrough (or so I thought). It showed the storage size of QUSRBRM
to be 80GB big. We went back to the PRTDSKINF and the DSPOBJD, and both
showed QUSRBRM to be 5GB big. The desktop utility showed file QA1ALI2 in
QUSRBRM to have a member size of 75GB big, and QA1ADI2 has a member size
of 8GB. We did a DSPFD, and the result showed 4.3GB for QA1ALI2 and
400MB for QA1ADI2:

======================================================================

Member List

Source Creation Last Change
Deleted
Member Size Type Date Date Time
Records Records
QA1ALI2 4331003904 10/02/13 11/05/03 07:17:29
3927216 0
Text:

Total number of members . . . . . . . . . : 1

Total number of members not available . . : 0

Total records . . . . . . . . . . . . . . : 3927216

Total deleted records . . . . . . . . . . : 0

Total of member sizes . . . . . . . . . . : 4331003904



Source Creation Last Change
Deleted
Member Size Type Date Date Time
Records Records
QA1ADI2 400281600 10/02/13 11/05/03 07:16:29
630503 0
Text:

Total number of members . . . . . . . . . : 1

Total number of members not available . . : 0

Total records . . . . . . . . . . . . . . : 630503

Total deleted records . . . . . . . . . . : 0

Total of member sizes . . . . . . . . . . : 400281600

=====================================================================

We now thought maybe the utility that we used is not working well, so we
dived into QSH, and here was what we saw:


=====================================================================

pwd
/qsys.lib/qusrbrm.lib/qa1ali2.file
$
ls -l
total: 4.230 gigabytes
-rwx---r-x 1 QBRMS 0 75178695888 May 3 07:17 QA1ALI2.MBR
$

cd /qsys.lib/qusrbrm.lib/qa1adi2.file

$

ls -l

total: 390.924 megabytes

-rwx---r-x 1 QBRMS 0 8210410066 May 3 07:16 QA1ADI2.MBR

$


======================================================================

What is interesting is that the 'ls -l' shows "total 4.230 gigabytes"
but the actual member size shows a lot more.

We then checked the size of these files on another V6R1 and a V5R4
server, and the same pattern was there - smaller system object size, but
big IFS size.

We were not sure if the issue was related to the IFS, so we checked a
random file (the same one we used for DSPOBJD):

======================================================================
$

cd /qsys.lib/opslib.lib/dspobjha.file

$

ls -l

total: 36.976 megabytes

-rwx---rwx 1 xxxxxxxxx 0 37445290 May 2 03:08
DSPOBJHA.MBR
======================================================================

The size seemed normal with this file. We thought maybe the number of
logical files over the main file could explain the reason for the big
size, but another dead end.

======================================================================

QUSRBRM QA1ALI2 4,345,004,032
QUSRBRM QA1A0LI2 64,151,552
QUSRBRM QA1A1LI2 190,914,560
QUSRBRM QA1A2LI2 81,920
QUSRBRM QA1A3LI2 65,536

======================================================================

Some of the other things we have tried to resolve this storage issue:

a. RTVDIRINF - Could not pinpoint the storage problem. Also, sizes in
the IFS was not what we see in QSH, but it matched up with the QRYIFSLIB
tool.
b. All CUMS and group PTF's are up to date
c. System was running at Security Level 50, reduced it to 40 to see if
it made a difference during a RCLSTG - no improvement.
d. Check disk status - all disks show normal
e. Deleted all spool files, and reclaim spool storage - no improvement.
f. A large number of jobs was shown under WRKSYSSTS - We have done
WRKJOBLOG *PENDING and deleted it all. Set IPL actions to compress Job
Tables, and IPLed. No improvement in storage, but the large number of
jobs were gone now.
g. Ran STRMNTBRM, it reduced file sizes, but it did not improve overall
storage utilization.

Confused yet? I know I am. We have send all this information through
to IBM, and is still waiting on comment from them.


To sum up, here are my questions:

1. Is this storage disparity between library and IFS for QUSRBRM normal?
It seems to be the norm if I compare it to other systems. Maybe what we
are seeing in the IFS is not what it looks like. (IBM's comment on this
was "The IFS view of an object in a library (instead of an IFS
directory) is quite often "stale" because the IFS view of library
objects is not consistently updated").

2. If this is normal, where has the storage disappeared to? Why does
the PRTDSKINF not show 100%? What are we overlooking here?

Thanks.






The information contained in this email is confidential and may contain proprietary information. It is meant solely for the intended recipient. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted in reliance on this, is prohibited and may be unlawful. No liability or responsibility is accepted if information or data is, for whatever reason corrupted or does not reach its intended recipient. No warranty is given that this email is free of viruses. The views expressed in this email are, unless otherwise stated, those of the author and not those of HYPHEN Technology (Pty) Ltd or its management. HYPHEN Technology (Pty) Ltd reserves the right to monitor, intercept and block emails addressed to its users or take any other action in accordance with its email use policy.

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2019 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].