Conference iosg::all-in-1_v30

    Re .1
    
    I disagree. But then I would because my team would have to fix it!
    
    Re .0
    
    I guess that because the file spec of the transfer user directories is
    hardwired into the SYSUAF records of the A1$XFER_IN and A1$XFER_OUT
    accounts, then it's hardwired into the startup file too. You can always
    change the logical by a reassignment in the site startup file:
    
    	OA$SITE_BUILD_SHARE:A1V30_SITE_START.COM
    
    and making corresponding changes in AUTHORIZE too. Would the author of
    .1 who knows a little ( :-) ) about Transfer user like to reassure us
    that it would all still work?
    
    Your second question:
    
    <<< Because this was already in ALL-IN-1 V2.3 can someone explain why there
    <<< is a flexibility to change some values, while on the other hand some
    <<< procedures contains hard-coded values, like ".MGR]".
    
    This is just the way it was "designed" and coded. Some things got made
    more flexible because people had asked for them to be, or we thought
    that it would be useful for them to be, and others didn't. We had a lot
    of other new functionality that we managed to squeeze in with our
    limited resorces!
    
    We always have to think of what would be the ffect on existing systems
    by making this sort of change.
    
    So, I don't think any QARs are in order here!
    
    Graham

    Hi,
    
    
    Thanks for your explanations.
    
�    This is just the way it was "designed" and coded. Some things got made
�    more flexible because people had asked for them to be, or we thought
�    that it would be useful for them to be, and others didn't. We had a lot
�    of other new functionality that we managed to squeeze in with our
�    limited resorces!
        
    I understand.

    The main reason for posting is that if other users want to change such
    things and they have problems, they can find a reference.

    One other similar problem can arise if you change the values of the
    logicals OA$MTI_LOG and OA$MTI_ERR. Once I had to this when a customer
    wants these log-files to be in OA$LOG. The problem occurs in EMLOGCTRL
    (to switch the log-files) where ".LOG" is substracted from the file-
    spec. So, if ".LOG" is in the directory-spec (which is the case if the
    files reside in OA$LOG) you will end up with an invalid file-
    specification for MTIERR.LOG and MTILOG.LOG.

    This is the modification I made (between $ ! + and $ ! - lines):

    $ old_error_log="''error_log'" - "''error_log_type'" - "''error_log_ver'" + ".BAK"
    $ ! +
    $ ! Concatenate above error symbols to make the extraction correctly.
    $ ! It went wrong if .LOG is in the directory specification. SB.
    $ ! 
    $ type_ver = error_log_type + error_log_ver
    $ old_error_log = "''error_log'" - "''type_ver'" + ".BAK"
    $ ! -
    $ rename 'error_log 'old_error_log

    and

    $ old_traffic_log="''traffic_log'" - "''traffic_log_type'" - "''traffic_log_ver'" + ".BAK"
    $ ! +
    $ ! Concatenate above error symbols to make the extraction correctly.
    $ ! It went wrong if .LOG is in the directory specification. SB.
    $ ! 
    $ type_ver = traffic_log_type + traffic_log_ver
    $ old_traffic_log = "''traffic_log'" - "''type_ver'" + ".BAK"
    $ ! -
    $ rename 'traffic_log 'old_traffic_log


    Still keeping the faith, Sjaak.

    Sjaak,
    
    The OA$MTI_* one is also kind of not a bug (not that i'm biased)
    because the log files were put in [ALLIN1.MGR] about 5 years before
    OA$LOG was even invented and it never even crossed our minds to
    move them because we thought that customers/programs/specialists etc
    were already so used to looking for them where they were.
    
    I guess though it's a good suggestion to move them to OA$LOG and
    hopefully it will get done when/if somebody also removes the code
    for VMS version 3.0 in those files as well (:==:)
    
    Regards,
    
    Andrew.D.Wicks