[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1474.0. "Do CO_EX Systems work?" by AIMTEC::MORABITO_P () Tue Sep 22 1992 16:59

Has anyone out there had any success bringing up a co-existent system?
My situation is this, I had a customer who installed a co-existent ALL-IN-1
3.0 system into the following environment:

	ALL-IN-1 2.4
	VMS A5.5
	Nothing integrated with ALL-IN-1

When ALL-IN-1 is started, everything goes along fine until the File Cabinet
Server tries to start.  

The customer receives the following error message:

%SUBMIT-F-OPENIN, error opening SYS$SYSDEVICE:[ALLIN1.LIB_SHARE]OAFC$SERVER.EXE
-RMS-E-FNF, file not found

The value of OA$LIB_SHARE at this point is the 2.4 directory rather than the
ALLIN1_1 3.0 directory.  The startup is looking for the OAFC$SERVER.EXE
in the 2.4 directory.  The customer tried numerous work arounds for the problem
and still was unable to get a clean startup.  Anytime you go to the subprocess,
the ALL-IN-1 2.4 logicals are defined.  We became so frustrated that we
decided to make one of our lab nodes a co-existent system.  Here is the 
environment on this system:

	ALL-IN-1 2.4
	VMS 5.5
	SFCP 1.2

We receive the following error message:

%SUBMIT-F-OPENIN, error opening SYS$SYSDEVICE:[ALLIN1.SFCP.LIB_SHARE]OAFC$SERVER
.EXE
-RMS-E-FNF, file not found

In both cases the server process does not start.  However, you can manually
start it. 

We have done this from the SYSTEM account, the ALLIN1_1 account, and
with SETOA.COM running and not running.  Everytime the same result.
When ALL-IN-1 goes to the subprocess on the 3.0 co-existent system, the 2.4 
logical values are used.  Is this normal behaviour for a co-existent system?  
Is there something that both myself and the customer have forgot to do?  The 
customer is not too happy.  In his mind he feels that there is no way a 
co-existent system between 2.4 and 3.0 of ALL-IN-1 will fly.  The way that this
works, he can't see it being of much use if you are unable to access the 3.0
system in the subprocess.

The bottom line is, what are the restrictions for running a co_existent 
systems?

Paul

T.R	Title	User	Personal Name	Date	Lines
1474.1	Well.....	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Wed Sep 23 1992 11:20`	20
	We had a field test site running a co-ex system, and it all worked fine. In fact I bumped into the customer a week or so ago, and he said they were stil using it. Obviously we tested it here too, and we got the FCS to work. Coincidentally, I had a report similar to yours about the subprocess logicals, so I went and looked at the code, and it goes to a lot of trouble to make sure the subprocess gets its process table munged just like happens to the main process when you do a SETOA. I asked for more info. about this, but haven't heard anything yet. Perhaps you could ask the customer to see what logicals are defined in the subprocess? What does the definition of the subprocess's process logical table look like: SHO LOG/FULL LNM$PROCESS/TABLE=LNM$PROCESS_DIRECTORY Graham
1474.2	Logical from subprocess for CO-EXISTENT system	AIMTEC::MORABITO_P		`Wed Sep 23 1992 17:30`	55
	Graham, I was unable to make contact with the customer, but here is some information from the co-existent system that we set up here. I also included the logicals for OA$DATA and OA$LIB as defined in the subprocess. %SETOA-I-SET, the primary system has been set $ SHO LOG/FULL LNM$PROCESS/TABLE=LNM$PROCESS_DIRECTORY "LNM$PROCESS" [super] = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY) 1 "LNM$PROCESS_TABLE" [kernel,no_alias,table] = "" [terminal] (LNM$PROCESS_DIRE CTORY) $ sh log oa$data "OA$DATA" = "OA$SITE_DATA_SHARE" (LNM$SYSTEM_TABLE) = "OA$SITE_DATA_LLV" = "OA$DATA_SHARE" = "OA$DATA_LLV" 1 "OA$SITE_DATA_SHARE" = "SYS$SYSDEVICE:[ALLIN1.SITE.DATA_SHARE]" (LNM$SYSTEM_T ABLE) 1 "OA$SITE_DATA_LLV" = "SYS$SYSDEVICE:[ALLIN1.SITE.DATA_ENGLISH]" (LNM$SYSTEM_T ABLE) 1 "OA$DATA_SHARE" = "SYS$SYSDEVICE:[ALLIN1.DATA_SHARE]" (LNM$SYSTEM_TABLE) 1 "OA$DATA_LLV" = "SYS$SYSDEVICE:[ALLIN1.DATA_ENGLISH]" (LNM$SYSTEM_TABLE) $sh log oa$lib "OA$LIB" = "OA$SITE_LIB_LLV" (LNM$SYSTEM_TABLE) = "OA$SITE_LIB_SHARE" = "OA$LIB_LLV" = "OA$LIB_SHARE" = "OAX$SFCP_LIB" 1 "OA$SITE_LIB_LLV" = "SYS$SYSDEVICE:[ALLIN1.SITE.LIB_ENGLISH]" (LNM$SYSTEM_TAB LE) 1 "OA$SITE_LIB_SHARE" = "SYS$SYSDEVICE:[ALLIN1.SITE.LIB_SHARE]" (LNM$SYSTEM_TAB LE) 1 "OA$LIB_LLV" = "SYS$SYSDEVICE:[ALLIN1.LIB_ENGLISH]" (LNM$SYSTEM_TABLE) 1 "OA$LIB_SHARE" = "SYS$SYSDEVICE:[ALLIN1.LIB_SHARE]" (LNM$SYSTEM_TABLE) 1 "OAX$SFCP_LIB" = "OAX$SFCP_SITE_LIB_LLV" (LNM$SYSTEM_TABLE) = "OAX$SFCP_SITE_LIB_SHARE" = "OAX$SFCP_LIB_LLV" = "OAX$SFCP_LIB_SHARE" 2 "OAX$SFCP_SITE_LIB_LLV" = "SYS$SYSDEVICE:[ALLIN1.SFCP.SITE.LIB_ENGLISH]" (LNM $SYSTEM_TABLE) 2 "OAX$SFCP_SITE_LIB_SHARE" = "SYS$SYSDEVICE:[ALLIN1.SFCP.SITE.LIB_SHARE]" (LNM $SYSTEM_TABLE) 2 "OAX$SFCP_LIB_LLV" = "SYS$SYSDEVICE:[ALLIN1.SFCP.LIB_ENGLISH]" (LNM$SYSTEM_TA BLE) 2 "OAX$SFCP_LIB_SHARE" = "SYS$SYSDEVICE:[ALLIN1.SFCP.LIB_SHARE]" (LNM$SYSTE Paul
1474.3	One possible solution, how many more problems?	CSCOA2::BEKELE_D	My Opinions are MINE, MINE, all MINE!	`Wed Sep 23 1992 21:57`	47
	Hi Graham, Two modifications seem to have resolved problem: 1. A1V30START.COM: $ : $ : $START_FC_SERVER: $ say " Starting the File Cabinet Server" $ @SYS$STARTUP:OAFC$SYSSTARTUP.COM $ say "" $ if a1$kipostinstall then RETURN $ say " Running ALL-IN-1 to start local File Cabinet Server Processes" $ say "" $ ALLIN1 /NOINIT /OVERRIDE GET OA$DCL = "@OA$LIB:SETOA 1" ! <<<<<<<<Add line>>>>>>>>> OA$FLO_OPEN_LIB OA$LIB:MANAGER DO OA$LIB:OAFC$SERVER_START_NODE $ RETURN $ : $ : 2. OAFC$SERVER_START_NODE.SCP ! This script will call OAFC$STARTUP for each server on a local node. ! OAFC$STARTUP will then submit a job to the proper batch queue to ! start the specified server. !- get oa$dcl = "@oa$lib:setoa 1" !<<<<<<<line added<<<<<<< FOR OAFC_SERVER_MASTER WITH .SERVER_TYPE EQS "LOCAL" AND - .SERVER_NODE EQS OA$NODE DO - GET #OAFC_SERVER_NAME = .SERVER_NAME_1\\ - DO OA$LIB:OAFC$SERVER_STARTUP .EXIT ! Since it appears that whenever a "GET OA$DCL = "foo"" is executed when ALLIN1/NOINIT then the problem may resurface and this may not be a "cure all" solution. Regards, Dan
1474.4	It seems to work for me....	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Mon Sep 28 1992 16:24`	37
	Re .2 In your output, the message: %SETOA-I-SET, the primary system has been set shows that you have just done a SETOA to the V2.4 system... I wanted you to do the $SHO LOG in the ALL-IN-1 "$" subprocess. We don't have a co-ex system set up here, but out multiple development systems use the same technology, and in those I get the following: $ SHO LOG/FULL LNM$PROCESS/TABLE=LNM$PROCESS_DIRECTORY "LNM$PROCESS" [super] = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY) = "OAER$ENGLISH_TABLE" = "OAER$SHARE_TABLE" 1 "LNM$PROCESS_TABLE" [kernel,no_alias,table] = "" [terminal] (LNM$PROCESS_DIRECTORY) Here the system has a prefix (defined in OALNM.MAR/OBJ) of "ER", but the principle is the same. On a normal (non-co-ex) system, I get: $ SHO LOG/FULL LNM$PROCESS/TABLE=LNM$PROCESS_DIRECTORY "LNM$PROCESS" [super] = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY) = "OA$ENGLISH_TABLE" 1 "LNM$PROCESS_TABLE" [kernel,no_alias,table] = "" [terminal] (LNM$PROCESS_DIRECTORY) Both as I expect, adding in the language table, and for the co-ex system the share table, into the process search order. Re .3 Yes, the fixes you have made would address the problem, I just can't see how the problem can happen! Graham