| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 83.1 | Yes, there is a bug somewhere | PETE::BURGESS | | Mon Mar 26 1990 17:06 | 10 |
| Yes, *all* MCC routines are available in the mcc$kernel_shr image.
So there is definitely a bug either on my side of the interface or
on your side.
I'd like to recreate your problem on my system. Could you send
me a small source program with the significant code?
Pete Burgess
|
| 83.2 | QARed | TENERE::FLAUW | | Tue Mar 27 1990 05:33 | 10 |
|
Peter,
I have Qared it as QAR 70 in mcc_int database.
The pointer to the source file is given in the QAR.
Thanks and regards,
Marc.
|
| 83.3 | Missing lib$initialize psect | PETE::BURGESS | | Tue Mar 27 1990 18:07 | 19 |
| The forthcoming SRM eco on using callable mcc will present
the full story on building executable images. The information which you
were missing is that today (ie it's temporary) the executable must contain
a special object module (mcc$kernel_init.obj) which contains a
lib$initialize psect contribution. Before the executable's main
routine is called, lib$initialize will call the mcc$kernel_initialize
routine to initialize the multi-threading environment and prepare the
current context as a thread.
Because callable mcc has not yet been completely announced (ie SRM
update), the object module was not included in the ut1.0.0 kit.
I hope to provide toolkit developers with everything for the
eft update kit.
/Pete Burgess
|
| 83.4 | Thanks, Pete. | TENERE::FLAUW | | Wed Mar 28 1990 02:15 | 6 |
|
Thanks, Pete. I will be waiting for EFT update.
Best regards,
Marc.
|
| 83.5 | more MIR questions | ATPS::RAMAN | Ashok Raman, 381-0007, ZKO3-3/Z34 | Fri Aug 31 1990 17:48 | 12 |
| I have been looking into using the MIR and have a few fundamental
questions -
- Does it make sense to create a repository in an AM ?
- Where would one create it ? For 10.12 SRM examples, wouldn't
repeated executions return 'Repository failed-to-create--already-exists'
kind of message.
Thanks for the help,
Ashok
|
| 83.6 | Create it wherever it makes sense | TOOK::GUERTIN | Wherever you go, there you are. | Fri Sep 07 1990 16:15 | 39 |
| AM's often need attributes, entity instances, etc, to be network-wide.
If this is the case, and they cannot directly support it, they need to
use the mcc_dns routines. If the information is system-wide (or
cluster-wide if they are in a cluster environment and define the
location of the repository as the common disk) then they can use the
MIR routines. MIR repositories are generally defined once for the
lifetime of the product. The caller defines a unique repository name
and calls mcc_mir_create_repository() which in turn computes a unique
number (unique per system) called the repository-id. The number is
used as an "index" by the MIR routines to identify the repository.
Repository names are (more or less) permanent and get stored in the
MCC_MIR_DIRECTORY.DAT file. Repository locations also get saved across
MCC image activations and are stored in the MCC_MIR_ATTRIBUTE.DAT file.
After you have created a repository, all that is needed is to do a
mcc_mir_get_repository_id() which translates the unique name into the
repository-id.
One algorithm commonly used is:
stat = mcc_mir_get_repository_id( ... );
if (stat == MCC_S_NOREPOSEXIST)
stat = mcc_mir_create_repository( ... );
or something like that.
Also, I believe that the mcc_mir_create_repository() when it fails with
MCC_S_REPOSEXIST ALWAYS updates and returns the repository-id of the
repository name which it found. This is because it does a
mcc_mir_get_repository_id() call to check for existence before trying
to create it. So you should be able to just do...
stat = mcc_mir_create_repository( ... )
if ((stat == MCC_S_NORMAL) || (stat == MCC_S_REPOSEXIST))
/* do normal processing */
But I'll need to check on the latter.
-Matt.
|