Conference iosg::all-in-1_v30

    
    Hong,
                                                            
    Firstly, you can only use the Manage Servers subsystem if your account
    has the identifier OAFC$SYSMAN. You will see that this identifier does
    exist for the managers account.
    
    This explains the server states :
    
    RUNNING/ENABLED - When the manager was in the subsystem
    
    STOPPED/ Invalid authentication info received by FC server
                    - When an different user was in the subsystem without
                      the OAFC$SYSMAN ID.
    
    
    Your other problems are not so obvious. The server or certain accounts
    appear to have run out of some quota - have a general check on the
    system and check nothing is getting too low.
    
    The message about the server not being licensed is strange, and I've
    heard of a similar instance recently. Has your cluster got a cluster
    alias properly defined ?
    
    Are your problems isolated to certain users, or users who are logged
    into a particular node ?
    
    I'll have a further think on this one...
    
    
    Kevin.
    
    

    
    re .0
    
    Nothing was changed in the FCS between 3.0 and 3.0-1 that should 
    effect resources of the FCS, all that was in there was bug fixes.
    There were some fixes around storing and retrieving large content
    files, but these only effected TeamLinks connections. Are all you
    uses IOS users or are there some TeamLinks users?
    
    As Kevin menioned, the only way to get invalid authenticaton from
    the system management routines is to call them without having
    the VMS rights ID OAFC$SYSMAN. The MANAGER account has it (actually
    its the ALLIN1 VMS account). If you go into the MS menu withouth this
    rights ID, the state of the server will appear as STOPPED.
    
>10-FEB-1993 17:32:15.75  Server: CNB06V::"73=" 
> Error: %OAFC-E-NODISTLICENSE, Remote Server is not licensed to export information.  
    
    Errors like this mean that someone attempted to access a file cabinet 
    object that the server on CNB06V does not think is on this node, so it
    brokered the request to another node. That other node does not have
    the DSO installed.
    
    Note we had this problem reported the other day, it seems to revolve
    around the drawer name having a '.' between the node:: and the drawer
    name.  Could this be happening to you also?
    
    --Bob
    

    
    Hong,
    
    As Bob says, the message:
    
    "The remote server is not licensed to export information"
    
    
    will occur is a user attempts an operation in a remote drawer on a
    system which does not have the A1-DIST-SHR license. However, I was
    making assumption that this wasn't the case, and that the error
    was being produced through normal local node use. I guess I was being
    sidetracked by another problem I'm working on !
    
    Can you try this. Create a drawer from a user account and then read the
    information from the Manage Drawers subsystem (SM MFC MS SEL R).
    What is the EXACT drawer string that is returned, i.e. with the syntax
    NODE::"[USER]DRAWER".
    
    Thanks,
    Kevin.
    
    
    

Bob/Kevin

>>    As Kevin menioned, the only way to get invalid authenticaton from
>>    the system management routines is to call them without having
>>    the VMS rights ID OAFC$SYSMAN. The MANAGER account has it (actually
>>    its the ALLIN1 VMS account). If you go into the MS menu withouth this
>>    rights ID, the state of the server will appear as STOPPED.

I can only pass over the customer's swearing that it happened to his ALLIN1 
account, which was naturally having OAFC$SYSMAN as permanent rights id. 

>> 10-FEB-1993 17:32:15.75  Server: CNB06V::"73=" 
>> Error: %OAFC-E-NODISTLICENSE, Remote Server is not licensed to export information.  

There's no DSO installed in this cluster.
    
>>    Note we had this problem reported the other day, it seems to revolve
>>    around the drawer name having a '.' between the node:: and the drawer
>>    name.  Could this be happening to you also?

Looked like it, e.g. CNB06V::."COURSE" and CNB06V::."[ABBOTT NEIL]MAIN"
What caused this to happen ? Was it reported in this notes file or from 
another source?

>>    Can you try this. Create a drawer from a user account and then read the
>>    information from the Manage Drawers subsystem (SM MFC MS SEL R).
>>    What is the EXACT drawer string that is returned, i.e. with the syntax
>>    NODE::"[USER]DRAWER".

As above, i.e. CNB06V::."[ABBOTT NEIL]TEST1"


>>    Nothing was changed in the FCS between 3.0 and 3.0-1 that should 
>>    effect resources of the FCS, all that was in there was bug fixes.
>>    There were some fixes around storing and retrieving large content
>>    files, but these only effected TeamLinks connections. Are all you
>>    uses IOS users or are there some TeamLinks users?

Yes, there's 10+ TeamLinks users on this cluster and it seems difficult to 
relate TL activities to server event logging, or doesn't it ?

Today, their sever log files were much cleaner than yesterday's loggings. They 
also decided to raise enqueue quota from 4000 to 5000 on each of 250-300 user 
nodes. 


I was told the only relevant customization at this site was the first user 
flag in PROFIL, which is used to restrict the number of drawers that can be 
created by a user, with the default of 1.

Thanks for further comments

Hong

    
    
    Hong,
    
>>I can only pass over the customer's swearing that it happened to his ALLIN1 
>>account, which was naturally having OAFC$SYSMAN as permanent rights id. 

    Unless somehow the rights ID was temporarily removed from the Managers
    account, I can't see how this could have happened.
    
    
>>>> Error: %OAFC-E-NODISTLICENSE, Remote Server is not licensed to export information.  

>>There's no DSO installed in this cluster.
 
    Your cluster does not need to have the DSO license in order to produce
    this error. The DSO environment only requires the remote node you are
    accessing to have the DSO license installed. Your server is producing
    this error because someone tried to perform operations in a remote
    drawer on a system which does not have the DSO license installed.
    
    
>>Looked like it, e.g. CNB06V::."COURSE" and CNB06V::."[ABBOTT NEIL]MAIN"
>>What caused this to happen ? Was it reported in this notes file or from 
>>another source?

    I have heard of another site who commented that some drawer strings
    included a ".", similar to what you are seeing. Are all the drawer
    strings including this "." or is it only happening with drawers that
    have been recently created?
    
    Also, is your customer running V3.0 or V3.0-1 ??

    
    Kevin.
    
    
                                                        

    Kevin
    
    Those "."'s seemed to exist in all drawers, incl those recently created
    TeamLinks drawers. The rest, converting from SFCP under 2.4, were IOS
    folders plus a small number of drawers created since the 3.0 upgrade.
    
    This site went to 3.0-1 last weekend, i.e. less than a week ago when
    errors on "excedded enqueue quota" were first detected in server log
    files, in addition to those on "...license to export info..". I
    suspected those testing TeamLinks accounts were having something to do
    with the latter since original IOS users were considerably restricted
    with drawer usage, e.g. only one drawer is allowable; also, FCS tasks
    are rather new to these users and thus rarely used.
    
    I was also told FCS performance was still poor, esp the end-user task
    IAD was still taking a few minutes as had experienced in 3.0. Similar
    access by the ALLIN1 account was always fast as it was done I believe 
    in a different way. Is there a genuine, reliable way of measuring the
    performance against certain criteria?
    
    Again thanks for all comments
    
    
    Hong
    

    
    Hong,
    
    On V3.0, IAD is VERY slow if the system field on the selection form is
    filled in. By default the field is blank, and it only needs to be 
    filled in when a user is looking for drawers on a remote system.
    
    However, I believe this performance hit was fixed in V3.0-1, but I
    can't be 100% sure.
    
    
    
    Kevin.
    
    

        Kevin
    
        Yes, the customer only used a local system for drawer access and
    	thus never specified anything in the system field.
    
        Any idea on the origin of the "." in the drawers name string ?
    
    	Thanks
    
    	Hong
    

    
    Hong,
    
    I'm not sure why some drawer strings have the embedded "." - but
    it is in fact legal to have this, and it shouldn't cause any
    unexpected behaviour.
    
    
    Kevin.