| 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 |
Hi Mcc Gurus, simple questions about the MIR
Extract from the SRM
"the MIR routines are a set of common routines that allow any
management module to define and manage private MIRs.
These repositories are not to be shared between management modules"
Let us say that I have a FM FOO which creates a repository FOO_REPOS
In the Ultrix environement, there is one process running the FM FOO code per
Ultrix user using the services offered by the FM.
For me this means there is already "somewhere" a locking mechanism to allow
concurrent access to the same repository from different processes.
The question is therefore the following:
Is it possible to have the FM which creates the repository, perform
READ/WRITE accesses to this repository AND to have a separate
application which directly:
1. opens the FOO_REPOS (using mcc_mir_get_repository_id)
performs also READ/WRITE accesses to this repository
2. opens the FOO_REPOS (using mcc_mir_get_repository_id)
JUST uses this repository with READ_ONLY access
(mcc_mir_get_identifier & mcc_mir_read_attr_data)
I understand very well that the best thing should be for this external
application to use the MCC call interface of the FOO FM but it seems really
unefficient to:
- build an MCC call in the external application
- decode this MCC call in the service routine of the FOO FM
- the FM issues the mcc_mir_xx routine calls and returns the value in
the out_p
- the external application checks the mcc_call and eventually (a long
time after...) uses the out_p
I thank you for your advices,
Regards,
Damien.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5390.1 | Yes, it is possible | TAEC::FLAUW | Tue Jul 27 1993 04:52 | 41 | |
re: .0 Damien, Up to my knowledge, the MIR routines don't offer the user a way to specify whether the repository is opened in read/write mode or in read mode. >For me this means there is already "somewhere" a locking mechanism to allow >concurrent access to the same repository from different processes. You are correct. >The question is therefore the following: > > Is it possible to have the FM which creates the repository, perform > READ/WRITE accesses to this repository AND to have a separate > application which directly: > > 1. opens the FOO_REPOS (using mcc_mir_get_repository_id) > performs also READ/WRITE accesses to this repository > > 2. opens the FOO_REPOS (using mcc_mir_get_repository_id) > JUST uses this repository with READ_ONLY access > (mcc_mir_get_identifier & mcc_mir_read_attr_data) > What you are mentionning is possible, but it assumes that the external application has the exact knowledge of the structure of the information stored in the MIR. It means also that this application would have to change if the structure of the private MIR changes. Accessing this information through the mcc_call isolates the external application from the structure of the MIR, allows for distribution of mcc_call in future and let the FOO FM do any additional processing that might be needed, like generating a state/attribute change event, if the information changed in the MIR is a state or an attribute. Best regards, Marc. | |||||