Conference iosg::all-in-1_v30

    
    Yukiji,
    
    The FCS requires access to the file OA$DATA_SHARE:PARTITION_MASTER.DAT.
    If it cannot open this file it will not start.
    
    If what you are saying is that you redefined OA$DATA_SHARE to point
    to a directory that actually does contain the partition_master.dat, 
    then there is no problem.
    
    I am a little weak on co-existant systems so forgive me if I overlooked
    something obvious here.
    
    The FCS requires access to OA$DATA_SHARE:PARTITION_MASTER.DAT, if it
    is not there we cannot start.
    
    --Bob
    

	Bob,
    
	Of course the PARTITION_MASTER.DAT is resided in OA$DATA_SHARE:
      which is SYS$SYSDEVICE:[ALLIN2.DATA_SHARE]. This is a secondary 
      system's OA$DATA_SHARE.

>    If what you are saying is that you redefined OA$DATA_SHARE to point
>    to a directory that actually does contain the partition_master.dat, 
>    then there is no problem.
    
	But I can't have the logical OA$DATA_SHARE always pointing to 
      the secondary system's directory, because all the data files of
      the primary system are in SYS$SYSDEVICE:[ALLIN1.DATA_SHARE].
	
	What I want to know is how I can make only the FCS look at 
      OA1$SHARE_TABLE first.

	Thanks anyway, then, Co-ex developers, what can I do ?

                            			Yukiji

    It seems to me that if A1V30START has done a SETA1, then all of the
    commands and scripts:
    
    	A1V30START.COM
    	OAFC$SYSSTARTUP.COM
    	OAFC$SERVER_START_NODE.SCP
    	OAFC$SERVER_STARTUP.SCP
    	OAFC$SERVER_STARTUP.COM
    	OAFC$STARTUP.COM
    
    that get executed on the way to starting the server should do the right
    thing, and the server detached process should be passed the address of
    the partition file correctly.
    
    The FCS image itself has been built knowing about the system prefix
    (OA1$) as you can see in:
    
    	OAFC$SERVER_LINK.COM
    
    So, unless the FCS isn't using this info to translate the logicals out
    of the right logical name table, I don't see why this doesn't work. It
    certainly worked here when we we're testing it.
    
    Graham

    
    re .3
    
    >The FCS image itself has been built knowing about the system prefix
    >(OA1$) as you can see in:
    >
    >	OAFC$SERVER_LINK.COM
    >
    >So, unless the FCS isn't using this info to translate the logicals out
    >of the right logical name table, I don't see why this doesn't work. It
    >certainly worked here when we we're testing it.
    
    I searched the entire FCS code base for OA1$, and there is nothing in
    the code about it. Though I don't claim to totally understand all the 
    logical tables for IOS, it could be possible the FCS is doing it 
    wrong. Graham, you say this was tested and worked?
    
    The FCS tries to open the file OA$DATA_SHARE:PARTITION_MASTER.DAT, it
    is not passed the location of the partition master file by anyone.
    
    --Bob
    
    

    Bob,
    
    OA$LIB:OAFC$SERVER_STARTUP.SCP pulls a configuration file address out
    of the server master file (OA$DATA:OAFC_SERVER_MASTER.DAT) and passes
    it onto OA$LIB:OAFC$SERVER_STARTUP.COM, which in turn passes it on to
    SYS$STARTUP:OAFC$STARTUP.COM, which stuffs it down a mailbox to the
    server. I don't know how this data file gets set up, perhaps it's
    populated at installation time? Even so, if it has OA$DATA_SHARE in it,
    the FCS needs to know which table to translate the logical from.
    
    In OA$BUILD:OAFC$SERVER_LINK.COM, the system prefix (normally OA$, but
    OA1$ for a co-ex system) is passed from A1LINK. The prefix is used to
    build a MACRO module that defines the symbol OA$LNM_PREFIX to be used
    inside the FCS code.
    
    What then, does the FCS do with it??  :-)
    
    It should be checking that if it's not "OA$" then logicals should be
    translated out of the 'OA$LNM_PREFIX'_SHARE_TABLE instead of /SYSTEM.
    This is especially important for the OA$SHARE* logicals, otherwise the
    wrong mail will get read!
    
    I know this has worked, but perhaps when we were testing it we
    mistakenly put a full file spec. in the configuration file and hence
    hid this problem.
    
    Graham

    
    re .5
    
    I think we are talking about two different files.
    
    .0 is having trouble opening the partition_master.dat file.
    
    >OA$LIB:OAFC$SERVER_STARTUP.SCP pulls a configuration file address out
    >of the server master file (OA$DATA:OAFC_SERVER_MASTER.DAT) and passes
    >it onto OA$LIB:OAFC$SERVER_STARTUP.COM, which in turn passes it on to
    >SYS$STARTUP:OAFC$STARTUP.COM, which stuffs it down a mailbox to the
    >server. I don't know how this data file gets set up, perhaps it's
    >populated at installation time? Even so, if it has OA$DATA_SHARE in it,
    >the FCS needs to know which table to translate the logical from.
    
    All true, this is how the FCS gets the server configuration file.
    
    >In OA$BUILD:OAFC$SERVER_LINK.COM, the system prefix (normally OA$, but
    >OA1$ for a co-ex system) is passed from A1LINK. The prefix is used to
    >build a MACRO module that defines the symbol OA$LNM_PREFIX to be used
    >inside the FCS code.
    
    Fair enough, this is one area of the FCS I know little about.
    
    
    >It should be checking that if it's not "OA$" then logicals should be
    >translated out of the 'OA$LNM_PREFIX'_SHARE_TABLE instead of /SYSTEM.
    >This is especially important for the OA$SHARE* logicals, otherwise the
    >wrong mail will get read!
    
    Unless I am misreading our RMS access code (quite possible since it
    is in BLISS), we have the partition master file hard coded 
    to open OA$DATA_SHARE:PARTITION_MASTER.DAT. I don't see any 
    consideration for OA$LNM_PREFIX in that section of the code.
    
    Could be a problem, do you have a way you can retest this?
    
    --Bob
    

	Graham, thank you for your suggestion. (and the nice week in Atlanta
      you and the others gave me)

        After I copied the file, PARTITION_MASTER.DAT into the primary
      OA$DATA_SHARE: the error messages in OAFC$SERVER.LOG changed like
      below.

      Server: EWBV79::"73="  Error: %RMS-E-FNF, file not found  Message:
      Server startup failed. Check file: oa$data_share:system_folders.dat

      Server: EWBV79::"73="  Error: %RMS-E-FNF, file not found  Message:
      CsiStart; System folders cache creation failed

	So if I want to start the server process in this method, I have to
      copy all the files it needs to start. It seems very ugly to me.

	I wonder why the server can't refer to the table, OA1$SHARE_TABLE.
      I'm at a loss...

							Yukiji

    
    re .9
    
    Yukiji,
    
    >	So if I want to start the server process in this method, I have to
    >  copy all the files it needs to start. It seems very ugly to me.

    I agree, ugly.
    
    >	I wonder why the server can't refer to the table, OA1$SHARE_TABLE.
    >  I'm at a loss...

    Simple explanation, sounds like a bug. I know that does not really
    make you feel much better, but at least now it is found. The FCS
    has it hard coded to look in OA$DATA_SHARE for several files, including
    the two you found (partition_master and system_folders). 
    
    --Bob
    
    

    
    Graham,
    
    I will list them at the end of this. 
    
    If as you and kevin say, that we should still find it since we should 
    just be using another symbol table then these shouldn't matter. 
    
    When I get a chance for further investigation i will check into if we
    have a hard coded symbol table name someplace as well.  If you guys can
    set up a co-existant system it would help. We don't have the systems
    to do it on.
    
    The files we look in OA$DATA_SHARE for are:
    
    PROFILE.DAT
    OA$SHARED_DAF_MASTER.DAT
    PARTITION.DAT
    SYSTEM_FOLDERS.DAT
    PARTITION_MASTER.DAT
    OA$SCRIPT_COMPLETION.DAT
    A1CONFIG.DAT
    
    Keep in mind that these are the default locations we look in. The way
    our RMS open routine works, you can pass in a  filename to look for, if
    you don't it uses the above names for the file you are looking for. If
    you pass in a filename it tries that one first, if that fails it then
    tries the above.
    
    Again, if as you say, this is a simple case of looking in the wrong
    logical name table, then it should be an easy fix.
    
    --Bob
    

	Bob and Graham,

	Sorry for having been bothering you, finally I've managed to find
      the cause of this problem.

	When relinking FCS, we used OAFC$SERVER_LINK.COM directly with no
      parameters, so OAFCLNM.MAR included the line where OA$LNM_PREFIX was
      defined as .ASCID /OA$/. Why we used the procedure not through A1LNKDRV
      was due to a documentation error in the Japanese manual, and partly 
      original English version document is to blame.

	Management Guide P.2-12 says 'If you are relinking after upgrading
      to a new version of VMS, copy OAFC$SERVER.EXE and OAFC$MTS_PRIV_SHR.EXE
      to SYS$COMMON:[SYSEXE] and ...', but no new FCS images are created 
      unless the symbol A1$CHANGED_VMS_VER has the value 1. So we directly
      called OAFC$SERVER_LINK.COM to produce new FCS images after CDA$ACCESS.EXE
      upgraded according to the Japanese document.

	Once we relink FCS images with the command like,
		$ @OAFC$SERVER_LINK OA$BUILD_SHARE OA1$
      the server becomes immortal :-)

					Thank you,	Yukiji