Conference iosg::all-in-1_v30

1861.0. "General ALL-IN-1 V3 questions" by DUBSWS::EIJS () Thu Nov 26 1992 13:56

Hi,

I'm teaching a 'ALL-IN-1 V3.0 <everything> Update' course here in Dublin, and
there were some situations I couldn't explain directly:

1) If you run ALL-IN-1 in a cluster, you have 1-n FileCabinetServers running 
   (n the number of nodes). If a remote 'users' use the cluster alias, the 
   connections are spread over the different servers.
   Is it possible for a local user to do the same by specifying the cluster 
   alias instead of 0::?

   When I tried 'WP FC DRM IAD' with 'System = My current node', I could add 
   it to my FileCabinet. When reading it I saw '<node>::"[xxx]name"', but
   FILECAB.FULLPATH["xxx"] showed 0::"[xx]name" again. 

   I don't have a cluster here so I can't check it. Anyone an idea?

2) Creating a drawer from 'SM MFC MD C' the 'Sharing type' doesn't allow for
   'ADVANCED SHARED'. The Named Data of the Create form ';;~~PRE_PROCESSING~~;;'
   shows a "'" too much when defining the symbol #FC_DRAWER_TYPE_OPTIONS. Is 
   this known?

3) From the different documents about the FileCabinetServer I read that by
   default access of the FileCabinetServer takes 2 Links, while working with
   a DRAWER takes 3 links (or channels). 
   Are connections made associated with DECnet links? For remote 'users' it 
   I guess it will but what if a local user uses the local FileCabinetServer?
	
   The reason for asking is that during one of the sessions the students created
   a new ALL-IN-1 account, accessed it, created a Drawer, and suddenly for 
   each new account 2 DECnet links were set up. We didn't spent too much time
   on this, but because this is a stand-alone system, the DECnet links couldn't
   be explained very well.

Link   Node             PID       Process         Remote link  Remote user
--------------------------------------------------------------------------------
24695  40.865 (node)    00000530  PROGRAMMER1     24696        OBJ_73
24696  40.865 (node)    0000011B  DBES02$SRV73    24695        PROGRAMMER1


4) When the logical OAFC$SRV_OBJ is defined to a server object different than
   73=, the option 'SM MFC MP R' fails with the message:

   	Symbol 'PART$MAINT:#OAFC_PARTITION.%OPEN[#OAFC_PARTITION]' not found

   When defined to 73=, no problem. This is done from a different account 
   than MANAGER, but it is an exact copy of the MANAGER (including 
   OAFC$SYSMAN). From the trace we got:

   #OAFC_PARTITION, Value: DBES02
   #OAFC_PARTMAINT_SERVER, Value: 

   Any idea?

5) An ALL-IN-1 account is called 'PROGRAMMER9' with the same VMS account.
   When I add this user to a group as follows:

	(PROGRAMMER9)

   it is recognized as a VMS account, so ALL-IN-1 doesn't fill the 'Mail
   Address' field. I enter:

	PROGRAMMER9 @node @MRGATE

   The code goes off, uses #GS_SEL_MEMBER to check if the account is valid. At
   that time the symbol contains value "PROGRAMMER9". Then the code adds the
   account with 'GROUP ADD' using 'PROGRAMMER9' and 
   '( PROGRAMMER9 @node @MRGATE )'.

   When reading the group members, the VMS account disappeared and the ALL-IN-1
   name appeared:

	PROGRAMMER9			( PROGRAMMER9 )

   Is this me just being naive?


Thanks,

	Simon

    Hi Simon,
    
>   Is this me just being naive?
    
    What else could it be ;^)
    
    For your first question about the use of 0:: the reason for its use is
    so that there is no need for an enormous conversion job if the cluster
    name changes. So instead there is code in the FILECAB data set that
    translates 0:: to the cluster name and vice versa. If there is no
    cluster name, then node name is used instead.
    
    Question 2 - the bug in SM MFC MD C is known. Thank you for asking.
    
    Question 3 - there are some other notes about links. The "surprise" is
    usually that IAD (index of available drawers) uses a seperate
    connection.
    
    Question 4 - Didn't understand the question. Are you saying everything
    works from the Manager's account?
    
    Question 5 - On the group member file just the VMS account name is
    stored. When ALL-IN-1 wants to find the mail address for this account
    it looks up to see if there is an ALL-IN-1 account for the member. If
    there is then it decides that it knows the mail address without needing
    to look in the Mail Address field. Though you tried to fool ALL-IN-1 by
    supplying the name in brackets, ALL-IN-1 was having none of it ;^). I
    think in this case you're more right than the code - if the user has
    gone out of way to force a mail address in , then it should be used.
    
    Cheers
    
    Stuart
    
    

    
    Hi Stuart,
    
    Thanks for the answers.
    
    Re 4). No, the problem also appears when using the ALL-IN-1 MANAGER
    account. The culprit seems to be the definition (/JOB) of the logical
    OAFC$SRV_OBJ to something different than 73=.
    
    Ciao,
    
    	Simon

    
    re .0
    
>4) When the logical OAFC$SRV_OBJ is defined to a server object different than
>   73=, the option 'SM MFC MP R' fails with the message:
>
>   	Symbol 'PART$MAINT:#OAFC_PARTITION.%OPEN[#OAFC_PARTITION]' not found
>
>   When defined to 73=, no problem. This is done from a different account 
>   than MANAGER, but it is an exact copy of the MANAGER (including 
>   OAFC$SYSMAN). From the trace we got:
>
>   #OAFC_PARTITION, Value: DBES02
>   #OAFC_PARTMAINT_SERVER, Value: 
>
>   Any idea?
    
    Not really an idea, this is going to take both knowledge of the FCS 
    system managemnt interface and the UI that IOS uses on top of this.
    I don't have both.
    
    The above will make a call to OafcShowPartition, this routine takes an
    optional server to connect to. If this server is passed we try to use
    that server, if the server is not passed in, the we will check if 
    we have a connection up to the partition you are talking about, if so
    we use that connection, if not we make a connection to the partition
    you are talking to by using the oafc$srv_obj.
    
    Can anyone tell me if IOS passes in a server, or do they let us figure
    it out?
    
    --Bob