Conference iosg::all-in-1_v30

    
    
    Does the user that is doing the SM MFC MS hold the OAFC$SYSMAN rights
    ID? If not he will always be shown a status of "Stopped" for the
    FCS.
    
    If the log file says the server is there, and the process exists, then
    it probably is there. Do a $show device/files/nosys on the disk that
    holds the servers configuration file, see if the server process shows
    up as having it open (it should also have several others open
    as well like SYSUAF).
    
    What happens if someone tries to connect to the FCS that you say is
    not there, but the system says is there?
    
    -Bob
    

Hi Bob,

Thanks for the reply.

Yes, the user doing the SM MFC MS does hold the OAFC$SYSMAN identifier.

Here is the result of the $show device/files. The server process doesn't see
OAFC$SERVER_CONFIG.DAT or OAFC$SERVER_MASTER.DAT, but it does see a file
called KIRKTN$SERVER73.DAT - is this the one you mean ?

KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]KIRKTN$SERVER73.DAT;1
KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]PARTITION_MASTER.DAT;1
KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]OA$SHARED_DAF_MASTER.DAT;6
KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]OA$SCRIPT_COMPLETION.DAT;1
KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]DOCDB.DAT;94
KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]DAF.DAT;94
KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]RESERVATIONS.DAT;1

Not sure exactly how to go about "connecting to the FCS". All I have at the
moment are two seperate users who have reported a "File Cab Server is not
available" error on sending mail. I've tried, but haven't been able to 
reproduce this so far.

Cheers,

	Gil

    
    gil,
    
    It looks like the server is up...
    
>Here is the result of the $show device/files. The server process doesn't see
>OAFC$SERVER_CONFIG.DAT or OAFC$SERVER_MASTER.DAT, but it does see a file
>called KIRKTN$SERVER73.DAT - is this the one you mean ?

    Could be the config file, if you go into the MS menu and do a 
    read on the server on the node in question it will show you the
    config file, I would bet this is it.
    
    
>KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]KIRKTN$SERVER73.DAT;1
>KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]PARTITION_MASTER.DAT;1
>KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]OA$SHARED_DAF_MASTER.DAT;6
>KIRKTN$SRV73    20C01481  [ALLIN1.DATA_SHARE]OA$SCRIPT_COMPLETION.DAT;1
>KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]DOCDB.DAT;94
>KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]DAF.DAT;94
>KIRKTN$SRV73    20C01481  [SHARED_AREAS.FILMS]RESERVATIONS.DAT;1

    To me this looks like the server is up and has a drawer open, the last
    3 files are drawer related files, the rest are system files.
    It looks to me like the server is up. Does it show up in an
    mcr ncp sho know objects? (May be a object other than 73?), look for
    the process ID in the sho known obj output.
    
>Not sure exactly how to go about "connecting to the FCS". All I have at the
>moment are two seperate users who have reported a "File Cab Server is not
>available" error on sending mail. I've tried, but haven't been able to 
>reproduce this so far.
    
    Assuming you are running on ncp object 73, log in on the node in 
    questions, to be safe, do a deass oafc$srv_obj, the go into A1
    and try to create a drawer. If it works you connected. If not
    depending on the error you may not have connected.
    
    The part about mail is confusing, IOS does not use the FCS for 
    mail at all, so I don't know how you got that.
    
    --Bob
    

    
    Bob,
    
    Right enough - the config file is indeed KIRKTN$SERVER73.DAT !
    
    Doing an NCP>sh known objects showed no object 73, or any other object
    with the File Cab Server process ID associated with it.
    
    I tried creating a drawer as you suggested, and it worked as normal.
    
    I then tried to start the server again, first killing the old server
    process. Surprise surprise - it came up no problem !
    
    Object OBJ_73 appeared in NCP, and all is well. I haven't a clue why we
    had these delays, nor why we got errors on mailing, but I'm pleased
    that we're back to normal !
    
    Thansk very much for your help, and hope I haven't wasted your time,
    
    Cheers,
    
    	Gil
           

    
    re .4
    
    If you got the drawer created then the FCS was up and running just
    fine, the mail problems were a red hering, since the FCS and IOS don't
    speak during mail operations.
    
    I would guess it was some sort of glitch in NCP, the server seems to
    have been there all the time.
    
    Glad everyone is happy now.
    
    --Bob
    

    Hi,
    
    I read and checked 13 notes in here, and relevent STARS article, and I
    STILL CAN'T GET IT TO WORK!
    
    The server starts fine interactively, but as a detached process - NO
    WAY. There is no errorlog created before the job dies, so from a STARS
    article I conclude that it must die in the first lines of code. In fact
    it doesn't not even go to the mailbox stuff as the process has already
    disappeared at that point. 
    Image accounting and audit did not give a clue, and accounting says that 
    shareable images must be installed. What image must be installed that
    needs not be installed interactively? Why in the detached only and which 
    image if all other ones are fine for the interactive process.
    
    thx in advance.
    /rhr
    

    
    Hi...
    
    Sounds like this problem is caused by a logical name or protection
    problem.
    
    Firstly, check that for the OAFC$SERVER UIC the group logical name
    table doesn't have any definitions which would affect access to
    shareable images.
    
    Then I suggest that you try a $ SET UIC [OAFC$SERVER] and turn off all
    privs using $ SET PROCESS/PRIV=(NOALL,TMPMBX,NETMBX). Once you have
    done this, try running the server again or doing a $ DIRECTORY/SECURITY
    of SYS$SHARE:OAFC*.EXE.
    
    You might find that there is a logical which is pointing you to the
    wrong image or more likely that there is a version in SYS$SPECIFIC
    which is protected against access. It's bound to be some problem like
    that.
    
    Finally, you could check using INSTALL LIST/FULL on the shareable
    images which it's likely to reference (OAFC$MTS_SHR and
    OAFC$MTS_PRIV_SHR) and seen where INSTALL claims versions are
    installed. These files should generally be in SYS$COMMON:[SYSLIB].
    
    Paul.