[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

1835.0. "Drawer and help problems after install" by KERNEL::OTHENJ () Mon Nov 23 1992 11:03

Hello,

	ALL-IN-1 v3.0

	Could someone who has just done an installation/ been in a similar 
scenario please check these few points for me? The customer did have a 
co-existant system, but deleted this before the upgrade.

1) The customer upgraded from 2.4 to 3.0. The installation returned no 
errors, but the customer found that all users had access, via IAD, to a 
folder called [DECPAGE]MAIN. They could read and write to this folder. The 
customer wondered if this was a bug in the upgrade for accounts that have a 
dir spec, but no owner, or what could have gone wrong to cause this. The 
customer has DECpage installed on their system. By deleting and recreating 
the folder, the access is now denied. Has anyone seen this before?

2) Help modules on co-ex system were modifiable=Y (e.g. MAIN) so he could 
customise them. When they moved over to their upgraded system, modifiable=N 
on the help forms so he had to change this flag to modifiable=Y before they 
could receive their customisations. I have looked on our two v3.0 systems, 
and it does appear that the default flags between an upgraded version and a 
clean installation are different, but we may have changed this over time. Are 
the modifiable flags different between the two different types of installation, 
and if so why?

	Thanks,
			Julie

T.R	Title	User	Personal Name	Date	Lines
1835.1	World readable drawer	CHRLIE::HUSTON		`Mon Nov 23 1992 13:42`	26
	re .0 >1) The customer upgraded from 2.4 to 3.0. The installation returned no >errors, but the customer found that all users had access, via IAD, to a >folder called [DECPAGE]MAIN. They could read and write to this folder. The >customer wondered if this was a bug in the upgrade for accounts that have a >dir spec, but no owner, or what could have gone wrong to cause this. The >customer has DECpage installed on their system. By deleting and recreating >the folder, the access is now denied. Has anyone seen this before? I believe you are talking about a drawer, not a folder. If DECPAGE had an entry in the ALL-IN-1 profile prior to the upgrade then [DECPAGE]MAIN will exist as that profile entries main drawer. A possible explanation for everyone having access to it would be that everyone has access to the DECPAGE directories, this would have been set up by the DECPAGE installation. When you say you delete/create the drawer over again, what ALL-IN-1 account are you using to delete/create it? If it is not DECPAGE then you are doing something different than what the installation intended. --Bob
1835.2	Simple: Upgrade doesn't change them!	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Mon Nov 23 1992 13:44`	17
	I'll answer Q2 In V2.4, Help wasn't supported by CM, so all the .HLP elements were marked as non-modifiable. In V3.0, help is supported, so I made all the help elements be modifiable. On a co-ex installation, which is for all practical purposes a fresh installation, you get a new SDC elements file with all the help set to "Y", however when you do an upgrade, we don't change individual field contents of existing SDC element file records, so all the help elements, and everything else that you couldn't customise in V2.4, gets left as "N". A "simple" loop through CM$SDC should fix this up. Be careful that all the other fields, like Site Location etc., are OK though. Graham
1835.3	CM$SDC is updated, however, MODIFY not	DUBSWS::EIJS		`Wed Nov 25 1992 17:17`	46
	Well, actually the records in CM$SDC do get updated, but MODIFY only gets written when the record is new. Extract from CM_POST_CONVERT_SDC_LLV.SCP: .IF CM$SDC.%KEY[#CM_KEY] EQS "" THEN - GET #CM_NEW_ELEMENT = 1 \\\\- WRITE ADD CM$SDC ELEMENT = #CM_ELEMENT, - ELEMENT_TYPE = #CM_TYPE, - LANGUAGE = #CM_AREA, - MODIFY = .MODIFY, - MODIFIED = .MODIFIED, - MOD_TIME = .MOD_TIME, - CUSTOMISED = .CUSTOMISED, - LIVE = .LIVE, - SUBSYSTEM = .SUBSYSTEM, - DUMMY1 = .DUMMY1 \\\\- IFNOTSTATUS \\\\- GET #CM_STATUS_TMP = 0 \\- .IF CM$SDC.%KEY[#CM_KEY] NES "" THEN - WRITE CHANGE CM$SDC %KEY = #CM_KEY, - DESCRIPTION = .DESCRIPTION, - DISK_LOCATION = .DISK_LOCATION, - CUSTOM_AREA = .CUSTOM_AREA, - LIB_FLAG = .LIB_FLAG, - APPLICATION = .APPLICATION, - APPCODE = .APPCODE, - EXCEPTION = .EXCEPTION, - STORED = .STORED, - DELETED = .DELETED, - FLAGS = .FLAGS, - INFO_FLAG_V21_US = .INFO_FLAG_V21_US, - INFO_FLAG_V22_US = .INFO_FLAG_V22_US, - INFO_FLAG_V21_BEV = .INFO_FLAG_V21_BEV, - INFO_FLAG_V21_LLV = .INFO_FLAG_V21_LLV \\\\- Taking in consideration that ths MODIFY flag might be changed by someone, overwriting it during an installation might cause some confusion. Or...are we too cautious here? Ciao, Simon