Issue 626: CORBA sequence IDL type in COBOL (cobol-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Under the current standard, the sequence accessor functions have no way of knowing how big each element in a sequence is.Add another element to the sequence type describing length of elements Resolution: resolved, close issue Revised Text: Actions taken: July 16, 1997: received issue February 25, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: Chris Steele To: "'cobol-rtf@omg.org'" Cc: Mas Yokota Date: Wed, 16 Jul 97 11:22:00 P Encoding: 55 TEXT Regarding the CORBA sequence IDL type in COBOL: Under the current standard, the sequence accessor functions have no way of knowing how big each element in a sequence is. Here is the current structure of an unbounded sequence: 01 seq1 is typedef. 03 seq-maximum type CORBA-long. 03 seq-length type CORBA-long. 03 seq-buffer usage POINTER. where seq-maximum is the size of the allocated array (in number of elements) that seq-buffer points to, seq-length is the current number of items in this array, and seq-buffer points to the array itself. The accessor functions have the following signature: call "CORBA-sequence-element-get" using a-CORBA-sequence, a-CORBA-unsigned-long, a-element-type. where a-CORBA-unsigned-long refers to the index of the requested item. Now, CORBA-sequence-element-get (and by the same token, CORBA-sequence-element-set) has no idea how big each item in the array is, so it can't really index into the array and get the requested item. In June of 1997, Mr. Gamble and I traded ideas on the subject, and we concluded that our favorite solution was to add another element to the sequence type that describes the length of the sequence elements. If anyone wishes, I could dig up the actual correspondence. Anyway, here is the new structure: 01 seq2 is typedef. 03 seq-maximum type CORBA-long. 03 seq-length type CORBA-long. 03 seq-element-size type CORBA-long. 03 seq-buffer usage POINTER. Now, seq-element-size contains the size of each element, in bytes, so that the accessors can do their thing. This is the solution that I implemented into the product that I am working on. If there is a better solution, I'm certainly open to it. However, I just thought I'd put in my two cents. Thank you, Chris Steele Unitech Research, Inc. csteele@unitech.com Return-Path: From: "Karam Singh" To: "'cobol-rtf@omg.org'" , "Chris Steele" Cc: "Mas Yokota" Subject: Re: Date: Thu, 17 Jul 1997 08:39:26 +0100 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Hello Chris, Given the current COBOL sequence support structure there is also no way for a generic sequence accessor function to know the type of the sequence either. If the unmarshalling/marshalling of the sequence data to/from COBOL format is postponed until element access time (when type information may no longer be available) then this is also a problem. I worked around this by adding a typecode pointer to the unbounded sequence structure instead of the size. Given a typecode I can determine the size. So the structure might look like: 01 seq1 is typedef. 03 sequence-maximum type CORBA-Long. 03 sequence-length type CORBA-Long. 03 sequence-buffer usage pointer. 03 sequence-type type CORBA-Typecode. (Please forgive the lack of indenting. My 'new' mailer won't let me insert leading spaces or tabs!!) This is a similar solution to what you have proposed but now gives the sequence some type information which may or may not be useful depending on when the data is converted to/from COBOL format. In the work I am doing I have chosen to defer converting to/from COBOL format until element access time. Cheers, Karam. +------------------------------------------------------------------------+ | Karam P. Singh Phone: +353-1-662-5255 x2429 | | IONA Technologies Fax : +353-1-662-5244 | | 8-10 Lower Pembroke St. EMail: ksingh@iona.com | | Dublin 2, Ireland WWW : www.iona.com | +------------------------------------------------------------------------+ | Orbix 2.2 - order your copy - http://www.iona.com/orbix22release.html | | * | | Orbix wins prestigious 'best ORB middleware' Well Connected Award from | | Network Computing Magazine | | http://techweb.cmp.com/nc/808/808wellcon22.html | +------------------------------------------------------------------------+ ---- From: Chris Steele To: 'cobol-rtf@omg.org' Cc: Mas Yokota Date: Wednesday, July 16, 1997 7:06 PM > > >Regarding the CORBA sequence IDL type in COBOL: > > >Under the current standard, the sequence accessor functions have no way >of knowing how big each element in a sequence is. Here is the current >structure of an unbounded sequence: > >01 seq1 is typedef. > 03 seq-maximum type CORBA-long. > 03 seq-length type CORBA-long. > 03 seq-buffer usage POINTER. > >where seq-maximum is the size of the allocated array (in number of >elements) that seq-buffer points to, seq-length is the current number of >items in this array, and seq-buffer points to the array itself. The >accessor functions have the following signature: > >call "CORBA-sequence-element-get" using > a-CORBA-sequence, > a-CORBA-unsigned-long, > a-element-type. > >where a-CORBA-unsigned-long refers to the index of the requested item. > >Now, CORBA-sequence-element-get (and by the same token, >CORBA-sequence-element-set) has no idea how big each item in the array >is, so it can't really index into the array and get the requested item. > >In June of 1997, Mr. Gamble and I traded ideas on the subject, and we >concluded that our favorite solution was to add another element to the >sequence type that describes the length of the sequence elements. If >anyone wishes, I could dig up the actual correspondence. Anyway, here is >the new structure: > >01 seq2 is typedef. > 03 seq-maximum type CORBA-long. > 03 seq-length type CORBA-long. > 03 seq-element-size type CORBA-long. > 03 seq-buffer usage POINTER. > >Now, seq-element-size contains the size of each element, in bytes, so >that the accessors can do their thing. This is the solution that I >implemented into the product that I am working on. If there is a better >solution, I'm certainly open to it. However, I just thought I'd put in >my two cents. > > > >Thank you, > >Chris Steele >Unitech Research, Inc. >csteele@unitech.com > From: "Roush, Elizabeth F" To: cobol-rtf@omg.org Cc: Vance Klingman Subject: Issue 626: CORBA sequence IDL type in COBOL (cobol-rtf) Date: Thu, 2 May 2002 14:57:11 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Hello, I have a question regarding this issue and the definition of a sequence in the current Cobol Mapping Specification (formal/99-07-47) vs. the definition of a sequence as defined in the COBRA/IIOP 2.1 specification (formal/97-09-01). The definition in CORBA/IIOP 2.1(formal/97-09-01) defines a sequence as the following: "... 3.10.3.1 Sequences OMG IDL defines the sequence type sequence. A sequence is a one-dimensional array with two characteristics: a maximum size (which is fixed at compile time) and a length (which is determined at run time). ..." However, the Cobol Mapping Specification (formal/99-07-47) defines a sequence as the following: "... In COBOL, bounded and unbounded sequences are represented by a COBOL group item: * The group item label is -. * It will contain one instance of the type with the label . * It will contain an opaque pointer to the sequence with the label -SEQ. ..." I found a discussion (issue 626) but the resolution does not appear to have made it to Cobol Mapping Specification (formal/99-07-47). Also, in this discussion, a Cobol sequence example is defined as: "... 01 seq1 is typedef. 03 seq-maximum type CORBA-long. 03 seq-length type CORBA-long. 03 seq-buffer usage POINTER. ..." Can you tell me what the correct Cobol mapping of a sequence is and what resolution was finally decided for determing the length of the element. Thank you, Elizabeth Roush Unisys Corporation elizabeth.roush@unisys.com