Conference iosg::all-in-1_v30

    bjarne,
    
    can you identify what PC is causing the unknown node message? that
    error is usually the VAX not knowing the PC or vice versa.
    
    most of the other memory errors could be explained away by raising the
    FCS quotas - unless they reappear that is.
    
    one other thing to check is that the FCS images in SYS$SYSTEM and
    SYS$LIBRARY are really V3.0A ones and not v3.0/v3.0-1 - do a date on
    them or an analyze and make sure they aren't in SYS$SPECIFIC.
    
    regards,
    
    Andrew.D.wicks
             

    Andrew,
    
    
    I have not managed to identify which PC is causing the "UNKNOWNNODE
    ..." message in the log file.  Any other place I could look to find
    this out?
    
    I did a <get sm$_mupa_version on the customers ALL-IN-1 system
    concluding that this is a "proper" 3.0-A system:
    
    --> ALL-IN-1 IOS Server for VMS V3.0A (MUPA) BL61A 16-Dec-1993
    
    A <get sm$_tlc_version showed:
    
    --> TeamLinks Connection Package V2.0 BL41 26-NOV-1993
    
    
    I enabled trace yesterday and after a crach or two this morning I have
    a horrendously large, NORSK1$SERVER73_TRACE.DAT, from which I have
    created a readable OAFC_TRACE.TXT output file which I will put on 
    SNORRE:: as soon as I get hold of it (being mailed at present ....).
    
    Checking OPERATOR.LOG and an output from ACC/FULL/SINC gave no
    indication of the cause of the problem.
    
    
    Also, a dir of the customers systems SYS$SYSTEM: + SYS$LIBRARY: areas show
    the following:
    
    Directory SYS$COMMON:[SYSLIB]
    
    OAFC$CLIENT_SHR.EXE;3
                            222   8-FEB-1994 17:52:32.18
    OAFC$LIBRARY.OLB;1     1090  12-MAR-1992 09:51:43.67
    OAFC$LINK.OPT;1           1  12-MAR-1992 09:51:41.27
    OAFC$MESSAGES.SDI;1
                             16  12-MAR-1992 09:52:52.95
    OAFC$MTS_PRIV_SHR.EXE;5
                             15  15-FEB-1994 17:25:09.73
    OAFC$MTS_SHR.EXE;1     2481  12-MAR-1992 09:53:06.89
    OAFCDEF.H;2              44   8-FEB-1994 17:51:57.13
    OAFCDEF.R32;1            29  12-MAR-1992 09:48:36.78
    OAFCDEF.SDL;2            53   8-FEB-1994 17:51:58.38
    OAFCEXT.H;3              94   8-FEB-1994 17:51:59.64
    OAFCEXT.R32;1            88  12-MAR-1992 09:49:17.71
    OAFCEXT.SDI;1           101  12-MAR-1992 09:49:59.86
    OAFCEXT.SDL;3            97   8-FEB-1994 17:52:00.98
    
    Total of 13 files, 4331 blocks.
    
    
    $ dir sys$system:oafc*
    
    Directory SYS$COMMON:[SYSEXE]
    
    OAFC$CONVERT_SYSTEM_FOLDERS.EXE;1
                            117   8-FEB-1994 17:52:33.74
    OAFC$CREATE_SERVER.EXE;3
                             42  26-NOV-1993 13:13:26.14
    OAFC$MTS_PRIV_SHR.EXE;4
                             15   8-DEC-1993 15:04:00.26
    OAFC$PRINT_TRACE_LOG.EXE;3
                              5   8-FEB-1994 17:52:36.24
    OAFC$SERVER.EXE;6       814  15-FEB-1994 17:25:25.43
    OAFC$SYSFOLD_SEED.EXE;3
                            139   8-FEB-1994 17:52:37.49
    
    Total of 6 files, 1132 blocks.
    
    
    
    Everything looks in perfect order to me!  I'm in the process of
    submitting an IMPT since the customer is getting rather fed up with
    this nuisance.
    
    
    Regards,
    
    
    	Bjarne                                                         
    

    Bjarne,
    
    if you only have 20 PCs you could check the server knows all of them
    and that each of them knows the server - it wouldn't take too long.
    
    there are two MTS_PRIV_SHRs one in each directory - that's not a good
    sign, get rid of the old one. I also wasn't too sure about the dates since
    they appear to predate the release of the MUP?TLC did the customer get
    a network copy. also the OAFC$CREATE_SERVER looked old. 
    
    You'll need to restart the FCS after cleaning out the old images.
    
    I'd give a good set of dates/images only our machine decided to end its
    life last night and despite no end of swearing at it refuses to boot
    this morning - the doctors and priests of Field Services have been
    summoned to pronounce on it.
    
    Regards,
    
    Andrew.D.Wicks

    Andrew,
    
    I have copied both the readable output of the  FCS TRACE file from
    yeasterday and the OAFC$SERVER.LOG file to SNORRE::
    
    Also, as suggested in .3, I have renamed the old
    OAFC$MTS_PRIV_SHR.EXE to a different name.  The server has not been
    restarted yet, but this will be done at some point during the weekend. 
    The image I renamed was located in SYS$SYSTEM, but I also checked
    memory and only the newest one (which is located on SYS$LIBRARY) was
    installed in memory so my renaming probably will have no effect.
    
    An ANAL/IMAGE  of the OAFC$CREATE_SERVER.EXE (dated 26-NOV-1993) showed
    the following:
    
    	            image name: "OAFC$CREATE_SERVER"
                    image file identification: "OAFC_TLC V3.0B"
                    link date/time: 19-NOV-1993 16:44:39.84
                    linker identification: "05-13"
     
    
    I will be away out of the office for the next two weeks, but someone
    else will be following up this case and therefore any help here is much
    appreciated!
    
    
    Thanks,
    
    	Bjarne