Conference iosg::all-in-1_v30

Hi Steve,
    
>    1) Both the Install guide and release notes refer to a recommend-
>    ation to backup CM_SITELOG.DAT and CM_SDC_SITE_ELEMENTS.DAT before 
>    upgrading...
>    
>    The second file doesn't exist (but CM_SDC_ELEMENTS.DAT does, which 
>    I've already gotten confirmation for).  Question is, does 
>    CM_SDC_ELEMENTS.DAT need to be backed up (isn't a new version 
>    supplied)?

Yes, it is still advised. During an upgrade installation the
CM_SDC_ELEMENTS.DAT is merged into the V3.0 CM$SDC.DAT first 
(CM_POST_MERGE_SDC_UPG.SCP), because we don't want to loose any additional 
information from CM_SDC_ELEMENTS.DAT, do we?

Then, in a second stage, the new supplied CM$SDC.DAT (supplied as
CM$SDC$<language>.DAT) is merged into the CM$SDC.DAT, together with the action
to modify existing record entries (which came from V2.*) for 'non-critical'
V3.0 information. Not all fields are modified (like CUSTOMISED, etc.). Check
CM_POST_CONVERT_SDC_LLV.SCP and CM_POST_CONVERT_SDC_SHARE.SCP for the
modifications. 

If the V2.* to V3.0 Merge fails, CM_SDC_ELEMENTS.DAT will not be deleted. 
However, one time we experienced that all checks to see if the OA$CNV_MERGE
worked correctly gave the green light, although it should have failed, and
CM_SDC_ELEMENTS.DAT was deleted. That's the reason to keep a copy, to re-do the
conversion. 
    
Ciao,

	Simon

    
>    2) An existing 2.4 license (customer license) will suffice for the 
>    V3.0 installation upgrade....Correct?
    
    	Correct for customer PAKs. Internal PAKs obtained from VTX may no
    	longer be valid and you would need to get another from VTX.
    
    Regards,
    Paul

    
    Thanks for previous replies..a few other observations:
    
    * I believe the release notes p. 1-2 concerning incorrectly-defined 
    'dev' directory logicals for second-language logicals are 
    incorrectly stated. (would not a top-level directory reference be 
    required in the equivalence string, and shouldn't the dev_rec logical 
    point to a 'dev_rec' directory ?)
    
    * I would also offer that the installation guide's description of 
    the postinstallation task to 'replace customized help modules' would 
    be self-defeating, since the replaced modules would not get entries 
    written in the CM database (which would be nice, even if the
    customizations were done pre-upgrade)
    
    Also can someone explain why the DNS images are required if I'm not
    using DNS ?
    
    Thanks,
    
    Steve

    Hi Steve,
    
    I don't have a copy of the release notes here, so I won't comment on
    page 1-2's contents. The logical for the receive area (a sub-directory
    of the development area) should point to the place where ALL-IN-1/CM+
    can unpack elements that are being transferred from another system. I
    believe CM+ uses the logical name, so if this pointed to something like
    DISK$A1:[MY_TRANSFER_LOCATION.RECEIVE] it would probably work.  
    
    You are correct that the right way to replace customized help modules
    is to do so via CM (now that they are replaced). However, I can see
    that people might want to concentrate on other things immediately after
    an installation and so take the short-cut outlined in the installation
    guide. After the installation is stable they can come around and do the
    "right" thing. Dealing with mandatory update elements is a much higher
    priority than help (IMHO).
    
    Finally, I thought that the requirement for DNS was lifted a couple of
    baselevels ago. DNS is used by the File Cabinet Server - that's the
    only reason ALL-IN-1 requires it. 
    
    Tony

    I'd hoped that Bob might have come through with the definitive answer
    by now, but...
    
    We don't need DNS started.
    
    All we need is for the DNS images to be installed as specified
    (somewhere!) since there are some routines in them that are used by the
    FCS, and perhaps the main image too.
    
    Graham

    I just failed on installing V3.0 for the first time despite 3 days of
    system prep.  I checked all the parameters several times and even upped
    a few based on Tony's book.  I noticed that DNS$SHR was listed as a
    required image in the Installation Guide, when it apparently should be
    DNS$SHARE.  However, even though I have it INSTALLed /OPEN/HEAD/SHARE,
    the installation failed after a very long time with:
    
    
    A1-I-A1LINKED, Finished linking images
    %DCL-W-ACTIMAGE, error activating image DNS$SHARE
    -CLI-E-IMGNAME, image file
    $121$DKA300:[SYS0.SYSCOMMON.][SYSLIB]DNS$SHARE.EXE
    -SYSTEM-F-PROTINSTALL, protected images must be installed
    %A1-I-RNEPROF, Running command procedure EPROFIL.CA1
    %DCL-W-ACTIMAGE, error activating image DNS$SHARE
    -CLI-E-IMGNAME, image file
    $121$DKA300:[SYS0.SYSCOMMON.][SYSLIB]DNS$SHARE.EXE
    -SYSTEM-F-PROTINSTALL, protected images must be installed
    
    %A1-E-RETRY1, Please correct any reported problems before attempting
    %A1-E-RETRY2, to install ALL-IN-1.
    
    %VMSINSTAL-E-INSFAIL, The installation of A1 V3.0 has failed.
    
    Did I miss this in the release notes, or is this something to be
    expected?  Will it work if I just do an 
    
    INSTALL REPLACE DNS$SHARE.EXE/OPEN/HEAD/SHARE/PROT
    
    ??
    
    I did run the PC option before beginning the full installation and it
    did not complain about this.  I do not use DNS on my system; it is in a
    hidden area.  If this has not been release noted, perhaps it should be
    as it is extremely aggravating; I will have to skip the installation
    for a week or so.
    
    I have modified my own procedure to check things out for V3.0, but I
    don't see a listing for the number of system disk blocks required for a
    "safety mode" installation.
    
    Ben

    Tony's book doesn't cover ALL-IN-1 V3.0. Tony's second book might, but
    only just.  The SYSGEN parameters in ATO are OK, but there are a few
    differences for V3.0 and the installation guide is the proper place to
    check.
    
    Did you startup DNS or just use INSTALL to install DNS$SHARE.EXE? I
    have always found that @SYS$STARTUP:DNS$STARTUP is the best way to get
    DNS to become aquainted with the rest of the system.
    
    Tony

	This seems to work for me.

$	FILE = "SYS$SHARE:DNS$SHARE.EXE"
$	IF F$SEARCH(FILE) .NES. "" THEN INSTALL REPLACE 'FILE'/SHARE/PROT/OPEN
$	FILE = "SYS$SHARE:DNS$RTL.EXE"
$	IF F$SEARCH(FILE) .NES. "" THEN INSTALL REPLACE 'FILE'/OPEN/SHARE

HTH

John

    
    re .5
    
    Graham,
    
    I would have come back with an answer, but I was off in Florida 
    getting some sun and golf in rather than freezing up here in NH.
    Now that I am back I will try and give one :-)
    
    re .7
    
    Tony,
    
    sys$startup:dns$startup is for a dns server. This is not what is needed
    for the FCS, the FCS requires the dns clerk images that contain the
    dns rtl routines.
    
    re everyone else
    
    The FCS requires the existance of sys$share:dns$share.exe and
    dns$rtl.exe because we are CAPABLE of running with DNS used as the
    naming mechanism. This requires us to include calls to sys$dns as
    well as other dns routines. These routines are ONLY USED IF THE
    FCS IS RUNNING AT DISTRIBUTION LEVEL 1 (DISTRIBUTION ON).
    
    The FCS also contains routines that mimick the DNS routines, these are
    used whenever the server is running at distribution level 0
    (Distribution off -- DECnet naming).
    
    THe files that we require to exist are shipped with VMS. I would like
    to stress, we do not require the existance of a DNS server or namespace
    nor do we require that dns$clerk be started. In fact it is a
    requirement that we DON'T require the clerk. (Clear ??)
    
    --Bob
    

    Re. 9
    
    
    Hi Bob, I know that DNS$STARTUP starts everything up - including the
    DNS clerk... you can see that old (bad) habits developed during field
    test die hard...
    
    T

I just returned from Expert Training, so I am looking at this again.  I guess I 
could have gotten the answer directly from Graham, but I was too busy admiring 
his outfit.

Tony, I don't know why you couldn't have included information about an incomplete 
product in your book.  Performance information for undeveloped products could be
very valuable since they are developed intutively rather than by wasting time
in a lab or with actual users.   Acutally, I had do make some assumptions 
based on what I thought you *would* say if you actually knew performance info
on V3 from customer experience. ;-)

At any rate, it might be nice if 

1.  The correct file names were documented along with *how* they are to be 
     installed.

2.  The checking option also checked for these files.


I will try again awith the suggestions and post the results.

Ben

The installation worked in a mere 8 hours on a VAXstation 3540 with 32 
Mb of memory.  Of course, we did discover some memory problems later.

I notice that there is a still a message on the screen telling the 
user to:

$ SET PROC/PRIV=(NOBYPASS,ALL)

This is left over from V2.4 (at least).  It should be 

$ SET PROC/PRIV=(ALL,NOBYPASS)

I also notice that it requires you to log in on another terminal to 
change certain things the second time around, such as an existing user 
account.  Whatever happened to the concept of being able to pick up a 
failed installation after an error.  Surely, this error is about as 
minor as they come.

Ben

    <<< $ SET PROC/PRIV=(NOBYPASS,ALL)
    <<<This is left over from V2.4 (at least).
    
    Probably V2.3 actually. Noted :-)
    
    I didn't think we *required* you to log into another terminal to fix
    things, we only gave you the opportunity of fixing things whereas in
    V2.4 and earlier the installation would have failed and made you start
    again!
    
    In the case of already exisiting accounts I thought we would allow you
    to use them after checking that you knew what you were doing. I'm sure
    you'll give me the full details to correct this belief :-)
    
    Graham
    
    PS Only 8 hours - I wish I had such a quick machine! Let me swop you
    with my 6Mb VS2000 running DECwindows....

The log file is unfortunately gone.  However, my recollection is that I installed
once, got the error, and then began again.  On the second pass, it found all the 
accounts it put in the first time, and saw this as a conflict.  I had to 
login in a second session and remove them.  It could have just as well deleted 
them, or so it seemed to me at the time.

The DNS$SHARE problem continues, as I had to put the file somebody posted in an 
earlier reply into the system startup.  I had put it into 
OA$SITE_BUILD_SHARE:A1V30_SITE_START.COM, but that didn't work, since it 
couldn't run ALL-IN-1 without the image being installed, and that is apparently
executed after ALL-IN-1 is run.  The startup file kept aborting.

However, it does work now, and we have a chance to play.  I nominated myself as
a system manager, which seems a trifle different from nominating someone as an
administrator; you have to grant the identifier manually.  I might have made all
the nomination procedures the same, but this may work out.

Ben