[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

1043.0. "CM SEARCH ORDER" by NEWOA::FAIRHOLM_C (Cheryl Fairholm) Tue Jul 14 1992 13:06

We have upgraded a V2.4 Base installation to V3, everything seems 
to be fine except for Customization Management.

Problem:

One can access the CM forms, but if you try any of the option 
like CO (copy from base area) or even R of a form or element you 
get an error message - 

Error opening SCRIPT file "CM_COPY_SDC"
file not found

then if you try and use <CTRL N> you get the error message 

------------------------------------- TOP ------------------------------------
------------------------------------ BOTTOM------------------------------------






Error opening MERGE file "VIEW"                                ...Press RETURN


It seems to be the search order messing up, we have tried 
changing that, for instance making the first area in the search 
to be OA$LIB_SHARE (among other things).  When you use the 
LOGCIAL function to find where it's looking it translates it 
correctly to DISK$DATA2:[ALLIN1.LIB_SHARE] which is where the 
script file is.

But the error still persists.

Can anyone shed some light please.

T.R	Title	User	Personal Name	Date	Lines
1043.1	CM problems (Moved from 1045.0 by Moderator)	CHEST::ALLIN1		`Tue Jul 14 1992 15:06`	59
	We have an identical problem to note 1043. When we do not go into CM, everything works OK. But going into CM screws up our system - scripts are not found. We are sure it is to do with the search list setting. This is our ALL-IN-1 directory structure (spread over two disks) We have identical ALLIN1 and ALLIN1_SHARE root directories on both disks - why this directory structure exists I don't know. The person who installed ALL-IN-1 V2.4 must have entered these devices and directories during V2.4 installation. But all logicals point to the correct directories and the installation succeeded. DISK$DATA1: [ALLIN1] [ALLIN1_SHARE] (accounts used by ALL-IN-1) (all the BRITISH language stuff) \| \| \| \| MGR,POSTMASTE,A1, BLP_BRITISH, LIB_BRITISH, IVPUSER,TRANSFER_ SCP_BRITISH, DO_BRITISH, INCOMING etc. SITE, etc. DISK$DATA2: [ALLIN1] [ALLIN1_SHARE] (language independent (one shared area) directory) \| \| \| \| LIB_SHARE,BLP_SHARE, SHARE1 DO_SHARE, ADMIN_DATA, SITE etc. What we have checked and tried: 1. All logicals are set up correctly before going into CM and that files like CM_*.SCP exist. 2. All logicals are CHECKED AFTER going into CM and that files like CM_SITE_SDC.SCP exist. e.g <GET OA$FILE_SEARCH_ORDER 3. Manualy setting OA$FILE_SEARCH_ORDER <GET OA$FILE_SEARCH_ORDER = "OA$LIB:", ... 4. Checked notes 246 and 430. Is different disks with the same accounts causing a problem ? If so, why ? -- Terry
1043.2	TXL search order	IOSG::BILSBOROUGH	Just testing. Please ignore!!!	`Tue Jul 14 1992 15:26`	8
	What does your TXL search order look like? Can you give me all the values of your OA$* logicals. Thanks Mike
1043.3	Checking that everything is really there	SIOG::T_REDMOND	Thoughts of an Idle Mind	`Tue Jul 14 1992 16:00`	9
	Do all the logical names specified in OA$FILE_SEARCH_ORDER actually exist? Do they all point to "real" directories? Most of the CM files are stored in OA$LIB, so it's not a TXL problem. What do the contents of your ESO (Element Search Order) file define? You'll find this in an .A1$ESO file in OAUSER. Thanks, Tony
1043.4	Maybe a ':' is missing?	CESARE::EIJS	All in 1 Piece	`Tue Jul 14 1992 16:41`	15
	And... Do the logicals defined in your search order have the famous ':' included. A reminder. If your a CM Programmer, look at CM_PROGRAMMER.A1$ESO, if a Maintainer, then at CM_APPLICATION.A1$ESO and if a Manager at CM_MANAGER.A1$ESO (all in OAUSER:). If in doubt, can you include the contents of the file as a reply? Ciao, Simon
1043.5	HERE'S THE INFO	NEWOA::FAIRHOLM_C	Cheryl Fairholm	`Tue Jul 14 1992 17:26`	41
	The cm_manager.a1$eso, seems OK, it certainly reflects the search order returned by <GET OA$FIELD_SEARCH_ORDER when in CM, and as you can see they do have the famous ':'. 1 OA$SITE_DEV_BRITISH: OA$SITE_DEV_SHARE: [] OA$SITE_LIB_LLV: OA$SITE_LIB_SHARE: OA$LIB_LLV: OA$LIB_SHARE: And here are the relevant oa$* logicals as per the search order. "OA$SITE_DEV_BRITISH" = "DISK$DATA2:[ALLIN1.SITE.DEV_BRITISH]" "OA$SITE_DEV_SHARE" = "DISK$DATA2:[ALLIN1.SITE.DEV_SHARE]" "OA$SITE_LIB_BRITISH" = "DISK$DATA1:[ALLIN1_SHARE.SITE.LIB_BRITISH]" "OA$SITE_LIB_LLV" = "DISK$DATA1:[ALLIN1_SHARE.SITE.LIB_BRITISH]" "OA$SITE_LIB_SHARE" = "DISK$DATA2:[ALLIN1.SITE.LIB_SHARE]" ""OA$LIB_LLV" = "DISK$DATA1:[ALLIN1_SHARE.LIB_BRITISH]" "OA$LIB_SHARE" = "DISK$DATA2:[ALLIN1.LIB_SHARE]" As a matter of interest, I've been into another node where everything is working fine and compared logicals etc etc.. and the only difference is that everything on the other node was on one device and [ALLIN1...]. All help greatly accepted.
1043.6	Where do the application areas point?	AIMTEC::WICKS_A	DEC Mail Works for ME sometimes	`Tue Jul 14 1992 17:44`	6
	Out of interest what are the entries for OA in CM$APP and SHARE/BRITISH in CM$MAF? Regards, Andrew.D.Wicks
1043.7	OA$SITE_DEV_BRITISH: refers to wrong directory (I think)	CESARE::EIJS	All in 1 Piece	`Tue Jul 14 1992 18:33`	106
	Cheryl, I think the directory "DISK$DATA2:[ALLIN1.SITE.DEV_BRITISH]" probably doesn't exist. I think it should be: "DISK$DATA1:[ALLIN1_SHARE.SITE.DEV_BRITISH]". This has to do with a problem described in the Release Notes (I think 1.5), dealing with SITEROOT definitions in CM$MAF which are different from actual directories created during the installation. The title of the Release Note part is not completely correct, as the problem might appear during any installation of ALL-IN-1. I'm looking for other notes in this conference which deal with the same problem, but untill then, the text below is (some kind of problem description). Ciao, Simon 1.5 After any (first time?) installation (both Primary/Secondary language). The problem described above actually refers to the following situation: - Fresh installation:, SHARE root: <device>:[ALLIN1.SITE.DEV_ENGLISH] - Fresh installation, different <language> root: <device>:[ENGLISH.SITE.DEV_ENGLISH] or <device_2>:[ALLIN1.SITE.DEV_ENGLISH] or <device_2>:[ENGLISH.SITE.DEV_ENGLISH] - Second language uses a different root: <device>:[BRITISH.SITE.DEV_BRITISH] or <device_2>:[ALLIN1.SITE.DEV_BRITISH] or <device_2>:[BRITISH.SITE.DEV_BRITISH] However, the current restriction of the Application Areas is that the SITEROOT directory must be the same for all application areas within the application (SITEROOT in example = <device>:[ALLIN1.SITE]. The SITEROOT directory is taken from the OA$SITE_LIB_SHARE: logical during the installation). This involves only the SITEROOT definition for Development (and Receive) areas. The SITEROOT definition for the Live (and Base) areas (as can be found in A1CONFIG.DAT) are not involved. If different <language> root directories have been chosen during the installation, after the installation, or after startup of ALL-IN-1 the logicals will refer to: OA$SITE_DEV_SHARE -> <device>:[ALLIN1.SITE.DEV_SHARE] OA$SITE_DEV_ENGLISH -> <device>:[ALLIN1.SITE.DEV_ENGLISH] OA$SITE_DEV_REC_ENGLISH -> <device>:[ALLIN1.SITE.DEV_REC_ENGLISH] OA$SITE_DEV_BRITISH -> <device>:[ALLIN1.SITE.DEV_BRITISH] OA$SITE_DEV_REC_BRITISH -> <device>:[ALLIN1.SITE.DEV_REC_BRITISH] but the installation created different directories. The logical definitions for OA$SITE_DEV_SHARE and OA$SITE_DEV_REC_SHARE are correct. The following action is advised to be taken if the root directory of the language files or second language was different from the root directory of the SHARED files of the primary installation (BRITISH and ENGLISH are used as examples, <device>:[ALLIN1.SITE] is taken as the SITEROOT value of CM$MAF): $ Set Default <device>:[BRITISH.SITE] $ Backup/Log/Ver [.DEV_BRITISH...]. - <device>:[ALLIN1.SITE.DEV_BRITISH...]/By_Owner=Original $ Backup/Log/Ver [.DEV_REC_BRITISH...]. - <device>:[ALLIN1.SITE.DEV_REC_BRITISH...]/By_owner=Original $ Delete [.DEV_BRITISH...].;* $ Delete [.DEV_REC_BRITISH...].;* ! (1-n times) This will copy/create the Development environment for the second language to/in the right place. An optional workaround is to change the Application Area SITEROOT directory in CM. Enter ALL-IN-1 as an Application manager, and start CM. Change the value(s) of the Application area SITEROOT via (BRITISH taken as an example): <GET #A = "<device>:[<language root>.SITE]" <WRITE CHANGE CM$MAF %KEY = "OA BRITISH",SITEROOTCODE = #A <GET #A = "<device>:[<language root>]" <WRITE CHANGE CM$MAF %KEY = "OA BRITISH",ROOTCODE = #A Warning: This workaround will prevent the following CM functionality from proper functioning: SA -> Store Application RA -> Restore Application
1043.8	wrong directory seems to be the prob	NEWOA::FAIRHOLM_C	Cheryl Fairholm	`Fri Jul 17 1992 13:18`	10
	One of our team has taken your advice Simon, and it certainly appears to be the language directory problem. Testing from the ALL-IN-1 manager's account now works, but unfortunately other support problems have arisen with a higher priority, so for now ALL-IN-1 upgrade has been shelved. Sould be able to go back in ernest next week. Thank you all for your help. Cheryl