[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

2674.0. "ALL-IN-1 UPGRADE hints where SFCP is involved" by BACHUS::BHP144::Laroche (Veerle Laroche) Fri May 07 1993 09:21

Hello,


I'm preparing an upgrade of ALL-IN-1 V2.4 with SFCP integrated to ALL-IN-1 
V3.0-1.


I'm specially worried about the SFCP migration.  It's my first upgrade
where SFCP is involved.  

Are there things I can check before starting upgrade to avoid
surprises afterwards ?


Thanks for feedback,


Veerle Laroche.

T.R	Title	User	Personal Name	Date	Lines
2674.1	Check PROFIL.LANGUAGE for SFCP Cabinets ...	AIMTEC::VOLLER_I	Gordon (T) Gopher for President	`Fri May 07 1993 16:52`	13
	Veerle, The most common problem we've seen with upgrades from SFCP systems is that the SFCP cabinets have no LANGUAGE field in the profile. It will pay to check this before starting. Also, make sure you run the CART in advance, resolve all the issues you can prior to the upgrade and have a plan for any elements that must wait until after the upgrade. Cheers, Iain.
2674.2	Some hints!	STKOFF::MARTENSSON	LOM - Sweden	`Fri May 07 1993 17:15`	38
	Veerle, A couple of things to be careful about: Is SFCP translated? Is ALL-IN-1 an US or English version? If YES, you must look into the dataset SFC_SAC and verify if the "YES"-flag is translated or not. If the yes-flag for the access is translated to O (=Oui) you must change the if-statements in OA$LIB:SFCP_CONVERT_ACL.SCP .if .read eqs "Y" ..... then get #doc_access = "R" ... must be change to .if .read eqs "O" and #valid_user eqs "1" - then get #doc_access = "R" \\\\- If you do not change this, you will end up with a lot of ace's on files with access "none". Another good point (to charge extra for!!): Migration from SFCP to FCdrawers can ends up in very big ACL's. Before the migration, make lists of the entries in SCF_SAC with a boilerplate: ex: <&OA for sfc_sac do get oa$merge_line = .USER "{CR} !" .xxx_ACCESS> From this list try to sort out different groups, and create them. The list file from the merge can be used to create UDPs to help you enter members in the different groups. If you use this method, you must change the migration script files. Best regards LOM
2674.3	And ...	AIMTEC::WICKS_A	on the Streets of San Francisco	`Fri May 07 1993 17:39`	12
	And to add to the previous two experts: Make sure that the SFCP accounts point to valid VMS accounts on valid disks - check the profil entries in other words. Make sure that SFCP isn't customised - the migration script is only designed for out-of-the-box uncustomised SFCP. regards, Andrew.D.Wicks
2674.4	Thanks for your hints	BACHUS::BHP144::Laroche	Veerle Laroche	`Mon May 10 1993 13:42`	9
	I thank you all for the replies. I will run the cart, what I always do. And check everything you mentioned. Thanks, Veerle
2674.5	Run FCVR	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Tue May 11 1993 18:39`	4
	If you can, run FCVR (or at least the pre-check) before the migration, to make sure everything is OK. Graham