| 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 |
As mentioned in note 5728 and 5594 of this conference we are
using the mcc_mir routines within our TBL-project very extensively
to store our instance- and attribute-data in the private MIR.
Creation of attribute- and instance-repositories is done with
the routine mcc_mir_create_repository of DECmcc V1.3.0 (ULTRIX)
with the appropriate repository types MCC_K_DB_FTYPE_ENTDEF
MCC_K_DB_FTYPE_ATTRIBUTE by our own FM and AM.
Doing this in parallel within two processes the following
problems occur:
Problem 1:
start process 1 start process 2
create inst-repos 1
==> repos_id = 10
create inst-repos 2
==> repos_id = 11
create inst-repos 3
==> repos_id = 12
create inst-repos 4
==> repos_id = 12 (!!)
create inst-repos 5
==> repos_id = 13
create inst-repos 6
==> repos_id = 13 (!!)
We assume, that process 2 gets the right repos_id the first time
creating one repository, but after that numbering of the repos_id
is done seperately by each process, that means the same repos-ids are reused.
This causes confusing and unacceptable behaviour and inconsistence
of the stored data.
Problem 2:
create inst-repos 1
==> repos_id = 22
create inst-repos 2
==> repos_id = 23
create attr-repos 4
==> repos_id = 23 (!!)
Reading and writing of these repositories
causes the following return status:
MCC_S_WRONGREPOSTYPE 52876290
Is this bug known by anybody, is there a bug-fix?
Heidi
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5981.1 | Sounds like a bug. | TAEC::LAVILLAT | Mon May 09 1994 10:15 | 15 | |
Heidi, Your are not supposed to create MIR repositories very often, that is why *maybe* the access to the repository table is not well protected. I would suggest you enter a CLD for this problem, so that the MCC maintenance team is aware of it. I would also suggest that you work around the problem by doing the mutual exclusion yourself via flock or any other way. Regards. Pierre. | |||||