| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hello,
We here use the DAP> DELETE CLASS <entity> to create
bigger dictionaries than the development one but
smaller than the system-wide one .
Our partners exactly have the same need as we have to
create those intermediate dictionaries (containing the iconic
map/Domain FM for example ...)
Will the command DELETE CLASS in the future versions be :
1- Documented, working ?
2- Undocumented working ?
3- Undocumented, not working ?
The last is of course the worst for us, so in case 3- would
something work to create such intermediate/customizable dictionaries ?.
Thanks for your help
Catherine
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 967.1 | DELETEing Dictionary information can be dangerous | TOOK::GUERTIN | I do this for a living -- really | Mon Apr 29 1991 10:53 | 15 |
Catherine,
We felt, after much back and forth discussion, that the DAP DELETE
CLASS command was too destructive to document. We were concerned at
fieldtest that customers (in particular end-users) could easily wipe
out a major portion of their dictionary. The DAP program has no error
recovery or confirm-delete capability. We knew that developers would
have a problem, however, we felt that the UPDATE command would be able
to provide the needed capabilities (in fact, it DELETEs and then
LOADs).
If you need information about future DAP functionality, please contact
the Project Leader for the MCC Toolkit team, Darryl Black (MKNME::BLACK).
-Matt.
| |||||
| 967.2 | one MSL developer's concerns, as sent to Darryl | COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Apr 29 1991 12:49 | 38 |
Darryl,
Hi, I wanted to respond to an issue raised in note 967 of the
MCC conference regarding support of the delete command.
I don't have an opinion as to whether DELETE CLASS
specifically should remain an accepted DAP command. But I do
have a concern that a specific capability be available. That
is the ability for an update job to "do the right thing" in
order to leave the dictionary in the proper state, without
knowing ahead of time what the current state is.
The desired state of the dictionary after the job runs is that
the dictionary have the current definitions loaded from the
.COM file produced by the MSL compiler. If LOAD and UPDATE
are the only DAP commands available, then the update job has
to know whether or not the class has ever been loaded into the
dictionary, so it knows which one to use. That is because LOAD
fails if the class already exists in the dictionary, and UPDATE
fails if it doesn't.
I currently have our update job use a DELETE in one DAP
invocation followed by a LOAD in another DAP invocation. The
job ignores the completion status of the DELETE invocation.
This sequence produces the desired result regardless of the
prior state of the dictionary. If you remove DELETE, is there
a way to have the update job do the right thing?
Perhaps you might modify UPDATE so it optionally deletes the
class if it is already there, but doesn't complain if it
isn't. That would give us the same capability, without
exposing DELETE CLASS to the user.
Thanks for considering this issue,
Richard Kittell
AIM Engineering
| |||||
| 967.3 | DFLAT::PLOUFFE | Jerry | Mon Apr 29 1991 14:43 | 23 | |
RE: .0
Catherine:
Hello. I discussed your question w/ Darryl and he the net result is that
the DELETE command will remain working--though undocumented for all the
reasons that Matt mentioned in .1. This decision will most likely be
revisited (along with other key DAP interface issues) in v2.0. We will
keep your need in mind. Thanks for informing us of your use of this
command.
RE: .2
Richard:
I agree with your assessment of the need "to do the right thing". I will
put this on the DAP to do list.
- Jerry
Current member of the Toolkit Team
working on DAP...
| |||||