Conference iosg::all-in-1_v30

David,

This is a wild guess but the FCS seems to be looking to initialise a library
when it falls over. Are the OA$ logicals all defined in the SYSTEM table in 
EXEC mode and set to valid values. I would check OA$LIB is pointing to valid
devices first, followed by OA$DATA, OA$BLP, OA$BUILD, OA$DO and then any others
that point to devices.

Object 73 is added by the FCS as part of it's startup, it just never got that
far in your case.

Also if you look in OA$LOG:OAFC$SERVER.LOG you will see where it runs the FCS
process and then gets the PID and eventually tries to pass the name of the
configuration file to the newly created process. Does this log show any errors 
and does it get as far as passing the configuration filename to the server?

Terry

    
    As far as I can tell, all the OA$ logicals are correct.  When the
    procedure runs the FCS process, it gets the PID and tries to OPEN the
    mailbox for /READ and /WRITE.  It tries the OPEN step over and over,
    without success, until it finally gives up with a
    
     Error writing to server process mailbox - %RMS-E-FNF, file not found
    
    error.  I assume this is because the process has long since died.
    
    - David
    

    
    David,
    
    Can you put in the contents of:
    
    sys$manager:oafc$server.log
    and
    sys$manager:oafc$server_error.log
    
    To get more information you can start the server directly from your
    process. Do the following:
    
    $ srv :== $sys$system:oafc$server
    $ srv p1
    
    where p1 is the name of your server configuration file, probably 
    oa$data_share:server_config.dat.
    
    this may give more information, especially if the server has not 
    gotten far enough to initialize the oafc$server*.log files.
    
    --Bob
    

    Well, I must admit I'm a little chagrined.
    
    It turns out that some miscreant who was playing with earlier
    versions of some products left an OAFC$SERVER.EXE image from 1989(!?!)
    in SYS$SYSROOT:[SYSEXE], so it was that image that the ALL-IN-1 FCS
    startup was attempting to run, rather than the newly-created image in
    SYS$COMMON:[SYSEXE].  Deleting the older image solved the problem.
    
    - David
    

    
    	I have seen that a few times, but could never figure out what
    	the problem was (or even if it was a bug)! Thanks for the
    	solution! The mailbox naming changed between baselevels, so
    	the com file was writing to one name, the server reading from
    	another. Presumably the server's location changed at some time
    	too, from SYS$SPECIFIC to SYS$COMMON.
    
    Regards,
    Paul

    The installation of V3.0 tries to cope with the situation of you having
    installed Teamlinks and the FCS against V2.4. In that case it doesn't
    want to overwrite the FCS stuff you've got already.
    
    Unfortunately, we can't readily tell the difference between this
    correct situation and the actions of a miscreant in your case.
    
    Sorry,
    
    Graham

    I had a problem similar to this one with PBL123A, and the previous
    "SSB" version.  The server would appear to start, and the log showed
    success, but there was no server.  There was no message on the console,
    and nothing written to the OAFC$SERVER.LOG or  OAFC$SERVER_ERROR.LOG.
    When I installed the new kit, I got a message:
    
%A1-I-GENIDOK, Identifier OAFC$SYSMAN will be used from the previous installatio
n.
    
    then later:
    
    A1$POST running -- setting file protections
%UAF-E-GRANTERR, unable to grant identifier OAFC$SYSMAN to SYSTEM
-SYSTEM-F-NOSUCHID, unknown rights identifier

%A1-E-RETRY1, Please correct any reported problems before attempting
%A1-E-RETRY2, to install ALL-IN-1.


    The installation seems to have succeeded, and the IVP completed
    successfully.  I went into AUTHORIZE, and did a SHOW/ID OAFC$SYSMAN,
    and it was there.  Then I did a GRANT/ID OAFC$SYSMAN SYSTEM, and it
    failed with a message "unknown rights identifier".  It appears that
    it was the SYSTEM identifier that was unknown, since the uic of SYSTEM
    showed up as [1,4] [1,4].  I did a ADD/IDENT SYSTEM/VALUE=UIC=[1,4] and
    the GRANT command worked.
    
    I guess this is a pretty unusual situation. I have no idea what
    happened to the identifier, although I did discover when I installed
    V2.3 at a customer site, it used the rights identifier of
    SYSTEST for A1XFER_IN, then V2.4 changed that to something else,
    leaving me with no A1XFER_IN identifier, only SYSTEST.
    
    Ben

    I think one or two other things have been known to go wrong if the
    [SYSTEM] identfier doesn't exist. We did change some code that was
    setting the ownership of files in SYS$SHARE (and other system
    directories) so that it did $SET FILE /OWNER=PARENT instead of
    /OWNER=SYSTEM for just this reason.
    
    The identifier seems to be missing more often on older sites, which
    have presumably been running the same VMSsystem for a "long time"...
    
    It's worth adding this to the list of things to look out for.
    
    Graham