J4 - presentation/discussion on "Future of the COBOL Standard"

In article <63q1pkF28mvcqU1@mid.individual.net>,
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> writes:
>
>
> "Bill Gunshannon" <billg999@cs.uofs.edu> wrote in message
> news:63o51dF28emujU1@mid.individual.net... 
>
> Sometimes, when you are in the middle of something, your perception of tha
t
> thing is different from that of someone who is detached or outside it.
>
> People will be maintaining COBOL for some years to come yet, and the peopl
e
> doing that see only that.

You obviously missed the part about writting large applications in
COBOL.

>
> (I predicted 12 years ago that by 2015 COBOL would no longer be used as th
e
> major in-house development language, and would, to all intents and purpose
s
> be "dead"...I see no reason to change that prediction and, in fact, it is
> coming true quicker than I thought...)

Maybe in New Zealand!

>
> It is still important and relevant. (At least for now; take another look i
n
> 7 years...)

Like Unix and many other things, I was told that COBOL was on its way out
over 25 years ago.  Guess what.......  I have recently looked at a number
of places that are looking for long term, full-time COBOL programmers.
Unfortunately they almost all want current IBM OS experience, which I
don't have, having been out of the IBM forld for nearly 30 years.
These places are nit just doing maintenance while they migrate to C#
or Java.  They are still developing applications in COBOL.  Just because
the user doesn't see the COBOL doesn't mean it isn't there.

>
> But that doesn't change the overall trend. The rate of change is
> accellerating and and what might have taken 30 years last century, may tak
e
> 15, or even 10, in this one...
>
> There is a new influx of computer people coming into the industry who are
> NOT conditioned to a sequential procedural paradigm. The "old timers" are
> dying off or retiring. The effects of this are inevitable.

Yeah, Fortran is supposedly the same way, except that I have seen recent
job postings looking for people who know Fortran or are willing to learn.
Oldtimers can pass their knowledge on.  If you can really program in one
language it is not all that different to learn a new one.  Especially
if you just ignore all the hype over new paradigms that really don't
apply to your core business.

>
> Meantime, as you observed, "business as usual"...:-)

And likely to be so til long after I am out of the IT world.

bill

--
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

On Wed, 12 Mar 2008 17:01:25 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Now, your point about sorts on ODO arrays being faster is an interesting
>one, but, as I have never used an ODO array in memory and therefore have no
>need to sort it, for me, that's a teeny bit irrelevant... I don't sort fixe
d
>length arrays either; instead, I load them in sequence and use SEARCH ALL
>(if they're large) or just SEARCH if they're small. Easy, no messing, does
>the job, works for me.

And if they're tiny, I search by hand (days of the w).

On Thu, 13 Mar 2008 01:48:57 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>But that doesn't change the overall trend. The rate of change is
>accellerating and and what might have taken 30 years last century, may take
>15, or even 10, in this one...
>
>There is a new influx of computer people coming into the industry who are
>NOT conditioned to a sequential procedural paradigm. The "old timers" are
>dying off or retiring. The effects of this are inevitable.

I wonder how long it will take before we will be at an equivalent
stage with today's methodologies and tools.

On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:m1pbt3hf9l197putsqlr2pvr1iccpgv7ka@
4ax.com... 
><snip>
> 
>
>As usual, Robert's claim for what the "average COBOL porgramme" does or doe
sn't
>do is based on his rigourously applied research method, i.e. "it seems to m
e -
>that of those programs and programmers that I have seen, that ..."
>
>Needless to say, given the LARGE number of files that are still used by COB
OL
>programs and that require ODO's, what he has stated does apply in some
>environments, but requires a use of "average" that is not universally used.

I don't know any statistics regarding an "average Cobol program" but I
do know our shop standard for the 25+ years I've worked for my
employer disallows the use of "Occurs Depending On" clause in our
software.

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

"With global warming, somebody's baby is going to have to burst into
flames to make people do the right thing."
--  Chris Rock
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

On Mar 13, 2:16 am, Robert <n...@e.mail> wrote:
> On Tue, 11 Mar 2008 20:38:59 -0700 (PDT), Richard <rip...@azonic.co.nz> wr
ote: 
> 
> 
> 
>
> You are missing the point. That several writers here were opposed to ODO s
hows the opinion
> of some 'typical' programmers.

I am not sure that they were 'opposed' to it, they simply didn't
bother with it.

 
> 
> 
> 
> 
>
> HP didn't write that; Micro Focus write it. The exact same sentence appear
s in most Micro
> Focus manuals.
> 
> 
>
> 1000.
> 
>
> There is only one way to implement a binary search. Unless the value of 2 
is different in
> your universe.

These are different things entirely. You are correct that with a
smaller table the number of binary chops reduces. However, if each
access is 'less efficient', because for example it checks against a
data item rather than literal, then it may still be slower.

In any case, even if the SEARCH ALL is faster it may be that loading
the table is slower, especially if the DO is incremented with each
access.

On Wed, 12 Mar 2008 11:30:03 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

>In any case, even if the SEARCH ALL is faster it may be that loading
>the table is slower, especially if the DO is incremented with each
>access.

Without having table sorts available, I've coded comb sorts in CoBOL.
An example of this was a report where all of the line items for each
bill need to be sorted in a bill run.

>>> On 3/11/2008 at 10:01 PM, in message
<63p2sfF28n6tgU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
> No they don't. But they can vary in length, WITHOUT needing ODO...
> VARCHAR
> columns are implemented the way ODO SHOULD have been... transparently to
> the
> user.

This is exactly one of the reasons that Cobol should have dynamic length
fields.  Currently you have to define a "VARCHAR" in Cobol like this:

01  A-VARCHAR-STRING.
49  A-VARCHAR-STRING-LEN   PIC S9(4) COMP-5.
49  A-VARCHAR-STRING-TXT   PIC X(1000).

EXEC SQL
SELECT A_VARCHAR_STRING
INTO :A-VARCHAR-STRING
FROM FRANK.TABLE1
END-EXEC

DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING-TXT(1:A-VARCHAR-STRING-LEN)
'"'.

Yuck!!  I would much rather have:

01  A-VARCHAR-STRING   PIC X ANY LENGTH
LIMIT IS 1000
PREFIXED BY BINARY-SHORT.

EXEC SQL
SELECT A_VARCHAR_STRING
INTO :A-VARCHAR-STRING
FROM FRANK.TABLE1
END-EXEC

DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING '"'.

Though to be honest the data definition is much too long, but I could live
with it just to have this feature.

Frank

On Mar 13, 2:12 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Robert" <n...@e.mail> wrote in message
>
>  news:38kft3t3h52mm32b1vekgqe1qu98l7l1la@
4ax.com...
>
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> No comment?
> 
> 
>
> Er...excuse me, but I think it does. It says the size of the array DEPENDS
> ON the count field. But it doesn't. The size of the array is always the
> maximum possible.

Whether that is true or not is an implementation issue. A particular
compiler _could_ make it truly dynamic, but the performance penalty
would be unacceptable.

In any case, for file records it _IS_ true. The size of the record on
tape/disk really does depend on the count field.

The problem with Robert's claims(this time) is that ODO is used for
two different things. It controls the size of records in files, and it
is used to limit SORT and SEARCH. The first use is a bad thing because
there shouldn't be arrays in file records, but when tapes were all one
had it was a useful way of having sub-records. The complications of
having multiple ODO led to sites banning its use, quite rightly, when
disks became available and a separate file could be used for them.

While it may be true that SEARCH ALL is fractionally faster using ODO
and the recent ability to SORT a table requires it,  these are seldom
used. Most of my tables are used sequentially because they hold groups
of data, they are lists not arrays. I can't recall ever bothering with
a SEARCH ALL. In most applications of requiring stuff by key I have
used the indexed file directly rather than load it all into an array
and SEARCH for it.

In any case SEARCH ALL still works without ODO, just fill the unused
portion with high values <shrug>. My tests do show that with Fujitsu
the ODO array access is fractionally slower, but only by 1%, and that
is with the depending on set fixed at maximum.

It is all to do with designing the system right in the first place
rather than fretting over a few milliseconds.

> 
>
> I have yet to see an implementor's manual that references the standard. As
> implementor's manuals are what programmers normally use, whatever the
> standard says is really irrelevant.
> 
>
> I know of no way in COBOL (apart from CICS and Assembler GETMAIN calls on
> IBM mainframes) that can DYNAMICALLY allocate storage. So how exactly am I
> supposed to dynamically allocate these ODO structures?
>
>
> 
> 
>
> I doubt it and would need to see proof.  And, to be brutally frank, I real
ly
> don't care... :-)
>
> ODOs must be calculated at run time (even for fixed references); fixed
> length can be calculated at compile time, for fixed references. I would
> agree there probably isn't much to choose between variable references, but
> I'd still have to code that awful ODO and it is UGLY!!!! :-)
>
> Even then, if it saves a few milliseconds but I have to code ODO, that
> solution is not for me...
> 
>
> :-)
>
> Given that I have actually optimised existing applications and been paid
> serious money for making them run many times faster than they did
> previously, probably not much. However, I am not obsessed by processor spe
ed
> in applications which spend most of their time waiting for IO to complete.
.
>
>
> 
> 
>
> OK, if you say so... :-)  I really have no comment on that so will butt ou
t
> at this point.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

If the proposed revision:

A) limited ANY LENGTH items to the 01-level, then it might work better

B) made any of the BINARY-xxxx fields something other than processor depende
nt

C) didn't try and support both "direct" and "indirect" storage of such items
,

Then, Yes, I would say that it might be a useful feature.  As currently defi
ned,
it just has BUNCHES of problems (both in the specification and probable
performance hits).

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47D7DC66.6F0F.0085.0@efirstbank.com... 
> <63p2sfF28n6tgU1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote: 
>
> This is exactly one of the reasons that Cobol should have dynamic length
> fields.  Currently you have to define a "VARCHAR" in Cobol like this:
>
> 01  A-VARCHAR-STRING.
>    49  A-VARCHAR-STRING-LEN   PIC S9(4) COMP-5.
>    49  A-VARCHAR-STRING-TXT   PIC X(1000).
>
> EXEC SQL
>    SELECT A_VARCHAR_STRING
>    INTO :A-VARCHAR-STRING
>    FROM FRANK.TABLE1
> END-EXEC
>
> DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING-TXT(1:A-VARCHAR-STRING-LEN
)
> '"'.
>
> Yuck!!  I would much rather have:
>
> 01  A-VARCHAR-STRING   PIC X ANY LENGTH
>                       LIMIT IS 1000
>                       PREFIXED BY BINARY-SHORT.
>
> EXEC SQL
>    SELECT A_VARCHAR_STRING
>    INTO :A-VARCHAR-STRING
>    FROM FRANK.TABLE1
> END-EXEC
>
> DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING '"'.
>
> Though to be honest the data definition is much too long, but I could live
> with it just to have this feature.
>
> Frank
>

On Wed, 12 Mar 2008 12:45:11 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

>The problem with Robert's claims(this time) is that ODO is used for
>two different things. It controls the size of records in files, and it
>is used to limit SORT and SEARCH. The first use is a bad thing because
>there shouldn't be arrays in file records, but when tapes were all one
>had it was a useful way of having sub-records. The complications of
>having multiple ODO led to sites banning its use, quite rightly, when
>disks became available and a separate file could be used for them.

Even with tapes, the concept of header and detail records was being
used instead of variable length tables after a while.