| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 350.1 | INFO - encoding an attribute list | GOSTE::CALLANDER | | Wed Sep 26 1990 12:44 | 28 |
|
The V1.0 kit has a problem with excepting empty sets. This will
be fixed in the EFT kit.
As to what you are trying to do, I am confused. A set_of can only
be a set_of a specific data type. Do you mean you have defined multiple
attributes, each being a seperate set_of some specific datatype?
As for ILV encoding you have to remember that what you are encoding
is not the specific attribute but the attribute list that this
attribute is a member or.
param_begin [reply code]
cons_begin [attrib_list code]
cons_begin [set_of attribute code]
put [1st set_of value]
:
cons_end
put [next attribute]
:
cons_end
param_end
Remember when doing this that the mode for the cons_begin on an
attribute list is list and not native.
Hope this helps
|
| 350.2 | I was not clear enough, anyway what the ILV should look like ? | RIVAGE::LAVILLAT | | Thu Sep 27 1990 10:14 | 83 |
|
Thanks for your answer.
Sorry, I was not clear ...
First, you are rigth, I meant I have defined multiple
attributes, some being a seperate set_of some specific datatype.
Second, you rigth again, I forgot a put_cons_begin [ attrib_list_code ]
in my example ( and its corresponding put_cons_end).
When you say "The V1.0 kit has a problem with excepting empty sets"
is this for both ILV encoding and FCL ?
I am sorry to ask, because I was not able to find it in the notesfile :
when will this EFT kit available ?
I checked my ILV encoding of an empty SET OF, and dumped it.
I am afraid there is something wrong with it, though I did exactly
as you said :
[ 1 ] (
[ 1 ] (
[ 2 ] (
[ 1 ] 04
[ 2 ] 01 07 48 41 52 4e 45 53 53
[ 3 ] 00
)
[ 3 ] (
[ 1 ] 34 -- 4
[ 3 ] 00
[ 4 ] (
)
)
)
)
Application Type = HARNESS
Protocol List = { ( Invalid data type.
+ access violation.
But when the set is not empty I got the same kind of ILV,
and it works ...
[ 1 ] (
[ 1 ] (
[ 2 ] (
[ 1 ] 04
[ 2 ] 01 07 48 41 52 4e 45 53 53
[ 3 ] 00
)
[ 3 ] (
[ 1 ] 34 -- 4
[ 3 ] 00
[ 4 ] (
[ 1 ] (
[ 1 ] 01 07 48 41 52 4e 45 53 53
[ 2 ] 01 03 41 41 41
)
[ 1 ] (
[ 1 ] 01 07 48 41 52 4e 45 53 53
[ 2 ] 01 03 42 42 42
)
)
)
)
)
{ ... }
Examination of attributes shows:
Application Type = HARNESS
Protocol List = { ( ProtocolName = HARNESS,
ApplicationId = AAA ),
( ProtocolName = HARNESS,
ApplicationId = BBB ) }
Are all this ILVs correct ?
Thanks and regards
Pierre.
|
| 350.3 | INFO - it isn't you it's the FCL | GOSTE::CALLANDER | | Thu Sep 27 1990 17:52 | 16 |
| The problem is that the fcl is just NOT handling the empty set.
This has been qared by Verna Gilbert who found it while testing
the set_of from the iconic map.
This won't be fixed until the EFT release. As far as the date for
that goes...I don't believe that anything has been formally announced
but don't expect it for at least another month+. If you have found
that this problem is a "show stopper" and is inhibiting your
development, please send a note to Peter Savage (TOOK::P_SAVAGE)
or Anne Pelagatti (TOOK::) stating your case and requesting a patched
FCL executable.
(As for the access violation at least that much has been fixed in
the SSB kit we recently built.)
|
| 350.4 | QUESTION Still a problem with EFT 1.1 ? | TENERE::LAVILLAT | | Thu Dec 06 1990 05:03 | 85 |
|
Hi again,
It seems that the FCL still does NOT handle empty SETs. The problem is
that we NEED them !
Am I wrong ? When will this be fixed ? Any idea for a workaround ?
Regards
Pierre.
PS : Here is a trace of execution , tell me if something is wrong with my OUT_P
( my empty set is a SET OF SimpleName)
$ mana/ent
DECmcc (T1.1.0)
MCC> show GMA_TEST 0 SIF SCPA 12 all char
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 1
PARTITION code: 4
AES dump of ENTITY IN:
depth=3 class code= 9501 instance = 0 class code= 5 instance = no curlen class
code= 8 instance = 12
ILV dump of IN_P: in_p is NULL
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
*********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-RESPONSE, success with response reply
ILV dump of OUT_P:
[ 1 ] (
[ 1 ] (
[ 2 ] (
[ 1 ] 34 -- 4
[ 3 ] 00
[ 4 ] (
[ 1 ] (
[ 1 ] 01 03 55 41 4c
[ 2 ] 01 03 41 41 41
)
)
)
[ 3 ] (
[ 1 ] 34 -- 4
[ 3 ] 00
[ 4 ] (
)
)
)
)
AES dump of ENTITY OUT:
depth=3 class code= 9501 instance = 0 class code= 5 instance = no curlen class
code= 8 instance = 12
GMA_TEST 0 SIF SCPA 12
AT 6-DEC-1990 10:52:12 Characteristics
Examination of attributes shows:
Protocol List = { ( ProtocolName = UAL,
ApplicationId = AAA ) }
SCPs set = { Invalid data type.
,
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=0100000C, PC
=002338DB, PSL=03C00000
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
=0000000A, PSL=0000000F
$
|
| 350.5 | don't know | GOSTE::CALLANDER | | Thu Dec 06 1990 15:14 | 15 |
|
Okay, two things to realize. First the ILV dump doesn't dump
everything, second a null set_of is still a set_of something.
There a two potential problems here.
1) the FCL isn't excepting an empty set on output
- or -
2) you are not filling in the descriptor before doing your
ilv put of the attribute.
We are going to look into this some more. It was our understanding
that the phase 5 team was successfully returning the null set. I
will see what else I can find out.
|
| 350.6 | In my opinion an empty set can be a set of anything | TENERE::LAVILLAT | | Fri Dec 07 1990 04:05 | 28 |
|
>> second a null set_of is still a set_of something.
For an MSL point of vue I agree, but for an ILV point of
vue I do not understand : I thougth a empty set could only be encoded
doing :
stat = mcc_ilv_put_cons_begin (
ilv_context,
&Attrib_Idcode,
&MCC_K_DT_SET_OF,
&reason_code,
&MCC_K_ILV_NATIVE_VALUE);
stat = mcc_ilv_put_cons_end ( ilv_context );
So there is no way to specify what the SET is OF, am I wrong ?
Do I need to do a mcc_ilv_put with an empty MCC descriptor, set with
mcc_l_dt = what_the_set_of_is, mcc_w_curlen = 0 and mcc_l_id = 1 or a
mcc_ilv_put with a ValueDesc parameter set to MCC_K_NULL_PTR, or ???
Help !!!
Regards
Pierre
|
| 350.7 | ... | GOSTE::CALLANDER | | Fri Dec 07 1990 10:25 | 8 |
|
We are looking into it. By the comment in .5 (I believe) what was
meant is that the data type field of the value descriptor used to
do the initial ILV put of the attribute must be set. If it isn't
things won't work. As far as the put cons goes there are not other
arguments that you could have setup. Sorry for the confusion but
I don't find it real easy to describe ILV constructs.
|
| 350.8 | The empty construct needs the datatype | COOKIE::KITTELL | Richard - Architected Info Mgmt | Fri Dec 07 1990 11:21 | 123 |
|
This is the routine I use to produce ILV for an attribute for which I don't
have a value. By default it returns a reason of unavailable but it will
return any other reason specified. Note that for sets it does supply the
datatype of the construct to the cons_begin function.
The attr_info structure parameter describes
the attribute and looks like:
typedef struct
{
MCC_T_IDCode id; /* attribute code from MSL */
MCC_T_UNSLONG partition; /* attr partition code */
MCC_T_UNSLONG mcc_datatype; /* DECmcc datatype code */
MCC_T_UNSLONG vms_datatype; /* VMS descriptor datatype code */
MCC_T_UNSSHORT bytes; /* bytes needed to store attribute */
MCC_T_Descriptor *initial_value; /*
* optional initial value to
* set when attribute initialized.
*/
MCC_T_Descriptor *val_desc; /* attribute value */
} util_attr_info_t;
/*
**++
** FUNCTIONAL DESCRIPTION:
**
** U T I L _ A T T R _ U N A V A I L
**
** Puts a entry in the ILV for the specified attribute, indicating
** that the attribute value is not available.
**
** FORMAL PARAMETERS:
**
** attr_info - (read) Address of attribute info record for the
** attribute.
**
** ctx - (read) The address of an ILV context block.
**
** reason - (read) Address of reason code, NULL defaults to
** unavailable.
**
** RETURN VALUE:
**
** MCC_S_NORMAL if all is well, MCC_S_... error code otherwise.
**
** SIDE EFFECTS:
**
** None
**
** DESIGN:
**
**
**
**--
*/
extern MCC_T_UNSLONG util_attr_unavail (attr_info, ctx, reason)
util_attr_info_t *attr_info;
struct MCC_R_ILV_CONTEXT *ctx;
MCC_T_Enumeration *reason;
{
MCC_T_UNSLONG status;
MCC_T_UID uid;
MCC_T_Enumeration reasoned = MCC_K_REASN_ATTR_NOT_AVAIL;
MCC_T_Descriptor empty_desc =
{
0, DSC_K_DTYPE_Z, DSC_K_CLASS_S, uid, 0, 0, MCC_K_VER_DESCRIPTOR,
0, 0, MCC_K_NULL_PTR
};
/* Set up descriptor. */
empty_desc.mcc_l_dt = attr_info->mcc_datatype;
empty_desc.mcc_l_id = attr_info->id;
empty_desc.mcc_b_dtype = attr_info->vms_datatype;
empty_desc.mcc_w_maxstrlen = attr_info->bytes;
/* Modify default reason if appropriate. */
if (reason)
reasoned = *reason;
switch (attr_info->mcc_datatype)
{
case MCC_K_DT_FULL_ENTITY:
empty_desc.mcc_a_pointer = MCC_K_NULL_PTR;
empty_desc.mcc_w_curlen = attr_info->bytes;
status = mcc_ilv_put (ctx, &empty_desc, &reasoned);
break;
case MCC_K_DT_SET_OF:
case MCC_K_DT_SEQUENCE_OF:
/* Start the ILV construct for the set. */
status = mcc_ilv_put_cons_begin (ctx, &empty_desc.mcc_l_id,
&empty_desc.mcc_l_dt,
&reasoned,
&MCC_K_ILV_NATIVE_VALUE);
/* Close the set construct. */
if (GOOD(status))
status = mcc_ilv_put_cons_end (ctx);
break;
case MCC_K_DT_FULL_NAME:
case MCC_K_DT_LATIN1STRING:
case MCC_K_DT_SIMPLE_NAME:
if (attr_info->bytes > sizeof (MCC_T_UID))
empty_desc.mcc_w_curlen = sizeof (MCC_T_UID);
else
empty_desc.mcc_w_curlen = attr_info->bytes;
status = mcc_ilv_put (ctx, &empty_desc, &reasoned);
break;
default:
empty_desc.mcc_w_curlen = attr_info->bytes;
status = mcc_ilv_put (ctx, &empty_desc, &reasoned);
break;
}
return (status);
} /* util_attr_unavail */
|
| 350.9 | FCL fails on empty set_of, but doesn't look at the set if reason code isn't success | TOOK::DITMARS | Pete | Fri Dec 07 1990 12:09 | 10 |
| It looks like the difference between Richard's code and Pierre's is that Richard
sets the reason code to MCC_K_REASN_ATTR_NOT_AVAIL while Pierre is setting
it to MCC_K_REASN_SUCC_OP.
FCL probably doesn't look at the value if the reason code is
MCC_K_REASN_ATTR_NOT_AVAIL. When it does look at an empty set, it accvios.
Pierre, is returning MCC_K_REASN_ATTR_NOT_AVAIL a viable work-around for you?
I have QAR'd FCL on this, QAR 86 in the MCC_INTERNAL QAR database.
|
| 350.10 | found it... | GOSTE::CALLANDER | | Fri Dec 07 1990 16:43 | 21 |
| RE .9
That is exactly what the difference was. The case of an empty set
with a successful reason code was not supported. The access violation
was due to the fact that the FCL found it had a null set, deallocated
the descriptor it had for storing the value and then returned to
the print routine. Unluckily the print routine expected the descriptor
to be there when handling a null set, and only the a_pointer field
to be null.
In a nutshell we have found the problem and a fix is in place in
our local test environment. If you can not wait until the update
for the fix maybe something can be worked out, but personally just
encoding it with the failure reason code would be better so that
we get more testing on the official EFT kit.
Thanks for finding the problem
(and taking the time to report it)
Jill
|
| 350.11 | We found a workaround | TENERE::LAVILLAT | | Mon Dec 10 1990 11:46 | 26 |
| Re .8
"This is the routine I use to produce ILV for an attribute for which I don't
have a value."
I got the value : it is an empty SET !
Re .9
"Pierre, is returning MCC_K_REASN_ATTR_NOT_AVAIL a viable work-around for you?"
Sorry , the answer is no. We found another workaround that is : send back a
dummy element in the set ( I do the put_cons_begin in list mode before knowing
if the set is empty or not, it is not me that do the ilv-put of the set, so
it is more easy for us to implement this).
I just want to add that everything is not attribute list and we can have SETs
in response to ACTION verbs, exceptions, event arguments and also records of
SETs and so on... but you know all this better than me !
Thanks again for your help and suggestions
Regards
Pierre.
|
| 350.12 | Input and Output? | SCRPIO::LIZBICKI | | Tue Dec 11 1990 16:48 | 8 |
|
Re: .10
Does this mean that the FCL is fixed to accept a null set as input,
as well as display it for output?
Lynne
|
| 350.13 | empty sets in V1.1 | GOSTE::CALLANDER | | Wed Dec 12 1990 11:33 | 7 |
| It means it will be fixed, we have the output end working and back
into CMS and are currently checking out the input end. We thought
it had already been done but can't remember. It is a scheduled task
to be completed before V1.1 ships.
Sorry for any inconveniences this caused.
|
| 350.14 | Perhaps the Iconic PM didn't get this? | COOKIE::KITTELL | Richard - Architected Info Mgmt | Mon Apr 08 1991 19:30 | 16 |
|
Jill,
Should the fix you speak of have applied to the Iconic PM as well? I know much
of the conversion stuff is common between the two PMs. I can get null sets
out of FCL just fine, but from IMPM:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000010, PC
=002B1A63, PSL=03C00004
break on exception at SHARE$MCC_ICONIC_MAP_PM+305763
This is with SSB V1.1
I can cause this either my REMOVing the last element of a set, or specifying
{} as the attribute value in the SET window. The ILV returned is correct,
the construct is there with the correct id and datatype.
|
| 350.15 | Empty setof is getting decoded incorrectly | VERNA::V_GILBERT | | Tue Apr 09 1991 13:04 | 8 |
| Richard,
I just tried setting a Setof enumeration to {} and indeed it acc-vio'd NOT
on the encoding of the attribute BUT on the decode of p_out.
I will fix it as soon as possible.
Verna
|