| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2467.3 | different bug than in 1544, I believe | GANTRY::HULL | Digital Services Delivery - Motown | Wed Mar 24 1993 20:15 | 78 |
| [I had posted this, saw Andrew's previous note (collision), deleted it, and
now its back as I think this is a different problem]
How do we fix this? I've found all the problems, but don't know what actions to
take for the correct fix (ie, do it the right way):
A TRACE reveals it to be failing in the DISKQUOTA$ check. This routine is
NOT returning a valid entry for a disk with NO quota enabled. It is
failing on an error 70 code, "Identifier is not a resource identifier".
The relevant trace output follows:
This is being run from the MANAGER acct.
![SYMBOL] Symbol: "", Value:
![SCRIPT] IF Operation starting
![SCRIPT] .IF condition #CM_VMSUSR EQS "" OR #CM_DISK EQS "" is FALSE
![SCRIPT] Null ELSE clause detected
![SCRIPT] CM_CHECKQUOTA Line 10:
![SCRIPT] CM_CHECKQUOTA Line 12: GET #CM_KOR = ":ID_ENTRY" \GET #CM_DEVICE= FIL
! E$.DEVICE[#CM_DISK]
![SYMBOL] Symbol: #CM_KOR = ":ID_ENTRY", Value: :ID_ENTRY
![SYMBOL] Symbol: #CM_DISK, Value: USER0:
![SYMBOL] Symbol: #CM_DEVICE = FILE$.DEVICE[#CM_DISK], Value: USER0:
>>>> disk is USER0: This is the correct disk.
![SCRIPT] CM_CHECKQUOTA Line 15: GET #CM_DISKQUOTA_KEY = #CM_DEVICE " " #CM_VMSU
! SR \GET #CM_DISKQUOTA_STATUS = DISKQUOTA$:ID_ENTRY.STATUS[#CM_DI
! SKQUOTA_KEY]
![SYMBOL] Symbol: #CM_DISKQUOTA_KEY = #CM_DEVICE " " #CM_VMSUSR, Value: USER0: O
! A$PRVAPP
>>>> cm_vmsusr is OA$PRVAPP (??) why not ALLIN1 ?
![SYMBOL] Symbol: #CM_DISKQUOTA_KEY, Value: USER0: OA$PRVAPP
![SYMBOL] Symbol: #CM_DISKQUOTA_STATUS = DISKQUOTA$:ID_ENTRY.STATUS[#CM_DISKQUOT
! A_KEY], Value: 70
![SCRIPT] CM_CHECKQUOTA Line 16:
![SCRIPT] CM_CHECKQUOTA Line 17: .IF #CM_DISKQUOTA_STATUS EQ 70
![SYMBOL] Symbol: #CM_DISKQUOTA_STATUS, Value: 70
![SYMBOL] Symbol: 70, Value: 70
>>>>This volume does NOT have quotas enabled. It ought to be returning error
status 52. Why is it coming back with 70?
Extract from Script CM_CHECKQUOTA.SCP:
The actual script with the (IMHO) bad logic is:
GET #CM_KOR = ":ID_ENTRY" \-
GET #CM_DEVICE = FILE$.DEVICE[#CM_DISK]
GET #CM_DISKQUOTA_KEY = #CM_DEVICE " " #CM_VMSUSR \-
GET #CM_DISKQUOTA_STATUS = -
DISKQUOTA$:ID_ENTRY.STATUS[#CM_DISKQUOTA_KEY]
![I think the 52 check (no quotas enabled) ought to go FIRST, like I've done here:]
.IF #CM_DISKQUOTA_STATUS EQ 52 THEN .GOTO CHECK_SPACE
![Then check for bad identifiers, etc]
.IF #CM_DISKQUOTA_STATUS EQ 70
.THEN
GET #CM_DISKQUOTA_STATUS = DISKQUOTA$.STATUS[#CM_DISKQUOTA_KEY]
GET #CM_KOR = ""
.END_IF
!moved above .IF #CM_DISKQUOTA_STATUS EQ 52 THEN .GOTO CHECK_SPACE
.IF #CM_DISKQUOTA_STATUS EQ 50 THEN .GOTO QUOTA_ENABLED_NO_ENTRY
.IF #CM_DISKQUOTA_STATUS NE 1 THEN .GOTO GENERAL_ERROR
Using OA$MANAPP which *IS* a resource identifier gives error code 52 back, but
the value of using OA$PRVAPP is Hard-coded in
![SCRIPT] CM_RESTORE_BACKUP_SAVESET Line 26: GET #CM_RESTORE_TARGET_BACKUP_DISK
! = FILE$.DEVICE[#CM_RESTORE_STORAGE] \GET #CM_STATUS = 0 \GET #CM
! _VMSUSR = "OA$PRVAPP"\GET #CM_MESS = "1"\GET #CM_DISK = #CM_REST
^^^^^^^^^^^^^^^^^^^^
|
| 2467.7 | Contact US Digital Solutions Library | BONNET::PAPIAT | European Assets Library-Valbonne | Mon Mar 29 1993 11:09 | 10 |
|
Ref .5
Yes ALL-IN-1 Mail Janitor Utility V3.0 is distributed
by the US Digital Solutions Library, and as such supported
by their hotline, and OEG group if necessary.
Contact HORUS::MAINTAINER or call hotline at DTN 264-8990
|
| 2467.8 | | SIOG::T_REDMOND | Thoughts of an Idle Mind | Wed Mar 31 1993 13:24 | 7 |
| Dave (.6) is correct. Beatrice (.7) is also correct. It's a CM restore
problem and MJU is supported (finally, at last, horray!) in the U.S.
Al, (going back to the original problem), did you check (as suggested
by ADW) that OA$PRVAPP is in fact defined as a resource identifier?
Thanks, Tony
|
| 2467.9 | A fix would be nice...8^) | GANTRY::HULL | Digital Services Delivery - Motown | Wed Mar 31 1993 18:30 | 24 |
| Tony -
Yes, OA$PRVAPP is a Resource identifier per normal systems. My quick "fix"
to alleviate all this bugginess was to edit the actual CM script that does
the disk space check, and just force it to always return success (1). In
my case the A1 disk has 2.6 MILLION blocks free! And quotas are NOT turned
on.
So it's a definite bug, and a real show-stopper at that.
-Al
!+
! CM_CHECKQUOTA.SCP
!+
.LABEL START
!+--------------------------
! force success in all cases for now
GET #CM_STATUS = 1
.EXIT
!+--------------------------
etc etc
|
| 2467.13 | anything new? | GIDDAY::BURT | Chele Burt - CSC Sydney, DTN 7355693 | Mon May 17 1993 03:52 | 21 |
| Hello and Greetings,
I've just had a customer report the same problem.
There was a STARS article on this very nastiness, entitled
"CM PCF Fails In V3.0 With 'Unexpected quota problem returned'
& dated Feb. 1992,
" SOLUTION:
This has been reported to Engineering.
To resolve the problem, make sure that the owner UIC of the
form library is valid in the Authorize (UAF) utility and
also has an associated rights identifier.
So SOMEONE must have known about it for a while.
Chele
|