backup problem - VMS

This is a discussion on backup problem - VMS ; On Oct 5, 8:30 am, jhjr4381 wrote: > On Oct 4, 3:38 pm, JF Mezei wrote: > > > > > jhjr4381 wrote: > > >> > > %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;202 > > >> > > -RMS-E-EXT, ACP file ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: backup problem

  1. Re: backup problem

    On Oct 5, 8:30 am, jhjr4381 wrote:
    > On Oct 4, 3:38 pm, JF Mezei wrote:
    >
    >
    >
    > > jhjr4381 wrote:
    > > >> > > %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;202
    > > >> > > -RMS-E-EXT, ACP file extend failed
    > > >> > > -SYSTEM-F-EXQUOTA, process quota exceeded

    >
    > > Question:

    >
    > > Do all "extend file" operations consume the same amount of quotas ?

    >
    > > Do "extend file" operations consume more reources if the disk is
    > > fragmented and each extent results in a lot of different fragments being
    > > allocated to the file ? (versus a single extent being made from
    > > consecutive blocks on disk). ?

    >
    > > Is it possible that a very large default file extent quantity might
    > > consume more quotas than a smaller one ?

    >
    > > Is it possible that after many extents, adding an extra extent might
    > > consume a lot more resources ?

    >
    > > Perhaps the original poster might wish to give some details on how big
    > > DUA510FUL.LOG;202 gets, and post a DIR/HEADER

    >
    > That's one reason why I originally asked if to extend a file you need
    > contiguous space.


    You don't need contiguous free space to avoid the creation of
    extension file headers. What you need to avoid that is to be able to
    map few enough extents for your file so that the primary file header
    doesn't fill up. While contiguous free space larger than your file
    *is* sufficient, it is *not necessary*.

    > The backup finally worked. I added some steroids to the quotas for the
    > account (system). Actually just beefed them up by 10-15% over what I
    > posted yesterday.


    I still be it was FILLM or DIOLM.

    >
    > Someone asked about CHANNELCNT - that was set to 1000.
    >
    > I also created a new batch queue (also without WSxxx quotas) as the
    > previous batch queue. Then I moved the output to a new disk that had a
    > couple of million blocks of free disk space where the old disk only
    > had about 100K free space.
    >
    > Here's an dir of the failed log file sizes:
    > DUA510FUL.LOG;202 8480 3-OCT-2007 12:18:05.95
    > DUA510FUL.LOG;201 5760 2-OCT-2007 12:06:59.65
    > DUA510FUL.LOG;200 928 1-OCT-2007 20:00:37.29
    > DUA510FUL.LOG;199 4224 29-SEP-2007 19:43:36.24
    > DUA600FUL.LOG;190 1 3-OCT-2007 14:38:23.66
    > DUA600FUL.LOG;189 896 2-OCT-2007 23:03:23.97
    > DUA600FUL.LOG;188 1 29-SEP-2007 23:04:06.9
    >
    > Here's a dir of the log files from last nights successful backup:
    >
    > DUA510FUL.LOG;1 15588 4-OCT-2007 16:11:47.05
    > DUA600FUL.LOG;1 18672 4-OCT-2007 20:47:35.6
    >
    > I'm not sure what finally did the trick, and I don't like using a
    > shotgu approach, but I'll take the results. When things settle down,
    > I'll back off the steroids on system's account and see if I can
    > trigger it to fail.
    >
    > Thanks for all your help and suggestions folks. I've had problems on
    > three system simultaneously, so it's been a blast for the laast week
    > or so!


    AEF


  2. Re: backup problem

    On Oct 5, 8:39 am, AEF wrote:
    > On Oct 5, 8:30 am, jhjr4381 wrote:
    >
    >
    >
    > > On Oct 4, 3:38 pm, JF Mezei wrote:

    >
    > > > jhjr4381 wrote:
    > > > >> > > %BACKUP-F-WRITEERR, error writing DKA100:[BACKUP]DUA510FUL.LOG;202
    > > > >> > > -RMS-E-EXT, ACP file extend failed
    > > > >> > > -SYSTEM-F-EXQUOTA, process quota exceeded

    >
    > > > Question:

    >
    > > > Do all "extend file" operations consume the same amount of quotas ?

    >
    > > > Do "extend file" operations consume more reources if the disk is
    > > > fragmented and each extent results in a lot of different fragments being
    > > > allocated to the file ? (versus a single extent being made from
    > > > consecutive blocks on disk). ?

    >
    > > > Is it possible that a very large default file extent quantity might
    > > > consume more quotas than a smaller one ?

    >
    > > > Is it possible that after many extents, adding an extra extent might
    > > > consume a lot more resources ?

    >
    > > > Perhaps the original poster might wish to give some details on how big
    > > > DUA510FUL.LOG;202 gets, and post a DIR/HEADER

    >
    > > That's one reason why I originally asked if to extend a file you need
    > > contiguous space.

    >
    > You don't need contiguous free space to avoid the creation of
    > extension file headers. What you need to avoid that is to be able to
    > map few enough extents for your file so that the primary file header
    > doesn't fill up. While contiguous free space larger than your file
    > *is* sufficient, it is *not necessary*.
    >
    > > The backup finally worked. I added some steroids to the quotas for the
    > > account (system). Actually just beefed them up by 10-15% over what I
    > > posted yesterday.

    >
    > I still be it was FILLM or DIOLM.
    >


    Uh, make that 'bet', no 'be'.

    On further reflection, maybe BYTLM as the HELP says that this affects
    file-access windows.

    AEF


  3. Re: backup problem

    I know BACKUP circa 5.mumble started to look at available quotas,
    notably the working set and tried to pre-allocate as much memory as
    possible so that it could read large chunks of files into memory and
    write to TK50s in large chunks, saving considerable time for backups
    since the TK50 had fewer start/stop cycles.

    Is it possible that in this case (this is a question), BACKUP
    pre-calculated how much it could process in memory based on a set of
    available quotas, and say, for instance, that WSEXTENT would have
    allowed for 100 files be processed at the same time, but FILLM was set
    at 75, BACKUP would then limit itself to processing only 75 files at a
    time. But in doing so, it would bring the FILLM quota down to 0, so if
    it needed an extra FILLM to extend the log file, there would be none,
    hence the error ?

    In the above theoretical example, increasing FILLM to 101 would solve
    the problem because WSEXTENT would cause BACKUP to limit itself to 100
    files. (leaving 1 FILLM free to be used). It can be argued that having
    "unbalanced" quotas was a user problem, but it can also be argued that
    BACKUP's calculation should always leave a couple of units of quota left
    for anciliary operations such as extending a log file.

    This is just uneducated speculation on my part. May not apply to people
    living in the real universe.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2