Conference iosg::all-in-1_v30

    Jan,
    
    Well you're a braver man than I (co-ex, TCP and non-safety!!)
    
    1) the correct name is in the release notes but not in the section
       "known problems with documentation" for some reason.
    
    2) did pre-check tell you this or not? Anyway the good thing is that
       A1$POSTINSTALL is rerunnable
    
    3) I must admit I had wondered about the bits of DIAMOND that were
    rolled back into TCP. I know IOSG went to greate lengths to get round
    a problem where the File Cab Server existed before v3.0. Was it just
    PARTITION or did any of the other files such as OAFC$SERVER thingies
    get in the way .... oh and have you QARd it.
    
    Regards,
    
    Andrew.D.Wicks
    
                                   

    Andrew,
    
    > Well you're a braver man than I (co-ex, TCP and non-safety!!)
    Small country, limited resources (in Holland, TCS, CSC, first
    and second-line support are in one room).
    
    > 2) did pre-check tell you this or not? Anyway the good thing is that
    
    Yes. I picked another disk for the ENGLISH part after
    pre-check warned me that I didn't have enough space on my 
    initial disk. A1TXL was 1132 blocks, my free space was 300.
     
    >rolled back into TCP. I know IOSG went to greate lengths to get round
    >a problem where the File Cab Server existed before v3.0. Was it just
    >PARTITION or did any of the other files such as OAFC$SERVER thingies
    >get in the way .... oh and have you QARd it.
    
    Would a workaround be changing the decnet object number
    of the TCP server before installing 3.0 ?
    
    Regards,
    
    Jan

    
    	V2.4 + TCP and co-ex V3.0 problems.
    
    	I remember discussing this with Graham during TCP development.
    	I don't think we (he :-) supports co-ex with TCP. :-(
    
    	The problem was teaching the FCS about co-ex logicals. I remember
    	that the FCS team were eager to put in the co-ex support, but I
    	don't think it ever made it. One idea was to start the server
    	detached, but from a command file so that it had a CLI and you
    	could wrap it up in a co-ex set of logicals.
    
    	At least that is how I remember it. Maybe Graham can elaborate.
    
    Regards,
    Paul

    Well we did end up teaching the FCS about co-ex systems, or it wouldn't
    work in a standard co-ex installation.
    
    However, as Andy mentioned, we don't do a number of things to do with
    the FCS if we detect that TCP is already installed, in order to avoid
    messing up any files that are already set up. It sounds like we may not
    have handled all of those cases correctly. I don't believe that
    changing the DECnet number will affect what we do.
    
    If you were a customer, I'd probably have to say that co-existent
    systems are only supported against standard V2.3 and V2.4 systems, so
    you'd need to show that these problems with the seeding occurred with a
    normal V3.0 upgrade before we would agree to them being real problems.
    
    Graham

    
    Running housekeeping procedure RSD resulted in one strange
    problem .
    
    RSD complained about missing OA$LIB:OA$SAM_REORG_SHARED_DIRS.EXE ...
    
    To be sure that my lack of disk space on my ENGLISH disk wasn't
    causing this problem, I reinstalled the co-ex system again
    with plenty of space. Problem is still there.
    
    The two other RSD images are there. Known ?
    
    Regards,
    
    Jan
    
    

    Hi there!
    
    	Ho hum, it appears your OA$LIB:OA$SAM_REORG_SHARED_DIRS.EXE
    	problem has nothing to do with co-ex systems.
    
    	After a cursory examination, I found another system with this
    	problem, so it looks like a bug.
    
    Regards,
    Paul

    
    Quick fix for the field:
    
    $!================ LINK.COM
    $ link /nomap /nodebug /notraceback /nocross -
                    /executable=OA$LIB:OA$SAM_REORG_SHARED_DIRS -
                    A1$BUILD:OA$SAM_REORG_SHARED_DIRS, -
                    oa$build:OALNM, -
                    SYS$INPUT /option
            SYS$SHARE:VAXCRTL.EXE /shareable
    $EXIT
    $!================ end LINK.COM
    
    @A1LNKDRV won't work (checks for "installation", if not no link).
    
    Regards,
    
    Jan

RE .7:

    $!================ LINK.COM
    $ link /nomap /nodebug /notraceback /nocross -
                    /executable=OA$LIB:OA$SAM_REORG_SHARED_DIRS -
                    OA$BUILD:OA$SAM_REORG_SHARED_DIRS, -
                    OA$BUILD:OALNM, -
                    SYS$INPUT /option
            SYS$SHARE:VAXCRTL.EXE /shareable
    $EXIT
    $!================ end LINK.COM

This will work, but note the different directory to that given in .7.  Also make
sure you use the correct OALNM file (see notes below on co-existent systems).

If upgrading from V2.3 or V2.4, the previous version of the image will still be
in OA$LIB.  So it is important to perform the above link to get the new
version of RSD.  

Please could someone in Atlanta create a STARS article for this.
    
>> @A1LNKDRV won't work (checks for "installation", if not no link).

This is the intended behaviour.  In V2.4, we shipped the .EXE for RSD.  This
meant it could only work with the base "OA$" system.  However, this is not
acceptable for V3.0, where RSD needs to run with co-existent systems.

Hence, for V3.0, we ship the .OBJ, and link RSD during the installation, so that
it picks up the appropriate logical name prefix (from the aforementioned
OALNM.OBJ).  The image only needs to be linked once, at installation time (i.e.
A1$INSTALL is TRUE).

Scott Marshall
Graham Pye
Paul Tallett

    
    I will include this information in STARS, but wouldn't it be even
    better to include this in the Read Me First. Or is it too late
    for that now? 
    
     Can you clarify a couple of things. First, if this is supposed to be
    linked in A1LNKDRV during the install, why didn't this happen when
    the install was done?  And also, it would be easier to have customers
    run A1LNKDRV rather than the procedure in .8.  Would this work if
    a local symbol A1$INSTALL is set to YES before A1LNKDRV is run?  Just
    a couple of questions to satisfy my curiosity!
    
    Thanks, Faith Donohue
    CSC/ Atlanta
    

    re. 8
    
>If upgrading from V2.3 or V2.4, the previous version of the image will still be
>in OA$LIB.  So it is important to perform the above link to get the new
>version of RSD.  
    
    What will happen if a customer runs RSD with the old image ?
    I expect that an upgrade from 2.3 will result in a system
    with the "corrupted directory" bug in it.
    
    Jan

    Re .9
    
    No, it's too late for the RMF, the kit is in production.
    
    It is linked in A1LNKDRV / A1LINK during the installation, we just
    forgot to copy the newly linked image out of the kit working directory
    into OA$LIB....
    
    I considered the suggestion of setting the symbol and running A1LNKDRV
    again, but that seemed to me to be rather an overkill in time, since it
    would unnecessarily link all the other images too. Since the link
    instructions were fairly simple for the RSD image, I thought this was
    the best workround. I'm quite happy for you to put both versions in the
    STARS article if you think that would be helpful.
    
    Re .10
    
    Correct. V2.3 users know that they sholdn't be running RSD unles
    they've been patched anyway. If they have the patch, then they'll be no
    worse than they were before.
    
    Re .11
    
    I suggest you contact the relevant authorities directly. I don't have
    any information about any checks in the mail...
    
    Graham

    
    Graham,
    
     Thanks for the explanation and I'll get both the workarounds in
    STARS with the overkill of running the A1LNKDRV noted.
    
    Faith
    

Re .13:  Note that the A1LNKDRV solution still won't put the .EXE into
OA$LIB, unless you do clever things with the A1$WORK logical.  That's
the whole point of using an explicit link command instead.

Re .11: Andy, please tell me what was said about RSD in a recent QRB (in mail
if it's too rude to put here!)

Scott

>Re .13:  Note that the A1LNKDRV solution still won't put the .EXE into
>OA$LIB, unless you do clever things with the A1$WORK logical.  That's
>the whole point of using an explicit link command instead.

In note 391.2, Andy mentions undocumented options to avoid linking
all images. Is there an option to just relink one image ?
If not, PFR ?

Regards,

Jan

    Not exactly.
    
    There are symbols to stop each image being linked, so if you set all
    but one of them, then only one image is linked.
    
    The symbols have names like:
    
    	a1$no_llv
    	a1$no_main
    	a1$no_formatter
    	a1$no_tmserver
    	a1$no_submit
    	a1$no_mailcount
    	a1$no_fcserver
    
    Although the FCS isn't linked unless the VMS version has chnaged
    anyway.
    
    Graham

    Re. .9,.10.11

    I thought you might add this info to your STARS article:
    
    I do not have OALNM.MAR nor OALNM.OBJ, as I have never relinked
    ALL-IN-1 since the upgrade to BL123A.

    I created them manually following a1link.com. The link procedure as
    taken from the notesfile did not like the $EXIT at the end. It
    seemed to take it as part of the link command (I am no link
    specialist). I removed the $exit and finally had a new version 
    of OA$SAM_REORG_SHARED_DIRS. 
    
    It is 24 blocks and thus 3 blocks smaller than the old one.
    Correct?
    
    /rhr                                                   
    

>>    It is 24 blocks and thus 3 blocks smaller than the old one.
>>    Correct?
    
    	Yes.  This matches the version in the build area from which BL123A
    was created.
    
    Martin.