Re: [Firebird-devel] Preventing error code collision

2015-07-27 Thread Ann Harrison

  On Sun, Jul 26, 2015 at 5:15 PM, Vlad Khorsun wrote:
 
   
Or is there a reason to ignore those higher bits for the facility
 and code?
 
  I have no idea why ENCODE_ISC_MSG written in this way.
 
CLASS_MASK seems to not be used anywhere, or at least I can't
 remember
ever having seen an error code with the bit 30 (warning) or 31
 (info)
set. Or is it used somewhere internally as an in-band channel?
 
  Looks like something planned at the past (before Firebird) but
 never used...
 
 27.07.2015 1:24, Ann Harrison wrote:
  Firebird was based on InterBase which was based on Rdb/ELN, an
 implementation of DEC's [standard(!)] relational
  interface.  As part of DEC's VAX software empire, DSRI used DEC's error
 message facility.  Every project had a code and
  used it as a prefix to its error messages.



 On Mon, Jul 27, 2015 at 4:14 AM, Vlad Khorsun hv...@users.sourceforge.net
  wrote:
Ann, thanks for explanation. But, it is still not clear why
 ENCODE_ISC_MSG
 is more strict than necessary. It limits number of facilities by 31
 (bitmask
 used allows 255) and number of codes per facility by 16383 (instead of
 65535).

Currently, we have no problem with it, just curious...


The high bits in the codes may have been intended for severity ... I really
don't remember.  The high bits in the facility were to distinguish
relational database errors from other DEC product errors.  I'd feel free to
use any of them.

Cheers,

Ann
--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-27 Thread Jim Starkey

On 7/27/2015 11:31 AM, Ann Harrison wrote:



27.07.2015 1:24, Ann Harrison wrote:
 Firebird was based on InterBase which was based on Rdb/ELN, an
implementation of DEC's [standard(!)] relational
 interface.  As part of DEC's VAX software empire, DSRI used
DEC's error message facility.  Every project had a code and
 used it as a prefix to its error messages.

On Mon, Jul 27, 2015 at 4:14 AM, Vlad Khorsun
hv...@users.sourceforge.net
mailto:hv...@users.sourceforge.net wrote:
   Ann, thanks for explanation. But, it is still not clear why
ENCODE_ISC_MSG
is more strict than necessary. It limits number of facilities by
31 (bitmask
used allows 255) and number of codes per facility by 16383
(instead of 65535).

   Currently, we have no problem with it, just curious...


The high bits in the codes may have been intended for severity ... I 
really don't remember.  The high bits in the facility were to 
distinguish relational database errors from other DEC product errors.  
I'd feel free to use any of them.




The only VMS documentation I could find identifies the high order bits 
as internal control flags.


A piece of almost forgotten history is that when Interbase first 
shipped, it had bi-directional interoperability of Rdb/VMS and Rdb/ELN.  
Something we liked to do was fire up Database on VMS and throw queries 
at Interbase on an Apollo.  Like Firebird, the Rdb y-valve loaded 
subsystems dynamically, so we could slip our remote (and embedded) 
subsystems under the DEC y-valve.  DEC didn't support TCP/IP (TCP/IP 
will blow over before we could do an implementation, which almost 
turned out to be true), so we had to use a third party TCP/IP.


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-27 Thread Vlad Khorsun
27.07.2015 1:24, Ann Harrison wrote:

 On Sun, Jul 26, 2015 at 5:15 PM, Vlad Khorsun wrote:


  
   Or is there a reason to ignore those higher bits for the facility and 
 code?

 I have no idea why ENCODE_ISC_MSG written in this way.

   CLASS_MASK seems to not be used anywhere, or at least I can't remember
   ever having seen an error code with the bit 30 (warning) or 31 (info)
   set. Or is it used somewhere internally as an in-band channel?

 Looks like something planned at the past (before Firebird) but never 
 used...


 Firebird was based on InterBase which was based on Rdb/ELN, an implementation 
 of DEC's [standard(!)] relational
 interface.  As part of DEC's VAX software empire, DSRI used DEC's error 
 message facility.  Every project had a code and
 used it as a prefix to its error messages.

   Ann, thanks for explanation. But, it is still not clear why ENCODE_ISC_MSG
is more strict than necessary. It limits number of facilities by 31 (bitmask
used allows 255) and number of codes per facility by 16383 (instead of 65535).

   Currently, we have no problem with it, just curious...

Regars,
Vlad

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-26 Thread Mark Rotteveel
On 25-7-2015 15:08, Vlad Khorsun wrote:
 25.07.2015 15:45, Mark Rotteveel wrote:
   
 How would I go about that if none of the errors in that facility are
 defined inside Firebird,

 We could define and reserve facility code for Jaybird and let you know it.

That would be great.

 and how can I know/calculate the range of error
 codes I can use (a quick glance at the code seems to suggest that each
 facility has 24 bits for error codes)?

 Look at src\common\msg_encode.h :

 const ISC_STATUS ISC_MASK = 0x1400;   // Defines the code as a valid 
 ISC code
 const ISC_STATUS FAC_MASK = 0x00FF;   // Specifies the facility where 
 the code is located
 const ISC_STATUS CODE_MASK= 0x;   // Specifies the code in the 
 message file
 const ISC_STATUS CLASS_MASK   = 0xF000;   // Defines the code as warning, 
 error, info, or other


Looking at the code in msg_encode.h, I notice that the above masks don't 
align with the definition of ENCODE_ISC_MSG:

return ((ISC_STATUS(facility  0x1F)  16) | (code  0x3FFF) | ISC_MASK);

Shouldn't that be:

return ISC_STATUS(((facility  16)  FAC_MASK) | (code  CODE_MASK) | 
ISC_MASK);

Or is there a reason to ignore those higher bits for the facility and code?

CLASS_MASK seems to not be used anywhere, or at least I can't remember 
ever having seen an error code with the bit 30 (warning) or 31 (info) 
set. Or is it used somewhere internally as an in-band channel?

Mark
-- 
Mark Rotteveel

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-26 Thread Vlad Khorsun
26.07.2015 12:08, Mark Rotteveel wrote:
 On 25-7-2015 15:08, Vlad Khorsun wrote:
 25.07.2015 15:45, Mark Rotteveel wrote:

 How would I go about that if none of the errors in that facility are
 defined inside Firebird,

  We could define and reserve facility code for Jaybird and let you know 
 it.

 That would be great.

   Facility code 26, name JAYBIRD.

 and how can I know/calculate the range of error
 codes I can use (a quick glance at the code seems to suggest that each
 facility has 24 bits for error codes)?

  Look at src\common\msg_encode.h :

 const ISC_STATUS ISC_MASK= 0x1400;   // Defines the code as a valid 
 ISC code
 const ISC_STATUS FAC_MASK= 0x00FF;   // Specifies the facility where 
 the code is located
 const ISC_STATUS CODE_MASK   = 0x;   // Specifies the code in the 
 message file
 const ISC_STATUS CLASS_MASK  = 0xF000;   // Defines the code as warning, 
 error, info, or other


 Looking at the code in msg_encode.h, I notice that the above masks don't
 align with the definition of ENCODE_ISC_MSG:

 return ((ISC_STATUS(facility  0x1F)  16) | (code  0x3FFF) | ISC_MASK);

 Shouldn't that be:

 return ISC_STATUS(((facility  16)  FAC_MASK) | (code  CODE_MASK) |
 ISC_MASK);

 Or is there a reason to ignore those higher bits for the facility and code?

   I have no idea why ENCODE_ISC_MSG written in this way.

 CLASS_MASK seems to not be used anywhere, or at least I can't remember
 ever having seen an error code with the bit 30 (warning) or 31 (info)
 set. Or is it used somewhere internally as an in-band channel?

   Looks like something planned at the past (before Firebird) but never used...

Regards,
Vlad

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-26 Thread Ann Harrison
On Sun, Jul 26, 2015 at 5:15 PM, Vlad Khorsun hv...@users.sourceforge.net
wrote:


 
  Or is there a reason to ignore those higher bits for the facility and
 code?

I have no idea why ENCODE_ISC_MSG written in this way.

  CLASS_MASK seems to not be used anywhere, or at least I can't remember
  ever having seen an error code with the bit 30 (warning) or 31 (info)
  set. Or is it used somewhere internally as an in-band channel?

Looks like something planned at the past (before Firebird) but never
 used...


Firebird was based on InterBase which was based on Rdb/ELN, an
implementation of DEC's [standard(!)] relational interface.  As part of
DEC's VAX software empire, DSRI used DEC's error message facility.  Every
project had a code and used it as a prefix to its error messages.

Cheers,

Ann
--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] Preventing error code collision

2015-07-25 Thread Mark Rotteveel
Up to now Jaybird has always used the Firebird error codes, or specific 
error messages defined in code.

I am currently looking into defining some Jaybird specific error codes, 
with associated messages and SQL states. To prevent collisions with 
future error codes in Firebird, I'd like to know if using codes below 
3 would be sufficient to prevent collision, or would it be 
better to follow the same formal rules as used inside Firebird to 
generate error codes (eg reserve a facility code for Jaybird)?

Mark
-- 
Mark Rotteveel

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-25 Thread Vlad Khorsun
25.07.2015 14:57, Mark Rotteveel wrote:
 Up to now Jaybird has always used the Firebird error codes, or specific
 error messages defined in code.

 I am currently looking into defining some Jaybird specific error codes,
 with associated messages and SQL states.

   Are you going to report is using Firebird API ? Are you going to add
Jaybird specific messages into firebird.msg ?

 To prevent collisions with
 future error codes in Firebird, I'd like to know if using codes below
 3 would be sufficient to prevent collision, or would it be
 better to follow the same formal rules as used inside Firebird to
 generate error codes (eg reserve a facility code for Jaybird)?

   I think, facility is what you need.

Regards,
Vlad


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-25 Thread Dmitry Yemanov
25.07.2015 15:16, Vlad Khorsun wrote:

 To prevent collisions with
 future error codes in Firebird, I'd like to know if using codes below
 3 would be sufficient to prevent collision, or would it be
 better to follow the same formal rules as used inside Firebird to
 generate error codes (eg reserve a facility code for Jaybird)?

  I think, facility is what you need.

I second that.


Dmitry


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Preventing error code collision

2015-07-25 Thread Mark Rotteveel
On 25-7-2015 14:16, Vlad Khorsun wrote:
 25.07.2015 14:57, Mark Rotteveel wrote:
 Up to now Jaybird has always used the Firebird error codes, or specific
 error messages defined in code.

 I am currently looking into defining some Jaybird specific error codes,
 with associated messages and SQL states.

 Are you going to report is using Firebird API ? Are you going to add
 Jaybird specific messages into firebird.msg ?

Jaybird doesn't use firebird.msg, I occasionally export the error 
messages and sqlstates from a Firebird build to the 
isc_error_msg.properties and isc_error_sqlstates.properties of Jaybird 
(and the error code constants to ISCConstants.java). However, the 
Jaybird specific error codes, error messages and sqlstate mapping will 
be within Jaybird itself.

I want to reuse (extend) the existing error message mechanism inside 
Jaybird to obtain the messages and sqlstate mappings from multiple 
sources and that means that I have to avoid collisions.

 To prevent collisions with
 future error codes in Firebird, I'd like to know if using codes below
 3 would be sufficient to prevent collision, or would it be
 better to follow the same formal rules as used inside Firebird to
 generate error codes (eg reserve a facility code for Jaybird)?

 I think, facility is what you need.

How would I go about that if none of the errors in that facility are 
defined inside Firebird, and how can I know/calculate the range of error 
codes I can use (a quick glance at the code seems to suggest that each 
facility has 24 bits for error codes)?

Mark
-- 
Mark Rotteveel

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel