Conference iosg::all-in-1_v30

    
    Terry, 
    
    You are suppose to ask me easy questions in the morning :-)
    
    Actually you asked several good questions, i will answer them all once
    I tromp through some code to make sure I have it all correct.
    
    --Bob
    

Terry,

Here is the information you wanted, this will probably turn out more questions,
I will try to answer them before asked when I can.

First a little background.

The server config file currently is under-utilized for what it was designed to
do. Back in the old days (1-2+ years ago), the FCS had a goal of everyone 
everywhere using DNS as the naming mechanism of choice.  When this goal was
the driving force for all design issues, the server config file played a much
bigger part for the server. It held much more than it currently does (hence the
large record size). It held partition ids which were DNS CTSs of the partitions
it knew about. This meant that ANY TIME  a server accessed a remote partition
the CTS was added to the server config file. In this way the server would
"learn" about other partitions that exist over the network and subsequent
access to them would be faster than the first. There was also a large 
chunk of space added that was unused but had plans for it in the future.

A side effect of this "learning and remembering" that the server did was that
the startup of the server was dependant on the number of partitions we knew
about (not serviced, but knew about). When the server started up it would
next through the configuration file and add each partition to its parttion 
cache.  We removed this "remembering" portion to solve a startup degradation,
so now the only thing in the server config record was one record which contains
the server values needed to run.

Now on to the questions:

>Each server has it's own configuration file containing one record in the form
>
>Byte	Use							Default Value
>----	---							-------------
>0-13	Unused (set to null)
>14	0 or 1 (see below)
>15	Unused (set to null)
>16	51
>17	Unused (set to null)
>18	Distribution. 0 = Off  1 = On					   0
>19-33	Unused (set to null)
>34-37	Drawer Cache							  10
>38-41	Max Client Connects						 512
>42-45	Max # of Drawers						  50
>46-49	Session Timeout							1200
>50-53	Unused (set to null)
>54-57	Drawer Timeout							 600
>58-61	Authorization Timeout						 600
>62-63	Unused (set to null)
>64	DECnet object number
>65-525	Unused (set to spaces)
>526-1023 Unused (set to null)
>
>When a field (that has a default value listed above) is set to 0 then the 
>default value is used.

this is mostly correct, I will update and make it more clear by showing 
the real data structure that this config file record is mapped onto at
startup time, this will hopefully make it easier to understand. NOTE that
this is an FCS INTERNAL ONLY data structure and is not available to clients
so I would appreciate it if you not pass it along, it would only confuse
people and would have no usefull purpose to them. Taken from one of our 
include files:


/*  Server configuration profile data-structure. */

typedef struct srv_count_b
    {
    OafcUINT16      version;        /*  Version of configuration file */
    OafcUINT16      length;         /*  Length of the record in bytes */
    OafcUINT32      flags;          /*  Flags bitvector */
    OafcUINT32      part_known;     /*  Number of partitions known */
    OafcUINT32      part_served;    /*  Number of partitions served */
    OafcUINT32      part_cache_siz; /*  Size of the partition id cache */
    OafcUINT32      draw_cache_siz; /*  Size of the drawer cache */
    OafcUINT32      sessions_max;   /*  Number of sessions allowed */
    OafcUINT32      drawers_max;    /*  Number of concurrent drawers allowed */
    OafcUINT32      session_tmo;    /*  Timeout for sessions (secs) */
    OafcUINT32      garbage_tmo;    /*  Timeout for garbage collection (secs) */
    OafcUINT32      drawer_tmo;     /*  Timeout for drawer scavenging (secs) */
    OafcUINT32      authorization_tmo;  /*  Timeout for drawer authorization (secs) */
    OafcUINT16      static_buf_cnt; /*  Number of static OafcQDsc to allocate */
    OafcUINT8       object_number;  /*  DECnet object number */
    } SrvSysManConfig;
#define SRVSYSMANSIZE (OafcUINT32)sizeof(SrvSysManConfig)

A record in the configuration file is basically 2 parts, a CTS which currently
should be all 0's (this is also the key to the config record.) and the above
structure.

So Here is what the config record looks like (basically what you said, but
more info added):

Starting byte     length
                   bytes      field            default value
____________________________________________________________________
    0               14      partition id       0 for config record*
    14              200     server config 
                            or partition name*

so from what you put (above) we can break the server confi rec down to:

    14              2       version of server     1
                            that created file
    16              2       length of this rec    51
    18              4       flags for srv use     0
    22              4       #partitions known     unused
    26              4       #partitions served    unused at level 0
    30              4       partition cache size  10
    34              4       drawer cache size     10
    38              4       max #sessions         512
    42              4       max drawers open      50
    46              4       session timeout       1200secs
    50              4       garbage coll TMO      600secs
    54              4       drawer timeout        600secs
    58              4       authorization tmo     600secs
    62              2       Q-descriptors         10
    64              1       DECnet object #       73

* -- had multiple uses when partition ids from DNS use to be stored in the
configuration file. There is a possibility that a config file exists that
still has them in there so we need to check for them.

>When a server is created all the fields in it's configuration file are set to 
>0 except the following
>
>  - Byte 14 (set to 1)
This is the version of the server that the file is created for, should be 
V1.0

>  - Byte 16 (set to 51)
This is the length of the record

>  - DECnet object number (set to 73)
this is our "official" decnet object number.

>  - Bytes 65 to 525 (set to spaces)
unused so set to blanks

>I thought that OA$DATA:OAFC$SERVER_CONFIG.DAT was used to create the server
>config file when a server was created, 
When a new server is created a new configuration file is created from the file
OA$LIB:OAFC$SERVER_CONFIG.FDL, the file you mention is not used.

>but it's contents are different from
>the server config file immediately after creation of the server. The 
>OA$DATA:OAFC$SERVER_CONFIG.DAT file is all null except the following
>
>  - Byte 16 (set to 51)
>  - Drawer Cache (set to 10)
>  - Byte 26 (set to 10)
>  - Byte 30 (set to 10)
>  - DECnet object number (set to 73)
>  - Bytes 65 to 525 (set to spaces)

This is a default file installed by our installation and used for running 
the IVP. 

>Now to the questions ...

You mean that wasn't them :-)

>Is the OAFC$SERVER_CONFIG.DAT file used to create the server configuration
>files on creation of a server, 
Nope, OA$LIB:OAFC$SERVER_CONFIG.FDL  is used and the config record is filled
in to run with default values.

>if not what is it used for, if so why the
>differences between the content of this file and the content of the initial 
>server configuration file.

Basically its used for the IVP, it can be used for a real server.
The differences are basically due to the time in FCS history it was written,
there are no functional differences.

>What is byte 14 used for?

The version of the server the config file is created for.

>What is byte 16 used for?

Length of the config record, can't think of anyplace we actully use it.

>I also noticed that when the server attributes are edited for the first time
>all the attributes stored as 0 (use default value) are updated with their new 
>values even if these values have not changed from the default value. EXCEPT
>for the Session Timeout field which is left at 0 until it is specifically
>modified. Why this odd behaviour for Session Timeout?

all fields are updated because when the server starts up, it reads the current
record from the file and if the fields are 0, we use the default value, ie
we actually put the default value in the in memory copy of the record. When
you change any field of the config record (shown above) and we update the
config file with it, the entire record is written to the file so all fields
are updated. Perhaps not the optimal thing to do, but thats how it works.
As for the special treatment of session TMO? Good question, according to
the code there is no special treatment, I will have to test that one!

Hope this answers all your questions, but it probably gives you more to ask.

--Bob

    

Bob,

Thanks for the information, it's very useful.

I just re-tested the setting of session TMS and it definately is not changed
from 0 until the value is explicitly modified.

I expected all the fields to be updated once a change was made, if you are 
updating the file record then it costs nothing extra to update all the fields.

Terry

Bob,

You were right, now that I have had time to digest the file layout I have a few 
more questions.

1. part_cache_siz field is used to define the size of the partition cache.

I assume this is irrelevant for dist level 0 as there can be only one partition
and hence no point in having a cache. Is this correct?

For dist level 1 this presumably is valid and used. Is there a UI in ALL-IN-1
to set it (e.g. does it appear magically on the server attribute edit screen
if dist level is 1). I don't think there is a UI, but I thought I would ask to
make sure.

2. Garbage_TMO

A timeout for the garbage collection does not make sense. Is this the frequency
at which the garbage collection is run?

Again I can see no UI for changing this, is that correct?

3. Static_Buf_Cnt

I'm not sure what this is used for. The comment against it in your note does
not make it's use clear. I would guess that it determins the size of some
internal queue, maybe for incomming requests?

Again I can find no UI for changing this.

Thanks in advance for the help.

Terry

    
    re .4
    
    Terry,
    
    You are slipping, the questions are getting easier, not that I mind :-)
    
>1. part_cache_siz field is used to define the size of the partition cache.
>
>I assume this is irrelevant for dist level 0 as there can be only one partition
>and hence no point in having a cache. Is this correct?
>
>For dist level 1 this presumably is valid and used. Is there a UI in ALL-IN-1
>to set it (e.g. does it appear magically on the server attribute edit screen
>if dist level is 1). I don't think there is a UI, but I thought I would ask to
>make sure.

    I think we went through this before in another note so I will be brief.
    The part cache size is the number of buckets in the servers partition 
    cache which is a hash table.
    
    It is VERY VERY relevant in all distribution levels. Don't get confused
    by one partition vs one partition with multiple names. There are 
    2 things in the partition cache. It is a cache of all the partitions
    that the server "knows" about, including its own partition which could
    have multiple names.  At server startup, the server seeds the cache
    with the local partition (for level 0 and for level 1 with the contents
    of the partitions master file).  Now a dist level 0 partition on a
    cluster will have n+1 names where n is the number of members of the
    cluster and the +1 for the cluster alias if there is one.
    
    Every time a broker happens, the two involved servers "swap" partition
    lists and add the new partitions to the partition cache. In this way
    a server learns about other servers/partitions in the network.
    Subsequent connections to a partition that is in teh cache will be 
    faster than connections to a partition that is not in the cache.
    
    I am not sure if the manage server UI allows you to change this (I
    can't seem to get to my A1 account that I have the privs to get to this
    menu). If it does have it, note that the cache size is NOT DYNAMIC, it
    will take a server restart to get it to take effect.
    
>2. Garbage_TMO
>
>A timeout for the garbage collection does not make sense. Is this the frequency
>at which the garbage collection is run?

    Yup, its the frequency of the GC thread being run.
    
>Again I can see no UI for changing this, is that correct?

    Same as above, can't check at this moment.
    
>3. Static_Buf_Cnt
>
>I'm not sure what this is used for. The comment against it in your note does
>not make it's use clear. I would guess that it determins the size of some
>internal queue, maybe for incomming requests?
>
>Again I can find no UI for changing this.

    This is not changeable. Except by us. It is used to transfer network
    buffers from AST level to user level for processing. I wouldn't even 
    mention it to a customer.

Bob,

Thanks for the information, I will try to make the next question more difficult
;^}

There is no UI on the Manage Servers ALL-IN-1 menu to change the partition cache
or garbage collection TMO, I just wanted to check that there was not some other
way of updating these attributes via ALL-IN-1.

Terry

    
    I am no expert on what the ALL-IN-1 UI provided, I know there are some
    things that were not provided. Perhaps a more UI knowledgable person
    can answer that one.
    
    --Bob
    

Bob,

When I updated my course notes to add in your info on Garbage_TMO it looked
supprisingly like the description of Drawer_TMO.

Thinking about it some more I could not see a significant difference between 
the two, except that Drawer_TMO has an ALL-IN-1 UI and Garbage_TMO does not.

What is the difference between these two server attributes?

Thanks,

Terry

    
    Well, ya they are really the same thing. We had dreamed of having a 
    real garbage collection mechanism that one of the things it did was
    periodically reclaim memory from several places. We decided not
    to do this, but couldn't remove the tag. They are equivalent
    functionally. I would say use the drawer TMO as the name is more
    intuitive.
    
    --Bob