Conference iosg::all-in-1_v30

    See note 1126 also for discussion on this

    
    Re:0
    
    To change the 'current values' go to MA (Manage Applications) and
    choose DAL (Define Application Logicals).
    
    As for fiddling with CM$MAF why didn't you do a WRITE CHANGE ?
    
    Hope this helps.
    
    Thanks,
    
    Mike
    

    
    Will DAL change the current logical values or will it update
    the logical translations in the CM$AUTH$LOCATIONS file or even
    better do both?  If it doesn't update the file, what is the
    recommneded method to do this?
    
    Trying to put all this together!
    
    Faith
    

    Faith,
    
    Option DAL doesn't update CM$AUTH$LOCATIONS. 
    
    DAL first checks (and defines) the Development/Receive logicals, then
    checks (and defines) the Authorized Live (and Base) locations, from
    CM$AUTH$LOCATIONS. 
    
    Ciao,
    
    	Simon


    PS Working remote from Max Brouwers' account

    
    Simon,
    
    That's what I had suspected. Then that leads me to more questions.
    
    First, how does the CM$AUTH$LOCATIONS get populated originally? and
    why on one of our V3.0 systems does it have entries for the OA
    application for all element types and on another it does not.  I'm 
    confused, can you tell?
    
    What would be your recommendations for updating this information
    when/if you move ALL-IN-1 areas to another disk?  I am trying to
    write up some complete documentation and this is the only missing 
    link!
    
    
    
    Give me a call @ DTN 343-1125 if necessary.
    
    Thanks, Faith
    
    
      

CM$AUTH$LOCATIONS is populated by the installation procedure.

Moving disks - there are no facilities to automatically adjust the contents
of CM$AUTH$LOCATIONS after you move locations from disk to disk.  However, 
it's easy enough to see how it could be done.

For example, here is some code (that I won't guarantee to work).

GET #NEW_DISK = "DISK$A2:"

FOR CM$AUTH$LOCATIONS WITH (.SITE_TRANS = "DISK$A1:") DO -
   GET #CM_LOC_KEY = .%KEY\\-
   GET #CM_LOCATION = .SITE_TRANS\\-
   GET_SYMBOL #CM_LOCATION,#CM_LOCATION2, "[" \\-
   GET #CM_LOCATION = #NEW_DISK "[" #CM_LOCATION \\-
   WRITE CHANGE CM$AUTH$LOCATIONS %KEY = #CM_LOC_KEY, -
       SITE_TRANS = #CM_LOCATION

You'll have to also change the .BASE_TRANS field if the base locations are 
changing disks.

Tony

    
    A few more questions about the when the translations in this file are
    used and what they are intended for.
    
    It doesn't look like the information in this file is used to define 
    these logicals during the ALL-IN-1 start up proceudre, is that right?
    
    Is the information in this file ONLY used to define these logicals when
    the DAL option is invoked?  
    
    You said that this file is initially populated during installation.
    Is it intended that the standard OA application areas (SHARE and
    ENGLISH) are included in this file.  If so, it seems like this
    conflicts with the use of the A1CONFIG file for defining the base and
    site logiclas for this application during start up.  It seems like 
    the OA application areas that are defined in the A1CONFIG should not
    be included here.  
    
    I am still not sure why on 2 different V3.0 systems, one has entries
    for the OA application areas and the other does not.   Can you give me 
    any indication of which should be expected on a V3.0 system.  Also, on
    the system that does have these entries many of the logical
    translations stored in the file are not correct based on the current
    logical definitions.  It seems like this could happen easily and if
    the OA application areas are expected to be stored in here, then there
    should be some procedure available to update this file.  Why are
    the logical translations stored in the file? Couldn't they be
    determined when needed based on the current translation value for the
    logical which could be stored in the file.
    
    
    Can I assume, the the OA application area logicals will be defined
    properly during startup from the A1CONFIG definitions. And that if
    this file (CM$AUTH$LOCATIONS) does not contain the correct logical
    trnaslations for ENGLISH and SHARE areas it will ONLY affect the system
    if the DAL option is run for this application. If so, then I can
    also redefine the logical translations stored in the file, based on
    the logicals after the ALL-IN-1 start up procedure runs once A1CONFIG
    is changed and moved.
    
    Thanks in advance.
    
    Faith
    

Re .5

>    Why on one of our V3.0 systems does it have entries for the OA
>    application for all element types and on another it does not.  I'm 
>    confused, can you tell?

Is the system which misses the authorized locations a system which has been 
upgraded/updated with the different BLs of ALL-IN-1 V3.0? An update of ALL-IN-1 
V3.0 system will NOT update the CM$AUTH$LOCATIONS data set.
As Tony indicated, the data set will be populated during the installation.

Re .8
    
>    It doesn't look like the information in this file is used to define 
>    these logicals during the ALL-IN-1 start up proceudre, is that right?

The logicals for the OA application are defined via A1V30START.COM at the
moment according to A1CONFIG. 
However, the 'Startup' field in CM$APP (where the 'OA' application is defined)
contains the application specific startup procedure, and the logicals are
redefined for the 'OA' application according to CM$AUTH$LOCATIONS. So the 'OA'
logicals are defined twice. 

This can be prevented by removing the entry 'DO CM_DEFINE_APPLICATION_LOG' from 
the 'Startup' field in CM$APP.

Moving disks means (for the 'OA' application) that the info in 
CM$AUTH$LOCATIONS should be adjusted as discussed in previous answers. If you 
decided to take the 'OA" application specific startup procedure out of CM$APP, 
then the info in A1CONFIG needs to be updated so that when ALL-IN-1 is 
restarted the logicals are re-defined.
    
>    Is the information in this file ONLY used to define these logicals when
>    the DAL option is invoked?  

DAL is a shortcut. If you decided that your application will use an application 
specific startup procedure ('DO CM_DEFINE_APPLICATION_LOG' could serve) than 
the fields 'Site/base Translation' can be be used during ALL-IN-1 startup to 
define application logicals. Currently there is no other use of these fields.

>    You said that this file is initially populated during installation.
>    Is it intended that the standard OA application areas (SHARE and
>    ENGLISH) are included in this file.  If so, it seems like this
>    conflicts with the use of the A1CONFIG file for defining the base and
>    site logiclas for this application during start up.  It seems like 
>    the OA application areas that are defined in the A1CONFIG should not
>    be included here.  

See above. The entry 'DO CM_DEFINE_APPLICATION_LOG' isn't really needed for the
'OA' application. 

>    I am still not sure why on 2 different V3.0 systems, one has entries
>    for the OA application areas and the other does not.   

See above.

>    Can you give me any indication of which should be expected on a V3.0 
>    system.  

Any installation, except the V3.0 -> V3.0 update installation will populate the 
data set for 'SHARE' and a 'language'.

>    Also, on the system that does have these entries many of the logical
>    translations stored in the file are not correct based on the current
>    logical definitions.  It seems like this could happen easily and if
>    the OA application areas are expected to be stored in here, then there
>    should be some procedure available to update this file.  Why are
>    the logical translations stored in the file? 
    
The translations of the logicals are retrieved during the installation 
procedure according to the installation symbols and logicals used. 
The fact that the logicals values are different from the translations stored in 
CM$AUTH$LOCATIONS can only be explained by:

	A1CONFIG has changed
	CM$APP doesn't contain a startup procedure for 'OA'
    
As said, the current reason for storing the information in this file is to be 
an aid in defining application logicals. 
 
>    Couldn't they be determined when needed based on the current translation 
>    value for the logical which could be stored in the file.

You mean you want an option which updates the information in CM$AUTH$LOCATIONS 
according to the current logical value (which might be different from the 
translation in CM$AUTH$LOCATIONS)? 
Basically we need the translation value because we want to define the logicals. 
That might happen in circumstances these logicals don't exist. No current 
values available then.... Hmmm, I think I don't understand the question too 
well!

>    Can I assume, the the OA application area logicals will be defined
>    properly during startup from the A1CONFIG definitions. 

Yes.

>    And that if
>    this file (CM$AUTH$LOCATIONS) does not contain the correct logical
>    trnaslations for ENGLISH and SHARE areas it will ONLY affect the system
>    if the DAL option is run for this application. 

Yes.

>    If so, then I can
>    also redefine the logical translations stored in the file, based on
>    the logicals after the ALL-IN-1 start up procedure runs once A1CONFIG
>    is changed and moved.

Yes.

	Ciao,

		Simon    

    Faith,
    
    AMERIG should have all the correct CM files as I copied them in by hand
    - if not let me know. As for DIMUND well I don't feel responsible or
    even irresponsible! for that machine but I guess that copying the data
    files over might make the weird behaviour go away.
    
    Regards,
    
    Andrew.D.Wicks