MicroFocus! Me so angry?
The Twitcher
some information about licensing from MicroFocus....
I think I am not so happy?
The info tells me that I need to have a license when I want to ship
our Payroll-system to our customers.
The application is created with NetExpress!
If we do need to license all our customers: I hope business gets worse
for MF!
If not: try to explain my misunderstanding...
Anyone having a good idea what to use instead of MF? Please let me
know!
Thanks, Twitcher
Gloria De Dionigi
> The info tells me that I need to have a license when I want to ship
> our Payroll-system to our customers.
Hi Twitcher,
I' don't know NetExpress but I think (unfortunately)
that you've not misunderstood !
I use Acucobol and it's the same.
RM COBOL it's the same.
And so on.
Gloria.
Peter E. C. Dashwood
I did years ago and have not regretted it. Superb product and no license
fee...
Pete.
Gloria De Dionigi <dedi...@luigitosi.com> wrote in message
news:afh5sk$1jn$2...@newsreader.mailgate.org...
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
qIroS
I think this changed between NE 3.0 and NE3.1 IIRC, 3.0 had freely
distributable runtime whereas 3.1 does not.
If 3.0 is good enough for your needs, try using that.
Grinder
"qIroS" <qI...@tlhIngan.co.uk> wrote in message
news:102526347...@doris.uk.clara.net...
MicroFocus/Merant would be the ones to ask, but it's my understanding that
there is/was a licensing fee for the 3.0 runtime. It was, however, not as
aggressively enforced.
Richard Plinston
> >
> > I think this changed between NE 3.0 and NE3.1 IIRC, 3.0 had freely
> > distributable runtime whereas 3.1 does not.
>
Merant is no longer the one to ask, they sold it and it is now
MicroFocus again (with new owners). Actually Merant was _never_ the one
to ask as the sales staff (that I talked to) were/are completely
clueless about the actual licencing terms (and the products), the only
bit they understood was where money had to be paid.
> but it's my understanding that
> there is/was a licensing fee for the 3.0 runtime. It was, however, not as
> aggressively enforced.
From MF Cobol/2 1.x until NE 3.1 and including derivitives such as
Microsoft Cobol 4.x and 5.x and IBM Cobol 1.x, it was possible to build
a distributable executable with no run-time fee. The licence to do this
was in the manual and it specified what features could be used. Some
additional features, if used, would require that a run-time licence be
obtained for the client.
Even though it was clearly stated in the manual, and on some sales
brochures that 'free runtimes' could be distributed, the sales staff
denied this, claimed that it did not apply, stated it had been
superceeded and said it was wrong, and you must buy from them.
I understand that at NE 3.1 it has finally been removed and run-times
are required per user. However it was agreed that the standard 10 user
site run-time could be 'split' and it was not necessary to use a 10 user
licence for each site if only one or two users needed it.
I have also been variously told that 'one user' is one instance of one
application running if they are separately started. So if Payroll and
Debtors are separate .EXEs and one user has each running in seaparte
windows on one machine that is two user licences.
I keep within the allowable 'free' licence and don't worry about
upgrading to newer versions.
Fujitsu also has a split in run-time. The standard is freely
distributable but additional features (such as multi-threading) requires
run-time fee and/or that the Enterprise edition be purchased.
Lee Unterreiner
charges
"The Twitcher" <dutch_...@yahoo.com> wrote in message
news:a68c53f0.0206...@posting.google.com...
<snip>>
dazed & Confused
debbie s.
James J. Gavan
The Twitcher wrote:
Unfortunately this is a recurring theme.
First, you have to ask yourself, why did we buy Net Express in the first
place ? Without doubt it is a superb product, but that licensing GRRRRH.
Get the e-mail address for Tony Hill their new head honcho and let him
know your views about licensing. (Just like the rest of us you say to
yourself, I paid my dues by buying a not too cheap product and then they
want to sting me for royalties).
Having asked yourself, why Net Express, then evaluate alternatives. Can
you dumb down, taking a less effective compiler, or do you want one that
closely matches. Depends what you want to program, but Fujitsu POWER COBOL
is the nearest competitor with an equal number of features. That's not
knocking compilers like Acu or R/M (Liant) etc. which still do a good job.
Whichever compiler you choose, there will be a price tag, albeit no
royalties. How much effort have you put into coding in Net Express - this
is an additional cost factor when considering a switch.
Very important - when and if you do decide on another compiler, ask the
vendor very specifically, "Which features included in the draft of COBOL
2002 will you NOT be supporting ?".
Jimmy, Calgary AB
Mike Kinasz
which make up the application server? What if all you deploy is just one
standalone EXE or one standalone standard DLL with everything statically
linked? Anybody know?
Mike
"The Twitcher" <dutch_...@yahoo.com> wrote in message
news:a68c53f0.0206...@posting.google.com...
JerryMouse
"Richard Plinston" <rip...@Azonic.co.nz>
>
> Fujitsu also has a split in run-time. The standard is freely
> distributable but additional features (such as multi-threading) requires
> run-time fee and/or that the Enterprise edition be purchased.
But even there, one has choices.
For most applications, multi-threading is no big deal. The other major item
for which Fujitsu anticipates a run-time is their fast sort. "BSort" is
installed automatically on your development machine, but "ClunkySort" is
part of your created distribution.
(This leads to the confusing situation where an application runs like a
scalded cat on the development machine, but not nearly so well when the
application is deployed!)
Anyway, for large sorts, we implemented an Active-X control from Sort
Solutions (I think is was about $60) which is as fast as the Fujitsu sort -
and has no runtime fees. Thanks to Thane Hubble for the heads-up for this
swell product.
Thane Hubbell
compiler vendors that do NOT charge a runtime fee. (Oh - and KOBOL as
well). Some past versions of MF COBOL only charged a runtime fee if
you distributed certain componants. If you use Dialog system though -
you fall into that category. Finally - even if you "Static link" -
you will have to distribute part of the runtime support files. I have
an extreme dislike for runtime fees, especially on inexpensive
software.
There was a small developer amnesty program with NetExpress 3.1 - not
sure you can quailfy but ask your MicroFocus sales rep.
"Mike Kinasz" <mki...@cbspayroll.com> wrote in message news:<7q6T8.26876$Uu2.4527@sccrnsc03>...
Thane Hubbell
and RM charge a modest runtime fee.
Coming down on the other side of the argument - didn't MF users have
the opportunity to review the license agreement before purchase?
"James J. Gavan" <jjg...@shaw.ca> wrote in message news:<3D1CDB64...@shaw.ca>...
Lee Unterreiner
"JerryMouse" <nos...@bisusa.com> wrote in message
news:0WhT8.446956$Gs.32...@bin5.nnrp.aus1.giganews.com...
>
> "Richard Plinston" <rip...@Azonic.co.nz>
> >
> > Fujitsu also has a split in run-time. The standard is freely
> > distributable but additional features (such as multi-threading) requires
> > run-time fee and/or that the Enterprise edition be purchased.
>
That was a short-time policy. All Fujitsu COBOL runtimes (for Windows)
are FREE including that for .NET
William M. Klein
require separate run-time license for the multi-threading support. They do
(I think) for some other features (certainly their "enhanced" sort, for
example)
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:3D1D5DFA...@Azonic.co.nz...
> Grinder wrote:
> > >
<snip>
Richard Plinston
> > distributable but additional features (such as multi-threading) requires
> > run-time fee and/or that the Enterprise edition be purchased.
William M. Klein wrote:
>
> It is my understanding that the most recent release(s) of Fujitsu do *not*
> require separate run-time license for the multi-threading support. They do
> (I think) for some other features (certainly their "enhanced" sort, for
> example)
"""*Production execution of ISAPI, SAF, MTS and invoking COBOL from
Active Server Pages requires the multi-threaded run-time which is
provided in the Enterprise Edition."""
If you purchase the Enterprise edition then the multi-threaded run-time
is free for distribution. With the other editions you would either have
to upgrade to Enterprise or pay for run-times.
Richard Plinston
> > >
> > > Fujitsu also has a split in run-time. The standard is freely
> > > distributable but additional features (such as multi-threading) requires
> > > run-time fee and/or that the Enterprise edition be purchased.
> >
>
> That was a short-time policy. All Fujitsu COBOL runtimes (for Windows)
> are FREE including that for .NET
The standard run-times are free with the Standard and Professional
editions (Professional includes PowerCobol). The multi-threaded
run-time is free _if_ you have the Enterprise edition (which is why I
said ..).
My understanding of the Academic edition is that it does not include a
deployment licence, so they don't get the free run-time.
The .NET deployment is:
"""NetCOBOL for .NET Deployment Fees1(per processor)
Number of Processors List Price Maintenance
1 $0. $0.
2 $1,500. $300.
4 $2,250. $450.
8 $3,250. $650.
16 $5,250. $1,050.
32 $9,250. $1,850."""
James J. Gavan
Thane Hubbell wrote:
> Jimmy - please see my post under the "Me so Hungry" thread - Both Acu
> and RM charge a modest runtime fee.
>
> Coming down on the other side of the argument - didn't MF users have
> the opportunity to review the license agreement before purchase?
>
I wont swear to it, but I think Version 3.1 'happened' before we realized there was a
'gotcha' ! So far as I am aware, having moved to V 3.1 there's no way to backtrack to V 3.0
- no royalties.
Jimmy
JerryMouse
"Lee Unterreiner" <f...@nospam.flu-ent.com> wrote in message
news:afkosj$jcs$1...@slb3.atl.mindspring.net...
Yeah, but BSort is still a per-seat license for deployed applications. Sort
Solutions (the $60 Active-X routine) is just as fast as BSort (on 3M
255-byte records, 10 byte key) and has no runtime or per-seat fee.
Paul Raulerson
and AIX, as well as for the mainframe.
Cost is about $3K per developer though.
-Paul
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message news:bfdfc3e8.02062...@posting.google.com...
Carlos Lages
Harald Cordes
> which make up the application server? What if all you deploy is just one
> standalone EXE or one standalone standard DLL with everything statically
> linked? Anybody know?
>
> Mike
It will require a licence key.
Richard Riehle
Try GNAT Ada. You can download it for free. You can do
everything you can do in COBOL, including decimal types
and Picture Editing. You can develop for Windows, Linux,
Solaris, etc and make your code portable across all of those
platforms while doing so.
I used to use COBOL. Now I prefer Ada. COBOL is still
pretty good for a lot of applications, but the compiler publishers
are determined to kill it off through their greed. The Ada
compiler publishers almost did the same thing when the DoD
demanded everything be coded in Ada. Now that Ada is free
of the DoD, things have gotten better.
Richard Riehle
Paul Barnett
manager - they are not expensive. Discuss your situation with him/her. ISVs
include this in the price they charge to thier customers. MF, like any other
company, needs revenue to fund R&D.
Run-times were chargable in Net Express 3.0 but this was not clear in the
wording of the license agreement so a run time amnesty was announced for 3.0
users.
"qIroS" <qI...@tlhIngan.co.uk> wrote in message
news:102526347...@doris.uk.clara.net...
Angel
deal with runtime royalties?
When I buy one of these books with a CD in the back containing
all of these freeware / shareware programs. Who's paying
how much royalty on that?
Grinder
"Angel" <an...@smart.net> wrote in message
news:Pine.LNX.4.21.020710...@smarty.smart.net...
> How do the code jockeys in C, Java, VB, or other compilers
> deal with runtime royalties?
I can't speak beyond Windows/Mac development, but in those cases it's rare
to see a runtime licensing fee.
Paul Raulerson
has been optimized for a lot of different platforms.
Java has no runtime royalties whatsoever.
VisualBasic has no runtime royalties.
What we need is an open source COBOL compiler, perhaps based on the gcc backend.
Of course, the problem there is that the ISAM/VSAM/DMS/whatever indexed file system isn't present there either.
-Paul
"Angel" <an...@smart.net> wrote in message news:Pine.LNX.4.21.020710...@smarty.smart.net...
JerryMouse
"Paul Raulerson" <praul...@hot.NOSPAM.rr.com> wrote in message
news:Fe8X8.90586$q53.2...@twister.austin.rr.com...
> C has no runtime license - even if it did, no one would pay it they would
just use the GCC compiler, which is excellent quality and
> has been optimized for a lot of different platforms.
>
> Java has no runtime royalties whatsoever.
>
> VisualBasic has no runtime royalties.
>
> What we need is an open source COBOL compiler, perhaps based on the gcc
backend.
> Of course, the problem there is that the ISAM/VSAM/DMS/whatever indexed
file system isn't present there either.
If royalties are an issue, that means the compiler-created software is
destined for sale or other distribution. An "Open-Source" compiler implies
one cannot charge for software created with the compiler, therefore no sale
or distribution for consideration.
"Open Source" is a litigation swamp.
Tom Morrison
<snip>
> If royalties are an issue, that means the compiler-created software is
> destined for sale or other distribution. An "Open-Source" compiler implies
> one cannot charge for software created with the compiler, therefore no
sale
> or distribution for consideration.
You need to read the open source licenses again. I think you have drawn the
wrong conclusion.
> "Open Source" is a litigation swamp.
Hasn't been so far.
Paul Raulerson
If that were true, most of the UNIX applications sold today would not be sellable, since they are created with the GNU C compiler. I
think you are mistaken here; the license applies to the compiler only, not products you use the compiler to create.
And as for open source litigation, I don't think there are any. That despite Phil Payne(ITA!) trying to raise hate and discontent
over the Hercules S/390 emulator.
-Paul
"JerryMouse" <nos...@bisusa.com> wrote in message news:0RgX8.38848$iX5.1...@bin3.nnrp.aus1.giganews.com...
>
Richard Plinston
>
> "Paul Raulerson" wrote:
> >
> > VisualBasic has no runtime royalties.
Yes it does, it is called 'Windows', users of VB programs should remit
royalties (called upgrades) to MS every year. :-)
> If royalties are an issue, that means the compiler-created software is
> destined for sale or other distribution. An "Open-Source" compiler implies
> one cannot charge for software created with the compiler, therefore no sale
> or distribution for consideration.
No. Wrong. Simply not true at all. You have been listening far too much
to the Microsoft propaganda.
"Open Source" does not imply, in any way, that there is no charge for
any software, it only implies that the source is available. This may be
charged for or may be free. Even Microsoft claims that Windows should
be considered 'Open Source' (using its own unique definition) because
the source code is available (in a very limited and restrictive way).
What you may be confused about (and MS wants you to be confused about)
is that the licence of much 'Open Source' software is the GPL.
'Open Source' may have any licence or licences that the author's decide,
just like closed source software.
If you use GPL software as the basis for you own software, _AND_ you
distribute your software, then you are restricted by that 'licence to
use' and this may make your software GPL. However, a compiler does not
necessarily make the compiled program require that it be GPLed - that
depends on the actual licence.
The author has the right to offer for his own whatever licence he
wishes. If you want some software to be not under the GPL so that you
can avoid those terms then you buy from the author(s) a different
licence (if he wishes to sell). Much software is available under the
GPL for free or under a commercial licence at a price. Borland's Kylix
for example. The Commercial Licence allows for selling your own
software with certain terms and conditions.
It is no different from non-GPL software either. For example with
Fujitsu Cobol or other there are student or academic licences which
prohibit distribution of your own compiled programs (but your source may
be freely distributed). If you want to sell executables then you must
buy a commerical licence.
>
> "Open Source" is a litigation swamp.
Complete nonsense, but what Microsoft wants you to believe.
When you obtain _any_ licence to use you are required to comply with its
terms and conditions and failing to do so results in a 'litigation
swamp' as Microsoft itself found out last year when they were sued in
France for failing to comply with a software licence which was not GPL
or 'Open Source' at all.
> If royalties are an issue, that means the compiler-created software is
> destined for sale or other distribution.
It doesn't actually. In-house users require run-times too. If a
business buys a compiler and hires a programmer the resulting programs
will not be 'for sale' or 'other distribution' but the employees using
the software will require run-times.
In this particular situation a GPLed 'Open Source' compiler will not
impose any restrictions at all.
Tim Josling
This is completely false. For example, the output of gcc can be used in
commercial closed source products. The same applied to the output of bison and
flex.
It simply depends on the T&Cs of the licence.
As for open source being a litigation swamp, I have been looking and have not
found any company that got into serious trouble from using open source
software. Even companies that have stolen open source code and incorporated it
into closed source products in violation of copyright have generally been
allowed to clean up the code and excise the open source code.
On the other hand, using closed source software has resulted in large fines
etc for companies because they could not produce the paper trail of licences
and upgrades etc etc.
Tim Josling
Richard Plinston
>
> And as for open source litigation, I don't think there are any.
There has been some, such as with MySQL. But this has been _far_ less
than litigation over proprietry software licencing.
Richard Plinston
>
> "Open Source" is a litigation swamp.
Only if you use it in the same machine as a recent Microsoft product
because the MS EULA may specifiy that you are not allowed to use GPL
software. It will be Microsoft litigating against you.
One way to avoid litigation is:
1. Obtain appropriate licences for the software that _you_ want to
use.
2. Follow the terms and conditions of those licences.
3. Avoid any contact with Microsoft. If the BSA Spanish
Inquisition cannot find you they will not be able to persecute you.
Angel
I think that what COBOL needs are ANSI-85 compilers
on the market that are about half or third the cost of whatever
current Windows operating system there is. A price on
par with various other language vendors.
And with no resell runtime license fees. It should
be as easy to get the runtime as it is to get the latest
media player on Windows. From a jack box that
pops up on the screen asking if you want to download it
from the web. Free.
Make it easy for the market to accept COBOL.
Fujitsu moved in this direction a few years ago.
They started giving away free their basic COBOL-85 compiler.
And with no resell fees for runtime.
I thought back then that they had the right idea.
I expect many took the free compiler just to tinker
around with it. But many of those will eventually come up
with profitable ideas in the future. When they start
making a profit, they will start looking around for
(and have the money for) larger compiler packages.
Where else but Fujitsu? Since they are already used
to their compiler and all.
It would boost the industry if the vendors sold their COBOL-85
compilers at a give away (loss leader) price
of $50.00 US. With no resell runtime fees.
Then sell their GUI, web, debuggers, cbl_ subroutines,
and compiler extensions, at whatever price
the market can bear.
Increasing their customer base with a low end
product, and then picking it up on their high
end products. I believe this is a strategy that
would increase dramatically vendor's profits
over the long term.
Having profitable compiler vendors is a vital
necessity for the COBOL industry.
(I'm not trying to disparage the free work
going on at sourceforge. I believe in them too.
But there has still got to be money flowing
for promoting the language.)
As I mentioned, Fujitsu went in this direction.
I expect Fujitsu to gain more profits than
their competitors in the future.
JerryMouse
"Tom Morrison" <t.mor...@liant.com> wrote in message
news:M%gX8.524$9i3.37...@newssvr11.news.prodigy.com...
I have not read the EULA for open source. Can you quote the applicable
section? I don't know where to find it inasmuch as I have no dealings with
the open source community. Buncha'
goddamn communists, if you ask me("From each according to his ability, to
each according to his need"). Nevertheless, I'm willing to be reassured.
Now here's a hoot: Some worry one consequence of the open source movement is
Micros~1's new Palladium movement. Palladium will be, at the least,
'inconvienent' for the open source community. Palladium will be part of the
OS and requires every executable to be 'signed' by a trusted entity (not
necessarily Micros~1). Each change to an open source module would, in
theory, require new signing by some trusted group. (Each computer would have
it's own permitted list of 'trusted sources.')
There's an article about Palladium today on Salon:
http://www.salon.com/tech/feature/2002/07/11/palladium/index.html?x
John Bradley
Up 'til now I have held my pen as discussions on this topic came and
went. Your's is such a thoughful and sincere appeal to vendors that I
feel compelled to respond.
I've interspersed specific comments in your text, and then followed up
with a general statement. I hope these help you and some of the
others agonizing over this issue, as well as perhaps stimulate other
vendors to throw caution to the wind and address it honestly.
news:<Pine.LNX.4.21.020712...@smarty.smart.net>...
> I think that what COBOL needs are ANSI-85 compilers
> on the market that are about half or third the cost of whatever
> current Windows operating system there is. A price on
> par with various other language vendors.
I can see how you and other COBOL developers would like this.
> And with no resell runtime license fees. It should
> be as easy to get the runtime as it is to get the latest
> media player on Windows. From a jack box that
> pops up on the screen asking if you want to download it
> from the web. Free.
>
> Make it easy for the market to accept COBOL.
No problem so far.
>
> Fujitsu moved in this direction a few years ago.
> They started giving away free their basic COBOL-85 compiler.
> And with no resell fees for runtime.
>
Yes, they did, and do.
> I thought back then that they had the right idea.
> I expect many took the free compiler just to tinker
> around with it. But many of those will eventually come up
> with profitable ideas in the future. When they start
> making a profit, they will start looking around for
> (and have the money for) larger compiler packages.
> Where else but Fujitsu? Since they are already used
> to their compiler and all.
Here's where the reality (at least for us) intrudes:
What is a "larger compiler package?" More $50 compilers? Add-on
tools? I think you partially answer this later. You hit on a key
point: After a development organization uses a compiler to build an
application, what more does it need from the supplier of the compiler?
If the compiler vendor is selling a "loss-leader" compiler, then the
answer to this question is of paramount importance. More on this
later.
>
> It would boost the industry if the vendors sold their COBOL-85
> compilers at a give away (loss leader) price
> of $50.00 US. With no resell runtime fees.
>
It would only boost the industry if the vendors were better off doing
this than they are now not doing it. If they aren't better off, then
they will simply go away, and eventually there would be no for-profit
vendors.
> Then sell their GUI, web, debuggers, cbl_ subroutines,
> and compiler extensions, at whatever price
> the market can bear.
This is a very good point. Unfortunately, we have found two things to
be true:
1. People expect add-on development tools to not cost substantially
more than the compiler itself.
2. If most of the revenue and all of the profit comes from add-on
tools, then there is no motivation to provide the compiler itself.
Just sell add-on tools to the most popular compiler(s) out there.
Save yourself the grief of developing and maintaining the compiler.
Of course the compiler vendor can attempt to prevent #2, and keep all
the opportunity for himself, but that leads to very closed systems,
which are not necessarily what is needed to stimulate the market.
>
> Increasing their customer base with a low end
> product, and then picking it up on their high
> end products. I believe this is a strategy that
> would increase dramatically vendor's profits
> over the long term.
Again, if I knew what these highly-profitable high-end products were,
I would be building them for my competitors products.
>
> Having profitable compiler vendors is a vital
> necessity for the COBOL industry.
I agree 100%.
>
> (I'm not trying to disparage the free work
> going on at sourceforge. I believe in them too.
> But there has still got to be money flowing
> for promoting the language.)
Not to mention simply paying serious attention to the technical
requirements of the language. Most, if not all, successful volunteer
system software efforts are directed at things for which you can
recruit volunteers. Unfortunately, COBOL is not very exciting to the
vast majority of compiler/database gurus, especially those with large
amounts of time to spend on volunteer work.
>
> As I mentioned, Fujitsu went in this direction.
> I expect Fujitsu to gain more profits than
> their competitors in the future.
I am sure that is their plan. It is even possible that they target a
market segment for which the plan is achievable. I'm sure they
believe so.
We (Liant/RM) are (mostly) in a particular segment of the COBOL market
for which I am certain that the Fujitsu model cannot be profitable,
ever.
We serve small to medium-sized software houses that produce COBOL
applications for sale to businesses ranging from mom & pop to F1000.
In most cases, they do not provide source code with their products.
In some cases they do, but the development groups involved in
maintaining the applications are usually from 1 to at most 10
developers.
We sell compilers for about $1,500 (list) and runtimes from $150 to
$15,000 (list) depending on platform and number of uses.
Over the 20 some-odd years we have marketed a COBOL system, we have
spent about $35-45M on R&D alone. Our total compiler revenue for the
same period has been about $20M. As you can see, we wouldn't be
around if we were only selling our compilers (even at the present
price). In fact, if we had to give something away, it would be far
more likely that we could give away compilers and still stay in
business than give away runtimes. In fact, over 80% of the R&D
mentioned was spent on runtime fixes/improvements, not compiler
enhancements.
Why do we spend so much on runtimes? Because what we are really
providing our customers is a business application deployment platform
that is stable and consistent across a changing hardware/operating
system landscape. Many of our customers have not recompiled their
application since compiling it on a DOS system or an NCR 68K Tower
system in the mid-1980's. But in the meantime they expect it to run
on every popular UNIX system and Windows NT/2000/XP, as well as
anything that comes along in the future, as long as it has a disk and
display attached to it.
So, we charge for runtimes because they are, and always have been for
us, the primary value that we deliver to our customers. The compiler
is just a tool that is used by a small group of developers to produce
their company's product that is then sold to, in many cases, thousands
of companies. It is not feasible for Liant to front-load our revenue
to target the developer and thus, eliminate runtime charges. To
reduce to price of compilers to $50 would require that we sell about
100 times as many compilers as we do now. That is about 35 times the
size of the market we now serve. We have to tie our revenue from our
customers to events that generate revenue for them. This is when they
sell their product, and we receive runtime revenue. They don't have
the money "up front", and wouldn't give it to us (or any other
compiler vendor) if they did.
I hope some of the other vendors can add their two cents worth,
because I believe that the situation is much the same there. I don't
believe that a professional grade COBOL compiler and runtime can be
built, maintained, marketed and sold as a profitable endeavor without
significant runtime revenue. This is not to say that a company can't
do this unprofitably, however. If their business model can derive
profits from other products or activities, then they can lose money on
COBOL and make it up elsewhere. Such a model may or may not make
sense, but the end result is the same, a royalty free runtime (at
least while it lasts).
Meanwhile, companies like Liant, completely dependent on COBOL
products alone for their existence, must charge for runtimes just to
survive. If the market we serve demands no-cost runtimes, they will
have to get them from someone else. This is not because we are
greedy, or arrogant, or insensitive, but because we have no business
without runtime fees.
If you, or others, can tell us how to fund a COBOL company that
provides nearly-free compilers and free runtimes that run on all
present and future platforms, I will listen.
In the meantime, thank you for your thoughtful post. I appreciate the
issues you raised.
Regards,
John Bradley
President and CEO
Liant Software Corporation
Richard
So you agree that you know anything about the subject. In fact you
don't even seem to know that 'Open Source' is not a licence, or that
there are several different licences (in fact hundreds) that are used
for 'Open Source' software - everything from 'do what you like' to
'you can't do anything without paying me'.
> I have no dealings with
> the open source community. Buncha'
> goddamn communists, if you ask me
So in spite of admitting to know nothing about the subject, or any of
its users, you pre-conceive opinions about them.
Not unsurprisingly, this is exactly the opinion that Microsoft _wants_
you to have, and you have exactly the amount of knowledge of the
subject that MS wants you to have too.
> ("From each according to his ability, to
> each according to his need").
That sounds like a Christian principle, or that of the Inland Revenue
and Social Welfare system.
If 'Open Source' is 'Communist' then Microsoft is 'National
Socialist': Fascist and Nazi. ("From each according to their ability,
to us according to our greeds").
> Nevertheless, I'm willing to be reassured.
but only if it comes from a _reliable_ source, such as Microsoft's
marketing department ?
> Now here's a hoot: Some worry one consequence of the open source movement is
> Micros~1's new Palladium movement. Palladium will be, at the least,
> 'inconvienent' for the open source community. Palladium will be part of the
> OS and requires every executable to be 'signed' by a trusted entity (not
> necessarily Micros~1). Each change to an open source module would, in
> theory, require new signing by some trusted group. (Each computer would have
> it's own permitted list of 'trusted sources.')
Palladium is only a 'consequence' of 'Open Source' in that it is the
only way that MS has found to eliminate this as competition.
With previous competitors, MS has been able to eliminate them with OEM
contracts, bundling, free software, per-box pricing and other
practices that have been found to have been illegal.
The GPL has been created to ensure that MS cannot eliminate this
competition in the way they have been doing - the courts haven't
stopped the illegal practices, but these cannot be used against GPL
software.
Now, ironically, MS is trying to use new laws to eliminate
competition, as you point out above. If Palladium becomes compulsory
by law then MS will become a 100% monopoly and competition disappears
completely (in the USA).
Of course it requires the users to buy into Palladium, the Empire's
good citizens will do so because the Emperor tells them to, and to not
do so would be 'Communist' or 'Un-American' or 'Anti-Business' or
'Anti-God' or something.
Well 95% of the world's population doesn't care about 'Un-American'
because we ain't Americans and don't want to be.
Richard
> be as easy to get the runtime as it is to get the latest
> media player on Windows. From a jack box that
> pops up on the screen asking if you want to download it
> from the web. Free.
Well actually it is not 'free' (as in freedom) and certainly not
unemcumbered. To get the latest WMP you need to accept a new EULA. I
suggest that you read this because clicking it gives up control of
your machine to Microsoft. It specifically gives them permission to
download new software that they choose onto your machine and to
'update' or 'upgrade' any software that you have and to disable any
software that is on your machine without asking you.
The only thing 'free' is that they didn't ask you to pay money to have
your freedom compromised in this way.
Registering the MS EULA in the past has given them (or their agents
the BSA) the rights to enter your property and inspect your computers
for any transgressions and also given them the right to fine you for
not being able to supply the appropriate paperwork for what is on your
machine.
Now with this new EULA that you probably didn't even notice accepting,
they don't even need to enter your premises to inspect and change the
contents of your computer.
> Make it easy for the market to accept COBOL.
Well you've helped the market accept dictatorship.
> Fujitsu moved in this direction a few years ago.
> They started giving away free their basic COBOL-85 compiler.
> And with no resell fees for runtime.
The free compiler is under a student or academic licence. Have you
actually read this licence ? Does it actually give you the right to
distribute run-times at all ?
Yes, Fujitsu commercial versions (ie paid for) do give the developer
the right to distribute run-times for free, but you seem to be
arbitralily attributing this to the free student and academic versions
as well.
> It would boost the industry if the vendors sold their COBOL-85
> compilers at a give away (loss leader) price
> of $50.00 US. With no resell runtime fees.
It may 'boost' the programmers for a very short time, but 'the
industry' is the compiler writers and they would go broke in a week.
With no compiler writers where would the programmers go ?
> Then sell their GUI, web, debuggers, cbl_ subroutines,
> and compiler extensions, at whatever price
> the market can bear.
All that would happen is that other companies would write the GUI,
Web, subroutines too and would undersell the compiler writers as they
would have no compiler losses to underwrite.
> As I mentioned, Fujitsu went in this direction.
> I expect Fujitsu to gain more profits than
> their competitors in the future.
Fujitsu uses their hardware and mainframe business to support their
Cobol development. Much of what is in Fujitsu Cobol is aimed at
supporting mainframe use, they don't need to make a profit from PC
Cobol.
Paul Raulerson
Turbo Pascal, at $49 a pop. No runtime fees, no excessive licensing. Made more than one fortune.
As for COBL compiler costs, I don't mind *either* paying a single cost for the compiler that includes maintenance, *or* paying a
small cost for the compiler and a yearly maintenance fee. I object strongly to both. Even more so when runtime costs are added in.
As for how that would work? Well, IBM doesn't charge much at all for the compiler on a mainframe, but they do get those monthly
fees. Recurring revenue is *always* the ticket to wealth. Works well, because there is more than a billion lines of currently
executing COBOL code on IBM mainframe computers...
Finally, as to add on tools, price them in tiers. Make them affordable for a single developer and
tier the price up to support really big shops. That has also worked before.
I don't honestly see the problem, except that bean-counters appear to be running the world. CEOs are supposed to listen to the
advice of CFO's, not let the CFO run the company. (*sigh*)
-Paul
"John Bradley" <j.br...@liant.com> wrote in message news:25fb80a6.02071...@posting.google.com...
Angel
Dear Mr. Bradley,
Thank you for making clear the insights you shared.
I am sorry that your R&D was not fully recouped.
By all means, do what you have to do to stay in business.
As I said, the COBOL industry is best served by
vendors making a profit. I hope you are profitable
now and in the future.
I can see your point, runtime license fees are a vital
necessity in this instance. The strategy
is a good one for your market segment. Your customers
are best served by it.
I also recognize that COBOL is the most powerful language.
It has the most function points. I can imagine
the huge costs associated with creating a COBOL compiler.
(Versus the small costs of creating a C or Java compiler.
A kid in high school could write one of those, I think.)
Thanks again for your insights. They are sobering.
I will consider them in the days ahead.
I was going to make a few comments interspersed below.
But I have decided to stop here.
Those who have read this before need not go further.
On 12 Jul 2002, John Bradley wrote:
> Date: 12 Jul 2002 14:11:51 -0700
> From: John Bradley <j.br...@liant.com>
> Newsgroups: comp.lang.cobol
> Subject: Re: MicroFocus! Me so angry? Vendors note! (long)
Angel
Thank you for your comments.
Yes, I did imply that the free compiler from Fujitsu
allows free runtimes. Thanks for the correction.
In my mind, the nuisance of having to deal with runtime
licenses might impair one's ability to sell a product
to thousands of customers. Selling is hard enough
as it is, without another reason for the customers
to just leave.
But from another post, I can see that runtime licenses
are a necessity in some markets. I stand corrected.
And your comment about Fujitsu is not making a
profit on their COBOL compiler. That is sobering,
if it is true. I would hope all COBOL vendors
could maintain a handsome profit. If they can not,
then the customers would really have incentive
to leave.
It may be that, within the COBOL industry, runtime
licenses are the nature of the beast. If that's
true, I humbly ask compiler vendors to make them
as gentle as possible. So as not to scare off
potential customers.
This concludes my comments. One need not read
the rather long post following again.
On 12 Jul 2002, Richard wrote:
> Date: 12 Jul 2002 15:24:42 -0700
> From: Richard <rip...@Azonic.co.nz>
> Newsgroups: comp.lang.cobol
> Subject: Re: MicroFocus! Me so angry? Vendors note!
>
Richard
> And with no resell runtime license fees.
You shouldn't think that, say, VB, has no run-time costs. The
run-time cost is buying Windows, or upgrading to the latest version,
plus Client licences for SQL server or for copies of Access.
The .NET CLR for C#, for example, appears to be free but using it will
result in sending money to MS at some point - for upgarding NT/2000
servers to .NET servers, or upgrading to a new version of SQL Server
that has the CLR embedded, or dumping existing Oracle or DB/2 and
replacing with MS SQL.
Compare this with, say, AcuCobol or RM Cobol where paying for the
run-times allows you to run these on the system that the _user_
chooses.
Thane Hubbell
Snipped the text - read it in the thread...
John,
Thank you for a well reasoned and thoughtful post. I want to take off
my Fujitsu and Flexus hats for a moment and put on my Joe COBOL hat,
and try to help get the two camps closer together.
I'm a COBOL programmer. COBOL is what I know and love and what I am
most productive using. Many years ago, I wanted to develop a software
product for resale - the target price, $25.00 - $50.00. I wanted to
use COBOL because of the above stated reasons. I chose a compiler
with no runtime fees because of the price point. Had there been no
such compiler, I would have not done the project or used some other
tool. (Visual C++. Visual Basic etc - No runtime fees there either).
Runtime fees are one model for revenue growth. The compiler I
presently use has a modest acquisition price and a hefty yearly maint
fee. This maint fee is another model. If the vendor provides a good
service and quality tools with reasonable updates - the customer is
more than happy to pay this fee.
The problem for me with runtimes fees is not the fact that they are
simply unfair. For my $50.00 software, I can't afford to pass along a
$150.00 runtime fee to the end user. If I want to deply as a CGI
application behind a web server, I can use PERL or Python - for a
reasonable cost - but for COBOL some vendor charge $10,000 for the
server license. This is simply unreasonable and is makes the market
self limiting. It may be entirely fair to charge a fee for runtimes -
let's look at a few models and see what I think is fair and unfair
about each:
1 - Flat runtime fee. Seems to be a fair idea. Problem is the fee
itself -- when you say fees vary from $150.00 to $15000 - that's not a
flat fee.
2 - Percentage fee - based on sales or revenue of developer
3 - Volume discount runtime fee
4 - No runtime fee
Problems with 1 are simply where one draws the line at price. It
seems crazy to only charge $10.00 to handle a high volume transaction
server and it seems crazy to charge $150.00 for some software that is
$50.00 software. However, in reality $10.00 might be the fair number.
The runtime performs the same service regardless of what I do with
it. Charging more would be like charging the kidergarden 10 cents for
fingerpaint, but for the same paint you charge Thomas Kinkade
$10,000.00. See what I mean? Its a tool - what I do with the tool
should not influence what you charge for it. From the other point of
view you can say I would have NO revenue without your tool so you
deserve to benefit from my success in a proportionate manner.
Problems with 2 are similar to the last part of 1. Is this really
fair? From either side? Some fool will come along and tell you his
software Is FREE - he is charging $10,000 for the CD Media it's
delivered on, or for support services.
3 might be a more reasonable compromise. Go ahead and charge $50.00
for 1 runtime, and $5.00 if I sell 2000 runtimes. I'm selling them
FOR YOU - so I should get a bigger cut if I sell more.
4 most attractive from the developer point of view, but as you note,
dangerous if the revenue stream does not lead to profit. My free
runtime is worthless if the company goes out of business.
Personally I think the best, most equitable method is to leave the
runtime free. Charge for support and maintenance and provide a
service based on those fees that the customer will desire and enjoy.
Happy customers keep paying their bills.
I can see both sides to the argument - and from a small developer
standpoint this is my take.
Thanks!
Paul Raulerson
You could as well deploy under AIX, which is 'free" for unlimited users on any RS/6000(PSeries) machine
you buy from IBM. You still paid IBM for that O/S, they just included the cost in the cost of the machine.
Oh, and the IBM COBOL compiler for AIX is $899 per machine, and has no runtime licensing.
In fact, IBM is a good example there, both OS/400 and AIX used to have nasty restrictive licensing, and
now they don't. IBM makes a LOT more money off both of them now.
"Richard" <rip...@Azonic.co.nz> wrote in message news:217e491a.02071...@posting.google.com...
John Bradley
I would not disagree with most of your analysis. In our own case, we
have fixed (but not flat, as you point out) runtime fees as the
default. We do recognize, and accommodate, the developer who markets
a very low-price product. In those cases, we will work with them to
establish a percentage of their product price as a royalty, or some
other scheme that fairly distributes the fruits of victory. I agree
that it is neither fair, nor feasible for someone to pay even 20% of
their product revenue for licensed, embedded technology. As far as the
cheaters go, we have to assume that our customers are out for a
win-win outcome. Of course this is not always the case, but in
general, the companies that are going to succeed in their markets are
also the ones that realize that their suppliers must stay in business
too.
The problem we have, in our market, is that there is usually very
little relationship between the number of compilers and other
development tools we sell and the ability of the customer to pay. In
other words, almost all of our customers have purchased between 1 and
5 compilers over the past 5 years, but some (our "best", needless to
say) have distributed 10,000 to 50,000 runtimes. The average customer
has distributed maybe 10. As you can see, since 80% of the revenue
comes from the 20% that use thousands of runtimes, but still only buy
a few compilers, it is difficult to come up with any kind of
development tool-only scheme for maintenance or anything else I can
think of that yields revenue necessary to stay in this business.
The dilema is that it is not our customers that pay for what we do, it
is their customers.
Any further thoughts?
John
tha...@softwaresimple.com (Thane Hubbell) wrote in message news:<bfdfc3e8.0207...@posting.google.com>...
John Bradley
Some comments below:
"Paul Raulerson" <praul...@hot.NOSPAM.rr.com> wrote in message news:<%wKX8.96080$p85.2...@twister.austin.rr.com>...
> Let me add that the single most commercially successful compiler that was ever marketed, was
> Turbo Pascal, at $49 a pop. No runtime fees, no excessive licensing. Made more than one fortune.
>
I'm not trying to claim that you can't make a profit on cheap
compilers (although I would assert that it is very unlikely that you
can have sustained and growing profit on any pure-compiler business).
In any case, I believe that the market dynamics and needs of COBOL are
not identical to those of other languages.
> As for COBL compiler costs, I don't mind *either* paying a single cost for the compiler that includes maintenance, *or* paying a
> small cost for the compiler and a yearly maintenance fee. I object strongly to both. Even more so when runtime costs are added in.
In my post to Thane, I cover why this doesn't work for us. Basically,
the number of compilers a company uses and the business they see as a
result of those compilers is almost uncorrelated.
> As for how that would work? Well, IBM doesn't charge much at all for the compiler on a mainframe, but they do get those monthly
> fees. Recurring revenue is *always* the ticket to wealth. Works well, because there is more than a billion lines of currently
> executing COBOL code on IBM mainframe computers...
You are right, the mainframe COBOL market is completely different from
ours. Almost every company that uses COBOL application has COBOL
compilers, and there is a correlation between the number of
programmers and the ability of the company to pay. In addition, the
true runtime fee for IBM is the mainframe itself. I doubt that many of
us know the P&L for their Toronto COBOL group. Having developed
several compilers for IBM over the past decades, I can assure you that
in at least some cases, the compiler offering was unlikely to be a
profit center (nor was it necessarily intended to be).
>
> Finally, as to add on tools, price them in tiers. Make them affordable for a single developer and
> tier the price up to support really big shops. That has also worked before.
>
Again, there are no "really big shops" in our market. And most of our
large customers were small when they were initially developing their
applications. How can we charge two companies, both of whom have 5
compilers, radically (like 1000:1) different amounts for their
development tools?
> I don't honestly see the problem, except that bean-counters appear to be running the world. CEOs are supposed to listen to the
> advice of CFO's, not let the CFO run the company. (*sigh*)
In my experience, bean counters always want to double the price of
everything. They can't see how you could lose more than 49% of your
customers that way. They don't seem to think very inductively. ;-)
Thanks, John
John Bradley
Lest I leave the wrong impression regarding our R&D, let clarify that
I wasn't trying to say that we didn't recoup our R&D, just that the
R&D couldn't be recouped (not to mention yield a bottom-line profit)
without much, much more revenue than that flowing from the development
tools alone. We have been fortunate to have been profitable for
almost all of our 32 year history, thanks in most cases to runtime
fees.
Thank you for giving me the opportunity to present my perspective.
John
Angel <an...@smart.net> wrote in message news:<Pine.LNX.4.21.020712...@smarty.smart.net>...
Richard
You miss the point. Yes you pay for the OS and associated services,
but you may pay a single company for all different services, or you
may pay several different companies. Where there may appear to be
'free' runtimes, it may be that there are other payments to the same
company.
> You could as well deploy under AIX, which is 'free" for unlimited users on any RS/6000(PSeries) machine
> you buy from IBM. You still paid IBM for that O/S, they just included the cost in the cost of the machine.
>
> Oh, and the IBM COBOL compiler for AIX is $899 per machine, and has no runtime licensing.
Exactly my point. The RS/6000 includes the cost of AIX and Cobol
run-times. If AIX was available for non-IBM hardware then it would
not be free. The IBM Cobol compiler (just like the Fujitsu one) is
aimed at encouraging the use of mainframe services, so IBM will
subsidise the development from its other business.
> In fact, IBM is a good example there, both OS/400 and AIX used to have nasty restrictive licensing, and
> now they don't. IBM makes a LOT more money off both of them now.
I doubt that they make a 'lot' of money from the Cobol products, but
they do make more money from upgrading the hardware to run the new
Cobol systems implemented because the runtime is free.
Richard
> Let me add that the single most commercially successful compiler that was ever marketed, was
> Turbo Pascal, at $49 a pop. No runtime fees, no excessive licensing. Made more than one fortune.
The one that sold at '$49 a pop' was version 3. This was not
developed by Borland but had been written as Compass Pascal in Denmark
(?). Phillippe Kahn took an agency for the product and packaged and
marketed it.
He could afford to sell it cheap because he had not made a large
investment in developing the product.
It was also a fairly simple product, providing little beyond a simple
editor and compiler with debugger.
What you pay for with Cobol is the professional quality 'shared access
database' and other features required by reliable business
applications.
If you wanted to do that with Turbo Pascal you had to buy several
additional products, some of which may have per user charges - such as
a professional database system.
Paul Raulerson
here, and I intend to take a good solid look at the Liant stuff this week. Mostly because you guys seem to really be interested in
the COBOL community.
I'm thinking that viewing the COBOL compiler market dynamics as fundamentally different from a platform oriented language vendor is
probably where we disagree. Yes, runtimes can go over many *many* platforms, and are a wonderful thing. They are also wonderful
sources of one time revenue.
But take a step back for a minute; what if you included the compiler with a single runtime for $50, and
did not sell standalone runtimes to run *with that specific compiler* on just that platform? Pick Windows because that is the
biggest platform for this kind of thing. Explore that idea for a minute; what the situation is now is that I have to sell a
compiler with the product, and it is going to cost me $50 per PC. That is not an unreasonable cost for a 'garage developer' in 2002,
and in fact, will lead to many sales just out of curiosity.
But even more than that, what does this theoretical COBOL compiler do for you? Well, if promoted right, and accepted by the
"community" out there, you could find yourself with de-facto data standards out there. People distribute stuff in MS Access
databases now not because it is a really cool tool, but because it is readily available.
What would guarantee that kind of stuff even more? Well, nothing would guarantee it, but if you can find an unrealized niche and
distribute the compiler for free (reserving official support for those customers who decide to pay for it directly) you could gain
an enormous advantage on the competition if and when the need arises to turn stuff developed on that free compiler into for pay
products.
You might wind up getting phone calls like:
Uh.. I developed this really cool program to maintain and calculate test scores, and the school registrar heard about it and wants
me to put the program on the schools UNIX computers. How much will it cost us to do that? ... Sure we can do that! How many users
and by the way, did you know our professional version of the compiler uses a much more robust database under UNIX? We could set
your school up with everything they need to run the program on a single UNIX host for $999, and on as many other hosts as you want
for $38.96 per user...."
Surely that is not a guaranteed way to successful realize a lot of revenue from a low cost or free compiler, but
hey, look how it worked for Java!
Richard
> Surely that is not a guaranteed way to successful realize a lot of revenue from a low cost or free compiler, but
> hey, look how it worked for Java!
What are you actually referring to here ? Java generates no revenue
at all as a compiler or run-time. There is some high end server tools
that generate revenue, but not necessarily for Sun.
With Java the revenue comes from hardware sales for servers (Sun makes
servers) and to application server and database sales.
Cobol compilers and run-times can be cheap or free, too, when they can
be supported by hardware sales (such as with IBM AIX and AS/400) or
when they provide tools to support mainframe usage (and thus expand
sales).
Sun and IBM fund Java losses because most Java application
developments mean that Sun and Unix servers are not replaced by some
Windows boxes running VB.
Microsoft funds VB and C# compilers and run-times because every new
application developed maens some Unix box gets dumped and replaced by
a Windows box (or three).
Cobol runs on anything and everything, unless it can be tied to
specific systems which will fund it then it must be charged for.
Paul Raulerson
Ever been to a Java trade show, or an XML trade show? You will find hundreds of products (perhaps thousands) built to support Java
program development or Java base products. There is even a reasonably
priced COBOL compiler that generates Java Byte Code.
And the top end Java compilers, while they still do not have a runtime fee associated with them, are not exactly cheap. Visual Age
Java is $3000 per seat, about the same cost as Visual Age COBOL.
Also, You can easily buy Borland's C compiler for about $3000K, IBM Visual Age C for NT for about $400, but Microsoft's C compiler
is really only *easy* to purchase through an MSDN subscription, which runs $3000 per *year*.
I find it difficult to believe that Microsoft is loosing money on that or subsidizing it in any way. They are sure quick enough to
charge your credit card $250 per incident if you call them. Even *with* MSDN.
I don't think IBM is loosing money on VA C either, even at $400 per seat (NT pricing).
In other words, you are making an assumption that any low cost compiler is subsidized, and that just
simply is not true. I am not even sure that is true about mainframe compilers, though I will admit it is a different viewpoint than
the PC stuff.
After all, Microsoft has a target hardware market too - any PC on the planet they can get their OS running on.
Now here is a dream:
I wish I could go to a COBOL compiler vendor and plunk down some bucks and buy a whole system, in fact, two *kinds* of systems.
The first kind of system would be for developers and have all the products I could ever want to develop COBOL software on it,
compiler, enough runtimes I could use the machine to demo software to clients, a decent editor (ISPF or a clone please!) and special
developer only support. Of course, I would have to expect that I would have to sign a special license for that, and perhaps the
software just would not run on any other machine!
The second would be a machine that is setup to run the software, or with any other options I specify, sold at a significantly higher
price and licensed to the end customer. Perhaps the software is still locked to a CPU id, or perhaps it is just licensed for that
single box and part of the sales job is to explain that clearly to the customer.
MMM- let see - my goodness! That is what you can do from IBM!!
As a PWD developer, which costs my (or my company) only a few hundred dollars per year, I can purchase hardware and big discounts
(up to 50%), most software from IBM costs me only media cost for the first copy, and 50% discount after that, and I have access to
basic technical support. (I can certainly pay for higher levels of tech support if I want it.)
For mainframe development, it costs me between $11K and $14K to get the hardware and a loan of all the software, including z/OS or
OS/390, CICS, COBOL, C, HLASM, WebSphere, HTTP Servers, and others. (Nope, they don't loose money on that deal either, that is about
what it costs, and includes a nice profit margin as well, since it includes a Flex-ES license and laptop computer to run it on. The
laptop by the way, can easily support multiple developers over a network connection.)
Now why the heck can't a COBOL compiler company do the same kind of thing? Not only would it provide real developers with a cost
effective way to get access to the right products, but it would also provide Compiler vendors with a way to support developers at a
modest profit, or at worst, in a way that is cost neutral. And it would inevitably lead to more sales of runtimes and runtime
support, as well make selling them a lot easier.
Heck, it would even be possible to do something like that using Linux, and since you know absolutely what hardware is in the
machine, what software and so forth, sell service on the doggon machine, hardware and software as well.
I can see lots of ways that would work out.
Well, enough of that, this discussion just hit one of my soapbox buttons. The world is changing very fast, and it looks to me that
what people want is a way to put a box in a closet, connect to it easily and seamlessly from the PC on their desktop, and then be
able to just forget about it.
-Paul
"Richard" <rip...@Azonic.co.nz> wrote in message news:217e491a.02071...@posting.google.com...
Angel
Very insightful comments. Thanks.
I have another complication to consider.
What about the small programmer who publishes a book?
Included with the book is a CD with one of
his $10.00 to $50.00 programs on it. The terms are "Buy this
book and get this program for free!"
(Look at how AOL made it big overnight by giving away
months of connection for free. It was a strategy that
paid off for them.)
The programmer does not know what percentage of book sales result in
an install of the software. It might be lower than 3%
for all he knows.
He does not know who actually loads the software on their machines.
(For giving it away free, he does not want to know. Read
the fine manual!)
How does one deal with runtime licenses in this case?
Vendors with a runtime license strategy place themselves outside
of this market, I believe. But they (hopefully) have a profitable
market elsewhere.
It may be that a programmer's strategy very much determines
the vendor to use.
Would it help if the COBOL FAQ had a short addition to the
vendor's section? Something like the following.
"Different vendors serve different markets. A programmer
vending low cost packages may find Fujitsu the better.
A programmer targeting platform independence may find
Liant better. Get to know your vendors, and choose
what is best for you."
Maybe a list of positives for each vendor?
An off topic concern I have is that maybe COBOL has
gotten too powerful for vendors to support profitably.
Maybe the ANSI/ISO committee should restrict themselves
to profitable enhancements only. If they do restrict
themselves, maybe they should restrict more than they
have in the past. I do not know enough about what
went on to know if this is a valid concern.
On 12 Jul 2002, Thane Hubbell wrote:
> Date: 12 Jul 2002 22:54:35 -0700
> From: Thane Hubbell <tha...@softwaresimple.com>
> Newsgroups: comp.lang.cobol
> Subject: Re: MicroFocus! Me so angry? Vendors note! (long)
>
Peter E. C. Dashwood
this thread with interest.
It is excellent when the person responsible for Company policy is prepared
to outline his reasons for that policy in an open forum. Whether I agree
with John's analysis or not, I commend his post and respect him for doing
it.
My own thoughts on the subject follow, and other comments are interspersed
below.
First off, I think we should be looking at whether there is a Market for
COBOL at all in the developing IT landscape.
I believe the useful life of COBOL will not be more than 10 years. (Note I
said "useful"...Personally, I shall be writing COBOL for the next 20 years
(hopefully) but that has more to do with love of it than actually serving
any useful purpose, or achieving something that could not be achieved more
easily or efficiently by other means.(I am assuming that even better
alternatives will appear in the next 10 years)) We are already seeing the OO
languages like Java eroding what has traditionally been COBOL's base.
The failure of the COBOL user base to embrace OO COBOL (and this has been
compounded by the dismal failure to get the standard for it released) has
probably killed any future that the Language might have had.
More and more Companies are getting out of IT development. The days of
in-house Program development shops are severely numbered. The prohibitive
development costs and consistent under-delivery of traditional IT is slowly
but surely sounding the death knell on the way we have traditionally
provided IT services to Corporates. New technologies like Component based
design, Object Orientation, Web Enablement, and effective Corporate
solutions, based on these technologies, (like SAP, Siebel, and Chordiant)
are going to render the need for Source Code based development redundant.
While many of you will not accept this picture, and believe you can keep on
doing what you have always done, the statistics are saying otherwise. Look
at advertised jobs for COBOL.
Whether we like it or not, COBOL is currently hanging by a thread.
Whatever good reasons there may be for charging a Runtime Fee (and I accept
many of John's arguments), the Market place simply cannot and will not
accept that imposition. (at least it won't long term...)
It will as long as it HAS to... If the "only game in town" for you is an
AcuCOBOL application, you will buy it and pay the Runtime Licence Fee (RTLF)
or whatever the cost of the application is. BUT you will resent having a
choice of one, will realise that your position is now an exposed one, and
will be looking for an alternative.
Having all your eggs in one basket, if your application vendor goes broke
(or retires to the Bahamas...<G>), you may have a very bad time explaining
to the Board how you got the Company into such a situation. Eventually
someone will come along with a package that has no RTLF, will offer to
convert all your existing data and "make you an offer you cannot refuse".
(Or, worse still, a directive will simply come down from Senior Management
that Corporate direction is now SAP and your AcuCOBOL application will be
migrated to the appropriate SAP module within the next 6 months...)
More below...
John Bradley <j.br...@liant.com> wrote in message
news:25fb80a6.02071...@posting.google.com...
>
> news:<Pine.LNX.4.21.020712...@smarty.smart.net>...
> > I think that what COBOL needs are ANSI-85 compilers
> > on the market that are about half or third the cost of whatever
> > current Windows operating system there is. A price on
> > par with various other language vendors.
>
> I can see how you and other COBOL developers would like this.
>
I see no relationship whatsoever between the cost of the OS (or any other
software) and the cost of a COBOL Compiler. I do see need for competitive
pricing against other language/compiler options. (As Java is free, this
makes it kind of tough for the COBOL vendors...<G>). Unfortunately, even if
COBOL was distributed free it is now probably too late to prevent the demise
of it as a useful working Language for serious development. The key to the
survival of ANY Language today is whether or not it supports the OO
paradigm. (I have explored WHY this is so at length elsewhere....see
http://www.aboutlegacycoding.com/?AURL=%2FArchives%2FV3%2FV30201%2Easp)
> > And with no resell runtime license fees. It should
> > be as easy to get the runtime as it is to get the latest
> > media player on Windows. From a jack box that
> > pops up on the screen asking if you want to download it
> > from the web. Free.
> >
> > Make it easy for the market to accept COBOL.
>
> No problem so far.
Except that it is too late...
> >
> > Fujitsu moved in this direction a few years ago.
> > They started giving away free their basic COBOL-85 compiler.
> > And with no resell fees for runtime.
> >
>
> Yes, they did, and do.
>
And I for one am grateful to them. I moved from MicroFocus when they shafted
the user base over VISOC and there were Fujitsu, just waiting for guys like
me. They have excellent OO support (did not wait for the Standard but
responded to the Market) and actually encourage and assist component
development. Those two things alone make their product worth the price, in
my opinion.
I would love to be able to implement Fujitsu COBOL development into the
Corporate environment, (especially as part of my current assignment is to
advise on tech strategy). The reason I can't do so at the moment is not a
Fujitsu (or any other vendor) problem; it is a COBOL problem. So, I have a
ludicrous situation where my personal component development is done in
COBOL, but I can't recommend it for Corporate use because there are too many
questions over the future of the Language and the availability of OO COBOL
skills. (I am hoping that we can run a pilot project if/when the right
opportunity presents itself...)
I don't know how well AcuCOBOL supports OO, but I do know that without this
facility you can kiss COBOL goodbye.
The argument runs thus:
"IT development should use the best tools for the job.
COBOL is the best tool for the job, for many aspects of commercial systems
development.
COBOL is "closed". It has its own file system and does not easily interface
to components from other languages.
Therefore we can't use COBOL."
If we use OO COBOL and avoid the COBOL file system (I use RDB through ODBC
for all file access in components), these objections are overcome and COBOL
is viable again. But now we have the RTLF problem. Before we can deploy it,
we have to solve the Runtime hassle... At least with Fujitsu, I can argue it
is free...
>
> Here's where the reality (at least for us) intrudes:
>
> What is a "larger compiler package?" More $50 compilers? Add-on
> tools? I think you partially answer this later. You hit on a key
> point: After a development organization uses a compiler to build an
> application, what more does it need from the supplier of the compiler?
Well, I believe that is a very limited view, John. Successful vendors will
build a working relationship with their customers (irrespective of the value
of the Business. Sometimes the value is in intangibles and may only be
realised some time later. It can manifest itself by something as simple as a
conversation over a few beers that can result in thousands of dollars of
revenue, from a source that could not possibly have been foreseen.)
Simply selling a compiler and going away won't cut it. I realise that in the
small end of the Market which you defined for your products, regular contact
with customers may be non cost effective, but you can address this with
technology. Get a lively User group forum running on a server you sponsor or
own. Many of the regular contributors here (self included...) started out
contributing to the MicroFocus Forum before they pulled it (they were happy
as long as everyone said nice things about their products, but got really
upset when criticisms were aired. I believe they missed a fantastic
opportunity to address user concerns, improve their products and build
invaluable goodwill. Instead, they managed to alienate some of the people
who could have done most to promote their products. I accept that the
Company today is not the Company as it was then, but the damage is done.)
> If the compiler vendor is selling a "loss-leader" compiler, then the
> answer to this question is of paramount importance. More on this
> later.
>
> >
> > It would boost the industry if the vendors sold their COBOL-85
> > compilers at a give away (loss leader) price
> > of $50.00 US. With no resell runtime fees.
> >
>
> It would only boost the industry if the vendors were better off doing
> this than they are now not doing it. If they aren't better off, then
> they will simply go away, and eventually there would be no for-profit
> vendors.
>
Yes, you are absolutely right on this. Besides, this is only viable if there
is a bright future for COBOL and that is doubtful at the present time.
> > Then sell their GUI, web, debuggers, cbl_ subroutines,
> > and compiler extensions, at whatever price
> > the market can bear.
>
> This is a very good point. Unfortunately, we have found two things to
> be true:
>
> 1. People expect add-on development tools to not cost substantially
> more than the compiler itself.
>
> 2. If most of the revenue and all of the profit comes from add-on
> tools, then there is no motivation to provide the compiler itself.
> Just sell add-on tools to the most popular compiler(s) out there.
> Save yourself the grief of developing and maintaining the compiler.
>
> Of course the compiler vendor can attempt to prevent #2, and keep all
> the opportunity for himself, but that leads to very closed systems,
> which are not necessarily what is needed to stimulate the market.
>
Agree totally. Good argument.
> >
> > Increasing their customer base with a low end
> > product, and then picking it up on their high
> > end products. I believe this is a strategy that
> > would increase dramatically vendor's profits
> > over the long term.
>
> Again, if I knew what these highly-profitable high-end products were,
> I would be building them for my competitors products.
>
Hahaha! So true...
> >
> > Having profitable compiler vendors is a vital
> > necessity for the COBOL industry.
>
> I agree 100%.
>
Sadly, I predict that probably 50% of the COBOL vendors who are with us at
the moment, will not be doing COBOL within the next 10 years. The shrinking
market cannot support them and the smaller market share vendors will be
squeezed out or will sell out to the larger market share vendors.
> >
> > (I'm not trying to disparage the free work
> > going on at sourceforge. I believe in them too.
> > But there has still got to be money flowing
> > for promoting the language.)
>
> Not to mention simply paying serious attention to the technical
> requirements of the language. Most, if not all, successful volunteer
> system software efforts are directed at things for which you can
> recruit volunteers. Unfortunately, COBOL is not very exciting to the
> vast majority of compiler/database gurus, especially those with large
> amounts of time to spend on volunteer work.
>
The Open Source COBOL movement is commendable and worthwhile, but it is of
no commercial interest. It is an Academic exercise. Until it is stable
enough and viable for major Corporates to embrace it, it will have no
credibility. Unfortunately, by the time this stage is reached the said
Corporates will no longer be interested in COBOL. Your point about gurus not
being interested is also valid.
> >
> > As I mentioned, Fujitsu went in this direction.
> > I expect Fujitsu to gain more profits than
> > their competitors in the future.
>
> I am sure that is their plan. It is even possible that they target a
> market segment for which the plan is achievable. I'm sure they
> believe so.
>
Fujitsu are a Corporate giant with fingers in many pies all over the World.
They do not rely on COBOL for their existence. However, they have shown a
commendable committment to COBOL so far and there is no reason to believe
they will not continue to do so, at least as long as they believe the
products and the spin offs are profitable to them. The argument made
elsewhere in this thread that COBOL can be seen to be a way of selling
hardware is also applicable.
> We (Liant/RM) are (mostly) in a particular segment of the COBOL market
> for which I am certain that the Fujitsu model cannot be profitable,
> ever.
>
> We serve small to medium-sized software houses that produce COBOL
> applications for sale to businesses ranging from mom & pop to F1000.
> In most cases, they do not provide source code with their products.
> In some cases they do, but the development groups involved in
> maintaining the applications are usually from 1 to at most 10
> developers.
>
> We sell compilers for about $1,500 (list) and runtimes from $150 to
> $15,000 (list) depending on platform and number of uses.
>
> Over the 20 some-odd years we have marketed a COBOL system, we have
> spent about $35-45M on R&D alone. Our total compiler revenue for the
> same period has been about $20M. As you can see, we wouldn't be
> around if we were only selling our compilers (even at the present
> price). In fact, if we had to give something away, it would be far
> more likely that we could give away compilers and still stay in
> business than give away runtimes. In fact, over 80% of the R&D
> mentioned was spent on runtime fixes/improvements, not compiler
> enhancements.
>
Isn't it true that that runtime was not just for COBOL? I understand that
AcuCOBOL generates intermediate code for cross platform compatibility
(similar to the MicroFocus .int files). Such intermediate code can be easily
adapted for other source languages besides COBOL. Not being familiar with
Liant's product range I don't know whether you offer C, Pascal, Fortran, or
similar...can you clarify?
> Why do we spend so much on runtimes? Because what we are really
> providing our customers is a business application deployment platform
> that is stable and consistent across a changing hardware/operating
> system landscape. Many of our customers have not recompiled their
> application since compiling it on a DOS system or an NCR 68K Tower
> system in the mid-1980's. But in the meantime they expect it to run
> on every popular UNIX system and Windows NT/2000/XP, as well as
> anything that comes along in the future, as long as it has a disk and
> display attached to it.
>
> So, we charge for runtimes because they are, and always have been for
> us, the primary value that we deliver to our customers. The compiler
> is just a tool that is used by a small group of developers to produce
> their company's product that is then sold to, in many cases, thousands
> of companies. It is not feasible for Liant to front-load our revenue
> to target the developer and thus, eliminate runtime charges. To
> reduce to price of compilers to $50 would require that we sell about
> 100 times as many compilers as we do now. That is about 35 times the
> size of the market we now serve. We have to tie our revenue from our
> customers to events that generate revenue for them. This is when they
> sell their product, and we receive runtime revenue. They don't have
> the money "up front", and wouldn't give it to us (or any other
> compiler vendor) if they did.
>
This is a very honest and reasoned argument. I am persuaded by it. Your
particular Marketplace DOES require you to charge for RTLF. However, I
believe this may be putting the future for you in jeopardy. See my arguments
above.
> I hope some of the other vendors can add their two cents worth,
> because I believe that the situation is much the same there. I don't
> believe that a professional grade COBOL compiler and runtime can be
> built, maintained, marketed and sold as a profitable endeavor without
> significant runtime revenue.
Oh, yes it can <G>! IBM have been doing it for 43 years. The fact is that
the revenue stream is indirect (hardware sales dependent on the compiler(s)
they are offering, and ongoing maintenance contracts). Of course, they were
selling hardware long before COBOL became generally available. The main
reason for the Conference on Data Systems Languages (CODASYL) in 1959 was
not because of the requirements of Grace Hopper and the US Navy (although
folk lore over the years has made it look that way...), it was because ALL
the major vendors realised they could get a much bigger slice of the
available Government contracts (hence the invitation to the US Navy and good
old Grace) if they could bid jointly for certain business. This meant a
cross platform capability. It was in everybody's interest and they knew it.
That is not to say that there wasn't a certain amount of genuine altruism
and desire to do something for the emerging Data Processing industry, but it
was commercial opportunity which drove the development of COBOL 59.
Ironically, it is lack of commercial opportunity which will cause the demise
of the Language. The entrenched User base (primarily in the mainframe
arena...what I call "Fortress COBOL" ) have fervently resisted the changes
that would have made the language viable in the 21st Century. The belief was
that the Market would accept what it was given as it had no choice. Wrong.
The Market has moved on (as Markets always do...) 200 million users are not
about to become computer programmers. Instead, they have demanded systems
that don't require programming. And they are starting to get them. As more
such systems are developed, the commercial opportunity for traditional COBOL
development becomes smaller and smaller.
> This is not to say that a company can't
> do this unprofitably, however. If their business model can derive
> profits from other products or activities, then they can lose money on
> COBOL and make it up elsewhere. Such a model may or may not make
> sense, but the end result is the same, a royalty free runtime (at
> least while it lasts).
>
> Meanwhile, companies like Liant, completely dependent on COBOL
> products alone for their existence, must charge for runtimes just to
> survive. If the market we serve demands no-cost runtimes, they will
> have to get them from someone else. This is not because we are
> greedy, or arrogant, or insensitive, but because we have no business
> without runtime fees.
>
As I noted above, this may mean a limited life for your Company.
> If you, or others, can tell us how to fund a COBOL company that
> provides nearly-free compilers and free runtimes that run on all
> present and future platforms, I will listen.
>
I agree. It cannot be done. It would require the following:
1. A change in the attitude of COBOL programmers. Acceptance that change is
needed and the desire to build systems in COBOL that are open and accessible
and can co-exist side-by-side with other tools and exchange data with them
easily and efficiently. (The OO paradigm achieves this...).
2. A change in the PUBLIC perception of COBOL as an archaic, outmoded,
"dinosaur development" Language.
3. A change in the MANAGEMENT perception of COBOL. It is generally perceived
as being the "umbrella" for the days when the Business had to go cap-in-hand
to the IT department and beg and plead for systems that were delivered 9
months later, cost far more than they were supposed to, and provided
functionality that was no longer pertinent to the Business Environment. Many
Managers still remember those days (most of them came up through the
Business) and it is anathema to them. When they hear "COBOL" they associate
it with Waterfall Development, under-delivery, and cost overruns. (This
isn't fair of course, but I have found from first hand discussion with many
Managers in many different Business arenas, that this is a common thread
...)
As none of the above is imminently likely, you should draw your own
conclusions as to whether it is worth staying in the COBOL Vendor business.
Finally...
My advice to COBOL vendors: Diversify. (unless you have a very profitable
entrenched base which natural attrition will take 20 years to whittle down
to the point of non-viability, OR, you are generating other revenue flows by
offering COBOL).
My advice to Client/Server COBOL Programmers: Expand your skill set. Learn
OO. (But then you probably already have, right <G>?)
My advice to Fortress COBOL people:
If you are over 35, Behave yourself...you can probably hang in where you are
for the next 10 years doing maintenance. Look for early retirement...around
45.
If you are under 35, what are you doing here?! Get transferred to the Java
or VB group...
If you are currently over 40, well, you probably didn't read this anyway,
and if you did, just write me off as a know-nothing troublemaker...take a
nap until Nursie comes to change your poultice...<G>
I have been a programmer for 37 years and a COBOL programmer for 35 years.
(I first compiled with the COBOL 59 compiler...in 1967). COBOL was my living
for over 20 years. I love the language and will write it as long as I am
able to and there is a compiler available. But what I write today is far
removed from what I wrote 35 years ago. Sadly, this is not the case in many
Fortress COBOL installations and, worse yet, the attitude is the same as it
was 35 years ago too... Today's users are not the users of 35 years ago.
They are more computer literate, they expect more from computer systems, and
they will not be treated with scorn by a superior class of "technocrats".
The Fortress has not been overrun. It has been bypassed. The "new
technology" hordes, riding lightly armed on their fast little ponies, have
simply swept past it. It will die from attrition over the next 10 years.
Unless COBOL is removed from the Fortress it will die too.
Pete.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
Peter E. C. Dashwood
More below...
> news:<Pine.LNX.4.21.020712...@smarty.smart.net>...
> > I think that what COBOL needs are ANSI-85 compilers
> > on the market that are about half or third the cost of whatever
> > current Windows operating system there is. A price on
> > par with various other language vendors.
>
> I can see how you and other COBOL developers would like this.
>
I see no relationship whatsoever between the cost of the OS (or any other
software) and the cost of a COBOL Compiler. I do see need for competitive
pricing against other language/compiler options. (As Java is free, this
makes it kind of tough for the COBOL vendors...<G>). Unfortunately, even if
COBOL was distributed free it is now probably too late to prevent the demise
of it as a useful working Language for serious development. The key to the
survival of ANY Language today is whether or not it supports the OO
paradigm. (I have explored WHY this is so at length elsewhere....see
http://www.aboutlegacycoding.com/?AURL=%2FArchives%2FV3%2FV30201%2Easp)
> > And with no resell runtime license fees. It should
> > be as easy to get the runtime as it is to get the latest
> > media player on Windows. From a jack box that
> > pops up on the screen asking if you want to download it
> > from the web. Free.
> >
> > Make it easy for the market to accept COBOL.
>
> No problem so far.
Except that it is too late...
> >
> > Fujitsu moved in this direction a few years ago.
> > They started giving away free their basic COBOL-85 compiler.
> > And with no resell fees for runtime.
> >
>
> Yes, they did, and do.
>
And I for one am grateful to them. I moved from MicroFocus when they shafted
The argument runs thus:
>
> Here's where the reality (at least for us) intrudes:
>
> What is a "larger compiler package?" More $50 compilers? Add-on
> tools? I think you partially answer this later. You hit on a key
> point: After a development organization uses a compiler to build an
> application, what more does it need from the supplier of the compiler?
Well, I believe that is a very limited view, John. Successful vendors will
build a working relationship with their customers (irrespective of the value
of the Business. Sometimes the value is in intangibles and may only be
realised some time later. It can manifest itself by something as simple as a
conversation over a few beers that can result in thousands of dollars of
revenue, from a source that could not possibly have been foreseen.)
Simply selling a compiler and going away won't cut it. I realise that in the
small end of the Market which you defined for your products, regular contact
with customers may be non cost effective, but you can address this with
technology. Get a lively User group forum running on a server you sponsor or
own. Many of the regular contributors here (self included...) started out
contributing to the MicroFocus Forum before they pulled it (they were happy
as long as everyone said nice things about their products, but got really
upset when criticisms were aired. I believe they missed a fantastic
opportunity to address user concerns, improve their products and build
invaluable goodwill. Instead, they managed to alienate some of the people
who could have done most to promote their products. I accept that the
Company today is not the Company as it was then, but the damage is done.)
> If the compiler vendor is selling a "loss-leader" compiler, then the
> answer to this question is of paramount importance. More on this
> later.
>
> >
> > It would boost the industry if the vendors sold their COBOL-85
> > compilers at a give away (loss leader) price
> > of $50.00 US. With no resell runtime fees.
> >
>
> It would only boost the industry if the vendors were better off doing
> this than they are now not doing it. If they aren't better off, then
> they will simply go away, and eventually there would be no for-profit
> vendors.
>
Yes, you are absolutely right on this. Besides, this is only viable if there
is a bright future for COBOL and that is doubtful at the present time.
> > Then sell their GUI, web, debuggers, cbl_ subroutines,
> > and compiler extensions, at whatever price
> > the market can bear.
>
> This is a very good point. Unfortunately, we have found two things to
> be true:
>
> 1. People expect add-on development tools to not cost substantially
> more than the compiler itself.
>
> 2. If most of the revenue and all of the profit comes from add-on
> tools, then there is no motivation to provide the compiler itself.
> Just sell add-on tools to the most popular compiler(s) out there.
> Save yourself the grief of developing and maintaining the compiler.
>
> Of course the compiler vendor can attempt to prevent #2, and keep all
> the opportunity for himself, but that leads to very closed systems,
> which are not necessarily what is needed to stimulate the market.
>
Agree totally. Good argument.
> >
> > Increasing their customer base with a low end
> > product, and then picking it up on their high
> > end products. I believe this is a strategy that
> > would increase dramatically vendor's profits
> > over the long term.
>
> Again, if I knew what these highly-profitable high-end products were,
> I would be building them for my competitors products.
>
Hahaha! So true...
> >
> > Having profitable compiler vendors is a vital
> > necessity for the COBOL industry.
>
> I agree 100%.
>
Sadly, I predict that probably 50% of the COBOL vendors who are with us at
the moment, will not be doing COBOL within the next 10 years. The shrinking
market cannot support them and the smaller market share vendors will be
squeezed out or will sell out to the larger market share vendors.
> >
> > (I'm not trying to disparage the free work
> > going on at sourceforge. I believe in them too.
> > But there has still got to be money flowing
> > for promoting the language.)
>
> Not to mention simply paying serious attention to the technical
> requirements of the language. Most, if not all, successful volunteer
> system software efforts are directed at things for which you can
> recruit volunteers. Unfortunately, COBOL is not very exciting to the
> vast majority of compiler/database gurus, especially those with large
> amounts of time to spend on volunteer work.
>
The Open Source COBOL movement is commendable and worthwhile, but it is of
no commercial interest. It is an Academic exercise. Until it is stable
enough and viable for major Corporates to embrace it, it will have no
credibility. Unfortunately, by the time this stage is reached the said
Corporates will no longer be interested in COBOL. Your point about gurus not
being interested is also valid.
> >
> > As I mentioned, Fujitsu went in this direction.
> > I expect Fujitsu to gain more profits than
> > their competitors in the future.
>
> I am sure that is their plan. It is even possible that they target a
> market segment for which the plan is achievable. I'm sure they
> believe so.
>
Fujitsu are a Corporate giant with fingers in many pies all over the World.
They do not rely on COBOL for their existence. However, they have shown a
commendable committment to COBOL so far and there is no reason to believe
they will not continue to do so, at least as long as they believe the
products and the spin offs are profitable to them. The argument made
elsewhere in this thread that COBOL can be seen to be a way of selling
hardware is also applicable.
> We (Liant/RM) are (mostly) in a particular segment of the COBOL market
> for which I am certain that the Fujitsu model cannot be profitable,
> ever.
>
> We serve small to medium-sized software houses that produce COBOL
> applications for sale to businesses ranging from mom & pop to F1000.
> In most cases, they do not provide source code with their products.
> In some cases they do, but the development groups involved in
> maintaining the applications are usually from 1 to at most 10
> developers.
>
> We sell compilers for about $1,500 (list) and runtimes from $150 to
> $15,000 (list) depending on platform and number of uses.
>
> Over the 20 some-odd years we have marketed a COBOL system, we have
> spent about $35-45M on R&D alone. Our total compiler revenue for the
> same period has been about $20M. As you can see, we wouldn't be
> around if we were only selling our compilers (even at the present
> price). In fact, if we had to give something away, it would be far
> more likely that we could give away compilers and still stay in
> business than give away runtimes. In fact, over 80% of the R&D
> mentioned was spent on runtime fixes/improvements, not compiler
> enhancements.
>
Isn't it true that that runtime was not just for COBOL? I understand that
AcuCOBOL generates intermediate code for cross platform compatibility
(similar to the MicroFocus .int files). Such intermediate code can be easily
adapted for other source languages besides COBOL. Not being familiar with
Liant's product range I don't know whether you offer C, Pascal, Fortran, or
similar...can you clarify?
> Why do we spend so much on runtimes? Because what we are really
> providing our customers is a business application deployment platform
> that is stable and consistent across a changing hardware/operating
> system landscape. Many of our customers have not recompiled their
> application since compiling it on a DOS system or an NCR 68K Tower
> system in the mid-1980's. But in the meantime they expect it to run
> on every popular UNIX system and Windows NT/2000/XP, as well as
> anything that comes along in the future, as long as it has a disk and
> display attached to it.
>
> So, we charge for runtimes because they are, and always have been for
> us, the primary value that we deliver to our customers. The compiler
> is just a tool that is used by a small group of developers to produce
> their company's product that is then sold to, in many cases, thousands
> of companies. It is not feasible for Liant to front-load our revenue
> to target the developer and thus, eliminate runtime charges. To
> reduce to price of compilers to $50 would require that we sell about
> 100 times as many compilers as we do now. That is about 35 times the
> size of the market we now serve. We have to tie our revenue from our
> customers to events that generate revenue for them. This is when they
> sell their product, and we receive runtime revenue. They don't have
> the money "up front", and wouldn't give it to us (or any other
> compiler vendor) if they did.
>
This is a very honest and reasoned argument. I am persuaded by it. Your
particular Marketplace DOES require you to charge for RTLF. However, I
believe this may be putting the future for you in jeopardy. See my arguments
above.
> I hope some of the other vendors can add their two cents worth,
> because I believe that the situation is much the same there. I don't
> believe that a professional grade COBOL compiler and runtime can be
> built, maintained, marketed and sold as a profitable endeavor without
> significant runtime revenue.
Oh, yes it can <G>! IBM have been doing it for 43 years. The fact is that
the revenue stream is indirect (hardware sales dependent on the compiler(s)
they are offering, and ongoing maintenance contracts). Of course, they were
selling hardware long before COBOL became generally available. The main
reason for the Conference on Data Systems Languages (CODASYL) in 1959 was
not because of the requirements of Grace Hopper and the US Navy (although
folk lore over the years has made it look that way...), it was because ALL
the major vendors realised they could get a much bigger slice of the
available Government contracts (hence the invitation to the US Navy and good
old Grace) if they could bid jointly for certain business. This meant a
cross platform capability. It was in everybody's interest and they knew it.
That is not to say that there wasn't a certain amount of genuine altruism
and desire to do something for the emerging Data Processing industry, but it
was commercial opportunity which drove the development of COBOL 59.
Ironically, it is lack of commercial opportunity which will cause the demise
of the Language. The entrenched User base (primarily in the mainframe
arena...what I call "Fortress COBOL" ) have fervently resisted the changes
that would have made the language viable in the 21st Century. The belief was
that the Market would accept what it was given as it had no choice. Wrong.
The Market has moved on (as Markets always do...) 200 million users are not
about to become computer programmers. Instead, they have demanded systems
that don't require programming. And they are starting to get them. As more
such systems are developed, the commercial opportunity for traditional COBOL
development becomes smaller and smaller.
> This is not to say that a company can't
> do this unprofitably, however. If their business model can derive
> profits from other products or activities, then they can lose money on
> COBOL and make it up elsewhere. Such a model may or may not make
> sense, but the end result is the same, a royalty free runtime (at
> least while it lasts).
>
> Meanwhile, companies like Liant, completely dependent on COBOL
> products alone for their existence, must charge for runtimes just to
> survive. If the market we serve demands no-cost runtimes, they will
> have to get them from someone else. This is not because we are
> greedy, or arrogant, or insensitive, but because we have no business
> without runtime fees.
>
As I noted above, this may mean a limited life for your Company.
> If you, or others, can tell us how to fund a COBOL company that
> provides nearly-free compilers and free runtimes that run on all
> present and future platforms, I will listen.
>
I agree. It cannot be done. It would require the following:
Clark F. Morris, Jr.
C run-time is a part of the base LE sub-routines that come with the zOS
operating system. The main difference is that basic COBOL file types
(sequential, direct and random) are supported in the base operating
system.
The problem for the end user and the vendor comes when there is more
than one application depending on COBOL run-times. Both have to be at
the same level or the more recent level has to support applications
written to the prior level. This has been a rigorous target for IBM
(and probably other mainframe vendors such as Unisys). I can't comment
on the PC world. There is also the problem that Vendor X COBOL can't
use vendor Y's runtime.
The two thorny and complex issues in the PC world are how to handle
licensing and support of run-times when the same organization obtains
application packages from two different vendors requiring the same run
time and how should support of two different run-times be handled on the
same system?
How are these issues handled for packages written in C/C++?
Paul Raulerson
Anyways, in the PC world, applications that include a runtime typically load the runtime files in a particular PATH, and then ensure
the application is ran with the correct PATH setting to ensure the appropriate runtimes are loaded first.
UNIX applications often do the same thing. In fact, the IBM COBOL and IBM C++ compilers for AIX have to play that trick, since the C
runtimes overwrite some older COBOL runtimes. For things like VASM look-alike filesystems, a server daemon is usually ran.
It can certainly get a lot more complex than what I described above, especially under UNIX, but good system admins (= mainframe
SYSPROGs) can usually keep that kind of nonsense to a minimum.
-Paul
"Clark F. Morris, Jr." <cfm...@istar.ca> wrote in message news:3D32C165...@istar.ca...
Richard
> If you are under 35, what are you doing here?! Get transferred to the Java or VB group...
The problem with Java and VB is that they are 'language de jour'.
Algol, Algol-68, PL/1, Pascal, Modula-2, Oberon, Ada, C, C++,
Objective-C, C#, VB, Java.
What will they be doing next year ?
Certainly there is momentum behind Java, and C# will attract a
following amongst those who will use anything with the Microsoft
brand, but most languages have gone through a cycle of around 15 years
or so before they become marginal.
Rick Smith
wrote, of Sir Earl Popper;
"In the field of social and political philosopy, Popper is best
known for his critique of historicism, particularly as exemplified
by Plato, Hegel, and Marx. This is the doctrine that there are
laws or principles of historical development, mastery of which
would enable us to predict the course of human history, much
as the astronomer predicts eclipses. In Popper's view
predictions are only possible for systems that are
'well-isolated, stationary, and recurrent' ('Conjectures and
Refutations,' 1974 edition, p.339) and this does not, and
could not, hold of human society, where among the major
factors determining development are our own decisions
about how to respond to our situation. Thus, for example,
the technology that has become such a powerful influence
on contemporary society could not even in principle been
predicted a century ago. For Popper the choice and
responsibility have to remain with individuals; we can never
have sufficient grounds for saying, 'Society must develop
thus, whether its members want it so or not.'"
Within the 'society' of computer programmers we make
"our own decisions about how to respond to our situation."
While Popper suggests that one should not make
predictions of the future in such societies, it is nonetheless
true that had one predicted the demise of numerous
"COBOL-killer" languages; such predictions would have
had more success than predictions of the demise of
COBOL.
COBOL is somewhat unique in its orientation toward the
expression of most business problems. Wulf (as quoted
in other threads) said "the nature of language shapes
the ways in which we think about problems." COBOL is
well-suited to thinking about solutions to business problems.
Peter E. C. Dashwood <dash...@nospam.enternet.co.nz> wrote in message
news:3d32c...@Usenet.com...
[snip]
>
> My own thoughts on the subject follow, and other comments are interspersed
> below.
>
> First off, I think we should be looking at whether there is a Market for
> COBOL at all in the developing IT landscape.
As long as business exists there will be a market for COBOL.
The question is how often people in "our situation" will decide
to use COBOL. That determines the size of the market.
> I believe the useful life of COBOL will not be more than 10 years. (Note I
> said "useful"...Personally, I shall be writing COBOL for the next 20 years
> (hopefully) but that has more to do with love of it than actually serving
> any useful purpose, or achieving something that could not be achieved more
> easily or efficiently by other means.(I am assuming that even better
> alternatives will appear in the next 10 years)) We are already seeing the
OO
> languages like Java eroding what has traditionally been COBOL's base.
This depends a great deal on one's definition of "what has
traditionally been COBOL's base." I define COBOL's base
as batch processing. That is because standard COBOL has
no interactive capability. While it is possible to run batch Java
programs, that is not its strength.
> The failure of the COBOL user base to embrace OO COBOL (and this has been
> compounded by the dismal failure to get the standard for it released) has
> probably killed any future that the Language might have had.
Once again people in "our situation" determine whether OO
adds value to COBOL. I see little value in OO for most
COBOL applications. I do see value in being able to say
"me too!"
[snip]
> Whatever good reasons there may be for charging a Runtime Fee (and I
accept
> many of John's arguments), the Market place simply cannot and will not
> accept that imposition. (at least it won't long term...)
I can agree with that!
Gavan
Richard wrote:
Given the topic, don't know where the other languages will be going - but check out the
following survey on COBOL usage :-
Peter E. C. Dashwood
The official "MS Line" is that .NET, because it uses a common runtime for
ALL languages, overcomes this problem and provides a "level playing
field"...
Personally, I am not yet persuaded that NETCobol has enough facilities to
make it worth developing executables or even components that can use the
Common Language Runtime (CLR), although I have to admit that the early
indications are good.
I do believe that the future is in components and they should be developed
using the Language best suited for the job. (In many cases this will be
COBOL).
Even if .NET delivers what it promises (and the jury is still out, at least
as far as I am concerned) there is still the question of what happens with
non-MS environments like UNIX and the many "UNIX like" environments which
are part of today's IT infrastructure.
There are indications that CORBA will serve Java Beans in a .NET
environment, but I don't know anybody who's done it yet... (anyone out there
who has done this please mail me privately).
I have also heard that .NET will support the mainframe "eventually" but,
again, I don't know of any cases where this is actually happening.
If anyone can shed some light on this I would be very grateful. COBOL has a
place in this environment and it would be a pity if it simply "falls through
the cracks"...
Pete.
Clark F. Morris, Jr. <cfm...@istar.ca> wrote in message
news:3D32C165...@istar.ca...
Posted Via Usenet.com Premium Usenet Newsgroup Services
Peter E. C. Dashwood
Gavan <jjg...@shaw.ca> wrote in message news:3D335B2B...@shaw.ca...
> Given the topic, don't know where the other languages will be going - but
check out the
> following survey on COBOL usage :-
>
> http://www.cobolportal.com/developer/future.asp
>
Thanks for this link, Jimmy. It is very interesting. I read and digested it
carefully. (In passing, I have to note that the standard of English in the
document was appalling, with frequent grammatical and spelling
errors...coming from 3 University Professors it makes me wonder about the
standard of education in the US...To be fair, English may not be the first
language of one of the Authors, but let's not get sidetracked...<G>)
Here is what I think about it...
>>>
"This paper will describe the results from a survey taken of professional
business and industry employers who are using COBOL in their information
systems. A discussion of the IS Manager's view of the future of COBOL is
presented. Almost 90 percent of IS Mangers surveyed indicated that COBOL
should continue to be offered in college curriculums, and also nearly 90
percent indicate that both object-oriented and web-based features of the
COBOL language should be integrated into COBOL instruction in college
curriculums. It is hoped that these results will help academia to design
their curriculums to meet the expanding need for IS people over the next
five years."
<<<
Two things to note here.
1. They surveyed sites already committed to COBOL. That's fine, but it doesn
't indicate the "take up" of COBOL by uncommitted sites. If the committed
sites slowly erode (and I believe that is what is happening) then the basis
for this paper is doubtful.
2. They recognise there is no future for COBOL without OO and are moving to
get it taught as part of the new COBOL curriculum. If this succeeds, I would
have to review completely my prediction as to the demise of COBOL. I believe
this may be the one thing that could save it and bring it into the 21st
Century. I got quite excited by this, but calmed down when I read what they
said later <G>. see below.
>>>
"Responses were received from 142 business and industry organizations. The
response rate was 2.8 percent from this business and industry group."
<<<
Hardly an enthusiastic response. Nevertheless, the survey itself is
valuable.
>>>
More than 45 percent of IS manager responses stated that COBOL would
continue to be used over the next 10 years at the existing level while less
than 15 percent indicated that COBOL would be eliminated or replaced in the
organization.
<<<
Most IS managers have NO IDEA what is going to happen in the next 10 MONTHS,
never mind the next 10 YEARS. Effective planning covers 3 to 6 months
accurately, after that all bets are off. Their responses are based on what
they see NOW. It ain't necessarily so..
>>>
Slightly more than 30 percent of the respondents indicated that COBOL would
decline in importance of use in application development. However, about 5
percent said that use of COBOL would actually increase over the next 10
years.
<<<
We need to know the experience background of these "Managers". How accurate
are they likely to be? Anybody can predict anything. It is the basis for
the prediction, and the insight of the predictor, that determine the
accuracy of the prediction.
>>>
Nearly 20 percent of IS managers indicated that object-oriented COBOL would
be used to wrap existing COBOL applications in the development of new
applications. More than 30 percent of respondents indicated that they are
implementing COBOL web-based facilities to enable migration of legacy COBOL
applications to the Internet.
<<<
So around 30% of the respondents to the survey are planning to migrate
existing code and are looking at sensible ways to do this. This is
encouraging, but it still leaves 70% who are happy with the status
quo.("Ostriches".<G>). This is where the decline of COBOL by natural
attrition is likely to occur.
>>>
Also, more than 30 percent of IS managers stated that they will be using
another computer language development environment to eventually replace
COBOL.
<<<
Ah, so my 70% of ostriches is really only 40% because 30% have already
decided to replace COBOL. (I can't decide whether that is good or bad
news.<G>)
>>>
More than 25 percent of the respondents believe that object-oriented
methodology will become the standard for future application development
while more than 60 percent indicate the belief that object-oriented
methodology will become popular but will not totally replace existing
structured methodology.
<<<
So 15% either don't know or don't care, and 60% cannot let go of what they
do now, although they are being pushed to do so. The good news is that 25%
(more than I expected) can see where it's going. There may be some hope yet.
The problem with this 25% is that they will respond to a survey saying they
believe it will happen, but they are not prepared to bite the bullet and
MAKE it happen. Until we see some real action indicating a change of heart
from Fortress COBOL, the Language remains hanging by a thread. Client/Server
implementations, while very valuable, will not of themselves ensure the
continued life and zestful health of COBOL.
>>>
It seems fairly evident that the results obtained from the present research
positively rejects the null hypothesis. The COBOL language will continue to
be widely used in business application development over the next 10 years.
Neither business nor academia can deny this analysis of the data as
interpreted by the authors.
<<<
Brave words! Unfortunately, not necessarily true words. Both Business and
Acadaemia can certainly contest, if not refute, the accuracy of "this
analysis of the data as interpreted by the authors".
While certainly better than nothing, the sample is poor. There is no
indication of the background and experience of the "IS Managers", and they
are all from Fortress COBOL installations with a vested interest in
preserving the status quo.
Nevertheless, the fact they are requiring new recruits to have a grounding
in OO techniques (even though they don't understand these techniques
themselves) is some encouragement.
My own assessment is as follows:
This survey gives some glimmers of hope for the future, but it does NOT give
any solid indication of ACTION towards this future. The attitude is
"Acadaemia should provide people who know the latest stuff and then we can
look at maybe doing something about it." There is no commitment to in-house
training NOW. Ths is understandable because the Managers surveyed do not
themselves understand why it is important. They have an uncomfortable
feeling that the technology is sweeping past COBOL (which indeed it is.) but
they can't put their fingers on what is required or why it is required.
I reckon programmers should take things into their own hands, for the sake
of their own futures. Expand your skill set. Learn Java and OO concepts AS
WELL as COBOL. It can only improve your value. The days when you could get a
lifetime career out of writing COBOL are fast disappearing.
Whether I am right or the Professors are right about COBOL in the next 10
years, can you afford to take the chance?
Clark F. Morris, Jr.
and predecessors
does not come with the routines that are unique to COBOL or PLI so that
those routines have to be licensed separately and have separate
FMIDs. This is being posted so that any misunderstanding on my part can
be clarified.
"William M. Klein" wrote:
>
> Clark,
> What release of z/OS or OS/390 are you on???
>
> The *full* COBOL, PL/I, and Fortran run-times *are* included in LE (Language
> Environment) - which most DEFINITELY is part of the distributed "operating
> system" (and has been for almost a decade now).
>
> It is true that only the Assembler and C compiler are part of the OS - and
> that you need to "purchase" the other compilers, but the run-times are
> "free" with the OS. (True on OS/390, z/OS, VM, *and* VSE)
>
> P.S. The "debugger" is also a cost-added feature, but once you buy it for
> ANY high-level language, it is available for all.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
Donald Tees
news:3d340...@Usenet.com...
>
> Gavan <jjg...@shaw.ca> wrote in message news:3D335B2B...@shaw.ca...
>
> > Given the topic, don't know where the other languages will be going -
but
> check out the
> > following survey on COBOL usage :-
> >
> > http://www.cobolportal.com/developer/future.asp
> >
> Thanks for this link, Jimmy. It is very interesting. I read and digested
it
> carefully. (In passing, I have to note that the standard of English in the
> document was appalling, with frequent grammatical and spelling
> errors...coming from 3 University Professors it makes me wonder about the
> standard of education in the US...To be fair, English may not be the first
> language of one of the Authors, but let's not get sidetracked...<G>)
>
When it starts with "Many educators are currently being challenged today
..." one has to wonder. Maybe they get paid by the word.
Donald
Ira Baxter
> These are excellent points you raise, Clark.
>
> The official "MS Line" is that .NET, because it uses a common runtime for
> ALL languages, overcomes this problem and provides a "level playing
> field"...
And if you wait for any reasonable length of time, it won't be true.
Today, there is a particular .NET runtime and libraries [much bigger
than the runtime!]. Of course, MS can't
resist the urge to improve (assuming it has No Bugs :), and so tomorrow
there will be another one. And of course, the improvements Will Be
Upwards Compatible (we've all been down this road, and it only
works 95% of the time). So in 1-2 years, you'll be facing
*another* CLR, but your present app works on the current one.
We have a Java based customer, who has an enormous application
based on Java (JDK 1.2). His app uses many *documented* features
of the JDK 1.2 that changed slightly when Sun released JDK 1.3.
He doesn't have the energy to make the switch, but he has new
products being developed, so his team wants to use the newer foundations.
And he's having a hard time explaining to his customers why
they have to configure multiple JDKs.
The good news is, as Raulerson said, that you can manage this
with environments, etc. The bad news is that the "common runtime"
is simply a lie if you consider the passage of time, as all
large applications must.
--
Ira Baxter, Ph.D. CTO Semantic Designs
www.semdesigns.com 512-250-1018
Mike
> Personally, I am not yet persuaded that NETCobol has enough facilities to
> make it worth developing executables or even components that can use the
> Common Language Runtime (CLR), although I have to admit that the early
> indications are good.
Peter, Yes all .NET languages "are Created Equal" in that all
previous independent runtime compilers now Must also Buy M$ Visual
Studio as a runtime tax which bastardizes "Guest Languages" as
evaluated here http://www.javalobby.org/pdf/clr.pdf Check Amazon.com
and user forums for evaluations that hate C++.NET which is C#'s
closes syntax next to JAVA/ Delphi. You are probably better off
learning just C# if you wish to work on M$ .NET as you have to make so
many system invokes just to set variables etc and then the resulting
code is a few non-standard COBOL integrated statements.
Fujitsu is coming out with a Linux COBOL soon, however they have NO
integration of an OSS RDBMS like MySql, which will make their product
useless, compared to PHP and MySql winning team. Their licensing
program is trying to emulate MicroFocus, like charging for 2
processors, which leaves you with very few good Internet web servers.
I see nothing wrong in runtime fees if they choose a percent of sales
model (like http://www.PayPal.com ).
I have become so tired of M$'s Ballmer and his parrot sounding
zombies with Senator McCarthy type rhetoric "Linux communism theme"
that I have changed my MS-w2k-ISS-COBOL-CGI/SQL(access) development
intranet to a dual-boot Redhat-Apache-PHP-CGI-/MySql and Will deploy
to a Redhat internet server verses Win2k. Has anyone tried Linux-Wine
with Fujitsu-COBOL? I would suggest anyone doing Internet work to
download the Free PHP IDE 2.01 at http://www.zend.com .
Mike-exCobolNerd.
Thane Hubbell
business model you have adopted (and that obviously works) is
virtually impossible to "change" overnight. I don't suggest you try
to do so. Had I known that the vendor would work with me on the
runtime fees I might have made different decisions -- but I actually
did ask at the time, and none were willing to budge. Perhaps vendors
need to be a little more vocal in sharing their potential terms?
That said - I understand the financial presssure to work for those
clients that generate the most revenue. However - since as you note,
the price of the runtime is most often passed to the end user, how
about letting the middle man make some $$ selling your runtime? Allow
this middle man greater and greater discounts as more runtimes are
sold? 1-50, $50.00 each, 50-100, $40.00 each etc etc etc.... I think
that might be a fairer way to support your present model.
On the OTHER hand - there is little encouragement for you to enhance
your product with this model. Those selling development tools with no
runtime fees must continue to enhance the product in order to get
repeated maintenance fees and repeat/extended sales. I think the no
runtime fee model helps encourage innovation and the introduction of
new products.
Do you charge a yearly maint fee per runtime?
j.br...@liant.com (John Bradley) wrote in message news:<25fb80a6.02071...@posting.google.com>...
Thane Hubbell
> Very insightful comments. Thanks.
>
Welcome... your good observations snipped - I want to address the
question you ask though...
>
> An off topic concern I have is that maybe COBOL has
> gotten too powerful for vendors to support profitably.
> Maybe the ANSI/ISO committee should restrict themselves
> to profitable enhancements only. If they do restrict
> themselves, maybe they should restrict more than they
> have in the past. I do not know enough about what
> went on to know if this is a valid concern.
This certainly is a good and valid concern. The committee, in work
this week considering the next version of the standard, is attempting
to do something very similar to this. We want to add enhancements
that are benefitial to users, but not make such vast changes as to
introduce errors or take such a long time to create. To frequent an
issue of a standard can be just as bad as one that takes too long. We
strive to find a good compromise.
Gazaloo
> Java has no runtime royalties whatsoever.
Eh? WebLogic, WebSphere -- $billions...
> VisualBasic has no runtime royalties.
Eh? Windows -- $billions...
Gazaloo.
Paul Raulerson
distribution, no runtimes at all.
VisualBasic development is essentially a one time cost, the cost of the software.
All software everywhere has a cost associated with it of a platform to host it on, but that is NOT a runtime license fee.
-Paul
"Gazaloo" <g...@a.loo> wrote in message news:RLIZ8.563835$352.98930@sccrnsc02...
Angel
I've snipped and added some insights of my own below.
I humbly accept proofreading and grammatical corrections. :)
On Mon, 15 Jul 2002, Peter E. C. Dashwood wrote:
>
> First off, I think we should be looking at whether there is a Market for
> COBOL at all in the developing IT landscape.
>
The term 'developing IT landscape' may be a little nebulous.
So that one may understand my comments below, let me point out
that in the PC segment of the market, COBOL is the intruder.
First there was Microsoft BASIC. Then there were several others.
Pascal and C, I believe. These were pretty much the market
on this machine.
COBOL came later, and took some market share away from the "old guard."
The point I'm trying to make is this. If COBOL completely died
on the PC market, it would only go back to where it was.
Not counting the intrusions of other languages into the mainframe
market (such intrusions have earlier been Fortran and RPG) COBOL might
be about the same market as ever was. It might be larger or
smaller nowadays, I don't know.
> I believe the useful life of COBOL will not be more than 10 years. (Note I
> said "useful"...Personally, I shall be writing COBOL for the next 20 years
> (hopefully) but that has more to do with love of it than actually serving
> any useful purpose, or achieving something that could not be achieved more
> easily or efficiently by other means.(I am assuming that even better
> alternatives will appear in the next 10 years)) We are already seeing the OO
> languages like Java eroding what has traditionally been COBOL's base.
>
> The failure of the COBOL user base to embrace OO COBOL (and this has been
> compounded by the dismal failure to get the standard for it released) has
> probably killed any future that the Language might have had.
>
The death of COBOL will not be brought about by lack of OO.
Before I get a boxing kangaroo sic'd on me, let me relate a story.
I was working as a consultant at a software house. I casually
mentioned to one of the developers on the team that a new
COBOL was coming out that supports Object Orientation.
He laughed in my face. Then he related his story.
He had attended an industry committee meeting.
Something about a standardized format for xml data
exchange, of which he was a committee member. During one of the
lunch breaks, he happened to sit with a developer from his
largest competitor. This competitor does everything in C or C++.
So he asked whether the competitor had ever used OO.
The competitor said he had. In fact, they had brought in a college
professor as a consultant to guide the OO project and libraries.
Everything was well planned and done just right.
But they had to back out the OO changes from the code. As it so happens
in this industry, banks and such, they process millions
of records a day. These clients can process hundreds of millions
of records without even blinking. Jobs less than 10,000
records are considered test jobs.
It turns out that OO is such a performance penalty that the clients
could not use the software. It was a production emergency to
get it fixed.
Then the developer on my team said sadly "I feel sorry for those
developers that dive whole hog into OO without looking.
There's likely many that will loose their jobs learning
that lesson."
I present this as an insight into another market.
I do not mean to disparage your comments regarding the PC
market. Your concerns there are valid. In the PC market
the CPU is typically sitting in a wait state 95% of the time.
In the mainframe market, the CPU can not afford to sit in
wait state that low. (The owner would go bankrupt.)
Performance is a critical priority in markets other than the PC.
For this reason alone, OO technology will never go over very big here.
James J. Gavan
Angel wrote:
> I appreciate the points you made. They are insightful.
> I've snipped and added some insights of my own below.
> I humbly accept proofreading and grammatical corrections. :)
>
> On Mon, 15 Jul 2002, Peter E. C. Dashwood wrote:
>
> >
> > First off, I think we should be looking at whether there is a Market for
> > COBOL at all in the developing IT landscape.
> >
>
> The term 'developing IT landscape' may be a little nebulous.
>
> So that one may understand my comments below, let me point out
> that in the PC segment of the market, COBOL is the intruder.
>
> First there was Microsoft BASIC. Then there were several others.
> Pascal and C, I believe. These were pretty much the market
> on this machine.
>
> COBOL came later, and took some market share away from the "old guard."
>
I doubt one can dispute your claim about BASIC as the first on a PC. As to the
others - can't give you exact date but I was using RM/COBOL (ANSI '74) on Radio
Shacks in 1980/81.
OO is no different to any other technology. If you go Rick Smith's 'pure OO' route
- then there's a fair chance you will get your knickers in a twist. You have to
adapt any technology to your particular needs. Banking is certainly an area we
know to be transaction intensive (number crunching), and just a straight 'Read
Sequential and Update Master' - doesn't have much competition from OO. (But note
you can code your program as an OO Class to exactly mimic that operation). But
when you move into on-line enquiries, that's where components tend to have an
advantage. (Regarding banks - as we've seen from contributors here - using pure
SQL/DB just doesn't cut it for them - they go for a mix using the same 'Read
Sequential and Update Master', and the SQL element for queries/selective
reporting).
I can't vouch for it, and it does cause me to swallow in disbelief - but Adele
Goldberg, (one of the original Xerox PARC team), illustrates where Smalltalk is
used in what we would traditionally consider to be 'COBOL territory' - banking
being one such.
I've no doubt Richard (Ada) and Grinder (Pascal) could cite us cases for usage of
their respective OO languages in large applications.
Jimmy, Calgary AB
Susan A Allen
"James J. Gavan" wrote:
> (But note
> you can code your program as an OO Class to exactly mimic that operation). But
> when you move into on-line enquiries, that's where components tend to have an
> advantage. (Regarding banks - as we've seen from contributors here - using pure
> SQL/DB just doesn't cut it for them - they go for a mix using the same 'Read
> Sequential and Update Master', and the SQL element for queries/selective
> reporting).
I want to toss my hat in this arena; Stored Procedures are straddling
the great divide between batch and OO objects and the SQL performance is
pretty darn good from a user view. Perhaps not for millions of records;
but certainly on hundreds to thousands of them.
Susan A
Richard Plinston
> So that one may understand my comments below, let me point out
> that in the PC segment of the market, COBOL is the intruder.
>
> First there was Microsoft BASIC. Then there were several others.
> Pascal and C, I believe. These were pretty much the market
> on this machine.
>
> COBOL came later, and took some market share away from the "old guard."
Cobol has been on Microprocessors since 1978, well before there were IBM
PC, well before there was MS-DOS. MicroFocus Cobol, MicroSoft Cobol and
RM Cobol ran on CP/M, MP/M, Oasys and other systems on 8080/8085/Z80
machines. These moved to 8086/DOS systems at a very early date, and to
IBM-PCs.
In fact Cobol predated C on most of these systems (though there was
Small C and Tiny C).
> ..., I don't know.
I agree with that.
> I present this as an insight into another market.
> I do not mean to disparage your comments regarding the PC
> market. Your concerns there are valid. In the PC market
> the CPU is typically sitting in a wait state 95% of the time.
Since the late 70s I have worked primarily in microprocessor based
(starting with 8085) multi-user systems developed in Cobol running on
MP/M, Tubbo-DOS, Concurrent-DOS, Multiuser-DOS, or Unix/Linux. A small
user may have 20 user processes running on, say, a Pentium 233 using
dumb terminals, old 386/486s as serial terminals or Windows machines
running terminal emulation programs with each user having access to 4
separate tasks each.
My systems don't sit in wait states for 95% of the time.
Donald Tees
news:3D4184DF...@shaw.ca...
(Huge snippage)
>
> OO is no different to any other technology. If you go Rick Smith's 'pure
OO' route
> - then there's a fair chance you will get your knickers in a twist. You
have to
> adapt any technology to your particular needs. Banking is certainly an
area we
> know to be transaction intensive (number crunching), and just a straight
'Read
> Sequential and Update Master' - doesn't have much competition from OO.
(But note
> you can code your program as an OO Class to exactly mimic that operation).
But
> when you move into on-line enquiries, that's where components tend to have
an
> advantage. (Regarding banks - as we've seen from contributors here - using
pure
> SQL/DB just doesn't cut it for them - they go for a mix using the same
'Read
> Sequential and Update Master', and the SQL element for queries/selective
> reporting).
I think the biggest problem with the "pure OO" route is that it is not "pure
OO". It is a model of OO that is the normal method of using OOP when
designing bottom up systems using smallish numbers of objects. That the
student thinks this is the only model is largely a result of the legacy OOP
objects written in bottom up languages like C++. As we all know, that
language was designed for operating systems, not bussiness. The Cobol
object model is far richer, designed for both bottom up systems like Rick
describes, but also for top down bussiness systems built of components, like
Pete espouses.
I have written both types, in Cobol. I have, for example, a serial device
handling object that I built bottom up. It contains a complete system for
hooking up something to a serial port on a PC, at the wiring level. Plug in
the device, and it is like a terminal, handles baud rates etc. Instances of
those provide a serial driver for up to twenty ports. Above that is a class
of devices, with thier own test routines. (bar code readers, scanners, weigh
scales, etc.). Above that is a few Cobol systems that use them. That
entire system is installed and maintained separately from the systems above
it. I could, in fact, sell it as a stand alone system. Even though it is
written in Cobol, it follows the model proposed by Rick, and it works well.
Rick of course, would say that this is *very* atypical of IT/DP and actually
supports his arguement.
It is when you start looking at OOP as a top down language, however, that
Rick's arguements fall apart. In fact, top down applications abound with
persistant objects that exist for long periods of time, and evolve slowly
over that entire duration. In fact, the simple Isam file is an excellent
example of a collection of persistant objects, each identified by a key. To
use Ricks's approach is the equivalent of insisting Isam be replaced by
array's. By gaining speed you sacrifice individual object locking, the same
as you would have with the old fashioned Cobol we all know and love.
I am starting to think that source code should be part of the top down
"Cobol Object". There is an object that persists for a few decades, or
should if it is written in Cobol.
Donald
Donald Tees
"Richard Plinston" <rip...@Azonic.co.nz> wrote in message
news:3D42524D...@Azonic.co.nz...
> Angel wrote:
>
> > So that one may understand my comments below, let me point out
> > that in the PC segment of the market, COBOL is the intruder.
> >
> > First there was Microsoft BASIC. Then there were several others.
> > Pascal and C, I believe. These were pretty much the market
> > on this machine.
> >
> > COBOL came later, and took some market share away from the "old guard."
>
> Cobol has been on Microprocessors since 1978, well before there were IBM
> PC, well before there was MS-DOS. MicroFocus Cobol, MicroSoft Cobol and
> RM Cobol ran on CP/M, MP/M, Oasys and other systems on 8080/8085/Z80
> machines. These moved to 8086/DOS systems at a very early date, and to
> IBM-PCs.
>
> In fact Cobol predated C on most of these systems (though there was
> Small C and Tiny C).
>
Yes, as I recall Cobol appeared with CPM/86 on the Altos close to 5 years
before the PC. That was migrated to MPM/86 which was multi-terminal. It
was not until PC's got cheap enough to emulate terminals for that system
that PC's were really taken seriously enough for anything but
word-processing. I have object oriented code that ultimately started on
that system.
Donald
Rick Smith
Donald Tees <donal...@sympatico.ca> wrote in message
news:rxn09.10093$DN4.2...@news20.bellglobal.com...
[snip]
> It is when you start looking at OOP as a top down language, however, that
> Rick's arguements fall apart. In fact, top down applications abound with
> persistant objects that exist for long periods of time, and evolve slowly
> over that entire duration. In fact, the simple Isam file is an excellent
> example of a collection of persistant objects, each identified by a key.
To
> use Ricks's approach is the equivalent of insisting Isam be replaced by
> array's. By gaining speed you sacrifice individual object locking, the
same
> as you would have with the old fashioned Cobol we all know and love.
First, it's not clear, to me, that you ever understood my arguments.
I guess I may have to accept that the misrepresentation of my ideas
and concepts is the price of being "popular." <g>
Second, my approach was "hinted at" over three years ago. It was
never presented in the recent discussion. (Edited text from the
prior post is presented below.)
The network database is near perfect for persistent storage of
OO objects. What is missing is a means for reconstituting
different classes of objects from a set in the database.
In memory, the relationship between objects is maintained by
object references to those other objects.
To maintain this relationship between objects, when stored in
ISAM or relational databases, foreign keys must be introduced
in place of the object reference to the class. A network database
maintains the relationship with pointers in the database and,
therefore, does not require the introduction of foreign keys.
Foreign keys violate an OO principle that changes in
representation, within a class, will have no effect outside the
class. The existence of foreign keys means that some changes
in the representation of the key, within a class, will have an effect,
outside the class.
One of the revelations I had in the recent discussion, was
that foreign keys had to be introduced to use ISAM for
object storage. To me, the introduction is an "impurity."
The use of ISAM and relational databases to store objects
is not very OO. <G>
-----------
Subject: Re: Flow Charts
Date: 1999/03/18
"Data Structure Diagrams: Used to show system wide data and
to show the relationship between data entities. When used within
a network model to describe data, the resulting diagram can be
used to distinguish classes, or to identify the various records
(entities) that exist within a network ... data base ..."
<
http://groups.google.com/groups?selm=7crl28%2428q%241%40server.cntfl.com&out
put=gplain >
James J.Gavan
Rick Smith wrote:
[snip]
First, it's not clear, to me, that you ever understood my arguments.
I guess I may have to accept that the misrepresentation of my ideas
and concepts is the price of being "popular." <g>Second, my approach was "hinted at" over three years ago. It was
never presented in the recent discussion. (Edited text from the
prior post is presented below.)The network database is near perfect for persistent storage of
OO objects. What is missing is a means for reconstituting
different classes of objects from a set in the database.In memory, the relationship between objects is maintained by
object references to those other objects.To maintain this relationship between objects, when stored in
ISAM or relational databases, foreign keys must be introduced
in place of the object reference to the class. A network database
maintains the relationship with pointers in the database and,
therefore, does not require the introduction of foreign keys.Foreign keys violate an OO principle that changes in
representation, within a class, will have no effect outside the
class. The existence of foreign keys means that some changes
in the representation of the key, within a class, will have an effect,
outside the class.One of the revelations I had in the recent discussion, was
that foreign keys had to be introduced to use ISAM for
object storage. To me, the introduction is an "impurity."
tho' as yet I still don't buy 'pure OO' - which nut, who has probably never
written a WORKING application in ANY language said there is such a thing as 'pure OO' ? (The *emphasis* is WORKING APPLICATION).
And your comment above , "To me, the introduction is an "impurity." - has somebody defiled a vestal virgin <G>.
I'll get back in due course, when my thoughts are 'pure', well at least 'clear' <G>.. Talking of digging up history - where's your Multiple Inheritance example you *promised* Thane about two years ago ?
The use of ISAM and relational databases to store objects
is not very OO. <G>
Does that mean that Java has got it *wrong* as well ? Seems you'll have to come up with a new OO language - SmithQuick (???)
-----------
Subject: Re: Flow Charts
Date: 1999/03/18"Data Structure Diagrams: Used to show system wide data and
to show the relationship between data entities. When used within
a network model to describe data, the resulting diagram can be
used to distinguish classes, or to identify the various records
(entities) that exist within a network ... data base ..."
<
http://groups.google.com/groups?selm=7crl28%2428q%241%40server.cntfl.com&out
put=gplain >
You make some good points Rick but you fail to support them without the slightest attempt at pseudo code for OO COBOL. Remember we should be talking about 'Pure OO COBOL" here. If you want to talk about 'Pure OO' then you are in the wrong News Group.
Give you a clue to where I'm at. Ken Foskey (no longer contributes here, regrettably, because he earns his bread with C), used to make the point that COBOL was deficient because of using 'data' instead of objects. (Could be he was reading some of the same books as you <G>). COBOL since inception has been a data centric language and I see no need to turn 'strings' into objects, just for the hell of it, when it isn't necessary.
Jimmy, Calgary, AB
John Bradley
Sorry for MY delay! I just noticed your post. I answer your
questions below:
tha...@softwaresimple.com (Thane Hubbell) wrote in message news:<bfdfc3e8.02071...@posting.google.com>...
<snip>
> That said - I understand the financial presssure to work for those
> clients that generate the most revenue. However - since as you note,
> the price of the runtime is most often passed to the end user, how
> about letting the middle man make some $$ selling your runtime? Allow
> this middle man greater and greater discounts as more runtimes are
> sold? 1-50, $50.00 each, 50-100, $40.00 each etc etc etc.... I think
> that might be a fairer way to support your present model.
We have used almost every conceivable pricing scheme over the years,
including the one you propose. It was originally used extensively
(1981-87) timeframe. The problem is that when you base price on
purchase history alone, it usually just becomes a "bonus" to the
customer (i.e., serves no incentive purpose). We once had a Stanford
MBA-type product manager refer to it as RM's "golden age plan" for
customers.
What we do now is provide a way to "buy-down" runtime pricing if you
are willing and able to commit to a specific volume. For example, if
you know (or believe) you will sell between 1,000 and 5,000 products,
we will give you a better price on the runtime based on your selling
at least 1,000. If you are confident of a larger number, that will
yield an even better price.
>
> On the OTHER hand - there is little encouragement for you to enhance
> your product with this model. Those selling development tools with no
> runtime fees must continue to enhance the product in order to get
> repeated maintenance fees and repeat/extended sales. I think the no
> runtime fee model helps encourage innovation and the introduction of
> new products.
>
It certainly encourages enhancement and differentiation of the
compiler. I think, typically, a vendor's R&D follows the money. If
they receive income exclusively from the compiler, they will tend to
spend the most on enhancing the development phase of the application.
If they receive most of their income from the runtime platform (as we
do), they will tend to spend the most on the deployment side of the
application cycle (such as file system, portable object and data,
configuration, testing etc.). Which of these is good for the customer
is something that each customer will decide.
> Do you charge a yearly maint fee per runtime?
We do, although until recently our outrageously generous "upgrade"
policy led to few takers. Now, you don't have to buy yearly
maintenance, but if you don't, and you do need to upgrade or change
platform after the warranty period, you must purchase a new one (or
negotiate a deal at that time). As you have no doubt noticed, this is
becoming a common paradigm (Oracle, MS etc.). I suspect it is for the
same reason we have gone to this model. When the computing industry
was young, platforms changed rapidly, computer makers came and went on
a daily basis, and operating systems came in many flavors. Our
runtime model business worked just fine without maintenance, because
there was lots of other incentive for customers to repurchase
runtimes. This income is what paid for the R&D necessary to keep
everything running well on dozens of major platforms and hundreds of
minor ones. With the stability that has come over the past few years,
we increasingly found ourselves having to find ways to "sell" a new
version of our product, when in fact the majority of the expense was
keeping it up to par in much less visible (but even more critical)
areas. Hence, our attempt to smooth out upgrade revenue and make it
more predicatable and tied to actual cost. I suspect the big players
have similar reasons for doing more-or-less the same thing.
Thanks for your comments.
John
Donald Tees
marketing. I feel that being able to distribute demonstration copies
absolutely vital to modern marketing, so by precluding the selling in the
runtime, you are disabling a *very* large proportion of the market.
Donald
"John Bradley" <j.br...@liant.com> wrote in message
news:25fb80a6.02073...@posting.google.com...
James J.Gavan
Donald Tees wrote:
> One problem is that it precludes any kind of shareware approach to
> marketing. I feel that being able to distribute demonstration copies
> absolutely vital to modern marketing, so by precluding the selling in the
> runtime, you are disabling a *very* large proportion of the market.
>
> Donald
John,
Thanks for your candour as a CEO in taking the time to contribute here. But one
further insidious thing about runtimes. You've no doubt seen messages from Pete
Dashwood promoting the Component concept. There's a big market for them. Not
deliberately excluding the others, but with their GUI support it is possible
from Fujitsu or Net Express for a COBOL developer to come up with a real doozy
of a component.
It could potentially have a very wide market - likely the developer would put a
modest retail price on the end product, (going for volume), but now add the
runtime royalties to the developer's cost to be passed on to end users ???
And I always come back to this one - Joe Blow drives his new taxi cab out of the
showroom. As he hits the highway a salesman rushes out from the showroom
shouting, "Don't forget each time you pick up a fare, you are obliged to give us
a piece of the action". I rather think not, in the rest of the commercial world.
Jimmy, Calgary AB
Rick Smith
James J.Gavan <jjg...@shaw.ca> wrote in message
news:3D460ECC...@shaw.ca...
>
> Rick Smith wrote:
>
> > [snip]
[snip]
Hell, I don't buy "pure OO" either; however, to discuss
the problems of OO, generally, one must establish a
reference. That reference is a concept of "pure OO."
Then by noting the differences between "pure OO" and
the pactical application of OO, we may be able to see
circumstances in which the application of OO may be
unwise. Where the application of OO is not unwise,
then use OO.
My willingness to raise the problems with using OO COBOL
does not diminish my desire to use OO, when it makes
sense.
> And your comment above , "To me, the introduction is an "impurity." - has
> somebody defiled a vestal virgin <G>.
More than a year back, I communicated briefly with the
OO, e-mail group. I declined to participate in the on-going
discussions because, as I recall saying, I was going to think
about "pure OO" and the design patterns of business
applications. It is, perhaps, not surprising that no one seems
to remember; but you, Pete, and the others in that group
were "warned." <G>
> I'll get back in due course, when my thoughts are 'pure', well at least
'clear'
> <G>.. Talking of digging up history - where's your Multiple Inheritance
example
> you *promised* Thane about two years ago ?
It became relatively unimportant during the extended illnesses
of two family members; but I did give some suggestions in the
other thread. I still might give an example later. First, I must
become convinced that it is "safe" to discuss OO COBOL,
all of OO COBOL, in this group. <G>
> > The use of ISAM and relational databases to store objects
> > is not very OO. <G>
>
> Does that mean that Java has got it *wrong* as well ? Seems you'll have to
come
> up with a new OO language - SmithQuick (???)
I don't do Java! However, as I understand it, Java has only
streams for I-O, JDBC does the relational. Java is not the
problem.
[snip]
>
> You make some good points Rick but you fail to support them without the
> slightest attempt at pseudo code for OO COBOL. Remember we should be
talking
> about 'Pure OO COBOL" here. If you want to talk about 'Pure OO' then you
are in
> the wrong News Group.
I wanted to discuss problems, as I see them, with using
OO COBOL. COBOL code was not required; steel shorts
were. <g>
I can accept responsibility for my lack of clarity; but I am
not responsibile for the condemnation, denigration, and
misrepresentation that occurred. [I am mostly over it!] <g>
> Give you a clue to where I'm at. Ken Foskey (no longer contributes here,
> regrettably, because he earns his bread with C), used to make the point
that
> COBOL was deficient because of using 'data' instead of objects. (Could be
he was
> reading some of the same books as you <G>). COBOL since inception has been
a
> data centric language and I see no need to turn 'strings' into objects,
just for
> the hell of it, when it isn't necessary.
COBOL has always had notions of class and polymorphism;
but not inheritance and methods. These have been mentioned
before.
The COBOL (abstract) classes NUMERIC, ALPHANUMERIC,
etc., have abstract 'behavior' concerning the effects of using
a MOVE (method), ADD (method), etc., on these classes.
Furthermore, the 'properties': USAGE, PICTURE, etc., override
the abstract 'behavior' to provide 'behavior' specific to the
object (data item).
I seem to recall that Ken Foskey read Betrand Meyer's OOSC.
Anyone reading that book, with an open mind, will have a
great deal of respect for the power of OO. However, it is
contrary to 'practical' application in OO COBOL. It is too
"pure OO."
Having said that, COBOL is a language for processing data.
This implies that data should be central.
-----------
The CODASYL DBTG proposed both the DDL and DML
for COBOL around 1971. The proposals were for use on
a network database, which, I feel, is near perfect for the
storage of COBOL objects.
At this time, work on what was to become OO was
underway and the relational data model was nearing
completion.
Once it was shown that the relational data model was near
"mathematically perfect," support for the network data model
was dropped. As OO approached "mathematical perfection,"
everyone was being encouraged to drop what they're using
and use OO.
What I find curious is that relational works well with non-OO
and network works well with OO; hence "mathematical
perfection" seems not to be the criteria by which we should
be selecting technology.
One interesting speculation is: If the DBTG proposal had
be accepted, would OO COBOL have happened, say,
ten years ago? <g>
Peter E. C. Dashwood
Rick Smith <rick...@mfi.net> wrote in message
news:uke8g5i...@corp.supernews.com...
>
> > >
> > > The network database is near perfect for persistent storage of
> > > OO objects. What is missing is a means for reconstituting
> > > different classes of objects from a set in the database.
> > >
You can "reconstitute" an instance simply by saving the reference to it.
> > > In memory, the relationship between objects is maintained by
> > > object references to those other objects.
> > >
No it isn't. The references simply reference the objects. There is no
implicit relationship between the references unless you choose to make it so
within your own code. For example, if I have three objects A, B, and C,
which exist in a hierarchical structure (B and C depend on A) and are linked
logically to each other (A at the top level, AB and AC at the next level),
it is impossible to tell simply from the object references, the nature of
the relationship. I would need to use the references, to access properties
in the objects, before I would get the relationship. OR I could save the
references in a hierarchic structure within my own code. Object references
by themselves say nothing about relationships other than "This is an
instance of an object of Class X".
> > > To maintain this relationship between objects, when stored in
> > > ISAM or relational databases, foreign keys must be introduced
> > > in place of the object reference to the class. A network database
> > > maintains the relationship with pointers in the database and,
> > > therefore, does not require the introduction of foreign keys.
> > >
It is true that Network DBs do maintain their relationships by linked lists
of pointers but, as the statement that object references imply relationships
is incorrect, it would still require a foreign key (referenced as an object
property) to maintain the relationship, even on a Network database. Without
the foreign key there would be no way of knowing whether AB or AC was the
first child of A. (The Network DB software would return the first child
pointed to... it could be any object that was stored at the same child
level... say, BB). Objects at the lower level would require the foreign key
of the level above in order to maintain the logical structure. The network
structure will maintain 1:1 and 1:many relationships (purely structural) but
it will not maintain logical relationships without foreign keys.
> > > Foreign keys violate an OO principle that changes in
> > > representation, within a class, will have no effect outside the
> > > class. The existence of foreign keys means that some changes
> > > in the representation of the key, within a class, will have an effect,
> > > outside the class.
> > >
And that is precisely why most DBMSs won't let you change a foreign key. If
it is changed (in format or content) it is no longer useful as a foreign
key. Some systems implement referential integrity checking to ensure that
when a primary key is changed, which is also used as a foreign key (is
involved in logical relationships) all the dependent instances are also
changed.
> > > One of the revelations I had in the recent discussion, was
> > > that foreign keys had to be introduced to use ISAM for
> > > object storage. To me, the introduction is an "impurity."
> > >
If a foreign key remains inviolate (and it must, if it is to be used as a
foreign key) then where is the problem?
>
> More than a year back, I communicated briefly with the
> OO, e-mail group. I declined to participate in the on-going
> discussions because, as I recall saying, I was going to think
> about "pure OO" and the design patterns of business
> applications. It is, perhaps, not surprising that no one seems
> to remember; but you, Pete, and the others in that group
> were "warned." <G>
>
It is kind of a pity you didn't stay with the group. I believe much of this
discussion would not be taking place...
>
> I can accept responsibility for my lack of clarity; but I am
> not responsibile for the condemnation, denigration, and
> misrepresentation that occurred. [I am mostly over it!] <g>
>
You have handled it well <G>.
But it doesn't make you right. Try applying some of your own ideas on OO. As
Jimmy said, write some code. It doesn't matter whether you use Java or OO
COBOL or C++, you will get a feel for how objects and object references
behave. You will never glean that from reading a book.
>
> The COBOL (abstract) classes NUMERIC, ALPHANUMERIC,
> etc., have abstract 'behavior' concerning the effects of using
> a MOVE (method), ADD (method), etc., on these classes.
> Furthermore, the 'properties': USAGE, PICTURE, etc., override
> the abstract 'behavior' to provide 'behavior' specific to the
> object (data item).
>
It is an appealing analogy but it is incorrect. The Class clauses in COBOL
bear no relationship to the meaning of CLASS in OO (they were formulated 20
years before OO so you would hardly expect them to...).
While you can argue that MOVE, ADD etc. are Methods which operate on these
Classes, the 'properties' include the Class and this is patently absurd. (In
the absence of a PICTURE or floating point definition, COBOL data must be
defined with the SIZE, CLASS, and USAGE clauses... How can a Class have a
property which is the Class? If PICTURE is used, the Class is indicated by
the X or 9 or A in the picture. As this attribute actually represents the
Class, the whole analogy crashes about now...)
>
> -----------
> The CODASYL DBTG proposed both the DDL and DML
> for COBOL around 1971. The proposals were for use on
> a network database, which, I feel, is near perfect for the
> storage of COBOL objects.
>
And I feel is no more perfect than any other file system. (See above).
I remember very well the time you are describing.
> At this time, work on what was to become OO was
> underway and the relational data model was nearing
> completion.
>
> Once it was shown that the relational data model was near
> "mathematically perfect," support for the network data model
> was dropped. As OO approached "mathematical perfection,"
> everyone was being encouraged to drop what they're using
> and use OO.
>
It is not true that Network Databases were dropped. They had been declining
for some time. Hierarchic databases were the flavour and IMS was in it's
heyday. I don't remember hearing about OO at this time, but I'll take your
word for it.
Systems like IDMS and ADABAS (network model databases, in those days...)
simply couldn't be maintained as easily as the existing IMS DBs and, later,
the new RDBs (DB2 initially). However, it is true that the Network DB
performance was, for the most part, better than the other models.
(Eventually the others caught up and that is why we see very few network DB
implementations today.)
> What I find curious is that relational works well with non-OO
> and network works well with OO; hence "mathematical
> perfection" seems not to be the criteria by which we should
> be selecting technology.
>
The "fact" that OO works well with Network has only been established in your
own mind, and it is based on incorrect belief regarding the obviation of
foreign keys.
Hence "mathematical perfection" remains a worthy criterion by which we can
safely select technology <G>.
>One interesting speculation is: If the DBTG proposal had
> be accepted, would OO COBOL have happened, say,
> ten years ago? <g>
>
It WAS accepted on one site I worked on. We used DDL and DML but we didn't
use OO. I don't quite remember when I first got interested in OO, but it
was't in 1971...
You have obviously done a lot of study on OO and carefully considered many
of the academic arguments. It is a pity I think that you didn't get into
using it instead of reading about it.
Still, as I have remarked elsewhere, it really doesn't matter Rick.
Whether you like it or not, approve or not, see flaws or not, the fact
remains it is here to stay.
Pete.
Donald Tees
> > etc., have abstract 'behavior' concerning the effects of using
> > a MOVE (method), ADD (method), etc., on these classes.
> > Furthermore, the 'properties': USAGE, PICTURE, etc., override
> > the abstract 'behavior' to provide 'behavior' specific to the
> > object (data item).
> >
> It is an appealing analogy but it is incorrect. The Class clauses in COBOL
> bear no relationship to the meaning of CLASS in OO (they were formulated
20
> years before OO so you would hardly expect them to...).
>
> While you can argue that MOVE, ADD etc. are Methods which operate on these
> Classes, the 'properties' include the Class and this is patently absurd.
(In
> the absence of a PICTURE or floating point definition, COBOL data must be
> defined with the SIZE, CLASS, and USAGE clauses... How can a Class have a
> property which is the Class? If PICTURE is used, the Class is indicated by
> the X or 9 or A in the picture. As this attribute actually represents the
> Class, the whole analogy crashes about now...)
>
>
Strangely enough, Pete, I disagree with you on this, and tend to agree with
Rick.
Thinking purely in OO, in the beginning, there was a single object -- the
character. It came in three classes, and collections of these can be
described with a picture clause. Collections of those can be built into
records, etc. Similarly, methods can be built that use that data. The Cobol
Source Code Module is an "object" with three methods: compiling, linking,
and executing.
Where the analogy breaks down is that it only works if you consider the
source code module as a lower level object that runs invisibly at execution
time. If you were in debug mode, and single stepping, then the analogy DOES
hold, all the way down to the byte level. Once compiled, the object-code
"object" is created and destroyed as per Rick's model each time the module
is used.
Donald
Rick Smith
>
> Rick Smith <rick...@mfi.net> wrote in message
> news:uke8g5i...@corp.supernews.com...
> >
> > > >
> > > > The network database is near perfect for persistent storage of
> > > > OO objects. What is missing is a means for reconstituting
> > > > different classes of objects from a set in the database.
> > > >
> You couldn't do that with any other database either. Why would you want
to?
> You can "reconstitute" an instance simply by saving the reference to it.
The most "graphic" example might be a set drawing (owner) and
drawing objects (members). Because the drawing objects may
come from different classes, to retrieve a drawing from the DB,
it would be necessary to retrieve the drawing objects, perhaps,
as a collection. Because the drawing objects are of different
classes, type information would need to be saved to reconstitute
the object with the correct class. The drawing objects may be of
only one class and, therefore, does not require type information.
> > > > In memory, the relationship between objects is maintained by
> > > > object references to those other objects.
> > > >
> No it isn't. The references simply reference the objects. There is no
> implicit relationship between the references unless you choose to make it
so
> within your own code. [snipped example]
I think your placing too much "distance" among these paragraphs.
A logical model of (part of) a system has similarities in the
physical models for network and OO. Set members in network
and collections of objects in OO are logically equivalent. For
example, the logical relation: Order --> Line Item; has a physical
relationship between owner and member that is maintained in
network by pointers and in OO through collections of object
references. Or, if you like, I choose to make it so.
> > > > To maintain this relationship between objects, when stored in
> > > > ISAM or relational databases, foreign keys must be introduced
> > > > in place of the object reference to the class. A network database
> > > > maintains the relationship with pointers in the database and,
> > > > therefore, does not require the introduction of foreign keys.
> > > >
> It is true that Network DBs do maintain their relationships by linked
lists
> of pointers but, as the statement that object references imply
relationships
> is incorrect, it would still require a foreign key (referenced as an
object
> property) to maintain the relationship, even on a Network database.
Without
> the foreign key there would be no way of knowing whether AB or AC was the
> first child of A. (The Network DB software would return the first child
> pointed to... it could be any object that was stored at the same child
> level... say, BB). Objects at the lower level would require the foreign
key
> of the level above in order to maintain the logical structure. The network
> structure will maintain 1:1 and 1:many relationships (purely structural)
but
> it will not maintain logical relationships without foreign keys.
I pulled out the purple book and a reference for a network DB
that I used once upon a time. Both show that members may
be ordered in different ways and each set consists of one
owner and, possibly, many members for that owner. Your
discussion as it relates to BB would not occur and the
discussion as it relates to AB and AC does not apply to the
logical models I am talking about. That is, no owner object
would have two object reference to the same object type
(except where surrogate is used, temporarily). Where multiple
members are loaded, access would be through a collection;
such as, a collection of Line Items for an Order.
However, in the case of the reference to an Item ordered,
the Line Item is "technically" the owner in OO; but must be
a member in the set Item --> Line Item, in the network DB.
In other words, Line Item is a member of two sets.
Members do not require foreign keys because set selection
is through the owner.
> > > > Foreign keys violate an OO principle that changes in
> > > > representation, within a class, will have no effect outside the
> > > > class. The existence of foreign keys means that some changes
> > > > in the representation of the key, within a class, will have an
effect,
> > > > outside the class.
> > > >
> And that is precisely why most DBMSs won't let you change a foreign key.
If
> it is changed (in format or content) it is no longer useful as a foreign
> key. Some systems implement referential integrity checking to ensure that
> when a primary key is changed, which is also used as a foreign key (is
> involved in logical relationships) all the dependent instances are also
> changed.
>
> > > > One of the revelations I had in the recent discussion, was
> > > > that foreign keys had to be introduced to use ISAM for
> > > > object storage. To me, the introduction is an "impurity."
> > > >
> If a foreign key remains inviolate (and it must, if it is to be used as a
> foreign key) then where is the problem?
Maybe I should have put a <G> behind that statement.
> > More than a year back, I communicated briefly with the
> > OO, e-mail group. I declined to participate in the on-going
> > discussions because, as I recall saying, I was going to think
> > about "pure OO" and the design patterns of business
> > applications. It is, perhaps, not surprising that no one seems
> > to remember; but you, Pete, and the others in that group
> > were "warned." <G>
> >
>
> It is kind of a pity you didn't stay with the group. I believe much of
this
> discussion would not be taking place...
And if this discussion is of interest to others not in that
group, they would be missing something interesting.
[snip]
> >
> > -----------
> > The CODASYL DBTG proposed both the DDL and DML
> > for COBOL around 1971. The proposals were for use on
> > a network database, which, I feel, is near perfect for the
> > storage of COBOL objects.
> >
> And I feel is no more perfect than any other file system. (See above).
>
> I remember very well the time you are describing.
>
> > At this time, work on what was to become OO was
> > underway and the relational data model was nearing
> > completion.
> >
> > Once it was shown that the relational data model was near
> > "mathematically perfect," support for the network data model
> > was dropped. As OO approached "mathematical perfection,"
> > everyone was being encouraged to drop what they're using
> > and use OO.
> >
> It is not true that Network Databases were dropped. They had been
declining
> for some time. Hierarchic databases were the flavour and IMS was in it's
> heyday. I don't remember hearing about OO at this time, but I'll take your
> word for it.
Perhaps I am taking some literary(?) license. I read, and I do
not recall the reference, that E. F. Codd, an IBM researcher
and developer of the relational model, convinced IBM
management that the relational model was superior for
data storage and retrieval. Furthermore, that the superiority
claimed was based on mathematics. Subsequently, IBM
withdrew from the CODASYL DBTG, thus reducing support.
> Systems like IDMS and ADABAS (network model databases, in those days...)
> simply couldn't be maintained as easily as the existing IMS DBs and,
later,
> the new RDBs (DB2 initially). However, it is true that the Network DB
> performance was, for the most part, better than the other models.
> (Eventually the others caught up and that is why we see very few network
DB
> implementations today.)
I looked at some OO databases. Where it was mentioned,
they used the relational model. Maintenance may be the issue.
OO is very flexible in changing classes to adapt to needs.
An OO database needs to be very flexible in accommodating
those changes. Relational seems to fit better in that
category.
Rick Smith
> "Peter E. C. Dashwood" <dash...@nospam.enternet.co.nz> wrote in message
> > >
> > > The COBOL (abstract) classes NUMERIC, ALPHANUMERIC,
> > > etc., have abstract 'behavior' concerning the effects of using
> > > a MOVE (method), ADD (method), etc., on these classes.
> > > Furthermore, the 'properties': USAGE, PICTURE, etc., override
> > > the abstract 'behavior' to provide 'behavior' specific to the
> > > object (data item).
> > >
> > It is an appealing analogy but it is incorrect. The Class clauses in
COBOL
> > bear no relationship to the meaning of CLASS in OO (they were formulated
> 20
> > years before OO so you would hardly expect them to...).
They are the same. Too bad you didn't study more theory. <G>
> > While you can argue that MOVE, ADD etc. are Methods which operate on
these
> > Classes, the 'properties' include the Class and this is patently absurd.
> (In
> > the absence of a PICTURE or floating point definition, COBOL data must
be
> > defined with the SIZE, CLASS, and USAGE clauses... How can a Class have
a
> > property which is the Class? If PICTURE is used, the Class is indicated
by
> > the X or 9 or A in the picture. As this attribute actually represents
the
> > Class, the whole analogy crashes about now...)
The class NUMERIC is abstract. It defines no data; but does
define methods. (CLASS is not a property!) The class
ALPHABETIC is abstract. It has its methods, also. The class
ALPHANUMERIC is abstract and inherits from both NUMERIC
and ALPHABETIC. There are other named classes, as well
(and categories in the FDIS).
The COBOL language also has some abstract behaviors for
which names are not given. We might call these storable and
pictureable. Every data item (object) is composed of several
abstract classes which define its behavior when an instruction
sends a message to a method of that object. The behavior
of the object, when it receives the message, is defined by the
general rules of the language.
In theory, ADD 1 TO RECORD-COUNT is the same as
INVOKE RECORD-COUNT "ADD" USING 1. In fact,
simulation of COBOL in other languages might use the
equivalent of the second form. It is, in part, by thinking
about simulation of COBOL that the "sameness" of COBOL
CLASS and OO class, appear.
Peter E. C. Dashwood
<G>.
> Thinking purely in OO, in the beginning, there was a single object -- the
> character. It came in three classes, and collections of these can be
> described with a picture clause.
Yes, but that PICTURE clause contains a recursive reference to the class...
That is where my objection to the analogy stems from.
I accept the remainder of the arguments. Furthermore, I agree that if you
consider it loosely, it is probably OK.
Pete
Peter E. C. Dashwood
No, that's OK, Rick. I agree that PHYSICALLY the Network model can represent
Owner/Member relationships. The problem is when you need to define LOGICAL
groups (and that is what is required in commerce most of the time).
The Network model does not require a single instance of an OWNER. (At least,
the ones I have worked with didn't. The Owner set could have multiple
members (instances)). If this is not true for the model you are presenting
then what you are saying is true. But you would then need an Owner Set for
every instance, and that sounds pretty impractical to me...) I believe this
to be a very contrived model and it is not what I would expect in reality.
It really isn't so important to me that I intend to spend more time on it.
Believe what you like. If you ever get around to building serious commercial
systems in the real world you will quickly find that what is in the
textbooks does not always agree with what is on the hard disks...
Is there any evidence to suggest that it is of the least interest to anyone
other than youself and the committed OO ers?
I see none...<G>
Doctor Codd certainly did what you say above but I believe it was in the
mid-to-late 70s. Again, I guess it really doesn't matter. I'm just not sure
what your point is...
> > Systems like IDMS and ADABAS (network model databases, in those days...)
> > simply couldn't be maintained as easily as the existing IMS DBs and,
> later,
> > the new RDBs (DB2 initially). However, it is true that the Network DB
> > performance was, for the most part, better than the other models.
> > (Eventually the others caught up and that is why we see very few network
> DB
> > implementations today.)
>
> I looked at some OO databases. Where it was mentioned,
> they used the relational model. Maintenance may be the issue.
> OO is very flexible in changing classes to adapt to needs.
> An OO database needs to be very flexible in accommodating
> those changes. Relational seems to fit better in that
> category.
>
There was a move a few years back to develop something called an "Object
Database" (some friends of mine were involved in it...) It doesn't seem to
have come to much. Despite your academic argument regarding purity etc. the
World has voted with its feet and for all practical purposes Relational
Databases prove adequate. Whether they supporting Structured or OO code.
I admire the research you have put in, Rick, but I regret you haven't
obtained a more pragmatic and practical result.
(But then, that's just me... as long as you are happy, your time was not
wasted <G>)
James J.Gavan
"Peter E. C. Dashwood" wrote:
I'll get back to Rick in due course seeing he mentioned lists/collectiions, but
just some background info on your para below :-
>
> There was a move a few years back to develop something called an "Object
> Database" (some friends of mine were involved in it...) It doesn't seem to
> have come to much. Despite your academic argument regarding purity etc. the
> World has voted with its feet and for all practical purposes Relational
> Databases prove adequate. Whether they supporting Structured or OO code.
Ed Arranga's/Frank Coyle's book published in '96 did make reference to an OO
(COBOL ?) DB - would be available in "COBOL '97". Next reference (not to DB) was
Doake and Hardgreave - features would be available in "COBOL '98". Whoops - we
slipped again - now we talk about "COBOL 200X" ( could it become 2002 ???) - No,
that's not an opener for you to lambast 'alphabet soup ' <G>
Recently picked up on a proposal for OO DB Classes to be added to the as yet
undefined Standard Classes (includes collections/dictionaries). Not knowing the
background on this topic, I did raise some queries. For the life of me couldn't
see why one needed a Standard method to do an SQL Connect, where the existing
SQL syntax does the job very nicely, thank you. As you are probably already
aware, I've got the SQL hived off into separate classes. Yes I *do* have a
method-id "connect" - but it is very customized to my own needs. Harkening back
to the W.W.II energy saving propaganda I asked, "Is your journey really
necessary ?".
Thane replied, J4 had arrived at the same conclusion. Phew ! Nice to know I
wasn't completely out to lunch <G>.
Jimmy, Calgary AB
Rick Smith
>
[snip]
>
> The Network model does not require a single instance of an OWNER. (At
least,
> the ones I have worked with didn't. The Owner set could have multiple
> members (instances)). If this is not true for the model you are presenting
> then what you are saying is true. But you would then need an Owner Set for
> every instance, and that sounds pretty impractical to me...) I believe
this
> to be a very contrived model and it is not what I would expect in reality.
> It really isn't so important to me that I intend to spend more time on it.
The SYSTEM as the first owner is either implicit (as you
experienced) or explicit (as I experienced).
Every set has a 1:M relationship, including my example.
It is sufficiently important to me that I cannot allow "impractical,"
"contrived," and "not ... reality" to go unanswered. <g>
Consider a simple data model for Order Entry:
System --> Customer
the system may have many customers.
Customer --> Order
each customer may have many orders.
Order --> Line Item
each order may have many line items.
System --> Shipper
the system may have many shippers.
Shipper --> Order
each shipper may ship many orders.
System --> Item
the system may have many items.
Item --> Line Item
each item may occur in many line items.
Now the object model:
Application --> Customer
the application holds an object reference to a customer.
Customer --> Order
the customer object hold an object reference to an order.
Order --> Line Item
the order holds an object reference to a collection of line items.
Order --> Shipper
the order holds an object reference to the shipper.
Line Item --> Item
the line item holds an object reference to an item.
[The last two items are reversed from the data model to
reflect the change of view from 1:M to M:1.]
None of these objects need to know the key of the object
referenced, in either the data model or the OO model.
To store the objects in a relational database, directly, the key
of the object referenced must by known to reconstruct the
relation. This "couples" the objects to each other such that
changes in the key in one object will affect other objects.
This "coupling" does not occur in a network database.
However, as it happens, it is possible to "decouple" the
objects when using a relational database. The pointers,
used in the network database, may be abstracted to
symbolic identifiers. If each object is given a unique
identifier, those identifiers may substitute for pointers.
The relation of owner to members may then be placed
into a relation table with columns <owner, member>.
The order of members may be established by
ORDER BY in an SQL statement or by extending the
relation table with an order column.
The effect is that a relational database may be used
to simulate a network database or, if you like, call
it an object-oriented database for business applications.
James J. Gavan
Rick Smith wrote:
Pete says your model is 'contrived'. I would suggest you are making OO bend over
backwards to treat everything as an object when on many occasions data can still
be considered as strings, (pic x/pic 9). Let me clarify that; Net Express allows
you to create Collections "ofReferences" (objects) or "ofValues" (strings),
although each string is still referenced by a 'pointer', (object reference).
When you want to *do* something with the data in the element, using
'ofReferences', you have to translate it back to a string; that step is
unnecessary if you go with 'ofValues'.
The only true advantage of object references, where they are 'ofReferences', is
for displaying, either Windows or the Web.
The model you illustrate, inevitably finishes up as an Invoice - it starts out
as a Purchase Order(s), becomes a warehouse Picking List(s) and after
confirmation of execution, becomes the Invoice(s).
The 'pieces' you illustrate are all there, but taking your example, I see no
justification for holding that mass as one lump in memory, (I'm referring where
you wrote earlier to all data(objects) being in memory, so I'm assuming you are
still on the same tack). As a design strategy, ignoring OO for the moment, I
would suggest the following applies to both Procedural and OO :-
- Header - CustomerID, his PO # and Order Date
- Line Item - Product ID, Qty, (purely from a design point of view, why would
you want to hold Line Item as a separate entity from Product ID ?)
Obviously there is more detail than I indicate above.
- Shipper - I'm guessing here you are referring to the contractor who is going
to move the goods on your behalf, as opposed to your own transport, so this
could be BR Rail (I know you don't call it that now) or perhaps the Unilever
subsidiary SPD.
I don't see that this is part of your initial 'Order set' - it only becomes
relevant when you get close to the warehouse picking phase, having established
tonnage and from your selective list of contractors, who fits the bill and has
transportation currently available. Including this in your original model only
bogs it down with unnecessary complexity.
- Header - CustomerID, his PO # and Order Date
- Line Item - Product ID, Qty.
Agreed if you were holding the above in memory as object references, then you
could get away with 'cross reference' between the Header and Line Items. God
help you though, if somebody accidentally knocks the three-pin power plug out of
the wall ! And as for suggesting it's ALL in memory for all orders - watch out
for the gentlemen arriving in white coats to take you off to the nearest funny
farm !
As a design concept, OO is not a mysterious topic, (I wish they had called the
concept pointers rather than objects), it essentially follows the same design
rules as Procedural, it just gives you some additional whistles and bells,
particularly and to me paramount, REUSABILITY, achieved through hierarchical
classes - reusability also being closely tied into Pete justifiably promoting
COMPONENTS.
I can visualize a model where a particular order is initially constructed as a
set of 'string' elements in either an ordered or sorted collection. (Same animal
as a W/S Table but has the ability to shrink and grow). Just because little Amy
Woodhouse has keyed the order into the application, doesn't mean that the
contractor has a driver sitting in his cab, engine running and ready to roll as
soon as the goods have been put into his wagon.
There are time delays between the business phases and you have to store that
order as persistent objects for subsequent retrieval. (I know you're reading
this Warren - that's another $10 phrase for saying archive the order to a COBOL
file or DB <G>). Rick, I'm going to ignore your reference to network DB - let's
go with what we *actually* have, RDBMS
Of necessity, your COBOL file/DB Table must have links cross referring those
order 'elements' and I just don't see them as something nasty called 'foreign
keys'. Why Mickey Mouse around coupling or de-coupling just to keep 'pure OO'
happy ?
Good try Rick - give it another shot. OO is no different to Procedural if you
want KISS <G>
Jimmy, Calgary AB
Judson McClendon
>
> Well 95% of the world's population doesn't care about 'Un-American'
> because we ain't Americans
True enough.
> and don't want to be.
Wow! That will be news (and a relief) to the U.S. Immigration and
Naturalization Service! Up to now, they've been totally swamped with requests
to come here. Not to mention the millions who sneak in here illegally every
year anyway. :-)
--
Judson McClendon j...@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
James J. Gavan <jjg...@shaw.ca> wrote in message
news:3D4AF051...@shaw.ca...
>
>
> Rick Smith wrote:
>
[snip]
>
> Pete says your model is 'contrived'.
Based upon the prior discussion, Pete is not qualified
to make the statement.
[snipped the irelevant]
>
> The model you illustrate, inevitably finishes up as an Invoice - it starts
out
> as a Purchase Order(s), becomes a warehouse Picking List(s) and after
> confirmation of execution, becomes the Invoice(s).
Interesting, except that the model I illustrate, is a framework --
a design pattern for creating applications for entering different
types of orders. I never specified the type of order. <G>
> The 'pieces' you illustrate are all there, but taking your example, [snip]
> As a design strategy, ignoring OO for the moment, I
> would suggest the following applies to both Procedural and OO :-
>
> - Header - CustomerID, his PO # and Order Date
> - Line Item - Product ID, Qty, (purely from a design point of view, why
would
> you want to hold Line Item as a separate entity from Product ID ?)
>
> Obviously there is more detail than I indicate above.
But, the above does not apply to the framework.
> - Shipper - I'm guessing here you are referring to the contractor who is
going
> to move the goods on your behalf, as opposed to your own transport, so
this
> could be BR Rail (I know you don't call it that now) or perhaps the
Unilever
> subsidiary SPD.
Or, the person or department responsible for the repair
for a repair order.
Or, the supplier for an equipment requisition.
Or, etc.
> I don't see that this is part of your initial 'Order set' - it only
becomes
> relevant when you get close to the warehouse picking phase, having
established
> tonnage and from your selective list of contractors, who fits the bill and
has
> transportation currently available. Including this in your original model
only
> bogs it down with unnecessary complexity.
>
> - Header - CustomerID, his PO # and Order Date
> - Line Item - Product ID, Qty.
Order Date may be usable for all orders, quantity may be usable
for line items; but including the other information in the framework
hinders reuse of the framework.
[snip]
>
> As a design concept, OO is not a mysterious topic, (I wish they had called
the
> concept pointers rather than objects), it essentially follows the same
design
> rules as Procedural, it just gives you some additional whistles and bells,
> particularly and to me paramount, REUSABILITY, achieved through
hierarchical
> classes - reusability also being closely tied into Pete justifiably
promoting
> COMPONENTS.
But, you seem to be missing the concept of the reusabliity of
frameworks through composition by aggregation. (Composition
by aggregation is the conterpart to composition by inheritance.)
[snip]
>
> Of necessity, your COBOL file/DB Table must have links cross referring
those
> order 'elements' and I just don't see them as something nasty called
'foreign
> keys'. Why Mickey Mouse around coupling or de-coupling just to keep 'pure
OO'
> happy ?
The open/closed principle applies. A class is open for extension;
but closed for modification.
If you put, into a class, definitions that depond upon a representation
in another class, you make the class not reusable. Also, violation of
the open/closed principle is lot like using GO TO in structured
programming. As long as that part of the program needs no
modification, it does little harm. If it does need modification, it
may be a major headache.
> Good try Rick - give it another shot. OO is no different to Procedural if
you
> want KISS <G>
It is different, if you want to do right. <G>
Data modelling in the network "paradigm" distinguishes between
the relationship and the related classes. This allows classes to
be used in different contexts, i.e., reusability.
Peter E. C. Dashwood
> >
> > Pete says your model is 'contrived'.
>
> Based upon the prior discussion, Pete is not qualified
> to make the statement.
>
Hahaha! I question your qualification for deciding I am
unqualified...<G>
(Or is it just that anyone who disagrees with you is unqualified?)
Go and develop some actual systems using the principles you are
advocating, Rick. When you've done that for thirty odd years we'll
talk again...<G>
Pete.
John Bradley
> One problem is that it precludes any kind of shareware approach to
> marketing. I feel that being able to distribute demonstration copies
> absolutely vital to modern marketing, so by precluding the selling in the
> runtime, you are disabling a *very* large proportion of the market.
Donald,
This is a good point. In our case, we have a special runtime
configuration that is "bound" to a specific application (the
customer's demo). These can be freely distributed.
John
John Bradley
<snip ...>
> Thanks for your candour as a CEO in taking the time to contribute here. But one
> further insidious thing about runtimes. You've no doubt seen messages from Pete
> Dashwood promoting the Component concept. There's a big market for them. Not
> deliberately excluding the others, but with their GUI support it is possible
> from Fujitsu or Net Express for a COBOL developer to come up with a real doozy
> of a component.
>
> It could potentially have a very wide market - likely the developer would put a
> modest retail price on the end product, (going for volume), but now add the
> runtime royalties to the developer's cost to be passed on to end users ???
>
Jimmy,
I'm not trying to defend runtime fees for all situations. I think
there are many for which they are a very poor alternative, given what
the user [of COBOL] is trying to accomplish and the market in which he
competes. I think your example is one for which our traditional model
does not fit very well. There are others.
The key point I was trying to make is that for a certain type of COBOL
vendor (a company dedicated [i.e., no "collateral" sources of revenue]
to satisfying the market demand for an industrial strength,
platform-neutral COBOL application environment), runtime fees are
probably the only viable way to have a business. Anything else is
smoke and mirrors. Like any other business, if these companies find
that there is no market for their COBOL products that can yield a
profit, they will serve a different market. So far, we do not find
this to be the case in our market. I just wanted to help this audience
understand that this is the simple reason for runtime fees that
applies (I believe) to all of the vendors that presently charge such
fees.
An inference that can (and should, in my opinion) be drawn is that if
all (or most) of the COBOL market does demand "free" runtimes (i.e.,
no cost burden on application deployment that flows back to the COBOL
vendor), the only suppliers of COBOL at that time will be companies
that have some other strategic business interest beyond the language
and its runtime software environment.
> And I always come back to this one - Joe Blow drives his new taxi cab out of the
> showroom. As he hits the highway a salesman rushes out from the showroom
> shouting, "Don't forget each time you pick up a fare, you are obliged to give us
> a piece of the action". I rather think not, in the rest of the commercial world.
In our case, a closer analogy would be: Joe Blow buys his new taxi
for about 10% of its cost to manufacture, the dealer having informed
him during his selection process that if he is successful in his new
business, he will be expected to send in some of his income derived
from using the taxi. I'll resist the temptation to expand the
metaphor to include the alternative taxi vendors, and their quid pro
quo (g).
Thanks, I enjoyed the opportunity to engage this lively group!
John
Donald Tees
Are you saying that you have a separate runtime that can be used as long as
everything is statically linked, or are you saying that you make an
exception for demos? If the former, is the dynamic linking the only
difference, and if the later, what steps to I have to take to get
permission?
Donald
Donald
Judson McClendon
>
>(...)
>
> The key point I was trying to make is that for a certain type of COBOL
> vendor (a company dedicated [i.e., no "collateral" sources of revenue]
> to satisfying the market demand for an industrial strength,
> platform-neutral COBOL application environment), runtime fees are
> probably the only viable way to have a business. Anything else is
> smoke and mirrors. Like any other business, if these companies find
> that there is no market for their COBOL products that can yield a
> profit, they will serve a different market. So far, we do not find
Neither did Apple find it to be the case either, when they started playing
hardball with *their* customers, back in 1979. Now, instead of the major
PC vendor in the world, they are a marginal market, at best. I and others
here believe runtime fees to be unfair and harmful to our businesses. Just
don't forget that *we* are your market. How many runtimes are you going
to sell if *we* stop developing with your product? Remember, business
is business, *until* you offend a customer. From then on, price does not
matter, and performance does not matter, with that customer. Any
company, including yours, offends their customers to the inexorable
detriment of their business. Rule number 1 in business is: don't screw
your customers, or it will kill you in the long run. Only one offended
customer can do more harm than 10 happy customers. Just because the
results aren't quickly seen does not mean they are less certain.
Grinder
new taxi cab out of the
> > showroom. As he hits the highway a salesman rushes out from
the showroom
> > shouting, "Don't forget each time you pick up a fare, you
are obliged to give us
> > a piece of the action". I rather think not, in the rest of
the commercial world.
>
> In our case, a closer analogy would be: Joe Blow buys his
new taxi
> for about 10% of its cost to manufacture, the dealer having
informed
> him during his selection process that if he is successful in
his new
> business, he will be expected to send in some of his income
derived
> from using the taxi. I'll resist the temptation to expand
the
> metaphor to include the alternative taxi vendors, and their
quid pro
> quo (g).
Hmm, perhaps COBOL compilers are just that much better, but the
upfront cost for these tools on the PC, are significantly
higher than those for other languages. If 10% is correct, that
makes the MSRP about ten times the cost of other enterprise
tools.
Surely there's some inertia at work here. Runtime fees may not
be enough to drive developers out of their existing
environment, but it has to be discouraging those making a
technology selection.