[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

942.0. "Upgrade Cheating" by WOTVAX::DORANA (Mr Ken Shabby) Fri Jun 26 1992 12:30

    Talking to a customer about the V3.0 upgrade.
    
    The customer has the following setup:
    
    3 ALL-IN-1 sites (ie 3 separate ALL-IN-1 clusters). Each cluster is
    more or less the same - ie The same applications, the same
    modifications to ALL-IN-1 etc.
    
    They also have a 'test bed'. Again, this is similar to the live
    ALL-IN-1 clusters.
    
    We have now upgraded ALL-IN-1 on the test bed. We are going through the
    modifications necessary on their applications/customizations in order
    to ensure everything works.
    
    The upgrade took 14 hours (it is only an 8530). The changes required to
    their code/mods will take 4-5 days minimum.
    
    They cant afford to repeat this effort on each cluster. They aim to
    only have 2 hours downtime.
    
    The only way to acheive their aim is to replace the ALL-IN-1 system
    disk on each live cluster with a backup of the ALL-IN-1 system disk
    from the development cluster.
    
    The questions are:-
    
    How to convert the profile from V2.4 to V3.0 format (is it just
    OA$CNV_CONVERT?)
    
    How to set up (seed?) the partition?
    
    Other files that are local that need converting - what are they?
    
    Any system (disk) files to take into account?
    
    Is this a bad idea - should they just upgrade the other systems?
    
    Cheers,
    
    Andy 
T.RTitleUserPersonal
Name
DateLines
942.1conversionsIOSG::TYLDESLEYFri Jun 26 1992 13:3413
    Andy,
    
    To set the ball rolling, yes, I believe the Profile could be manually
    converted with OA$CNV_CONVERT. Use OA$DATA:V24_PROFILE.DAT and you 
    might need to set the file acls after conversion. The other one to
    think about is SM_ACCOUNT_TYPES.DAT which underlies the templates.
    Use V24_SM_ACCOUNT_TYPES.DAT. Back up relevant files before you start. 
    Hope this helps. Can't comment on the overall risk in what you intend 
    to do.
    
    Cheers,
    DaveT
    
942.2OA$LIB:A1$POSTINSTALL.COMUTRTSC::SCHOLLAERTIOS: better than the real thingFri Jun 26 1992 13:5110
    Andy,
    
    Have a look at OA$LIB:A1$POSTINSTALL.COM for
    partition sedding and other 3.0 post install actions...
    
    Regards,
    
    Jan
    
    
942.3CM$AUTH$USERSCESARE::EIJSAll in 1 PieceFri Jun 26 1992 14:2214
    
    Andy,
    
    IF your applications reside in the OA application areas, and your
    swapping the ALL-IN-1 system disk (first time I hear about such a disk)
    then there should be no implications for CM, apart from:
    
    	CM$AUTH$USERS	(options CM AM MAP)	-> depends on PROFIL
    	
    The dataset is new for V3.0, but the contents might differ between systems.
    
    Ciao,
    
    	Simon
942.4Offically, I'd recommend the upgrade...IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeFri Jun 26 1992 17:0724
    .2's suggestion of examining the post install command procedures to see
    what it does is a good one.
    
    You'll find that a number of conversions take place, and also various
    scripts are run to populate data files.
    
    Also a number of other conversions and ACL settings get done during the
    installation, which you'll miss. You might want to review the KISETACLS
    and KISETOWNS .COMs in Base saveset A and see if any of those things
    need to be done after you've copied your backup across.
    
    A number of datafiles may need to be populated with environment
    specific things like disc names etc.
    
    You're probably getting the meessage by now, that I think you should do
    the upgrade again on each site. But then I write (well actually my team
    do :-) ) the installation code, so the only official advice I can give
    you is do it the "right" way.
    
    However I know people who have successfully done it your way!
    
    Good Luck,
    
    Graham
942.5He who lives by the sword dies by the swordAIMTEC::WICKS_ADEC Mail Works for ME sometimesFri Jun 26 1992 17:2813
    Andy,
    
    What about other files that got converted during v3.0 such as ATTENDEE?
    and are you sure that there aren't any differences in disknames between
    the clusters - for instance if their CM stuff is on FRED$DISK on
    cluster 1 will it be there on cluster 2... and then there's things
    like the names of the batch queues for the File Cab Server.
    
    Still i guess if/when it goes wrong you'll be ringing us anyhow.
    
    Regards,
                               
    Andrew.D.Wicks
942.6names names names!WOTVAX::DORANAMr Ken ShabbyFri Jun 26 1992 18:349
    Graham,
    
    Do you have any names that you could send me (Andy Doran @OLO) of
    people who have 'sucessfully done it my way.' - I promise not to tell
    them who told me...!
    
    Cheers,
    
    Andy
942.7Upgrade a COPY of the system disk?IOSG::TALLETTArranging bits for a living...Mon Jun 29 1992 09:0411
    
    	Hmmm. Sounds risky to me. How about doing an upgrade on a
    	COPY of the system disk from each of the clusters on your
    	test-bed machine? You would then have to do some smaller
    	amount of trickery to re-integrate the system disk back
    	into the cluster without losing changes that happened
    	whilst you were doing it. Still risky IMHO, but I would
    	have thought it safer than thr route you were suggesting.
    
    Regards,
    Paul