Issue 1969: Handling of minor codes for standard exceptions underspecified (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly underspecified. The text in 3.17.2 doesn"t actually mention the OMG space explicitly; it should. Also, the definition of the partitioning of the minor code, at the beginning of 3.17, is hopelessly vague -- what ``high order bits"" are used, what ``low order bits""? What"s the policy for obtaining a new vendor registration? Resolution: I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c Revised Text: Actions taken: September 23, 1998: received issue August 19, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 23 Sep 1998 17:35:22 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: handling of minor codes for standard exceptions underspecified References: <3606693A.BED3C7CC@fpk.hp.com> <8q1i4=AB0KGWEJdZRL@holmes.parc.xerox.com> <3607AA59.EAFEF4B2@fpk.hp.com> <360938C5.1B0AFCC1@fpk.hp.com> <36095651.9BBB7905@fpk.hp.com> Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly underspecified. The text in 3.17.2 doesn't actually mention the OMG space explicitly; it should. Also, the definition of the partitioning of the minor code, at the beginning of 3.17, is hopelessly vague -- what ``high order bits'' are used, what ``low order bits''? What's the policy for obtaining a new vendor registration? Bill Return-Path: From: Jeffrey Mischkinsky Subject: Re: handling of minor codes for standard exceptions underspecified To: janssen@parc.xerox.com (Bill Janssen) Date: Wed, 23 Sep 1998 22:27:23 -0700 (PDT) Cc: orb_revision@omg.org, interop@omg.org, juergen@omg.org 'Bill Janssen' writes: > > Looking at ptc-98-08-07, I find the discussion of minor codes > hopelessly > underspecified. The text in 3.17.2 doesn't actually mention the OMG > space explicitly; it should. Also, the definition of the > partitioning > of the minor code, at the beginning of 3.17, is hopelessly vague -- > what > ``high order bits'' are used, what ``low order bits''? What's the > policy for obtaining a new vendor registration? > > Bill I don't think things are quite as hopeless as first appears. The definition of the minor code (VMCID) was well specified in CORBA 2.2 (i didn't look further back than that), albeit in a different spot. The definition is in section 4.2.2 of the giop chapter (chap 13 in 2.2, and chap 15 in 2.3) which deals with the on the wire representation of system exceptions as part of reply status. It appears to me that all that is missing in 3.17.2 and 3.17 is a cross reference, as well as the officially assigned tag which needs to be filled in by OMG staff. Both of these are editorial in nature, and should NOT require assigning of an issue. The policy is the usual, apply to the omg for a VMCID. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: Sender: jis@fpk.hp.com Date: Thu, 24 Sep 1998 10:28:23 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Jeffrey Mischkinsky Cc: Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809240527.WAA11823@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > > 'Bill Janssen' writes: > > > > Looking at ptc-98-08-07, I find the discussion of minor codes > hopelessly > > underspecified. The text in 3.17.2 doesn't actually mention the > OMG > > space explicitly; it should. Also, the definition of the > partitioning > > of the minor code, at the beginning of 3.17, is hopelessly vague > -- what > > ``high order bits'' are used, what ``low order bits''? What's the > > policy for obtaining a new vendor registration? > > > > Bill > > I don't think things are quite as hopeless as first appears. > > The definition of the minor code (VMCID) was well specified in CORBA > 2.2 > (i didn't look further back than that), albeit in a different spot. > > The definition is in section 4.2.2 of the giop chapter (chap 13 in > 2.2, > and chap 15 in 2.3) which deals with the on the wire representation > of > system exceptions as part of reply status. > > It appears to me that all that is missing in 3.17.2 and 3.17 is a > cross > reference, as well as the officially assigned tag which needs to be > filled in > by OMG staff. > > Both of these are editorial in nature, and should NOT require > assigning > of an issue. > > The policy is the usual, apply to the omg for a VMCID. We can apply a quick editorial fix in 2.3a as suggested by Jeff. But even after that it would be good to come up with a proper paragraph describing the "minor" field for Chapter 3. This will of course be based on what is there in Chapter 15, but for completeness, the para in Chapter 3 should be in terms of concepts presented in Chapter 3 i.e. the "minor" field of ex_body. So I think we should do both what Jeff suggest immediately, and raise an issue to fix Section 3.17/3.17.1/3.17.2 in the RTF 2.4 timeframe. Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Fri, 25 Sep 1998 00:42:28 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Jeffrey Mischkinsky , Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified On Thu, 24 Sep 1998, Jishnu Mukerji wrote: > > We can apply a quick editorial fix in 2.3a as suggested by Jeff. But > even after that it would be good to come up with a proper paragraph > describing the "minor" field for Chapter 3. This will of course be > based > on what is there in Chapter 15, but for completeness, the para in > Chapter 3 should be in terms of concepts presented in Chapter 3 > i.e. the > "minor" field of ex_body. So I think we should do both what Jeff > suggest > immediately, and raise an issue to fix Section 3.17/3.17.1/3.17.2 in > the > RTF 2.4 timeframe. Whilst we are at it, another good idea would be to define symbolic constants for the various minor codes. Right now, I end up with lots of magic numbers in my code. Also, having to mask out bits of the code myself isn't very nice. It would be nice if the language mappings were to offer a little help for that. Cheers, Michi. Return-Path: Date: Thu, 24 Sep 1998 12:15:17 -0400 From: Bob Kukura Organization: IONA Technologies To: Michi Henning CC: Jishnu Mukerji , Jeffrey Mischkinsky , Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: Michi Henning wrote: > > On Thu, 24 Sep 1998, Jishnu Mukerji wrote: > > > > > We can apply a quick editorial fix in 2.3a as suggested by > Jeff. But > > even after that it would be good to come up with a proper > paragraph > > describing the "minor" field for Chapter 3. This will of course be > based > > on what is there in Chapter 15, but for completeness, the para in > > Chapter 3 should be in terms of concepts presented in Chapter 3 > i.e. the > > "minor" field of ex_body. So I think we should do both what Jeff > suggest > > immediately, and raise an issue to fix Section 3.17/3.17.1/3.17.2 > in the > > RTF 2.4 timeframe. > > Whilst we are at it, another good idea would be to define symbolic > constants for the various minor codes. Right now, I end up with lots > of magic numbers in my code. Also, having to mask out bits of the > code > myself isn't very nice. It would be nice if the language mappings > were > to offer a little help for that. I, too, was going to suggest consts for the standard minor codes. I was also wandering if it would be best to keep the standard minor codes orthogonal to the standard exception types. What I mean is that a particular minor code value should not have different meanings for different exception types. This would simplify mapping standard system exception instances to text, and might avoid a lot of confusion. It will be too late to change this after CORBA 2.3 is published, and assigning distinct codes now might be considered editorial, since they have to be reassigned from the OMG VMCID (which is not 0) anyway. Anyone agree or dissagree? -Bob > > Cheers, > > > Michi. Return-Path: Date: Thu, 24 Sep 1998 13:50:14 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bob Kukura CC: Michi Henning , Jishnu Mukerji , Jeffrey Mischkinsky , Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <360A7015.93CB7C7E@iona.com> Bob Kukura wrote: > > I, too, was going to suggest consts for the standard minor codes. > > I was also wandering if it would be best to keep the standard minor > codes orthogonal to the standard exception types. What I mean is > that > a > particular minor code value should not have different meanings for > different exception types. This would simplify mapping standard > system > exception instances to text, and might avoid a lot of confusion. It > will be too late to change this after CORBA 2.3 is published, and > assigning distinct codes now might be considered editorial, since > they > have to be reassigned from the OMG VMCID (which is not 0) anyway. > Anyone agree or dissagree? Thanks for bringing this up. I strongly support assigning the minor codes in a way orthogonal from the major codes, and doing it now before it is too late. I also support the idea of assigning constants for the OMG specified minor codes. Return-Path: Date: Thu, 24 Sep 1998 16:31:29 -0400 From: Bob Kukura Organization: IONA Technologies To: Jeffrey Mischkinsky CC: Paul H Kyzivat , michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809241837.LAA18057@wheel.dcn.davis.ca.us> Jeff, Jeffrey Mischkinsky wrote: > > 'Paul H Kyzivat' writes: > > > > > > Bob Kukura wrote: > > > > > > I, too, was going to suggest consts for the standard minor > codes. > > > > > > I was also wandering if it would be best to keep the standard > minor > > > codes orthogonal to the standard exception types. What I mean > is that > > > a > > > particular minor code value should not have different meanings > for > > > different exception types. This would simplify mapping standard > > > system > > > exception instances to text, and might avoid a lot of > confusion. It > > > will be too late to change this after CORBA 2.3 is published, > and > > > assigning distinct codes now might be considered editorial, > since they > > > have to be reassigned from the OMG VMCID (which is not 0) > anyway. > > > Anyone agree or dissagree? > > > > Thanks for bringing this up. I strongly support assigning the > minor > > codes in a way orthogonal from the major codes, and doing it now > before > > it is too late. > > This is clearly NOT an editorial change. I'm not so sure. Isn't it the editor's job to get official minor codes assigned for these things? I'm not aware of a policy having been established for OMG-standard minor codes, so one is needed. I don't really care so much whether the policy is to use a single orthogonal minor code space or lots of separate minor code spaces, but a consistent policy is needed now, and I'm not aware that one exists. > > And it is too late, in the sense > that this has already been adopted and was published in the CORBA > 2.2 > spec. I know of at least one vendor who has already implemented the > minor exception codes according to the specification. A very careful search of CORBA 2.2 turned up absolutely no standard minor codes, nor even a standard VMCID for OMG-standard minor codes. Am I missing something? Is an OMG standard VMCID defined in another spec? If so, it would seem this would need to incorporated into CORBA 2.3, and I'd appreciate if someone would tell me what the VMCID is and where its specified. Assuming it doesn't already exist, how could defining an OMG VMCID now and defining the policy for allocating minor codes from this VMCID break any existing ORB? By the way, CORBA 2.2 and CORBA 2.3 clearly say that VMCID=0 can be used by anyone for anything and is deprecated. This is because various ORBs aleady were using this space in incompatable ways. An OMG VMCID had better not have a value of 0. I've always understood the minor codes in specs that use VMCID=0 to be temporary. > > (Of course, I suppose there is nothing to prevent someone from > making > a formal proposal in the 2.4 Core RTF to make this change. And we > could > then discuss the pros/cons, whether this is out of scope, etc., > etc.) > > The intent of the proposal which > added the minor exception code "standardization" was to have n > minor code > spaces, one for each system exception. This provides upto 4096 minor > codes for each standard system exception. (I suppose if we run out > of > space in the OMG allocated id, we can always allocate another > one--it's > not likely that we'll run out of numbers). Sure, we could have up to 4096 minor codes per exception, but nothing requires OMG or anyone else allocating a VMCID to do it that way. > > The intent was not to create a parallel set of system exceptions > which is > essentially the effect of saying that there is one name space for > all minor > exception codes. > > >From a purely practical point of view, it will be easier to > maintain > a seperate (hopefully) small table of standard minor codes for each > system exception. This way when someone wants to define a new one in > a > submission (or RTF), they don't have to figure out what is the > highest code > that's ever been allocated. The chances of "colliding" with others > are reduced. I disagree on this one. Lots of small tables seems harder to deal with than one larger table. I'm not strongly attached to a single minor code table, but it seems we need to choose which way to go. > > > > > I also support the idea of assigning constants for the OMG > specified > > minor codes. > > sure, we could do that. (If someone wants to do the work.) It's not > essential, > but would make coding a bit easier. Of course to prevent name > collisions > they'd probably have to look something like EXCEPTIONNAME_MINORNAME > > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 > jeffm@visigenic.com +1 650-358-3049 -Bob Return-Path: From: Jeffrey Mischkinsky Subject: Re: handling of minor codes for standard exceptions underspecified To: paulk@noblenet.com (Paul H Kyzivat) Date: Thu, 24 Sep 1998 11:37:33 -0700 (PDT) Cc: kukura@iona.com, michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org 'Paul H Kyzivat' writes: > > > Bob Kukura wrote: > > > > I, too, was going to suggest consts for the standard minor codes. > > > > I was also wandering if it would be best to keep the standard > minor > > codes orthogonal to the standard exception types. What I mean is > that > > a > > particular minor code value should not have different meanings for > > different exception types. This would simplify mapping standard > > system > > exception instances to text, and might avoid a lot of confusion. > It > > will be too late to change this after CORBA 2.3 is published, and > > assigning distinct codes now might be considered editorial, since > they > > have to be reassigned from the OMG VMCID (which is not 0) anyway. > > Anyone agree or dissagree? > > Thanks for bringing this up. I strongly support assigning the minor > codes in a way orthogonal from the major codes, and doing it now > before > it is too late. This is clearly NOT an editorial change. And it is too late, in the sense that this has already been adopted and was published in the CORBA 2.2 spec. I know of at least one vendor who has already implemented the minor exception codes according to the specification. (Of course, I suppose there is nothing to prevent someone from making a formal proposal in the 2.4 Core RTF to make this change. And we could then discuss the pros/cons, whether this is out of scope, etc., etc.) The intent of the proposal which added the minor exception code "standardization" was to have n minor code spaces, one for each system exception. This provides upto 4096 minor codes for each standard system exception. (I suppose if we run out of space in the OMG allocated id, we can always allocate another one--it's not likely that we'll run out of numbers). The intent was not to create a parallel set of system exceptions which is essentially the effect of saying that there is one name space for all minor exception codes. >From a purely practical point of view, it will be easier to maintain a seperate (hopefully) small table of standard minor codes for each system exception. This way when someone wants to define a new one in a submission (or RTF), they don't have to figure out what is the highest code that's ever been allocated. The chances of "colliding" with others are reduced. > > I also support the idea of assigning constants for the OMG specified > minor codes. sure, we could do that. (If someone wants to do the work.) It's not essential, but would make coding a bit easier. Of course to prevent name collisions they'd probably have to look something like EXCEPTIONNAME_MINORNAME jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: Date: Thu, 24 Sep 1998 18:08:33 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bob Kukura CC: Jeffrey Mischkinsky , michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809241837.LAA18057@wheel.dcn.davis.ca.us> <360AAC21.7D6149DA@iona.com> Bob Kukura beat me to a reply. He did the research into 2.2 that I was otherwise going to have to do before replying. (Thanks Bob!) I don't have anything to add to what he said, so I will just 2nd it. Return-Path: From: Jeffrey Mischkinsky Subject: Re: handling of minor codes for standard exceptions underspecified To: kukura@iona.com (Bob Kukura) Date: Thu, 24 Sep 1998 14:50:39 -0700 (PDT) Cc: paulk@noblenet.com, michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org 'Bob Kukura' writes: > > Jeff, > > > I'm not so sure. Isn't it the editor's job to get official minor > codes > assigned for these things? I'm not aware of a policy having been > established for OMG-standard minor codes, so one is needed. I don't > really care so much whether the policy is to use a single orthogonal > minor code space or lots of separate minor code spaces, but a > consistent > policy is needed now, and I'm not aware that one exists. Submissions/RTF's assign the minor codes (the low order 12 bits), just as they do the major codes. The only thing the OMG assigns is the VMCID (the high order 20 bits). And that is in fact what has been done. > > > > > And it is too late, in the sense > > that this has already been adopted and was published in the CORBA > 2.2 > > spec. I know of at least one vendor who has already implemented > the > > minor exception codes according to the specification. > > A very careful search of CORBA 2.2 turned up absolutely no standard > minor codes, nor even a standard VMCID for OMG-standard minor > codes. > Am I missing something? Is an OMG standard VMCID defined in another > spec? If so, it would seem this would need to incorporated into > CORBA > 2.3, and I'd appreciate if someone would tell me what the VMCID is > and > where its specified. Hi Bob, Here's a copy of my response to Bill: >>The definition of the minor code (VMCID) was well specified in CORBA 2.2 >>(i didn't look further back than that), albeit in a different spot. >>The definition is in section 4.2.2 of the giop chapter (chap 13 in 2.2, >>and chap 15 in 2.3) which deals with the on the wire representation of >>system exceptions as part of reply status. >>It appears to me that all that is missing in 3.17.2 and 3.17 is a cross >>reference, as well as the officially assigned tag which needs to be filled in >>by OMG staff. This is the version of the corba 2.2 book i have on my machine. > > By the way, CORBA 2.2 and CORBA 2.3 clearly say that VMCID=0 can be > used > by anyone for anything and is deprecated. This is because various > ORBs > aleady were using this space in incompatable ways. An OMG VMCID had > better not have a value of 0. I've always understood the minor > codes in > specs that use VMCID=0 to be temporary. That's correct. The OMG's official VMCID has to be something other than 0. -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: Sender: jis@fpk.hp.com Date: Thu, 24 Sep 1998 18:15:22 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Bob Kukura Cc: Jeffrey Mischkinsky , Paul H Kyzivat , michi@dstc.edu.au, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809241837.LAA18057@wheel.dcn.davis.ca.us> <360AAC21.7D6149DA@iona.com> > > > > And it is too late, in the sense > > that this has already been adopted and was published in the CORBA > 2.2 > > spec. I know of at least one vendor who has already implemented > the > > minor exception codes according to the specification. > > A very careful search of CORBA 2.2 turned up absolutely no standard > minor codes, nor even a standard VMCID for OMG-standard minor > codes. > Am I missing something? Is an OMG standard VMCID defined in another > spec? If so, it would seem this would need to incorporated into > CORBA > 2.3, and I'd appreciate if someone would tell me what the VMCID is > and > where its specified. > > Assuming it doesn't already exist, how could defining an OMG VMCID > now > and defining the policy for allocating minor codes from this VMCID > break > any existing ORB? > > By the way, CORBA 2.2 and CORBA 2.3 clearly say that VMCID=0 can be > used > by anyone for anything and is deprecated. This is because various > ORBs > aleady were using this space in incompatable ways. An OMG VMCID had > better not have a value of 0. I've always understood the minor > codes in > specs that use VMCID=0 to be temporary. > As far as VMCID goes I am happy to editorially state that the OMG VMCID is 1. I did think for a moment about making it x80000, but then I heard the Java guys screaming in the distance in great agony.:-) Any comments? As for whether there is a single minor number space or a minor number space per exception, the only thing that I have available to me is the table that was handed to me for inclusion in Chapter 3, and I was given to understand that this was from an adopted spec IDL-Java? Portability?? which I don't know. Now this table has a couple of values already allocated in it and it appears to use the minor number space per system exception paradigm. So at least for now, until someone proves that this table is not from an adopted specification, I am reluctant to declare that the numbering scheme can be editorially dictated to be something other than what appears in that table. Unfortunately, the OMG archive server is currently down so I can't verify or unverify anything this afternoon. Finally, given that there is a bit of controversy surrounding this minor number space issue, I am not sure that making this an editorial change is a good idea anyway, while there are contrary opinions flying around on the matter. So once you guys resolve your differences and come up with a single proposal then we will see if that can be editorially incorporated. I will research the source of the table while you guys deck it out among yourselves, OK? Happy hunting.... Jishnu. BTW, why was poor Juergen in the CC list? I took him off, I hope none of you mind. I am sure he doesn't.:-) -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Thu, 24 Sep 1998 18:22:59 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jeffrey Mischkinsky CC: Bob Kukura , michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809242150.OAA28619@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > > Submissions/RTF's assign the minor codes (the low order 12 bits), > just > as > they do the major codes. The only thing the OMG assigns is the > VMCID > (the high order 20 bits). > > And that is in fact what has been done. [snip] > > > A very careful search of CORBA 2.2 turned up absolutely no > standard > > minor codes, nor even a standard VMCID for OMG-standard minor > codes. > > Am I missing something? Is an OMG standard VMCID defined in > another > > spec? If so, it would seem this would need to incorporated into > CORBA > > 2.3, and I'd appreciate if someone would tell me what the VMCID is > and > > where its specified. > > Hi Bob, > Here's a copy of my response to Bill: > > >>The definition of the minor code (VMCID) was well specified in > CORBA > 2.2 > >>(i didn't look further back than that), albeit in a different > spot. > > >>The definition is in section 4.2.2 of the giop chapter (chap 13 in > 2.2, > >>and chap 15 in 2.3) which deals with the on the wire > representation > of > >>system exceptions as part of reply status. > > >>It appears to me that all that is missing in 3.17.2 and 3.17 is a > cross > >>reference, as well as the officially assigned tag which needs to > be > filled in > >>by OMG staff. > > This is the version of the corba 2.2 book i have on my machine. Could you please say where a minor code value is specified in 2.2? I am not aware of any. BTW, has any vendor yet been assigned a VMCID? We made our request about a year ago and have been assured just this week by OMG staff that we will get our assignment soon. Needless to say our minor codes will have to change. Return-Path: Date: Thu, 24 Sep 1998 18:36:59 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jishnu Mukerji CC: Bob Kukura , Jeffrey Mischkinsky , michi@dstc.edu.au, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809241837.LAA18057@wheel.dcn.davis.ca.us> <360AAC21.7D6149DA@iona.com> <360AC47A.8346C446@fpk.hp.com> Jishnu Mukerji wrote: > As far as VMCID goes I am happy to editorially state that the OMG > VMCID > is 1. I did think for a moment about making it x80000, but then I > heard > the Java guys screaming in the distance in great agony.:-) Any > comments? I would prefer that it be something larger. For reasons that aren't worth discussing we are currently using minor codes that fall (sparsely) within VMCIDs 0-9. As noted earlier, once we get a VMCID assignment all of our codes will need to change, but I would be happier knowing that nothing will be officially assigned any time soon that clashes. If these numbers are assigned in a few years it won't matter. Return-Path: Date: Thu, 24 Sep 1998 15:34:30 PDT Sender: Bill Janssen From: Bill Janssen To: Jeffrey Mischkinsky , Jishnu Mukerji Subject: Re: handling of minor codes for standard exceptions underspecified CC: Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org References: <199809240527.WAA11823@wheel.dcn.davis.ca.us> <360A5707.2AB3E387@fpk.hp.com> Excerpts from direct: 24-Sep-98 Re: handling of minor codes.. Jishnu Mukerji@fpk.hp.co (2054*) > So I think we should do both what Jeff suggest > immediately, and raise an issue to fix Section 3.17/3.17.1/3.17.2 in > the > RTF 2.4 timeframe. Sounds good to me. Bill Return-Path: Date: Thu, 24 Sep 1998 15:36:19 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning , Bob Kukura Subject: Re: handling of minor codes for standard exceptions underspecified CC: Jishnu Mukerji , Jeffrey Mischkinsky , Bill Janssen , orb_revision@omg.org, interop@omg.org, juergen@omg.org References: <360A7015.93CB7C7E@iona.com> Excerpts from direct: 24-Sep-98 Re: handling of minor codes.. Bob Kukura@iona.com (1748*) > What I mean is that a > particular minor code value should not have different meanings for > different exception types. This would simplify mapping standard > system > exception instances to text, and might avoid a lot of confusion. I think this would be overly awkward to maintain. Bill Return-Path: From: Jeffrey Mischkinsky Subject: Re: handling of minor codes for standard exceptions underspecified To: paulk@noblenet.com (Paul H Kyzivat) Date: Thu, 24 Sep 1998 16:51:40 -0700 (PDT) Cc: kukura@iona.com, michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org 'Paul H Kyzivat' writes: > > > > > > A very careful search of CORBA 2.2 turned up absolutely no > standard > > > minor codes, nor even a standard VMCID for OMG-standard minor > codes. > > Could you please say where a minor code value is specified in 2.2? > I am not aware of any. sorry i misread the question, the corba 2.2 spec set up the system of defining VMCID codes. The first adopted submission to assign omg standard minor codes was the initial OBV specification. Some later specs--i'm not sure if they were RFP submissions or RTF work added some more. This is the source of the table that Jishnu was "handed". > BTW, has any vendor yet been assigned a VMCID? We made our request about > a year ago and have been assured just this week by OMG staff that we > will get our assignment soon. Needless to say our minor codes will have > to change. we got our's a long time ago, but it's a secret :-) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: Date: Thu, 24 Sep 1998 21:53:46 -0400 From: Bob Kukura Organization: IONA Technologies To: Jeffrey Mischkinsky CC: Paul H Kyzivat , michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809242351.QAA05292@wheel.dcn.davis.ca.us> Jeffrey Mischkinsky wrote: > > 'Paul H Kyzivat' writes: > > > > > > > > > A very careful search of CORBA 2.2 turned up absolutely no > standard > > > > minor codes, nor even a standard VMCID for OMG-standard minor > codes. > > > > Could you please say where a minor code value is specified in 2.2? > > I am not aware of any. > sorry i misread the question, > the corba 2.2 spec set up the system of defining VMCID codes. > > The first adopted submission to assign omg standard minor codes was > the initial OBV specification. > > Some later specs--i'm not sure if they were RFP submissions or RTF > work > added some more. > > This is the source of the table that Jishnu was "handed". Thanks for the info, Jeff. The traditional practice for specifications that need component, profile, or service context tags is to define them in the specification as "???" or "TBA" or something like that. The actual tag values are not assigned until later (hopefully before an official 1.0 version is published by OMG). When specifications need minor codes, it seems to me that a similar approach should be used, but it sounds like the writers of these specifications have so far been assigning the lower bits themselves. How do they ensure that these values will be available when some modified version of the spec is finally adopted, cleaned up, and published? Do they even expect those values to be used in the published version? What if two specs indpendently chose to use minor code 5, for instance (for the same exception, if that matters)? I hope we're not using separate VMCIDs for each specification. The mail from Jishnu leads me to believe that no VMCID has been officially assigned for OMG standard minor codes yet. I would certainly prefer that all the minor codes specified so far be defined editorially by Jishnu within a single OMG assigned VMCID. If this means some of the adopted lower bits from the various specs need to change, so be it. This should not be a problem, since noone could possibly have been using the official OMG VMCID yet. I sincerely hope that we end up with a definitive table somewhere in CORBA 2.3 listing all the assigned minor codes. This table should ideally contain const definitions for each minor code with meaningful names and with text describing the condition in which it is raised. Lets not repeat the same mistakes we made when originally defining the system exceptions. I don't think its reasonable for implementors or users to have to search the whole specification for minor codes. We should also expect lots of these things to be defined as new specifications are written and old ones are revised. Because no minor codes have been officially assigned yet, I'm still not convinced that assigning minor codes such that the same code isn't used for different meanings with different exceptions would be considered a non-editorial change. But I'm willing to go with the flow here. I've heard one other supporter of my suggestion to keep minor codes orthogonal from exception types, and two people opposed to it. I also reallize that the about to be adopted issue 778 resolution clearly treats each exception as having its own minor code space. If anyone else supports my suggestion, please speak up now, or be prepared to live with separate lists of minor codes for each standard system exception. > > > BTW, has any vendor yet been assigned a VMCID? We made our request > about > > a year ago and have been assured just this week by OMG staff that > we > > will get our assignment soon. Needless to say our minor codes will > have > > to change. > > we got our's a long time ago, but it's a secret :-) > > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 > jeffm@visigenic.com +1 650-358-3049 -Bob Return-Path: From: Jeffrey Mischkinsky Subject: Re: handling of minor codes for standard exceptions underspecified To: kukura@iona.com (Bob Kukura) Date: Thu, 24 Sep 1998 20:24:24 -0700 (PDT) Cc: paulk@noblenet.com, michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org 'Bob Kukura' writes: > > The traditional practice for specifications that need component, > profile, or service context tags is to define them in the > specification > as "???" or "TBA" or something like that. The actual tag values are > not > assigned until later (hopefully before an official 1.0 version is > published by OMG). > > When specifications need minor codes, it seems to me that a similar > approach should be used, but it sounds like the writers of these > specifications have so far been assigning the lower bits > themselves. > How do they ensure that these values will be available when some > modified version of the spec is finally adopted, cleaned up, and > published? Do they even expect those values to be used in the > published > version? What if two specs indpendently chose to use minor code 5, > for > instance (for the same exception, if that matters)? We started out specifying them, partly because getting tag values is a hassle, and partly because if there is a conflict in that 2 submissions are adopted simultaneously and they both attempt to define the same minor code value (for the same system exception), we've got plenty of RTF/editorial opportunities to take notice and fix. > I hope we're not > using separate VMCIDs for each specification. Nope. The intent was to use the same "omg standard VMCID" (not 0), which Jishnu is threatening to assign (at least until we use up all 4096 possible minor codes for one system exception). > > The mail from Jishnu leads me to believe that no VMCID has been > officially assigned for OMG standard minor codes yet. I would > certainly > prefer that all the minor codes specified so far be defined > editorially > by Jishnu within a single OMG assigned VMCID. If this means some of > the > adopted lower bits from the various specs need to change, so be it. There's no problem with overlap. > > I sincerely hope that we end up with a definitive table somewhere in > CORBA 2.3 listing all the assigned minor codes. This table should > ideally contain const definitions for each minor code with > meaningful > names and with text describing the condition in which it is raised. > Lets not repeat the same mistakes we made when originally defining > the > system exceptions. I don't think its reasonable for implementors or > users to have to search the whole specification for minor codes. We > should also expect lots of these things to be defined as new > specifications are written and old ones are revised. There is such a lovely table (Table 5-2) at the end of chapter 3. For each system exception it lists the defined minor exception codes and provides a short explanation. The relevant text in the body of the specification has more complete descriptions. Usually it says something like: if such-as-such occurs, the XYZ System Exception is raised with a minor code of nnn. If we wanted to be really fancy, we could embed cross-references in the table to all places in the spec where it requires that the system exception with that minor code be raised. (Gotta give the omg editor something to do :-) Currently no const definitions are provided, just the raw number, which is all that is needed for interopability and to write portable code. But, as i said before, we could certainly come up with symbolic names, though eventually there will be a lot. I assume we'd have to use some sort of a naming scheme such as MAJOR_MINOR, e.g. NO_IMPLEMENT_MISSING_VALIMP. > Because no minor codes have been officially assigned yet, They have been explicitly assigned and adopted already, so we'll have to make a change. > I'm still not > convinced that assigning minor codes such that the same code isn't > used > for different meanings with different exceptions would be considered > a > non-editorial change. But I'm willing to go with the flow here. > I've > heard one other supporter of my suggestion to keep minor codes > orthogonal from exception types, and two people opposed to it. I > also > reallize that the about to be adopted issue 778 resolution clearly > treats each exception as having its own minor code space. If anyone > else supports my suggestion, please speak up now, or be prepared to > live > with separate lists of minor codes for each standard system > exception. i think it will be easier in the long run. It will be less to keep track of, and ultimately less confusing. If we don't, we're going to wind up with stuff such as: minor code 432 NO_IMPLMENT, missing local value imp 576 OBJECT_NOT_EXIST, missing local value imp under condition xyz That won't be any easier to use or remember than major minor NO_IMLEMENT 1 missing local value imp OBJECT_NOT_EXIST 2 missing local value imp under condition xyz And tomorrow is the deadline... jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 Return-Path: Date: Fri, 25 Sep 1998 00:32:06 -0400 From: Bob Kukura Organization: IONA Technologies To: Jeffrey Mischkinsky CC: paulk@noblenet.com, michi@dstc.edu.au, jis@fpk.hp.com, janssen@parc.xerox.com, orb_revision@omg.org, interop@omg.org, juergen@omg.org Subject: Re: handling of minor codes for standard exceptions underspecified References: <199809250324.UAA15127@wheel.dcn.davis.ca.us> This should be the last message from me on this topic! Jeffrey Mischkinsky wrote: > > 'Bob Kukura' writes: > > > > The traditional practice for specifications that need component, > > profile, or service context tags is to define them in the > specification > > as "???" or "TBA" or something like that. The actual tag values > are not > > assigned until later (hopefully before an official 1.0 version is > > published by OMG). > > > > When specifications need minor codes, it seems to me that a > similar > > approach should be used, but it sounds like the writers of these > > specifications have so far been assigning the lower bits > themselves. > > How do they ensure that these values will be available when some > > modified version of the spec is finally adopted, cleaned up, and > > published? Do they even expect those values to be used in the > published > > version? What if two specs indpendently chose to use minor code > 5, for > > instance (for the same exception, if that matters)? > > We started out specifying them, partly because getting tag values is > a > hassle, and partly because if there is a conflict in that 2 > submissions are > adopted simultaneously and they both attempt to define the same > minor code > value (for the same system exception), we've got plenty of > RTF/editorial > opportunities to take notice and fix. > > > I hope we're not > > using separate VMCIDs for each specification. > > Nope. The intent was to use the same "omg standard VMCID" (not 0), > which Jishnu > is threatening to assign (at least until > we use up all 4096 possible minor codes for one system exception). Great! > > > > > The mail from Jishnu leads me to believe that no VMCID has been > > officially assigned for OMG standard minor codes yet. I would > certainly > > prefer that all the minor codes specified so far be defined > editorially > > by Jishnu within a single OMG assigned VMCID. If this means some > of the > > adopted lower bits from the various specs need to change, so be > it. > > There's no problem with overlap. > > > > I sincerely hope that we end up with a definitive table somewhere > in > > CORBA 2.3 listing all the assigned minor codes. This table should > > ideally contain const definitions for each minor code with > meaningful > > names and with text describing the condition in which it is > raised. > > Lets not repeat the same mistakes we made when originally defining > the > > system exceptions. I don't think its reasonable for implementors > or > > users to have to search the whole specification for minor codes. > We > > should also expect lots of these things to be defined as new > > specifications are written and old ones are revised. > > There is such a lovely table (Table 5-2) at the end of chapter 3. > For each system exception it lists the defined minor exception codes > and provides a short explanation. Most of this discussion could have been avoided if someone had pointed this out at the start. Its so small, I didn't notice it! I hope that the minor codes shown in this table will be updated (by Jishnu, editorially) to inlude the official VMCID. Users shouldn't have to do the math. > > The relevant text in the body of the specification has more complete > descriptions. Usually it says something like: > if such-as-such occurs, the XYZ System Exception is raised with a > minor > code of nnn. > > If we wanted to be really fancy, we could embed cross-references in > the > table to all places in the spec where it requires that the system > exception > with that minor code be raised. > (Gotta give the omg editor something to do :-) > > Currently no const definitions are provided, just the raw number, > which is > all that is needed for interopability and to write portable code. I'd still like to see consts added to the CORBA module. Putting raw numbers in code is bad enough, but typing these once the (non-0) VMCID is added will also be error prone. The table should then list the minor code and the name of the const. > > But, as i said before, we could certainly come up with symbolic > names, though > eventually there will be a lot. I assume we'd have to use some sort > of > a naming scheme such as MAJOR_MINOR, > e.g. NO_IMPLEMENT_MISSING_VALIMP. > > > Because no minor codes have been officially assigned yet, > > They have been explicitly assigned and adopted already, > so we'll have to make a change. > > > I'm still not > > convinced that assigning minor codes such that the same code isn't > used > > for different meanings with different exceptions would be > considered a > > non-editorial change. But I'm willing to go with the flow here. > I've > > heard one other supporter of my suggestion to keep minor codes > > orthogonal from exception types, and two people opposed to it. I > also > > reallize that the about to be adopted issue 778 resolution clearly > > treats each exception as having its own minor code space. If > anyone > > else supports my suggestion, please speak up now, or be prepared > to live > > with separate lists of minor codes for each standard system > exception. > > i think it will be easier in the long run. It will be less to keep > track of, > and ultimately less confusing. If we don't, we're going to wind up > with > stuff such as: > minor code > 432 NO_IMPLMENT, missing local value imp > 576 OBJECT_NOT_EXIST, missing local value imp under > condition xyz > > That won't be any easier to use or remember than > major minor > NO_IMLEMENT 1 missing local value imp > OBJECT_NOT_EXIST 2 missing local value imp under condition xyz > > And tomorrow is the deadline... Reason enough! > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 > jeffm@visigenic.com +1 650-358-3049 Thanks, -Bob