[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1

Title:	ALL-IN-1 (tm) Support Conference
Notice:	Please spell ALL-IN-1 correctly - all CAPITALS!
Moderator:	IOSG::PYECE

Created:	Fri Jul 01 1994
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2716
Total number of notes:	12169

2530.0. "Invalid parameters provided for CM_CHECKQUOTA.SCP" by AIMTEC::GRENIER_J (Jean Grenier) Wed Feb 19 1997 22:40

    Here is problem statement from customer, any ideas?
    *****
    I applied the three allin1 patches on 12/15/96 and now we can not
    recompile our libraries.  When we do a PCF we get a cm_checkquota error.
    I can replace the oa$main image from before we applied the patches 
    and PCF works fine.  I applied the patches to another one of our AXP 
    systems and it works fine.  Any Ideas on what is wrong?
    
    The Identifier OA$MANAPP is OK on the .FLB and in sysuaf.  I don't 
    think the problem has anything to do with compiling a library.  To 
    resolve the original problem, I did a manual OA$FBT_WRITE_LIBRARY and 
    a .FLC was created OK.  The message that appears on the screen when 
    trying to do PCF (on any library including USER.FLB) is:
    
          "Invalid parameters provided for CM_CHECKQUOTA.SCP"
    
    What seems to be happening is that the symbol #CM_VMSUSR is not
    defined.  After following the logic, I found that the line:
          "GET #CM_OWNER = FILE$.UIC[#CM_FLB]"  does not define the symbol.
    The #CM_FLB is defined OK.  I tried an interactive command from ALLIN1
    of <GET FILE$.UIC["DOCDB.DAT"] and my UIC is returned.  If I use
    "USER.FLB", nothing is returned.  With the older version of OA$MAIN, 
    I do get a value for both.  On our other Alpha system, I get values 
    for both. I've tried plugging in other filenames into the command, 
    and all but the .DAT files come up empty on the problem system.
    *****
    
    I saw an earlier note with references to an RMS patch, (alprms03_061
    /cscpat_2063) but the other system where it works has the same patches.  
    They can be compiled outside of ALL-IN-1 (allin1/noinit) with no problem; 
    its just using the PCF option they get the above error.
    
    Thanks,
    
    Jean

T.R	Title	User	Personal Name	Date	Lines
2530.1	Additional Information Gathered	AIMTEC::GRENIER_J	Jean Grenier	`Thu Feb 20 1997 00:36`	36
	Additional information from dial-in: The patches they installed were the three ECO's (EM,FCS,DSL) 1996-12-15 00:32:23.95 S031_017 EA 001 ENGLISH V3.1-1 A1EM 1996-12-15 00:22:29.31 V031_027 EA 001 ENGLISH V3.1-1 A1DSL 1996-12-15 00:03:06.82 S031_035 EA 001 ENGLISH V3.1-1 A1FCS I tried PCF with both OA$MAIN images installed and traced it, here is the section where they differ: File ALLIN1$DISK1:[ALLIN1.MGR]A1TRACE.LOG;1 192 ![SYMBOL] Symbol: #CM_OWNER = FILE$.UIC[#CM_FLB], Value: 193 ![IO] Getting next record from TXT$TXL_DO, Text starts ".IF FN$LOCA` 194 ![SCRIPT] CM_PCF Line 25: .IF FN$LOCATE(#CM_OWNER,"]") EQ 0 196 ![SYMBOL] Symbol: "]", Value: ] ****** File ALLIN1$DISK1:[ALLIN1.MGR]A1TRACE.LOG;2 197 ![SYMBOL] Symbol: #CM_OWNER = FILE$.UIC[#CM_FLB], Value: OA$MANAPP 198 ![IO] Getting next record from TXT$TXL_DO, Text starts ".IF FN$LOCA` 199 ![SCRIPT] CM_PCF Line 25: .IF FN$LOCATE(#CM_OWNER,"]") EQ 0 200 ![SYMBOL] Symbol: #CM_OWNER, Value: OA$MANAPP 201 ![SYMBOL] Symbol: "]", Value: ] I analyzed both OA$MAIN images, the one created after the patches were installed had CDA$ACCESS AND DDIF$VIEWSHR linked with it, the image prior to the patches did not. Doing a dir/size of the two resulted in: OA$MAIN.SAV_EXE;1 8567 15-DEC-1996 00:31:08.70 (with patches) OA$MAIN.EXE;4 8543 30-SEP-1995 03:46:35.58 (without patches) Clueless in Atlanta, Jean
2530.2	WAGs	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Thu Feb 20 1997 07:59`	26
	RE .0 <<<< "GET #CM_OWNER = FILE$.UIC[#CM_FLB]" does not define the symbol. What's the owner of the file (from DCL)? Perhaps it's owned by something odd that doesn't have an Identifier in SYSUAF? RE .1 <<<< I analyzed both OA$MAIN images, the one created after the patches <<<< were installed had CDA$ACCESS AND DDIF$VIEWSHR linked with it, the <<<< image prior to the patches did not. I can't see that the inclusion of CDA in the new image should make a difference, but it does indicate that something has changed on the system since the image was last linked. On my system, the SITE FLBs are owned by MANAPP, since they're the ones that a CM Application Maintainer could recompile, whilst the base FLBs are owned by [ALLIN1], since the Manager would be compiling those if ever necessary. Correspondingly, <get file$.uic['oa$lib:siteoaform.flb'] returns OA$MANAPP, whilst <get file$.uic['oa$lib:oaform.flb'] returns the UIC, so perhaps that's what the difference is?
2530.3	OA$MANAPP owns SITEOAFORM	AIMTEC::GRENIER_J	Jean Grenier	`Thu Feb 20 1997 15:06`	21
	The SITEOAFORM is owned by OA$MANAPP as shown when I did a directory: Directory ALLIN1$DISK2:[ALLIN1.SITE.LIB_ENGLISH] SITEOAFORM.BAK_FLC;1 OA$MANAPP (RWED,RWED,RE,RE) (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE) SITEOAFORM.FLB;190 OA$MANAPP (RWED,RWED,RE,RE) (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE) SITEOAFORM.FLB;189 OA$MANAPP (RWED,RWED,RE,RE) (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE) SITEOAFORM.FLB;188 OA$MANAPP (RWED,RWED,RE,RE) (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE) SITEOAFORM.FLC;1 OA$MANAPP (RWED,RWED,RE,RE) (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE) That was the first thing I checked because of past problems. Also, using the previous OA$MAIN (before patches), everything works as expected. Ideas????
2530.4	OA$BEATS_ME....	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Thu Feb 20 1997 16:26`	4
	The FILE$ code appears to simply copy the UIC from the XAB that RMS has set up, and then does an FAO using %I to decode the longword integer into a named UIC. I can't obviously see what could go wrong with that - Famous last words!!!