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've got a characteristic attribute called Members defined as SET OF Fullname. When I encode it into ILV for the response argument of a SET or SHOW FCL displays it as: Members = { }%MCC-E-FULLNAME_ERROR, error in Fu ll Name value %MCC-E-FULLNAME_ERROR, error in Full Name value Usually, when in doubt as to how to encode something into ILV I look at how FCL encodes it to send it on a SET. But this time, even though the ILV I send back is exactly what FCL sends me, the error message appears. Here's the output from FCL logging. The command is ADD Stor Mgmt Domain a members = {archive test} DECmcc (X1.1.0) FCL PM Arguments before call_function: AES DUMP of ENTITY IN: depth=1 class code= 21 instance = � ILV DUMP of INP: [ 0 ] ( [ 1 ] ( [ 5 ] ( [ 1 ] 34 -- 4 [ 3 ] 00 [ 4 ] ( [ 1 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 00 00 ) ) ) ) ILV DUMP of INQ: in_q is NULL ATTRIBUTE PARTITION: 4 HANDLE STATE, before call: FIRST ******************************************* FCL PM Arguments on return from call_function: ILV DUMP of OUTP: [ 2 ] ( [ 1 ] ( [ 5 ] ( [ 1 ] 34 -- 4 [ 3 ] 00 [ 4 ] ( [ 1 ] aa 00 04 00 de 11 a0 aa f9 6f 56 de 8e 00 00 00 ) ) ) ) AES DUMP of ENTITY OUT: depth=1 class code= 21 instance = � HANDLE STATE, on return: FIRST CVR returned: %MCC-S-RESPONSE, success with response reply HANDLE STATE, at check_handle: 0 Stor Mgmt Domain DEC:.A Characteristics AT 20-SEP-1990 20:59:53 Values Added Successfully. Members = { }%MCC-E-FULLNAME_ERROR, error in Full Name value %MCC-E-FULLNAME_ERROR, error in Full Name value
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
340.1 | have you made any progress | GOSTE::CALLANDER | Wed Sep 26 1990 10:16 | 10 | |
Rich, It is hard to tell from the dump exactly what is going on. Have you found anything else out? Also how are you creating the fullname, are you simply testing doing an ILV copy? | |||||
340.2 | INFO: FullName wasn't what I needed | COOKIE::KITTELL | Richard - Architected Info Mgmt | Wed Sep 26 1990 12:27 | 13 |
Jill, Sorry, I thought I had updated this a couple of days ago. It turned out FullName wasn't what I really needed anyway. What I was after was FullEntityName ------ aka AES. That is working fine. So I'm not sure if there is really a problem here, or I was just misusing the FullName datatype. | |||||
340.3 | mcc_dns routines for future use | GOSTE::CALLANDER | Wed Sep 26 1990 12:28 | 5 | |
In the future the best way to handle any of the DNS names is to use the mcc_dns_xxx routines. You will get documentation on these with the next release of the SRM. | |||||
340.4 | Bug in Fullname parsing anyway | MAVIC::D_MOORE | Wed Sep 26 1990 15:26 | 14 | |
Re: .0 I assumed that you wanted SET OF FullEntity as a data type. However, trying exactly what you did was rather interesting. It turns out that, although "archive test" is an invalid FullName, it parses anyway on input. On output the error was caught. So, even though you did it just like FCL handled in_p, the Fullname value in in_p was bogus. This is being QAR'ed. Anyway, I'm glad to hear that things worked well using FullEntity. -keep those bugs coming in- - Dave |