On Thu, 3 Apr 2008 18:31:09 -0600, "Frank Swarbrick"
<Frank.Swarbrick@[EMAIL PROTECTED]
>
wrote:
>I'm not talking about how the Cobol standard has them specified. Just
that,
>as a feature, I would like some better way to work with variable length
>strings.
>
>With regard to DIRECT... Without actually reading the standard, here is
>what I would intuitively *expected* with regard to a direct "any length"
>data item (fixed length font required for this to make any sense at
all!):
>
>01 AN-01-DATA-AREA.
> 05 FIXED-STR-10 PIC X(10).
> 05 VARIABLE-STR-10 PIC X ANY LENGTH LIMIT IS 10 DELIMITED BY
X'00'.
> 05 A-CHAR PIC X.
>
>
>MOVE 'XXXXXXXXXX' TO FIXED-STR-10
>MOVE 'TEST' TO VARIABLE-STR-10
>MOVE 'Z' TO A-CHAR
>MOVE 'YYYYYYYYYY' TO VARIABLE-STR-10
>
>Result in memory, before the final MOVE:
>XXXXXXXXXXTEST_ Z
>^^^^^^^^^^^^^^^^^^^^^^
>After the final MOVE:
>XXXXXXXXXXYYYYYYYYYY_Z
>^^^^^^^^^^^^^^^^^^^^^^
>The underscore represents the delimiter 'null' character.
>
>What you say says to me that before the final move we would instead see
>XXXXXXXXXXTEST_Z
That's what you'd get if you moved the group to a flat string. The
standard doesn't say
what memory would look like. It does say the address of a-char will not
change if the
any-length string is indirect (is represented by an inline pointer). I
take that to mean
the address of a-char MIGHT change if the any-length string is direct. The
compiler author
gets to decide whether to ****ft a-char when its neighbor changes length.
>I would agree that this is rather crazy.
>
>I think how I am looking at it, which is apparently not how you would
>sup****t it, is that if DIRECT is specified *along with a limit*, then the
>maximum storage required would be used. This is just like how in C you
can
>have, for instance:
>
>struct my_struct {
> char[21] field1;
> char[21] field2;
> char x;
>};
>
>void cfunc(struct my_struct *s) {
> strcpy(s->field1, "This is a test");
> strcpy(s->field2, "Another test");
> s->x = 'X';
>}
>
>Result in memory:
>This is a test_ Another test_ X
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>If I wanted to call cfunc from Cobol I could do this:
>
>01 MY-STRUCT.
> 05 field-1 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'.
> 05 field-2 PIC X ANY LENGTH LIMIT IS 20 DELIMITED BY X'00'.
> 05 X PIC X.
>
>
>CALL 'cfunc' USING MY-STRUCT
>DISPLAY field-1 '/' field-2 '/' x
>
>Result:
>This is a test/Another test/X
Compatibility with C is a non-issue because .. get this .. you are NOT
ALLOWED to pass a
variable length structure as a CALL parameter.
I seriously doubt any compiler author would enforce that restriction.
Then, to be
compatible with C, he would NOT ****ft X around.
>Now as for a DIRECT any-length data item without a limit specified, I
don't
>think that makes sense. Is it even allowed? My brain doesn't want to
try
>to interpret the standard right now.
DIRECT items must have a LIMIT except at the 01 level. If you leave it
off, they default
to INDIRECT.
>n 4/1/2008 at 8:54 PM, in message
><vzCIj.8760$fY6.7941@[EMAIL PROTECTED]
>, William M.
>Klein<wmklein@[EMAIL PROTECTED]
> wrote:
>> Frank,
>> As currently included in WD 1.10, I am very much opposed to it. The
>> problem
>> is that the current definition allows the data to be stored within the
>> structure
>> ("DIRECT") and to have such items within ODO's and with data after
this.
>> What
>> this means is that the "data" after the variable length field MUST be
>> "moved" in
>> storage each time the variable data size changes.
>>
>> If the proposed definition
>> - only allowed for "direct" variable length fields at the 01-level,
>> - allowed for "indirect" variable length items within structures
>> - figured out how to handle such fields within FILES (or disallowed it
>> there),
>> - didn't allow the same variable length field to be BOTH prefixed and
>> suffixed
>>
>> then I would be for it.
|
