Cobol - Did I write a good (efficient) program?

Author

Did I write a good (efficient) program?

MikeB

2008-03-30, 6:56 pm

I haven't written COBOL in a number of years and am quite rusty.
Recently someone asked my help to write some code to display an IP V6
address in human-readable code. I wrote something, but am not sure if
I used the best available techniques. Please have a look at what I
wrote and feel free to comment.

Background. An IP V6 address is 4 words (128-bit) long. It is in
binary format. For human-readable purposes it is converted into 8
"octets" separated by colons. leading zeroes in each field are
suppressed. To compact the address, one or more adjacent octets
containing all zeroes can be compressed *once* per IP address by
simply producing a pair of colons.

thus: 76DF:54AE:A30:1:1:4321:EAD5:AA43
or FD05::1:0:5 (in this instance 4 octets have been suppressed)
or even: ::1 (loopback address)

I was under a little time pressure (only had yesterday morning), so I
haven't figured out the compression part yet. However, that is
optional, so I'll do it when I have some spare time. In the meantime,
I'd like to hear from members of this group if I could have written
cleaner, leaner and more efficient COBOL.

Thanks.

-----------------------------------------------------------------------------------------------------------
000300 IDENTIFICATION
DIVISION.
000400 PROGRAM-ID.
IPDISP.
003200 ENVIRONMENT
DIVISION.
003300 DATA
DIVISION.
003400 WORKING-STORAGE
SECTION.
007212*
IPV6
007213 01 HEX-
VALUES.
007214 05 FILLER PIC X(32) VALUE
"000102030405060708090A0B0C0D0E0F".
007215 05 FILLER PIC X(32) VALUE
"101112131415161718191A1B1C1D1E1F".
007216 05 FILLER PIC X(32) VALUE
"202122232425262728292A2B2C2D2E2F".
007217 05 FILLER PIC X(32) VALUE
"303132333435363738393A3B3C3D3E3F".
007218 05 FILLER PIC X(32) VALUE
"404142434445464748494A4B4C4D4E4F".
007219 05 FILLER PIC X(32) VALUE
"505152535455565758595A5B5C5D5E5F".
007220 05 FILLER PIC X(32) VALUE
"606162636465666768696A6B6C6D6E6F".
007221 05 FILLER PIC X(32) VALUE
"707172737475767778797A7B7C7D7E7F".
007222 05 FILLER PIC X(32) VALUE
"808182838485868788898A8B8C8D8E8F".
007223 05 FILLER PIC X(32) VALUE
"909192939495969798999A9B9C9D9E9F".
007224 05 FILLER PIC X(32) VALUE
"A0A1A2A3A4A5A6A7A8A9AAABACADAEAF".
007225 05 FILLER PIC X(32) VALUE
"B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF".
007226 05 FILLER PIC X(32) VALUE
"C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF".
007227 05 FILLER PIC X(32) VALUE
"D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF".
007228 05 FILLER PIC X(32) VALUE
"E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF".
007229 05 FILLER PIC X(32) VALUE
"F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF".
007230 01 HEX-TABLE REDEFINES HEX-
VALUES.
007231 05 HEX-BYTE PIC XX OCCURS 256
TIMES.
007232
007235 01 IP-
ADDRESS.
007236 05 IP-ONE PIC
X(8).
007237 05 IP-TWO PIC
X(8).
007238 01 IP-BYTES REDEFINES IP-
ADDRESS.
007239 05 IP-BYTE6 PIC X OCCURS 16
TIMES.
007240
007241 01 IP-
BINARY.
007242 05 IP-HEX OCCURS 16
TIMES.
007243 10 FILLER PIC X VALUE LOW-
VALUES.
007244 10 IP-NUMBER-BINARY PIC
X.
007245 01 IP-INDEX REDEFINES IP-
BINARY.
007246 05 IP-NUMBER-INDEX PIC 99 USAGE COMP-5 OCCURS 16
TIMES.
007247
007248 01 IP-
DISPLAY.
007249 05 IP-DISPLAY-BYTE PIC XX OCCURS 16
TIMES.
007250 01 IP-OCTETS REDEFINES IP-
DISPLAY.
007251 05 IP-OCTET PIC X(4) OCCURS 8
TIMES.
007252
007253 01 IP-PRINT-FIELD PIC X(40) VALUE
SPACE.
007256
007257 01 IP-INDEX1 PIC S9(4) COMP VALUE
ZERO.
007258 01 HEX-INDEX1 PIC S9(4) COMP VALUE
ZERO.
007259 01 IP-PRINT-POSITION PIC S9(4) COMP VALUE
ZERO.
007260 01 FLD-START PIC S9(4) COMP VALUE
ZERO.
007261 01 FLD-LENGTH PIC S9(4) COMP VALUE
ZERO.
030600
030700 PROCEDURE DIVISION.
* for each of the 16 bytes in the IPV6
address:
046522 PERFORM VARYING IP-INDEX1 FROM 1 BY
1
046523 UNTIL IP-INDEX1 > 16
* move a byte into a two-byte field that can be used as a number
046524 MOVE IP-BYTE6(IP-
INDEX1)
046525 TO IP-NUMBER-BINARY(IP-INDEX1)
* bump the number up to be used as an index into the array
046532 ADD 1 TO IP-NUMBER-INDEX(IP-
INDEX1)
046533 GIVING HEX-INDEX1
* move the indicated bytes in the array (translation table) to
the
* display field
046540 MOVE HEX-BYTE(HEX-
INDEX1)
046541 TO IP-DISPLAY-BYTE(IP-
INDEX1)
046554 END-
PERFORM
046555
046556 MOVE 1 TO IP-PRINT-
POSITION
046557 MOVE SPACES TO IP-PRINT-
FIELD
046558
* IP V6 addresses are formatted as half-word "octets" dearated
by
* colons (":") and with leading zeroes suppressed.
*
* for each of the 8 octets:
046560 PERFORM VARYING IP-INDEX1 FROM 1 BY
1
046561 UNTIL IP-INDEX1 > 8
* set tally field to zero
046562 MOVE ZEROES TO FLD-START
* count leading zeroes
046563 INSPECT IP-OCTET(IP-INDEX1) TALLYING FLD-
START
046564 FOR LEADING "0"
046576 IF FLD-START =
4
046577 THEN
* if the entire field are zeroes, then simply display "0:"
*at a later stage figure out the IP compaction convention
* of allowing one or more zero address fields to be compacted
*once* per
* address into a sequence of
"::"
046578 MOVE "0:" TO IP-PRINT-FIELD(IP-PRINT-POSITION:
2)
046579 ADD 2 TO IP-PRINT-
POSITION
046586 ELSE
* only suppress leading zeroes
* how many bytes to move?
046587 COMPUTE FLD-LENGTH = (4 - FLD-START)
* move them into the display field
046598 MOVE IP-OCTET(IP-INDEX1)(FLD-START + 1:FLD-
LENGTH)
046599 TO IP-PRINT-FIELD(IP-PRINT-POSITION:fld-
length)
* calculate next position in display field
046600 COMPUTE IP-PRINT-POSITION = (IP-PRINT-
POSITION + fld-length)
* add a colon (":")
046601 MOVE ":" TO IP-PRINT-FieLD(IP-PRINT-POSITION:
1)
* bump position in display field
046602 ADD 1 TO IP-PRINT-
POSITION
046613 END-
IF
046614 END-PERFORM

Doug Miller

2008-03-30, 6:56 pm

In article <408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com>, MikeB <MPBrede@gmail.com> wrote:

Please repost in a more easily readable form.

>000300 IDENTIFICATION
>DIVISION.
>000400 PROGRAM-ID.
>IPDISP.
>003200 ENVIRONMENT
>DIVISION.
>003300 DATA
>DIVISION.
>003400 WORKING-STORAGE
>SECTION.

--
Regards,
Doug Miller (alphag

at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Rick Smith

2008-03-30, 6:57 pm

"MikeB" <MPBrede@gmail.com> wrote in message
news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
[snip]
> In the meantime,
> I'd like to hear from members of this group if I could have written
> cleaner, leaner and more efficient COBOL.

I can not say that it meets all the criteria but here is another
way to have done it. It uses intrinsic functions and STRING
to do ... uh ... character and string manipulation.

Showing the PROCEDURE DIVISION only.
-----
PROCEDURE DIVISION.
* Expand 16 byte IP-ADDRESS to
* 32 character hex display in IP-OCTETS
move 1 to ip-octets-ptr
perform
varying ip-index1 from 1 by 1
until ip-index1 > 16
compute hex-index1 =
function ord (ip-address(ip-index1:1))
string
hex-byte (hex-index1) delimited by size
into ip-octets
with pointer ip-octets-ptr
end-perform

* IP V6 addresses are formatted as 16-bit "octets" delimited by
* colons (":") and with leading zeroes suppressed.
*
* Leading zeros are replaced by spaces then
* formatting is done in reverse to suppress these spaces

MOVE 1 TO IP-PRINT-POSITION
MOVE SPACES TO IP-PRINT-FIELD

PERFORM VARYING IP-INDEX1 FROM 8 BY -1
UNTIL IP-INDEX1 < 1
inspect ip-octet(ip-index1)(1:3)
replacing leading zeros by spaces
string
function reverse (ip-octet(ip-index1))
delimited by spaces
":" delimited by size
into ip-print-field
with pointer ip-print-position
END-PERFORM

* Reverse the string
subtract 2 from ip-print-position
move function reverse (ip-print-field(1:ip-print-position))
to ip-print-field
stop run

HeyBub

2008-03-31, 3:57 am

MikeB wrote:
> On Mar 30, 10:09 am, spamb...@milmac.com (Doug Miller) wrote:
>
> Yikes, what's up with that? Sorry. I'll try again, but I'm posting
> from Google Groups and I fear I'm not in control of linebreaks and
> other stuff.
>
> So I put it on http://mpbrede.googlepages.com/coboltext in text format
> and downloadable. Sorry for the inconvenience.

So don't use a web-based newsgroup access method.

Google Groups is the AOL of the 21st Century.

Robert

2008-03-31, 3:58 am

On Sun, 30 Mar 2008 11:47:14 -0500, "Rick Smith" <ricksmith@mfi.net> wrote:

>
>"MikeB" <MPBrede@gmail.com> wrote in message
>news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
>[snip]
>
>I can not say that it meets all the criteria but here is another
>way to have done it. It uses intrinsic functions and STRING
>to do ... uh ... character and string manipulation.
>
>Showing the PROCEDURE DIVISION only.
>-----
> PROCEDURE DIVISION.
> * Expand 16 byte IP-ADDRESS to
> * 32 character hex display in IP-OCTETS
> move 1 to ip-octets-ptr
> perform
> varying ip-index1 from 1 by 1
> until ip-index1 > 16
> compute hex-index1 =
> function ord (ip-address(ip-index1:1))
> string
> hex-byte (hex-index1) delimited by size
> into ip-octets
> with pointer ip-octets-ptr
> end-perform
>
> * IP V6 addresses are formatted as 16-bit "octets" delimited by
> * colons (":") and with leading zeroes suppressed.
> *
> * Leading zeros are replaced by spaces then
> * formatting is done in reverse to suppress these spaces
>
> MOVE 1 TO IP-PRINT-POSITION
> MOVE SPACES TO IP-PRINT-FIELD
>
> PERFORM VARYING IP-INDEX1 FROM 8 BY -1
> UNTIL IP-INDEX1 < 1
> inspect ip-octet(ip-index1)(1:3)
> replacing leading zeros by spaces
> string
> function reverse (ip-octet(ip-index1))
> delimited by spaces
> ":" delimited by size
> into ip-print-field
> with pointer ip-print-position
> END-PERFORM
>
> * Reverse the string
> subtract 2 from ip-print-position
> move function reverse (ip-print-field(1:ip-print-position))
> to ip-print-field
> stop run

A better way to remove leading spaces is:

unstring ip-octet(ip-index1) delimited by all space
into temp-string, temp-string
string temp-string ':' delimited by space
into ip-print-fielld with pointer ip-print-position

If ip-octet had no spaces, it will go to the first temp-string and the second will be
unchanged. If it did have leading spaces, the first temp-string will be cleared to spaces,
the word will go into the second mention of temp-string.

Richard

2008-03-31, 7:00 pm

On Mar 31, 1:44=A0pm, Robert <n...@e.mail> wrote:
>
> Efficient is Cobolese for fast. In the Good Old Days we had to hold the ma=
chine's hand,
> showing it how to go fast. Concern for speed became THE criteria driving d=
esign.

No. Often saving space was just as big a concern. Fitting the client's
product and customer files onto one 4 MegaByte disk drive was as
important as having the daily invoice run take less than 24 hours.

> As
> machines got faster, we kept doing it out of habit and because no one told=
us to stop. We
> now program as though the year is still 1973,

Who are the 'we' that you speak of ? Are you making another of your
infamous 'universal truths' about 'all Cobol programmers', or is it
just yourself that is a 'royal wee'.

> ignoring the fact that the Pentium 4 on our
> desktop is 2,000 times the speed of a 370/158.

Well, it does seem that you were alone in wanting to save a few
nanoseconds on SEARCH ALL. You previously wanted to convince others to
use pointer based lists because you claimed they were faster than
tables (when my testing showed them not to be).

It may well be that you program "as though the year is still 1973",
but others may not be doing so.

Rick Smith

2008-03-31, 7:00 pm

"MikeB" <MPBrede@gmail.com> wrote in message
news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
[snip]
> Please have a look at what I
> wrote and feel free to comment.
[snip]
> thus: 76DF:54AE:A30:1:1:4321:EAD5:AA43
> or FD05::1:0:5 (in this instance 4 octets have been suppressed)
> or even: ::1 (loopback address)
>
> I was under a little time pressure (only had yesterday morning), so I
> haven't figured out the compression part yet.

I am not feeling pressured and have a lot of time, so ...
I rewrote your program adding the compression part
and wrote a test program to call it. The results are as
expected.

----- Results
76DF:54AE:A30:1:1:4321:EAD5:AA43
FD05::1:0:5
::1
----- Test program
program-id. iptest.
data division.
working-storage section.
01 ip-address pic x(16) value space.
01 ip-print-field pic x(40) value spaces.
procedure division.
string x"76DF54AE0A30000100014321EAD5AA43"
delimited by size
into ip-address
call "ipdisp" using ip-address ip-print-field
display ip-print-field
string x"FD050000000000000000000100000005"
delimited by size
into ip-address
call "ipdisp" using ip-address ip-print-field
display ip-print-field
string x"00000000000000000000000000000001"
delimited by size
into ip-address
call "ipdisp" using ip-address ip-print-field
display ip-print-field
stop run

Robert

2008-04-01, 3:55 am

On Mon, 31 Mar 2008 12:10:23 -0700 (PDT), Richard <riplin@azonic.co.nz> wrote:

>On Mar 31, 1:44_pm, Robert <n...@e.mail> wrote:
>
>No. Often saving space was just as big a concern. Fitting the client's
>product and customer files onto one 4 MegaByte disk drive was as
>important as having the daily invoice run take less than 24 hours.

I would think you'd oppose arbitrary size limits such as fixed length arrays.

>
>Who are the 'we' that you speak of ? Are you making another of your
>infamous 'universal truths' about 'all Cobol programmers', or is it
>just yourself that is a 'royal wee'.

'We' refers to those who pre-optimize code before there is evidence it needs to be
optimized. For instance, defining fixed length strings and arrays because they believe
variable length is too slow. That came out during a recent discussion about ODO.

>
>Well, it does seem that you were alone in wanting to save a few
>nanoseconds on SEARCH ALL. You previously wanted to convince others to
>use pointer based lists because you claimed they were faster than
>tables (when my testing showed them not to be).

The principal advantage of lists over arrays is no practical limit on size. They can grow
to millions of entries. Other advantages are variable length entries (e.g. words) and the
ability to splice a new entry into the middle.

>It may well be that you program "as though the year is still 1973",
>but others may not be doing so.

In 1973 everything (except files) was fixed length. We used fixed length strings, numbers,
arrays, records and blocks in files. Now, outside Cobol, most things are variable length.
The next Cobol standard proposes adding 'any length' data items and arrays. The Old Guard
are opposed.

Richard

2008-04-01, 3:55 am

On Apr 1, 3:40=A0pm, Robert <n...@e.mail> wrote:
> On Mon, 31 Mar 2008 12:10:23 -0700 (PDT), Richard <rip...@azonic.co.nz> wr=
ote:
>
machine's hand,[color=darkred]
g design.[color=darkred]
>
>
> I would think you'd oppose arbitrary size limits such as fixed length arra=
ys.

Why do you think that I would 'oppose' anything, let alone do so in
the absense of any context ?

Fixed length arrays are useful, variable, or unrestrained, structures
are useful, but not necessarily for the same problem. Some problems
have actual limits, some have arbitrary constraints.

old us to stop. We[color=darkred]
>
>
> 'We' refers to those who pre-optimize code before there is evidence it nee=
ds to be
> optimized.

Just you then is it ?

> For instance, defining fixed length strings and arrays because they believ=
e
> variable length is too slow. That came out during a recent discussion abou=
t ODO.
>

I can't recall _anyone_ claiming that ODO is 'too slow'. In most cases
they were completely indifferent to whether it was faster or slower.
They just made stuff work and left it to the CPU to get it done.

You seem to have this idea that every argument is either black or
white. If they don't flock to follow what you do then they must be
doing the extreme opposite.

>
>
> The principal advantage of lists over arrays is no practical limit on size=
.. They can grow
> to millions of entries. Other advantages are variable length entries (e.g.=
words) and the
> ability to splice a new entry into the middle.

That may be so, but it is often unrequired.

In any case lists made with pointers are so 80s. Modern stuff is done
with lists (with the list mechanism dealing with the grubby details),
tuples and dictionaries.

>
> In 1973 everything (except files) was fixed length. We used fixed length s=
trings, numbers,
> arrays, records and blocks in files. Now, outside Cobol, most things are v=
ariable length.

You just make up nonsense out of vauge generalizations and
pontifications. In the early 70s, when tapes were master files it was
quite common to use variable length records, either with repeating
groups or multiple record types. The 'modern' way is with normalised
data, removing the variability.

In fact 'outside Cobol' much has _always_ been 'variable length' and
much has been 'fixed length'. For example in C strings have a
terminator and are 'variable length' but only within a fixed length
declaration or allocation.

> The next Cobol standard proposes adding 'any length' data items and arrays=
.. The Old Guard
> are opposed.

In what way are the 'old guard' opposed ? They are most likely
completely indifferent, but that doesn't seem to be on your binary
scale of things where it must be 'rabid support' or 'opposed'.

In fact I have used 'any length' and found it useful.

Michael Mattias

2008-04-01, 7:55 am

You know, I've always used three tests to decide if code is well-written:

1. Does it work?
2. Is it *relatively* efficient?
3. Is it maintainable?

You need a "yes" answer to all three questions to have well-written code.

While 'works' is non-negotiable, I'll often often trade 'ultimate
efficiency' for maintainability; e.g., "ultimate" efficiency can often be
best achieved by using lots of GO TOs; but this comes at a maintainability
cost I am generally not willing to pay.

All done, but need more efficiency? My rule for optimizing may help: First
you make it work; only then can you make it work better.

YMMV.

--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com

2008-04-01, 6:56 pm

In article <57qIj.23163$0o7.2366@newssvr13.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
>You know, I've always used three tests to decide if code is well-written:
>
>1. Does it work?
>2. Is it *relatively* efficient?
>3. Is it maintainable?
>
>You need a "yes" answer to all three questions to have well-written code.
>
>While 'works' is non-negotiable, I'll often often trade 'ultimate
>efficiency' for maintainability; e.g., "ultimate" efficiency can often be
>best achieved by using lots of GO TOs; but this comes at a maintainability
>cost I am generally not willing to pay.

Where has this been talked about before... ahhhh... from
<http://groups.google.com/group/comp...61?dmode=source>

--begin quoted text:

(T)hat is a Major Source of Debate, I believe... the more that code caters
to hardware functions the more efficient it is... and the less
structured/maintainable/portable it is. You makes your choices, you takes
the results.

[snip]

All that aside I rarely concern myself with what others think... no matter
what one does there are those who will say that one is a hidebound
dinosaur and others who will say that one is a slave the the
flavor-of-the-month. If program-runs perform next-assignment else perform
code-like-hell until damned-thing-works... don't get much plainer than
that.

--end quoted text

DD

Howard Brazee

2008-04-01, 6:56 pm

On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>1. Does it work?
>2. Is it *relatively* efficient?
>3. Is it maintainable?
>
>You need a "yes" answer to all three questions to have well-written code.

Of course, the industry has changed considerably - which has changed
how we grade these.

Michael Mattias

2008-04-01, 6:56 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8@
4ax.com...
> On Tue, 01 Apr 2008 12:44:49 GMT, "Michael Mattias"
> <mmattias@talsystems.com> wrote:
>
>
> Of course, the industry has changed considerably - which has changed
> how we grade these.

I don't about "industry" but I have always weighed 'maintainability' very,
very heavily: When was the last time you saw a program which NEVER was
upgraded/enhanced/changed?

MCM

Howard Brazee

2008-04-01, 6:56 pm

On Tue, 01 Apr 2008 16:04:49 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>
>I don't about "industry" but I have always weighed 'maintainability' very,
>very heavily: When was the last time you saw a program which NEVER was
>upgraded/enhanced/changed?

I weigh it heavily as well - the atomic size of our components
changes. When maintenance can be done by pulling out one module and
plugging in another, we get an "A" by making that module easy to
access and replace. Actually fixing that part isn't as important
as it once was.

This process of change is at least as old as interchangeable parts in
the industrial revolution.

tlmfru

2008-04-01, 6:56 pm

Richard <riplin@azonic.co.nz> wrote in message
news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
On Apr 1, 3:40 pm, Robert <n...@e.mail> wrote:
told us to stop. We[color=darkred]
>
>
needs to be[color=darkred]
[color=darkred]
>Just you then is it ?

That's uncalled-for. Any programmer worth his thinking cap does this sort
of thing automatically - for instance, making sure that calculations that
don't beed to be inside a loop are moved outside it; or using a single
variable to hold the results of a complex calculation rather than
reiterating the calculation itself ... and so forth.

PL

Rick Smith

2008-04-01, 6:56 pm

"MikeB" <MPBrede@gmail.com> wrote in message
news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
> I haven't written COBOL in a number of years and am quite rusty.
> Recently someone asked my help to write some code to display an IP V6
> address in human-readable code. I wrote something, but am not sure if
> I used the best available techniques. Please have a look at what I
> wrote and feel free to comment.

Having taken the time and made the effort to truly
understand the problem and how it may be solved,
I find that the "best available technique" for obtaining
the numeric value of a character is the use of the
intrinsic function, ORD.

As for the balance of your program, I found no
technique that is necessarily better than what you have
done.

> Thanks.

You are welcome.

Frank Swarbrick

2008-04-01, 6:56 pm

>>> On 3/31/2008 at 8:40 PM, in message
<c463v3p7pdl8dc6dl5seo7j6u0mfrev3qr@4ax.com>, Robert<no@e.mail> wrote:
> In 1973 everything (except files) was fixed length. We used fixed length
> strings, numbers,
> arrays, records and blocks in files. Now, outside Cobol, most things are
> variable length.
> The next Cobol standard proposes adding 'any length' data items and
> arrays. The Old Guard
> are opposed.

Is anyone here a member of this Old Guard that is opposed to variable length
strings? I certainly am not. I would love them.

Frank

Pete Dashwood

2008-04-01, 6:56 pm

"Richard" <riplin@azonic.co.nz> wrote in message
news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
<snip>

I can't recall _anyone_ claiming that ODO is 'too slow'. In most cases
they were completely indifferent to whether it was faster or slower.
They just made stuff work and left it to the CPU to get it done.

You seem to have this idea that every argument is either black or
white. If they don't flock to follow what you do then they must be
doing the extreme opposite.

<snip>

[Pete]

Robert, I think this is very fair and, for me, goes straight to the nub of
the problem that some people here have with your posts.

I'm not getting involved in your specific argument here, but I definitely
think you could benefit by thinking about this.

I find your posts and ideas very valuable, and sometimes what you post is a
different insight into something often taken for granted. I like the way
that you challenge old ideas and we need that. However, Richard is right on
the button with this observation; inasmuch as you DO seem to see black and
white only, when most of us accept shades of grey.

Certainly, a forthright position has more impact and is often easier to
maintain, but if it makes you overlook the actual responses you elicit, then
it is counter productive.

Think on it :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-04-01, 6:56 pm

"tlmfru" <lacey@mts.net> wrote in message
news:96uIj.44130$QC.26319@newsfe20.lga...
>
> Richard <riplin@azonic.co.nz> wrote in message
> news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
> On Apr 1, 3:40 pm, Robert <n...@e.mail> wrote:
> told us to stop. We
> needs to be
>
>
> That's uncalled-for. Any programmer worth his thinking cap does this sort
> of thing automatically - for instance, making sure that calculations that
> don't beed to be inside a loop are moved outside it; or using a single
> variable to hold the results of a complex calculation rather than
> reiterating the calculation itself ... and so forth.
>

I agree that most of us who have any experience of programming do try and
make things more efficient as we write, often in the ways you note above,
and it is irrespective of whatever language we are using.

But we also need to recognise that modern optimisers can do this job for us
and often do it better than we can.

Today, this isn't as important as it once was.

It is also likely that in any exchange between Robert and Richard there are
going to be statements on both sides that are "uncalled for"... :-)

As long as it isn't mean or vicious, and nobody is blinded to the actual
value of their posts, I see no harm in it...:-)

Part of the normal rough and tumble on Usenet...

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-04-01, 6:56 pm

--
"I used to write COBOL...now I can do anything."
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:57qIj.23163$0o7.2366@newssvr13.news.prodigy.net...
> You know, I've always used three tests to decide if code is well-written:
>
> 1. Does it work?
> 2. Is it *relatively* efficient?
> 3. Is it maintainable?
>

Yep, same priorities I have always observed also...

However, in the light of my experience over the last decade or so, I would
qualify these criteria with: "applies only to Procedural Code."

OO Code has a different set...

1. Does it work?
2. Is it small and complete (encapsulated)?
3. Can I reuse and extend it easily?

Efficiency is taken care of by keeping components small, and using
optimizing compilers.

Maintainability is not a consideration as long as the interface is simple or
non existent. I like to use internal properties (via GETTERs and SETTERs) to
modify behaviour of components, as this avoids needing parameter interfaces,
but it isn't a hard and fast or black and white rule, and it is certainly
arguable... I have found it works and can completely eliminate maintenance.
These days I write stuff, thoroughly debug it, then forget about it. I don't
plan to "maintain" encapsulated functionality, and, so far, I have never had
to. I also don't need to regression test new functionality because it cannot
affect existing functionality, which continues to function as it always has.
OO encapsulation is a form of "ringfencing" for systems.

To modify existing functionality does NOT mean modifying a base class. It
means extending (through inheritance) or over-riding existing behaviours.
Again, only the parts of the system that invoke the modified functionality
need to be tested as the rest of the system is isolated from the changes.

This is, obviously, a different world from COBOL, which was conceived as
being "easily maintainable" in the days when that was important.

> You need a "yes" answer to all three questions to have well-written code.

Yes, but the question set is different between Procedural and Object
Oriented code.
>
> While 'works' is non-negotiable, I'll often often trade 'ultimate
> efficiency' for maintainability; e.g., "ultimate" efficiency can often be
> best achieved by using lots of GO TOs; but this comes at a maintainability
> cost I am generally not willing to pay.
>
> All done, but need more efficiency? My rule for optimizing may help:
> First you make it work; only then can you make it work better.

Emphaticaly agreed :-) For both Procedural and OO...

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-04-01, 6:56 pm

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:B2tIj.20982$xq2.2197@newssvr21.news.prodigy.net...
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:qbi4v3lh2qh46k37lsl1v3pg0f4jppaod8@
4ax.com...
>
> I don't about "industry" but I have always weighed 'maintainability' very,
> very heavily: When was the last time you saw a program which NEVER was
> upgraded/enhanced/changed?
>
I have dozens of them :-)

They're called "components"...

Each of them represents encapsulated basic functionality that simply doesn't
change. They are building blocks, just like atoms or bricks; you don't
modify the structure of the atoms to make a different molecule; you just
combine different atoms differently (or add some new ones).

Components that access or maintain data are most likely to be "volatile".
That's why I use an n-tier approach to system architecture. Components in
the DB access layer are virtually "cannon fodder" and can be replaced or
extended very quickly. (In fact, I am currently evaluating tools that will
automatically generate these components whenever I change the DB
design...There are some staggering tools available...)

It was this that led me to consider interfaces very carefully. Most of the
time, if you change an interface (maybe add another parameter or parameter
value) it has a serious effect and requires regression testing. If you can
avoid changing the interface you can avoid much of this grief. As Object
Classes can be forced to generate automatic methods for accessing and
setting their internal properties, this means I can change parameters
without changing interfaces. This allows me the option to "activate"
existing functionality that was built in by "up front" design (part of a
GENERAL rather than SPECIFIC solution, or to add new behaviours by
overiding or extending existing methods in a new subclass. (This allows
"evolutionary" design rather than "up front" design.) I can use either or
both design approaches, and I never need regression testing.

(It would be VERY difficult to implement such an approach, WITHOUT using
Object technology...)

Only the control elements that invoke the new or modified functionality need
to be tested.

Pete.
--
"I used to write COBOL...now I can do anything."

Michael Mattias

2008-04-01, 6:56 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65folmF1f605pU1@mid.individual.net...
> I have dozens of them :-)
>
> They're called "components"...

Applications programmers (eg, moi) don't think in terms of "components";
strangely enough, we think in terms of "applications."

I guess that explains as well as anything why it is 'systems' programmers
are the ones who just couldn't cut it in applications.

MCM

Pete Dashwood

2008-04-01, 9:56 pm

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:ZrzIj.36801$J41.3240@newssvr14.news.prodigy.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65folmF1f605pU1@mid.individual.net...
>
> Applications programmers (eg, moi) don't think in terms of "components";
> strangely enough, we think in terms of "applications."
>
> I guess that explains as well as anything why it is 'systems' programmers
> are the ones who just couldn't cut it in applications.
>

:-)

I build Applications from components; probably comes from using Meccano with
my Dad when I was a kid (before they invented Lego).

I have tried doing it the way you do, but I like the component based
approach better.

"Chacun a son gout" as the Irish say...

Pete.
--
"I used to write COBOL...now I can do anything."

Clark F Morris

2008-04-01, 9:56 pm

On Tue, 01 Apr 2008 23:21:29 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:65folmF1f605pU1@mid.individual.net...
>
>Applications programmers (eg, moi) don't think in terms of "components";
>strangely enough, we think in terms of "applications."
>
>I guess that explains as well as anything why it is 'systems' programmers
>are the ones who just couldn't cut it in applications.

I did have one applications programmer tell me that I always was a
systems programmer after he inherited some of my COBOL programs. On
the other hand, my last three contracts were in applications where I
influenced at least one system and also provided applications
technical support to a Year 2000 project.

Clark Morris
>
>MCM
>
>
>

William M. Klein

2008-04-01, 9:56 pm

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.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47F232DA.6F0F.0085.0@efirstbank.com...
> <c463v3p7pdl8dc6dl5seo7j6u0mfrev3qr@4ax.com>, Robert<no@e.mail> wrote:
>
> Is anyone here a member of this Old Guard that is opposed to variable length
> strings? I certainly am not. I would love them.
>
> Frank
>

Robert

2008-04-02, 3:57 am

On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein" <wmklein@nospam.netcom.com> 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.

18.16.2.3
3) The INDIRECT phrase specifies that the subject of the entry is an indirect elementary
data item as defined in 8.5.1.7.2, Location of any-length elementary items. If the
INDIRECT phrase is not specified, an any-length elementary item declared at the 01 or 77
level or containing the LIMIT phrase is a direct elementary data item;
otherwise, that data item is an indirect elementary data item.

I read that to say a direct data item in the middle of a record (other than 01/77) must
have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to ODO, thus
eliminating the need to move everything following when the length changes.

William M. Klein

2008-04-02, 3:57 am

It does have a "limit" - but it still needs to "move" the following data. (Of
course in Standard COBOL there can't be data following an ODO). "for contiguity"
of items, see,

"8.5.1.8.1 Contiguity of data items
A variable-length data item may be part of any group structure, and its
neighbors may be non-variable-length data
items or variable-length data items. A variable-length data item is logically
but not necessarily physically
contiguous with its neighbors. However a variable-length data item behaves in
all respects as though it were in fact
contiguous with its neighbors whenever a procedural operation is applied to a
group containing it."

In other words, no matter how direct items are stored, if you process the "group
item" containing them, it must "appear" as if the following items are directly
after the current length - not after the MAXIMUM length.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:gh66v3h1ml3rjf9ic3nbgli94sh1j5fr1i@
4ax.com...
> On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> 18.16.2.3
> 3) The INDIRECT phrase specifies that the subject of the entry is an indirect
> elementary
> data item as defined in 8.5.1.7.2, Location of any-length elementary items. If
> the
> INDIRECT phrase is not specified, an any-length elementary item declared at
> the 01 or 77
> level or containing the LIMIT phrase is a direct elementary data item;
> otherwise, that data item is an indirect elementary data item.
>
> I read that to say a direct data item in the middle of a record (other than
> 01/77) must
> have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to
> ODO, thus
> eliminating the need to move everything following when the length changes.

MikeB

2008-04-02, 3:57 am

On Mar 31, 6:20 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> "MikeB" <MPBr...@gmail.com> wrote in message
>
> news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
> [snip]
>
> [snip]
>
>
> I am not feeling pressured and have a lot of time, so ...
> I rewrote your program adding the compression part
> and wrote a test program to call it. The results are as
> expected.
>
> ----- Results
> 76DF:54AE:A30:1:1:4321:EAD5:AA43
> FD05::1:0:5
> ::1

Rick,
I took about 1 1/2 hours to work through and understand what you
did. I'm stunned. You clearly showed the difference between an amateur
(me) and a professional (you).

Thank you. That was a valuable learning experience for me. I have 1
simple question to see if I understood all of that code correctly.

* Compress adjacent " 0"s, once

move 1 to ip-compress-state
perform
varying ip-index1 from 1 by 4
until ip-index1 > 28
evaluate ip-compress-state
when 1
if ip-octets (ip-index1:4) = " 0"
and ip-octets (ip-index1 + 4:4) = " 0"
then
move spaces to ip-octets (ip-index1:4)
move ": " to ip-octets (ip-index1 + 4:4)
move 2 to ip-compress-state
else
move 1 to ip-compress-state
end-if
when 2

The
else move 1 to ip-compress state seems redundant, since you
can only ever be in that particular piece of code when the state = 1?

I could not conceive of a logic path that would lead you to excecute
that statement when the state would be other than 1, but perhaps I
missed something?

Once again, thank you. This is really great. And I learned a lot.

Wish I could find a way to apply such stuff as my day-to-day job.

Robert

2008-04-02, 3:57 am

On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>It does have a "limit" - but it still needs to "move" the following data. (Of
>course in Standard COBOL there can't be data following an ODO). "for contiguity"
>of items, see,
>
>"8.5.1.8.1 Contiguity of data items
>A variable-length data item may be part of any group structure, and its
>neighbors may be non-variable-length data
>items or variable-length data items. A variable-length data item is logically
>but not necessarily physically
>contiguous with its neighbors. However a variable-length data item behaves in
>all respects as though it were in fact
>contiguous with its neighbors whenever a procedural operation is applied to a
>group containing it."
>
>In other words, no matter how direct items are stored, if you process the "group
>item" containing them, it must "appear" as if the following items are directly
>after the current length - not after the MAXIMUM length.

The next paragraph seems to confirm that, when it qualifies any-length with indirect. The
implication is that a change to a direct any-length item DOES affect the addresses of its
neighbors.

"The physical address of a variable-length data item may change during execution of the
program. Dynamic-capacity tables and indirect any-length elementary items, however they
may change during execution, do not in any way affect the addresses of their neighbors."

What procedural operations are they referring to? A MOVE and comparison would work if the
maximum length were allocated and following items not shifted. I can think of two
situations where it matters. FUNCTION LENGTH says nothing about variable-length groups,
which seems like an error. Reference modification cannot be used on variable-length
groups.

How can a program tell whether the item following an any-length elementary item is
contiguous? What behavior would be different?

Suppose program A calls B with the address of an indirect any-length item or
variable-length group containing a direct any-length item. B changes the item's size and
address. How does A know the new address? The parameter passed was the address of the item
or group, not the address of its base pointer. If a Cobol program did pass the addess of
the base pointer, which it would almost have to, that would cause problems for other
languages, including the OS API.

Rick Smith

2008-04-02, 3:57 am

"MikeB" <MPBrede@gmail.com> wrote in message
news:5bc82b56-8468-4624-9602-4d7085ffe9ff@m73g2000hsh.googlegroups.com...

[snip]

> Thank you. That was a valuable learning experience for me. I have 1
> simple question to see if I understood all of that code correctly.
>
> * Compress adjacent " 0"s, once
>
> move 1 to ip-compress-state
> perform
> varying ip-index1 from 1 by 4
> until ip-index1 > 28
> evaluate ip-compress-state
> when 1
> if ip-octets (ip-index1:4) = " 0"
> and ip-octets (ip-index1 + 4:4) = " 0"
> then
> move spaces to ip-octets (ip-index1:4)
> move ": " to ip-octets (ip-index1 + 4:4)
> move 2 to ip-compress-state
> else
> move 1 to ip-compress-state
> end-if
> when 2
>
> The
> else move 1 to ip-compress state seems redundant, since you
> can only ever be in that particular piece of code when the state = 1?
>
> I could not conceive of a logic path that would lead you to excecute
> that statement when the state would be other than 1, but perhaps I
> missed something?

It is redundant, but it shows what state will be the next
state. I do the same in the code following 'when 2', which
has 'move 2 to ip-compress-state', after adjusting for an
adjacent compressable field. Perhaps, it is something that
was left over from my days servicing computer equipment
that used ROM-based microprogramming, where next
address fields are never left empty.

> Once again, thank you. This is really great. And I learned a lot.

You're welcome, though I am left with the feeling that
I could have made it more clear as to how it worked or
perhaps had chosen a different way, if I had spent a bit
more time on it. And I apologize for not removing the
comment about formatting in reverse, which no longer
applies.

Howard Brazee

2008-04-02, 6:59 pm

On Wed, 2 Apr 2008 10:07:54 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>OO Code has a different set...
>
>1. Does it work?
>2. Is it small and complete (encapsulated)?
>3. Can I reuse and extend it easily?
>
>Efficiency is taken care of by keeping components small, and using
>optimizing compilers.
>
>Maintainability is not a consideration as long as the interface is simple or
>non existent.

Except those characteristics are essential for good maintainability.
The application needs to be maintainable. The system needs to be
maintainable. The component size is different and techniques for
making the code maintainable have changed.

But the goal is the same.

SkippyPB

2008-04-02, 6:59 pm

On Tue, 01 Apr 2008 23:21:29 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:65folmF1f605pU1@mid.individual.net...
>
>Applications programmers (eg, moi) don't think in terms of "components";
>strangely enough, we think in terms of "applications."
>
>I guess that explains as well as anything why it is 'systems' programmers
>are the ones who just couldn't cut it in applications.
>
>MCM
>
>
>

What make you think systems progrmmers can't cut it in application? In
the beginning of my career I pulled double duty as a systems and
applications programmer. Never had a problem with either.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Save the whales. Collect the whole set."
-- Steven Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Michael Mattias

2008-04-02, 6:59 pm

"SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
news:7oa7v3t4asvik0cnrlsk5j8k4o7g4jkodt@
4ax.com...> > What make you think
systems progrmmers can't cut it in application? In
> the beginning of my career I pulled double duty as a systems and
> applications programmer. Never had a problem with either.

I was afraid of this. I was too subtle in my saracasm.

Well, at least the *applications* programmers "get it."

MCM

William M. Klein

2008-04-02, 6:59 pm

The problems with using the "max" rather than the "current" size occurs when
referencing the entire group item and moving it, for example, to a single
receiving item. Having "undefined/garbage" data in the "unused" portion of the
max part will cause problems. The GROUP item doesn't know (need to know) how
the individual sub-items are defined.

Is this clear? If not, I can try doing an example.

***

As far as you example goes, when passing an indirect variable length item or a
group containing one, what will be past is a pointer. If the called program is
in another language, then you would define the structure with a pointer as what
was received and need to process it "accordingly". If the subprogram did
something that COBOL couldn't handle when it came back, then various "exception
conditions" might be raised.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:tce6v3hriqrje7kcom4petuon9rp0a84bl@
4ax.com...
> On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> The next paragraph seems to confirm that, when it qualifies any-length with
> indirect. The
> implication is that a change to a direct any-length item DOES affect the
> addresses of its
> neighbors.
>
> "The physical address of a variable-length data item may change during
> execution of the
> program. Dynamic-capacity tables and indirect any-length elementary items,
> however they
> may change during execution, do not in any way affect the addresses of their
> neighbors."
>
> What procedural operations are they referring to? A MOVE and comparison would
> work if the
> maximum length were allocated and following items not shifted. I can think of
> two
> situations where it matters. FUNCTION LENGTH says nothing about
> variable-length groups,
> which seems like an error. Reference modification cannot be used on
> variable-length
> groups.
>
> How can a program tell whether the item following an any-length elementary
> item is
> contiguous? What behavior would be different?
>
> Suppose program A calls B with the address of an indirect any-length item or
> variable-length group containing a direct any-length item. B changes the
> item's size and
> address. How does A know the new address? The parameter passed was the address
> of the item
> or group, not the address of its base pointer. If a Cobol program did pass the
> addess of
> the base pointer, which it would almost have to, that would cause problems for
> other
> languages, including the OS API.

Pete Dashwood

2008-04-02, 6:59 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:rp37v3pcskcjhk6ui9ack5lus9tcipff8k@
4ax.com...
> On Wed, 2 Apr 2008 10:07:54 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> Except those characteristics are essential for good maintainability.
> The application needs to be maintainable. The system needs to be
> maintainable. The component size is different and techniques for
> making the code maintainable have changed.
>
> But the goal is the same.

Yes, of course. However, the WAY in which the goals are met is very
different. "Self-documenting" code is irrelevant. It only matters if code is
to be constantly changed. If the code NEVER changes, then it doesn't matter.
That was my point.

Pete.
--
"I used to write COBOL...now I can do anything."

Robert

2008-04-02, 9:56 pm

On Wed, 02 Apr 2008 21:37:18 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>The problems with using the "max" rather than the "current" size occurs when
>referencing the entire group item and moving it, for example, to a single
>receiving item. Having "undefined/garbage" data in the "unused" portion of the
>max part will cause problems. The GROUP item doesn't know (need to know) how
>the individual sub-items are defined.

I think a group move DOES need to handle any-length items separately. 8.5.1.9 says:

"Unlike other group items, a variable-length group is not equivalent to an alphanumeric
data item and cannot undergo a comparison or a move operation, in either direction,
explicitly or otherwise, unless the other operand is a compatible group. Groups are
compatible if all variable-length data items correspond and match as specified
below. For the purposes of compatibility, either both operands may be variable-length
groups or only one of the operands may be a variable-length group.

Determination of compatibility between a variable-length group and another group is as
follows:
3) For each any-length elementary item in either group there is a corresponding any-length
elementary item in the other group as specified in 8.5.1.9.1, Positional correspondence."

You say, above, a variable length group can be moved to a single receiving item. The last
sentence of the first paragraph says the same. But the first sentence and 3) appear to
require they both be variable-length groups with corresponding any-length items.

It is easy picture a move from a variable-length group to a fixed-length item, such as a
file record. It is not as easy to picture the reverse. Say it's moving bytes until it gets
to an any-length string defined as prefixed by binary-long. The input doesn't contain a
binary-long. How does it determine the length of the string?

Getting back to a move between two variable-length groups,
there is no requirement that the corresponding any-length items match on
direct/indirect
prefixed/delimited
limit

On a group move, the sending group might contain a direct item (with limit) while the
corresponding item in the receiving group is indirect. The sending item might be delimited
by low-value while the receiving group is prefixed by binary-long.

For these reasons, it seems a grouip move would have to be three operations
copy the bytes preceding the any-length item
copy the any-length item, which may require scanning for a delimiter
or allocating memory
copy the bytes following the any-length item

>Is this clear? If not, I can try doing an example.

I would appreciate an example that deals with the above points.

> ***
>
>As far as your example goes, when passing an indirect variable length item or a
>group containing one, what will be passed is a pointer. If the called program is
>in another language, then you would define the structure with a pointer as what
>was received and need to process it "accordingly". If the subprogram did
>something that COBOL couldn't handle when it came back, then various "exception
>conditions" might be raised.

I found the answer under CALL. Any-length items and variable-length groups are NOT ALLOWED
to be passed as parameters, period. That avoids dealing with the issue of size changing in
the called program.

The returning item is not allowed to be an any-length item, but can be a variable-length
group containing an any-length item. This is not a mistake, it shows that someone on the
standards committee understands the issues I asked about. If the returning were an
any-length elementary item, the called program would have no way to communicate its new
location after a size change. But when the returning item is a group, the group contains
pointers to its variable-length elements, enabling the called program to pass back their
new locations.

>
>--
>Bill Klein
> wmklein <at> ix.netcom.com
>"Robert" <no@e.mail> wrote in message
> news:tce6v3hriqrje7kcom4petuon9rp0a84bl@
4ax.com...
>

Rick Smith

2008-04-03, 3:56 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65fmhdF2fbsenU1@mid.individual.net...
[snip]
> To modify existing functionality does NOT mean modifying a base class. It
> means extending (through inheritance) or over-riding existing behaviours.

The priniples of object-oriented design do not include
the use of inheritance to overcome inadequate or faulty
design. In such cases, modifying a base class may be
unavoidable.

Pete Dashwood

2008-04-03, 7:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:3vednXJ8aMTLxWnanZ2dnUVZ_q2hnZ2d@mi
d-floridainternet...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65fmhdF2fbsenU1@mid.individual.net...
> [snip]
>
> The priniples of object-oriented design do not include
> the use of inheritance to overcome inadequate or faulty
> design. In such cases, modifying a base class may be
> unavoidable.

I have never encountered such a situation and do not expect to. (Guess my
designs are not "inadequate" or "faulty"...:-))

I really don't care about academic "principles of OO design" unless they are
pertinent to the world in which I live and work; your statement above is
not.

My own principles (derived from over a decade of real world use) tell me not
to modify a Base Class.

So I don't.

Pete.
--
"I used to write COBOL...now I can do anything."

Sponsored Links