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

On Mon, 10 Mar 2008 20:47:40 -0400, "Charles Hottel"
<chottel@earthlink.net> wrote:

>I can't speak for waht Pete Dashwood meant, but imagine an exponential
>equation that specifies a rate of change. Next imagine that the exponent in
>the equation is itself varying at an exponential rate.

That is singularity type changes.   Or maybe just hyperbole.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dDzBj.440419>
> [progams]  that require ODO's, what he has stated does apply in some
> environments, but requires a use of "average" that is not universally
> used.

Occurs Depending On is a perfectly fine and potentially quite useful
source-code level technique.

But it's like all other techniques: there are times to use it and times to
use something else.

Trying to quantify the techniques used by the "average" programmer is a
fool's errand. Example?

One time I was bought in as an outside contractor to work on a very specific
piece of software with which I had prior experience. The person supervising
my work had been the primary COBOL programmer for the client for nine (9)
years.

When I pronounced the job done, quite reasonably this supervisor wanted to
check out my coding techinques before she let me go.

Imagine my surprise when this nine-year veteran told me not only was my code
acceptable, but she was glad to have had the chance to review it because she
had NEVER SEEN THE 'SEARCH' VERB USED BEFORE.

That was the day I quit making *any* assumptions about "normal" or "average"
programming techniques.

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

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

I'll have to say that I don't think I've ever Occurs Depending On used
much for internal tables wherever I've worked (at least in the last
couple of decades) - and its usage in data files has been largely
superseded, first with header and detail records, and later with
database access.

But that's only my experience, I can't speak for the industry.

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

>Frank,
>  I am not certain that they are saying that some of these features wouldn'
t be
>"useful".  However, as currently defined (in WD 1.10)  there are both techn
ical
>problems and the run-time overhead would be significant.

With the world moving away from CoBOL to OO languages - why should
run-time overhead in batch CoBOL be significant?

Pete Dashwood wrote:
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13tbq3hb852cjc9@corp.supernews.com... 
>
> Other viewpoints always welcomed by me... :-) 
>
> Well, as it is the core of their business, they WOULD say that, wouldn't
> they? :-)
>
> I don't believe it is even true today, but I can't prove it so won't argue
> it.
> 
>
> Not exactly as I recall... and I was there :-)
>

[snipped]
 
>
> Maybe, but that is an academic argument. It doesn't matter what you call i
t,
> the fact is that the new languages can be written quicker, re-written
> quicker, require much less code, and have facilities that COBOL simply
> doesn't. Whether they are doing procedural processing under the guise of O
O
> or not is immaterial; they can be generated to do it quicker than a good
> COBOL programmer can code the thousands of lines it takes.
>
> I have been astounded at the encapsulated functionality in languages like
> C#, that simply isn't available in COBOL. It doesn't even matter what the
> paradigm is, it is quicker to point and click in Visual Studio, than it is
> to write hundreds of lines of COBOL in ISPF. End of story.

Let me second or third or whatever that!  8-)

I discovered yesterday that list boxes in .NET store objects rather than jus
t
strings (strings are objects). That means I can store an array of records
encapsulated as object instances in the list box. When an item in the displa
yed
list is selected, the code processing the click event has direct access to t
he
objects contents. No searching or sorting!

A PowerCOBOL list box ,at least as of version 5, only stores text, meaning t
hat
code needs to be written to find the corresponding record in a table. Indici
es
need to be managed in a synchronized fashion in the list box and the backing
table. Insertion, deletion, modification routines, etc. More code to write,
debug and support.

The really  thing about storing  objects in the list box is that the obj
ects
do not have to all be of the same type. I'm not sure how often this will be 
useful
but I can see having a list box that presents the user with a hierarchy of c
hoices
the choices relating to different types of things.

> 
>
> I understand what you're saying, Rick, but I contend that they won't. I kn
ow
> from my own experience (somewhat like being dragged kicking and screaming
> into Java and C#) that the desire to go back to COBOL diminishes with the
> increasing understanding and facility in OO languages. Yes, I COULD develo
p
> web applications in OO COBOL, yes, I COULD write OO COBOL components, but 
I
> won't and don't. (I did for many years and felt like a "voice in the
> wilderness" receiving scorn and vitriol from most of the COBOL community
> when I suggested that OO might be important for COBOL,  and a total lack o
f
> support from COBOL vendors when problems arose. Nowadays when I have a
> problem, I don't need or want to go to MicroSoft; there are around 60
> million people writing C#... I can get a GOOGLEd solution in minutes. Also
,
> the demonstrated attitude of the C# community is a helpful and positive on
e
> in the C# forums I have used...) I just don't believe that once
> "multilingual" programmers go away from COBOL, they will need or want to g
o
> back to it.
>
> The "new" features in COBOL, even if they could be implemented, are not
> going to make any difference.
>
> I respect MicroFocus for taking a hand in the standards debacle and I
> honestly wish them well. Whether they are driven by commercial necessity o
r
> a genuine desire to improve COBOL, what they are doing is commendable.
>
> Unfortunately, I believe it is too late.
>
> Pete.
> "I used to write COBOL...now I can do anything."

Jeff

>
>
>


----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==-
---
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsg
roups
---= - Total Privacy via Encryption =---

In article <brjdt31tddip4bo55n9u8ma5gigqprt62q@4ax.com>,
Howard Brazee <howard@brazee.net> writes:
> On Tue, 11 Mar 2008 17:44:36 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
> 
>
> With the world moving away from CoBOL to OO languages

Funny, I keep hearing this, except from the people actually still
maintaining and writting large COBOL projects.

>                                                        - why should
> run-time overhead in batch CoBOL be significant?

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 11 Mar 2008 19:31:57 GMT, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:
 
>
>Funny, I keep hearing this, except from the people actually still
>maintaining and writting large COBOL projects.

This time you heard it from someone actually still maintaining large
CoBOL projects.

It is easy to keep my head in the ground, and that makes me feel
secure.   But feeling secure isn't the same thing as being ready for
what comes.

On Tue, 11 Mar 2008 02:08:27 -0000, tim <TimJ@internet.com> wrote:

>On Mon, 10 Mar 2008 09:20:46 -0600, Howard Brazee wrote:
> 
>
>If the program you are compiling says packed-decimal the standard says it
>must be stored in packed decimal format. Of course you can provide
>optimization flags that allow this rule to be overridden in the name
>of speed. But with redefines and pointers/linkage it gets very difficult to
>maintain correctness in the generated code if you change the format from
>packed decimal to binary for example.
>
>Packed decimal is mostly about the same speed as binary on IBM mainframes,
>but it's a lot slower than binary on most Unix/PC CPUs. Packed decimal is
>a lot faster than display format on mainframes for arithmetic, due to lack
>of microcode support for most arithmetic operations performed on display
>format data.


The only true decimal arithmetic on the IBM 360/370/390/z systems is
packed decimal and (IEE754 something on the latest z).  It is more
efficient than converting to binary, doing the arithmetic and
converting back.  It also is more efficient than what I think is
available for decimal arithmetic on the Intel chips.  It is not nearly
as efficient as binary on the z series (or predecessors) if you are
not trying to get decimal rounding and behavior in division and other
places where it matters.  Incidentally COBOL is NOT one of the
languages for which support for the new floating point decimal
arithmetic is announce on the z series.

Clark Morris

Clark Morris
>
>Tim

"Jeff Campbell" <n8wxs@arrl.net> wrote in message
news:1205259923_658@isp.n...
> Pete Dashwood wrote: 
>
> [snipped]
> 
>
> Let me second or third or whatever that!  8-)
>

Thanks for your support, Jeff :-)

> I discovered yesterday that list boxes in .NET store objects rather than
> just
> strings (strings are objects). That means I can store an array of records
> encapsulated as object instances in the list box. When an item in the
> displayed
> list is selected, the code processing the click event has direct access to
> the
> objects contents. No searching or sorting!
>
> A PowerCOBOL list box ,at least as of version 5, only stores text, meaning
> that
> code needs to be written to find the corresponding record in a table.
> Indicies
> need to be managed in a synchronized fashion in the list box and the
> backing
> table. Insertion, deletion, modification routines, etc. More code to
> write,
> debug and support.
>
> The really  thing about storing  objects in the list box is that the
> objects
> do not have to all be of the same type. I'm not sure how often this will
> be useful
> but I can see having a list box that presents the user with a hierarchy of
> choices
> the choices relating to different types of things.
>

This is a good example, but it is just one of many...

Facilities like code reflection, generalized procedures through delegation,
access to event models, simple building and processing of collections,
access to a host of components that run across platforms and save
incalcuable amounts of time, are just some of the facilities that COBOL
simply doesn't even begin to address...

For batch processing, it doesn't matter; beyond that, it certainly does
matter...

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

"Howard Brazee" <howard@brazee.net> wrote in message
 news:4gpdt3der0761opav40ebu4d3d4v0g9vi2@
4ax.com...
> On 11 Mar 2008 19:31:57 GMT, billg999@cs.uofs.edu (Bill Gunshannon)
> wrote:
> 
>
> This time you heard it from someone actually still maintaining large
> CoBOL projects.
>
> It is easy to keep my head in the ground, and that makes me feel
> secure.   But feeling secure isn't the same thing as being ready for
> what comes.

Well said, Howard.

It isn't really about "COBOL right or wrong".

It is about dealing with reality.

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