Home > Archive > Cobol > March 2008 > (Non-Standard) ODO's
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
(Non-Standard) ODO's
|
|
| William M. Klein 2008-03-12, 6:55 pm |
| 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).
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.)
P.S. I am WELL aware of the storage requirements for "Standard-conforming"
ODO's.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Robert 2008-03-12, 6:55 pm |
| On Wed, 12 Mar 2008 13:14:13 GMT, "William M. Klein" <wmklein@nospam.netcom.com> 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).
>
>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.
| |
| William M. Klein 2008-03-12, 6:55 pm |
| Robert,
I don't think you checked what the Micro Focus ODOSLIDE directive does do. I
don'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.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:bg8gt39bl3j28u6egua9aobammb6vemskq@
4ax.com...
> On Wed, 12 Mar 2008 13:14:13 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> 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.
| |
| Frank Swarbrick 2008-03-12, 6:56 pm |
| >>> On 3/12/2008 at 7:14 AM, in message
<FGQBj.34620$Gl5.10481@fe02.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> 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
| |
| William M. Klein 2008-03-12, 6:56 pm |
| 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@efirstbank.com> wrote in message
news:47D7EA43.6F0F.0085.0@efirstbank.com...
> <FGQBj.34620$Gl5.10481@fe02.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
>
>
> [deleted]
>
>
> 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
>
>
| |
| Robert 2008-03-12, 9:55 pm |
| On Wed, 12 Mar 2008 20:08:21 GMT, "William M. Klein" <wmklein@nospam.netcom.com> 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@e.mail> wrote in message
> news:bg8gt39bl3j28u6egua9aobammb6vemskq@
4ax.com...
>
| |
| Michael Mattias 2008-03-13, 6:56 pm |
| In the grand scheme of things, does it really matter if ODOs are allocated
dynamically or statically?
Seems to me as long as there are "n" occurences available where n=current
value of DEPENDING ON variable, the applications programmer doesn't care a
hoot about the allocation strategy employed by the publisher.
True, that publisher's strategy may - and perhaps should - figure into your
evaluation of "which" COBOL compiler to use, but once that decision has been
made it's immaterial.
MCM
| |
| Richard 2008-03-13, 6:56 pm |
| On Mar 14, 2:54 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> In the grand scheme of things, does it really matter if ODOs are allocated
> dynamically or statically?
If everytime the DO changed a realloc() was done, then yes, it
certainly would matter. realloc()s are notoriously, and necessarily,
slow. You would have to (re)write the program in a way that minimised
the changes to the DO.
> Seems to me as long as there are "n" occurences available where n=current
> value of DEPENDING ON variable, the applications programmer doesn't care a
> hoot about the allocation strategy employed by the publisher.
ODO originated for data records to save space on tape based systems.
There it _does_ change the actual size of the record on the tape, or
(much later) disk files. Its application to Working-Storage was
primarily to cater for READ INTO and WRITE FROM where the W-S area
_needed_ to be 'full size' so that the record could be added to.
Note that a DO embedded in a record would set the ODO _after_ an INTO
had moved the complete data record from the FD record area. Dynamic
allocation is not an option.
The fact that much later SEARCH (1974) and table SORT (2002) use ODO
is merely for convenience of not having to invent another feature to
do this.
> True, that publisher's strategy may - and perhaps should - figure into your
> evaluation of "which" COBOL compiler to use, but once that decision has been
> made it's immaterial.
| |
| Robert 2008-03-14, 3:55 am |
| On Thu, 13 Mar 2008 13:54:21 GMT, "Michael Mattias" <mmattias@talsystems.com> wrote:
>In the grand scheme of things, does it really matter if ODOs are allocated
>dynamically or statically?
Yes. There would be no problem is every program were a single monolithic blob of Cobol.
When you let one program call another, there are problems with addressability. Say A calls
B, B calls C, C changes the structure size and exits. B's parameter is no longer valid. A,
which owns the structure, no longer knows where it is either.
You could have every data reference call a memory manager to get the structure's current
address. That would kill performance. You might as well write in Java.
The practical solution would be to require every ODO to be BASED, and have every CALL pass
a pointer to the BASE pointer. That's fine for Cobol, but you couldn't pass nor receive
ODO structures to/from other languages, because they're not expecting a double pointer.
The same would go for ANY LENGTH data items declared or implicitly INDIRECT, which would
have to be implemented with hidden BASE pointers. Note that *all* ANY LENGTH data items
not at level 1 are INDIRECT.
For example, a simple ASCIIZ string:
05 s-source pic x any length delimited by low-value.
05 s-destination pic x any length delimited by low-value.
call 'strcat' using s-destination, s-source
is not going to work, because Cobol will pass the addresses of base pointers, not the
addresses of strings.
>Seems to me as long as there are "n" occurences available where n=current
>value of DEPENDING ON variable, the applications programmer doesn't care a
>hoot about the allocation strategy employed by the publisher.
Now, he can touch n+1 without getting a memory protection error. For example, he sloppily
populates n+1 BEFORE incrementing the DO. If allocation were dynamic, the program would
abort.
>True, that publisher's strategy may - and perhaps should - figure into your
>evaluation of "which" COBOL compiler to use, but once that decision has been
>made it's immaterial.
Speed is not the only issue. Dynamic allocation would cause many language standards
issues. So long as the Cobol standard avoids dealing with implementation details, dynamic
allocation is not feasible. Not without losing compatibility with other languages and the
OS API.
|
|
|
|
|