Thanks, The
GROUP1 BLW=0000+008 0CL11
having "0CL11" certainly seems conclusive. I can think of some other
tests
(like going over a 4096 boundary - or using EXTERNAL) but it seems that
this
does allocate the full storage - even if it isn't used.
--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@[EMAIL PROTECTED]
> wrote in message
news:47D7EA43.6F0F.0085.0@[EMAIL PROTECTED]
>>>> On 3/12/2008 at 7:14 AM, in message
> <FGQBj.34620$Gl5.10481@[EMAIL PROTECTED]
>, 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
>
>>
>> documented extensions by these - and possibly other - compilers).
>
> [deleted]
>
>> 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.)
>>
>> P.S. I am WELL aware of the storage requirements for
>> "Standard-conforming"
>> ODO's.
>
> With IBM COBOL for VSE there doesn't appear to be any sort of dynamic
> allocation going on. I first added two additional data items:
> Before Group1:
> 77 ABEND PIC S9(3) PACKED-DECIMAL.
> After Non-standard-after-odo:
> 77 FILLER PIC X(16) VALUE '**WS ENDS HERE**'.
>
> The output listing shows the following (essentially):
>
> ABEND BLW=0000+000 2P
> GROUP1 BLW=0000+008 0CL11
> NUM BLW=0000+008,0000000 1C
> TABL1 BLW=0000+009,0000001 0CL9
> TABL-ITEM BLW=0000+009,0000001 1C
> 7
> NON-STANDARD-AFTER-ODO BLV=0000+000 1C
> FILLER BLW=0000+018 16C
>
> The trailing filler starts at an offset where there's enough room for
> NON-STANDARD-AFTER-ODO to be positioned with NUM being 9; plus it's
probably
> aligned on the next fullword boundary, which would account for the extra
> non-specified filler space.
>
> Anyway, the only thing that's really 'dynamic' is the value of the BLV
> itself. Doing some dumps shows that when NUM is 1, BLV=0 starts 10
bytes
> after BLW=0. When NUM is 9, BLV=0 starts 18 bytes after BLW=0. This
all
> appears to me to be quite reasonable.
>
> Frank
>
>
|
