Conference iosg::all-in-1_v30

    trev,
    
    shouldn't the node names be different in the message i.e it should
    say looking for updates for NodeB on NodeA? why would NodeA update
    NodeA
    
    Yours very confused.
    
    Andrew.D.Wicks (NOT the Network Profile Developer)

What's in OA$DATA_SHARE:MNODES.DAT (MNODES entry form)?

This defines
    a) Which nodes data should be fetched from
    b) Which nodes' data should be fetched from those nodes

Maybe this info is wrong?

Scott

Hi,

	RE .1  My logs always use this format!  I know it looks odd, now you
	       point it out...but what do your logs show?

	RE  .2 Here is the contents of my MNODES.DAT file


type oa$data:mnodes.dat
NODEFFNODEFF199203030300333300000Y00000000
NODEEENODEEE199401261125500400004Y00000000
NODEDDNODEDD199312141020005200001Y00000000
NODECCNODECC199311111111111100000Y00000000
NODEBBNODEBB000000000000000000000Y00000000
NODEAANODEAA199310090010101000000Y00000000
WAYOUTWAYOUT199401251525440300044Y00000000

	Looks o.k to me!

Thanks for listening...please reply with further suggestions etc.


-Trev

OK, here's the scoop:

The log file message "Looking for updates for nodeA on nodeA" is correct.

This means that UA is looking in the NETWORK.DAT file on nodeA (the second
nodename in the message, taken from the SOURCE NODE field of an MNODES record),
and reading all records that apply to nodeA (the first nodename in the message,
taken from the OWNING NODE field of an MNODES record).

Only records in the remote NETWORK.DAT whose NODE field equals the OWNING NODE
being looked for *and* whose timstamp is more recent than the timestamp in the
MNODES record will be copied to the local node.

So it is possible that updated records in the remote NETWORK.DAT will not be
fetched if their NODE fields are not the nodename that UA is looking for.

Does that answer your questions and solve the problem?

The reason for having SOURCE NODE and OWNING NODE is to enable you to set up
your network so that some nodes can fetch NETWORK information on behalf of
others (eg te more powerful machines, or those with faster network links).  It's
all in the documentation, or I can explain it here if wanted.

Scott

Hi Scott,


<<Does that answer your questions and solve the problem?<<

No! and No!

The customers network.dat contains new updated records with the correct
node name (for retrieval etc..) and these records are not getting pulled.

Trevor Talbot																																																																																																																																					

Hi,


	Has anyone got any further ideas on what I could try out etc.. ??


-Trev

Trevor,

If you're running UA on NODEB and the MNODES entry for which no fetches are
being done is NODEA,NODEA then try this:

On node B, enter the DCL command
$ SEARCH NODEA::OA$DATA:NETWORK.DAT NODEA

and see what you get back.  If this gives some error messages, it might give a
hint why UA can't read the records.

Other things to check are that the file/record formats are the same on both
nodes, that protections allow network access, etc, etc.

Make yourself a dummy NETWORK form on node B whose .FILE directive points at
the NETWORK.DAT file on NODEA, and see if you can read records using the form.
Check that all the fields contain sensible information.

Beyond that I'd need to look at the specific systems where you're having the
problem, and I don't have time to do that at the moment.

Scott

Please bear with me I'm not a techie...

> $ SEARCH NODEA::OA$DATA:NETWORK.DAT NODEA

This works fine on both systems, however when I do it from NODEA to NODEB 
the only place it picks up the occurance of NODEB is in the Mailbox Name
ie NODEA> sea NODEB::OA$DATA:NETWORK.DAT NODEB

returns records that look like:

BLOGGSJ                       NODEA1994021509433181Joe Bloggs           
        SYSTEM MANGLER                Customer Services
      111 1234            The Customer Support Centre   Jays Close          
          Basingstoke                   Hants
              RG22 4DE  BLOGGSJ AT A1_NODEB AT NODEA                    
                                 YN

The only thing I wondered about is the logical OA$PRIMARY_NODE, I
understand this should be defined as the node where the message router
runs and the content of this logical is what is used for the NODE Field in 
the records in NETWORK.DAT.  

In our case the message router for NODEA and NODEB is on NODEA.  
Therefore when a record is added to the NETWORK.DAT file the NODE field 
always contains NODEA, no matter which system you are on.  Now if the
update addressee's is checking the NODE field to find out which records it
should update it will never pick any up from NODEB.  Is this how it works?

Was MNODE ever designed to work with remote message routers?

Don't know if this helps

Regards

Lynn
    

Lynn,

Ahhhh, remote Message Router, it all makes sense now.

The story on this is as described in one of my previous missives on NETWORK.DAT,
in a very old topic in this conference.

Basically yes there is a problem with using NETWORK.DAT with remote Message
Router as different parts of the code assume OA$PRIMARY_NODE means different
things.  This should be addressed in a PFR.

The reason the UA job isn't fetching mail addresses from NODEB is exactly as I
explained in .6: your MNODES entry tells UA to look on NODEB for records whose
NODE field is NODEB.  All your NODE fields are NODEA, hence UA doesn't find
anything.

The way it should be set up is this:

On NODEB, any records in NETWORK.DAT for users who use ALL-IN-1 on NODEB (ie
have records in NODEB's PROFILE.DAT) should have a NODE field of NODEB,
regardless of whether they're using remote Message Router.  If the Message
Router is on NODEB too, then NODEB should appear in the mail address field; if
the Message Router is on NODEA then the NODE field should still be NODEB, but
the node in the mail address should be NODEA.

There are two workarounds you can try to fix this:
1) Change all the incorrect NODE fields in NETWORK.DAT on NODEB.
2) Change your MNODES entries: on every node which has an entry with NODEB
   as the source node, change the owning node to NODEA.

Note that workaround (2) will cause problems if there are ALL-IN-1 accounts on
both nodes NODEA and NODEB with the same username.

More info available if required...

Scott