Re: Is a 9406-525 64-bit or 32-bit?

[Bryan Dietz <bdietz400@xxxxxxxxx>]

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.