[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

1049.0. "moving loacation of APPLICATION AREA problem" by KAOFS::D_STREET () Tue Jul 14 1992 22:13

    Hello,
     I have a customer running ALL-IN-1 V3.0, and they have a question
    about the behavior of CSZ MA. They created an area with the C option,
    then did CA to "Create Application Area". Then they decided to change
    the location via the "E" option. Which they used to change the
    directory specification. Now when they enter EA, the OLD values are
    displayed. I looked into it, and think the EA gets its values from
    CM$APP.ROOTCODE["appnam"] and CM$APP.SITEROOTCODE["appname"]. If 
    I do a <GET CM$APP.ROOTCODE["appnam"] or a 
    <GET CM$APP.SITEROOTCODE["appname"] from the MA menu it has the right
    value, but in the EA form, it always displays the original value. 
    
    Two questions:
    
    	1. What is the proper way to change the directory location?
    
    	2. Why do I get different values inside and outside the EA form?
    
    					    Derek Street

T.R	Title	User	Personal Name	Date	Lines
1049.1	Concept 101	AIMTEC::WICKS_A	DEC Mail Works for ME sometimes	`Tue Jul 14 1992 22:31`	25
	Derek, I seet you're very confused about this! Applications deal with the CM$APP dataset - OA is an example of an application. Application Areas deal with the CM$MAF dataset - SHARE and ENGLISH are examples of application areas. when you typed E you were editing the application - you hadn't done anything to the Application Area hence why you thought you were seeing the 'old values' when you typed EA. This also explains why you think the 'new values' are in the CM$APP dataset when you do an <GET on it. Applications and Application Areas are two different things. I'll leave it to Simon for the official and recommended answer on moving either or both. Regards, Andrew.D.Wicks
1049.2	Why waiting for me while answers are correct?	CESARE::EIJS	All in 1 Piece	`Wed Jul 15 1992 10:09`	51
	Derek, You'll notice that when creating and editing the application area (EA) the fields for Rootcode and Siterootcode cannot be accessed. This is due to the current restriction that all application areas of an application need to have the same rootcode (see e.g. note 1043). Keep in mind that when editing the application area (and you would want to change the rootcode) you deal with existing directory structures which need to be moved around. Compare it with 'Transfer user'. As there isn't an option to handle changes of rootcodes properly, the following is suggested to change the directory location: 1) The right way: Delete the application area(s), change the application record (option E) and recreate the application areas. Keep in mind that when an application area still contains elements, you cannot delete it. In that case, copy the elements temporarily to another application area and delete and purge them from the application area about to be deleted. If elements have been moved to Base already, some additional processing is needed, but I don't think it is usefull to explain unless needed. 2) The 'tacky' way: Change the (Site)rootcode for the application via option E Change the (Site)rootcode for the application area via option EA, and: Get command> GET SITEROOTCODE = CM$APP.SITEROOTCODE[<key>] Get command> GET ROOTCODE = CM$APP.ROOTCODE[<key>] From DCL: Rename or backup the old directory to the new directory (don't forget all the ACL's) Decide what you want to do with the Live (and Base) locations, if they need to change also. If so then at least the records in CM$AUTH$LOCATIONS need to be edited via options CM AM MAL From the MA menu, select the application and area hjust modified, and run option DAL. This will redefine all the logicals. I would definitely recommend option 1, I added option 2 in case Andrew wants to have a go ;-);-). We are aware of the flaw in missing a rename option (at least for the Live (and Base) locations). Ciao, Simon
1049.4	Customer solution "works", but want to clean it up	KAOFS::D_STREET		`Thu Jul 16 1992 20:41`	21
	Hello, It's me again with another opertunity to display my ignorance (I am reading the manuals to try to get a better grip on this stuff) The client is working with the APPLICATION "OA", and has redefined the logicals OA$SITE_DEV_ENGLISH and OA$SITE_DEV_SHARE after ALL-IN-1 starts up to be in the same directories, but on a different disk. This allows his application to run, but they would like the entries in the APPLICATION AREA to point to the right locations. Currently they point to the place that ALL-IN-1 believes them to be at startup (ie. not the true location as defined by the new values of the logicals) Is it possible to write the new locations to the data set that the application area uses ? The 'tacky' way in the previous note says to "Change the (Site)rootcode for the application area via option EA". This is confusing as you cannot access those fields in that form. Derek Street. (PS.Please let me know if this is confusing you, and I will try to clarify)
1049.5	.2 contains the actions	CESARE::EIJS	All in 1 Piece	`Thu Jul 16 1992 23:51`	24
	Derek, Please read the lines from .2 as: >2) The 'tacky' way: > Change the (Site)rootcode for the application via option E > Change the (Site)rootcode for the application area via option EA, > and: > and from within that form... (PF1 7)... > > Get command> GET SITEROOTCODE = CM$APP.SITEROOTCODE[<key>] > Get command> GET ROOTCODE = CM$APP.ROOTCODE[<key>] HTH, Simon PS In this case, when all application area SITEROOTCODE values of one and the same application change, but in the end point to the same device and top directory, you don't have to worry about the warning which was issued at note 1043.