Liant (RM/Cobol) purchased by Micro-Focus

What's the poop here. Is RM/Cobol doomed to go away?

I don't know anything about it, but see:
http://microfocus.com/Liant/index.asp
and
http://microfocus.com/AboutMicroFocu...0711161533.asp

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Iles" <bobi@core.com> wrote in message
news:55db1$4877722e$d0665605$20900@FUSE.NET...
> What's the poop here. Is RM/Cobol doomed to go away?

"Robert Iles" <bobi@core.com> wrote in message
news:55db1$4877722e$d0665605$20900@FUSE.NET...
> What's the poop here. Is RM/Cobol doomed to go away?

ALL COBOL is doomed to go away... sometime. :-)

RM may be sooner than some other variants, although MicroFocus have stated
committment to keeping it.

As the new Management at MF are far from stupid, they are probably looking
at how best to integrate the two products and maximise ROI.

Rather than "go away" it may reappear in a new set of clothes...

Pete.
--
"I used to write COBOL...now I can do anything."

My best guess (and it is ONLY a guess) is that it will be treated much as the
AcuCorp acquisition was.

The one BIG thing that MAY turn out to be interesting, is that MF will now have
a PL/I compiler "of their own". They used to include a PL/I option with a
re-badged IBM (OS/S? Windows?) compiler, but I think this MAY be of interest to
some IBM mainframe shops.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:6dqbguF3t05mU1@mid.individual.net...
>
>
> "Robert Iles" <bobi@core.com> wrote in message
> news:55db1$4877722e$d0665605$20900@FUSE.NET...
>> What's the poop here. Is RM/Cobol doomed to go away?
>
> ALL COBOL is doomed to go away... sometime. :-)
>
> RM may be sooner than some other variants, although MicroFocus have stated
> committment to keeping it.
>
> As the new Management at MF are far from stupid, they are probably looking at
> how best to integrate the two products and maximise ROI.
>
> Rather than "go away" it may reappear in a new set of clothes...
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>

> As the new Management at MF are far from stupid, they are probably looking
> at how best to integrate the two products and maximise ROI.
>
> Rather than "go away" it may reappear in a new set of clothes...
>

I do not think so. My guess is (as Bill put it) that most mainframe/
mid-range platforms are run by these companies, they have a
'maintenance assets' on their shoulder. Aside from having their own
devtools on such bigger platforms.... I think they'll be extracting
juices from it.

Maintaining 'old' and even continued updates of mainframe (and mid-
range) hardware will still take them a long way.

Computer language support though is another battlefield to be won,
right now they're winning the battle on mainframes. On the PC-based
side, who knows.... Pete is a convert which I think PC-based devtools
are much easier nowadays. MF NetExpress has alternative though. Which
way MF will turn, they'll have the ball.

Licensing fees? Nah, even open source need support fees.

"Rene_Surop" <infodynamics_ph@yahoo.com> wrote in message
news:e893f814-cfa6-4167-b158-4092e390b740@k13g2000hse.googlegroups.com...
>> As the new Management at MF are far from stupid, they are probably
>> looking
>> at how best to integrate the two products and maximise ROI.
>>
>> Rather than "go away" it may reappear in a new set of clothes...
>>
>
> I do not think so. My guess is (as Bill put it) that most mainframe/
> mid-range platforms are run by these companies, they have a
> 'maintenance assets' on their shoulder.

Sorry, not sure of your intended meaning here. Do you mean that most
mainframe/ mid range platforms are running MF software, or that MF is
running mainframe/mid-range platforms, and who has the "maintenance assets"
on their shoulder? MF or mainframe/mid-range companies?

I know English is not your first language, Rene, and I have tried todecipher
meaning, but I am just confused by the above.

Can you restate it in a different way?

If you are saying that companies running mainframe/mid-range platforms need
to maintain these platforms and using MF products can help? I guess that
would be true.

However, the problem is not with maintaining current assets, it is about
leveraging them into the future. Just because something has been fine in the
past doesn't mean that it is good for the future. Marketplaces and tech
environments change. User expectations become higher as they see what other
people (especially their competitors) have available. The old procedural
model running on a centralised mainframe may have been fine for the last
century but it isn't going to hack it in this one. Distributed systems using
networking, and especially the Internet, are simply cheaper, more
accessible, and more dynamically responsive than the old centralised model.
However, procedural languages are not even "well" suited for this
environment.

So, it isn't about maintaining COBOL because that's what we've got. (Except
in the very immediate future, of course...) It is about seeing a pathway to
ensure better service in the long run, and guarantee the company's IT assets
and support for the duration. Even the mainframe sites where Fortress COBOL
is still alive and well are starting to realise that it can't last. They are
looking for alternatives to get them into the OO playground (kicking and
screaming in some cases...) and vendors like IBM are providing migration
paths to help them. (Java is a player here...) SOA is one useful way to
leverage existing assets. Wrapping existing code as a service buys time and
helps to rationalise the reuse of current code. Refactoring is an essential
step along the migration path and nobody wants to throw the baby away with
the bath water. Companies like MicroFocus are well placed to provide tools
and support for bridging between procedural and non-procedural code. (Part
of their product set is designed to increase programmer productivity by
moving development off the mainframe. As workstation familiarity grows with
developers, they are more likely to be receptive to distributed networked
systems and the use of objects. Even if they're not, there is a rising
generation who are completely comfortable and familiar with the concepts and
who will expect to implement systems differently from the way we did in the
latter part fo the twentieth century.)

Whether MF will place themselves to assist migration or not is entirely a
matter for them and the future will reveal their plans. I don't believe they
will invest long term in a future for COBOL, but I could be wrong... I
believe that if they do, it will be disastrous for both them and their
customer base...However, given that they have a strong current customer base
for COBOL they only have two options:

1. Continue support for COBOL indefinitely and watch their customer base
evaporate by attrition. (There is also very high risk in being a "one trick
pony"...
2. Provide one or more pathways for migration away from COBOL, but making
maximum use of existing assets.

Which option would you pursue if you were them :-)?


>Aside from having their own
> devtools on such bigger platforms.... I think they'll be extracting
> juices from it.
>
> Maintaining 'old' and even continued updates of mainframe (and mid-
> range) hardware will still take them a long way.

Hardware is not really that important. It will continue improving as it has
done, although even Moore says that his law has reached its expiry date and
no longer applies.

>
> Computer language support though is another battlefield to be won,
> right now they're winning the battle on mainframes.

I disagree :-). Even the staunchest mainframe COBOL sites are looking for
other options, long term. They obviously can't just drop it, but as a long
term solution it is a non-starter.

>On the PC-based
> side, who knows.... Pete is a convert which I think PC-based devtools
> are much easier nowadays.

I am certainly persuaded the toolset is better for non-procedural
development on workstations. However, even if all the facilities of VS 2008
were available with COBOL (and they are if you use Fujitsu NetCobol for
..NET), it still doesn't give you the facilities that other languages do, and
it costs a lot more, even without the consideration of runtime fees (if you
are running NetExpress). It costs more to maintain thousands of lines of
code than it does to "maintain" components. Much more. This lesson is
starting to be learned. Even with cheap outsourcing (where you are
relinquishing control over the maintenance process to a large extent, and
encountering quality, delivery, and communication issues....) it simply
isn't enough to cobble thousands of lines of code into a working system and
expect it to compete with component based systems that utilise platform
components as if they were part of the OS, which can be quickly assembled
(or knocked down and reassembled) with visual tools, and which do not
require extensive infrastructure and system programming support to keep
running.

>MF NetExpress has alternative though. Which
> way MF will turn, they'll have the ball.
>

Possesion is an important part of winning any (foot)ball game, but, by
itself, it doesn't guarantee points on the board... :-)
(It pains me to write this, as the All Blacks lost the second test to South
Africa last night, by a whisker...It is a very quiet Sunday here :-))

> Licensing fees? Nah, even open source need support fees.

Spoken as one who doesn't have to run a viable commercial business... :-)

Why would I use NetExpress (for example...) and have to pay for every
deployment of my COBOL application, when I can write it in C# and deploy and
run it for absolutely free? (Not to mention I can do it more painlessly,
more quickly, and have more facilities available for inclusion in it?)

It isn't difficult arithmetic... :-)

Pete.
--
"I used to write COBOL... now I can do anything."

In response to comments in the Liant thread (in CLC), it is my understanding
that the Micro Focus "strategic" (and tactical) plans include providing support
and tools for:

1) Offloading of development for (IBM) mainframe (z/OS and z/VSE) applications
that are intended to RUN (in "production) on those mainframes.

2) Provide support and tools for shops that want to offload to Unix, Linux,
Windows etc of applications that are currently running (for production) on
mainframes - but for those who want to retain (for the moment and/or for the
future) some or all of the code in the original COBOL (ASM and now PL/I) source
code. (This also includes shops that want to retain things like CICS for use on
these workstation and *nix production environments.)

3) To provide tools and support for shops that want to do new development (and
enhancement to existing applications) on Workstation (and *nix) platforms -
where the code is in COBOL (and I would guess now for applications with PL/I as
well).

***

The exact "balance" between these 3 varies from year to year and *MAY* change in
the future. However, MF provides tools and products, for all of these.

I do not see Micro Focus currently (or in the near future) providing paths AWAY
from COBOL (and/or PL/I) - unless you consider things like Dialog Systems to be
"away" from COBOL.

***

I do NOT speak for Micro Focus on this - and I certainly do not know exactly how
the recent Liant (and last year's AcuCorp) acquisitions fit into this exactly.

I don't know how MF's current income is divided between these 3 types of
"users". My guess (and it is only a guess) is that the 3rd provides for a
smaller portion of current income that the first two. How the first two compare
in providing MF income, I can't even guess at - but I do think that TOGETHER
that is where most of their current income comes from - as will the income in
the foreseeable future. The Liant acquisition will fit "nicely" with both of
these first two. From watching comp.lang.pl1, I think that the 3rd is even LESS
of an issue for PL/I than it is for COBOL, but I certainly could be mistaken on
this.

--
Bill Klein
wmklein <at> ix.netcom.com

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:nTuek.241984$Ev5.23060@fe09.news.easynews.com ...
> In response to comments in the Liant thread (in CLC), it is my
> understanding that the Micro Focus "strategic" (and tactical) plans
> include providing support and tools for:
>
> 1) Offloading of development for (IBM) mainframe (z/OS and z/VSE)
> applications that are intended to RUN (in "production) on those
> mainframes.
>

They were amongst the first to do this and a a leader in the field. I was
the instigator for getting the IBM software house in North Harbour
(Southampton, England) moved to this platform in the late 1980s.

> 2) Provide support and tools for shops that want to offload to Unix,
> Linux, Windows etc of applications that are currently running (for
> production) on mainframes - but for those who want to retain (for the
> moment and/or for the future) some or all of the code in the original
> COBOL (ASM and now PL/I) source code. (This also includes shops that want
> to retain things like CICS for use on these workstation and *nix
> production environments.)

A major portion of current business.

>
> 3) To provide tools and support for shops that want to do new development
> (and enhancement to existing applications) on Workstation (and *nix)
> platforms - where the code is in COBOL (and I would guess now for
> applications with PL/I as well).
>
> ***
>
> The exact "balance" between these 3 varies from year to year and *MAY*
> change in the future. However, MF provides tools and products, for all of
> these.

Yes, I'd agree. However, I think the third one will disappear within 7
years.

>
> I do not see Micro Focus currently (or in the near future) providing paths
> AWAY from COBOL (and/or PL/I) - unless you consider things like Dialog
> Systems to be "away" from COBOL.

I guess it depends what you mean by "near future". Certainly not this
week... :-) However, market forces are at work and they have always proven
to be irresistible in the past. I see no reason to think they won't be in
this instance.

Having said that, I accept that there is still a lot of "COBOL think" within
the user base (and MicroFocus itself...) which makes it hard for many people
inside and outside the organisation to see what is happening in the real
world. It isn't about retaining COBOL (or PL/1 or Assembler) as viable
development languages, it is about a completely changing paradigm that HAS
to be OO and component based. The COBOL and PL/1 user bases both missed the
OO boat, and it is far too late to recall it to the jetty.

There is a new generation of users and developers (I was talking to some of
them yesterday and it was very stimulating; quite amazing to see the thngs
they take for granted and expect as basic computing capability...) and their
demands for functionality will not be met by procedural code.

Many of the established things we take for granted, like paper invoices and
statements will simply be obsolete as new transactional methods of trading
become commonplace. At the moment, people have a choice whether they use
cheques or EFTPOS, for example, but they can't take bullion to the Bank or
demand gold for paper currency (as they once could). In the future there
will be no cheques and there will be no choice. As populations explode and
transaction volumes skyrocket, it will simply be non-viable to process
trilions of bits of paper just so an ever diminishing minority of the
population can feel secure. This popular demand, allied with advanced and
much more powerful technology, will, more than anything else, spell the end
of procedural (and, eventually, batch...) processing.

When you can see the status of your accounts and trace transactions at any
moment, in real time, on your PDA, you won't be concerned about paper. Even
third world countries in Africa are doing telephone banking from mobile
phones already, and the mobile phone is changing the world...
(http://www.nytimes.com/2008/04/13/ma...pagewanted=all)

The rising generation take these things as read. Some of the group I was
with yesterday were amazed when I told them I had never seen TV until I was
their age (early teens). They are all computer literate and use spreadsheets
search engines and databases as a matter of course. Most of them are
accessing the Internet from cell phones and PDAs. Text messaging and email
are becoming passe and being replaced by twitter; video and sound are
considered fundamental and basic.

In 10 years time I don't see them using batch processes...

Having spent a lifetime in IT it is easy to fall into "accepted ways" of
approaching problems. The people who will replace us have no such
constraints.

For them, writing thousands of lines of code to program a computer would be
like us writing a thesis in pig latin.

>
> ***
>
> I do NOT speak for Micro Focus on this - and I certainly do not know
> exactly how the recent Liant (and last year's AcuCorp) acquisitions fit
> into this exactly.
>
> I don't know how MF's current income is divided between these 3 types of
> "users". My guess (and it is only a guess) is that the 3rd provides for a
> smaller portion of current income that the first two. How the first two
> compare in providing MF income, I can't even guess at - but I do think
> that TOGETHER that is where most of their current income comes from - as
> will the income in the foreseeable future.

We might disagree about "foreseeable" here, Bill... :-) Basically, I do
agree with your statement, though.


>The Liant acquisition will fit "nicely" with both of these first two. From
>watching comp.lang.pl1, I think that the 3rd is even LESS of an issue for
>PL/I than it is for COBOL, but I certainly could be mistaken on this.
>

Pete.
--
"I used to write COBOL...now I can do anything."

On Sat, 12 Jul 2008 12:17:33 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>> What's the poop here. Is RM/Cobol doomed to go away?
>
>ALL COBOL is doomed to go away... sometime. :-)

All existing computer languages are so doomed - at least as languages
used for real work.

"Howard Brazee" <howard@brazee.net> wrote in message
news:qktm74944el40ime2h3tr780l3f378qac4@4ax.com...
> On Sat, 12 Jul 2008 12:17:33 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>> What's the poop here. Is RM/Cobol doomed to go away?
>>
>>ALL COBOL is doomed to go away... sometime. :-)
>
> All existing computer languages are so doomed - at least as languages
> used for real work.

Probably.

However some will be around longer than others.

It isn't about languages as such, it is about whether or not they support
the OO paradigm, and do so easily and elegantly.

Languages that don't, simply have no place in the future. Notice that all
the "sexy, new" languages are based around this paradigm.

More importantly, programmers that don't, have limited lifetimes, or are
"sentenced" to a narrow niche marketplace which is gradually disappearing
anyway...

Pete.
--
"I used to write COBOL...now I can do anything."