| 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 |
I don't seem to be able to get an MCCReply argument out.
One of the directives in my MM invokes one of the others, through
mcc_call_access. If the called directive (now the service provider)
returns an exception with an argument, like NOENTITY, I'd like to roll
that into an exception return from the caller (client).
I decided the client will return MCC_K_CANNOT_COMPLETE with an argument of
MCC_K_ARG_SVC_ERR. The datatype of that argument is MCCReply. The entries
in the reply tables look like:
static dt_reply_arg_list ReplyArg_svc_err[] = {
offsetof(dt__LocalContext, ReplyArg_p1), MCC_K_ARG_SVC_ERR,
REPLY_K_END_OF_ARG_LIST
};
/* DHSM__UNABLE_TO_COMPLETE_SVC 7 */
MCC_S_COMMON_EXCEPTION,
MCC_K_CANNOT_COMPLETE,
&ReplyArg_svc_err,
When my do_directive routine returns with a value of MCC_S_COMMON_EXCEPTION,
p_context->reply_index is DHSM__UNABLE_TO_COMPLETE_SVC and the
p_context->ReplyArg_p1 points at a descriptor for an MCC_R_Reply_List
record. I made sure none of the addresses in that record pointed at a
value on the stack. Everything is static or on the heap.
The end_directive routine is invoked and passes the callargs and context
pointers to mcc_desframe_set_cvr_and_reply. The return status is
"invalid descriptor". I can't see anything wrong with either the
ReplyArg or out_p descriptors:
*DHSM_AM__ARCHIVE\p_context->ReplyArg_p1
mcc_w_maxstrlen: 52
mcc_b_dtype: 0
mcc_b_class: 1
mcc_a_pointer: 1427724
mcc_w_curlen: 52
mcc_b_flags: 0
mcc_b_ver: 1
mcc_l_id: 4
mcc_l_dt: 59
mcc_a_link: 0
===
So, instead of set_cvr_and_reply, I used ilv_put_mccreply and friends
to encode the reply list into out_p myself, and modified end_directive
so it doesn't call set_cvr_and_reply for that particular reply_index.
FCL displays "The requested operation cannot be completed" but then
instead of displaying the contents of the reply list argument it does
"%MCC-I-REQ_NOT_SATIS, request not satisfied" and that's all.
The output from FCL with tracing follows:
DECmcc (X1.1.0)
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=4 class code= 10 instance = �class code= 11 instance = no curlen class code= 12 instance = no curlen class code= 13 instance = a
ILV DUMP of INP:
[ 0 ] (
[ 1 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 10
HANDLE STATE, before call: FIRST
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 2 ] (
[ 4 ] (
[ 1 ] 01
[ 2 ] 58 02 00 00
[ 3 ] 03 26 80 59
[ 4 ] 0c
[ 5 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 14
[ 3 ] 01
[ 4 ] 05
[ 5 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
[ 1 ] (
[ 1 ] 01
[ 2 ] 0c
[ 3 ] 7f
[ 4 ] 00
[ 5 ]
)
[ 2 ] (
[ 1 ] 01
[ 2 ] 0d
[ 3 ] 01
[ 4 ] 06
[ 5 ] 61 -- a
)
)
[ 6 ] 0a
[ 7 ] (
)
[ 8 ] (
)
[ 9 ] (
)
[ 10 ] 60 59 93 b0 50 5a c9 01 ff ff ff ff ff ff 5c 1e
[ 11 ] (
[ 3 ] (
[ 6 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 14
[ 3 ] 01
[ 4 ] 05
[ 5 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
)
)
)
[ 12 ] (
)
)
)
AES DUMP of ENTITY OUT:
depth=4 class code= 10 instance = �class code= 11 instance = no curlen class code= 12 instance = no curlen class code= 13 instance = a
HANDLE STATE, on return: FIRST
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
HANDLE STATE, at check_handle: 0
Node DEC:.a Storage VMS File a
AT 22-SEP-1990 15:51:36
The requested operation cannot be completed
%MCC-I-REQ_NOT_SATIS, request not satisfied
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 346.1 | INFO: Needed another level | COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Sep 24 1990 23:56 | 112 |
After looking at the ILV produced by other MMs it looked like there needed
to be another level with an id of 0 between the exception code and the
argument code.
That was easy enough, and now FCL correctly extracts the CVR from the
MCCReply fields and reports the right error:
The requested operation cannot be completed
%MCC-E-NOENTITY, no corresponding entity instance exists
I'm pretty sure I've seen FCL format the MCC Service Error Argument, which
in this case would display the entity whose absence caused the problem. If
only I could remember what error to which directive and entity I saw it
on, I could look at the ILV and revengr it. But I can't.
Can anyone give me some hints towards getting the PM to display the
contents of MCCReply?
For you ILV savants, here's the latest:
DECmcc (X1.1.0)
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=4 class code= 10 instance = �class code= 11 instance = no curlen class code= 12 instance = no curlen class code= 13 instance = a
ILV DUMP of INP:
[ 0 ] (
[ 1 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 10
HANDLE STATE, before call: FIRST
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 2 ] (
[ 0 ] (
[ 4 ] (
[ 1 ] 01
[ 2 ] 58 02 00 00
[ 3 ] 03 26 80 59
[ 4 ] 0c
[ 5 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 14
[ 3 ] 01
[ 4 ] 05
[ 5 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
[ 1 ] (
[ 1 ] 01
[ 2 ] 01
[ 3 ] 15
[ 4 ] 04
[ 5 ] 01 17 32 34 2d 53 45 50 2d 31 39 39 30 20 32 30 3a 34 30 3a
32 36 2e 30 33
)
)
[ 6 ] 0a
[ 7 ] (
)
[ 8 ] (
)
[ 9 ] (
)
[ 10 ] c0 d8 bc 5e 0b 5c c9 01 ff ff ff ff ff ff 5c 1e
[ 11 ] (
[ 3 ] (
[ 6 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 14
[ 3 ] 01
[ 4 ] 05
[ 5 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 05 00 01 01 61 00
00
)
)
)
)
[ 12 ] (
)
)
)
)
AES DUMP of ENTITY OUT:
depth=4 class code= 10 instance = �class code= 11 instance = no curlen class code= 12 instance = no curlen class code= 13 instance = a
HANDLE STATE, on return: FIRST
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
HANDLE STATE, at check_handle: 0
Node DEC:.a Storage VMS File a
AT 24-SEP-1990 20:40:26
The requested operation cannot be completed
%MCC-E-NOENTITY, no corresponding entity instance exists
| |||||
| 346.2 | MKNME::DANIELE | Tue Sep 25 1990 09:22 | 58 | ||
Does this help?
MCC> register snmp ffff
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=1 class code= 18 instance = ffff
ILV DUMP of INP: in_p is NULL
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 10
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 19 ] (
[ 4 ] (
[ 1 ] 03 26 80 59
[ 2 ] 01
[ 3 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 12
[ 3 ] 62 -- b
[ 4 ] 4a -- J
[ 5 ] 66 66 66 66 -- ffff
)
)
[ 4 ] (
[ 3 ] (
[ 6 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 12
[ 3 ] 62 -- b
[ 4 ] 4a -- J
[ 5 ] 66 66 66 66 -- ffff
)
)
)
)
)
)
AES DUMP of ENTITY OUT:
depth=1 class code= 18 instance = ffff
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
SNMP ffff
AT 25-SEP-1990 08:21:15
The requested operation cannot be completed
MCC Service Error = No such entity: SNMP ffff
MCC>
| |||||
| 346.3 | <here's one> | TOOK::HAO | Tue Sep 25 1990 10:00 | 132 | |
Sorry Mike. Your example was for an MCCMessage datatype, not MCCReply.
Richard, I'm not sure if the extra level is needed. The following is
an ILV dump of the command that returns a hard-coded MCCReply argument.
This is for the PM_TESTER module which is used to test datatype
conversion routines.
The response ID is 1. Two arguments are returned, of which Argument
ID 6 is the one with MCCReply datatype:
POLE$ mana/enter
DECmcc (X1.1.0)
MCC> dump mcc 0 pm_tester mccreplyarg
FCL PM Arguments before call_function:
AES DUMP of ENTITY IN:
depth=2 class code= 7 instance = 0 class code= 11 instance = no curlen
ILV DUMP of INP:
[ 0 ] (
[ 6 ] (
[ 5 ]
)
)
ILV DUMP of INQ: in_q is NULL
ATTRIBUTE PARTITION: 10
*******************************************
FCL PM Arguments on return from call_function:
ILV DUMP of OUTP:
[ 1 ] (
[ 100 ] 01 0b 4d 43 43 52 65 70 6c 79 41 72 67
[ 6 ] (
[ 1 ] 0b
[ 2 ] 78 00 08 00
[ 3 ] 03 26 80 49
[ 4 ] 03
[ 5 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 07
[ 3 ] 00
[ 4 ] 00
[ 5 ]
)
[ 1 ] (
[ 1 ] 01
[ 2 ] 0b
[ 3 ] 00
[ 4 ] 00
[ 5 ]
)
)
[ 6 ] 0a
[ 7 ] (
[ 222 ] (
[ 6 ] 6e 61 6d 65 -- name
)
)
[ 8 ] (
[ 3 ] (
[ 1 ] 01
[ 4 ] 08 ae
[ 16 ] 73 74 72 69 6e 67 -- string
)
)
[ 9 ] (
[ 0 ] (
[ 1 ] 01
[ 2 ] 07
[ 3 ] 00
[ 4 ] 00
[ 5 ]
)
[ 1 ] (
[ 1 ] 01
[ 2 ] 0b
[ 3 ] 00
[ 4 ] 00
[ 5 ]
)
)
[ 10 ] 10 00 0e 02 cc e3 16 00 10 00 00 01 00 00 00 00
[ 11 ] (
[ 1 ] (
[ 1 ] 01
[ 4 ] 08 ae
)
)
[ 12 ] (
[ 0 ] (
)
)
)
)
AES DUMP of ENTITY OUT:
depth=2 class code= 7 instance = 0 class code= 11 instance = no curlen
CVR returned:
%MCC-S-RESPONSE, success with response reply
MCC 0 PM_TESTER
AT 25-SEP-1990 08:54:25
Dump of MCCReplyArg Successful
MCCReplyArg = 11, X0.8.0,
%MCC-S-RESPONSE, success with
response reply,
Test,
MCC PM_TESTER ,
Null Partition,
BooleanArg = True,
Unsigned32Arg = 2222,
Latin1StringArg = "string",
MCC PM_TESTER ,
Test Successful,
BooleanArg = True,
Unsigned32Arg = 2222
MCC>
*************************************
Christine
| |||||
| 346.4 | SOLUTION: No Null Pointers | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Sep 26 1990 02:45 | 5 |
Thanks, Christine. The trick is to not have any null pointers in the MCCReply structure. Even if in_p is null, the field in the reply list has to point at a valid descriptor for a null ILV buffer. If there isn't an out_entity, set the field to in_entity. | |||||