× 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.



when I tried the following:
CRTPF FILE(DUMMY/DUMMY00002) RCDLEN(32766) SIZE(147483646 1000 1000)
ALLOCATE(*YES)
File DUMMY00002 created in library DUBSYSBD01.

But got the following error:

MCH2804
Tried to go larger than storage limit for object &1.


So I made the Size parm smaller
RCDLEN(32766) SIZE(47483646 1000 1000)

and it is chewing up DASD rather quickly.

Bryan


ALopez@xxxxxxxxxx said the following on 2/14/2008 8:07 AM:
Any chance that some other limit is involved? Do the user profiles have storage limits set? I'm not at all sure what happens in these cases when user limits are reached.

It well could be, but I don't know where. I was signed in as QSECOFR during the install and that profile can't be changed from MAXSTG(*NOMAX). I double checked the profiles created during the install, and both MYSQL, NOBODY and ZEND* had the same value.

There is, in the Unix world, an ULIMIT command that can control maximum file size/open files/storage size/etc. I found this command in reference to error code 0511-197 for tar in the Unix world. Running that in QSH as "ulimit -a" shows:
ulimit -a file size (kilobytes) unlimited
open files 200 core file size (kilobytes) unlimited
cpu time (seconds) unlimited
data segment size (kilobytes) unlimited
stack size (kilobytes) unlimited
storage size (kilobytes) unlimited
Changing the open files value doesn't seem to have any impact.

I thought this had been resolved in a previous append. Without examining the code of tar I cannot be sure but this smacks of a coding defect. My guess is that you have TOO MUCH free space. Why? Because tar is checking the available free-space but (probably) storing it in a too small value (e.g., short instead of int or int instead of long long) therefore overflow occurs and the resulting value indicates insufficient free-space even though that is not true.

That's my suspicion as well. Since I actually have more than a terabyte of free DASD, it looks like the install is seeing 1[084]G of free space. As tar progresses, the [084] gets reduced until there is (apparently) less than the amount of DASD needed.
You can prove this by creating dummy objects to consume lots of free space. Something like:
CRTPF DUMMY/DUMMY00001 RCDLEN(32767) SIZE(2147483647) ALLOCATE(*YES)
repeated until sufficient space is consumed.

Thanks. I did want to try that, but was thinking of restoring a bunch of items from tape to a junk library. When I try to run that I'm told that RCDLEN has a maximum size of 32766 and SIZE a max of 2147483646. The resulting file has a size in DSPOBJD of 16384. What am I missing?

This sort of rubbish happened a lot in the early days of DOS and Unix as drive sizes increased. I thought we were past that by now.

Ah, but we're porting all of the 'functionality' of Unix into OS/400. I wouldn't mind, but QSH seems to have lousy job logging.

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.