| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1136.1 | How to import elements | SIOG::T_REDMOND | Thoughts of an Idle Mind | Tue Jul 28 1992 18:22 | 17 |
| Take these steps.
1. Create the application.
2. Create some application areas.
3. Put copies of your elements into the applications "Receive area".
If the application is called CARS then you'll have directories like
[ALLIN1.SITE.DEV_REC_CARS_SHARE] The receive directory is composed
of a set of sub-directories, one for each element type. Put your
elements into the different directories. DO mode scripts in .DO etc.
4. Use the RV (Receive from VMS) option on the AM menu to import the
elements into CM. Tell CM what type of element you are interested
in (DO etc.) and what application area (CARS_SHARE, CARS_ENGLISH)
you have put the elements to be imported.
5. CM imports the elements... you can update the element details later
on if you want with the UED option.
Tony
|
| 1136.2 | Receive areas is what you want to use | IOSG::BILSBOROUGH | Just testing. Please ignore!!! | Tue Jul 28 1992 18:24 | 17 |
|
When you create an application and then an area for it, receive
directories are created for you. Put you application code into these
directories (one dir for each SCM+ element type) and then go to
AM (Application Maintainer) RV (Receive from VMS) choose the
application and press return.
The receive areas are pointer to by logicals such as
OA$SITE_DEV_REC_CARS_AREA1:
Hey presto!, the elements are in SCM+
Hope this helps.
Mike
|
| 1136.3 | And also... | AIMTEC::WICKS_A | DEC Mail Works for ME sometimes | Tue Jul 28 1992 18:32 | 8 |
| Since you want to be the OEG of your application you also need to:
6. Create base locations/directories for your elements
7. Use MBA to move the elements you RV'd from Develop to Base.
regards,
Andrew.D.Wicks
|
| 1136.4 | And also... (2) | CESARE::EIJS | All in 1 Piece | Wed Jul 29 1992 09:47 | 51 |
|
Hi Dave,
In addition...
Re .1
> 3. Put copies of your elements into the applications "Receive area".
> If the application is called CARS then you'll have directories like
> [ALLIN1.SITE.DEV_REC_CARS_SHARE] The receive directory is composed
The example is correct, but it is not necessary that the Receive area resides
under [ALLIN1.SITE]. If you decided to call your SITEROOT directory [CARS.SITE]
then the Receive area resides in [CARS.SITE.DEV_REC_CARS_xxx]. It's just to get
the picture.
Re .3
> 6. Create base locations/directories for your elements
> 7. Use MBA to move the elements you RV'd from Develop to Base.
If you add the entries to CM$AUTH$LOCATIONS (AM MAL) use the existing logicals
you use already. If you don't have Site directories, please create them, and
also define the necessary logicals pointing to these directories. You need Site
directories as they form part of the key for authorized locations.
Re .0
> (some scripts go in OA$DO, others go in their own application directory
> (e.g. xxx$$D_DO) where XXX is the application nemonic (CARS say).
This is tricky. Keep in mind that:
- Live/Base locations for your CARS applications cannot be e.g. OA$SITE_DO_xxx,
as these 'belong' to the OA application -> these elements need to go into the
OA application areas
- You can package only seperate applications. You cannot package e.g. elements
from the CARS and OA application together. Two packages are needed then
But...
If the elements which were put in OA$DO were non-standard elements (not
belonging to the OA application) and the reason for putting elements in OA$DO
was to be able to put them in the TXL you can refrain from doing this. When
defining the Live/Base locations, you can indicate whether or not the elements
of a particular location (read Directory) can be included into the TXL. You're
not restricted to OA$DO, OA$BLP and OA$SCP any longer.
Ciao,
Simon
|
| 1136.5 | What areas should be defined? | LARVAE::PATON_S | It's not easy having a good time! | Mon Aug 03 1992 12:15 | 11 |
| I'm finding this whole topic a little confusing!
How does one decide what areas to create?
I have a very simple application that I wish to put into CM, is there a
way of separating the user code and the manager code using CM?
The questions may sem obvious, but the examples in the guides are just
that little bit not specific enough.
Thanks
|
| 1136.6 | Some thoughts | CESARE::EIJS | All in 1 Piece | Tue Aug 04 1992 09:51 | 57 |
|
Hi,
> How does one decide what areas to create?
There are probably a number of ways to approach this.
First thing: it is definitely not necessary to create Applications and
Application Area just because you're able to do so now. If you come
from V2.* and you're happy the way CM works withing the ENGLISH/<nay
other language>/SHARE areas then stay with it.
If you decide to keep on working with the OA application then keep the
following few things in mind:
1) If possible, use unique type of element names to seperate your
'application' elements
2) Use the 'Application' field (in the 'Update element details' form) to
indicate to which 'application' the element belongs (read this as
'application' within the OA application)
3) You're not the Original Engineer of the OA application, so you cannot
move elements to Base
Another reason for not creating a new Appllication could be if most of
your application elements are modifications of the OA Base elements.
Another could be if the application consist of a relatively low
number of elements. The 'overhead' of a seperate application (+ areas)
might not be worth it.
(Now don't think I'm not in favor of seperate application... ;-))
The new Application structure can be used to create an environment
equal to, but completely seperated from the OA applicationn (I know, a
very short description).
Referring to your situation.
In case it's relatively simple, but a seperation between User and
Manager is needed, refer to the 3 points stated above.
In case you want complete seperation of your elements you can decide to
create an Application with one Area. The seperation between
User/Manager files can be done via naming conventions and the
'Application field value' as described in 2). Modifications to OA
elements can be done by copying them to your new Application Area.
In case you want a further seperation, you can create a seperate
Application area for User and Manager elements. This might come of use
if e.g. both User and Manager use some forms or procedures which are
the same in name, but differ in contents (just because a Manager might
be able to do more than a user). Just an example.
This explanation is not complete, but I hope it gives an idea.
Ciao,
Simon
|
| 1136.7 | more questions | BERN01::MAURERF | Isn't your mouse looking for cheese? | Mon Aug 24 1992 14:57 | 19 |
| Well, I'm still on the dark smog of CM+ but I hope the sun will raise
soon.
I tried the steps described and everythings went ok, except point 7. As
soon as I want to move to base(MBA), ALL-IN-1 knows only two site locations.
I already defined the authorized locations and don't see what is
missing? (dir/logicals are ok too)
I have one more question about CM+. I'd like to develop a multilanguage
application. So I would create an application (AM C) and at least two
different application areas ( CA area code: share/english/etc...).
Then I would have to define search lists that would set logicals like
in a1v30start.com, so that users would get elements from the
appropriate language, is it right?
Any advise would be appreciated.
Felix
|
| 1136.8 | correct area? | IOSG::BILSBOROUGH | Just testing. Please ignore!!! | Mon Aug 24 1992 15:25 | 10 |
|
Felix,
Have you defined the authorized locations for the file types that your
trying to move to base?
Are you sure that the elements that you are moving are created in the
correct area?
Mike
|
| 1136.9 | Some more infos | BERN01::MAURERF | Isn't your mouse looking for cheese? | Mon Aug 24 1992 16:06 | 40 |
| Mike,
All the elements I need are actualy in [allin1.site.dev_tmw_german],
before I used RV, they were in [allin1.site.dev_rec_tmw_german...]
according to their element type. The authorize location seems to be ok,
it is defined as follow:
Change Authorized Location
Area: TMW_GERMAN
Type: BLPW
Site Location: TMW$SITE_BLP_TMW_GERMAN:
Base Location: TMW$BLP_TMW_GERMAN:
Description: Default TXL directory for BLPW elements
Open: Y
Txl: Y Txl Type: BLP
Languages:
Protection proc.: OA$LIB:CM_SET_PROT
Site Translation: A1DISK:[ALLIN1.SITE.BLP_TMW_GERMAN]
Base Translation: A1DISK:[ALLIN1.BLP_TMW_GERMAN]
This is of course an entry for one element type, other entries are
similar. But if I use option VA (View an application area), then it
just shows site location:
Element type: BLP
Location: TMW$SITE_BLP_TMW_GERMAN:
Description: Default TXL directory for BLP elements
Open: Y
Location: TMW$SITE_LIB_TMW_GERMAN:
Description: Default directory for BLP elements
Open: Y
Is this correct?
Felix
|
| 1136.10 | other locations | IOSG::BILSBOROUGH | Just testing. Please ignore!!! | Mon Aug 24 1992 16:23 | 11 |
|
No,
The other authorised locations for your application should appear also.
Can you show me the other locations just so I can be sure that there
isn't something unusual going on.
Ta
Mike
|
| 1136.11 | Is this a bug? | BERN01::MAURERF | Isn't your mouse looking for cheese? | Tue Aug 25 1992 10:35 | 30 |
| By tracing ALL-IN-1 flow, I found that MBA is calling script
cm_move_to_base.scp, which in turn call form cm$get$liveloc and the ND
are as follow:
Form: CM$GET$LIVELOC
Library: A1DISK:[ALLIN1.LIB_GERMAN]CM.FLB;
-------------------------------------------------------------------------------
;;.TYPE;;
ARG/OVERLAY/HARD=CM$_SELECT_LIVE
/PRE='GET OA$DISPLAY=""\GET DISPLAY = #CM_INDEX_DISPLAY'
;;LOCATION;;
/HARD=CM$_GEN_LIVE_LOC
/RSE_VALID = CM$AUTH$LOCATIONS WITH .AREA == #CM_LANGUAGE
AND .TYPE == #CM_TYPE AND .LOCATION == LOCATION
AND .OPEN == CM$_Y
/RSE_RECOG = CM$AUTH$LOCATIONS WITH .AREA == #CM_LANGUAGE
AND .TYPE == #CM_TYPE AND .LOCATION = LOCATION
AND .OPEN == CM$_Y;
GET LOCATION = CM$AUTH$LOCATIONS.LOCATION[OA$SEL_KEY]/AUTO
/SHOW = '.LOCATION " " .DESCRIPTION'
.Location always point to site location, .base_location would be the
real base location. Is this problem only on german versions or do I
miss somthing?
Felix
|
| 1136.12 | Same in all languages so maybe | AIMTEC::WICKS_A | It wasn't supposed to end this way | Tue Aug 25 1992 20:34 | 10 |
| Felix,
Apart from a /PUT_SAVE = #CM_LIVE_LOC which I think you probably just
missed when you wrote the note the named data is the same on the US
version. Named Data is almost always language independent and isn't
translated - the screen image is.
Regards,
Andrew.D.Wicks
|
| 1136.13 | More ... | AIMTEC::WICKS_A | It wasn't supposed to end this way | Tue Aug 25 1992 21:00 | 15 |
| Two things I forget to add...
1) Mike is mistaken in .10 as VA doesn't ever show you the base
locations it only shows you the live locations. AM MAL select the
element and GOLD V is the only way I know to see both live and base
on the same screen.
2) MBA actually does work for me, I am on a machine where I created
the application whereas you are trying to import the elements
and then say that you are the OEG - I wonder if that makes a
difference.
Regards,
Andrew.D.Wicks
|
| 1136.14 | Base is determined from site | FAILTE::LAAHS | An accumulation of Celts | Wed Aug 26 1992 11:08 | 25 |
| I actually wrote this yesterday but had problems entering it due to
network to IOSG:-
Felix,
In answer to your question about how many areas to create for a
multi-lingual application - yes! You are correct.
As to your other problem. CM+ always determines a base location from
the corresponding site location. Therefore the named data is correct
for CM$GET$LIVELOC since you will specify the site location and the
code will find the base location.
Therefore when moving to base CM+ needs to know the site location. If
the element is already live then teh site location will already be
known. If the element is not live then CM+ prompts you as to what the
site location should be.
I hope this answers your query? (PS If not could you try an MLA and see
what live site locations you are offered?)
Kevin
|
| 1136.15 | just being confused | BERN01::MAURERF | Isn't your mouse looking for cheese? | Wed Aug 26 1992 11:53 | 8 |
| I'm sorry for the confusion, I was not understanding why ALL-IN-1 was
giving me live location as valid location as I was trying to move to
base. Except this, MBA works fine as PME MB pick up the right location in
cm$auth$locations.
Thanks all for patience and help.
Felix
|
| 1136.16 | You can also create an application specific startup | HLDG00::BROUWER | Max Brouwer DTN 838-3043 | Tue Sep 01 1992 11:46 | 21 |
|
Fritz,
The logical search list(s) can also be defined from the procedure which
you specified as the 'Startup' procedure when you created the
Application (MA C). By default the application specific startup
procedure is CM_DEFINE_APPLICATION_LOG.SCP, but because you want
something more done than this procedure does by default, you can create
your own one (with CM_DEFINE_APPLICATION_LOG as template) which
includes the definition of you logical search lists.
This procedure runs everytime ALL-IN-1 is started.
But then, A1V30_SITE_START.COM is OK also.
Ciao,
Simon
PS Working from Max Brouwers' account
|
| 1136.17 | Having fun with CM+ | BERN01::MAURERF | Isn't your mouse looking for cheese? | Wed Sep 09 1992 10:52 | 484 |
| Hi all,
As Simon suggested, I have created a procedure to define logicals for
a multilanguages application. This was not too difficult as I used
parts of A1V30START.COM. This procedure is able to findout which
languages are installed in your system, and it sets dynamics logicals,
so that users get right language elements. This procedure can be used
as follow in A1V30_SITE_START.COM:
$!----------------------------------------------------------------------!
$! Setting up for XYZ
$ @oa$build:a1_application_startup.com a1disk:[allin1.data_share] XYZ
$!----------------------------------------------------------------------!
The first parameter is the A1CONFIG.DAT location and the second one is
your application name. There is one rectriction at the moment, the base
location and the site location of your separate application should be
the same as ALL-IN-1 itself. There is maybe some suggestions on the net
to this.
Felix
$!------------------------------------------------------------------------
$! Filename : a1_application_startup.com
$! Author : F.Maurer - DEC
$! Creation : 28-aug-92
$!
$! Purpose : Application Startup procedure for ALL-IN-1
$! V3.0 to setup multilanguages logicals
$!
$!
$!
$! Prerequesits : - P1 should indicate A1CONFIG.DAT location
$! - P2 should be your application name.
$! - application location must be created
$! under ALL-IN-1 route ([allin1...] as
$! this command procedure read A1CONFIG
$! records.
$!======================================================================
$! The following symbol is very important as it is the key
$! of successfully defined logicals
$!
$ an = "TMW" !!!Application name default
$ if P2 .nes. "" then an = P2
$!----------------------------------------------------------------------
$ set noon
$ on control_y then goto CLEAN_UP
$ install = "$install /command_mode"
$ say = "write sys$output"
$ first_time = 0
$ define = "define"
$ done_deflanguage = 0
$ if f$trnlnm("OA$LIB_share") .eqs. "" then first_time = 1
$! if "''a1$kipostinstall'" .eqs. "" then A1$kipostinstall = 0
$CHECK_PRIV:
$ prvstr = "''f$getjpi("","PROCPRIV")'"
$ IF 'f$locate("SYSNAM",prvstr) .eqs. 'f$length(prvstr) THEN -
goto NO_SYSNAM
$
$ say ""
$ say " Starting ''an'"
$ if P1 .eqs. "" then gosub NO_P1
$ gosub DEFINE_FIELDS
$
$!+++
$! Open A1CONFIG.DAT and read the first record.
$! This will describe the BASE component
$!---
$ if "''f$trnlnm("A1CONFIG")'" .nes. "" then close a1config
$ open /read /error = NO_FILE /share=write a1config 'P1'A1CONFIG.DAT
$ read /end = LANGUAGES_DONE /nolock a1config base_record
$
$!+++
$! Test the KEY to see if this CONFIG file is OK
$!---
$ key = "''f$extract(language, language_len, base_record)'"
$ key = "''f$edit(key, "TRIM,UPCASE")'"
$ if key .eqs. "A1BASE" then goto READ_FIELDS
$ say ""
$ say "The file A1CONFIG.DAT appears to contain incorrect information"
$ say "Please rectify the problem, and then run this procedure again"
$ say ""
$ goto CLEAN_UP
$
$READ_FIELDS:
$ file_loc = "''f$extract(fileloc, fileloc_len, base_record)'"
$ file_loc = "''f$edit(file_loc, "TRIM,UPCASE")'"
$ data_loc = "''f$extract(dataloc, dataloc_len, base_record)'"
$ data_loc = "''f$edit(data_loc, "TRIM,UPCASE")'"
$ site_loc = "''f$extract(siteloc, siteloc_len, base_record)'"
$ site_loc = "''f$edit(site_loc, "TRIM,UPCASE")'"
$ sdata_loc = "''f$extract(sitedata, sitedata_len, base_record)'"
$ sdata_loc = "''f$edit(sdata_loc, "TRIM,UPCASE")'"
$ a1prefix = "''f$extract(prefix, prefix_len, base_record)'"
$ a1prefix = "''f$edit(a1prefix, "TRIM, UPCASE")'"
$
$ oa$lib_share = "''file_loc'" - "]" + ".LIB_share]"
$ table = "lnm$system_table"
$!
$ if a1prefix .eqs. "OA$" then goto DEFINE_FIXED_LOGICALS
$
$ set noon
$ set nocontrol=y
$ old_messages = f$enviroment("MESSAGE")
$ set message /noid /nosev /nofac /notext
$ create/name_table -
/executive_mode -
/parent_table = LNM$SYSTEM_DIRECTORY -
/protection = W:RE -
'a1prefix'SHARE_TABLE
$ set message 'old_messages'
$ set control=y
$ set on
$
$DEFINE_FIXED_LOGICALS:
$ say " Defining language independent logical names"
$!
$!+
$!+++
$! Define "fixed" logical names -- same for all systems
$!---
$ dsnt = "define /exec /nolog /table=''table'"
$ dsnt 'an'$site_lib 'an'$site_lib_'an'_llv, -
'an'$site_lib_'an'_share
$
$ dsnt 'an'$lib 'an'$site_lib_'an'_llv, -
'an'$site_lib_'an'_share, -
'an'$lib_'an'_llv, -
'an'$lib_'an'_share
$
$ dsnt 'an'$data 'an'$site_data_'an'_share, -
'an'$site_data_'an'_llv, -
'an'$data_'an'_share, -
'an'$data_'an'_llv
$
$ dsnt 'an'$do 'an'$site_do_'an'_llv, -
'an'$site_do_'an'_share, -
'an'$do_'an'_llv, -
'an'$do_'an'_share
$
$ dsnt 'an'$blp 'an'$site_blp_'an'_llv, -
'an'$site_blp_'an'_share, -
'an'$blp_'an'_llv, -
'an'$blp_'an'_share
$
$ dsnt 'an'$scp 'an'$site_scp_'an'_llv, -
'an'$site_scp_'an'_share, -
'an'$scp_'an'_llv, -
'an'$scp_'an'_share
$
$ dsnt 'an'$build 'an'$site_build_'an'_llv, -
'an'$site_build_'an'_share, -
'an'$build_'an'_llv, -
'an'$build_'an'_share
$
$ dsnt 'an'$site_data 'an'$site_data_'an'_llv, -
'an'$site_data_'an'_share
$
$!+++
$! Define *_share logicals using information in A1CONFIG.DAT
$!---
$ an$lib_an_share = "''file_loc'" - "]" + ".LIB_''an'_share]"
$ an$data_an_share = "''data_loc'" - "]" + ".DATA_''an'_share]"
$ an$do_an_share = "''file_loc'" - "]" + ".DO_''an'_share]"
$ an$blp_an_share = "''file_loc'" - "]" + ".BLP_''an'_share]"
$ an$scp_an_share = "''file_loc'" - "]" + ".SCP_''an'_share]"
$ an$build_an_share = "''file_loc'" - "]" + ".SOURCES_''an'_share]"
$ an$slib_an_share = "''site_loc'" - "]" + ".LIB_''an'_share]"
$ an$sdata_an_share = "''sdata_loc'" - "]" + ".DATA_''an'_share]"
$ an$sdo_an_share = "''site_loc'" - "]" + ".DO_''an'_share]"
$ an$sblp_an_share = "''site_loc'" - "]" + ".BLP_''an'_share]"
$ an$sscp_an_share = "''site_loc'" - "]" + ".SCP_''an'_share]"
$ an$sbld_an_share = "''site_loc'" - "]" + ".SOURCES_''an'_share]"
$ an$sdev_an_share = "''site_loc'" - "]" + ".DEV_''an'_share]"
$ an$sdev_rec_an_share = "''site_loc'" - "]" + ".DEV_REC_''an'_share]"
$!
$DEFINE_MAIN_LOGICALS:
$!+++
$! Define main ALL-IN-1 logicals
$!---
$ dsnt 'an'$lib_'an'_share 'an$lib_an_share'
$ dsnt 'an'$data_'an'_share 'an$data_an_share'
$ dsnt 'an'$do_'an'_share 'an$do_an_share'
$ dsnt 'an'$blp_'an'_share 'an$blp_an_share'
$ dsnt 'an'$scp_'an'_share 'an$scp_an_share'
$ dsnt 'an'$build_'an'_share 'an$build_an_share'
$
$DEFINE_SITE_LOGICALS:
$!+++
$! Next the SITE logicals
$!---
$ dsnt oa$site_dev_'an'_share 'an$sdev_an_share'
$ dsnt oa$site_dev_rec_'an'_share 'an$sdev_rec_an_share'
$ dsnt 'an'$site_lib_'an'_share 'an$slib_an_share'
$ dsnt 'an'$site_data_'an'_share 'an$sdata_an_share'
$ dsnt 'an'$site_do_'an'_share 'an$sdo_an_share'
$ dsnt 'an'$site_blp_'an'_share 'an$sblp_an_share'
$ dsnt 'an'$site_scp_'an'_share 'an$sscp_an_share'
$ dsnt 'an'$site_build_'an'_share 'an$sbld_an_share'
$!+++
$! All BASE logicals now defined.
$!---
$DEFINE_LANGUAGE_LOGICALS:
$!+++
$! Read language records from A1CONFIG.DAT and and define
$! LANGUAGE logicals for each installed language.
$!---
$ read /end_of_file = LANGUAGES_DONE /nolock a1config language_record
$ language = "''f$extract(language, language_len, language_record)'"
$ language = "''f$edit(language, "TRIM,UPCASE")'"
$ if language .eqs. "A1COUNTRY" .or. language .eqs. "A1BASE" then -
goto DEFINE_LANGUAGE_LOGICALS
$ file_loc = "''f$extract(fileloc, fileloc_len, language_record)'"
$ file_loc = "''f$edit(file_loc, "TRIM,UPCASE")'"
$ data_loc = "''f$extract(dataloc, dataloc_len, language_record)'"
$ data_loc = "''f$edit(data_loc, "TRIM,UPCASE")'"
$ site_loc = "''f$extract(siteloc, siteloc_len, language_record)'"
$ site_loc = "''f$edit(site_loc, "TRIM,UPCASE")'"
$ sdata_loc= "''f$extract(sitedata, sitedata_len, language_record)'"
$ sdata_loc= "''f$edit(sdata_loc, "TRIM,UPCASE")'"
$ deflanguage= "''f$extract(deflang, deflang_len, language_record)'"
$!+++
$! The following test is to make sure we process the default language first.
$! So that logical search lists that contain default language LLV logicals will
$! be complete. CJT-H.
$!---
$ if (.not. done_deflanguage) .and. (deflanguage .eqs. "N")
$ then
$ goto DEFINE_LANGUAGE_LOGICALS
$ else
$ if done_deflanguage .and. (deflanguage .eqs. "Y") then -
goto DEFINE_LANGUAGE_LOGICALS
$ if .not. done_deflanguage
$ then
$ close a1config
$ open /read /error = NO_FILE /share=write a1config 'P1'A1CONFIG.DAT
$ endif
$ done_deflanguage = 1
$ endif
$!
$ say " Defining ''language' language logical names"
$!
$ an$lib_an_llv = "''file_loc'" - "]" + ".LIB_''an'_''language']"
$ an$data_an_llv= "''data_loc'" - "]" + ".DATA_''an'_''language']"
$ an$do_an_llv = "''file_loc'" - "]" + ".DO_''an'_''language']"
$ an$blp_an_llv = "''file_loc'" - "]" + ".BLP_''an'_''language']"
$ an$scp_an_llv = "''file_loc'" - "]" + ".SCP_''an'_''language']"
$ an$build_an_llv= "''file_loc'" - "]" + ".SOURCES_''an'_''language']"
$ an$llv = "''file_loc'" - "]" + ".SOURCES_''an'_''language']"
$
$ an$slib_an_llv= "''site_loc'" - "]" + ".LIB_''an'_''language']"
$ an$sdata_an_llv= "''sdata_loc'" - "]" + ".DATA_''an'_''language']"
$ an$sblp_an_llv= "''site_loc'" - "]" + ".BLP_''an'_''language']"
$ an$sscp_an_llv= "''site_loc'" - "]" + ".SCP_''an'_''language']"
$ an$sbld_an_llv= "''site_loc'" - "]" + ".SOURCES_''an'_''language']"
$ an$sdev_an_llv= "''site_loc'" - "]" + ".DEV_''an'_''language']"
$ an$sdev_rec_an_llv= "''site_loc'" - "]" + ".DEV_REC_''an'_''language']"
$
$ set noon
$ set nocontrol=y
$ old_messages = f$enviroment("MESSAGE")
$ set message /nofac /nosev /noid /notext
$ create/name_table -
/NOLOG -
/executive_mode -
/parent_table = LNM$SYSTEM_DIRECTORY -
/protection = W:RE -
'a1prefix''language'_TABLE
$!Define symbol that holds this name - to be used as a parameter for
$!script symbiont start procedure
$ language_table = "''a1prefix'''language'_table"
$ set message 'old_messages'
$ set control=y
$ set on
$
$ dsnta = "define /exec /nolog /table=''a1prefix'''language'_table"
$ dsnta 'an'$lib_'an'_llv 'an$lib_an_llv'
$ dsnta 'an'$data_'an'_llv 'an$data_an_llv'
$ dsnta 'an'$do_'an'_llv 'an$do_an_llv'
$ dsnta 'an'$blp_'an'_llv 'an$blp_an_llv'
$ dsnta 'an'$scp_'an'_llv 'an$scp_an_llv'
$ dsnta 'an'$build_'an'_llv 'an$build_an_llv'
$ dsnta 'an'$llv 'an$llv'
$ dsnta 'an'$site_lib_'an'_llv 'an$slib_an_llv'
$ dsnta 'an'$site_data_'an'_llv 'an$sdata_an_llv'
$ dsnta 'an'$site_blp_'an'_llv 'an$sblp_an_llv'
$ dsnta 'an'$site_scp_'an'_llv 'an$sscp_an_llv'
$ dsnta 'an'$site_build_'an'_llv 'an$sbld_an_llv'
$
$!+++
$! All language logicals now defined in their own table.
$! Now define some language logicals in the MAIN table -- for SCM
$!---
$DEFINE_SCM_LOGICALS:
$
$ dsnt oa$site_dev_'an'_'language' 'an$sdev_an_llv'
$ dsnt oa$site_dev_rec_'an'_'language' 'an$sdev_rec_an_llv'
$ dsnt 'an'$blp_'language' 'an$blp_an_llv'
$ dsnt 'an'$scp_'language' 'an$scp_an_llv'
$ dsnt 'an'$build_'language' 'an$build_an_llv'
$ dsnt 'an'$site_lib_'language' 'an$slib_an_llv'
$ dsnt 'an'$site_blp_'language' 'an$sblp_an_llv'
$ dsnt 'an'$site_build_'language' 'an$sbld_an_llv'
$ dsnt 'an'$site_scp_'language' 'an$sscp_an_llv'
$!
$ if deflanguage .nes. "Y" then goto RUN_A1_INSTALL
$
$DEFINE_DEFAULT_LANGUAGE_LOGICALS:
$
$ dsnt 'an'$llv 'an$llv'
$ dsnt 'an'$lib_'an'_llv 'an$lib_an_llv'
$ dsnt 'an'$data_'an'_llv 'an$data_an_llv'
$ dsnt 'an'$blp_'an'_llv 'an$blp_an_llv
$ dsnt 'an'$scp_'an'_llv 'an$scp_an_llv'
$ dsnt 'an'$build_'an'_llv 'an$build_an_llv'
$ dsnt 'an'$site_lib_'an'_llv 'an$slib_an_llv'
$ dsnt 'an'$site_data_'an'_llv 'an$sdata_an_llv'
$ dsnt 'an'$site_blp_'an'_llv 'an$sblp_an_llv'
$ dsnt 'an'$site_scp_'an'_llv 'an$sscp_an_llv'
$ dsnt 'an'$site_build_'an'_llv 'an$sbld_an_llv'
$!
$RUN_A1_INSTALL:
$!+++
$! Run the image to INSTALL the language specific form libraries and TXL
$!---
$ say ""
$ say " Running ALL-IN-1 to install the ''an' - ''language' FORM LIBRARIES"
$ say ""
$!---
$ oaliblang = f$trnlnm("''an'$LIB_''an'_llv",language_table)
$ oasiteliblang = f$trnlnm("''an'$SITE_LIB_''an'_llv",language_table)
$ call check_library 'oaliblang''an'.flc
$ call check_library 'oasiteliblang'SITE'an'.FLC
$ goto do_install
$ CHECK_LIBRARY : SUBROUTINE
$ flcname = p1
$ if f$search("''flcname'") .eqs. ""
$ then
$ say " Compiled form library ''flcname' not found"
$ say " Continuing without installing ''flcname'"
$ endif
$ ENDSUBROUTINE
$!
$DO_INSTALL:
$ ALLIN1 /NOINIT /OVERRIDE /LANGUAGE = 'LANGUAGE'
OA$FBT_REMOVE_LIB 'ap'$LIB:'an'
OA$FBT_REMOVE_LIB 'ap'$LIB:site'an'
FOR FIRST OA$DIR_SEARCH:"''an'$LIB:'an'.FLC" DO OA$FBT_INSTALL_LIB 'an'$LIB:'an'
FOR FIRST OA$DIR_SEARCH:"''an'$LIB:site''an'.FLC" DO OA$FBT_INSTALL_LIB 'an'$LIB:SITE'an'
oa$TXL_INSTALL
oa$TXL_INSTALL CMTXL
$!
$!+++
$! Go back and do this again for the next language
$!---
$ goto DEFINE_LANGUAGE_LOGICALS
$
$LANGUAGES_DONE:
$!+++
$! EOF had been reached on A1CONFIG.DAT. All language records
$! have therefore been processed.
$! Make sure we can restart
$! We don't want to cancel the shutdown if housekeeping is running on another
$! node in this cluster, so test first.
$!---
$!
$!+++
$! Now clean up and leave
$!---
$CLEAN_UP:
$ set nocontrol_y
$ close a1config
$ set control_y
$ a1$kipostinstall == 0
$ say " ALL-IN-1 startup procedure completed"
$ exit
$
$NO_FILE:
$ say ""
$ say " A1CONFIG.DAT not found"
$ say ""
$ exit
$
$NO_SYSNAM:
$ say ""
$ say "You must have SYSNAM privilege to run the ''application_name' Startup"
$ say ""
$ exit
$!
$NO_P1:
$!+++
$! Begin subroutine NO_P1
$!---
$ read sys$command p1 -
/timeout = 30 -
/error = no_file_specified -
/prompt = "Enter the location of the file A1CONFIG.DAT> "
$RETURN
$!+++
$! End subroutine NO_P1
$!---
$NO_FILE_SPECIFIED:
$
$ say "No location for A1CONFIG.DAT was specified -- procedure will abort
$ say ""
$ say " **** ALL-IN-1 HAS NOT BEEN STARTED ****"
$ exit
$
$DEFINE_FIELDS:
$!+++
$! Subroutine to define field offsets in A1CONFIG.DAT records
$!---
$ language = 0
$ language_len = 16
$
$ version = 16
$ version_len = 3
$
$ rev = 19
$ rev_len = 5
$
$ fileloc = 24
$ fileloc_len = 50
$
$ dataloc = 74
$ dataloc_len = 50
$
$ siteloc = 124
$ siteloc_len = 50
$
$ sitedata = 174
$ sitedata_len = 50
$
$ mbxname = 224
$ mbxname_len = 12
$
$ numlang = 236
$ numlang_len = 2
$
$ date = 238
$ date_len = 11
$
$ translate = 249
$ translate_len = 1
$
$ mail = 250
$ mail_len = 1
$
$ rem$mr = 251
$ rem$mr_len = 1
$
$ mrnode = 252
$ mrnode_len = 6
$
$ dds$lev = 258
$ dds$lev_len = 1
$
$ wps = 259
$ wps_len = 1
$
$ deflang = 260
$ deflang_len = 1
$
$ prefix = 261
$ prefix_len = 4
$
$ lex = 265
$ lex_len = 15
$
$ vmsacc = 280
$ vmsacc_len = 23
$
$ mailqueue = 303
$ mailqueue_len = 20
$
$ mgrdir = 323
$ mgrdir_len = 50
$
$RETURN
$!+++
$! End subroutine DEFINE_FIELDS
$!---
$! END A1V30START.COM
|
| 1136.18 | more than one symbol file? | BERN01::MAURERF | Isn't your mouse looking for cheese? | Wed Sep 09 1992 11:19 | 8 |
| Can somebody tell me what append when installing 2 differents
applications on a system, if both applications have a literal symbol
file (for example site$oa.a1$msg). Will the first one be overwritten,
or does ALL-IN-1 merge both files?
Thanks for any answer.
Felix
|
| 1136.19 | Overwritten: Yes; Merged: No | IOSG::SCM | CM+ Development Team from Torino | Thu Sep 10 1992 13:05 | 46 |
|
Hi Fritz,
When an application is restored then elements will be overwritten, just
if you were installing ALL-IN-1. Base elements in case of restoring a
Base application. Development elements in case you're restoring a Site
application. No element is merged at the moment.
To answer your question: yes the element SITE$OA will be overwritten in
development, so you have to make sure that the 'old' SITE$OA is moved
to live before you restore the 'new' application (in case of a Site
application).
No merge is done. However, if CMS is available, you can use the Merge
utility to do so:
1) Modify your CM profil to:
'Pre-install merge': N 'Element in CM:' N
2) Move the old SITE$OA to Live
3) Restore the 'new' application
4) Select the SITE$OA on the CM menu
5) Use option MBE (Merge with Base element)
6) CM will ask you for the VMS file: select the Live file:
OA$SITE_BUILD_<language>:SITE$OA.A1$MSG
7) CM will merge the differences between the Base element (original)
and the Live element (New element) into the element under development.
This might be a conflict, but as the messages are new anyway you
could deletre the bConflict remarks and that's it.
Another way to to run Differences between the Base element and Any file
(OA$SITE_BUILD_<language>:SITE$OA.A1$MSG) and file the changes. Then
edit the 'new' SITE$OA in development and include the saved differences
yourself.
You'll see, a merge is more than just a merge, definitely automatic
merges.
HTH,
Simon
|