Conference iosg::all-in-1_v30

    
    Hilary,
    
    In order to successfuly use the Manage File Cabinet Servers subsystem
    your account must have the OAFC$SYSMAN identifier. The installation
    adds this identifier to the Manager's account, but if you are using an 
    account without this, then a running server would be shown as "Stopped"
    from the UI.
    
    When accessing the subsystem, is there a very long pause (i.e. >20
    seconds) before the server is shown as "Stopped", or is this happening
    immediately ? 
    
    Also, if the server is stopped/restarted does everything return to
    normal ?
    
    
    Thanks, I hope the OAFC$SYSMAN identifier is the cause !
    
    Kevin.
    
    

Morning Kevin, 

I'm working from the ALL-IN-1 manager account, and yes, the id OAFC$SYSMAN 
is granted.

There is a reasonable (8 seconds) pause before the server is shown as 
stopped and the message "Invalid arguments" is given, but it's immediate 
when re-accessing the menu (exit screen MS)

No, stopping/restarting doesn't help.  The server is *shown* as Stopped but 
seems to function - very strange.

Any ideas ?
Cheers
Hilary

>There is a reasonable (8 seconds) pause before the server is shown as 
>stopped and the message "Invalid arguments" is given, but it's immediate 
>when re-accessing the menu (exit screen MS)
>
>No, stopping/restarting doesn't help.  The server is *shown* as Stopped but 
>seems to function - very strange.

    	The server management UI tries to access the server and if it
    	gets an error, it shows the status as stopped. You are getting an
    	error "Invalid arguments", so it is showing the status as stopped.
    	You are sure it says "arguments" not "authentication"? That would
    	indicate the OAFC$SYSMAN problem earlier.
    
    	If it really says "arguments", have you recently installed the MUP
    	on this system? Could you have mismatched versions of things? Can
    	you think of anything "strange" at your installation that has
    	caused problems before? (eg funny usernames, interference from
    	other products, customisations etc.)
    
    Regards,
    Paul
    

    
    Hilary,
    
    As Paul asks, what version of IOS are you running ?
    
    Check SYS$SYSTEM and SYS$SHARE for OAFC* modules - make sure you have
    nothing old lying around in the root directories, there appears to be a
    mismatch somewhere along the way.
    
    Is it possible to SET HOST to the system, if so I can probably take 5
    minutes to give it a check over...
    
    Kevin.
    
    

    
    I saw this during the installation of one of the earlier versions
    of FT V3.0a, if I recall right, there was a mismatch version or 
    some such thing (Kevin, you fixed it for us).
    
    Sorry, but I don't recall exactly what it was, but it was during
    a pre-SSB version. Are you sure you are using SSB V3.0a?
    
    --Bob
    

re .3 Yes, it is "arguments" and no can't think of anything strange.

Yes, did install MUPA, and your (.6) question made me realize that I had 
copied the saveset to patch MUPA but hadn't done it, so I just have patched 
MUPA and the versions now are :

OA$VERSION
ALL-IN-1 V3.0A

SM$_MUPA_VERSION
ALL-IN-1 IOS Server for VMS V3.0A (MUPA) BL61A 16-Dec-1993

SM$_TLC_VERSION
TeamLinks Connection Package V2.0 BL41 26-NOV-1993


Restarted ALL-IN-1 and the server will not start, this time it's really 
stuck. no errors at all now.

Kevin, you may set host, call me at 821-4281 for the password.

Thanks a lot
Hilary

To close the story :

After patching MUPA the server was defined with a TCP/IP address of 8224. 
Changing that to 0 and all was OK.

Hilary

    
    
    Apologies, I was meant to put a note in similar to Hilary's a couple of
    days ago to close the subject.
    
    Well, not completely close. Somehow the TCP/IP port number for the
    default 73 server was not written as "0", but was left blank. This
    results (after some number crunching) with a TCP/IP port number of
    8224. We're still not 100% certain how this happened, but it has not
    been reported elsewhere.
    
    If anyone observes similar behaviour, and they have not been an FT site
    for MUPA/TLC, then please let me know !
    
    
    Thanks,
    Kevin.
    
                                                       

    
    Consider yourself infomred :-)
    
    After last weekends wonderfull New England weather, we had power
    outages due to the ice. Monday morning I came in to complaints
    about the FCS not talking TCP/IP on our cluster. A quick check showed
    that the server was running, but its port was 8224 in the context 
    block.  I stopped and restarted the FCS and all was well.
    
    --Bob
    

    
    Bob,
    
    OK, but did you have to explicitly edit the server config to reset the
    port to "0" - or was it a simple matter of stopping and restarting ?
    
    On Hilary's system the port number was correct in the context block,
    but doing a read showed up 8224. Also, we have worked out a way this
    could happen on sites that have upgraded from previous MUPA/TLC base
    levels, so you only half count :-)
    
    Anyone else seen similar things from a fresh MUPA/TLC ???
    
    Thanks for the complaint, now I know how you must have felt all those
    endless years...
    
    
    Kevin.
    
    

    Kev,
                                                                   
    we saw the 8224 here on a much upgraded system but wrote it off as
    just one of those things. Interestingly we hadn't even selected TCP/IP
    as an option in the install. 
    
    Regards,
    
    Andrew.D.Wicks

    
    Andrew,
    
    Yes, there was a problem during the many base levels we did for the
    TLC. At one point the TCP/IP port field was blank, which lead to the
    server trying to start as port 8224. This I can well believe, but
    Hilary's installation was a fresh, so it's all rather confusing.
    
    Kevin.
    
    

    
    >OK, but did you have to explicitly edit the server config to reset the
    >port to "0" - or was it a simple matter of stopping and restarting ?
    
    Nope, just stop/restart all was well, no edit of config file, I did
    read it though and it said the right thing.
    
    >levels, so you only half count :-)
    
    Alright, I'm moving up in the world :-)
    
    >Thanks for the complaint, now I know how you must have felt all those
    >endless years...
    
    Don't worry Kevin, you had years to torment us, we will never be
    even :-)
    
    --Bob

Hi Kevin,

	A site in the U.K just reported a similiar prob,
they get the following error on FCS start:-

%OAFC-E-INVATTR, 
 the meesgae number for OAFC is 55804554.


Another MUPA install, they do use Teamlinks.

I'm getting him to re-link the FCS ...then I find this
note...Were you able to edit the FCS config file whilst
the status was stopped? I thought it could only be edited
whilst running(until the next release :-) )

-Trev

Hi,


	The customer re-linked FCS and in fact oa$main etc.
he did fine a missing oadsl image error which has been
fixed now. Using the new images same problem. No other
errors in any oafc*.log files. He re-created the config
file from the script in oa$lib. The audit /resource info
is changing like it is working, but  the status still says
stopped (and he does have the rights id!). He will check
out if user can perform cross drawer operations etc..
	The AIDA server is installed but this state is 
off.


Any ideas??


-Trev

    
    Trevor,
    
    Some questions...
    
    Firstly, can we ensure they have the correct version of MUPA/TLC.
    What is the result from doing:
    
    <GET SM$_MUPA_VERSION
    <GET SM$_TLC_VERSION
    
    Make sure they have OA$DSL$SHR.EXE in SYS$COMMON:[SYSLIB]. If it is not
    there the server will probably link/run against DSL$SHR.EXE which is
    probably not a good thing.
    
    Are they running with TCP/IP ?  What is the port number they see in the
    context block and during a read of the server ?
    
    Were they a field test site during MUPA/TLC FT, or is this a 'virgin'
    installation from V3.0 ?
    
    
    Thanks,
    Kevin.
    
    

Hi Kevin,

	Thanks for your response - some answers:

<get sm$_mupa_version = BL61A 16-DEC-1993
<GET SM$_TLC_VERSION = BL41 26-NOV-1993
he has got oa$dsl$shr.exe in sys$common:[syslib]
No tcp/ip being used, port number is 0
however the oafc show_server #server_name #state = "port_number" returns null.
Not a field test site.
The FCS is being used o.k by users!!! it is just the status that is wrong.

	The customer tells me he is building his own kits for rolling out 
to other sites - he now thinks this maybe a problem with his kit build!!!!

I'll let you know....don't work those brain cells on this any more until
we have eliminated his kit build.

Thanks for your help so far though,

cheers,

-Trev

    Just for the record, 8224 was the object on all our systems (5) after 
    MUPA and TLC.
    Cheers 
    Hilary

    
    Trevor,
    
    This bit is real important. Although the context block shows the port
    number to be 0, what does READing the server information show up ? 
    I just want to make sure this is not something similar to what Hilary
    saw. Having said that it is different anyway befcause your servers
    appear to be up and running ok...
    
    Thanks, let us know if you need anymore help,
    Kevin.
    
    

Hi Kevin,

	Here's the scoop so far....

When he goes onto the MS menu the error
%OAFC-E-INVARG,  appears, this shows up when executing the show_server function
to get the port_number.

When he Edits the config file the error
%OAFC-E-TLVBADSTREAM, appears

When he Reads the port_number is zero, as is the context block.

The context block status is still saying stopped but the server is being used and
seems o.k other than the above!!! 

Is there a way to write directly the port_number ?

Since he re-built his kit the WORM error has now gone completely!!

Help still required...


Cheers


-Trev

Hi,


	Just to let you know - This problem has now been solved. The customer
had an old options file that he used and it linked against the dsl$shr.exe
instead of the new oa$dsl$shr image.  He also had another old com file used
in the link. When using the latest and greatest - no problems no errors.


Thanks for all suggestions etc..

-Trev

    
    Trev,
    
    The TLV error suggests something along those lines was happening. My
    response was going to be "Well it looks like you have the wrong
    versions of something" :-)
    
    Anyway, glad normality has been returned...
    
    Kevin.