Conference iosg::all-in-1_v30

    
    Couple of questions:
    
    1) Do both clusters have DSO installed?
    2) Have FCS's been re-started since DSO installed?
    3) Are there any proxies other than those mentioned with the users in
    question?
    4) Is the FCS started on both nodes of both clusters?
    
    --Bob
    

Hi Bob,

1) Do both clusters have DSO installed?
   Yes

2) Have FCS's been re-started since DSO installed?
   Yes

3) Are there any proxies other than those mentioned with the users in question?
   No

4) Is the FCS started on both nodes of both clusters?
   Yes

Is there some DSO trouble shooting guide available

Hi,

Is DSO at all supported in a heterogeneous cluster; two system disks and one 
ALL-IN-1 disk ?

Martin

    
    I, like Kevin, can't come up with much in ways of an explanation for
    this. 
    
    one thought, is that the FCS basically uses the VMS security principles
    to detect whether you have access to a document, it has nothing to do
    with IOS itself. 
    
    Can you do the following: from the remote side, see if you have access, 
    via DECnet, to one of the documents you want to see. For instance, on
    the local side, get a documetn into the context block and do an
    <get oa$cur_docfilename, then from the remote side, from DCL, do:
    
    $ copy remote_node::file from above []
    
    See if this copies the file over, this is basically what the FCS is
    trying to see if you can do.
    
    The multiple system disks might be confusing things.
    
    --Bob
    

Hi Bob,

>>    $ copy remote_node::file from above []

    I've done this already, and wasn't a problem at all ...
    
>>    The multiple system disks might be confusing things.
    
    Coming weekend the customer will untie the heterogeneous cluster into two
    seperate clusters. I hope that will fix his problem.

Martin

    Hello all,
    
    I wonder how this configuration can work.
    
    ONE ALL-IN-1 system running one a FOUR node heterogeneous cluster
    of which two couples form TWO homogeneous sub-clusters.
    
    Manual says that a local file cab server is to be considered
    as part of a cluster. All four servers are local on all nodes.
    So what happens when you do an Index of drawers of a node that
    is not part of the sub-cluster ? I can imaging things mess up.
    
    Regards,
    
    Jan
    

Hi to all DSO experts,

The customer is really pushing me on this issue, now they want to be certain 
that untying the heterogeneous cluster will solve the problem, even Simon Eijs
is involved in trying to solve this nasty problem.

Customer has also thought about what could possibly be wrong. Here's his theory:

1. User BOSMAN2 on system APCL02 requests IAD (sytem=ADOORN, user=BOSMAN)
2. IS ADOORN$SRV73 (=AP0101$SRV73 or AP0103$SRV73) a local FCS
3. Yes, it's a local server, so look up VMSUSR (BOSMAN2) in SYSAUF on ADOORN
4. BOSMAN2 doesn't exist on ADOORN, so end of the story. Message "FileCabinet
   server not available" is kind of misleading.
5. When there's also a BOSMAN2 SYSUAF entry on ADOORN, then there are no 
   problems.

So once again the question will untie the cluster solve the problem ?

Thank you,

Martin

    
    There is no way to know for sure if untying the cluster will solve the
    problem, becuase we don't yet know what the problem is for sure. The
    multiple system disks is a high candidate, but without watching a
    debug server run so that we can see what is really happening, there
    is no way to be sure.
    
>1. User BOSMAN2 on system APCL02 requests IAD (sytem=ADOORN, user=BOSMAN)
>2. IS ADOORN$SRV73 (=AP0101$SRV73 or AP0103$SRV73) a local FCS
>3. Yes, it's a local server, so look up VMSUSR (BOSMAN2) in SYSAUF on ADOORN
>4. BOSMAN2 doesn't exist on ADOORN, so end of the story. Message "FileCabinet
>   server not available" is kind of misleading.
>5. When there's also a BOSMAN2 SYSUAF entry on ADOORN, then there are no 
>   problems.
    
    
    The biggest hole I see in this is step 3. If you are already talking
    to a server, and you then ask if that server is local, then if the
    answer is "yes", there will be no lookup to the UAF file. it will
    simply run the partition.dat looking for drawers owned by
    BOSMAN2. If it doesn't find any, it would return success, with no
    drawer information.
    
    This really looks like the FCSs are tyring to broker, to make sure, 
    try disabling the DSO license and restart the FCS, try the operation 
    again, if you get errors about the DSO not being installed then
    you are brokering and I would GUESS that untying the cluster would
    solve the problem, if you don't get dso errors, then I would GUESS that
    you are not brokering and the DSO is not the problem, but untying the
    cluster MIGHT still solve the problem.
    
    Basically, I don't know of this setup ever being tested, I know I never
    imagined it (so never tested it) while writing the DSO handling code.
    
    --Bob
    

    The SPD doesn't explicitly say we support mixed environment (aka
    heterogenous) clusters or not.
    
    The Management Guide says (paraphrasing) that we only support them as
    long as each bit of the cluster has its own SYSUAF and all its own data
    files. Also, you need to be careful how all the queues used for the
    Sender/Fetcher and starting the FCS run on the right nodes. Then you
    treat the two halves of the cluster as completely different systems.
    
    My view (guess :-) ) is that this would work if the cluster alias
    wasn't defined, and the two ALL-IN-1 systems were completely separate.
    Instead the OA$CLUSTER_NODE (name???) logical should be defined on each
    set of nodes.
    
    In any case, probably the only way to find out is to set it up on the
    customer's system and try it!
    
    Graham

Hi Graham,

What are you exactly trying to say Do you say that the mixed environment
should work or should the cluster be split up ?

Martin

Hi,

Jan Schollaert pointed me to note 402. How about that.,,,

Martin<