Home > Archive > Cobol > May 2006 > If all the CoBOL people updating the language...
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 |
If all the CoBOL people updating the language...
|
|
| Howard Brazee 2006-05-23, 6:55 pm |
| If all the CoBOL people updating the language over the last couple of
decades had done everything quickly and well, what would be the
language's future?
We would still have vendors making expensive compilers in an era when
learning Java has no compiler costs.
We would still have people developing Web skills using cheap tools -
and then graduating to tougher assignments with that background.
We would still have old timers using CoBOL the old way on mainframes,
not understanding how to migrate to OO.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
| Clever Monkey 2006-05-23, 6:55 pm |
| Howard Brazee wrote:
> If all the CoBOL people updating the language over the last couple of
> decades had done everything quickly and well, what would be the
> language's future?
>
Logical error: begging the question. Since the question is unanswerable
we have no choice but to illogically jump to some unrelated conclusion.
> We would still have vendors making expensive compilers in an era when
> learning Java has no compiler costs.
>
This is an anachronism. As compiler tools evolved, they did so in step
with development systems in general. Right now we have a world where
some compiler tools cost money to maintain. Even so-called free
toolchains have a cost somewhere. The question is, where do we want
those costs to be loaded?
> We would still have people developing Web skills using cheap tools -
> and then graduating to tougher assignments with that background.
>
Huh?
> We would still have old timers using CoBOL the old way on mainframes,
> not understanding how to migrate to OO.
>
That "migration" is not cheap, nor easy, nor risk-free. Are you ready
to take full responsibility for such a migration? Are you sure you want
your bank and insurance records managed by some code jockey just out of
school who only knows OO and thinks it is the One True Way? If OO was a
true panacea, it would have already solved our code maintenance
problems. As an experienced maintenance coder I can tell you this has
not happened. OO is a tool that can be used properly and for the right
problem. Nothing more.
Development systems move forward, in fits and starts, depending on a
complex matrix of requirements, economy and technical improvements. It
is an error to assume that we stand from a position we always knew we'd
arrive at. There is nothing so uncertain as the future. Unless your
crystal ball is so perfect, in which case I suggest getting out of the
computer business and into high-stakes gambling.
There is no obvious, shining path. Belief in such a thing proves that
the believer is not taking many important factors into consideration.
| |
| Pete Dashwood 2006-05-23, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:e7f672lk68005r2dtrgo13anat88s19im0@
4ax.com...
> If all the CoBOL people updating the language over the last couple of
> decades had done everything quickly and well, what would be the
> language's future?
>
> We would still have vendors making expensive compilers in an era when
> learning Java has no compiler costs.
>
> We would still have people developing Web skills using cheap tools -
> and then graduating to tougher assignments with that background.
>
> We would still have old timers using CoBOL the old way on mainframes,
> not understanding how to migrate to OO.
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com
>
Maybe. We'll never know.
Pete.
| |
|
| Howard Brazee wrote:
> If all the CoBOL people updating the language over the last couple of
> decades had done everything quickly and well, what would be the
> language's future?
>
> We would still have vendors making expensive compilers in an era when
> learning Java has no compiler costs.
> We would still have people developing Web skills using cheap tools -
> and then graduating to tougher assignments with that background.
>
> We would still have old timers using CoBOL the old way on mainframes,
> not understanding how to migrate to OO.
>
What I have found in my experience working for big, slow companies is
that cost isn't the consideration. It's quality and ease. It's
reliability and the comfort level that management feels will cause the
least risk. None of these types want a slick system with open source
code, no matter how well it works. Cheap or free scares them. They
want the ability to understand the system, recite a trusted Vendor
name. They want a nice big budget to work with as well. Office
politics unfortunately determines a lot of what resources are chosen
for a department's budget. This affects what we cube monkeys have to
work with, unfortunately in most cases.
This is why Cobol is still around, and will remain for a while yet,
until there is truly a sensible alternative. Anybody with skills
integrating existing legacy systems with the newer OO stuff will
probably benefit. I've been stuck with my old pal Cobol since Y2K, but
I'm not biased against it. No matter how I try, I can't get away from
the mainframe, so I've learned to love him. I'm a sucker for stability
I guess. I'm not an old timer yet, still in my 30's - but I like
working on mainframe systems. They don't crash or blow up, when the VB
or java apps freak out over the slightest issue. No drama with them,
they are sacred and I think unfairly maligned. The quickest and most
realistic way to do business, in a large shop, is to learn how to marry
the two, mainframe dino's and OO  ness. There's a place for both,
at least for now.
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com
| |
| Howard Brazee 2006-05-24, 9:55 pm |
| On 23 May 2006 20:30:15 -0700, "Holly" <anderschwan@hotmail.com>
wrote:
>What I have found in my experience working for big, slow companies is
>that cost isn't the consideration. It's quality and ease. It's
>reliability and the comfort level that management feels will cause the
>least risk. None of these types want a slick system with open source
>code, no matter how well it works. Cheap or free scares them.
There's some truth to this. But it only scares them for a while.
Cheap and easy comes in the back door. Apple II computers with
Visicalc snuck in. It wasn't long ago that Web pages were back-door
items.
When they decided to be a part of the Web, they found people who
already knew HTML and didn't have to go to HTML school. (Remember who
is doing the decision making). This was sort of like having the
bookkeepers running the early mainframes, they already knew tabulating
machines.
So the question is: As Web skills snuck in the back door, separate
from existing IS, could they have included CoBOL? I don't think
this was likely, even with an enhanced CoBOL, unless the language was
"free" the way Java and HTML were, or at least cheap, the way Visicalc
was.
Alternatively, were Visicalc or Web pages going to come in via MIS?
Not likely. Management was scared to let them in, and looked the
other way until it was too late to decide.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
| Clever Monkey 2006-05-24, 9:55 pm |
| Howard Brazee wrote:
> On 23 May 2006 20:30:15 -0700, "Holly" <anderschwan@hotmail.com>
> wrote:
>
>
> There's some truth to this. But it only scares them for a while.
> Cheap and easy comes in the back door. Apple II computers with
> Visicalc snuck in. It wasn't long ago that Web pages were back-door
> items.
>
Not in the enterprise. The personal computer and the business apps that
run on them were targeted directly at the small business sector. Larger
companies didn't see the point of such a tool until much, much later.
If I was being unkind, I'd suggest that such apps were afterthoughts,
anyway. The primary interest into personal computers was driven by
hobbyists and (later) people wanted to buy a neat toy. Actual
engineering or business uses for smaller firms came later, and most
medium sized companies used minis in the 70s and 80s. The underpowered
and unconnected personal computer was delegated to the secretary if it
was present at all. Engineers might have one at home to play with them
the way engineers do.
I don't know what you mean about "Web pages". Hypertext and the web was
a direct outgrowth from academic research. It was inspired and made
possible by server technology like Archie and Gopher, which in turn was
a direct outgrowth of the academic use of the internet. The intent was
to make a tool that facilitated communication between varied and
dispersed university researchers.
COBOL isn't even in the same space. COBOL/mainframe shops don't care
about cheap and easy. I'm late to this game and even I see that when I
work with insurance companies, telcos and manufacturers.
> When they decided to be a part of the Web, they found people who
> already knew HTML and didn't have to go to HTML school. (Remember who
> is doing the decision making). This was sort of like having the
> bookkeepers running the early mainframes, they already knew tabulating
> machines.
>
HTML is just one part of the "web", and I'm not sure who is doing any
sneaking here. Knowing how to make a simple web page isn't helping
anyone get a job in some new space, since hacking HTML is not really
related to anything from a previous paradigm.
> So the question is: As Web skills snuck in the back door, separate
> from existing IS, could they have included CoBOL? I don't think
> this was likely, even with an enhanced CoBOL, unless the language was
> "free" the way Java and HTML were, or at least cheap, the way Visicalc
> was.
>
Really, I know of no one who sneaked in the door knowing HTML. There
was a brief moment in the 90s when one could pretend to be a small-time
consultant and hack up basic sites for businesses just getting on the
ball (and a smart person might finagle that into a job in a real
company) but by and large web development was turned into a ghetto as
everyone chased the browser wars.
This is the reason for so many bad pages still in existence, and the
dearth of good sites. Those who have lasted in the biz have had to
become serious professionals on their own, but there are few parallels
with enterprise development. These folks work for themselves, or in the
marketing department. We are only climbing out of those dark ages now.
And, really, HTML can afford to be "free" since it is hardly
standardized or complete (or even /well-defined/). I still don't get
the connection between a lame SGML parser and an enterprise computing
system.
Again, VisiCalc made a lot of money at the time compared to other
commodity software, but it was one of the first shrink-wrapped apps to
do so. However, VisiCalc had little impact on the Accounts department
at any company larger than a handful of people. That is, the companies
using COBOL and mainframes likely did not depend on VisiCalc for
anything, and the user-base (such as it was) did not really mix or even
necessarily know about each-other.
To answer your question obliquely, some analysts are claiming that an
important space for enterprise development are mainframe developers who
also know client-server models, and can understand the challenges in
connecting the two worlds together. That is, specific tools like HTML
are not important, since we will have agents and processes that generate
well-formed HTML for us. The important thing is that we understand how
to mate mainframe processes with client-server (perhaps OO) processes to
solve modern business problems.
These are analysts, so take that with a grain of salt, but there you
have it.
> Alternatively, were Visicalc or Web pages going to come in via MIS?
> Not likely. Management was scared to let them in, and looked the
> other way until it was too late to decide.
>
I'm pretty sure conflating business apps like VisiCalc and knowing HTML
is not all that helpful. Then again, I'm not certain what you are
driving at. I'm not sure I agree with your premise that knowing a bit
of HTML is in any way related to coding in an enterprise level computing
environment, or that a modern toolchain like Java can be used as any
sort of yardstick. Java is "free" (in some respects) only because this
is the space it is in now. There are also many other free compiler
tools that have been around for much longer. This is more of a function
of the explosion of the internet than anything else.
Java is based on modern techniques developed over many years since COBOL
was invented to solve a set of highly critical business problems. To
me, you are comparing Apples and Pencils.
Perhaps if you use a different example I might see your point.
| |
| Howard Brazee 2006-05-24, 9:55 pm |
| On Wed, 24 May 2006 13:18:03 -0400, Clever Monkey
<clvrmnky.invalid@hotmail.com.invalid> wrote:
>Not in the enterprise. The personal computer and the business apps that
>run on them were targeted directly at the small business sector. Larger
>companies didn't see the point of such a tool until much, much later.
It took longer, but they arrived. At first it was lower level
management, sales staff, and such, but as they were promoted, Visicalc
was promoted to Lotus and then Excel, without management decisions.
>I don't know what you mean about "Web pages". Hypertext and the web was
>a direct outgrowth from academic research. It was inspired and made
>possible by server technology like Archie and Gopher, which in turn was
>a direct outgrowth of the academic use of the internet. The intent was
>to make a tool that facilitated communication between varied and
>dispersed university researchers.
The stuff that the other programmers create and get noticed for
separate from the CoBOL programmers. The academia didn't back-door
these into enterprise shops, but hobbyists and new hires did.
Now that they have arrived, it no longer is a big risk to pick their
tools over our tools with the next big purchase of an Information
System package.
>COBOL isn't even in the same space. COBOL/mainframe shops don't care
>about cheap and easy. I'm late to this game and even I see that when I
>work with insurance companies, telcos and manufacturers.
But commercial packages now have Web front ends. And enterprise
companies have IS personnel who can maintain them. They also have
Suns running Oracle which can be accessed via just about any tools.
All of these have gradually become part of the enterprise culture,
it's no longer Mainframe CoBOL or nothing. And it happened without
making a decision that Mainframe CoBOL wasn't the future.
>This is the reason for so many bad pages still in existence, and the
>dearth of good sites. Those who have lasted in the biz have had to
>become serious professionals on their own, but there are few parallels
>with enterprise development. These folks work for themselves, or in the
>marketing department. We are only climbing out of those dark ages now.
>
>And, really, HTML can afford to be "free" since it is hardly
>standardized or complete (or even /well-defined/). I still don't get
>the connection between a lame SGML parser and an enterprise computing
>system.
Companies played with web pages because it didn't cost much. Then
they learned how useful the were, and gradually spent more money to do
them better. No big decisions there, but now they have two
computing staffs, the old forgotten staff, and the new sexy staff.
>To answer your question obliquely, some analysts are claiming that an
>important space for enterprise development are mainframe developers who
>also know client-server models, and can understand the challenges in
>connecting the two worlds together. That is, specific tools like HTML
>are not important, since we will have agents and processes that generate
>well-formed HTML for us. The important thing is that we understand how
>to mate mainframe processes with client-server (perhaps OO) processes to
>solve modern business problems.
Those guys aren't CoBOL guys. Systems, Interfacing, privacy, &
security are bigger than ever.
>Java is based on modern techniques developed over many years since COBOL
>was invented to solve a set of highly critical business problems. To
>me, you are comparing Apples and Pencils.
Business packages are being built with databases and Java interfaces.
My point though is that I see people lamenting the fact that CoBOL
hasn't been updated sufficiently to meet modern demands. I don't
think such updating would have significantly influenced the way
decisions have been made with regards to CoBOL and the enterprise.
Those decisions were made for other reasons.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
| |
| Richard 2006-05-24, 9:55 pm |
| > However, VisiCalc had little impact on the Accounts department
> at any company larger than a handful of people.
That is simply not true. The reason that IBM produced its PC was
exactly because it was finding Apple IIs and Commodore Pets in its
mainframe sites running Visicalc, and CP/M machines with WordStar and
dBase. The PC was aimed exactly at those with the same software and
much the same hardware. They took their System 23 and hacked it into
the 5150. IBM regarded their PC as a terminal for larger machines with
added facilities (which is why the serial ports are DTE).
Small businesses were using the small multiuser systems such as Altos,
PolyMorphic and Onyx.
| |
| Clever Monkey 2006-05-24, 9:55 pm |
| Richard wrote:
>
> That is simply not true. The reason that IBM produced its PC was
> exactly because it was finding Apple IIs and Commodore Pets in its
> mainframe sites running Visicalc, and CP/M machines with WordStar and
> dBase. The PC was aimed exactly at those with the same software and
> much the same hardware. They took their System 23 and hacked it into
> the 5150. IBM regarded their PC as a terminal for larger machines with
> added facilities (which is why the serial ports are DTE).
>
> Small businesses were using the small multiuser systems such as Altos,
> PolyMorphic and Onyx.
>
I'll accept this, but I do note that you mention that these early PCs
were thought of as terminals. This is really the point I was making.
There was no "back door" driving this, but a business need.
No business I've ever worked for until the late 90s ever used PC
software for accounting or customer information. All used homegrown
systems running on Unix or (later) big commercial systems.
It's a well-known irony noticed by many old-timers, that PCs were
originally viewed as adjuncts to big iron and now are the defining
aspect of many enterprise organizations.
| |
| Richard 2006-05-24, 9:55 pm |
| > No business I've ever worked for until the late 90s ever used PC
> software for accounting or customer information. All used homegrown
> systems running on Unix or (later) big commercial systems.
That depends on what you mean by 'PC'. If you mean 'Computers that are
Personal' then, no, they wouldn't. If you mean 'IBM 5150, 5170 PCs and
clones' then they were all but useless until Novell networking allowed
them to share data reliably. If you are using 'PC' as a general term
for microcomputer then I haven't worked for any company for the last 20
or more years that _didn't_ use 'PC software' for accounting and
customer information.
You may recall that the Apple II was the first 'PC', advertised as a
'Personal Computer' around 1979.
I first worked with networked micros and micro (8080/8085/Z80)
multiuser systems in the late 70s, I still have some Polymorphics,
Onyxes and lots of ICLs lying around here. These ran TheOS, MP/M,
TurboDOS or other Multiuser and there were several software houses
selling accounting packages. Later used 8086/386/486 with
Concurrent-CP/M, CDOS and derivitives (in fact I still do) and now
Linux.
| |
| Howard Brazee 2006-05-25, 7:55 am |
| On Wed, 24 May 2006 19:14:30 -0400, Clever Monkey
<clvrmnky.invalid@hotmail.com.invalid> wrote:
>I'll accept this, but I do note that you mention that these early PCs
>were thought of as terminals. This is really the point I was making.
>There was no "back door" driving this, but a business need.
What IS thought the PCs were doesn't change the fact that they were
used in ways that IS did not plan for, and that the business model for
IS changed from the way users used them - as opposed to the way IS
planned.
That said, Apples with Visicalc were already in place before PCs were
being used as terminals. Even PCs with Lotus were in before IS
decided that they could be used as terminals.
| |
| Alistair 2006-05-25, 6:55 pm |
|
Richard wrote:
>
> That depends on what you mean by 'PC'. If you mean 'Computers that are
> Personal' then, no, they wouldn't. If you mean 'IBM 5150, 5170 PCs and
> clones' then they were all but useless until Novell networking allowed
> them to share data reliably. If you are using 'PC' as a general term
> for microcomputer then I haven't worked for any company for the last 20
> or more years that _didn't_ use 'PC software' for accounting and
> customer information.
>
I encountered an accountancy firm in 1982 which used a Commodore Pet
micro to do accounting work for customers.
| |
| Clever Monkey 2006-05-26, 6:55 pm |
| Richard wrote:
>
> That depends on what you mean by 'PC'. If you mean 'Computers that are
> Personal' then, no, they wouldn't. If you mean 'IBM 5150, 5170 PCs and
> clones' then they were all but useless until Novell networking allowed
> them to share data reliably. If you are using 'PC' as a general term
> for microcomputer then I haven't worked for any company for the last 20
> or more years that _didn't_ use 'PC software' for accounting and
> customer information.
>
I mean "Personal Computer" of any sort. Obviously our experiences differ.
|
|
|
|
|