Conference azur::mcc

  Mike,

  The best I can remember - there is no requirement that exception codes
  (or response codes for that matter) must be sequential.

  Be sure though that they do not define any exception *arguments* with
  a code of 1;  this is reserved for 'Problem Persistence'.  This is
  documented in the SRM, but not very well.

  /keith

Keith-

Are you sure about exeption argument code 1 being reserved?  I didn't
spend much time looking, but the SRM I have has got examples all over
the place with exeception args coded to 1.  (Maybe my reading of this is wrong,
check out pages 153(figure7.10), pgs 207, 208, 211.)

-Dave

Mike-

I don't remember if the Sample AM does things the 'right' way, but tell
your customer to avoid the lower numbers for AM-specific exceptions
(I don't know why 31
sticks in my head.)  The reason being that you often use the same exceptions
on all of your directives.  Although all of the numbers are 'free' for
you to use for most directives, the REGISTER directive for one expects
to have its numbers free.  If you keep all of your own AM-specific exception
numbers above that, then it will reduce the chance of there being a collision
now or in the future.

This is particularly important if the customer never takes advantage of the
MSL registration process, although they never caught any of my collisions...

Use the MS files provided in SYS$LIBRARY for REGISTER, SHOW etc. for your
global entity. (such as MCC_REGISTER_DIRECTIVE.MS)

-Dave

  Dave

RE: .2

  I know that for the Show directive exceptions - Argument code #1 is 
  reserved for 'problem persistence'.  This is needed by generic FM's like
  Alarms, Exporter, and Historian.  Problem Persistence allows the MM to
  tell the caller if the exception is a Permenent or Temporary Problem.

  According to the SRM (ch 15) - 'Common Arguments' apply to *any* exception;
  Specialized or Common Exceptions.

  The Example you mentioned (MSL for the EXAMPLE_AM) is *wrong* ... It should
  not be using an argument code of 1 for *any* exceptions.

  The SRM is wrong in the way it describes Problem Persistence.  If you do
  not return it in your exception, the caller must assume that this is
  a temporary problem -- the SRM says to assume a Permenent Problem 8(

  I have QAR'd this - but doubt that it will be corrected for SRM v1.2

RE: .3

  I would agree with staying away from low numbers.  If it was up to me,
  I would have set aside a few thousand number (high ones probably) as
  reserved to Digital for things like Problem Persistence...but that didn't
  happen 8(

  I don't know of any other reserved code (off the top of my head) like
  problem persistence.  I haven't heard of any problem with the # 31

  /keith

    
    re: .0
    
    Hi Mike,
    
    Nope.  No known restrictions forcing ordering of exceptions.  DNA4 and
    DNA5 both have large gaps in their exception codes for various
    situations.  The explanation takes a long time, but the upshot is that
    it doesn't matter.  You define it, and it works.
    
    Has a problem?  Which part specifically doesn't work?
    
    MSL Compile?  Dictionary enroll?  Parse table build?  Actual usage?
    
    DNA4/dNA5 has gaps and works fine, so we're not seeing this.
    
    So, where's the problem?  Then we can figure out what is hopefully a
    pretty small problem (even better, maybe an obscure mistake!).
    
    -Jim
    

There is no ordering requirement on exceptions or exception arguments.
"Specialized Exceptions" and their arguments are as unique as other
definitions in an MCC MS.  

The MM's private exceptions are returned with a CVR of 
MCC_S_SPECIALIZED_EXCEPTION, and the PMs will go to the exception definition
under the directive, under the entity tree in question, and to the 
arguments defined for it.

The two common exception arg. data types are no longer defined as data types
in v1.2, and if you want to use them in your SPECIALIZED exceptions, you must
define them as types (enumerations) in your own MS.  Problem Persistence
and Entity Existence are defined in section 15.2 of the v1.2 SRM.  Note that
Common Exceptions have these defined, and since the Common Exceptions are
always available to an MM, you can confuse all the code by not copying the 
definitions correctly (and then using them in both common and specialized
exceptions).  Yes, this is a problem waiting to happen if MMs don't
register their MS's or the Registry doesn't catch these conflicts.

Since these different exceptions are in different branches of the dictionary,
it should not matter if there is a "Specialized Exception" or a "Specialized 
Exception" Argument with the same id code as a Common Exception, or Common
Exception Argument.  Different Directives can use the same codes for
different Specialized Exceptions.

But to really make things confusing, the Standard Directive Templates in
ch. 15 of the SRM have Standard Specialized Exceptions.  These are not
in the COMMON G.E. and must be included into _your MM's_ MS for each 
Standard Directive Definition.  Should your MM require additional 
specialized exception codes for a standard directive, their codes DO need 
to start somewhere after these codes.  Gaps in the code space don't matter.

The SRM has never been very clear on this, and is unlikely to get clearer.
However, reading from an evolutionary viewpoint, I think the SRM v1.2 
descriptions are improved over v1.1 (and I didn't write them (:-))).

This sounds awfully pedantic, I hope it's worth the time I put in.

Ruth K.