Re: Reasonably priced COBOL products


James J. Gavan wrote:
tsquare21 wrote:
Good points Bill, I would have to agree that cobol except entriprise
programing is not very viable solution for small development, cost the
#1 block. Yet in the early years most programing languages cost were
significant, even for C, Pascal (delphia) and other languages. As
competition grew (mostly from borland) cost of many languages were
driven down. Maybe that is the only reason COBOL is yet high, Borland
never produced a COBOL version. I remember my first Borland C pacage
it came on 9 3.5 HD disks. Yet MF was selling CObol for $2000 and it
was on 3 disks, what a joke.

Firstly, if you trace back Bill's messages over the years, he has always
expressed the opinion that it was not viable for PC COBOL vendors to
produce 'cheap' compilers that would give them a steady revenue source.
Dear old VISOC at about $800 a crack zoomed up to about $3,000 in Net
Express V 1.0. Net Express V 3.1 was the one that introduced the
universal runtime feature - but note there was a time gap until 3.1 -
VISOC, N/E V 1, 2, 3.0 - by which time you had done a lot of coding
using the new product !

I would have to disagree, for most major languages (except maybe JAVA)
started out costing considerable more then they do today. Those that
tried to include a run time fee werer soon holding nothing as
programers released cheap Shareware programs. Can you picture
sidekick's (one of Borlands first products) market impact with a $50
plus runtime fee, Nill. That includes every shareware product realesed
without any runtime fees. Of course I don't know any shareware program
that was ever develope using COBOL, most likly due to the fact that
COBOL has no graphic capabilities.

To be fair to Micro Focus and the others - if you aren't manufacturing
and selling big iron then you have to get 'innovative' for your revenue
source. I think M/F have been overly 'innovative' to the point I for one
have had it with the whole COBOL game. From a recent message I received,
it isn't just the straight runtime fees - the author quotes figures
like the potential of $125,000 and $40,000 for using other M/F features !

MF being inovative, maybe only in there price structure. As I stated
when Borland was coming in +9 disk MF program came in 3 disk. So what
exactly did MF offered more then Borland. Code base was stagnet with
no new added features as was common with Borland and other compiler
options. To tell you the truth I can"t understand WHY? no one
released an inexpensive COBOL option. Just maybe it is because COBOL
is so easy to code that all those interprise aplication remain because
of ease of coding. Maybe this reason is why COBOL has no alternitive
cost structure. Corporation can hire entry level programers and still
recive some reasonable assurance that they will be productive and
recieve additional job training. So the ease of COBOL programing could
be a reason COBOL reamans expensive and assured to have a limited
future.

Yet COBOL, maybe the most EASIEST programing language to learn was
never developed to it's pointential. All other Languages were
extensivly develope to incompas much more then thier initial programing
capabilities. Here we are in 2006 and we still are using 85 code. Not
only is our api's staganet but what new cabilities did 85 add. Did the
cobol standard include local varibles, that should have been add ages
ago. Was a graphic engine included, or any way to code the video
interface. was a int, float data set included (I know there are work
arounds). I could go on with the frozen COBOL ccompiler but we are all
aware of it's limitation.

I'd be prepared to take a bet that COBOL is the EASIEST language to
learn - and that was the original intention when it was designed, way
back, in some six months. (I learned shorthand in the RAF - I can assure
you this message I'm writing is much EASIER to comprehend than
shorthand - the only advantage of the latter is that you can quickly
write down what is being said - and hope to God you can figure it out
when you get back to typing it in your mother tongue !).

APIs, Local Variables, Graphic Engine. Go back to the late fifties/early
sixties the mainframe vendors had the big stick to wield their clout.
Hindsight, yes, but they could have controlled where the computer market
went, but as a group completely missed the potential impact of the dinky
toys - PC desktops. I don't want to put words in his mouth, but I
believe while a member of the COBOL Standards (J4) Bill agreed with the
long held general consensus - COBOL should NOT be designed to
acknowledge individual operating systems. Fair enough in one sense. But
given that thought, how could we slot in at least two of your points
above - APIs and a Graphic Engine.

What you are saying is it's the commitee that has a negative impact on
COBOL. While COBOL relied on these lame duck commitee members to
direct COBOL upgrade (or lack of it). Most languages were controled by
a company that only intrest was to out produce thier compition. The
only way to do this was to continuly inhance there compiler. Does C
even have some commitee that tells manufactures what can be added or
not.

As you say there are workarounds - but the real solution becomes Java or
C, which is where anybody, with still some 20 years of working life,
will likely finish up.


When it comes to the 'neutrality' feature in COBOL there has always been
politics to contend with. Way back when Grace Hopper was involved, Big
Blue wanted to keep a certain feature 'confidential'. Grace and another
didn't like that, and 'gently suggested' to the then Canadian
representative on the Standards, that he should 'accidentally' release
this particular document ! Confidentiality was blown.

My own impression - Big Blue is still a big offender. Look at some of
the messages that get posted here, understanding JCL, SORTS, DB2 etc.,
not one COBOL RESERVED WORD in the whole bunch. They're interested in
the big iron sales and you can use which of their languages you like.
Reflect - what's dramatically different about using their languages
dovetailed to their O/S, compared to Bill Gates and Windows ?

Big Blue like MS does more to hinder the PC market then inhance it.
Other then releasing the PC what has IBM done for the PC since and the
was what 25 years ago. Unfortunatly like most corporates they have use
agendas to run there companys instead of letting markets and product
development rule. Then again we can probaly say that for all cappalist
corporations.

Absolutely no reflection on the lady who represents IBM on J4, (and
Chuck Stevens can attest to her contribution, particularly as he is/has
taken on her old job of chairing the ISO COBOL Committee), but
regardless of her efforts, my feeling is that the real decisions are
made much higher up above her in the IBM family tree. An example - I
looked at an old paper on COBOL OO Collections which contained a phrase
like 'the Base Class does not have to be in COBOL' - funny I said, why
would you want to do that ? IBM Enterprise is released with skeleton OO
classes, but NO collections and it reads like :-

'MyParticular Class inherits for JavaBase'

- Java is used to create/destroy objects and you do all your fancy GUI
stuff and lists/Maps in Java !

Even where OO is included in COBOL it is treated as a second-league
contender. J4, the ANSI Committee, is an 'American' committee which does
welcome 'outsiders', but over time the situation has become that the ISO
Committee determines what COBOL will have and pass that on to J4. So
there are 'teams' from several countries represented on the ISO. (The
American team is largely the J4 members). The others, fair bet they are
all, mainly, from development companies being big iron users, (as the
vendor market has all but disappeared in Europe), and just want to mosey
along without getting involved in OO. (From a practical point of view,
regarding ISO, how many small folks (PC Windows/Unix/Linux developers)
could afford/waste the time or money to represent their countries).

Fairly recent emphasis has been on amending the following feature in
COBOL :-

Working-Storage Tables 'OCCURS x TIMES' or "OCCURS x DEPENDING ON y"

Whichever way you cut the cookie you still finish up with a fixed
allocation of memory, used or otherwise. The solution is there in OO
where you can grow/increase/decrease Collection sizes at will. Nah !
Let's stick with the tried and true W/S Table and we'll build in a
solution comparable to the OO approach.

The tried and true WS data sets what a joke. My programs are fairly
small and I have a hard time controling the GLOBOL WS data. I can just
imagine a large corporation with 10,000's lines of code trying to
maintain it's WS area. Is it that difficult to include a way to have
Local Varibals. What the big deal just hav a Local Storage key word
that is in area 1. then define your varibles as you would any WS data
sets. What the big deal to that. then for some graphic programing you
add another keyword "graphic" and it would take a number of varibles to
place some points on the monitor.

That is all you would need to make COBOL a major player in the
programing marketplace.

I'm sure it is the EASI3EST LANGUAGE TO COMPREHEND
So why don't I just move to another platform. I like COBOL, as i said
it's so easy to learn and program. Personaly I just don't wan't to
re-wright all My CoBOL code to another platform, then theres that
learning curve, no thanks.

That's my gripe for the week

If you have years and years of COBOL coding, giving you some rock-solid
libraries, I can certainly see your reticence to do a switch. Given that
you have another 20 years work life, career wise, play it safe and get a
handle on C or Java. Particularly so if you are US-based where we see
occasional messages bitching about folks getting in with green cards or
outsourcing. Your work competitors in Asia, (outsourcing), are growing
and growing.

No my expericence is more of a personal programing language. I have a
stub COBOL program (that I paid to have coded) and I just inhance this
base program. Since COBOL IS an easy language I have since added to
even to the stup program. This is the only reason I remain a COBOL
programer it does what I want it to do.

Meanwhile the whole COBOL game, Standards, vendors and developers are
shooting COBOL in the foot - certainly developers sticking with a
mindset of COBOL '85. Not 2010, 'cos that's just around the corner, but
2020, a weakened COBOL market ? 2030 - COBOL might just be an
interesting historical footnote ?

Shot COBOL in the foot and Gangreen has set in.


Interesting thought - given 2020 or 2030 I wonder what either C or Java
will, look like ?

Jimmy, Calgary AB

.

Relevant Pages

  • Re: Reasonably priced COBOL products
    ... Yet in the early years most programing languages cost were ... significant, even for C, Pascal and other languages. ... Maybe that is the only reason COBOL is yet high, ... Meanwhile the whole COBOL game, Standards, vendors and developers are shooting COBOL in the foot - certainly developers sticking with a mindset of COBOL '85. ...
    (comp.lang.cobol)
  • Re: Reasonably priced COBOL products (was: Where I can Download Netexpress ?
    ... Yet in the early years most programing languages cost were ... significant, even for C, Pascal and other languages. ... Maybe that is the only reason COBOL is yet high, ...
    (comp.lang.cobol)
  • Re: Another HST up the spout?
    ... The perils of programing when pissed .... ... COBOL is a high level language, and designed for less skilled programmers, and to map data as much as possible into the physical world. ...
    (uk.railway)
  • Re: Theodore Adorno, a prophet of data systems design
    ... Hey, goose man. ... >> especially those who cling to outdated languages. ... Buddy of mine wrote an efficient chess program in Cobol to demonstrate ... Levine the Genius Tailor says, "no problem, just hold your arm like ...
    (comp.programming)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... with no mainframe COBOL at all, ... And general-purpose computers running general-purpose applications are a ... movement in general programming toward better ... But are these pockets of "old time languages" significant in a global ...
    (comp.lang.cobol)