[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

908.0. "PROB: IMPM accvios when Defaulting Constructed Datatype" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Thu Apr 11 1991 13:43

V1.1 SSB

We'd like to be able to define default values for attributes that are
constructed datatypes. In most cases the default value is simply {},
but there are a few places where we'd like to specify a non-null default
value.

The MSL compiler won't accept DEFAULT = {} but it will take DEFAULT="{}".
From FCL the defaulting mechanism works fine, but it only has to send
the flag. The IMPM likes to display the default value as well, and is
getting an accvio when it tries.

Particulars:

When in the Set window for the object, I position the cursor over the
Policies Enabled field and use the middle-button menu to select the
Default Value. If the field holds a value from a previous operation it
is cleared, but the default value is not inserted. If OK is clicked the
operation is not performed because no fields appear to have been set.
If the middle-button menu is used to select the default value again:

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC
=00401FBD, PSL=03C00000

Just in case it was the null set that was causing the problem I tried
DEFAULT = "{Initialize on Prepare}" but it had the same behavior.

TYPE MediaLibraryPolicies = 24 (Vol Name Same as Cart Side 0 = 1,
                                Import Name Exceptions Prohibited = 2,
                                Media Name Same as Volume Name = 4,
                                Unlabeled Media Prohibited = 8,
                                User Init Prohibited = 16,
                                Defer Prepare Until Assign = 32,
                                Truncate on Prepare = 64,
                                Initialize on Prepare = 128,
                                Erase on Prepare = 256,
                                Assign All Base Sides at Once = 512,
                                Assign All Compound Sides at Once = 1024,
                                Erase on Discard = 2048
                               );

TYPE MediaLibraryPolicySet = 26 SET OF MediaLibraryPolicies;

         ATTRIBUTE Policies Enabled = 37 : MediaLibraryPolicySet
           SYMBOL = ATTR_POLICIES,
           DEFAULT = "{}"
         END ATTRIBUTE Policies Enabled;

T.R	Title	User	Personal Name	Date	Lines
908.1	It might be ILV, but if only the IMPM bombs ??	TOOK::KOHLS	Ruth Kohls	`Thu Apr 11 1991 18:05`	14
	I have no idea whether ILV has any bearing on this for the IMPM, but currently the ILV routines do not support Implementation Default for Constructor (set, sequence, et al) types. Someone put in a QAR a while ago against the SRM, but I missed it until today. Unfortunately, the current IMPLDEFAULT mechanism won't work for constructors. The first workaround I thought of won't work either, and the second workaround is getting a little complex. Fortunately, I'm thinking (smell the smoke?) about ILV and ASN right now, so I'll toss this problem into the stew. Ruth
908.2	why I thought it worked from FCL	COOKIE::KITTELL	Richard - Architected Info Mgmt	`Fri Apr 12 1991 11:10`	31
	RE: .1 >Unfortunately, the current IMPLDEFAULT mechanism won't work for constructors. Well, it does kinda work for the common case, that of the default being an empty set. But I agree that is more of an accident than anything. Given the Policies Enabled attribute described in the basenote, I can issue MCC>SET MediaLibrary mumble Policies Enabled The ILV generated by FCL is [ 0 ] ( [ 1 ] ( [ 37 ] ( [ 1 ] 34 -- 4 [ 3 ] 00 [ 4 ] ( ) ) ) ) So when doing the ILV decode I open the construct as usual and get ILVEOC on the first mcc_ilv_get_id. That leaves my in-memory structures for the attribute describing an empty set, which is the default value. I realize that isn't the way the defaulting mechanism should work, but it did a good job of masquerading as the real thing.
908.3	The AM can do the defaulting....	TOOK::CAREY		`Fri Apr 12 1991 11:31`	31
	Yeah, the QAR against the SRM on this issue came from me (at least one of them did). If you'd like to set a default value for a constructed type your best bet right now is to "assume a reasonable value" if the argument isn't supplied. That is, your AM can know about this information. In DECnet Phase IV we've considered using this approach a couple of times for use on first use of a value (which is usually pretty easy to guess at in DECnet). The default values in the dictionary are intended to be "likely defaults" for use only by the Iconic Map to display to the user. They are never intended to be passed across the MCC interface. The idea is that a specific entity may know how it wants to set its default values better than a generic director, and must get the opportunity to do so. To get these defaults in general working, you may want to provide that fraction of the entity's behavior in your Access Module. That is, notice "implementation default" attributes, and replace them in the parameter list with the defaults you have selected. This isn't necessarily trivial, but it allows you to project a nice behavior onto an entity that may not know a whole lot about being nice. The other side of the coin is DECnet/OSI, where the entities are expected to be capable of retaining enough information to know their own defaults and want the right to set it themselves. -Jim Carey
908.4		COOKIE::KITTELL	Richard - Architected Info Mgmt	`Fri Apr 12 1991 17:13`	16
	RE: .2 > To get these defaults in general working, you may want to provide that > fraction of the entity's behavior in your Access Module. That is, Jim, The "defaults in general" are working just fine, and weren't at all difficult to implement. And the AM automatically supplies "initial values" for most attributes. It differentiates between initial values and default values. Default values are only applicable to settable attributes, and are applied when an instance is created and whenever mcc_ilv_get returns the right code. Initial values are applied only when an instance is created.
908.5	actually an FCL bug makes it work...	TOOK::CALLANDER		`Fri Apr 12 1991 17:31`	6
	FCL is supposed to be trying to send the flag, like IMPM does, but in one case we didn't get the code in place so....we pick up the string from the default field in the dictionary and convert it into an ilv encoded value just like a user typed it in. In reality this is listed as a bug, and the FCL PM has been qared on it.