| RE: .0
Philippe.
> I'm running into a slight problem with the design framework, so I would
> like to know what the mcc_desframe_package_callargs routine does to the
> out_entity parameter ? Does it perform an mcc_aes_copy, or does it copy
> the pointer ?
No .. package call args does no aes-copies .. I've included the
source code below. Makes me wonder why the call arguments wasn't a structure
in the first place. Its simpler to manipulate and pass around as a single
structure ... 8{
> I have a request with a wildcarded child entity. I handle the first
> child, on exiting my am (with handle set to MORE), I get the correct ID
> in my out_entity.
You get the correct Id, because you Set (or Create) the Out-Entity
Argument .. Right?
> On the second call however, I get an invalid ID. I dumped both the
> callargs.p_out_entity and the out_entity using mcc_aes_dump(), and
> found them to be different. The correct Id was in callargs.
Where do you get the Invalid Id? From In-Entity? In-Entity should not
have changed since your first call. Did Out-Entity change between calls?
Who is calling your AM? FCL/IMPM/Alarms/ ...
When you say 'Invalid Id' .. what exactly are you refering to? The
Entity Class Code? Or the Entity Instance Id (from the Instance
Descriptor)?
> I know I can work around this by testing the handle and using
> mcc_aes_copy to set my out_entity, but it doesn't "feel" right. Could
> this be a bug in the design framework, or is it me?
The Design Framework does nothing with Out-Entity .. Well, that is,
nothing behind your back. In the "init-handle-first" code, the In-Entity
is copied to the Out-Entity. This is the only place I can think of that
Out-Entity gets touched outside what your MM needs to do with Out-Entity
> By the way, if I remember correctly, mcc_aes_dump used to be documented
> in SRM 1.0, but disappeared with the SRM 1.1, yet it is extremely
> useful when debugging this type of problem. Any chance of it finding
> it's way back into the SRM ?
Someone from the SRM project team could better answer this. I would hope
that *EVERY* encapsulated object (AES, HANDLE, ATS, ...) which DECmcc uses
would have a dump routine of some kind .. needed during development.
/keith
/*
* ---------------------------------------------------------------------
*
* mcc_desframe_package_call_args
*/
extern MCC_T_CVR mcc_desframe_package_call_args(
verb, in_entity, attribute, time_spec, in_q, in_p,
handle, out_entity, time_stamp, out_p, out_q, call_args)
unsigned long int *verb;
MCC_A_AES in_entity;
unsigned long int *attribute;
MCC_A_TIMEFRAME time_spec;
MCC_T_Descriptor *in_q;
MCC_T_Descriptor *in_p;
MCC_A_HANDLE handle;
MCC_A_AES out_entity;
MCC_T_Descriptor *time_stamp;
MCC_T_Descriptor *out_p;
MCC_T_Descriptor *out_q;
dt_callargs *call_args;
{
call_args->p_verb = verb;
call_args->p_in_entity = in_entity;
call_args->p_attribute = attribute;
call_args->p_time_spec = time_spec;
call_args->p_in_q = in_q;
call_args->p_in_p = in_p;
call_args->p_handle = handle;
call_args->p_out_entity = out_entity;
call_args->p_time_stamp = time_stamp;
call_args->p_out_p = out_p;
call_args->p_out_q = out_q;
return(MCC_S_NORMAL);
}
|
| RE: .2
> In the code, we set the aes pointed to by callargs.p_out_entity. When I
> say "invalid ID", I mean invalid (wrong ?) instance value.
>
> What I don't understand is how at the same point in time, (i.e. just
> before the AM performs a return to caller ), dumping out_entity and
> dumping callargs.p_out_entity can give different results if they both
> point to the same aes ??? Yet, this is exactly the problem I have ???
That is strange because - Yes - both Out-Entity & the callargs.p_out_entity
are the same pointers. The only thing I can think of is which ever
Out-Entity pointer you are using (the *real* call argument or the callargs
structure) .. you are off by a level of indirection. For example, you
passed one of the Entity pointers by value and it should have been by
reference .. or something like that.
I'll step through the Sample-AM code to double check the Out-Entity.
.flame on
Wouldn't it be nice if we had ** Function Prototypes ** to
allow the compiler to help developers find these types of errors!
.flame off
> I know aes's are opaque structures, but it would be nice to have a
> better view of how they are built and how the mcc_aes set of routines
> work. Is there any information available on this ?
All of the abstracted routines could use more documentation.
SRM Chapter 10.1 (Abstract Entity Specification AES Routines) has a
description and a programming example (note: will not work on Ultrix due
to passing constants by reference; should be fixed in the next SRM release).
There is also some information in the Toolkit Management Module Programming
guide under "The MCC_CALL interface".
Q: Do you have any specific questions we could answer here ?
/keith
|
|
Using the Sample AM, I issued a Show directive and compared
the contents of the "call_args.p_out_entity" and the actual
"out_entity" call argument ... after calling the desframe
package call arguments routine.
You can see that both pointers are the same. I suspect that
when accessing the Out-Entity argument, your MM is off by a
level of indirection.
/keith
------------------------------------------------------------
DBG> exam call_args
MCC_SAMPLE__SHOW\mcc_sample__show\call_args
p_verb: 2686108
p_in_entity: 1746544
p_attribute: 2686168
p_time_spec: 0
p_in_q: 0
p_in_p: 0
p_handle: 2685628
p_out_entity: 1746208 <---- The Out-Entity ----+
p_time_stamp: 2685988 arguments are |
p_out_p: 2685748 the same |
p_out_q: 2686228 |
|
|
DBG> ex out_entity |
V
MCC_SAMPLE__SHOW\mcc_sample__show\out_entity: 1746208
|