Conference iosg::all-in-1_v30

    It sounds like your ALL-IN-1 system has not been installed with
    privileges. Use the INSTALL utility to check this. Another check would
    be to see if the user can read mail messages, which also requires the
    image to raise privileges.
    
    Cheers
    
    Stuart

    Well, I've checked all of the images, and they seem to be OK.
    
    Also looked at the ability of the user account to send mail, and they
    can't send it.
    
    When the account is given SETPRV in authorize, and they grant
    themselves priv's then they can create groups.  I know it's only a work
    around, but it doesn't solve the problem.
    
    Any additional help would be appreciated,
    
    Kevin

    Hi,
    
    I wonder if there's a diskquota problem getting in the way. The group
    member files are usually owned by VMS account ALLIN1. Can you check
    whether ALLIN1 is under or over disk quota on the disk that the group
    member files are stored in (in directory oa$group_share).
    
    Cheers
    
    Stuart

    Also check that all the OA$... logicals (and any they refer to, such as
    disknames) are defined in /EXEC mode - especially OA$LIB: ($SHOW
    LOGICAL/FULL OA$LIB etc)
    
    ALL-IN-1 gets suspicious if some of these aren't in EXEC mode, and will
    turn off its installed privs.
    
    This most often happens because the startup procedure is run by a user
    without SYSNAM priv - for some extraordinary reason, VMS doesn't report
    an error if you do a DEFINE/EXEC without privs - it just ignores the
    qualifier and defines it in supervisor mode (to be fair to VMS, HELP
    DEFINE /EXEC does, now, warn you about this)!
    
    Dave.

    Having looked at the logicals, I found that OA$SCRIPT and
    OA$SCRIPT_ENGLISH are both defined as [super].  
    
    
    Before I do anything else, I have to ask if this is something I can
    modify?  I'm in unfamiliar territory with this one!
    
    Regards,
    
    Kevin

    No, it's OK for the OA$SCRIPT* logicals to be defined [super].
    
    Well at least ours are like that, so I assume it's OK :-)
    
    The ones to worry about are OA$LIB and OA$DATA and all the bits of them
    underneath.
    
    Graham

    Well, the problem continues.
    
    Today the class was going to try and create an application area.
    
    When I, from the manager account, tried to demo this from SM-CSZ-MA-C,
    when I filled in the part about the site root directory, I received an
    error about disk quota not being enough.  I was able to fill in the
    form and go to the CA option, but after the <cr>, it blew up and again
    mentioned the disk quota problem.
    
    Any thoughts,
    
    Kevin

    If you go to DCL and type
    
    $MCR DISKQUOTA
    >USE device (where device is that indicated by logical oa$group_share)
    >SHO ALLIN1
    
    What do you get? If it's too low type
    
    >MOD ALLIN1/PERM=number
    >EXIT
    
    Cheers
    
    Stuart

    If it's affecting CM too, then you have to give quota to the ACL which
    owns the CM areas, I can't remember if that's OA$MANAPP or something
    else. DIR/OWN will tell you of course.
    
    The wide nature of this certainly makes it look like quota. Perhaps the
    disc is full, or has run out of file headers.
    
    Or perhaps it's some entirely different sort of quota, since VMS isn't
    desperately helpful with this sort of error. Look at the failing
    process form another process and see if $SHO PROC/FULL or similar gives
    you any clues.
    
    Graham

    Kevin,
    
    Is this the same system as Jeff Barton has logged a call at the CSC on?
    
    If so take a look at the script CM_INIT_APP_AREA in OA$DO and
    preferably put trace on.
    
    You'll see in the bit of code at label CHECK_QUOTA that it's searching
    for the identifiers OA$PRVAPP and OA$MANAPP having diskquota on the
    device the Application Area is to be placed.
    
    It calls CM_CHECKQUOTA to do the actual dirty work which uses the
    DISKQUOTA dataset - but I understand that you don't have diskquotas
    enabled
    
    Anyway i'm sure I trace would be invaluable...
    
    Regards,
    
    Andrew.D.Wicks

    
    Kevin,
    
    CM_CHECKQUOTA.SCP calls the DISKQUOTA$ data set. The first check it
    then makes if diskquota has been enabled. If not, it will continue and
    check the disk space left. If there's not enough disk space, it will
    display a message like:
    
    The disk space (<device>) or user diskquota (OA$MANAPP) values are too low
    
    Was this the message you got?
    
    Ciao,
    
    	Simon

    Just to let everyone know, this question has not been put to rest.
    
    I'm no longer at the facility where the problem occured, but I am
    working with the system manager (Jeff Barton), to see if we can come up
    with some type of reasoning as to why this occured.
    
    To answer Andrews question from 633.10, Yes this is the same problem.
    
    Regards,
    
    Kevin 

    
 >>  Or perhaps it's some entirely different sort of quota, since VMS isn't
 
    That is what I was wondering. I haven`t had time to work on the problem 
    since Friday. The exact error is "Unexpected Quota Problem Returned
    Please See your ALL-IN-1 System Manager." It doesn`t say Disk Quota ...
    although that was my fist thought too. 
    
     The Original problem with creating groups no longer seems to be a
    problem....ie it works now. 8^}  We are still having the problem with
    MA ...creating an application from the MA menu. 
    
     Someone mentioned putting a trace on.....how do I do that?? 
    
     Any help will be greatly appreciated. 
    
     FYI...System is VMS 5.4-2 running on a single node 6510. ALL-IN-1 was
    upgraded from a V2.4 system that seemed to be running fine. 
    
    				jeff b. 
    

    
    Jeff,
    
    You can get a trace via several ways, but the TRACEARG form (GOLD %)   
    should be the easiest one. Selecting:
    
    SCRINP, IO, INPUT, MESS, LOG and script filter (second column)
    CM_CHECKQUOTA.
    
    The procedure CM_CHECKQUOTA deals with (error) statusses 50 (no diskquota
    entry), 52 (no diskquot enabled), 1 (success) and 70 (Identifier is not
    a resoure Id).
    
    Any other error (54, 56, 58, 60, 62, 64, 66, 68, 72) refer to the
    message you got. So, the trace should show the value of symbol
    #CM_DISKQUOTA_STATUS and once we know that we might be able to tell
    more.
    
    Thanks,
    
    	Simon