| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1121.1 | Disk full? | IOSG::MAURICE | Ceci n'est pas une note | Fri Jul 24 1992 19:37 | 12 |
| Hi,
Is it possible that the disk on which the archive area is held is full?
I think that would cause the error as well.
> Good to see Stuart is still alive and well ;-)
I've been called a lot of things in my time but never that!
Cheers
Stuart
|
| 1121.2 | Disks not full & # of files ok... | DENVER::BAILEYR | OICU812! | Fri Jul 24 1992 21:06 | 6 |
| Sorry Stuart, I meant to mention that I checked for the disk(s) being full,
as well as the total number of files on each disk exceeding the maximum
number of files allowed (checked via SPM). We are well within the limits
on everything.
Thanks!
Randy
|
| 1121.3 | More possibilities | IOSG::MAURICE | Ceci n'est pas une note | Mon Jul 27 1992 10:59 | 29 |
| Hi Randy,
We're now into the land of obscure faults! (The following applies to
V2.4)
When checking for quota the system is checking whether the the ALL-IN-1
Manager has enough quota on the archive disk. It finds the Manager's
VMS account name by:
GET #OWN=PROFIL.VMSUSR[OA$_GBL_MANAGER_ACCOUNT]
If the result of this returns a non-existent VMS account name then you
would get your symptom.
The disk name being checked is found from the Open archive area by:
GET #ARCHIVE_DIR = ARCHIVE_SETS_DATA:STATUS.DIRECTORY["OPEN"]
If the result of this returns a non-existent device name then it would
be another cause.
Can users archive documents interactively. If not what error do they
get (make them press GOLD W to see them all).
Cheers
Stuart
|
| 1121.4 | Valid returns and ADN works... | DENVER::BAILEYR | OICU812! | Mon Jul 27 1992 15:47 | 17 |
| Stuart,
We see a valid VMS account returned from:
<GET #OWN=PROFIL.VMSUSR[OA$_GBL_MANAGER_ACCOUNT]
And we see a valid device returned from:
<GET #AD=ARCHIVE_SETS_DATA:STATUS.DIRECTORY["OPEN"]
Users can indeed ADN without problems and RAD, as well.
What is puzzling to me is the fact that the archiver "processes" several
accounts before encountering the diskquota problem - again on random
accounts (so far, beginning with A).
Still scratching my head...
Thanks
Randy
|
| 1121.5 | Still trying | IOSG::MAURICE | Ceci n'est pas une note | Mon Jul 27 1992 19:12 | 10 |
| More things have come to mind. First off has your customer been patched
up to date? In looking at the code I saw comments in the archive
scripts that suggest that some changes in this area were put in K603.
Also it would be worth checking whether there have been any site
customisations made to the archive scripts.
Cheers
Stuart
|
| 1121.6 | Unpatched 2.4, but modified archiver | DENVER::BAILEYR | OICU812! | Mon Jul 27 1992 20:35 | 11 |
| Stuart,
They are running an unpatched 2.4 system, but have definately customized
the archiver scripts. I'll send you mail and provide an on-line copy of
archive.com and archive_sys_user_folders.scp, if you care to look.
I do know that nothing has been modified regarding the archiver in months
and up until last week, we have had no problems.
Many thanks,
Randy
|
| 1121.7 | Found/fixed the problem! | DENVER::BAILEYR | OICU812! | Wed Aug 05 1992 16:48 | 13 |
| After Stuart pointed me in the right direction, we determined the cause. I
had set global buffers on the SYSUAF.DAT file and the node running the
archiver had a ridiculously low GBLPAGFIL SYSGEN parameter set. Thus when
the archiver tried executing CHECK_DISKQUOTA it could not properly open the
SYSUAF and returned a bad OA$STATUS, as it should have. The node running
the archvier is dedicated for batch and housekeeping jobs while the other
two nodes in the cluster are for interactive use. These other two nodes
had sufficient GBLPAGFIL and that's why the users had no problems archiving
interactively.
Getting smarter every day...
Randy (forever in Stuart's debt - AGAIN) Bailey
|