| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 800.1 | Slight technical issue here | SIOG::T_REDMOND | Thoughts of an Idle Mind | Thu Jun 04 1992 09:25 | 13 |
| Screwed up system? (I know that's a technical term...)
But seriously, there should only be one copy of CM$SITELOG, and that
should be in OA$DATA_SHARE. The copy which you have in
OA$SITE_DATA_SHARE isn't supposed to be there, but as you can see from
the directory listing, it is getting a little more activity than the
correct version.
Was this system upgraded? Or a new installation? Or did someone move
a copy of the file into OA$DATA: and so pick up OA$SITE_DATA_SHARE
rather than the base directory?
Tony
|
| 800.2 | OA$DATA_SHARE <> OA$DATA | UTRTSC::BOSMAN | We're just sugar mice in the rain | Thu Jun 04 1992 11:00 | 11 |
| Hi,
Ok. Maybe I did it myself using CREATE CM$SITELOG. But if the file only
should reside in OA$DATA_SHARE, then why is the .FILE definition
containing OA$DATA:
;;.FILE;;
OA$DATA:CM$SITELOG.DAT,OA$LIB:CM$SITELOG.FDL
Regards, Sjaak.
|
| 800.3 | Architecturally (i.e. Weak excuse coming up :-) ) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Jun 04 1992 11:58 | 10 |
| It's a general rule that we alwasy specify .FILEs as OA$DATA, since
this gets all the other bits of OA$DATA in the search list.
If you specify OA$DATA_SHARE, that's the only directory you get, no
possibility of searching a version in a language or SITE directory
first.
Now admittedly that may not be likely in this case, but....
Graham
|
| 800.4 | Even weaker ... | UTRTSC::BOSMAN | We're just sugar mice in the rain | Fri Jun 05 1992 07:51 | 9 |
| Graham,
If it is a general rule, then it certainly only applies to ALL-IN-1
V3.0, because OA$DATA_SHARE *was* used in V2.4 for CM$SDC, CM$SITELOG
and CM$SITEHIST.
Just nit picking.
Sjaak.
|
| 800.5 | Well you know what those CM types are like... :-) | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Fri Jun 05 1992 10:40 | 0 |
| 800.6 | That's why CM is such fun... ;-) | CESARE::EIJS | All in 1 Piece | Tue Jun 09 1992 10:59 | 24 |
|
Sjaak,
> Well you know what those CM types are like... :-)
That's why we do CM, customizable and to be convinced very easy ;-).
Alle gekheid op een stokje. Although it is the way it's always been
done, the CREATE function would really be somewhat complicated if all
kinds of checks should be included to figure out whether or not to
create a dataset in the first directory of a search list, or ask, or...
CREATE Should stay as CREATE.
However, from your answers I can see a 'little' wish that e.g. the CFI
option on the CM menu might get customized to do so. It does a check
already to see if the form is an ENTRY form, it checks if the .FILE
directive is a Data Decide one, so why not check the directory
specification for a search list and if so, ask where to put it (some
neat Index form displaying the seperate entities of the search list).
Shouldn't be too difficult.
Ciao,
Simon
|
| 800.7 | CM: nice but/and BIG | UTRTSC::BOSMAN | We're just sugar mice in the rain | Tue Jun 09 1992 11:29 | 21 |
| Hoi Simon,
CM is fun, yeah. I ran into this problem when I wrote a KITINSTAL for
an ALL-IN-1 application. Because this application updates a few
ALL-IN-1 elements I want to update CM to reflect a proper situation.
For ALL-IN-1 V2.4 system all went ok. But V3.0, phew, gimme a break.
Maybe you could give some clues on CM$SITEHIST. At this moment I assume
that for a base language element I should update CM$SITEHIST.DAT in
OA$SITE_DEV_llv. But is this file initially on the system? Or do I have
to create it?
Another problem I ran into was a stack dump on a WRITE CHANGE
CM$SITELOG where I specified all the fields. A work-around was to
split-up the WRITE CHANGE to update 10 fields at the time.
At this moment I think everything works well (...)
Morgen, eindelijk is het dan zover ... EK '92 !
Sjaak.
|
| 800.8 | CM$SITEHIST.DAT created authomatically? Yes & No! | CESARE::EIJS | All in 1 Piece | Tue Jun 09 1992 16:21 | 83 |
|
Sjaak,
CM$SITEHIST.DAT is now 'split' and one version is available per
application area. Don't refer to OA$SITE_DEV_LLV:, but to
OA$SITE_DEV_<application area>:, as we don't know about search list
logicals any longer (OA$SITE_DEV and OA$SITE_DEV_LLV have been deleted
since V3.0).
The form CM$SITEHIST now contains a .FILE directive to logical
CM$SITEHIST. Check CM_ADD_HISTORY.SCP how it is done.
If your application is part of the OA application (and stored in one of
the SHARE, ENGLISH, GERMAN, etc. application areas), then copies of the
original CM_SITEHIST.DAT have been made to the several Development
areas under the name of CM$SITEHIST.DAT.
If your application allready used 'new application areas' under V2.*,
then some additional activities are needed to get the application
working with CM in V3.0 (new means e.g. TEST_SHARE):
- Finish record in CM$APP (Options CM MA E)
- Finish record in CM$MAF (Options CM MA EA)
- Define symbols:
<GET #CM_DEFAULT_LOCS = CM$_N
<GET #CM_ACTION_KNOWN = ""
<DO CM_INIT_APP_AREA
- Finish information for Authorized Live/Base locations
(Options CM AM MAL)
- Add the necessary LOCK records for the DEVELOP.FLB for your
application if you didn't do so yet
- Review the accounts which have access to the application area
(which after an upgrade installation is every account)
If your application is new to be installed, for the CM part take into
account the following data sets:
- CM$APP -> Definition of Application
- CM$MAF -> Definition of Application area
- CM$AUTH$LOCATIONS -> Valid Live/Base locations
- CM$AUTH$USERS -> At least one Maintainer
- CM$SDC$LOCATIONS -> Invalid Live locations
- CM$FORM$LIBS -> Lock records for form libraries
- CM$SITELOG -> 4 new fields compared to V2.*:
APPCODE, EXCEPTION, STORED, DELETED
- CM$SDC -> 6 new fields:
APPCODE, EXCEPTION, STORED, DELETED, DIFF_LOC, RECEIPT
- You need to create the Development yourself like in V2.*, with
the following additional 3 files:
CM$SITEHIST.DAT
DEVELOP.HLB
FORMATTED_DEVELOP.HLB
(Check the OA$SITE_DEV_SHARE:)
- (Optionally) You need to create a Receive area:
Logical OA$SITE_DEV_REC_<application area>:
Directory [<Siteroot>.DEV_REC_<application area>], owned
by OA$MANAPP
Sub-directories for every element type
DEVELOP.FLB, DEVELOP.HLB, FORMATTED_DEVELOP.HLB and
CM$SITEHIST.DAT
(Check OA$SITE_DEV_REC_SHARE: for protections and ACLs)
This is a 'very short' answer to your CM$SITEHIST.DAT question. This is
a very quick overview of things to think about when adding your
application to CM in V3.0. Probably the start of a number of replies
;-).
Ciao,
Simon.
PS Zet het bier maar koud!
|
| 800.9 | Will study tomorrow ... | UTRTSC::BOSMAN | We're just sugar mice in the rain | Tue Jun 09 1992 17:01 | 21 |
| Simon,
A number of replies. Maybe. If it clearifies the working of CM :-)
With OA$SITE_DEV_llv I meant that you read llv as "ENGLISH" or "SHARE",
but you corrected me the right way to better use OA$SITE_DEV_area.
It's 5 o'clock, so I'm gonna to read your reply tomorrow a little
better. For now, I saw the ACL's on the directories where CM$SITHIST
could reside (trail & error on creating new elements and customizing
base elements). And thought I don't have to worry about that one; if
VMSINSTAL moves the files to their target directories CM$SITEHIST
automatically receives the correct security.
My KITINSTAL DEFINEs CM$SITEHIST (as you described) and looks if
CM$SITEHIST.DAT exists, and if it doesn't it does CREATE CM$SITEHIST.
Right?
My application updates only BA and adds two new elements to SITEOAFORM.
Ciao, Sjaak.
|
| 800.10 | Not necessary! | CESARE::EIJS | All in 1 Piece | Tue Jun 09 1992 18:23 | 22 |
|
Sjaak,
> My KITINSTAL DEFINEs CM$SITEHIST (as you described) and looks if
> CM$SITEHIST.DAT exists, and if it doesn't it does CREATE CM$SITEHIST.
> Right?
Right!
Well..., on second thought...
Because your elements are part of the OA application, the
CM$SITEHIST.DAT MUST BE on the right place, else the installation
proceudre should have told you something went wrong. It doesn't hurt to
check, but it shouldn't be necessary as when CM$SITEHIST.DAT isn't
there, CM won't work correctly in the first place, irregardless your
application.
Ciao,
Simon
|
| 800.11 | Confused of Alpharetta writes | AIMTEC::WICKS_A | DEC Mail Works for ME sometimes | Wed Jun 10 1992 02:36 | 14 |
| Since Sjaak's application only updates BA and two forms he only has to
worry about the CM$SITEHIST in the ENGLISH (or DUTCH) development area
doesn't he? or am I missing something??
Sounds like he could do his application easier with Storing and
receiving the elements in CM rather than KITINSTAL? or is that likely
to set off another *short reply* from Simon?
And are all these replies in Dutch really about beer and football as
they appear to be?
regards,
Andrew.D.Wicks
|
| 800.12 | Wooden sticks etc. | UTRTSC::BOSMAN | We're just sugar mice in the rain | Wed Jun 10 1992 08:02 | 24 |
| Hi,
� Since Sjaak's application only updates BA and two forms he only has to
� worry about the CM$SITEHIST in the ENGLISH (or DUTCH) development area
� doesn't he? or am I missing something??
I've to worry about CM$SDC, CM$SITELOG and CM$SITEHIST in
OA$SITE_DEV_<language> and/or OA$SITE_DEV_SHARE. In whatever language
the user is running ALL-IN-1.
� Sounds like he could do his application easier with Storing and
� receiving the elements in CM rather than KITINSTAL? or is that likely
� to set off another *short reply* from Simon?
Do you also suggest that we install ALL-IN-1 via CM?
� And are all these replies in Dutch really about beer and football as
� they appear to be?
CBNC, Simon also talked about crazyness on a wooden stick :-):-)
Regards, Sjaak.
|
| 800.13 | P & R | CESARE::EIJS | All in 1 Piece | Wed Jun 10 1992 09:03 | 11 |
|
Sjaak,
If you're using V3.0 (although the Dutch version might take a while
before getting released) then indeed, as Andrew suggested, consider the
use of Package and Restore. Then you don't have to worry about CM$SDC,
CM$SITELOG and CM$SITEHIST as it will be taken care of.
Ciao,
Simon
|