| 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. | |||||