Cobol - Is Micro Focus doomed?

Author

Is Micro Focus doomed?

Judson McClendon

2005-11-12, 6:55 pm

I feel very strongly about this issue, and I wanted to see how you other
COBOL users feel about it.

I used Micro Focus COBOL from the mid 80's, and then Net Express since the
90's. So I have invested some 20 years of my career into using Micro Focus
COBOL products. I did this by choice, so I have obviously been pleased with
the compilers. But I am abandoning Micro Focus because of their licensing
policies. Partly because of the licensing enforcement code that won't let me
freely install or reinstall the compiler on any PC I use, but mostly because
of the requirement for runtime licensing, on top of huge fees for the
compiler.

I don't illegally copy copyrighted software (or movies or anything else).
But can you imagine if any other industry's tool manufacturers required fees
from the end user of any product made with those tools? What if, when you
bought a couch you had to pay fees to the manufacturers of the saws,
hammers, sewing machines and other tools used to build the couch for as long
as you used it? Imagine such a situation with an automobile or computer!
Here I am with a $5,000 compiler, but I can't use it to write a stupid
little video database program for my daughter, without her having to pay
ridiculous runtime fees to MF! And on top of that, compilers are essentially
translators - that don't add function, they're worth nothing in themselves;
they simply translate source code into object code.

I've used Btrieve, now Pervasive, for a long time. They used to charge me
for the product, which I could use and distribute the runtime for free. Now
they charge for the runtime, but I can download the development tools for
free. I can live with that, but Net Express costs thousands of dollars, plus
a yearly support fee, AND they want runtime fees!

Over the years I have lost literally tens of thousands of dollars in lost
income and time wasted because of failures in MF's compiler licensing
software. I was once down for three months and could not use the software
because of that buggy piece of junk. Now they want me to inflict the same
kind of stupid hassle on clients who have been freely using software I wrote
for them 10 or 15 years ago, and make them pay a fee to MF for the
privilege! No way!

After investing so much of my career into a product, and to have them change
policy so dramatically on me, I feel betrayed. I am betrayed. In a time when
people are abandoning COBOL left and right, you would think MF would
appreciate their clients, rather than stomping on them. Apparently not. I am
so torqued about this that it makes my gut clench. I have looked at other
COBOL compilers, but haven't found one I like. Greed and short-sighted
stupidity on the part of MF is forcing me to abandon a language I have used
and loved for 37 years. Grrr!
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

Michael Mattias

2005-11-12, 6:55 pm

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:H4odf.26129$td.6293@bignews3.bellsouth.net...
> I feel very strongly about this issue, and I wanted to see how you other
> COBOL users feel about it.
> ...
> But I am abandoning Micro Focus because of their licensing policies.
Partly because of the licensing enforcement code that won't let me
> freely install or reinstall the compiler on any PC I use, but mostly
because of the requirement for runtime licensing...

Not that I agree with it, but it is Microfocus' business decision to make,
and the consequences are theirs to live with.

When I made the strategic decision to go in the "Windows(r) direction" in
about 1998, I looked at compiler and language products. One of the things I
looked at long and hard was, whatever decision I would make on the
language/compiler front, I wanted to make damn sure that should the
compiler/language product could never have me by the short hairs down the
road, either by failure to support the product or some harebrained change of
policies.

And you know, to this day I still avoid becoming attached to
'compiler-specific' features, regardless of the extra work required to make
whatever I do at least somewhat portable to a new compiler/language 'if
worst comes to worst.'

Fortunately COBOL code is pretty portable to other compiler products, and
the free market has a wonderful way of filling the gaps left by those who
abandon a loyal customer base.

MCM

Judson McClendon

2005-11-12, 6:55 pm

"Michael Mattias" <michael.mattias@gte.net> wrote:
>
> Not that I agree with it, but it is Microfocus' business decision to make,
> and the consequences are theirs to live with.

I agree they have the legal right to do so. But I question their ethical
right to cause such havoc with loyal customers. MF is fixated on large
business, for whom runtime fees are simply another detail. But the local
Chamber of Commerce showed me statistics that 77% of the entire US workforce
is employed by businesses with less than 20 employees. So big business hires
only 23%, less than a quarter of the workforce.

> And you know, to this day I still avoid becoming attached to
> 'compiler-specific' features, regardless of the extra work required to
> make
> whatever I do at least somewhat portable to a new compiler/language 'if
> worst comes to worst.'

I agree, and am beginning to get pretty paranoid about it. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

Michael Mattias

2005-11-12, 6:55 pm

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:CZodf.13237$kd.12498@bignews4.bellsouth.net...
> "Michael Mattias" <michael.mattias@gte.net> wrote:
make,[color=darkred]
>
> I agree they have the legal right to do so..... MF is fixated on large
> business, for whom runtime fees are simply another detail...

Once upon a time .....

There was a very fine 'any to any' mapping product available. It began life
about 1993 as "Mercator," published by TSI International, Ltd. One could
license an 'Authoring System", which is used to actually develop
applications, or one could purchase a 'runtime only' license. (To run
applications developed by others).

A few years later, TSI decided that the Mercator product had become such an
important part of their business that they renamed the company, "Mercator
Software, Inc."

About this time they also decided that 'big business' was where their future
was in this product: six-figure sales to nine-plus figure companies. They
eliminated the option to purchase a 'runtime only' license (which went for
about $250.00/CPU) and was pretty attractive to third-party developers
(e.g, me); henceforth if you wanted to run an application using the Mercator
runtime engine, you had to license the Mercator Authoring system to do do.

While very powerful and of excellent quality, the Mercator Authoring System
is just too expensive (about $10K up front + $2500/year maintenance) for
small customers to afford - epecially considering there is no way in hell
Suzy User could possibly know what to do with an Authoring System, so the
use of their engine as a component of systems created by niche vertical
market VARs (e.g., me) just totally dried up.

Mercator Software Inc. ended up abandoning the product and selling the
rights to Ascential Software, Inc..

Ascential promptly adopted the same 'big business' emphasis and did not
reinstate the 'third party VAR runtime only' license.

Ascential Software was recently acquired by IBM.

Funny how a complete series of CEOs of TSI International and Mercator
Software Inc could not do grade school arithmetic:

True or false? One sale at $100, 000 produces the same revenue as does 400
sales at 250 Dollars.

I'm not even including this likely truth: the sales expense for the single
$100,000 sale would be greater than the sales expense (which I shall
estimate as ZERO) had the 400 runtime engines been marketed thru the
third-party developers.. who are already out marketing their vertical market
products.

No, I do not know who's living happily ever after.

MCM

Donald Tees

2005-11-12, 6:55 pm

Judson McClendon wrote:
> I feel very strongly about this issue, and I wanted to see how you other
> COBOL users feel about it.
>
> I used Micro Focus COBOL from the mid 80's, and then Net Express since the
> 90's. So I have invested some 20 years of my career into using Micro Focus
> COBOL products. I did this by choice, so I have obviously been pleased with
> the compilers. But I am abandoning Micro Focus because of their licensing
> policies. Partly because of the licensing enforcement code that won't let me
> freely install or reinstall the compiler on any PC I use, but mostly because
> of the requirement for runtime licensing, on top of huge fees for the
> compiler.
>
> I don't illegally copy copyrighted software (or movies or anything else).
> But can you imagine if any other industry's tool manufacturers required fees
> from the end user of any product made with those tools? What if, when you
> bought a couch you had to pay fees to the manufacturers of the saws,
> hammers, sewing machines and other tools used to build the couch for as long
> as you used it? Imagine such a situation with an automobile or computer!
> Here I am with a $5,000 compiler, but I can't use it to write a stupid
> little video database program for my daughter, without her having to pay
> ridiculous runtime fees to MF! And on top of that, compilers are essentially
> translators - that don't add function, they're worth nothing in themselves;
> they simply translate source code into object code.
>
> I've used Btrieve, now Pervasive, for a long time. They used to charge me
> for the product, which I could use and distribute the runtime for free. Now
> they charge for the runtime, but I can download the development tools for
> free. I can live with that, but Net Express costs thousands of dollars, plus
> a yearly support fee, AND they want runtime fees!
>
> Over the years I have lost literally tens of thousands of dollars in lost
> income and time wasted because of failures in MF's compiler licensing
> software. I was once down for three months and could not use the software
> because of that buggy piece of junk. Now they want me to inflict the same
> kind of stupid hassle on clients who have been freely using software I wrote
> for them 10 or 15 years ago, and make them pay a fee to MF for the
> privilege! No way!
>
> After investing so much of my career into a product, and to have them change
> policy so dramatically on me, I feel betrayed. I am betrayed. In a time when
> people are abandoning COBOL left and right, you would think MF would
> appreciate their clients, rather than stomping on them. Apparently not. I am
> so torqued about this that it makes my gut clench. I have looked at other
> COBOL compilers, but haven't found one I like. Greed and short-sighted
> stupidity on the part of MF is forcing me to abandon a language I have used
> and loved for 37 years. Grrr!

That is precisely why I do not code in Cobol any more. It is not only
expensive, but the old saw about compatability is just that. Cobol ties
you in to a platform, rather than freeing you from it.

Donald

James J. Gavan

2005-11-12, 6:55 pm

Judson McClendon wrote:
> I feel very strongly about this issue, and I wanted to see how you other
> COBOL users feel about it. (ME - i.e. runtime-support fees.......).

Judson,

I am more than sympathetic to your comments and started a reply - just
got too bloody long winded. So scratched that approach.

Being a retiree, I haven't gotten into runtime fees, although I did see
somebody quote a figure which made me shudder.

So let's get a little specific before I respond to your message. Your
particular case, exactly what are the runtime fees in DOLLARS. For
example you produce some utility for $50,(intended to have widespread
appeal; not just COBOL users perhaps - a 'Component' if you like). Or
we'll say applications for $500, $5,000, $10,000 etc. Exactly what are
the runtime fees you are being asked to shell out for based on your own
intended end-user price ?

Jimmy

charles hottel

2005-11-13, 6:55 pm

I agree with you. When I retire I want to write programs that I want to
write, and I had plans to provide algorithms, tools and utilities for COBOL.
I was shocked and amazed at the prices charged for COBOL compilers. COBOL is
much less complex than C++ yet it costs so much more for a compiler. They
are not interested in individual sales and small companies. In one thread
they mentioned having to provide highly functional IDE's for companies. I
just do not buy their argument. There was a guy writing books and magazine
articles on C++ and he cobbled together a pretty good IDE for use with his
book in just a few months.

I admit that at one time I could not afford a COBOL compiler, but now even
though I could afford one I will not pay their price. I also agree that it
is their right to choose their market and how to approach it, but it is my
right to go in another direction as well.

Java is free and a seems to be a good language and has a lot of very
powerful classes for a very wide range of application types. My initial
response to Java a few years ago was somewhat negative but I now believe
that was mostly due to a sleep apnea problem which affected my learning
process. Since I have resolved that problem both Java and OO programming in
general have seemed much easier to learn.

The point is not to switch to Java but to simply realize that other
alternatives are out there if you are open to learning some new things and
learning new things is one of the main reasons I got involved with computers
and programming in the first place.

I have felt my own version of you pain over this matter and I hope you find
an acceptable solution to resolve your situation.

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:H4odf.26129$td.6293@bignews3.bellsouth.net...
>I feel very strongly about this issue, and I wanted to see how you other
>COBOL users feel about it.
>
> I used Micro Focus COBOL from the mid 80's, and then Net Express since the
> 90's. So I have invested some 20 years of my career into using Micro Focus
> COBOL products. I did this by choice, so I have obviously been pleased
> with the compilers. But I am abandoning Micro Focus because of their
> licensing policies. Partly because of the licensing enforcement code that
> won't let me freely install or reinstall the compiler on any PC I use, but
> mostly because of the requirement for runtime licensing, on top of huge
> fees for the compiler.
>
> I don't illegally copy copyrighted software (or movies or anything else).
> But can you imagine if any other industry's tool manufacturers required
> fees from the end user of any product made with those tools? What if, when
> you bought a couch you had to pay fees to the manufacturers of the saws,
> hammers, sewing machines and other tools used to build the couch for as
> long as you used it? Imagine such a situation with an automobile or
> computer! Here I am with a $5,000 compiler, but I can't use it to write a
> stupid little video database program for my daughter, without her having
> to pay ridiculous runtime fees to MF! And on top of that, compilers are
> essentially translators - that don't add function, they're worth nothing
> in themselves; they simply translate source code into object code.
>
> I've used Btrieve, now Pervasive, for a long time. They used to charge me
> for the product, which I could use and distribute the runtime for free.
> Now they charge for the runtime, but I can download the development tools
> for free. I can live with that, but Net Express costs thousands of
> dollars, plus a yearly support fee, AND they want runtime fees!
>
> Over the years I have lost literally tens of thousands of dollars in lost
> income and time wasted because of failures in MF's compiler licensing
> software. I was once down for three months and could not use the software
> because of that buggy piece of junk. Now they want me to inflict the same
> kind of stupid hassle on clients who have been freely using software I
> wrote for them 10 or 15 years ago, and make them pay a fee to MF for the
> privilege! No way!
>
> After investing so much of my career into a product, and to have them
> change policy so dramatically on me, I feel betrayed. I am betrayed. In a
> time when people are abandoning COBOL left and right, you would think MF
> would appreciate their clients, rather than stomping on them. Apparently
> not. I am so torqued about this that it makes my gut clench. I have looked
> at other COBOL compilers, but haven't found one I like. Greed and
> short-sighted stupidity on the part of MF is forcing me to abandon a
> language I have used and loved for 37 years. Grrr!
> --
> Judson McClendon judmc@sunvaley0.com (remove zero)
> Sun Valley Systems http://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."
>

Rick Smith

2005-11-13, 6:55 pm

"charles hottel" <jghottel@yahoo.com> wrote in message
news:a732d$43775468$4f9c624$23473@DIALUP
USA.NET...
[snip]
> [...] COBOL is
> much less complex than C++ yet it costs so much more for a compiler.

The first part may be true for the user; but the compiler
developer has to deal with the complexity of the
language specification. It is not clear to me that COBOL,
particularly 2002, is less complex than C++ in that regard.

James J. Gavan

2005-11-13, 6:55 pm

charles hottel wrote:
> I agree with you. <snip>

Charles,

Nice to hear from you again. Here's a sobering thought and had to go dig
down in the basement to get actual figures from Feb '81. Canadian dollars :-

- hardware :

Tandy Radio Shack Model II - 64 K ($5,645)
1 Drive Extension (10 inch floppies) ($1,699)
Line Printer VI ($1,350)
Extras (power bar, Printer cable, cover etc) ($193)

- Software :

Tandy's SCRIPSIT word processor ($379)
RM/COBOL ( '74) ($399).

Hardware : $8,694 Software : 778

RM/COBOL was bare bones compiler - no editor, examples, tips etc. Hence
the reason for SCRIPSIT to act as an editor. The COBOL compiler did the
job. Slowness was purely from the 'primitive' machine being used.

I guess those hardware and software figures have got somewhat switched
around.

In a hobbyist vein, it just doesn't make sense for you to shell out for
a commercial COBOL compiler. If and when they get around to OO perhaps,
KOBOL or one of the other 'Open Source' compilers might do it for you.

Jimmy, Calgary AB

Donald Tees

2005-11-13, 6:55 pm

James J. Gavan wrote:
> charles hottel wrote:
>
>
>
> Charles,
>
> Nice to hear from you again. Here's a sobering thought and had to go dig
> down in the basement to get actual figures from Feb '81. Canadian
> dollars :-
>
> - hardware :
>
> Tandy Radio Shack Model II - 64 K ($5,645)
> 1 Drive Extension (10 inch floppies) ($1,699)
> Line Printer VI ($1,350)
> Extras (power bar, Printer cable, cover etc) ($193)
>
> - Software :
>
> Tandy's SCRIPSIT word processor ($379)
> RM/COBOL ( '74) ($399).
>
> hardware : $8,694 Software : 778
>
> RM/COBOL was bare bones compiler - no editor, examples, tips etc. Hence
> the reason for SCRIPSIT to act as an editor. The COBOL compiler did the
> job. Slowness was purely from the 'primitive' machine being used.
>
> I guess those hardware and software figures have got somewhat switched
> around.
>
> In a hobbyist vein, it just doesn't make sense for you to shell out for
> a commercial COBOL compiler. If and when they get around to OO perhaps,
> KOBOL or one of the other 'Open Source' compilers might do it for you.
>
> Jimmy, Calgary AB

Why would any person "make do" with a bit of fluff when there are dozens
of powerfull compilers and compiler tools available?

To set up and compile with Cobol costs thousands of dollars, and it is
only going to be one of a dozen tools required to do the job. When you
are done, it costs each person that wishes to use it hundreds of dollars
ti *use your product*. I want to sell the software I write, not design
loss leaders for a compiler company.

I am curently making a good living converting code from Cobol to other
languages, because even the people that own it do not want to be in that
position. Cobol is now one of a dozen languages, and about a decade and
a half behind all of them. Yet they want to charge double for their
product. I simply can no longer make a profit if I use the language.

Donald

Richard

2005-11-13, 6:55 pm

> RM/COBOL was bare bones compiler - no editor, examples, tips etc.

> In a hobbyist vein, it just doesn't make sense for you to shell out for
> a commercial COBOL compiler. If and when they get around to OO perhaps,
> KOBOL or one of the other 'Open Source' compilers might do it for you.

Kobol isn't 'Open Source' it is a commercial product. It does include
an IDE and an editor but is otherwise a 'bare bones' comparable to
RM/Cobol of 20 odd years ago, and perhaps CIS Cobol.

James J. Gavan

2005-11-13, 6:55 pm

Richard wrote:
>
>
>
>
> Kobol isn't 'Open Source' it is a commercial product. It does include
> an IDE and an editor but is otherwise a 'bare bones' comparable to
> RM/Cobol of 20 odd years ago, and perhaps CIS Cobol.
>
Yes I knew that Richard. I should have worded it, "...KOBOL or one of
the 'Open Source'....". I wasn't aware it had an IDE - that's good - but
as I recall you don't much care for IDEs.

Having made the move to OO COBOL, KOBOL just doesn't cut it for me, as
is. Perhaps if later on......, they introduce OO ????

Jimmy, Calgary AB

James J. Gavan

2005-11-13, 6:55 pm

Donald Tees wrote:
> James J. Gavan wrote:
>
> Why would any person "make do" with a bit of fluff when there are dozens
> of powerfull compilers and compiler tools available?

I can certainly understand your irritance, but a "bit of fluff" ?
I can't comment on Fujitsu but I think it is fairly comparative to Net
Express in that it does have comprehensive included features. Bearing in
mind you took the route of using Flexus SP2 for screening, there's one
of your first additional costs.

So without having the 'latest greatest' NE V4, (still using V3.1), I have :-

(a) My preference, an integrated Development Environment for everything

(b) File handling feature, which I no longer use. And you know what you
get if you try to open a comp-3 file with say MS Word - bugger all !
Accidentally tried to open an ISAM, and their Data File Editor shows the
file with the comp-3s as Usage Display.

(c) Two choices of GUIs :-

(i) Dialog System ( which has come a longgggggg way since the DOS days -
again I don't use)

(ii) Dialog Editor and GUI classes.

(iii) Well there are other choices for GUIs - you can hook into Java or
C; for Java certainly classes to 'communicate' with Java, and I'm
talking V 3.1 not V 4 with dotNet. Interestingly Calin there in Toronto
recently asked about some White Paper. Appears you can use V 3.1 to do a
kinda dotNet approach, (haven't read it yet).

(d) SQL - You can jump right in without literally any expertise,
although it makes sense to bone up on the topic a bit. The ESQL
Assistant generates your copyfiles to handle the DB format and the
interpreted COBOL formats. Better still - set up a Query in the ESQL
Assistant - you can run the query and get results without compiling one
line of COBOL. Those same queries can be copy/pasted into your COBOL source.

(e) I'm sure there may be other features which I may not yet have
discovered. There's something to support XML - but I think that is in V 4.0.

For my money above is a pretty nifty set of features.

I'm not defending their pricing, but the accumulation of the above
appeals to me. Be assured I much preferred the $800 for VISOC as opposed
to some $3,500 for Net Express. Water under the bridge now, but we got
ROYALLY screwed for the move from VISOC to N/E. I would guess that some
moved to Fujitsu. I know Calin took a serious look, but didn't opt for
that change.

Because of a cock-up on their database around the Merant disaster, I
didn't get reminded that my annual Technical fee, (around $1,000) was
due. So if I wanted to upgrade to N/E V 4.0 I'm absolutely screwed.
According to their rules I'm a 'newbie' and would have to pay the full
price all over again.

Technical support - well they have several innovative schemes, 'money
makers' and an annual licence for Tech Support - the latter is in effect
letting you buy the next Version on a installment payment method; you
get interim Fixpacks and enhancements and are entitled to automatically
upgrade to the next Version they issue. (The more advanced Tech Support
is where the larger organizations have a real nutty problem that can't
be solved).

The other leg of the Tech Support is what I used to refer to as Answer
Exchange. Alan Wheeler who administered the old Compuserve Forum dreamed
up that name but brought me up to date calling it 'Micro Fcous Forum'.
That's the one I used to keep referring folks to. It's a freebie.
Either developers or M/F staff can jump in with suggestions. It's still
the old, old problem - Windoze. People, primarily using Dialog System,
s

ing clarification or being fed back with an API coded solution to
their particular problem. Additionally solutions are provided for
'talking' to C or Java.

Runtime Fees. Now that really is a different baby, and a stinker ! I
can't offer any solutions, but if Judson provides some ammo on what the
costs are to him then I can certainly make at least one suggestion. So I
await his reply.
>
> To set up and compile with Cobol costs thousands of dollars, and it is
> only going to be one of a dozen tools required to do the job. When you
> are done, it costs each person that wishes to use it hundreds of dollars
> ti *use your product*. I want to sell the software I write, not design
> loss leaders for a compiler company.

Bit emotive above Donald. Exactly what costs are you referring to. Care
to spell it out with an example ?
>
> I am curently making a good living converting code from Cobol to other
> languages, because even the people that own it do not want to be in that
> position. Cobol is now one of a dozen languages, and about a decade and
> a half behind all of them. Yet they want to charge double for their
> product. I simply can no longer make a profit if I use the language.
>
> Donald

Well truly, success on your conversions. And overall I can understand
why you got pissed off.

.......I await Judson's reply on the runtime fees. Typical of c.l.c.,
somebody asks a question and the thread goes off at a tangent on
divergent topics. Somebody asks about how you do something with SQL and
we finish up discussing the size of Marilyn Monroe's breasts :-)

Jimmy

charles hottel

2005-11-13, 9:55 pm

Well I am not up to date on the 2002 specification because I figure I will
be retired before any vendor implements it, so I cannot comment about the
complexity of it. Does anyone know of any vendor who is actually trying to
implement it? It seems to me that vendors have been adding their own
enhancements in the absence of timely standards, some/many of which may now
conflict with the 2002 standard. They are probably unwilling to undo what
they have done and lose upward compatibility. Of course they could do it by
adding more compiler options.

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11nf4277aisd16c@corp.supernews.com...
>
> "charles hottel" <jghottel@yahoo.com> wrote in message
> news:a732d$43775468$4f9c624$23473@DIALUP
USA.NET...
> [snip]
>
> The first part may be true for the user; but the compiler
> developer has to deal with the complexity of the
> language specification. It is not clear to me that COBOL,
> particularly 2002, is less complex than C++ in that regard.
>
>
>

Donald Tees

2005-11-13, 9:55 pm

James J. Gavan wrote:
> Donald Tees wrote:
>
>
>
> I can certainly understand your irritance, but a "bit of fluff" ?
> I can't comment on Fujitsu but I think it is fairly comparative to Net
> Express in that it does have comprehensive included features. Bearing in
> mind you took the route of using Flexus SP2 for screening, there's one
> of your first additional costs.
>

You were suggesting that we forgo a compiler like net express, and go
with one like Kobol. Kobol is not a serious tool. I will grant that
both Fujitsu and MF are full fledged compilers, and was not refering to
either of them as a bit of fluff. I was refering to what you suggested
as a replacement. Kobol is not mature enough to write anything serious
in, and I doubt it ever will be. If I cannot use one of the "real" Cobol
compilers, then I will go to another language. There are dozens of them.

>
>
> Bit emotive above Donald. Exactly what costs are you referring to. Care
> to spell it out with an example ?
>

Run time fees. In fact, I can not even give a customer *a free copy* of
my software. I have to pay a price, depending on the number of terminals
the customer has, to allow them to try it out free. If I try to sell it
on the net, allowing them to download a trial copy, then I would be
sued, under the terms they wish me to sign.

That means that I cannot produce any product worth less than several
thousand dollars, that uses Cobol. The reason for that is not just the
cost of the fee, but also the cost of the marketing. In fact, to even
demonstrate the system, I have to either travel to the customer site or
bring the customer to my site. Figure $500 to get to a site in another
city, and give a demo, then get home again. If they are more than 400
miles away (95% of my customers), then double that. In an international
market, that pretty well rules out 99.999% of all software. If I charge
only $5000 per copy of my code, then I can afford to show it to about 5
people per sale. If only one in 10 buys, I am out of pocket. The norm is
1 in 20 or 30.

The bottom line is that Cobol can only be used on software worth $30,000
or so per install. I converted a two and a half million line Cobol
system to a 4GL system last year for the cost of less than double that.
A demo now costs an Email, say 5 cents. So, for the cost of two sales, I
can drop marketing costs to 1/2000th per prospect. If 1 in 30 buys,
then the change in language cuts my marketing cost from $15,000.00 per
copy to $1.50 per copy.

>
> Well truly, success on your conversions. And overall I can understand
> why you got pissed off.
>
> ......I await Judson's reply on the runtime fees. Typical of c.l.c.,
> somebody asks a question and the thread goes off at a tangent on
> divergent topics. Somebody asks about how you do something with SQL and
> we finish up discussing the size of Marilyn Monroe's breasts :-)
>
> Jimmy

Half the problem is that they will not tell you the price. They hum and
they haw until you have spent your money, and then discover you are
*!@#$ed. I was told that I could could package up a demo version and
give it away free, but it was on the phone, and I was given a flat
refusal when I asked for it in writing. In fact, I was told I had to
sign a document saying that I would not, and was liable if I did. *That*
was in writing.

Cobol is now something I do as a hobby, or on other people's dimes.

Donald

Judson McClendon

2005-11-14, 7:55 am

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
> ......I await Judson's reply on the runtime fees. Typical of c.l.c.,
> somebody asks a question and the thread goes off at a tangent on divergent
> topics. Somebody asks about how you do something with SQL and we finish up
> discussing the size of Marilyn Monroe's breasts :-)

Jimmy, I'm waiting until business hours today (Monday) so I can get
specifics from the MF sales staff. Last time I looked, MF did not give
actual costs on their web site. Can't say I blame them for that, considering
the sticker shock. :-) I don't remember how much the runtime fees are, but
just as bad or worse is having to

dle my clients with a piece of buggy
crap like the compiler licensing enforcement software, which is truly
horrible! From time to time I go to run the compiler and the licensing
software has become corrupted or simply decided I no longer am entitled to
use the compiler. Assuming I can even get a fix without reinstalling
Windows, I have to wait for that, and go through TWO cycles of response
keys. And MF wants me to place my clients in that position? And what about a
client who has been happily using, with no runtime fees, software I wrote
for them 10 years ago and just because I make a slight change or bug fix,
they now have to start paying runtime fees to MF? How am I supposed to
justify that to a client? It is entirely unreasonable and unconscionable. A
serious betrayal of a loyal customer base.

For anyone who thinks I am exaggerating the trouble I have had with
licensing keys, see the log below. It is not entirely complete, because I
became so disgusted during one series of problems that I quit posting to the
log for a while.

Original keys: 11-08-1999
Desktop:
Request key: X-X
Response key: X-X
Notebook:
Request key: X-X
Response key: X-X
Replacement keys: 07-12-2000 (NE 3.0 to 3.1 upgrade crash)
Desktop:
Request key: X-X
Response key: X-X
Notebook:
Request key: X-X
Response key: X-X
Reinstall keys: 01-29-2001 (New computer)
Notebook:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 03-09-2001 (Upgrade hard drive)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 03-16-2001 (New computer)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 03-16-2001 (New computer)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 03-28-2001 (Dump WinME for Win98SE)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Temporary keys: 03-29-2001 (Wrong Request Key above)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X (temp)
Reinstall keys: 03-29-2001 (Moved to new PC)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Update keys: 03-29-2001 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 05-25-2001 (Corrupted license)
Notebook:
Request Key: X-X
Response key: X-X (temp)
Update keys: 05-29-2001 (Full response for temp key above)
Notebook:
Request Key: X-X
Response key: X-X
Temporary keys: 04-08-2002 (Corrupted license)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X (Temporary)
Temporary keys: 04-08-2002 (Corrupted license)
Notebook:
Revoke Code: X-X
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 04-08-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Update keys: 04-08-2002 (Full response for temp key above)
Notebook:
Request Key: X-X
Response key: X-X
Reinstall keys: 05-23-2002 (Upgrade notebook)
Notebook:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Temporary keys: 07-19-2002 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 07-22-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 08-02-2002 (Corrupted license)
Notebook:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 08-02-2002 (Full response for temp key above)
Notebook:
Request Key: X-X
Response key: X-X
Temporary keys: 08-02-2002 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 08-02-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 10-14-2002 (Corrupted license)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 10-14-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 10-14-2002 (Corrupted license)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 10-15-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 10-30-2002 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 10-30-2002 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 04-19-2004 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 04-19-2004 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 06-17-2004 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 06-17-2004 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 06-18-2004 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 06-18-2004 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 08-26-2004 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X (Temporary)
Update keys: 08-30-2004 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Temporary keys: 08-30-2004 (Corrupted license)
Desktop:
Request Key: X-X
Response key: X-X
Update keys: 08-26-2004 (Full response for temp key above)
Desktop:
Request Key: X-X
Response key: X-X
Reinstall keys: 09-07-2004 (New computer)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 07-24-2005 (New computer)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Reinstall keys: 10-02-2005 (New computer)
Desktop:
Revoke Code: X-X
Request Key: X-X
Response key: X-X
Temporary keys: 10-05-2005 (Corrupted license)
Notebook:
Request Key: X-X
Response key: X-X (REJECTED)
Reinstall keys: 10-10-2005 (Reinstall because of corrupt license)
Notebook: (after reinstalling Windows)
Request Key: X-X
Response key: X-X
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

Herwig Huener

2005-11-14, 6:55 pm

2005-11-14 16:52:00 MET

"James J. Gavan" wrote:

> ...

> In a hobbyist vein, it just doesn't make sense for you to shell out for a
> commercial COBOL compiler. If and when they get around to OO perhaps,
> KOBOL or one of the other 'Open Source' compilers might do it for you.

BTW: Since quite a long time, I p

ed again into the TinyCobol Pages.
I had the impression that they slow down development, or that they
loose interesst - is that so?

As for the original question: Quite so. At work, I have tons of
COBOL-Compilers "to play with": BS2000, and the different
MF-products. If I were inclined to play with COBOL in my own
time on my own computers at home, I could easily install the
Server Express for Linux - but just for fun, I certainly do not
pay those license fees. And why should I? My Linux-boxes have
some flavours of C, there is Pascal and there is Ada, and maybe
another few installed but not yet discovered languages. - No
hobbyist is in a shortage of languages to select from.

Herwig

Peter Lacey

2005-11-14, 6:55 pm

Judson McClendon wrote:
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>

I last used MF about 10 years ago; I remember being very frustrated
trying (unsuccessfully) to find, in all the massive documentation
provided, a table of the numeric values to use in a particular situation
to set the colours (can't remember the details now; maybe I have
supressed the memory as an intolerable trauma!) At the same time they
came out with some add-on to help "navigate" the product. I thought
then that it was a poorly designed product indeed if they had to add
something to help people find their way around in it...

PL

James J. Gavan

2005-11-14, 6:55 pm

Judson McClendon wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
>
>
>
> Jimmy, I'm waiting until business hours today (Monday) so I can get
> specifics from the MF sales staff. Last time I looked, MF did not give
> actual costs on their web site. Can't say I blame them for that, considering
> the sticker shock. :-) <snip>

OK you are getting all worked up, with the same justification that
Donald has. For good measure you are now throwing in the problem of
license keys. Never had it, and when I had to get from my clapped out
Win 98 to my new Win XP, obviously had to re-install from the CDs. Ahhh
la Belle Province - lots of help from my M/F buddy, Jean in Quebec. Make
the license keys a separate issue, rather than fog the waters with two
topics.

So get those prices so that you can illustrate the costs associated with
the hypothetical prices for your software. I want to see numbers - but
briefly my recommendation is going to be that you write to the person at
the top of the Micro Focus Christmas Tree !

Donald is lost to the COBOL cause. If they offered him a freebie set of
CDs in a leopard covered case - it just wouldn't make sense for him to
'reverse convert'. From what he wrote, he is obviously talking M/F
(runtime fees) and he was probably getting answers from the lowest
person on the marketing team ladder in Toronto. Shame on you Donald. I
thought you, as a Socialist were passionate about rights and fair play.
Perhaps you are a lover rather than a fighter.

I've been pissed off a couple of times in life, through incompetency
that affected me :-

- Having phoned, per instruction manual to have a Hoover tech come get
my Keymatic washing machine bolted down ready for transition, our own
removal van arrived but no joker from Hoover (UK). Phoned their Head
Office on Western Avenue, west of London, on a Saturday morning. They
sprang into action phoning all over S.E. England, (Surrey, Hampshire,
Sussex and Kent), until they located a warm body who could come fix my
machine at Guildford, Surrey.

- I've mentioned before, piss-poor MicroSOFT support in Canada. Phoned
Bill Gates. His secretary diplomatically took the call and passed it on
to a troubleshooter who made sure my problem got solved. The little
lady who handled it also kindly sent a diskette of sample programs I
might be interested in. (Their then compiler, not the re-badged M/F
compilers).

- somewhat out of sequence. When immigrating to Canada, Canada House in
London made a real cock-up of my paperwork. I had a job lined-up from a
visit to my brother in '74. Their stupidity lost me the job. So around
to the local library in Taunton to check out his snail-mail address for
somebody called Pierre Elliot Trudeau. So I write to him, something like :-

----------------------------------------------------------------------
Dear Prime Minister,

As one Liberal to another, (well, it was true..., so why not butter him
up :-) )....

- I applied for paperwork on ........
- I mailed the paperwork to Canada House, London on......
- We had our initial interview at Canada House on.... and on the basis
I already had a job lined-up was given a firm 'Go'.
- All four family members had our medicals and submitted the results to
Canada House on.......

(The next ones coming up were something like two to three months apart...)

- On......had a request from Canada House for my daughter's X-Rays which
had already been sent on ........above

- On ...... had a request from Canada House for my wife's birth
certificate which had already been sent on ...... above

- On..... (I think there was a third one - but you get the idea).

Unfortunately as a result of the above I have now lost the job. Could I
perhaps have confirmation when I can go to Canada ?

Yours sincerely, Jimbo
--------------------------------------------------------------------------

I'm sure our village postman was impressed when he dropped off a crisp
envelope emblazoned 'Office of the Prime Minister of Canada".

Meanwhile within some three days of my letter hitting Ottawa somebody
was real busy at the keyboard, teletypng to Canada House. So I get a
real, quick phone call from Canada House, like "Can you fly to Canada
next Friday ?" "Gimmie a break ! I've got to give Debenhams some two
w

s notice", I replied.

Anyway it worked, came about a month later and life goes on.

None of us really like getting upset, but sometimes you gotta do what
you gotta do. Fesity old bugger you say to yourself reading this. Not
true, I hate unpleasantness just like most. I'm courteous when talking
to a store manager, and I display the same courtesy and chat to a kid
wheeling out my groceries at a supermarket.

Still don't believe me ? I go with my beloved wife on a shopping trip.
She sees a dining table she likes, but she's not much interested in the
chairs. "Can I just buy the table ?". I'm already saying to myself "Oh
my Gawd". Then when she presses on having gotten an affirmative to the
previous question. "How much discount will you give me for cash rather
than plastic ?". WOOSH ! The sound of me, acutely embarrassed, making a
bee-line for the store's nearest exit !!!

All three examples above, I was firm but always courteous, just stating
facts. It burns my ass to see two 'veterans' of COBOL, like you and
Donald giving up, without first pursuing all options.

So those figures please. If your contacts are evasive, then that kinda
strengthens our hand when complaining. I await your figures.

Jimmy

James J. Gavan

2005-11-14, 6:55 pm

Herwig Huener wrote:
> 2005-11-14 16:52:00 MET
>
> "James J. Gavan" wrote:
>
>
>
>
>
>
> BTW: Since quite a long time, I p

ed again into the TinyCobol Pages.
> I had the impression that they slow down development, or that they
> loose interesst - is that so?

Herwig,

I don't know what these 'Open Source' people are doing. The whole thing
has been going on for years now. In a practical sense I don't see how a
group of volunteers can ever compete with commercial vendor products.
The name of the game now is you buy a compiler, (at least on PCs), but
with a considerable number of add-on tools included in the IDE to make
life so much easier. Some don't like the IDE approach, but then again
there are many of us that do. A question mark perhaps, but it's the
whole IDE concept which creates that up-front price for the vendor's
product - and whatever the price, they are certainly justified in
expecting some remuneration on their efforts, particularly if their
world is just software and they don't manufacture big iron.

Jimmy

Oliver Wong

2005-11-14, 6:55 pm

"charles hottel" <jghottel@yahoo.com> wrote in message
news:1c896$4377e65d$4f9c60e$30291@DIALUP
USA.NET...
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11nf4277aisd16c@corp.supernews.com...
> Well I am not up to date on the 2002 specification because I figure I will
> be retired before any vendor implements it, so I cannot comment about the
> complexity of it. Does anyone know of any vendor who is actually trying
> to implement it?

I'm working on something similar to a COBOL compiler (eighty-something
(84?), not 2002). I've also worked on a Java compiler back in university,
and I must say the COBOL compiler is much, much, much more complicated.
Perhaps on the order of 3 or 4 times more complex.

COBOL's "noise words" (e.g. "OF", "IN", etc.) are somewhat of an
annoyance, and the "abbreviated conditionals" feature in particular makes
the grammar non-context-free, which means most "modern" tools for compiler
development either won't work at all, or need to be heavily hacked to get
them to work with COBOL. Almost every programming language developped these
days can be parsed with a context-free parser, but not COBOL.

- Oliver

James J. Gavan

2005-11-14, 6:55 pm

Peter Lacey wrote:
> Judson McClendon wrote:
>
>
> I last used MF about 10 years ago; I remember being very frustrated
> trying (unsuccessfully) to find, in all the massive documentation
> provided, a table of the numeric values to use in a particular situation
> to set the colours (can't remember the details now; maybe I have
> supressed the memory as an intolerable trauma!) At the same time they
> came out with some add-on to help "navigate" the product. I thought
> then that it was a poorly designed product indeed if they had to add
> something to help people find their way around in it...
>
> PL

"Earwigo again" said the earwig as it fell off the wall. What's your
objective Peter, to prove my quote about Marilyn above was absolutely
correct :-)

Ten years ago ? What were you looking at, the old DOS version or VISOC;
the latter I'm sure would have had what I'm about to illustrate. I hate
those on-line helps, but they also have on-line manuals, so one of the
LRMs (Language Reference Manuals), mentioning Screen Section would
probably take you straight to this.

Seeing as it's you and me, two ex-Brits - did it through the on-line
help with a search on 'COLOUR' - every conceivable reference to COLOR
you don't need until you get a bit cute. The immediate references refer
to options for colorizing your IDE. Take a second shot at
Foreground-Color :-

1. This clause is available for use only with a color screen.
2. Integer-1 or identifier-1 specifies the foreground color of the
screen item. The colors and their corresponding values are:

0 black 8 grey
1 blue 9 light blue
2 green 10 light green
3 cyan 11 light cyan
4 red 12 light red
5 magenta 13 light magenta
6 brown or yellow 14 yellow
7 white 15 high intensity white

There you go - what's wrong with that ? Didn't bother to check for RGB
used with GUI-ing, but I think the above is what you were referring to.

Jimmy

Judson McClendon

2005-11-14, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
> OK you are getting all worked up, with the same justification that Donald
> has. For good measure you are now throwing in the problem of license keys.
> Never had it, and when I had to get from my clapped out Win 98 to my new
> Win XP, obviously had to re-install from the CDs. Ahhh la Belle Province -
> lots of help from my M/F buddy, Jean in Quebec. Make the license keys a
> separate issue, rather than fog the waters with two topics.

It isn't really two topics, Jimmy, they're intimately connected: In order to
implement the runtime licensing, MF requires that their crummy license
enforcement software be installed on the client's computers. You have one,
you have the other.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

Donald Tees

2005-11-14, 6:55 pm

James J. Gavan wrote:
> Judson McClendon wrote:
>
> Donald is lost to the COBOL cause. If they offered him a freebie set of
> CDs in a leopard covered case - it just wouldn't make sense for him to
> 'reverse convert'. From what he wrote, he is obviously talking M/F
> (runtime fees) and he was probably getting answers from the lowest
> person on the marketing team ladder in Toronto. Shame on you Donald. I
> thought you, as a Socialist were passionate about rights and fair play.
> Perhaps you are a lover rather than a fighter.
>

Completely irrelevant.

I like the Cobol language, and always have. I've worked in it for 40
years now, and find Cobol both easy to read and easy to write. However,
when choosing how to write code, my likes and dislikes are rather
irrelevant. What is relevant is costs, hassles, and the length of time
it takes to write the system, plus incremental costs that occur after
the fact, like marketing and upgrading/maintaining.

Cobol is wonderfull at handling fixed format data. The picture clause is
probably the most efficient (and oop oriented) method of specifying a
data format ever invented, and all by itself made programs far more
solid. Cobol was also one of the *only* languages that had some sort of
uniformity accross platforms, so in terms of product lifetime was one of
the best languages.

However, it is terrible at handling free-format data, and suits the
cosmetic part of programming poorly, at least in the modern world. In
addition, it is no longer uniform. Most of the Cobol code I have seen in
the last five years is easier to re-write than to convert. Because most
of the formating and I/O are now external, you are not only tied to the
Cobol compiler, but to three or four other tools that all are platform
dependant. Cobol has become *worse* to convert than other languages,
albeit largely for historical reasons.

About 90% of the Cobol code I replace, I replace not with new code I
wrote, but with new code that was generated automatically by a tool. For
example, I wrote 15 programs to convert data from Isam files yesterday.
Essentially, all I did was enter the copy books into a data dictionary,
and it produced all the conversion code, all the basic listings code,
and all the screen update code. What I spend my time on is refinements
and prettifying it.

Cobol has not caught up. At one time, I thought it could, and maybe it
still can, but I cannot afford to wait.

Now, in addition to that, they have added a huge cost factor. Commiting
financial suicide to remain faithfull to a concept as abstact as a
language ... well, maybe if I was French Canadian. It is no longer Cobol
anyway. It is now MF Cobol, Fujitsi Cobol, etc.

I see no reason to fight back. I'd no sooner fight for Cobol than I
would go to war for Ford. There are more important things in life. I
just try to adapt to the silly shit, and make a living. Ill send you
fiddle tunes instead of Cobol, maybe. You'd probably enjoy them more anyway.

Donald

Richard

2005-11-14, 6:55 pm

> than I would go to war for Ford.

Do try and keep up, it is Bush now.

;-)

Donald Tees

2005-11-14, 6:55 pm

Richard wrote:
>
>
> Do try and keep up, it is Bush now.
>
> ;-)
>
<chuckle>

Yes, I suppose it is.

Donald

James J. Gavan

2005-11-14, 6:55 pm

charles hottel wrote:
> Well I am not up to date on the 2002 specification because I figure I will
> be retired before any vendor implements it, so I cannot comment about the
> complexity of it. Does anyone know of any vendor who is actually trying to
> implement it? It seems to me that vendors have been adding their own
> enhancements in the absence of timely standards, some/many of which may now
> conflict with the 2002 standard. They are probably unwilling to undo what
> they have done and lose upward compatibility. Of course they could do it by
> adding more compiler options.

How soon are you retiring ? :-) In all probability your statement about
implementation is correct, plus the enhancements. From your perspective
writing utilities, as a hobby, and perhaps you want to market - purely
aimed at (a) Procedural COBOL or (b) the Web-world which implies
OO-ing/GUI-ing/Web-ing.

Just to take OO alone :-

- IBM - not much bothered; they provide the basics for generating OO
COBOL classes BUT, in Enterprise, "MyClass inherits from JavaBase" -
Java being responsible for creating/destroying objects - auto garbage
collection. Will IBM ever implement the TR(Technical Report) on
Collections/Dictionaries - why should they, there's a another version of
that in Java.

- Unisys - noticed any hint from Chuck that they are interested ?
- HP/Compaq - ditto
- Liant (RM/COBOL) - ditto
- Acu COBOL - ditto
- Realia - ditto
- Fujitsu-Siemens - I'm reasonably sure Karl is interested, seeing as he
keeps a watching brief on comp.lang.object.

- Fujitsu - Possibly closet to what became 2002 - they came in after
IBM,(Visual Age), Hitachi and Micro Focus already had taken a crack
based on the early musings (around '96) before COBOL 2002 became a
reality. I would suggest their version of collections/dictionaries is
closest to the TR(Technical Report) from J4 on lists. Still, they went
the dotNet route - so you can use any other language for lists.

- Micro Focus - (along with Hitachi) - collections/dictionaries based on
the Smalltalk model. OO certainly has the J4 2002 model, but I wont
guarantee exactly every feature, without checking - which I'm not going
to do :-). In their OO model not only can a sub-class inherit from super
class, but the sub-class can be made to inherit the Global data from
super class as well. Translation - wihout having to :-

invoke super "getTheSortFlag" returning SortFlag

Given that global copyfile feature above, you can, in the sub-class,
directly code :-

Evaluate true
when SortFlag ......
when Sortflag ......
when etc....
End-Evaluate

So before 2002 that, of several OO features, was a Micro Focus
'extension'. Now that we have 2002 that feature is still an 'extension'.

Given the references aboove to who is actually providing OO and who in
fact are currently providing colllections/dictionaries, leads me to the
question - "For whom are J4 producing the TR on Collections ?"

Clear as mud, isn't it ?

Jimmy, Calgary AB

James J. Gavan

2005-11-14, 6:55 pm

Donald Tees wrote:
> Richard wrote:
>
>
> <chuckle>
>
> Yes, I suppose it is.
>
> Donald

I LUVED it too :-)

Kellie Fitton

2005-11-14, 6:55 pm

Hi Donald,

I would like to disagree with you in regards to mighty COBOL and
the programming of GUI interFace cosmetics in the modern world...

I don't have 40 years of COBOL experience like you, but I can tell
you that mighty COBOL does an exellent and very sophisticated job,
when it comes to creating/handling/using GUI interFace applications,
the trick of cource is using some simple Win32 API's to show the
rabbit to your audience on the front end of the GUI application.

Most of the new languages today such as C, C++ and java are usually
having numerous memory leaks and freezeUps problems, when they are
handling the GUI interFace of their front end, simply because they
need to allocate/de-allocate the proper amount of memory every time
they use the Win32 API's, a problem mighty COBOL does not have, the
microFocus COBOL compiler NE handles all these tasks automatically.

As for the original question regarding the license prices for the
runTime system on a different machine, they want their customers
to shell out the amount of $1,100.00 USD for 10 licenses agreement,
even if you only need One single license for a single machine, they
can only sell out these agreements by the pack (10 licenses)...

Kellie. :--)

James J. Gavan

2005-11-14, 6:55 pm

Donald Tees wrote:
> About 90% of the Cobol code I replace, I replace not with new code I
> wrote, but with new code that was generated automatically by a tool. For
> example, I wrote 15 programs to convert data from Isam files yesterday.
> Essentially, all I did was enter the copy books into a data dictionary,
> and it produced all the conversion code, all the basic listings code,
> and all the screen update code. What I spend my time on is refinements
> and prettifying it.

Not quite the same as above, but just concentrating on COBOL files I've
had the ability to read COBOL files using a few classes for a number of
years now. (Although of course, I've since switched to SQL).

Am I bragging ? No. You might recall my being on this tack. And the
final resulted from input from three people. Firstly Will Price and the
white paper which he didn't have time to include in his first book.
Secondly Bill K. with the suggestion, "Use Record varying from "a" to
"b" depending upon "c". And thirdly, one Donald Tees with his
suggestion, "Use a fixed area for a PrimeKey". Extended your suggestion
to allow for ONE Alternate Key (fixed as well).

Then I saw an M/F user getting all screwed up over variable length
records - trying to put x"0d0a' at the end of SEQUENTIAL records so he
could signify the end of variable length records.

Based on your respective inputs above, my originals handled purely FIXED
length records - which is what I've always used. Given a little thought,
without major change it became possible to use the classes to handle
both truly FIXED and truly VARIABLE length records. I'm awaiting
confirmation that for any variable files, I haven't got any padding
characters that I can't see.

Five classes :-

- ISAM with a Fixed Primeky
- ISAM above plus ONE AlternateKey ( no dups)
- ISAM above plus ONE AlternateKey with duplicates
- Sequential
- Line Sequential
- Relative - why bother - it's basically a copy of the ISAM above, where
you provide ws-RelativeKey

So you don't want to jigger around with an existing file - contains
records for some 0.5 million customers. Basically back to Will's format
of a class dedicated to one particular file, using the copybooks again
like you are.

I thought it should be publicized to M/F users to illustrate that even
from Procedural programs you can make effective use of OO. It's not that
OO is the magic cure, just that additional flexibility, (which of course
I don't need to spell out to you).

If you want a copy I'll send it. After all you were a contributor as
part of my think tank.

Jimmy

James J. Gavan

2005-11-14, 6:55 pm

Kellie Fitton wrote:
> Hi Donald,
>
> As for the original question regarding the license prices for the
> runTime system on a different machine, they want their customers
> to shell out the amount of $1,100.00 USD for 10 licenses agreement,
> even if you only need One single license for a single machine, they
> can only sell out these agreements by the pack (10 licenses)...
>
> Kellie. :--)
>
Well young lady,

Your comments about APIs to one side - we are at least back on topic. I
could be dead wrong, but I believe I saw somebody write that M/F wanted
something like $10K up front for his particular set of coupon books.
That's why I'm interested in finding out what Judson's situation is.

It is pure GREED wanting the money up front. So Kelliie decides to
market her little API routine, the one with the car bitmap. You price it
at $50 and they now want to tack on $100 if you sell one !!!! What you
wont know is that when N/E 3.1 was introduced, and that's when the
Runtimes caused an uproar, M/F issued an Amnesty clause, something like,
"Well if you are a small user, and your product is less than $1,000 -
then OK, don't need to pay us the runtime".

But let's say Judson produces a nifty routine and at a perfectly fair
price which is $150. He now has to charge his customers $250 - using
what you say above. Judson's reaction. "Screw it !". (Well he's a
church-going Baptist, so he might just reply, "Oh deary me !" :-) )

I can't follow M/F's logic :-

- (a) Judson's "Screw it!" = Income to MF = Runtime ($100) X ZERO Sales

- (b) Now substitute, (and don't let's get into this one until we hear
from Judson) - M/F says, "We want a piece of the action, so we'll go
with 5% or perhaps 10% of your intended price :-

Income to Judson, assuming his price is $150 :-

$150 x 'n' sales

Income to M/F at 10% :-

$15 x 'n' sales

No great mathematical skills required here - it makes sense for M/F to
go for (b)

When we here from Judson, I'll provide a bit of background on, as I
understand it, how the runtimes came into play.

Jimmy

Donald Tees

2005-11-14, 6:55 pm

Kellie Fitton wrote:
> Hi Donald,
>
> I would like to disagree with you in regards to mighty COBOL and
> the programming of GUI interFace cosmetics in the modern world...
>
> I don't have 40 years of COBOL experience like you, but I can tell
> you that mighty COBOL does an exellent and very sophisticated job,
> when it comes to creating/handling/using GUI interFace applications,
> the trick of cource is using some simple Win32 API's to show the
> rabbit to your audience on the front end of the GUI application.
>
> Most of the new languages today such as C, C++ and java are usually
> having numerous memory leaks and freezeUps problems, when they are
> handling the GUI interFace of their front end, simply because they
> need to allocate/de-allocate the proper amount of memory every time
> they use the Win32 API's, a problem mighty COBOL does not have, the
> microFocus COBOL compiler NE handles all these tasks automatically.
>
> As for the original question regarding the license prices for the
> runTime system on a different machine, they want their customers
> to shell out the amount of $1,100.00 USD for 10 licenses agreement,
> even if you only need One single license for a single machine, they
> can only sell out these agreements by the pack (10 licenses)...
>
> Kellie. :--)
>

Oh, I agree that it can be done. In fact, I have an SP2 product that
works very well.

The point is, that it is no longer Cobol once you do it. It is a series
of calls to a specific os that can be done in *any* language, with
little variation in code. The code changes every time MS does, and it is
absolutely tied in to that specific OS. The major advantage of Cobol
(platform independence) is completely gone.

Once I have tied myself to a specific platform, and a specific version
of that platform, then language choice becomes far less important. I
have systems (in Cobol) that started on MPM-86, and migrated quite
nicely through all versions of DOS, WIN95, WIN98, and XPPRO quite
nicely, largely because they are in Cobol. That is a system life of
close to 30 years. I do not think Cobol is capable of doing the same
thing for the next 10 years, let alone 30.

Perhaps no language is capable of that in the current market, but I
continue to search for the holy grail. It appears, to me, that Cobol is
becoming less and less likely to fufil that vision ... it also appears
to me that MS operating systems in general cannot.

The mainframe market is quite a different place, and I am not very
familiar with it. However, I doubt that I would advise any young
programmer to take up Cobol today.

As to java, C and C++, I would not write bussiness data processing
applications in any of them.

Donald

Donald Tees

2005-11-14, 6:55 pm

James J. Gavan wrote:
>
> But let's say Judson produces a nifty routine and at a perfectly fair
> price which is $150. He now has to charge his customers $250 - using
> what you say above. Judson's reaction. "Screw it !". (Well he's a
> church-going Baptist, so he might just reply, "Oh deary me !" :-) )
>

That is not the problem. The problem is that you cannot give demo's, or
sell over the net.

*Nobody* can make money on a product that costs $100 to demonstrate.

You could not sell a *house* for $10,000, if you told each prospective
buyer that they had to pay you $100(in advance, non-refundable) to even
find out if the house existed. They look at you like you are a nut case.
The same is true for software.

This is not the dark ages. I have people I work for on a daily basis I
have never met in person. Software today is sold over the net, like it
or not, and if I cannot send code to someone to tryout, then I cannot
afford to sell it at all. Driving to each demo site so I can carry a
secret key, and ensure it is removed when done, is simply too expensive.

Donald

Peter Lacey

2005-11-14, 6:55 pm

"James J. Gavan" wrote:
>
> Peter Lacey wrote:
>
> "Earwigo again" said the earwig as it fell off the wall. What's your
> objective Peter, to prove my quote about Marilyn above was absolutely
> correct :-)

Well, no; I meant to add some of my beefs to his long, long list of
upgrades and reinstalls to hint at how kludgy and klutzy I found the
whole thing. But I did it while taking a break from editing a book on
educating kids to their maxiumum potential and failed to do it right!
>
> Ten years ago ? What were you looking at, the old DOS version or VISOC;

DOS version something or other.

> Seeing as it's you and me, two ex-Brits - did it through the on-line
> help with a search on 'COLOUR' - every conceivable reference to COLOR
> you don't need until you get a bit cute. The immediate references refer
> to options for colorizing your IDE. Take a second shot at
> Foreground-Color :-
>
> 1. This clause is available for use only with a color screen.
> 2. Integer-1 or identifier-1 specifies the foreground color of the
> screen item. The colors and their corresponding values are:
>

No, no, it wasn't that. That way of doing it was the same for several
compilers I worked with then. As I said, I can no longer recall the
issue. But whatever it was, the documentation made reference to coloUrs
in some aspect or other and I simply could not find that aspect further
defined, anywhere.

PL

James J. Gavan

2005-11-14, 6:55 pm

Donald Tees wrote:
> James J. Gavan wrote:
>
>
>
> That is not the problem. The problem is that you cannot give demo's, or
> sell over the net.
>
> *Nobody* can make money on a product that costs $100 to demonstrate.
>
> You could not sell a *house* for $10,000, if you told each prospective
> buyer that they had to pay you $100(in advance, non-refundable) to even
> find out if the house existed. They look at you like you are a nut case.
> The same is true for software.
>
> This is not the dark ages. I have people I work for on a daily basis I
> have never met in person. Software today is sold over the net, like it
> or not, and if I cannot send code to someone to tryout, then I cannot
> afford to sell it at all. Driving to each demo site so I can carry a
> secret key, and ensure it is removed when done, is simply too expensive.
>
> Donald

Yes it still is part of the problem. The 'runtime' gizmo produces a
'lock' on both the ability to market AND demo on the Web. I don't
disagree with the rest.

So if I got sufficient energy, I *could* start marketing my NDT
(Non-Destructive Testing) application which has universal appeal for any
corporation into oil/gas or chemicals. Early days of the Web, my then
end-user, had an enquiry from Malaysia. (Pretty specialized area -
because of its uniqueness - so as you can imagine there aren't too many
competitive products around. Last time I went Web searching there
weren't any - some 12-18 months back). The application doesn't do
anything clever, just that it is designed to a set of rules.

So I want to market the product. And just like you are suggesting, at my
tender years I'm not a happy camper about collecting frequent flyer
points - I really don't much care for any traveling - other than
inhaling the beauty of the Rockies about 45 minutes from home. I'm
talking about our Kananaskiss Provincial Park, not 'touristy' Banff.

So if I can post a demo to the Web ( BIG 'IF'), hopefully say our
Chinese oil/gas friends, as a result of a Web search would pick up on
'NDT'. I could be wrong but I think it would be totally impractical to
demo it from the web site. They would want to download it and test it
locally. BUT - the bloody 'runtime' problem all over again. (And we
haven't even talked about the license keys).

Just like when a union negotiates on behalf of its members with the
owners, nobody gets the whole cake; there has to be compromise.

One problem is that Micro Focus doesn't trust its customers. It's a
minority, but a little justification for that. Remember Richard rapping
a Frenchman across the knuckles because the man complained he couldn't
somehow produce a distributable executable from University Edition,
which had cost him the grand sum of $100. So they have put in hurdles
which are bloody annoying to the majority.

Just imagine, your Inco application, (the truck drivers logging in their
loads). You find out some mysterious outfit in Tennessee is using your
Inco software. You would be a little more than pissed. Point of interest
- do you protect your own software with some 'trigger', 'encryption
device' or whatever. Given the resources (people) they have, surely M/F
could come up with something just as effective but less kludgey ?

Jimmy

James J. Gavan

2005-11-14, 9:55 pm

Donald Tees wrote:
> Kellie Fitton wrote:
>
>
>
> Oh, I agree that it can be done. In fact, I have an SP2 product that
> works very well.
>
> The point is, that it is no longer Cobol once you do it. It is a series
> of calls to a specific os that can be done in *any* language, with
> little variation in code. The code changes every time MS does, and it is
> absolutely tied in to that specific OS. The major advantage of Cobol
> (platform independence) is completely gone.
>
> Once I have tied myself to a specific platform, and a specific version
> of that platform, then language choice becomes far less important. I
> have systems (in Cobol) that started on MPM-86, and migrated quite
> nicely through all versions of DOS, WIN95, WIN98, and XPPRO quite
> nicely, largely because they are in Cobol. That is a system life of
> close to 30 years. I do not think Cobol is capable of doing the same
> thing for the next 10 years, let alone 30.
>
> Perhaps no language is capable of that in the current market, but I
> continue to search for the holy grail. It appears, to me, that Cobol is
> becoming less and less likely to fufil that vision ... it also appears
> to me that MS operating systems in general cannot.
>
> The mainframe market is quite a different place, and I am not very
> familiar with it. However, I doubt that I would advise any young
> programmer to take up Cobol today.
>
> As to java, C and C++, I would not write bussiness data processing
> applications in any of them.
>
> Donald

Where do I start ? In a sense COBOL could have been the Holy Grail.
Although in a practical terms there is always room for a Holy Grail Mk
II; no innovation stands still in time. Bearing in mind when COBOL was
first introduced we were only talking Big Iron. And to suit your needs,
the Standards were set and still are obsessively operating system
independent. Individual vendors get around problems using the Standards
qualifier, 'this function is implementor defined'. Fine if they all
produce parallel processes with identical results.

But much of the 'implementor defined' stuff is done with an eye to each
individual vendor recognizing specific OS. Take COBOL file handling; we
have ISAMs with and without a secondary index file; two that have a
separate index are M/F and R/M; there maybe others. Each vendor stores
binary data as they see fit, which requires us, for the most part, to
use a data convert package to get from Compiler A to Compiler B. Who
knows, perhaps back in the early days if each file had contained a COBOL
STANDARD Header Record it could have indicated both, which COBOL
compiler the file was initially opened with and even the Operating
System it was intended for use with. Hindsight perhaps - but I doubt it
would have been unsolvable.

Like me, you must have observed over the years in this Newsgroup, that
while IBM does provide file handling, there are so many features which
are Big Blue oriented as opposed to COBOL; COBOL maybe the major
language on IBM machines, but as Rhett said, "Frankly my dear. I don't
give a damn". Just so long as you buy their big iron, they aren't fussy
which language of theirs you use. I get the impression their OS routines
appear to be designed to cover them all.

GUI-ing/Webbing an absolute must in the last quarter of the 20th and
certainly needed for the 21st century onwards. Again hindsight as
regards the Standard. Just double-checked from my OOP Language book -
Smalltalk's inception was 1971 - 80 eventually arriving at Smalltalk 80.
As the book says, "Smalltalk was born as a simulation language, along
the lines of Simula (a qualified specialized enhancement to ALGOL)".
Smalltalk even finished up as the OS for the Dynabook and other
computers. "When the folks at Apple Computer stopped by Xerox PARC (Palo
Alto Research Center) to see Smalltalk, they were impressed. They took
the idea of a GUI and scalable typefaces with them, but didn't grasp
the power of object-oriented programming at the time. The ex-Xerox PARC
people who founded Adobe Systems came from Smalltalk, where the concept
of scalable typefaces was prototyped".

What could have been... I suspect the mainframers (vendors) who really
had control of computing through the sixties, probably looked at the
'desktop' approach with amused contempt. Hindsight again; if they had
taken off the blinkers and seen the potential of Smalltalk and object
orientation..... They weren't the only ones; the CEO of Xerox was amused
when the PARC team did a presentation and included a funny little thing
called a mouse.

Quite conceivably, COBOL could have been the de facto language,
PROVIDING it had included OO. Run up against some new concept, and OO
would have been the way to take on the challenge. Some bright team comes
up with something like an OO database - just hang it on to the COBOL
package via an OO interface.

If only.... - much, much too late now and competitors spring up all over
the place challenging with new concepts devoted to OO. Meanwhile, back
at the ranch, J4 have their TR on XML to be introduced in 2008 (?).
Much, much too late. A number/plenty of COBOL programmers have been
doing XML for a number of years now with other tools.

As I suggested earlier - perhaps COBOL could have been the Holy Grail,
subject to the qualifiers I've covered above.

PS: It's like pulling a bloody hen's teeth :-

>As to java, C and C++, I would not write bussiness data processing
> applications in any of them.

EXACTLY which language are you using :-)

Jimmy

Herwig Huener

2005-11-15, 7:55 am

2005-11-15 11:30:00 MET

"James J. Gavan" says:

> ...

> I don't know what these 'Open Source' people are doing. The whole thing
> has been going on for years now. In a practical sense I don't see how a
> group of volunteers can ever compete with commercial vendor products.

They can. GNU and Linux show that. But, in the COBOL-World, a
talented programmer soonly realizes that he/she could be paid for work.
Some people kill for money. The less daring ones write COBOL-compilers.

Now, approaching the end of my professional career, I realize that I have
done too much programming just for the fun of it.

Herwig

Judson McClendon

2005-11-15, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
> Judson McClendon wrote:
>
> Judson,
>
> I am more than sympathetic to your comments and started a reply - just got
> too bloody long winded. So scratched that approach.
>
> Being a retiree, I haven't gotten into runtime fees, although I did see
> somebody quote a figure which made me shudder.
>
> So let's get a little specific before I respond to your message. Your
> particular case, exactly what are the runtime fees in DOLLARS. For example
> you produce some utility for $50,(intended to have widespread appeal; not
> just COBOL users perhaps - a 'Component' if you like). Or we'll say
> applications for $500, $5,000, $10,000 etc. Exactly what are the runtime
> fees you are being asked to shell out for based on your own intended
> end-user price ?

Sorry for the delay, Jimmy. My sales rep at MF (Lindsay Dodd) is "out of the
office 11/14 thru 11/16."
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

Judson McClendon

2005-11-15, 6:55 pm

Thanks for the feedback everybody.

From the responses here, looks like MF has pretty well dumped the small
COBOL user, and vice-versa.
--
Judson McClendon judmc@sunvaley.com
Sun Valley Systems http://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."

----- Original Message -----
From: Judson McClendon
Newsgroups: comp.lang.cobol
Sent: November 12, 2005 09:45
Subject: Is Micro Focus doomed?

I feel very strongly about this issue, and I wanted to see how you other
COBOL users feel about it.

Chuck Stevens

2005-11-15, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:QMcef.499616$oW2.472667@pd7tw1no...

<< Meanwhile, back at the ranch, J4 have their TR on XML to be introduced in
2008 (?).

A quibble. The TR for XML is applicable against the *current* standard, and
it is expected that it will appear before the next major revision to that
standard (expected in 2008); WG4 has requested that it *also* be
incorporated into the draft of that standard once the TR is approved. One
of the reasons it's being done as an ISO/IEC TR rather than a simple
INCITS/J4 document is so that it *can* go through the international review
and approval process independently of, and with any sort of luck complete
well before, the processes associated with the production of the 2008
standard are all done.

-Chuck Stevens

James J. Gavan

2005-11-15, 6:55 pm

Chuck Stevens wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:QMcef.499616$oW2.472667@pd7tw1no...
>
> << Meanwhile, back at the ranch, J4 have their TR on XML to be introduced in
> 2008 (?).
>
> A quibble. The TR for XML is applicable against the *current* standard, and
> it is expected that it will appear before the next major revision to that
> standard (expected in 2008); WG4 has requested that it *also* be
> incorporated into the draft of that standard once the TR is approved. One
> of the reasons it's being done as an ISO/IEC TR rather than a simple
> INCITS/J4 document is so that it *can* go through the international review
> and approval process independently of, and with any sort of luck complete
> well before, the processes associated with the production of the 2008
> standard are all done.

Well, I knew you would probably make some comment :-)

Really the point I was making, and it goes back to my comments about an
awareness of the significance of Smalltalk, *IF* COBOL is to survive at
all, there has to be an awareness of what's going on around us; as we
are primarily down to Vendors now on J4, I don't expect each member to
have a complete hands-on to all aspects of programming. Each
representative anyway will lean towards topics that they are comfortable
with. But as back-up to what you folks are doing, I'm sure each vendor
has a 'boffin cell' - brilliant thinkers who have to be kept 'tamed'.
Perhaps you keep them in a locked room, throw in the occasional bunch of
bananas until they release a brilliant thought. Frivolous if you like,
but I'm sure you understand what I'm getting at.

It's a bit like my local fire hall (fire station); the bell goes and
either the fire vehicles or the EMS teams, or both, jump into action.
Apparently some years ago, having had a fire hall burn down in their
absence, the alarm system now automatically shuts off their cooking
equipment. We know that to relieve their boredom they have become quite
dab hands at cooking.

Their response has to be 'tout suite', no time to deliberate whether or
not they should or should not go, or which route. Now you can't get to
that ultimate but as a policy I think you have to get as damn close as
you can.

Whether our old "J4" teams had such awareness I don't know. I recall
Warren (Simmons) once writing, that asked about OO, Grace Hopper
responded, "Oh is that what you mean by OO. Well we've always had that
in COBOL". Absolutely untrue - seems our 'Gracie' missed the significance.

Jimmy

James J. Gavan

2005-11-15, 6:55 pm

Judson McClendon wrote:
> Thanks for the feedback everybody.
>
> From the responses here, looks like MF has pretty well dumped the small
> COBOL user, and vice-versa.

I can wait patiently for your response on dollars. On above I can
understand your irritation. At face value it might look so, but I hope
not. Difficult to gage who is who, but apart from some small software
houses ( say 6 to 8 people), I get the impression that most who use the
Forum are loners like you and me. Given a team of 6 to 8, some of the
query stuff can be sorted out after discussion between their local peers.

If you are right or wrong on above, proof is in the eating of the
pudding - let's see the reply you get when you submit to the top of the
Christmas tree.

Jimmy

Russell

2005-11-15, 6:55 pm

To several posters - WHICH language are you using now? It needs to
be something that a Cobol programmer can respect, without breaking Vegas.
something that can be used for Business logic, and maintained.

2005-11-15, 6:55 pm

In article <Xns970F880907933rws0203comcastnet@216.196.97.131>,
Russell <rws0203nospam@comcast.net> wrote:
> To several posters - WHICH language are you using now?

COBOL... oh, did you mean 'off work hours'? I don't code much then.

DD

Michael Wojcik

2005-11-15, 6:55 pm

In article <F25ef.167$Y82.9@bignews4.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> writes:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:
>
> It isn't really two topics, Jimmy, they're intimately connected: In order to
> implement the runtime licensing, MF requires that their crummy license
> enforcement software be installed on the client's computers. You have one,
> you have the other.

That's not entirely true. In order to *enforce* runtime licensing,
you need license-enforcement software. However, there's a large body
of thought - which I find plausible - that unenforced runtime
licensing (aka "advisory licensing", or "nagware") provides equivalent
business benefits without the problems of license enforcement.

Unenforced runtime licensing notifies the customer when they exceed
their allotted licenses, but the software continues to work.

Enforced licensing has well-known problems. It's a security risk (for
example, it opens the product to simple denial-of-service attacks).
It penalizes honest customers. It impedes disaster recovery. And
perhaps most importantly, it fails to do what it's supposed to do,
because the work factor for bypassing runtime licensing simply cannot
be made very large, without thorough hardware support (like the DRM
platforms being mooted for Wintel machines).

There are a number of products which have successfully used unenforced
runtime licensing. There's even at least one Micro Focus licensed
option which uses unenforced runtime licensing: the MTO option for
Enterprise Server. (I had to double-check to be sure this was
spelled out in the product documentation - didn't want to give away
any secrets. But it's there, in the explanation for message
CASKC1001W, which is the warning issued to the CAS console when the
number of licenses is exceeded: "The system will continue as normal".)

I do not, of course, make decisions about licensing for Micro Focus,
and - while I certainly appreciate the sentiments you and others have
expressed in this thread - I think it's a complex matter central to
our business practices, and I wouldn't want to draw any conclusions
about it without doing thorough research. However, I do believe that
the specific problem of enforced runtime licensing has been avoided
successfully by a number of companies, and so I agree with Jimmy that
it should be treated as a separate issue.

--
Michael Wojcik michael.wojcik@microfocus.com

Some there are, brave, high-souled fellows, who could borrow the world to
play at ball, and never feel the responsibility, whereas others are uneasy
and not themselves with a single shilling that does not belong to them.
-- Arthur Ransome

James J. Gavan

2005-11-15, 6:55 pm

Russell wrote:
> To several posters - WHICH language are you using now? It needs to
> be something that a Cobol programmer can respect, without breaking Vegas.
> something that can be used for Business logic, and maintained.
>
Russell,

I'd like to know too.

In fact, it really doesn't much matter which language. (I've referred to
it before, I put Wang word processor macros together to help automate
typing purchase orders for typists - not data entry clerks. I could also
put those macros to work to read your file of purchase orders and
produce a summary report, say some six lines by category. Beautifully
typed, (Wang had the old style typewriter 'crescent shaped' set of keys
which 'jumped up' and put the character image on the paper). Only one
snag - you had to leave the machine on overnight to produce that report
after some 8 hours processing :-). Literally you saw the documents on
screen and the cursor trundling across each page, character by character
as it followed the instructions in your macros. (Example - suppose all
you were interested in was the $ total for the purchase order - starting
at the very top of each document it worked its way down, character by
character, until it got to your Total field - purely from vague memory,
having got what you wanted you could then close that document and bring
up the next).

But I think you might be in a plus, plus situation if your schooling
first taught you COBOL. The formalized approach assists you in thinking
in a business sense.

I don't think anything more up to date has come out since Thane's "Teach
Yourself COBOL in 24 Hours". Given that you are interested in
programming, then going through his book step by step gives you an easy
coverage of the different topics. However like so many texts, while it
does produce examples, it can't cover every contingency. For example,
without checking the text, I don't know if Thane spelled out the
difference between SEQUENTIAL and LINE SEQUENTIAL.

But given the basics, then actually getting into the real world and
trying, you find you missing pieces.

So what I'm suggesting is, with that disciplined COBOL background,
firstly familiarizing yourself with the new language you are using, and
applying the COBOL common sense approach, ANY language should not be an
obstacle to a COBOL programmer. (It doesn't much work out in the
opposite direction - once tried to talk to some comp.lang.obj people
about use of FACTORY in COBOL - firstly astounded that COBOL had OO and
secondly they hadn't a bloody clue in understanding what I was asking).

I think that if you get into a specific language group the questions and
answers, for the most part, tend to be resolved so far as that language
is concerned.

Now impressions of comp.lang.obj - regulars who jump in giving advice in
the abstract, sometimes with some suggested solutions in Java or C. The
background of the regulars ? Are they academics, do they publish books
to make money or do they *really* program to make a living - big
question. I don't go there frequently, but viewing some of the questions
asked and the answers given, I think, "What's the big deal ? That isn't
a problem in OO COBOL which is just an extension, (modified concepts),
of Procedural).

The one thing that can be said about those other Newsgroups is that they
do stay on topic. Something titled "Is Micro Focus doomed ?" doesn't
contain a reference to "Which Language are you using ?" :-). That's why
I don't come here often, it gets too time consuming. But I agonize about
Judson having to make a decision.

Now whether or not you stay a 'loyalist' to COBOL or jump off to C#,
Java or Linux - that's your choice.

Jimmy

Judson McClendon

2005-11-15, 6:55 pm

"Michael Wojcik" <mwojcik@newsguy.com> wrote:
>
> ... and so I agree with Jimmy that
> it should be treated as a separate issue.

Philosophically, they may be two issues, but we're specifically discussing
Micro Focus runtime licensing here, and the fees and the software
enforcement come in the same box. They are *not* two issues for Net Express
users, they are simply two attributes of the same issue, because when I
accept one, I get the other.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://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."

James J. Gavan

2005-11-15, 6:55 pm

Michael Wojcik wrote:
> In article <F25ef.167$Y82.9@bignews4.bellsouth.net>, "Judson McClendon" <judmc@sunvaley0.com> writes:
>
>
>
> That's not entirely true. In order to *enforce* runtime licensing,
> you need license-enforcement software. However, there's a large body
> of thought - which I find plausible - that unenforced runtime
> licensing (aka "advisory licensing", or "nagware") provides equivalent
> business benefits without the problems of license enforcement.
>

Good on you Michael for so diplomatically jumping in. As you wrote, you
checked the feature wasn't TOP SECRET, ensuring it was in the
documentation for Enterprise Server.

The License keys business has been a pain in the butt for years, getting
mentioned here rather than in the Forum. That 'reminder' approach
appeals to me. And without giving away your own secrets, would be nice
if there was a demo program in Net Express where we could do the same to
protect our own generated software. Still if the 'reminder' is triggered
on the end-user's machine and they have to come back to the developer to
ask....? Perhaps, killing two birds with one stone, both you (M/F) and
we developers would be covered ?

The runtime issue - I can't be sure; I don't think it was "M/F"
generated, that is the "old" M/F started by the co-founders, nor the
"new' M/F which started out privately in the West Indies, (Bahamas ?),
and having checked in the last couple of days, see it has now gone
public with updates on share values.

I don't recall their name so I'll call them ABC Corp - the other half of
what became the Merant disaster. As somebody once wrote "They (ABC) were
only interested in milking the "old" M/F for all it was worth", perhaps
even cutting back on product development. I hope I'm right and it is not
our former group of old and now current M/F employees - but my
suspicions are that ABC is the guilty party. So with the "new" M/F,
perhaps a re-think, compromise and resolution ?

Jimmy

Donald Tees

2005-11-15, 6:55 pm

James J. Gavan wrote:
>
> EXACTLY which language are you using :-)
>
> Jimmy

At the moment, I am using a product called Clarion 5. It is a 4gl code
generator, with the underlying language being Modula 2.

Donald

HeyBub

2005-11-15, 6:55 pm

Russell wrote:
> To several posters - WHICH language are you using now? It needs to
> be something that a Cobol programmer can respect, without breaking
> Vegas. something that can be used for Business logic, and maintained.

Well, we use Fujitsu COBOL. No runtime fees.