[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

116.0. "Removing Coexistent System - when to do it?" by GLOVES::ALLERTON (Steve Allerton 343-0205) Thu Feb 27 1992 15:31

    I believe there is some potential for trouble with respect to the 
    documented procedures concerning the removal of a coexistent system.
    
    The implication (as I read) in section 5.2 of the installation guide,
    is that an upgrade can be performed before the coex system is deleted.
    
    ("Do not delete the coexistent system until you have transferred your 
    customized files to your new system") and 
    
    ("Do not transfer your customized files to your previous system before 
    upgrading").
    
    I submitted a QAR a few weeks ago dealing with problems encountered
    when the coex system is deleted from the coex system's MANAGER account 
    (ALLIN1_1 by default).  In a nutshell, the coex delete procedure
    doesn't complete because a temporary file gets deleted before it is 
    "accessed" later by procedure call.
    
    I decided to try deleting the coex system from the SYSTEM account 
    this week (with help from some crackerjack students in a class I 
    piloted this week :>)).  We also had the coex system running side 
    by side with an upgraded V2.4 to V3.0 system and moved some 
    reworked customizations from the coex system back to the upgraded 
    system.  We then ran the delete_co-ex procedure from the system.
    
    The coex system was completely deleted, as were all the V3-introduced 
    identifiers (OA$MANAGER, OAFC$SYSMAN etc.) as well as the A1$SCRIPT, 
    OAFC$DEFAULT and OAFC$SERVER accounts.  Also gone was the executable 
    associated with the script symbiont and numerous "MTS" images.
    
    From what I can determine, the procedure expects that the coex system 
    will be deleted prior to upgrading, but the installation documentation 
    recommends something to the contrary.  And let me add something else...
    I have nothing but the highest regard for everyone concerned, and I 
    know what engineers and doc writers alike have been racing 130 m.p.h. 
    the past year and still found time to respond to my questions and 
    oft-idiotic ramblings.  here I'm just wondering if there's a 
    dangerous potential for an upgraded system being crippled out there
    somewhere.
    
    Thanks,
    
    Steve
T.RTitleUserPersonal
Name		DateLines
116.1130 mph (208kph) Apologies...IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeThu Feb 27 1992 22:5719
    Steve,
    
    Yes, you're right, it certainly looks like I was intending that the
    Co-ex system should get nuked before the upgrade when I did the code.
    
    It also looks like I overlooked that design aim when I reviewed the IG.
    
    I'll investigate some more shortly.
    
    Sorry,
    
    Graham
    
    PS Have you got any details of what your "crackerjacks" did to sort it
    out?
    
    PPS A belated apology that I still haven't got around to replying to
    your QARs or notes in DIAMONDFT, more urgent things have been occupying
    my mind recently!
116.2Might just the directory structure be removed?GLOVES::ALLERTONSteve Allerton 343-0205Fri Feb 28 1992 08:4119
    
    Graham,
    
    We deleted the co-ex system late in the course, so there wasn't much 
    chance to try bringing the upgraded system back to a fully functional 
    state.
    
    I tried recreating the deleted accounts and identifiers, but wasn't
    sure where (actually didn't have time) to look for the deleted .EXE 
    files.  Some of the students felt that the procedure could be 
    edited to comment out portions that delete the V3 stuff.  Since I did 
    an upgrade successfully last time after an incomplete coex removal, 
    I'm wondering why the V3 identifiers and images need to be removed 
    anyway.  Wouldn't the upgrade be able to simple re-use them if they 
    were already in place?
    
    Thanks,
    
    Steve
116.3Works for normal systems too....IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeFri Feb 28 1992 14:238
    Steve,
    
    Yes, the identifiers could be reused, but it's less confusing if they
    get deleted and take the system back to a clean state. Also, with a
    small change to one of the early checks, the procedure is an almost
    complete deleter of a normal V3.0 system too....
    
    Graham
116.4Fixed!IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeTue Mar 17 1992 10:337
    In the resubmitted V3.0 kit, we fixed the DELETE_CO-EX procedure so
    that it would figure out if there was a real V3.0 system installed, and
    if so, not delete all the new V3.0 things.
    
    Thanks for pointing this out!
    
    Graham
116.5A few problems lingerGLOVES::ALLERTONSteve Allerton 343-0205Sun Mar 22 1992 16:1223
    
    Graham,
    
    Thanks for following up...
    
    It looks like the procedure still flops if it is executed from the 
    coexistent system's ALLIN1_1 account (which I QAR'd earlier on)...
    
    The error is :
    
    %CREATE-E-OPENOUT, error opening DUA0:[ALLIN1_1]DELETE_ACCOUNTS.TMP; 
    as output (directory not found, no such file etc.).
    
    I don't see anything in the Release Notes telling me I have to use 
    another account (such as the SYSTEM account) to run this procedure.
    
    If another account (with BYPASS) is to be used instead, it also needs to 
    be granted the OAFC$SYSMAN identifier, otherwise the FCS can't be deleted, 
    nor can a number of other shared files (such as the coex DAF) that get 
    locked by it.   
    
    
    Steve