Success stories for Cobol
Ken Foskey
Following on from an email from Pete Dashwood. Do we have a
collection of real success stories of migrating the current system to
a web enabled application using Cobol and tools.
I am sure we can get one from Vendors but this is really about the
guys at the coal face having success so that it is not seen as a
marketing blurb (well it is but it is for the programmers).
quote from Pete>>>>>>>>>>>>>>
What we need are some Application successes so that when the spotty
nerd
comes in and says: "we are going to replace COBOL with python", the
Senior
Exec can say: "Interesting you mention COBOL. I know nothing about it
of
course, but the TIMES this morning said that our competitors are using
it
with great success. Apparently they saved a fortune revamping their
Life
and Pensions Group and are poised to grab a market slice, after we
thought
they were no longer a threat. I'll be interested to see the backing
for
your recommendations...and the costs..."
Nerd goes away and grabs the TIMES. Now he consults with his mentor
back at
AA. They agree it would be wise to propose something that is likely to
be
readily accepted, so they propose a review of all existing COBOL
applications with a view to funding enhancement and new development
within
the same paradigm. They still get their team in and everyone is happy.
If you think the above scenario is far-fetched, I can assure you it is
(very loosely) based on actual events which I have personally been
privy
to.
Remember also that newspapers prefer items which go "against the
flow".
<<<<<<<<<<<<<<<<<<<<<
I personally think this is a great idea. We really need to advertise
the power of cobol. I would go further than this.
<Anology follows>
There was a major change in thinking for the apple industry here in
Australia, they used to advertise that apple A was better than apple
B. They changed their tune, they realized their competition was
chocolate bars and now they are going from strength to strength.
What is the point of this ditty, well Cobol is the apples. We have
vendors thinking they are competing for the same market share, in
reality they are shrinking the market share by missing the major
point, portability.
</anology>
We desperately need the vendors to closely work together to come up
with a better minimum standard including some of the basic tools that
programmers can easily get elsewhere. This set needs to work on the
basic four Web, IBM, Unix and PC.
Cobol vendors are not competing for Cobol market share they are
competing with Delphi, Visual Basic (yuk), Small talk, etc. When
cobol was king it had the VSAM file access built into the language
when other languages were just thinking about it, this is what set it
aside from the other languages. To be blunt what does it offer me
now. Don't give me readable code, give me less code to write so I am
more productive.
We need the vendors and the standards committee to pull their fingers
out and really work on a minimum standard operational set for today's
computers including screen handling, tools such as collections,
persistent objects, etc. If the vendors fail to do this Cobol will
frankly loose my programming vote.
Now should I tell you what I really feel....
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
For fast secure document delivery on the Net
http://www.themailxchange.com.au/
Paddy Coleman
MERANT has a number of high profile successes in this area. For
details please see:
http://www.merant.com/customer_stories/
All the best.
Paddy Coleman
Manager, E-Business Support, EMEA
MERANT International
Ken Foskey <war...@zip.com.au> wrote in message
news:3957598C...@zip.com.au...
YukonMama
I'm not sure if this is a success or not....
A few of my coworkers have succeeded in putting an inquiry of a DB2 table out
on the web using COBOL and Websphere and I'm not sure what else. Anyway one of
them was giving a demonstration to some of the users and while they thought it
was pretty they saw no advantage to it over a 'green screen' ie a regular CICS
screen.
Management is gung ho about putting things out to the web via the mainframe -
the users are still dubious.
I'll report as things progress.
Eileen
(um my manager did little snoopy dances when he got his palm pilot hooked up to
the mainframe. We led him back to his desk and took away the rest of his
caffine for the day)
SkippyPB
us:
Last year I completed a project for an unamed (by me) bank that posted
cleared items for their commercial customers on a web page. The
request came from a server to a Tandem and then on to an IBM mainframe
via MQ where the data was gathered and formatted via mostly Cobol
programs and then returned along the reverse path. I wrote all the
Assembler and Cobol programs for the IBM side of the process.
Does that count?
Regards,
////
(o o)
-oOO--(_)--OOo-
Wife who puts husband in doghouse soon find him in cathouse.
Boycott Mitsubishi Industries
Remove nospam to email me.
Steve
William Lynch
I work for one of the big NYC banks. We implemented our first (in my
sector, anyway, securities processing) Internet application Sept. '99.
Customers enter instructions on our secure site and they're routed to
our existing COBOL/CICS application which processes all the existing
stuff, as well. It contains all the business rules and we won't junk it
casually. There's also a back end which makes all the customer's reports
available for downloading from the 'Net.
This is our strategic direction. We started providing our smaller
customers with PC based applications 10-12 years ago so they could enter
instructions & upload them to us. It worked great; but the more
successful it became, the bigger our expenses became managing all these
accounts & upgrading their software as needed. The PC software is being
phased out by the 'Net application. Never a problem with software
upgrades in this environment.
Bill Lynch
PS: If you're wondering why the smaller customers, the bigger ones have
system-to-system links & their trading systems send new transactions to
us automatically.
war...@my-deja.com
>
> I work for one of the big NYC banks. We implemented our first (in my
> sector, anyway, securities processing) Internet application Sept. '99.
> Customers enter instructions on our secure site and they're routed to
> our existing COBOL/CICS application which processes all the existing
> stuff, as well. It contains all the business rules and we won't junk
> it casually. There's also a back end which makes all the customer's
> reports available for downloading from the 'Net.
>
> This is our strategic direction. We started providing our smaller
> customers with PC based applications 10-12 years ago so they could
> enter instructions & upload them to us. It worked great; but the more
> successful it became, the bigger our expenses became managing all
> these accounts & upgrading their software as needed. The PC software
> is being phased out by the 'Net application. Never a problem with
> software upgrades in this environment.
>
> Bill Lynch
Bill,
Could you provide more information about the original system?
What language was the original written in?
Why did you choose to web enable cobol rather than migrating the PC
solution to the Web solution?
These questions are important to the manager making the decision.
'Configuration management' the process of releasing test and production
releases is often overlooked in a development process. This is why thin
clients are so attractive.
Thanks
Ken Foskey
http://www.zipworld.com.au/~waratah/
Sent via Deja.com http://www.deja.com/
Before you buy.
William Lynch
>
> wbl...@worldnet.att.net wrote:
> >
> > I work for one of the big NYC banks. We implemented our first (in my
> > sector, anyway, securities processing) Internet application Sept. '99.
> > Customers enter instructions on our secure site and they're routed to
> > our existing COBOL/CICS application which processes all the existing
> > stuff, as well. It contains all the business rules and we won't junk
> > it casually. There's also a back end which makes all the customer's
> > reports available for downloading from the 'Net.
> >
> > This is our strategic direction. We started providing our smaller
> > customers with PC based applications 10-12 years ago so they could
> > enter instructions & upload them to us. It worked great; but the more
> > successful it became, the bigger our expenses became managing all
> > these accounts & upgrading their software as needed. The PC software
> > is being phased out by the 'Net application. Never a problem with
> > software upgrades in this environment.
> >
> > Bill Lynch
>
> Bill,
>
> Could you provide more information about the original system?
>
> What language was the original written in?
> Why did you choose to web enable cobol rather than migrating the PC
> solution to the Web solution?
The system was originally written in COBOL II for a CICS environment on
an IBM mainframe (1992-93 time frame). We did not migrate the PC
solution to the Web, the Web is all new technology & design. We're
eliminating the PC solution for the reasons given.
Just occurred to me that you're interested in the original PC software.
It was written in some form of C and the first version of that software
was released to customers late '89-early '90. That version of software
was interfaced to an earlier version of the software we wrote in
1992-93.
Bill Lynch (who hasn't worked on the PC end of it)
Thane Hubbell
input system to "the web". The users were involved in the conversion
from day one, in order to try to avoid the pitfalls you mentioned.
Well, finally near completion, in parallel testing the final complaint
is -- it takes twice as long to enter the data with the web version.
Sure, it's pretty, but is it the right replacement for a heads down
data entry system?
On 01 Jul 2000 05:18:02 GMT, yuko...@aol.com (YukonMama) wrote:
>Well.....
>
>I'm not sure if this is a success or not....
>
>A few of my coworkers have succeeded in putting an inquiry of a DB2 table out
>on the web using COBOL and Websphere and I'm not sure what else. Anyway one of
>them was giving a demonstration to some of the users and while they thought it
>was pretty they saw no advantage to it over a 'green screen' ie a regular CICS
>screen.
>
>Management is gung ho about putting things out to the web via the mainframe -
>the users are still dubious.
>
>I'll report as things progress.
>
>Eileen
>
>(um my manager did little snoopy dances when he got his palm pilot hooked up to
>the mainframe. We led him back to his desk and took away the rest of his
>caffine for the day)
---
Try a better search engine: http://www.google.com
My personal web site: http://www.geocities.com/Eureka/2006/
Joshua Seltzer
For heads down data entry we have found properly designed character based
programs provide much faster entry on the part of our staff as well as much
less load and investment is systems, wans etc. It seems that the best
operating platform for GUI is a trade show floor. In our real world
experience the replacement of a "legacy" payroll & HR system with a new GUI
windows resulted in the same work taking about twice as long. We have been
designing and implementing our own systems for almost 20 years, all in
COBOL. We are now in the last stages of completing a major rewrite and new
version of a client-server Point of Sale system running on SCO UNIX using
Micro Focus Cobol,
SP2 for screens (did you know SP2 can do great pop ups, list boxes etc. in
character mode?) and client systems using embedded Unix (no windoz at all).
To round things out we use Micro Focus Fileshare for distributed file
handling. The character beside screens are very fast and the telnet and
rlogin features of Unix make implementation quick and inexpensive. The
System has been in live use since November 1999.
For SP2 screen coding we use a utility called IDW from The Business
Assistance Group www.bagtools.com to help create very sophisticated screen
features using SP2. It saves about 85-90% of the screen coding time. This
utility runs in windows and is compatible with SP2 screens on all platforms.
Josh Seltzer
Larich Distributors, Inc.
jsel...@larich.com
Thane Hubbell wrote in message <395f3546....@207.126.101.100>...
>Recently our payroll data entry was converted from a Unix text mode
>input system to "the web". The users were involved in the conversion
>from day one, in order to try to avoid the pitfalls you mentioned.
>Well, finally near completion, in parallel testing the final complaint
>is -- it takes twice as long to enter the data with the web version.
>Sure, it's pretty, but is it the right replacement for a heads down
>data entry system?
>
>On 01 Jul 2000 05:18:02 GMT, yuko...@aol.com (YukonMama) wrote:
>
<SNIP>-
William Lynch
>
> Recently our payroll data entry was converted from a Unix text mode
> input system to "the web". The users were involved in the conversion
> from day one, in order to try to avoid the pitfalls you mentioned.
> Well, finally near completion, in parallel testing the final complaint
> is -- it takes twice as long to enter the data with the web version.
> Sure, it's pretty, but is it the right replacement for a heads down
> data entry system?
Interesting comment, pretty much what my boss said when we got going on
the Web interface for our system. The Web version was for the customers
who want a pretty little GUI w/bells & whistles, etc. The ones who
simply want to crank out a bunch of work will stick with the older
technology (inc. the 3270 interface).
Bill Lynch
Merli...@netscape.net
> Well, finally near completion, in parallel testing the final complaint
> is -- it takes twice as long to enter the data with the web version.
I wish I had had a choice of platforms! My first plan was to put it on our OS/390 CICS machine, using PCOM3270 emulators under Windoze as the UI, but I was told flat out by the VP, that I would do it on the web or he'd find someone who would.
Even with zero animation and the cleanest page we could design, it still crawls, largely because of the back end, but mostly because, like any interpreted language, it takes several times the machine cycles that a compiled language takes.
=Dwight=
Bob Wolfe
>Thane Hubbell wrote:
>>
>> Recently our payroll data entry was converted from a Unix text mode
>> input system to "the web". The users were involved in the conversion
>> from day one, in order to try to avoid the pitfalls you mentioned.
>> Well, finally near completion, in parallel testing the final complaint
>> is -- it takes twice as long to enter the data with the web version.
>> Sure, it's pretty, but is it the right replacement for a heads down
>> data entry system?
>
>Interesting comment, pretty much what my boss said when we got going on
>the Web interface for our system. The Web version was for the customers
>who want a pretty little GUI w/bells & whistles, etc. The ones who
>simply want to crank out a bunch of work will stick with the older
>technology (inc. the 3270 interface).
>
>Bill Lynch
Bill:
The "compromise" solution is actually pretty good. The "middle
ground" to get much higher performance than a web interface, run
across the Internet (or an internal intranet) and get the fancy GUI
screens is a thin client architecture.
The folks who want the fancy GUI get what they want. The folks who
want remote access get what they want and the folks who want high
speed transaction processing get what they want.
A sophisticated version control system solves the remote PC component
installation and update problem. A good data encryption routine
solves the data security problem. Even if the end users INSIST on
using the web browser as the user interface mechanism, a simple
browser plug in can allow the thin client user interface screens to
run directly in the child window of the browser without sacrificing
transaction speed. Applications can be run on 2 tier or three tier
systems. Servers can be Mainframe based, UNIX based, VAX based or
Windows NT based.
<biased opinion>
Sometimes I am absolutely baffled as to why some folks in this
industry are so absolutely insistent that all of their applications
must be "web enabled." There are lots of other alternatives and many
of them are far superior. I think that sometimes management falls
into the trap of, "If (name the large vendor of your choice) says we
should do it that way, then by golly we're GOING to do it that way!"
I believe that allowing the programming team to do a little "up front"
research into implementation alternatives before the project is
commenced can pay huge dividends.
</biased opinion>
I'll climb down from my soapbox now.
Bob Wolfe, flexus
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com
Howard Brazee
>
> Sometimes I am absolutely baffled as to why some folks in this
> industry are so absolutely insistent that all of their applications
> must be "web enabled." There are lots of other alternatives and many
> of them are far superior. I think that sometimes management falls
> into the trap of, "If (name the large vendor of your choice) says we
> should do it that way, then by golly we're GOING to do it that way!"
Why should this industry be different from others? Human nature tells
managers who don't know better to copy the industry leaders. This is
obvious in public industries such as movie making, but I doubt if you
can find an industry without blind copying of style over substance.
I know, we expect OUR type of people to be more intelligent... (but we
should know better by now)
brucepbarrett
"Bob Wolfe" <fle...@epix.net> wrote in message
news:396098b8...@news.epix.net...
> Sometimes I am absolutely baffled as to why some folks in this
> industry are so absolutely insistent that all of their applications
> must be "web enabled." There are lots of other alternatives and many
> of them are far superior. I think that sometimes management falls
> into the trap of, "If (name the large vendor of your choice) says we
> should do it that way, then by golly we're GOING to do it that way!"
I think there is a facination in this country with the latest craze,
gadget, buzz word etc and it overflows into the business world because
people, management especially, don't want to be preceived as unknowing.
Then the old adage "S..t flows down hill" goes to work. Someone higher up
in the heap says "I want ..." and then the ones further down are left with
making it happen.
Russell Styles
it doesn't matter
if it is good or not, just "Is it on the web?".
Once you have the ACTUAL customer (Not the nitwit VP) in
hand, you can discuss and demonstrate
the better ways of doing it. Maybe.
Loaded question - are VP's always nitwits, or does it just
seem that way?
<Merli...@netscape.net> wrote in message
news:1tGZ16mMk7i4-pn2-icSutlQ79o4e@localhost...
> It seems tha...@softwaresimple.com (Thane Hubbell) keyed the
following on Sun, 2 Jul 2000 12:29:56:
>
> > Well, finally near completion, in parallel testing the final
complaint
> > is -- it takes twice as long to enter the data with the web
version.
>
William Lynch
>
> You seem to have missed the point. For marketing purposes,
> it doesn't matter
> if it is good or not, just "Is it on the web?".
>
> Once you have the ACTUAL customer (Not the nitwit VP) in
> hand, you can discuss and demonstrate
> the better ways of doing it. Maybe.
>
> Loaded question - are VP's always nitwits, or does it just
> seem that way?
Seems the farther up the hierarchy they go, the less they understand
what's going on (even at the "executive overview" level). But, I guess
it all works out because their bosses understand even less. To them an
application is a bunch of charts showing milestones, deliverables,
loading & resources.
Bill Lynch
James J. Gavan
Paddy Coleman wrote:
>
> Ken,
>
> MERANT has a number of high profile successes in this area. For
> details please see:
>
> http://www.merant.com/customer_stories/
Paddy,
What you say is correct, but it misses the point of Pete Dashwood's
original message, (You don't see him commenting here because he's still
having problems with his ISP in NZ).
Pete is not looking for success stories publicized in the COBOL press
or web sites, nor even in the general computer press/web sites - rather
he is promoting the idea that these success stories should be LOUDLY
PROCLAIMED in the financial press, Times of London, NY and Washington
Post etc. so that the message gets through to the chief executives that
COBOL is well, alive and kicking and that there is no need to re-invent
the wheel using the current language du jour - rather it can be
successfully done from COBOL which has a nearly 40 year history of
stability and success.
The message has to come across in laymen's' terms so that the CEO gets
it - it can be done more effectively and CHEAPER in COBOL - that's what
is going to make his eyes glint - the name of the game is PROFIT,
PROFIT...., keep the shareholders happy - no different from what is
constantly happening with mergers here in the oil patch, and yes, from
the "merger" Intersolv + Micro Focus = Merant.
As a suggestion :-
1. Success stories are gleaned from developers by compiler vendors.
2. Vendors agree (Gasp !) to put aside their rivalries and form a COBOL
Advertising Consortium, which includes COBOL add-on tools such as SP2
and ScreenIO. Note : COBOL coding tools, not generalised productivity
tools.
3. Catchy slogan, such as "You can do it quicker and cheaper in COBOL",
????
4. An annual 'splash' in the financial press, highlighting success
stories. Each story finishes with a footnote "...the above was achieved
using IBM/Merant/Fujitsu/RM/Acu etc.... COBOL", and where appropriate,
"... using SP2 or ScreenIO". Each story quotes web address for
compiler/tool.
5. The page finishes with the web sites for each contributor to the
Consortium.
Payola for vendors - not necessarily immediate return on a particular
ad, but creates the awareness of a "joint blitz" showing that COBOL folk
are in the game with a serious intent.
Perhaps not quite what Pete had in mind - but it'll do as a starter.
Jimmy
Michael Mattias
news:3961391A...@worldnet.att.net...
> Russell Styles wrote:
> >
> >
> > Loaded question - are VP's always nitwits, or does it just
> > seem that way?
>
> Seems the farther up the hierarchy they go, the less they understand
The Plan
In the beginning was the plan, and then the specification;
And the plan was without form, and the specification was void.
And darkness was on the faces of the implementors thereof;
And they spake unto their leader, saying:
"It is a crock of shit, and smells as of a sewer."
And the leader took pity on them, and spoke to the project leader:
"It is a crock of excrement, and none may abide the odor thereof."
And the project leader spake unto his section head, saying:
"It is a container of excrement, and it is very strong, such that none may
abide it."
The section head then hurried to his department manager, and informed him
thus:
"It is a vessel of fertilizer, and none may abide its strength."
The department manager carried these words to his general manager,
And spoke unto him saying:
"It containeth that which aideth the growth of plants, and it is very
strong."
And so it was that the general manager rejoiced,
And delivered the good news unto the Vice President:
"It promoteth growth, and it is very powerful."
The Vice President rushed to the President's side, and joyously exclaimed:
"This powerful new software product will promote the growth of the company!"
And the President looked upon the product,
And saw that it was very good.
--- PIERRE PHANEUF (posted in Fido PowerBASIC conference, August, 1995)
Thane Hubbell
wrote:
>3. Catchy slogan, such as "You can do it quicker and cheaper in COBOL",
>????
COBOL: The language of Champions. (Put it on a NASCAR).
---
Michael Mattias
news:3961e144....@207.126.101.100...
> On Tue, 04 Jul 2000 05:04:25 GMT, "James J. Gavan" <jjg...@home.com>
> wrote:
>
> >3. Catchy slogan, such as "You can do it quicker and cheaper in COBOL",
> >????
>
> COBOL: The language of Champions. (Put it on a NASCAR).
>
COBOL : Not just another TLA
William Lynch
Another good one!
Bill Lynch
William Lynch
>
> On Tue, 04 Jul 2000 05:04:25 GMT, "James J. Gavan" <jjg...@home.com>
> wrote:
>
> >3. Catchy slogan, such as "You can do it quicker and cheaper in COBOL",
> >????
>
> COBOL: The language of Champions. (Put it on a NASCAR).
I like this one!
How about for cereal boxes: "COBOL - The Breakfast of Champions"
To catch the geek/hacker (in the good sense of the term) crowd: "COBOL &
Jolt Cola - The Breakfast of Champions", or:
"COBOL - You Can't Do Anything Useful with It".
Bill Lynch
Thane Hubbell
<michael...@gte.net> wrote:
>Thane Hubbell <tha...@softwaresimple.com> wrote in message
>news:3961e144....@207.126.101.100...
>> On Tue, 04 Jul 2000 05:04:25 GMT, "James J. Gavan" <jjg...@home.com>
>> wrote:
>>
>> >3. Catchy slogan, such as "You can do it quicker and cheaper in COBOL",
>> >????
>>
>> COBOL: The language of Champions. (Put it on a NASCAR).
>>
>
>COBOL : Not just another TLA
I'll probably regret posting this, but ... What's TLA stand for?
Arnold Trembley
Thane Hubbell wrote:
>
> On Tue, 04 Jul 2000 16:07:02 GMT, "Michael Mattias"
> <michael...@gte.net> wrote:
>
> >COBOL : Not just another TLA
>
> I'll probably regret posting this, but ... What's TLA stand for?
Three-Letter Acronym.
Regards,
G Moore
>Sometimes I am absolutely baffled as to why some folks in this
>industry are so absolutely insistent that all of their applications
>must be "web enabled."
if the application fits the view of the web (anonymous or insecure
access to linked pictures and text) it would be a good candidate. most
corporate apps don't. every piece of data could potentially be used
against a corporation.
reply to email gvwm...@spam.ix.netcom.com remove the spam
G Moore
> Human nature tells
>managers who don't know better to copy the industry leaders. This is
>obvious in public industries such as movie making, but I doubt if you
>can find an industry without blind copying of style over substance.
>I know, we expect OUR type of people to be more intelligent... (but we
>should know better by now)
according to darwin, if your market dies out, you aren't more
intelligent.
Thane Hubbell
---
Thane Hubbell
<wbl...@worldnet.att.net> wrote:
>To catch the geek/hacker (in the good sense of the term) crowd: "COBOL &
>Jolt Cola - The Breakfast of Champions", or:
>"COBOL - You Can't Do Anything Useful with It".
>
That last has to be a typo right? "without" instead of "with".
Please?
William Lynch
>
> On Tue, 04 Jul 2000 18:09:16 GMT, William Lynch
> <wbl...@worldnet.att.net> wrote:
>
> >To catch the geek/hacker (in the good sense of the term) crowd: "COBOL &
> >Jolt Cola - The Breakfast of Champions", or:
> >"COBOL - You Can't Do Anything Useful with It".
> >
>
> That last has to be a typo right? "without" instead of "with".
> Please?
No typo, a poke at the academics & hackers who want nothing to do with
anything useful. (Intended as a small joke, too small, apparently)
Bill Lynch :-)
FRLSFLY
>intelligent.
Incorrect. According to Darwin, if you do not adapt to your market dying out,
you will not survive to reproduce.
If your market is stupid, intelligence can be a hinderance in predicting it's
behavior.
The adaptation being suggested here is to revive the COBOL market, our
'foodsource' by educating the people who make software purchasing decisions
that COBOL is a better solution.
The problem with this is that "better" may be too subtle a concept for most of
them. Applications can be built with the tools currently in vogue, and they
can be made to function usefully, if not optimally.
My hope is that COBOL will survive by increments- that existing applications
will continue to thrive, and that the 'C' derivatives will gradually wither
away under the weight of their higher costs.
Nathan Meyer
Berkeley, CA
"Big Endian" is what I like.
Thane Hubbell
<wbl...@worldnet.att.net> wrote:
>
>No typo, a poke at the academics & hackers who want nothing to do with
>anything useful. (Intended as a small joke, too small, apparently)
That's two on this subject I missed. I must be taking myself too
seriously. I'll try to lighten up.
Howard Brazee
G Moore wrote:
>
> Howard Brazee <howard...@cusys.edu> wrote:
>
> > Human nature tells
> >managers who don't know better to copy the industry leaders. This is
> >obvious in public industries such as movie making, but I doubt if you
> >can find an industry without blind copying of style over substance.
>
> >I know, we expect OUR type of people to be more intelligent... (but we
> >should know better by now)
>
> according to darwin, if your market dies out, you aren't more
> intelligent.
So let me move to biology. Occasionally a species becomes dominant for
some reason or another (maybe Irish potatoes). The ecosystem becomes
dependent on it working as advertised and when conditions change (a Word
virus), everybody is vulnerable. Copying the Industry leaders may not
be such a survival characteristic after all.
Joseph J Katnic
G Moore wrote:
>
> according to darwin, if your market dies out, you aren't more
> intelligent.
>
I think not.
Intelligence implies the ability to CHANGE the environment when natural
environmental changes would otherwise have made you extinct!
Certainly, our race could not have survived on the savanna competing
against better adapted hunters. We human did what we always do when
confronted with such a situation. We changed the rules!
--
Regards,
Joe Katnic jos...@iinet.net.au
Alistair Maclean
<jos...@iinet.net.au> writes
>
>
>G Moore wrote:
>>
>> according to darwin, if your market dies out, you aren't more
>> intelligent.
>>
>I think not.
>Intelligence implies the ability to CHANGE the environment when natural
>environmental changes would otherwise have made you extinct!
smallest organism (see acid rain from phytoplanktonic blooms) devoid of
intelligence. Further, I would deem it possible for a supposedly
intelligent organism to change it's environment adversely when faced
with extinction (see humans).
>Certainly, our race could not have survived on the savanna competing
>against better adapted hunters.
There is a theory (not the one about dinosaurs being thin at both ends
and thick in the middle) that humans evolved on the coastal margins.
This is supported by the apparent scarcity of fatty acids on the
savannah required to build large brains (and their abundance in
shellfish) and the tendency on the savannah to evolve just enough
intelligence to spot predators and no more.
>We human did what we always do when
>confronted with such a situation. We changed the rules!
Most project managers I have met adopt the ostrich stance when faced
with danger. Are they of superior intelligence?
>
>--
>Regards,
>Joe Katnic jos...@iinet.net.au
--
Alistair Maclean
As a solid rock is not shaken by the wind,
even so the wise are not ruffled by praise or blame. - Dhammapada 6
People are like teabags - you have to put them in to hot water before
you find out how strong they are.
James J. Gavan
FRLSFLY wrote:
>
> My hope is that COBOL will survive by increments- that existing applications
> will continue to thrive, and that the 'C' derivatives will gradually wither
> away under the weight of their higher costs.
Years ago visited an elderly lady, (now dead) in High River, south of
us. Went to the 'potty' room and was surprised to see a notice, "Don't
just sit there, do something !"
Well it's kinda the same with COBOL - it is NOT going to happen unless
developers get involved and start submitting suggestions to COBOL
Standards. If there's anything that turns your crank, contact Bill Klein
who will advise you on how to submit etc....
Jimmy, Calgary AB
Merli...@netscape.net
> You seem to have missed the point.
Nope, it wasn't a marketing issue - VP is my boss and also boss of non-exempt salaried supervisor type who is (1) the customer and (2) totally computer illiterate and intends to stay that way.
> Loaded question - are VP's always nitwits, or does it just
> seem that way?
To me, "no" to both. This particular VP went from mail room flunky to #2 in the company in 20 years in the same building and both his business acumen and care for his employees is seldom matched in our industry. This decision was probably an error, but there are political motivations I won't go into and the total labour involved in this system makes doubling the entry time a great heresy to me, Virgo Scottish Jew with 40 years in capacity planning, tuning, and assembler language, it is irrelevant to the overall scheme of the company's making tons of money.
=Dwight=
Michael Mattias
>
> That's two on this subject I missed. I must be taking myself too
> seriously. I'll try to lighten up.
Have you taken stock of your accumulated natal anniversaries lately?
Um, er, oh hell, what was it..? Oh Yeah! "Stuff Happens" when you get
older!
MCM
Thane Hubbell
<michael...@gte.net> wrote:
>Thane Hubbell <tha...@softwaresimple.com> wrote in message
>news:39632526....@207.126.101.100...
>>
>> That's two on this subject I missed. I must be taking myself too
>> seriously. I'll try to lighten up.
>
>
>Have you taken stock of your accumulated natal anniversaries lately?
>
I'll do that in August if I remember....
>Um, er, oh hell, what was it..? Oh Yeah! "Stuff Happens" when you get
>older!
Seems though it's less and less of it, and it's more and more
important.
Lenny
started writing Visual Basic about three years ago. No way do I want to go
back to Cobol. Windows apps can be developed so quickly with VB (or VC++),
why bother with Cobol, the dinosaur of a language?
I'm sure this will upset some of my fellow grey-beard programmers, but as
for me - there's no looking back!
Ken Foskey <war...@zip.com.au> wrote in message
news:3957598C...@zip.com.au...
>
> Following on from an email from Pete Dashwood. Do we have a
> collection of real success stories of migrating the current system to
> a web enabled application using Cobol and tools.
>
> I am sure we can get one from Vendors but this is really about the
> guys at the coal face having success so that it is not seen as a
> marketing blurb (well it is but it is for the programmers).
>
> quote from Pete>>>>>>>>>>>>>>
>
> What we need are some Application successes so that when the spotty
> nerd
> comes in and says: "we are going to replace COBOL with python", the
> Senior
> Exec can say: "Interesting you mention COBOL. I know nothing about it
> of
> course, but the TIMES this morning said that our competitors are using
> it
> with great success. Apparently they saved a fortune revamping their
> Life
> and Pensions Group and are poised to grab a market slice, after we
> thought
> they were no longer a threat. I'll be interested to see the backing
> for
> your recommendations...and the costs..."
>
> Nerd goes away and grabs the TIMES. Now he consults with his mentor
> back at
> AA. They agree it would be wise to propose something that is likely to
> be
> readily accepted, so they propose a review of all existing COBOL
> applications with a view to funding enhancement and new development
> within
> the same paradigm. They still get their team in and everyone is happy.
>
> If you think the above scenario is far-fetched, I can assure you it is
> (very loosely) based on actual events which I have personally been
> privy
> to.
>
> Remember also that newspapers prefer items which go "against the
> flow".
>
> <<<<<<<<<<<<<<<<<<<<<
>
> I personally think this is a great idea. We really need to advertise
> the power of cobol. I would go further than this.
>
> <Anology follows>
>
> There was a major change in thinking for the apple industry here in
> Australia, they used to advertise that apple A was better than apple
> B. They changed their tune, they realized their competition was
> chocolate bars and now they are going from strength to strength.
>
> What is the point of this ditty, well Cobol is the apples. We have
> vendors thinking they are competing for the same market share, in
> reality they are shrinking the market share by missing the major
> point, portability.
>
> </anology>
>
> We desperately need the vendors to closely work together to come up
> with a better minimum standard including some of the basic tools that
> programmers can easily get elsewhere. This set needs to work on the
> basic four Web, IBM, Unix and PC.
>
> Cobol vendors are not competing for Cobol market share they are
> competing with Delphi, Visual Basic (yuk), Small talk, etc. When
> cobol was king it had the VSAM file access built into the language
> when other languages were just thinking about it, this is what set it
> aside from the other languages. To be blunt what does it offer me
> now. Don't give me readable code, give me less code to write so I am
> more productive.
>
> We need the vendors and the standards committee to pull their fingers
> out and really work on a minimum standard operational set for today's
> computers including screen handling, tools such as collections,
> persistent objects, etc. If the vendors fail to do this Cobol will
> frankly loose my programming vote.
>
> Now should I tell you what I really feel....
>
> Thanks
> Ken Foskey
> http://www.zipworld.com.au/~waratah/
>
> For fast secure document delivery on the Net
> http://www.themailxchange.com.au/
Thane Hubbell
wrote:
>I have been writing Cobol since 1978, so I'm no rookie on this subject. I
>started writing Visual Basic about three years ago. No way do I want to go
>back to Cobol. Windows apps can be developed so quickly with VB (or VC++),
>why bother with Cobol, the dinosaur of a language?
>I'm sure this will upset some of my fellow grey-beard programmers, but as
>for me - there's no looking back!
Three years ago I might have agreed with you. But COBOL's come a long
way in three years and so have the third party tools. I tried my hand
at Visual Basic. If you want to create a user interface program with
no substance behind it, VB is certainly one way to go. Like other
event driven tools, however, I find it to be a Write once, write over
proposition. With COBOL I write once and revise. Over the long haul
COBOL is much more maintainable and reliable. Not to mention that I
can port my current COBOL GUI Applications to Unix or Linux from
Windows with few, if any, code changes. Try that with Visual basic.
Paddy Coleman
I have to agree with you (and yes I know I work for a COBOL vendor
and therefore you would expect me to say that <g>).
Visual BASIC is a great tool and you can do some really amazing things
with it. However, it has always concerned me that as a "language" it is
proprietary and very much tied to the Windows environment.
People and Companies who are developing systems which are likely to
have an extended lifespan should look at computer languages which have
a high degree of portability (or write once, run almost anywhere). At the
end of the day it is the data and business rules which are of value.
COBOL is just one language which has the ability to run on multiple
platforms and provides scalability. Other obvious candidates are C and
Java (I am sure the rest of your can provide others <g>).
There you go, my two pennies worth...
Paddy Coleman
Manager, E-Business Support, EMEA
MERANT International.
Thane Hubbell <tha...@softwaresimple.com> wrote in message
news:396bd3aa...@207.126.101.100...
Howard Brazee
Lenny wrote:
>
> I have been writing Cobol since 1978, so I'm no rookie on this subject. I
> started writing Visual Basic about three years ago. No way do I want to go
> back to Cobol. Windows apps can be developed so quickly with VB (or VC++),
> why bother with Cobol, the dinosaur of a language?
> I'm sure this will upset some of my fellow grey-beard programmers, but as
> for me - there's no looking back!
What has your experience been in maintenance?
WDS
This is fine, assuming that:
° Everything you write is new
° Nothing you write needs the file processing ability of COBOL
° Everything you write is on a PC/Windoze platform
...I could go on.
VB is great for many things. I use it.
COBOL also is great for many things. I use it, too.
I just don't think that we can blanketly replace all of anything with
any one other thing. Just my $0.02.
--
Reply Addr:-->WDavid dot Simon at ATL dot frb dot org<--
------------...@Spammer.Trasher----------------
Judson McClendon
> I have been writing Cobol since 1978, so I'm no rookie on this subject. I
> started writing Visual Basic about three years ago. No way do I want to go
> back to Cobol. Windows apps can be developed so quickly with VB (or VC++),
> why bother with Cobol, the dinosaur of a language?
> I'm sure this will upset some of my fellow grey-beard programmers, but as
> for me - there's no looking back!
Yes, and you will get to rewrite all of those VB apps every three years
or so, every time BG decides to jerk your chain. Like you, I started
programming COBOL in 1968, and I have COBOL programs still running
that are well over 20 years old. I have PC COBOL programs that are
over 20 years old. What are the chances that your clients/employer
will be running any of that VB code in 20 years? :-)
Hint: How many 5 year old VB programs are still running unmodified?
--
Judson McClendon ju...@bellsouth.net
Sun Valley Systems http://www.sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
Ray Smith
> or so, every time BG decides to jerk your chain. Like you, I started
> programming COBOL in 1968, and I have COBOL programs still running
> that are well over 20 years old. I have PC COBOL programs that are
> over 20 years old. What are the chances that your clients/employer
> will be running any of that VB code in 20 years? :-)
>
> Hint: How many 5 year old VB programs are still running unmodified?
I write Cobol programs on Unix and previously PC's and but have done a
little VB and some C++.
My question....
Why is it difficult to maintain VB code?
How many VB programs have "needed" changes or to be re-written because of
changes in OS or development tools?
There where quiet a few changes between VB 3 and VB 4 but since then I don't
think there has been any reason to re-write anything.
I agree with the point about portability, I can't see any VB code being run
on anything but a Windows machine but I'm yet to understand the comments
about maintainability.
Actually that might not even be true, I think I recall reading about a GPL'd
Visual Basic interpreter (with no GUI) under Unix???
I guess I should ask some of these questions on VB list to hear what they
have to say ...
Regards
Ray Smith
Judson McClendon
>
> My question....
>
> Why is it difficult to maintain VB code?
My version of VB 1.0 is copyright 1991. Do you realize how many
major (and I mean *major*) changes to VB and Windows there have been
in that 9 years? Is there any reason to think B.G. has stopped making
such changes? In 1990 B.G. was telling us OS/2 was the platform for
the 90's. He failed to see the Internet's significance for a while,
then turned everything upside down to catch up. If things aren't
changing so much, why is it there is a whole host of problems with
older programs with every new release of Windows, even with Microsoft
products? When you choose a proprietary language, you dance to the
proprietor's tune. Simple as that.
I like VB for some things, and use it myself, VBA too. But I do not
want to use it for my major development platform. For one thing,
it is entirely too flaky. Things work sometimes, sometimes they don't.
I wrote a small VBA program for my church. I wanted to use a simple
combo box on a form, but it won't work. You can click the down arrow
and it shows you the items, but you can't select them. When you click
on them, nothing happens, as if you didn't click. I can create an
identical combo box on another form in the same app, and it works.
I can remove this combo box and recreate it on this form, and it won't
work. If I could remember them all, I could name probably 20 or 30
such things that cropped up in writing that one small (~600 lines)
program. The code is correct, but it simply won't work. I shudder to
think what it would be like writing and supporting major applications
in such a flaky environment. Who needs that? (Office 2000 with SR1.)
Ray Smith
> major (and I mean *major*) changes to VB and Windows there have been
> in that 9 years?
I wouldn't do any "major" development with any version "1" product from any
company.
I don't think you can compare VB version "1" with the current VB. I beleive
VB 4.0 is the
first version that delievered enough functionality to produce non trival
software.
Since version 4.0 there have been minimal changes required to use source
from
previous versions. (I agree though small changes are required!)
>Is there any reason to think B.G. has stopped making
> such changes? In 1990 B.G. was telling us OS/2 was the platform for
> the 90's.
One thing to consider here is that VB has grown to be one of the most
popular languages in the world today. If Microsoft do make radical changes
to VB 7.0, 8.0 or onwards there is going to be far more negative feedback
than what has happened in the past.
(No one knows the future but MS have improved compatiabilty with each
release and there is no reason to beleive it will get worse.)
>He failed to see the Internet's significance for a while,
> then turned everything upside down to catch up.
I can't think of one Internet feature that has been added to VB that has
broken previous code.
>If things aren't
> changing so much, why is it there is a whole host of problems with
> older programs with every new release of Windows, even with Microsoft
> products? When you choose a proprietary language, you dance to the
> proprietor's tune. Simple as that.
Yes I agree totally. If you choose a proprietary language you have to dance
to their tune.
Sometimes when you dance to these tunes you get great results. Sometimes
you fall over and break a leg. In this case though the proprietary language
is one of the most popular languages used today
with an amazing array of tools, addons, training, and 3rd party resources.
>
> I like VB for some things, and use it myself, VBA too. But I do not
> want to use it for my major development platform. For one thing,
> it is entirely too flaky. Things work sometimes, sometimes they don't.
> I wrote a small VBA program for my church. I wanted to use a simple
> combo box on a form, but it won't work. You can click the down arrow
> and it shows you the items, but you can't select them. When you click
> on them, nothing happens, as if you didn't click. I can create an
> identical combo box on another form in the same app, and it works.
> I can remove this combo box and recreate it on this form, and it won't
> work. If I could remember them all, I could name probably 20 or 30
> such things that cropped up in writing that one small (~600 lines)
> program. The code is correct, but it simply won't work. I shudder to
> think what it would be like writing and supporting major applications
> in such a flaky environment. Who needs that? (Office 2000 with SR1.)
Yes most of these things can be put down to outdated software or
incompatiable
versions etc etc. I think everyone who has ever done "any" Windows
development
would have come across these things and they are total pains in the butt!!!!
There are many one off's you need to learn, and its a costly road to travel.
Its something you should be aware of before installing any software on any
Windows PC. This for me is the biggest problem with VB.
Visual Basic (and C++) will always have a much richer feature set, with more
powerful GUI tools.
If your developing a large internal system for a multi national bank (for
example)
I think you'd be an idiot to do it in VB.
If your writing small to medium size software that you have to sell to
middle management
and small businesses then VB is an option that when used correctly can give
you that
visual edge over competitors.
Lets not "beat around the bush" its easy to write software in VB and there
is a small price in keeping it current, but if that gives you extra sales
the extra effort might be offset by extra sales.
Just out of interest we use Cobol in the unix environment as a server and
use VB as a client
on Windows boxes. We have gone through the pain of outdated dll's, and
incompatibilities, etc etc but it's still a good solution to get good UI
and stable processing.
Also out of interest in my spare time I tinker with free software tools like
GNU C++ (the Mingw port for windows - www.mingw.org ) and wxWindows - a
cross platform GUI application framework for C++ (www.wxwindows.org). These
types of tools "might" solve lots of problems with both Cobol and VB, (but
yet again might create many more!).
Regards,
Ray Smith.
Ken Foskey
>
> Just out of interest we use Cobol in the unix environment as a server and
> use VB as a client
> on Windows boxes. We have gone through the pain of outdated dll's, and
> incompatibilities, etc etc but it's still a good solution to get good UI
> and stable processing.
>
> Also out of interest in my spare time I tinker with free software tools like
> GNU C++ (the Mingw port for windows - www.mingw.org ) and wxWindows - a
> cross platform GUI application framework for C++ (www.wxwindows.org). These
> types of tools "might" solve lots of problems with both Cobol and VB, (but
> yet again might create many more!).
Apologies to the cobol group. You really should try Delphi C++
builder. Your front end is trivial in this but the power of a real
language is still there.
Thane Hubbell
<Ray....@fujitsu.com.au> wrote:
>I write Cobol programs on Unix and previously PC's and but have done a
>little VB and some C++.
>
>My question....
>
>Why is it difficult to maintain VB code?
>
VB was quickly abandoned where I work, and VB Maintenance is shunned
on the existing products by the VB developers. I don't know why they
don't like it, but they don't.
Clark F. Morris, Jr.
organization's control or if it is to be accessed by both casual and
intensive users, web enablement makes a lot of sense. If an application
is on the web it can be accessed by someone with a Mac, a PC or a Linux
box. If Netscape 4.73 can be compiled for Linux on any platform, it can
run on a S390 under Linux 390 (no, I don't know how you would attach or
use a standard monitor). The just in time loading of the Java or HTML
code eliminates the need to update the client. Having said that, there
is probably a severe limitation on the amount of sophistication that can
be put on the code that runs in the browser and the response time may be
less than desired for the high volume data entry. Probably a general
rule would be that the uglier and klutzier (sp?) the interface looks,
the faster it is for data entry.
Given the advantages of web-based code in terms of platform
independence, can data entry portions be optimized to give decent
performance after initial load? The speed of current PC's and Macs give
me some hope that this should be possible.
Clark Morris, CFM Technical Programming Services Inc., cfm...@istar.ca
Bob Wolfe wrote:
>
> William Lynch <wbl...@worldnet.att.net> wrote:
>
> >Thane Hubbell wrote:
> >>
> >> Recently our payroll data entry was converted from a Unix text mode
> >> input system to "the web". The users were involved in the conversion
> >> from day one, in order to try to avoid the pitfalls you mentioned.
> >> Well, finally near completion, in parallel testing the final complaint
> >> is -- it takes twice as long to enter the data with the web version.
> >> Sure, it's pretty, but is it the right replacement for a heads down
> >> data entry system?
> >
> >Interesting comment, pretty much what my boss said when we got going on
> >the Web interface for our system. The Web version was for the customers
> >who want a pretty little GUI w/bells & whistles, etc. The ones who
> >simply want to crank out a bunch of work will stick with the older
> >technology (inc. the 3270 interface).
> >
> >Bill Lynch
>
> Bill:
>
> The "compromise" solution is actually pretty good. The "middle
> ground" to get much higher performance than a web interface, run
> across the Internet (or an internal intranet) and get the fancy GUI
> screens is a thin client architecture.
>
> The folks who want the fancy GUI get what they want. The folks who
> want remote access get what they want and the folks who want high
> speed transaction processing get what they want.
>
> A sophisticated version control system solves the remote PC component
> installation and update problem. A good data encryption routine
> solves the data security problem. Even if the end users INSIST on
> using the web browser as the user interface mechanism, a simple
> browser plug in can allow the thin client user interface screens to
> run directly in the child window of the browser without sacrificing
> transaction speed. Applications can be run on 2 tier or three tier
> systems. Servers can be Mainframe based, UNIX based, VAX based or
> Windows NT based.
>
> <biased opinion>
>
> Sometimes I am absolutely baffled as to why some folks in this
> industry are so absolutely insistent that all of their applications
> must be "web enabled." There are lots of other alternatives and many
> of them are far superior. I think that sometimes management falls
> into the trap of, "If (name the large vendor of your choice) says we
> should do it that way, then by golly we're GOING to do it that way!"
>
> I believe that allowing the programming team to do a little "up front"
> research into implementation alternatives before the project is
> commenced can pay huge dividends.
>
> </biased opinion>
>
> I'll climb down from my soapbox now.
>
> Bob Wolfe, flexus
> When replying by e-mail, make sure that you correct the e-mail address.
> Check out The Flexus COBOL Page at http://www.flexus.com
Warren Simmons
Warren Simmons
"Paddy Coleman" <paddy....@merant.com> wrote in message
news:8khbg5$cad$1...@hyperion.mfltd.co.uk...
> Thane,
>
> I have to agree with you (and yes I know I work for a COBOL vendor
> and therefore you would expect me to say that <g>).
>
> Visual BASIC is a great tool and you can do some really amazing things
> with it. However, it has always concerned me that as a "language" it is
> proprietary and very much tied to the Windows environment.
>
> People and Companies who are developing systems which are likely to
> have an extended lifespan should look at computer languages which have
> a high degree of portability (or write once, run almost anywhere). At
the
> end of the day it is the data and business rules which are of value.
>
> COBOL is just one language which has the ability to run on multiple
> platforms and provides scalability. Other obvious candidates are C and
> Java (I am sure the rest of your can provide others <g>).
>
> There you go, my two pennies worth...
>
> Paddy Coleman
> Manager, E-Business Support, EMEA
> MERANT International.
>
> Thane Hubbell <tha...@softwaresimple.com> wrote in message
> news:396bd3aa...@207.126.101.100...
> > On Tue, 11 Jul 2000 20:25:43 -0400, "Lenny" <bis...@springmail.com>
> > wrote:
> >
> > >I have been writing Cobol since 1978, so I'm no rookie on this
subject.
> I
> > >started writing Visual Basic about three years ago. No way do I want
to
> go
> > >back to Cobol. Windows apps can be developed so quickly with VB (or
> VC++),
> > >why bother with Cobol, the dinosaur of a language?
> > >I'm sure this will upset some of my fellow grey-beard programmers, but
as
> > >for me - there's no looking back!
> >
> >
> > Three years ago I might have agreed with you. But COBOL's come a long
> > way in three years and so have the third party tools. I tried my hand
> > at Visual Basic. If you want to create a user interface program with
> > no substance behind it, VB is certainly one way to go. Like other
> > event driven tools, however, I find it to be a Write once, write over
> > proposition. With COBOL I write once and revise. Over the long haul
> > COBOL is much more maintainable and reliable. Not to mention that I
> > can port my current COBOL GUI Applications to Unix or Linux from
> > Windows with few, if any, code changes. Try that with Visual basic.
> >
Warren Simmons
choice of name for the thread was bad IMHO.
Warren Simmons
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:397056be....@207.126.101.100...
> On Thu, 13 Jul 2000 16:20:39 +1000, "Ray Smith"
> <Ray....@fujitsu.com.au> wrote:
>
> >I write Cobol programs on Unix and previously PC's and but have done a
> >little VB and some C++.
> >
> >My question....
> >
> >Why is it difficult to maintain VB code?
> >
>
> VB was quickly abandoned where I work, and VB Maintenance is shunned
> on the existing products by the VB developers. I don't know why they
> don't like it, but they don't.
>
Judson McClendon
> Judson McClendon wrote:
> >
> >Is there any reason to think B.G. has stopped making such changes? In
> >1990 B.G. was telling us OS/2 was the platform for the 90's.
>
> One thing to consider here is that VB has grown to be one of the most
> popular languages in the world today. If Microsoft do make radical changes
> to VB 7.0, 8.0 or onwards there is going to be far more negative feedback
> than what has happened in the past.
That same situation didn't stop Microsoft from coming out with Windows
95/98 and NT/2000, all of which stomped on 'compatibility' pretty hard.
Just look at all the user interface changes between 95 and 98. :-)
> >He failed to see the Internet's significance for a while, then turned
> >everything upside down to catch up.
>
> I can't think of one Internet feature that has been added to VB that has
> broken previous code.
My point is that Microsoft can change direction quickly and without warning,
and they do it with little regard for the damage to their customers. Have
you ever noticed how many times they change simple things, like how you get
to a function in Office? From one release to another, there will *always*
be a number of common functions moved to another place in the dropdown
menus, for little or no reason. Have you considered how much human effort
is wasted when 10,000,000 users of Office all have to learn another way to
get to a commonly used function? We're talking many millions of dollars in
costs for training and loss of productivity over a pointless change, yet
Microsoft does it all the time. They also remove useful features, or
change the way they work, just for the heck of it.
James J. Gavan
Warren Simmons wrote:
>
> Add to these comments that C, C++ will get a new version called C#.
>
> Warren Simmons
> "Paddy Coleman" <paddy....@merant.com> wrote in message
> news:8khbg5$cad$1...@hyperion.mfltd.co.uk...
> > Thane,
> >
> > I have to agree with you (and yes I know I work for a COBOL vendor
> > and therefore you would expect me to say that <g>).
> >
> > Visual BASIC is a great tool and you can do some really amazing things
> > with it. However, it has always concerned me that as a "language" it is
> > proprietary and very much tied to the Windows environment.
> >
> > People and Companies who are developing systems which are likely to
> > have an extended lifespan should look at computer languages which have
> > a high degree of portability (or write once, run almost anywhere). At
> the
> > end of the day it is the data and business rules which are of value.
> >
> > COBOL is just one language which has the ability to run on multiple
> > platforms and provides scalability. Other obvious candidates are C and
> > Java (I am sure the rest of your can provide others <g>).
> >
> > There you go, my two pennies worth...
So let's take Paddy's second penny - JAVA. (In ye olden times a penny
would get you a bar of chocolate on the Underground - that is of course
when my sweetheart Shirley Temple and I were about six years of age <G>)
To find out what all the hype is about JAVA I'm doing a bit of boning up
on it. Just received two volumes, "Core Java" - and NOTE - published by
Sun Microsystems Press.
The authors have updated earlier versions, so now current includes
SWING. In the introductory chapters they cover some of the 'Common
Misconceptions about Java' :-
- Java is an easy programming language to learn
- Java is an easy environment in which to program
- Java will become a universal programming language for all platforms
- Java is is just another programming language
- Java is interpreted, so it is too slow for serious applications on a
specific platform
- All Java programs run inside a Web page
- Java appelts are a major security risk
- JavaScript is a simpler version of Java
- Java eliminates the need for CGI scripting
- Java will revolutionize client-server computing
- With Java, I can replace my computer with a $500 'Internet appliance"
Now surprisingly, considering the books are published by Sun, the
authors offer a blunt series of negatives to some of the items in the
list. That kinda leaves me feeling - what's the big deal ? (But of
course any option is better than slavishly following Billy G. up the
yellow brick road to C#).
Jimmy
Oscar T. Grouch
"James J. Gavan" <jjg...@home.com> wrote in message
news:3974981E...@home.com...
The 'big deal' is the availability of things (classes, documentation,
training materials, people, etc.) that make easier to do what you need to
do. Sometimes COBOL is the 'big deal' because it solves a certain class of
problems better than others. Sometimes it isn't.
For example, I'm playing with XML and all it's related technologies. If I do
the work in Java (or some other languages) I have immediate access to all
sorts of code, examples and experts in the field of XML parsing and
generation. If I do the work in ANSI 85 COBOL (which is what I'm trying to
do) then I have to write my own parsers and generators, or hunt up some
proprietary third-party product and shoehorn it into the architecture. It
turns the work of a few hours into a multiple man-month project because I
cannot leverage the work others have already done. Besides, COBOL is not a
particularly good language for writing a parser although it can hold it's
own as a generator.
- Karl
Thane Hubbell
wrote:
>For example, I'm playing with XML and all it's related technologies. If I do
>the work in Java (or some other languages) I have immediate access to all
>sorts of code, examples and experts in the field of XML parsing and
>generation. If I do the work in ANSI 85 COBOL (which is what I'm trying to
>do) then I have to write my own parsers and generators, or hunt up some
>proprietary third-party product and shoehorn it into the architecture. It
>turns the work of a few hours into a multiple man-month project because I
>cannot leverage the work others have already done. Besides, COBOL is not a
>particularly good language for writing a parser although it can hold it's
>own as a generator.
Just FYI - Microsoft has an ActiveX control for parsing XML -- if you
can use ActiveX from your COBOL variant, this could help you a bit.
James J. Gavan
"Oscar T. Grouch" wrote:
>
> > Now surprisingly, considering the books are published by Sun, the
> > authors offer a blunt series of negatives to some of the items in the
> > list. That kinda leaves me feeling - what's the big deal ? (But of
> > course any option is better than slavishly following Billy G. up the
> > yellow brick road to C#).
> >
> > Jimmy
>
> The 'big deal' is the availability of things (classes, documentation,
> training materials, people, etc.) that make easier to do what you need to
> do. Sometimes COBOL is the 'big deal' because it solves a certain class of
> problems better than others. Sometimes it isn't.
>
> For example, I'm playing with XML and all it's related technologies. If I do
> the work in Java (or some other languages) I have immediate access to all
> sorts of code, examples and experts in the field of XML parsing and
> generation. If I do the work in ANSI 85 COBOL (which is what I'm trying to
> do) then I have to write my own parsers and generators, or hunt up some
> proprietary third-party product and shoehorn it into the architecture. It
> turns the work of a few hours into a multiple man-month project because I
> cannot leverage the work others have already done. Besides, COBOL is not a
> particularly good language for writing a parser although it can hold it's
> own as a generator.
>
> - Karl
Karl,
I couldn't agree more - that is why WE MUST HAVE COMMON/GENERIC/PORTABLE
CLASSES in OO COBOL - and as a 'quickie' such classes may initially make
invokes to Java classes where appropriate until such time as we produce
a better, (certainly EASIER to read), library in COBOL.
Remember, even if we invoke Java, we still have to ask Sun, HP or Big
Billy or Big Billy II (C#) ?
Jimmy
Ken Foskey
>
> The exchange called "Success stories for Cobol" was interesting, but the
> choice of name for the thread was bad IMHO.
No it just did not achieve the original aims.
I have seen ZERO concrete proof of killer apps that superseded failed
developments in other languages. Most have been vague and appear to
be 'I knew cobol and it worked for me' sort of stories.
OVer to you.... still waiting
Clark F. Morris, Jr.
for the one or two parsing programs that I have written. What should be
in a language for it to be good for parsing things?
Clark Morris, CFM Technical Programming Services Inc., cfm...@istar.ca
Thane Hubbell
was ported to VB, failed, ported to C++, failed, and then ABANDONED -
the existing COBOL still runs the company. Does that count? I didn't
think so.
On Wed, 19 Jul 2000 21:43:25 +1000, Ken Foskey <war...@zip.com.au>
wrote:
---
James J. Gavan
Thane Hubbell wrote:
>
> I have direct first hand knowledge of a project where a COBOL system
> was ported to VB, failed, ported to C++, failed, and then ABANDONED -
> the existing COBOL still runs the company. Does that count? I didn't
> think so.
Unfortunately not. Now had you been able to write "Done in VB, failed,
then done in C++, failed, then done in COBOL - SUCCESS!" - dumb maybe,
but it doesn't count that it was already in COBOL - just shows the other
two were lousy approaches. And then some jerk is going to say, "But you
didn't try Java or Pascal or something etc...."
Jimmy
Oscar T. Grouch
data. Sometimes it can be accomplished with a simple UNSTRING statement. In
the case of XML it's a little more involved.
Consider this piece of XML:
<person gender="male">
<firstname>Bob</firstname>
<lastname>Smith</lastname>
</person>
and the corresponding COBOL copybook
01 PERSON.
05 FIRSTNAME PIC X(30).
05 LASTNAME PIC X(30).
For the sake of argument let's assume that the parser knows what type of
data to expect when it encounters each element (<person>, <firstname:>, or
<lastname>). In practice this involves interpreting either a DTD, an
ancillary document that describes the data, or a schema, which is more XML.
The parser needs to recognize each new element it encounters (<person>), any
attributes associated with that element ('gender="male"), determine what
'end-tag' it should expect to find marking the end of the new element, and
then do what is required to pull the meaningful information out.
In this example it's a pretty easy task in COBOL and could be accomplished
with a few UNSTRING statements. Writing a generic routine that can deal with
an arbitrary structure depth and a little more meaningful syntax is a bigger
challenge. Now you need some sort of stack, and unless you're going to
provide dynamic memory allocation and all the baggage that goes with it,
youre forced to set arbitrary limits on size and complexity in order to
declare the variables that will be used.
I find the job is easier if I have access to regular expressions, recursion,
and structured exception handlers. For reliability and ease-of-use it's nice
if the language enforces strong cohesion and loose coupling of routines.
COBOL does neither.
- Karl
"Clark F. Morris, Jr." <cfm...@istar.ca> wrote in message
news:3975D37C...@istar.ca...
Cheesle
news:3975D37C...@istar.ca...
> With the addition of reference modification, I found COBOL wasn't bad
> for the one or two parsing programs that I have written. What should be
> in a language for it to be good for parsing things?
In my humble opinion:
- Recursion (which some Cobol vendors support)
- Local storage (local to sections)
- Dynamic strings / Memory pointers (which some Cobol vendors support)
- Extensive string manipulation routines (could be made by one self)
I generally agree with you that Cobol may very well do a good job as a
parser. I have done a couple myself, but I have always preferred Pascal
before Cobol. C is probably an even better language for this purpose.
However, I am more familiar with Pascal.
The biggest parser I made was to convert from MS Cobol (MF) to Acucobol,
quite extensive if I may say so. No way I would have done that one with
Cobol.
Cheesle
William M. Klein
(checker) is and always has been written in COBOL. I would call that a
PRETTY EXTENSIVE parser <G>
--
Bill Klein
wmklein <at> ix dot netcom dot com
"Cheesle" <che...@online.NoSpamPlease.no> wrote in message
news:8l58kf$p4h$1...@news.cerf.net...
William Lynch
>
> With the addition of reference modification, I found COBOL wasn't bad
> for the one or two parsing programs that I have written. What should be
> in a language for it to be good for parsing things?
The PARSE command in REXX springs to mind. REXX is VERY powerful at
doing these kinds of things.
Bill Lynch
Michael Mattias
--
Michael Mattias
Tal Systems
Racine WI USA
michael...@gte.net
Cheesle <che...@online.NoSpamPlease.no> wrote in message
news:8l58kf$p4h$1...@news.cerf.net...
> "Clark F. Morris, Jr." <cfm...@istar.ca> wrote in message
> news:3975D37C...@istar.ca...
> > With the addition of reference modification, I found COBOL wasn't bad
> > for the one or two parsing programs that I have written. What should be
> > in a language for it to be good for parsing things?
>
Ken Foskey
>
> Just to repeat an "old" bit of news. The Micro Focus "syntax phase"
> (checker) is and always has been written in COBOL. I would call that a
> PRETTY EXTENSIVE parser <G>
I can vouch for that the parser that I wrote handled the working
storage and it was substantial. It becomes exponential when you talk
about the procedure division though.
Ken Foskey
>
> I have direct first hand knowledge of a project where a COBOL system
> was ported to VB, failed, ported to C++, failed, and then ABANDONED -
> the existing COBOL still runs the company. Does that count? I didn't
> think so.
I think that this is exactly what we want to show. The fact that
porting the business knowledge of an application is not that easy.
I would add, did you enhance the application with the latest front
end tools, on time and under budget.
Warren Porter
> "Clark F. Morris, Jr." <cfm...@istar.ca> wrote in message
> > With the addition of reference modification, I found COBOL wasn't bad
> > for the one or two parsing programs that I have written. What should be
> > in a language for it to be good for parsing things?
>
> In my humble opinion:
>
> - Recursion (which some Cobol vendors support)
> - Local storage (local to sections)
> - Dynamic strings / Memory pointers (which some Cobol vendors support)
> - Extensive string manipulation routines (could be made by one self)
>
> I generally agree with you that Cobol may very well do a good job as a
> parser. I have done a couple myself, but I have always preferred Pascal
> before Cobol. C is probably an even better language for this purpose.
> However, I am more familiar with Pascal.
Having working pointers is an excellent feature in Pascal or C when parsing
code. Reference modification puts COBOL in the ball park, but I stuck with C
when writing a record layout program to read FD copy books.
http://personal.lig.bellsouth.net/~wbport/programmer
--
Warren Porter - Remove digits
Thane Hubbell
wrote:
>
>I find the job is easier if I have access to regular expressions, recursion,
>and structured exception handlers. For reliability and ease-of-use it's nice
>if the language enforces strong cohesion and loose coupling of routines.
>COBOL does neither.
>
>- Karl
Have you tried AWK?
Thane Hubbell
wrote:
>Thane Hubbell wrote:
>>
>> I have direct first hand knowledge of a project where a COBOL system
>> was ported to VB, failed, ported to C++, failed, and then ABANDONED -
>> the existing COBOL still runs the company. Does that count? I didn't
>> think so.
>
>I think that this is exactly what we want to show. The fact that
>porting the business knowledge of an application is not that easy.
>
>I would add, did you enhance the application with the latest front
>end tools, on time and under budget.
No - the old green screens are still in use (Just on a PC now).
Ira D. Baxter
instances,
all you really need is recursion. And this is easily done (albeit a tiny
bit annoying to code)
in COBOL using an array to simulate a stack. A stack-array with about 100
entries
will parse anything of practical interest.
It is a *lot* nicer if one has tools that can automatically generate all
that stuff.
[We do, see http://www.semdesigns.com/Products/DMS/DMSToolkit.html.
DMS handles COBOL and XML as well as lots of other languages].
Then one can spend energy worrying about what to parse, and where to put
the results, rather than how to do it.
--
Ira Baxter, Ph.D., CTO idba...@semdesigns.com 512-250-1018x140
Semantic Designs, Inc., www.semdesigns.com FAX 512-250-1191
12636 Research Blvd #C214, Austin, Texas 78759
> On Wed, 19 Jul 2000 21:41:39 GMT, "Oscar T. Grouch" <dus...@home.com>
> wrote:
>
> >
Oscar T. Grouch
too. The standard C libraries have some useful routines as well. However
that's not the goal of this particular project so I don't really have my
choice of tools.
- Karl
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:397715c3...@207.126.101.100...
> On Wed, 19 Jul 2000 21:41:39 GMT, "Oscar T. Grouch" <dus...@home.com>
> wrote:
>
> >
> >I find the job is easier if I have access to regular expressions,
recursion,
> >and structured exception handlers. For reliability and ease-of-use it's
nice
> >if the language enforces strong cohesion and loose coupling of routines.
> >COBOL does neither.
> >
> >- Karl
>
> Have you tried AWK?
Joseph J Katnic
Cheesle wrote:
>
> "Clark F. Morris, Jr." <cfm...@istar.ca> wrote in message
> news:3975D37C...@istar.ca...
> > With the addition of reference modification, I found COBOL wasn't bad
> > for the one or two parsing programs that I have written. What should be
> > in a language for it to be good for parsing things?
>
> In my humble opinion:
>
> - Recursion (which some Cobol vendors support)
> - Local storage (local to sections)
> - Dynamic strings / Memory pointers (which some Cobol vendors support)
> - Extensive string manipulation routines (could be made by one self)
>
> I generally agree with you that Cobol may very well do a good job as a
> parser. I have done a couple myself, but I have always preferred Pascal
> before Cobol. C is probably an even better language for this purpose.
> However, I am more familiar with Pascal.
>
I'm familiar with Rexx, and except for AWK etc. has one of the most
powerful parsers around.
Powerful in the sense that it's statement construction is relatively
simple and most importantly easy to comprehend.
You can have your Unix special characters etc.
I've been giving this some thought lately. One think (among many) that
COBOL lacks is DYNAMIC Variables.
I would limit these beasts to be type AlphaNumeric.
Some example syntax:
01 Parsed-input-data.
03 a-keyword-value-pair DYNAMIC DELIMITED BY "," STRIPPING TRAILING
AND LEADING SPACES.
03 rest-of-input-data DYNAMIC STRIPPING TRAILING AND LEADING SPACES.
01 anInput-Pair.
03 aKeyword DYNAMIC DELIMITED BY "=" STRIPPING TRAILING AND LEADING SPACES.
03 aValue DYNAMIC STRIPPING TRAILING AND LEADING SPACES.
Now you could parse by
MOVE Input-Data to rest-of-input-data
PERFORM UNTIL LENGTH OF rest-of-input-data = ZERO
MOVE rest-of-input-data to Parsed-input-data
IF LENGTH OF a-keyword-value-pair > ZERO
MOVE a-keyword-value-pair to anInput-Pair
IF aKeyword = "BLAH"
MOVE aValue to BLAH-VALUE
END-IF
END-IF
END-PERFORM.
Of course it would be possible to do the reverse, moving fields to the
03 levels and moving the 01 level back to the "rest-of-" field thus
building up a text argument string.
Numeric conversion happens when you move a DYNAMIC field to a PIC 9
COMP-any field. and vice a versa.
Of course the DELIMITED BY xx statement can have xx a single character
constant, a multiple character constant or any character type field
including DYNAMIC.
This should allow for some complex parsing.
This scheme could be expanded to allow the definition of an XML
"record". i.e. from <tag> to </tag> with all the other tags inside.
Decoding would entail a series of MOVEs into the 01 level until the
lower level fields have all or partially been decoded.
This is somewhat different to current COBOL standard as each successive
move into 01 would not delete the existing data there, but would be
parsed using the rules in the data specification to determine which
field/s should receive the data.
Similarly, encode would be a move to the lower levels and a move from
the 01 level.
--
Regards,
Joe Katnic jos...@iinet.net.au
Ken Foskey
>
> Having working pointers is an excellent feature in Pascal or C when parsing
> code. Reference modification puts COBOL in the ball park, but I stuck with C
> when writing a record layout program to read FD copy books.
The cobol parser will parse a copybook and produce a structured
picture of the copybook for you to use in your program. If you find a
bug in this give me a yell and a sample and I will fix it free.
If you release you FD tool to public domain you can help everyone,
this is my hope.
Give me an email if you want help on howto. Take a look at refrmt
program that reconstitutes the working storage according to my format.
I promise I will get back to this in my spare time (small chuckle,
frowns, returns to other projects).
Howard Brazee
>
> Unfortunately not. Now had you been able to write "Done in VB, failed,
> then done in C++, failed, then done in COBOL - SUCCESS!" - dumb maybe,
> but it doesn't count that it was already in COBOL - just shows the other
> two were lousy approaches. And then some jerk is going to say, "But you
> didn't try Java or Pascal or something etc...."
Most any task can be done with most any language - with varying costs.
In general, Cobol users have different definitions of "done" than Java
programmers have.
Does "done" mean the program has gone into production and is used, or is
does it mean, it has lasted through the life cycle of the business need?
VB is great for some quick and dirty applications. I have never tried
maintaining a VB program which has been modified for 20 years in a
working environment and I doubt if I ever will.
Maybe programming SHOULD be throw away. We are in a throw away society,
we don't repair bad chips in our TV set. Maybe programming should be
throw away. Don't keep modifying programs from their original design -
just replace them. If so, then some of the advantages of Cobol are
gone.
But I haven't seen studies showing that we are there yet. Analysis and
design is expensive. Testing the analysis and design is expensive.
Pizzamaxsw
and then IBM/370 and may be most of the people don't now what kind of thing is
that 360 or 370; since that I had been programming in COBOL passing by diferent
kind of computers; processor speed (Imagine working with flippy and floppy
diskettes at less than 4MHZ). So, after 20 years I had tried RPG, Basic,
Dbase, Clipper, Foxpro, Oracle, Informix, C, CP/M, Dos, Windows, Unix (Aix,
HP-UX, DG-UX.....) and guess what????? COBOL is always present as a programming
language for new development, upgrades, migrations.
After 20 years I still programming in COBOL and I discover new Tools for
programming.
And after the Y2K nothing happens and so with COBOL. Think about it the only
basic thing you have to now is SPEAK ENGLISH, little of logic and then
enjoy.....
Vinicio Aizpurua
Independent Analist/Programmer
Miami, FL, USA
aizp...@aol.com