On Wed, 12 Mar 2008 20:08:21 GMT, "William M. Klein"
<wmklein@[EMAIL PROTECTED]
> wrote:
>Robert,
> I don't think you checked what the Micro Focus ODOSLIDE directive does
do.
When Num = 1, it slides Non-Standard-After-ODO to occupy the place of
Tabl-Item (2), the
length of Group1 is 3.
>Idon't think there is any question about the "address of" in your reply
giving
>different answers. However, that still doesn't say that the storage
itself is
>"dynamically" changed - only where the compiler "looks" for data
following an
>ODO.
If the difference is 8, the structure is statically allocated. If the
difference is more
than 8, probably thousands, the structure was dynamically reallocated when
its length
changed.
If the compiler were dynamically reallocating Group1, a CALL USING Group1
would have to
pass a pointer to a pointer, the base address of Group1. Otherwise, the
calling program
would have no way of knowing its new address after the called program
changed its length
and reallocated it. Doing so is easy and common in C by saying &&Group1,
but Cobol has no
convenient syntax for that. All it has is Group1 BASED Foo and CALL USING
Foo. The
standard does not require that syntax for CALL USING ODO structure,
therefore the standard
implicitly requres Group1 be allocated statically.
Unrelated to the standard, Micro Focus would have to change its bounds
checking if
allocation were dynamic. Presently, it checks a subscript against the
maximum (and
minimum if greater than 1), NOT against the ODO limit. For example, this
would not cause
an error:
move 1 to Num
move 'x' to Tabl-Item (9)
If Group1 were allocated dynamically, that would cause an undetected
memory access error.
Users would justifiably complain that bounds checking was broken.
>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>news:bg8gt39bl3j28u6egua9aobammb6vemskq@[EMAIL PROTECTED]
>> On Wed, 12 Mar 2008 13:14:13 GMT, "William M. Klein"
>> <wmklein@[EMAIL PROTECTED]
> wrote:
>>
>>>As a follow-up to another thread, I am actually curious (and don't
know the
>>>answer - but have a guess) what IBM does with "BLV" (base locators for
>>>variably
>>>located data) and what Micro Focus does when ODOSLIDE is turned on.
>>>Specifically whether either or both actually DO do "dynamic allocation"
for
>>>NON-Standard ODO's (i.e. those prohibited by the Standard - but allowed
as
>>>do***ented extensions by these - and possibly other - compilers).
>>>
>>>Consider:
>>>
>>>01 Group1.
>>> 05 Num Pic 9.
>>> 05 Tabl1.
>>> 10 Tabl-Item occurs 1 to 9 times depending on Num Pic X.
>>> 05 Non-Standard-After-ODO Pic X.
>>>
>>>Move 1 to Num
>>>Move "X" to Non-Standard-After-ODO
>>> *> "X" is placed into the 3rd byte of Group1
>>>Move 9 to Num
>>> *> "X" is now in Tabl-Item (2)
>>>Move "X" to Non-Standard-After-ODO
>>> *> "X" is placed in 11th byte of Group1
>>>
>>>So my question is whether the "change in size" of Group1 actually
involves
>>>dynamic change in storage allocated - or just SEEMS to. I am not even
certain
>>>how one could find this out. (I don't know, but I don't think the
generated
>>>Assembler would tell - but it might.)
>>
>> It would be easy to tell:
>>
>> move 1 to Num
>> display address of Non-Standard-After-ODO
>> move 9 to Num
>> display address of Non-Standard-After-ODO
>>
>> Without checking, I'd wager the addresses differ by 8, the compiler is
>> statically
>> allocating the maximum size (assuming the structure is in
working-storage or
>> file
>> section). We know it does that when ODO is at the end of the structure,
in
>> conformance
>> with the standard. There is no reason to think the compiler would act
>> differently in this
>> case, especially when we know it (Micro Focus) does not have a garbage
>> collector.
>
|
