Conference iosg::all-in-1_v30

    Banquo,
    
    	In V3.0 a number of files were moved from one directory to another,
    typically from a language directory to a share directory.  
    DELETE_MOVED_FILES.COM deletes the pre=V3.0 version of these files from
    the previous location.  This is run automatically as part of the
    postinstallation to ensure the old version is not used in preference to
    the new one.
    
    	DELETE_OBSOLETE_FILES.COM  deletes all the files that are no longer
    needed by V3.0.  This is not run by the postinstallation as some of
    these files may be used by customizations.
    
    	The V3.0-1 patch does not have a DELETE_OBSOLETE_FILES.COM file. I
    expect this is because there are no files obsoleted by the patch.  I
    cannot comment as to whether a possible future patch will have such a
    file but I should think the problem of overwriting the existing one
    will be considered.
    
    
    Martin.
     

    A customer I just upgraded told me they ran the *obsolete*.com file
    with unexpected results:
    
    1) ENGLISH ran great; however,
    
    2) SHARE deleted 125 files that were being used. Fortunately, CM was
    not touched, and they had an intact test system to copy the missing
    files from. ("Only" cost them three days of work.)
    
    Did _I_ do something wrong? Is there a bug?
    
    Thanks to all who help. Is your name really Banquo? Cool! When shall we
    three meet again?!
    
    Bruce

    Bruce,
    
    Could you give an example or two of these files that you say were
    deleted by mistake?
    
    Regards,
    
    Andrew.D.Wicks

    You _would_ ask that. We didn't get into the details. I do recall the
    ALL-IN-1 told me his boss called him up to report: "I can't schedule
    anything." (He was trying to do some housekeeping.)
    
    His impression was that the files that were erroneously deleted were
    not actually obsolete, but were instead merely moved from ENGLISH to
    SHARE, or vice versa.
    
    I know that isn't much to go on. Thanks for any help, anyway. Although
    this evidently isn't a widespread phenomenon, I will tell my people in
    the future to back up their OA$LIB, DO, SCP and BLP areas before
    running that procedure. And to do it on the weekend.
    
    Bruce

    Well Bruce the reason I asked wasn't to be awkard but because
    a) STARS shows nothing similar
    b) v3.0 has been out over a year and noone else has reported this
       to my knowldege.
    c) I looked at the COM file and it looked ok to me (i.e had deleted
       elements in it)
    
    Unless you have an example or GAP can make an educated guess at what
    happened i'm stumped on this one
    
    Regards,
                                  
    Andrew.D.wicks

    This was one of those sites, among many, where there was some funny
    code, such as hard-coding of script and com file locations, etc. It's
    possible what I saw was a result of some of that. We ran the CART and
    examined it with a fine-tooth comb before the upgrade, so it isn't as
    simple as letting them call obsolete elements.
    
    I'd really like to get out there and have a look at it, but they're out
    of money. (It's the Sheriff's Department of the largest county in the
    U.S., and they really have to stretch the dollars. They've even been
    shutting down stations.)
    
    Thanks for the help.
    
    Bruce
    

    This is how it's supposed to work:
    
    1A) You run the CART and it (amongst other things :-) ) identifies any
    files that you are referencing that we are intending to delete.
    
    1B) Any of these that you still want to use, you "customise" and move
    into the site areas.
    
    2A) The CART also tells you about any files that you are using that we
    are moving. I'm not sure about this part, I know that the CART
    identifies any files that have been customised that we are moving.
    Perhaps Tony can help with this when he returns from his holiday, or
    someone else?
    
    3) The installation provides new versions of the files that have moved
    to the new locations.
    
    4) DELETE_MOVED_FILES.COM which *IS* run by the installation gets rid
    of the files which have moved, so the TXL compilation finds the right
    versions and search list accesses find the right versions. *NOTHING* is
    deleted from the SITE areas.
    
    5) The installer gets to choose whether to run the command procedure 
    DELETE_OBSOLETE_FILES.COM, which does *NOT* delete anything out of the
    SITE areas.
    
    6) The CART "fix" script correspondingly sorts out the SDC elements
    file records for these elements.
    
    N.B. This doesn't apply to forms, since we replace .FLBs in their
    entirety, any deleted or moved forms immediately vanish from the base
    libraries.
    
    So, without any more details about exactly what went wrong on your site,
    I don't know what else to suggest... Perhaps they had some
    customisations that explicitly referenced some moved files in their old
    locations, and we didn't spot that with the CART.
    
    I HTH you to understand what we were trying to do, and hence might
    explain what happened.
    
    Graham

    I modified DELETE_OBSOLETE_FILES.COM so that instead of deleting files
    it made DIR/DATE of the files that were to be deleted by the procedure.
    
    I ran the procedure on a v3.0-1 system that had never had ALL-IN-1
    installed earlier, and out came:
    
    A1$DISK:[ALLIN1.LIB_SHARE]OA$SAM_REORG_SHARED_DIRS.EXE;1
                         24-MAR-1993 12:36:29.06
    
    
    On a customer system I had upgraded from v2.4 to v3.0-1, I also found
    that this file was new and should be commented out from
    DELETE_OBSOLETE_FILES.COM so that it did not get deleted.
    
    Below is my DIR_OBSOLETE_FILES.COM.
    
    Elin
    
$! DIR_OBSOLETE_FILES.COM
$! This is made by editing DELETE_OBSOLETE_FILES.COM
$! I don't guarantee anything, but the file has been of great help for me.
$! I have run it from a top directory e.g. [elin] 
$! Afterwards I did $SEARCH GAMLE_FILER.LIS 199 /win=3
$! in order to see which files were newer than 1990.
$! Remember to clean up the subdirectory and file 
$! that are created by this procedure
$!
$! Elin Christensen, November 1993
$!
$!******************************************************************************
$     a1$userdirect == f$trnlnm("oa$lib_share","lnm$system_table")-"]"+".USER]"
$       assign/nolog/process 'a1$userdirect' a1$userdirect
$ goto start
$ DIT : SUBROUTINE
$ dir_file = p1
$ if f$search("''dir_file'") .eqs. "" then goto naeste
$ dir/notrail/noheader/date/out= xxx.xxx 'dir_file';*
$ append xxx.xxx gamle_filer.lis
$ delete xxx.xxx;*
$ NAESTE:
$ ENDSUBROUTINE
$!
$ START:
$ crea/dir [.midlertidig]
$ set default [.midlertidig]
$ create gamle_filer.lis
$
$ if p1 .nes. ""
$  then
$       a1$language = p1
$  else
$       a1$language = "LLV"
$ endif
$ Write sys$output "Creating directory list of obsolete files..."
$ CALL DIT a1$userdirect:NICKNAMES.DAT
- and here follows all the rest of DELETE_OBSOLETE_FILES.COM......