| Andy,
Until Tony or Simon stop by here's some quick answers
1) I've already QAR'd this - the workaround is of course to add it
by hand.
2) You're right
3) don't know
4) You do still have the element that's in "Move Pending" current
don't you - if you have some other element that's in Deleted or
or Locked etc you'll see a message like the one you see.
5) This is the way it was designed.
There's one subdirectory for each STANDARD element type defined
in CM$ETYPES.
I do agree that the documentatio surrounding Applications and Areas in
the Management Guide is extremely concise (i'm being polite here!)
- I believe that there will be some info update articles coming on this.
Also element types isn't documented at all.
6) DAL only defines the ones it needs to - if you just see a "checking"
message then it means that the one it's looking at has already been
defined.
7) Yes it is magic! Look at a DO script called CM_DEFINE_DEV_LOGS
which is called from A1V30START.COM
There that's a start until the real CM+ experts check in.
Regards,
Andrew.D.wicks
|
| Regarding question 3, I believe the problem is that the
information on the .FILE Named Data line does not use the
file search order. This means that GUITARIST.FDL must exist
in whatever directory is you current default directory (usually
OAUSER, but not always). The safest thing to do with .FDLs
in a .FILE line is to use an explicit directory location.
Then you will need to create your .FDL file, move it to live
and THEN do a CFI to create a file for your current entry form.
_Mike
|
| Note 399.0 V3.0 CM questions 2 replies
42052::JOYCE "DCL dinosaurs on demand..." 69 lines 2-APR-1992 15:36
--------------------------------------------------------------------------------
> I'm just starting my sweaty fumblings with V3.0 CM and I've got a
> couple of questions...
Great! But can you stop sweating in case your output renders the
keyboard unusable for others?
> 1)From MANAGER I made another user an application maintainer (using
> the MAP option on the AM screen). The user was not granted the
> OA$MANAPP rights id. Why? (fwiw: I think the user was already an
> authorised programmer for the OA area)
Make users maintainers by setting the PRVAPP flag in profile. We'll fix
the bug that you (and Andrew) have noted in a PFR.
>2) If PRVAPP is "A" does that make a user an application maintainer
>for ALL areas? I guess not - they also need to be authorised using the
>MAP option foe each application area - but can someone confirm this?
No, the phantom data set *CMREADAREAS defines the areas you have access
to. If you can't access an area you can't act as a maintainer. But once
you are added to the list of authorized programmers (MAP option) you
can be allocated maintainer status. Note that the OA$MANAPP identifier,
which is what you get when PRVAPP is set in the profile, only allows
you access to some files. CM+ imposes its own checking against the
maintainer flag in CM$AUTH$USERS to stop you taking maintainer options
for an area if you don't have the privilege.
> 3) I created an ENTRY form with a segmented key. The named data looked
> a bit like this...
;;.TYPE;;
ENTRY/MODE=UPDATE/KEY=SNAME,FNAME
;;.FILE;;
OAUSER:GUITARIST.DAT,GUITARIST.FDL
> As I had set up the Element Search Order to include the GUIT_MAIN
> application area development directory, I assumed that ALL-IN-1 would
> find the FDL (which I had created using CM) there. I tried using the
> CFI option and it failed with a something like "Error !AS - couldn't
> open file". I checked that my CM search order include this development
> area - it did. I eventually gave up and changed to .FILE nd to
;;.FILE;;
OAUSER:GUITARIST.DAT,OA$SITE_DEV_GUIT_MAIN:GUITARIST.FDL
> and then CFI creates the file ok. BUT this means I'll have to edit the
> nd again before I make the thing live.
> I assume (and I haven't checked it out yet) that when the application
> is made live I would have set up an ESO element and done
> whatever else I have to do to set the serach order when the user runs
> the application.
OK. Two questions here. The first depends on whether or not the FDL was
in the search order and could be found. Where was the element located?
Was this directory in your current search order? For example, if the
element was still in the development area (i.e. hadn't yet been made
live), then you must have OA$SITE_DEV_GUIT_MAIN in your search order to
be able to locate it. I prefer to get the FDL right and move it into
the live location and then use an explict reference in named data to
access it there. i.e.
;;FILE;;
OAUSER:GUITARIST.DAT, GUIT$LIB_SHARE:GUITARIST.FDL
The second question revolves around application initialization. If you
create a new application area then you need to ensure that users can
access all the code contained therein when the application starts up.
Take a look at CM_INIT_ENVIRONMENT.SCP to see how CM manipulates
element search orders. You could also directly change the contents of
OA$FORM_SEARCH_ORDER and OA$FILE_SEARCH_ORDER by parsing them out and
inserting your form libraries/directories in the right place. You might
look at CM_FILE_ORDER.SCP and CM_FORM_ORDER.SCP to see how we play
around with search orders.
> Am I on the wrong track here? Does the CFI option use the element
> search order to look for an FDL?
Yes. The CFI option (just like the rest of ALL-IN-1) looks in your
search list to locate an element that is not referenced through a
logical name or directory specification.
> 4) As a programmer I "MLA"ed some elements. I then thought I'd try the
> Notify Maintainer option (NM). It said something like "No current
> message". I was under the impression that a message would be generated
> automatically?
I have just tried this and it works. Did the element (in the CM CWB)
have a "Move Pending" status.
>5) Can anyone give a consise explanation as to why, when I create an
>application area (SM CSZ MA CA) I get an unbelievably complex directory
>structure created? It seems to create a sub-dir for every element type
>(about 20 I think at last count) under this "received" area which I'm
>not sure of the use off, even after reading the documentation.
You get the structure to allow CM to work properly, including the
receive and transfer options which require directories for each element
type that might be transferred in an application.
> 6) I used the DAL (define application logicals) option and it seemed
> to go through all the authorised areas "Checking...". Only for some of
> these did it define a system logical name. Why?
Because we only define the minimum set of logical names to get the
application working under CM+. That means the development and receive
areas. It's up to you to define the other locations, normally during
startup. We do define a set of default authorized locations for you,
but you may want to change these (change disk locations etc.) before
you actually make the application live. That's why they aren't defined
initially.
> 7) Where is the Startup field in CM$APP used? Is there some magic
> worked by A1v30start to startup all the applications in CM$APP?
Yes, the magic is performed by CM_DEFINE_APPLICATION_LOG.SCP, which, if
set in your CM$APP record for the application, will read down through
the list of authorized locations for the application and define system
logical names for them all. This is how you can define the full set of
logicals (re above) if you want. A point to note is that logical search
lists are not defined here, so if you want to use search lists (for
example, like OA$LIB) in your application, you have to define them in
your own version of CM_DEFINE_APPLICATION_LOG.SCP. One way to do this
is to create a script that:
- Calls CM_DEFINE_APPLICATION_LOG.SCP to create the default set of
logical names
- Then makes any other changes felt necessary, such as the definition
of search lists or logicals not registered in the authorized
locations data set.
> Thanks in advance for any help.
You are welcome.
Tony
Andy
|
|
Hi Andy,
To elaborate to what Tony replied...
>>2) If PRVAPP is "A" does that make a user an application maintainer
>>for ALL areas? I guess not - they also need to be authorised using the
>>MAP option foe each application area - but can someone confirm this?
>
>No, the phantom data set *CMREADAREAS defines the areas you have access
>to. If you can't access an area you can't act as a maintainer. But once
>you are added to the list of authorized programmers (MAP option) you
>can be allocated maintainer status. Note that the OA$MANAPP identifier,
>which is what you get when PRVAPP is set in the profile, only allows
>you access to some files. CM+ imposes its own checking against the
>maintainer flag in CM$AUTH$USERS to stop you taking maintainer options
>for an area if you don't have the privilege.
The phantom *CMREADAREAS is used by a Programmer to pre-define the application
areas to which he/she has at least Read access to. The phantom *CMMANAGEAREAS
defines the areas you Maintain. Tony refers to this phantom when he says: 'CM+
imposes its own checking against the maintainer flag in CM$AUTH$USERS...'
In short: the ALL-IN-1 Manager should define an account as an Maintainer in
general. Then, the account becomes a Maintainer of an application area via the
MAP option.
>> 3) I created an ENTRY form with a segmented key. The named data looked
>> a bit like this...
>> .
>> .
>> Am I on the wrong track here? Does the CFI option use the element
>> search order to look for an FDL?
>
>Yes. The CFI option (just like the rest of ALL-IN-1) looks in your
>search list to locate an element that is not referenced through a
>logical name or directory specification.
Like Ben I have to disagree here. An FDL specification in the .FILE directive
without a directory specification doesn't get picked up during either '<CREATE
<form> ' or option CFI on the CM menu (which basically does the same), unless
the FDL is in the OAUSER directory or the FDL is in the directory which has
been set via '<SET_DEFAULT xxx'. The CREATE function doesn't take the
OA$FILE_SEARCH_ORDER into account.
>> 4) As a programmer I "MLA"ed some elements. I then thought I'd try the
>> Notify Maintainer option (NM). It said something like "No current
>> message". I was under the impression that a message would be generated
>> automatically?
>
>I have just tried this and it works. Did the element (in the CM CWB)
>have a "Move Pending" status.
I'm looking into this. It has to do with the current drawer.
>>5) Can anyone give a consise explanation as to why, when I create an
>>application area (SM CSZ MA CA) I get an unbelievably complex directory
>>structure created? It seems to create a sub-dir for every element type
>>(about 20 I think at last count) under this "received" area which I'm
>>not sure of the use off, even after reading the documentation.
>
>You get the structure to allow CM to work properly, including the
>receive and transfer options which require directories for each element
>type that might be transferred in an application.
I don't thing it is 'unbelievably complex' as all what is done is the creation
of a directory per element type. In short, when e.g. you receive elements from
VMS (option on the Maintainer menu) CM will loop through the Receive area(s)
and the underlying 'element type' directories (depending on the search
criteria) and then calculates to which application area the element belongs and
of which element type the element is. That's only one of the possibilities.
>> 6) I used the DAL (define application logicals) option and it seemed
>> to go through all the authorised areas "Checking...". Only for some of
>> these did it define a system logical name. Why?
>
>Because we only define the minimum set of logical names to get the
>application working under CM+. That means the development and receive
>areas. It's up to you to define the other locations, normally during
>startup. We do define a set of default authorized locations for you,
>but you may want to change these (change disk locations etc.) before
>you actually make the application live. That's why they aren't defined
>initially.
Live (and Base) locations are specified per element type (and per application
area). A lot of element types will have the same live location (take
OA$SITE_LIB_SHARE:, it's almost looks like a garbage can (with respect)). As
DAL loops through CM$AUTH$LOCATIONS it might find a live location a number of
times, while it only has to be defined once. That's why you see more messages
checking if the logical exists than messages defining the logical.
Ciao,
Simon
|