conversion from Microfocus NetExpress COBOL to Fujitsu netCOBOL.net

[anonymous]

Hello,

Has anyone successfully converted Microfocus NetExpress Cobol with imbedded SQL (pre compiled with Pro*COBOL) to NetCobol.net from Fujitsu?

Can you point a novice (in COBOL) to a valuable place to look for help?

Thanks

[Richard]

If it were to be done then it probably should not be done by a novice
in COBOL.

One restriction is that the SQL catered for in Fujitsu COBOL is only
what the Fujitsu manual specifies is valid which is not the complete
SQL syntax, nor the complete ODBC. In particular it allows: CONNECT,
DISCONNECT, SELECT, DELETE, UPDATE, INSERT, OPEN, CLOSE, FETCH; but
not, for example CREATE or DROP.

If the Microfocus COBOL has SCREEN SECTION or ADIS (Accept Display
CRT) then it may be difficult (or impossible) to get the user
interface working the same way.

There are many Microfocus-isms that are not supported by Fujitsu.

I have done some MF -> Fujitsu conversions, but not .net.

[Pete Dashwood]

http://primacomputing.co.nz

Migration tools are available to automate most of what you will need to do.

Understand that moving to NetCOBOL.Net may not be a good long term move.

Pete.

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

[Alistair Maclean]

I recommend that you look at the Prima Computing link that Pete
Dashwood provided.

In addition to Richard's comment about the differences between the two
compilers' implementations of SQL, please be advised that the PREPARE
and EXECUTE instructions allow FUJITSU to PREPARE a SELECT which is
EXECUTED with additional clauses added in the EXECUTE statement
whereas the MicroFocus implementation does not allow the EXECUTE
statement to specify additional clauses on the SELECT eg:

PREPARE select......

EXECUTE prepared-statement WHERE ABS = "sdf"....

would be allowed by Fujitsu and disallowed by MF.

[saur...@gmail.com]

Thank You Pete sending the link. I look forward to finding valuable information on your site.

We mostly want to move away from MF runtime license fee requirements and some conversion requirement we see from MF are unfeasible for us.

I do wonder why you think it's not wise to move NetCOBOL.net from Fujitsu?

Thanks
Saurabh

[HeyBub]

It's like having a baby: The project will be long, fraught with worry,
uncomfortable, and even painful.

But it's WORTH it.

[Pete Dashwood]

There is nothing wrong with the product; like the Micro Focus Visual COBOL
it is excellent.

The fact is you simply don't need it. These compilers represent an expensive
investment in a Language that you are trying to move away from.

If you are moving to .Net there are FREE .Net languages which do the job far
better than ANY version of .Net COBOL. (C#, VB.Net) because they have been
designed for .Net. (COBOL obviously hasn't.)

But it goes deeper than that. The COBOL paradigm is just wrong for a
networked solution like .Net. The network needs OBJECTS (and layers); COBOL
is NOT good at that.

It isn't that you CAN'T do it, it is just not the best way to do it. (You
CAN start a fire by rubbing two sticks together...when was the last time you
did that :-)) .Net COBOLs do support objects, but it soon becomes apparent
that the .Net languages do so better. (And quicker, and cheaper.) .Net COBOL
is therefore not a good long term investment.

However, most companies have a large investment in COBOL code which they
really don't want to throw away. (Some companies are happy to bite the
bullet and go for a completely new solution, but it all comes down to costs
and risks and is really an individual decision; there is no "one size fits
all.")

Based on my own experience in moving my own company's software to .NET I
developed tools that can automate the process. You can use your existing
COBOL compiler to refactor your COBOL code and wrap it in InterOP services
so it runs fine under .Net. All your new development would be in a .Net
language (we recommend C#, and we use it ourselves) and both the Legacy code
and the new code work as objects sharing the same database (which is
generated, along with a set of Data Access Layer Objects, by the PRIMA
Toolset.) Everything in the new environment is objects, and the legacy code
is automatically modified by our tools so it can also use the DAL objects.
In this way, everything plays nicely on the .Net playing field, the legacy
is brought into the same game (which buys you time to phase it out and
replace it), and you move to a 21st century implementation of your
applications. You are no longer tied to COBOL, though you CAN continue using
it if you want to.

PRIMA is unique in that we don't just move COBOL onto a different platform;
we actually re-factor it so it can work in the way that platform is designed
to work, and so that it won't degrade the performance of new applications
being developed in new languages for that platform.

You can use the existing COBOL compilers from Micro Focus and Fujitsu (which
are also excellent products, and very much cheaper than .Net COBOL; in fact,
if you are a "COBOL shop" you probably already own one of them...) to lever
the existing COBOL investment into .Net.

Our Toolset automates the following processes:

1. Creation of an optimized Relational database in second or third Normal
form, fully loaded with all of your existing data which is currently held on
indexed files. (The load programs are generated by the Toolset and can be
easily amended if required to filter old data that is no longer required for
the new database. Mostly people don't amend them, but we have had clients
who did and were glad of the facility. They are generated in COBOL so your
existing programmers can amend the load logic easily if you want to do that.
There is a video of this process on the PRIMA site at:
http://primacomputing.co.nz/COBOL21/demosandtutorials.aspx

(Take the 5 cent tour...)

Other videos explain more conceptual background as to why we use the
approach we do, and give more detail about the Data Conversion process.

Data and Code Conversion are steps on the way to complete Migration.

2. The creation of a separation layer between your applications and the new
database. Applications have all the existing COBOL code to do indexed file
access removed from them and it is replaced by invokes of DAL object
methods. This is all fully automatic. The COBOL legacy runs exactly as it
did before, but now it is using the new database. This means there is no
need for overnight batch runs to synchronise legacy files with the database,
and it means that new development can access the legacy data immediately.

We are currently looking at tools to separate the presentation layer for
things like PowerCOBOL and legacy that uses DIALOG/Panels or COBOL Screen
Section, and more tools to refactor COBOL processes from called and
performed modules and subroutines.

Our commitment is to leveraging COBOL legacy into a true Object Oriented
environment and enabling it to run there alongside, and exactly like,
applications that were built for that environment from scratch.

We don't see COBOL as a long term solution for the .Net environment, and
that is why I wouldn't recommend people to buy an expensive .Net COBOL
compiler. (The PRIMA Migration Toolset costs around half what the Fujitsu
.Net Compiler costs...)

There is much more than I can go into here and I don't want to use this
forum as a sales platform. You asked a question, I have tried to answer it,
but PLEASE browse COBOL21 and PRIMA sites, see the processes in action, and
if you want to discuss anything about our approach or have questions
regarding it, post here or mail me privately. Both sites have links to this
newsgroup and we give away stuff which many people have found useful.

The fact is that getting the best from COBOL legacy involves a lot more than
a platform migration.

[Pete Dashwood]

Until your kid grows up, gets into drugs and violence and then becomes a
serial killer... :-)

[docd...@panix.com]

In article <9fpb1...@mid.individual.net>,

What's the matter, Mr Dashwood... embarassed at the thought of having your
progeny join the constabulary?

DD

[Pete Dashwood]

Alistair is right, and there are quite a few differences, dynamic SQL being
only one of them.

Sadly, different RDBMS can respond differently to dynamic SQL, too.

I found out yesterday that some dynamic SQL which works fine on two RDBMs
returns an S1000 SQLSTATE on another. I fixed it by swapping connections in
the code, but it is annoying.

Fortunately, if there is no SQL in your applications, (we move it all out to
a separate Data Access Layer) it is pretty easy to deal with annoyances like
this, and know that it won't affect your application.

I was at a Microsoft developers monthly meeting last night and they had a 2
hour video of windows 8 and items of interest to developers.

The whole ida of preferred computer programming languages will become moot.
I saw Metro applications for win 8 which were written in HTML5 and
Javascript. The same apps could have been written in Silverlight, or C++, or
C# or VB or anything they support and the results would be exactly the same.
(Sorry, COBOL is not in the club...)

Instead of Visual Studio supporting your language of choice, you just decide
what you want to use today and you can mix and match whatever you want. (I
think MS were very conscious of the existing skillbase and the preferences
programmers have. In effect, you can leverage whatever skill you currently
have into Metro very easily.) Your finished application will run on ANY
windows platform (desktop, web, mobile, tablet, whatever...) It is acheived
because there is now a windows Run Time (win RT) which can be used by ANY of
the supported languages. Rather than a series of APIs it is simply Classes
that become objects you can use. None of it was particularly earth
shattering but it was a logical progression from .Net. They are guaranteeing
compatibility so .Net applications can run as they are or can be rewrapped
as Metro. It all looked like fun and I will load a copy of the pre-release
onto a virtual machine and try some of it as soon as I get some time.

The great "leveller" in all this is XAML. All of the languages will generate
XAML and visual Studio is being enhanced to provide more XAML manipulation
tools. It was quite impressive to see three lines of XAML connecting to
Facebook and dragging images back to a phone or desk. A lot of tedious stuff
with connections and so on is now abstracted into the RT and just becomes a
method invoke.

I like using C# code-behinds for web pages (and I still will be able to).
But now I can pass those same pages to Visual Studio and have them
re-invented to use the Metro UI (this is a tiled interface and it is pretty
sexy).

"Programming" has come a long way.

[Pete Dashwood]

I have a young friend who is seriously considering joining the Police force
at the moment. He is a good decent kid with a genuine desire to do something
worthwhile. His mother is having a fit and I am being very careful not to
say anything that could be used against me... :-)

To be honest, there is part of me that wants to see him succeed and do what
he aspires to, but there is another part that says it is too risky. I don't
mean risky in the sense of cops being in danger from the public; I mean
risky in the sense of him having all the decency knocked out of him by other
cops...

I have the utmost respect for people in Law Enforcement and wherever I can,
I support them. ("If you don't like Cops, next time you're in trouble, yell
for a Hippie...")

But I also read the papers...

[Howard Brazee]

On Fri, 14 Oct 2011 13:28:12 +1300, "Pete Dashwood"
<dash...@removethis.enternet.co.nz> wrote:

>To be honest, there is part of me that wants to see him succeed and do what
>he aspires to, but there is another part that says it is too risky. I don't
>mean risky in the sense of cops being in danger from the public; I mean
>risky in the sense of him having all the decency knocked out of him by other
>cops...

And we certainly are better off when some of the best people succeed
at becoming good cops.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison

[docd...@panix.com]

In article <9fpe0s...@mid.individual.net>,
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:

[snip]

>> What's the matter, Mr Dashwood... embarassed at the thought of having
>> your progeny join the constabulary?
>
>I have a young friend who is seriously considering joining the Police force
>at the moment. He is a good decent kid with a genuine desire to do something
>worthwhile. His mother is having a fit and I am being very careful not to
>say anything that could be used against me... :-)
>
>To be honest, there is part of me that wants to see him succeed and do what
>he aspires to, but there is another part that says it is too risky. I don't
>mean risky in the sense of cops being in danger from the public; I mean
>risky in the sense of him having all the decency knocked out of him by other
>cops...
>
>I have the utmost respect for people in Law Enforcement and wherever I can,
>I support them. ("If you don't like Cops, next time you're in trouble, yell
>for a Hippie...")
>
>But I also read the papers...

I've not only read newspapers, Mr Dashwood; I've also socialised with
officers ranging from the rawest recruits to the Faces in the Local
Newspaper. My conclusion is that if there is a sub-set of society that
loves putting on clothing that makes them a target in the eyes of others,
strapping on a gun, a club and running up stairs to break down doors and
look for trouble...

... then - as a taxpayer - I'd much rather folks belonging to this sub-set
be on my payroll.

'Whoever fights monsters should see to it that in the process he does not
become a monster.' - F Nietzsche, 'Beyond Good and Evil', 147

DD

[HeyBub]

Pete Dashwood wrote:
>>
>> What's the matter, Mr Dashwood... embarassed at the thought of having
>> your progeny join the constabulary?
>
> I have a young friend who is seriously considering joining the Police
> force at the moment. He is a good decent kid with a genuine desire to
> do something worthwhile. His mother is having a fit and I am being
> very careful not to say anything that could be used against me... :-)
>
> To be honest, there is part of me that wants to see him succeed and
> do what he aspires to, but there is another part that says it is too
> risky. I don't mean risky in the sense of cops being in danger from
> the public; I mean risky in the sense of him having all the decency
> knocked out of him by other cops...
>

Ah, that explains me. I spent eight years as a cop. You're right about the
physical danger - it's almost non-existent. In every city, trash collectors
get injured on the job far more than firemen and firefighters get injured
more than cops. Cops are down with secretaries in one-the-job injuries.

Being a cop is much like being a Boy Scout with a gun. You seldom see the
perpetrators, but you ALWAYS see the victim.

Cops do develop a gallows humor.

People are funny. In a stressful situation, the demeanor of calm vanishes
and they get even funnier. Ask any cop, ambulance driver, firefighter, or
emergency room worker. Here's an example:

Dispatcher: '532'

Unit 532: '532 go.'

Dispatcher: '532 check a report of nude, black female running across the
Highway 90 bridge at this time'

Unit 532: '532 clear. Enroute'

(about a minute goes by)

Dispatcher: '532'

Unit 532: '532, go'

Dispatcher: '532, have additional information on your nude, black female.
She is reportedly being pursued at this time by another black female with a
knife. Handle code 3'

Unit 532: '532 clear (sound of siren in background)'

The story goes no further. I purposefully never inquired into the facts of
the case. Whatever they were, they couldn't be as good as my imagination.
(Completely unlike the call I got "... two white females with chain-saws
involved...".)

Anyway, until you get a traffic violator that tells you "Hey, man, I didn't
know you was the fuzz. I thought you was just a couple of ordinary turds,"
you can't appreciate how some people just beg to be jailed.

Come to think on it, my sense of humor, finely honed as a deputy sheriff,
may be the reason I'm shunned.

[Pete Dashwood]

Jerry,

I, for one, have appreciated your sometimes wacky sense of humour through
this forum for many years.

I don't believe you are shunned. :-)

I know that cops put up with a lot. I guess any job dealing with the public
is like that and when you are dealing with a stressed out public you see the
worst of it.

(enjoyed your ancedotes, BTW)

My concern is really as Doc noted. When dealing with monsters it is
necessary not to become a monster. Some cops don't manage this and end up in
the News, although the majority probably do manage to juggle life and work.

My comments were not intended to be personal, just honest.

[Howard Brazee]

On Thu, 13 Oct 2011 18:47:29 -0600, Howard Brazee <how...@brazee.net>
wrote:

>And we certainly are better off when some of the best people succeed
>at becoming good cops.

In the U.S., cops aren't allowed to accept bribes, but politicians
live on them.

[HeyBub]

Pete Dashwood wrote:
>
> Jerry,
>
> I, for one, have appreciated your sometimes wacky sense of humour
> through this forum for many years.
>
> I don't believe you are shunned. :-)
>
> I know that cops put up with a lot. I guess any job dealing with the
> public is like that and when you are dealing with a stressed out
> public you see the worst of it.
>
> (enjoyed your ancedotes, BTW)
>
> My concern is really as Doc noted. When dealing with monsters it is
> necessary not to become a monster. Some cops don't manage this and
> end up in the News, although the majority probably do manage to
> juggle life and work.

I still think the bizarre sense of humor we develop is a big reason that
normal folk are uncomfortable around police.

A lady introduced me to her boyfriend and I, trying to show normal social
graces, inquired as to his occupation.

"I'm in solid waste disposal," he said. "I'm a Houston police officer."

I totally appreciated his wry riposte, but I doubt others would.

[docd...@panix.com]

In article <rphh97ptv6m8kqc2g...@4ax.com>,

Howard Brazee <how...@brazee.net> wrote:
>On Thu, 13 Oct 2011 18:47:29 -0600, Howard Brazee <how...@brazee.net>
>wrote:
>
>>And we certainly are better off when some of the best people succeed
>>at becoming good cops.
>
>In the U.S., cops aren't allowed to accept bribes, but politicians
>live on them.

In the US a police department can refuse to hire a candidate who scores
too highly on an intelligence test.

DD

[docd...@panix.com]

In article <se2dnXXWV--15QTT...@earthlink.com>,
HeyBub <hey...@NOSPAMgmail.com> wrote:

[snip]

>"I'm in solid waste disposal," he said. "I'm a Houston police officer."

Notice, class, the utter contempt in the equating of the citizenry with
'human waste'. Note further the absence of such niceties as 'To Preserve
and Protect'.

Even 'Pride, Integrity and Guts' shows greater courtesy towards those
whose tax-dollars allow for the existence of a patrolman's salary.

DD

[Louis Krupp]

It's "Serve and Protect."

Removal, if not actual disposal, of solid waste is one of the ways in
which the police serve and protect you and me. The weird sense of
humor is how they protect themselves.

The officer who jokes about solid waste disposal isn't thinking about
the people he's talking to, who are all law-abiding citizens until
they do something to indicate otherwise. The citizenry, the
taxpayers, are the good guys, clueless but generally harmless, who
need the police to protect them from the bad guys.

My impression is that cops aren't comfortable with gray areas, like
otherwise well-behaved people who use recreational drugs or who have
an alternate lifestyle or who vote Democratic. If you're one of
those, then cops may look askance at you or wonder where you lost your
way. That doesn't mean they think you're solid waste.

When you hear police say things like that, sigh, break out your most
genial, understanding smile, and relax. They're not talking about
you.

Louis

[HeyBub]

Heh! Once when escorting a juvenile shoplifter from a store in front of his
comrads, I asked the store owner "Does he need a tune-up on the way to the
station or has he been sufficiently beaten already?"

The store owner said, "No, he needs a tune-up."

"Let's go, asshole!"

The look on his friend's face was priceless.

You do what you can:

Once I pulled up behind a patrol officer who was talking to a lady on the
side of the road. Her face was bleeding from several cuts. It seems her
boyfriend (who was handcuffed in the back of the patrol car) had grabbed her
by the ears and used her face to bash out the passenger-side window.

Anyway, I approached just as the patrol officer was telling the woman: "For
the last time, are you going to file charges or are you not. I didn't see
him do anything, and if you're not going to file charges, I'll have to cut
him loose."

"I guess not," came the whispered reply.

Still, the patrol officer TRIED. Upon getting the man out of the patrol car
and removing the cuffs, the patrol officer got right in the miscreant's face
and said: "Listen up, you son-of-a-bitch, you touch that woman again and
you're gonna have ME to deal with. Do you understand, dimwit?"

"You must be nuts," said the driver to the patrol officer. "When I get her
home, I'm gonna beat her so bad she won't be able to lay down!... Get in the
car, woman!"

And they drove into the night, living unhappily ever after.

And to correct the notion that cops are uncaring droids, here's one more.

I'm driving the freeway at three o'clock in the morning when a Pontiac
passes me in my unmarked car doing over 100. I blinked twice, but before I
could get my act together a Houston Police car roars past in pursuit. I step
it up and presently I see the cops had the Pontiac pulled over.

Out of the Pontiac steps a GIANT black man. He must have been 6'5" and
weighed over 325 pounds. I figured him for a Houston Oiler defensive
lineman! Many gold chains surrounded his neck.

"Why are you in such a hurry, sir?" asked one of the two cops.

"Pussy, man!"

(Quizzical looks) "Say what?" asked the other patrolman.

"My old lady called. Said to get my black ass over there. She was is the
"mood." And officers, she ain't in the mood all that often!"

(The two cops look at each other) One finally says, "Well, we can't honestly
write a ticket to a man for that... Go on, get outta here, but take it
easy."

" 'Preciate that, officers. I really do."

Zoom.

And we three cops stood there, on the side of the road, in the early morning
darkness, with a small smile on our lips knowing that we just did something
to make the world a better place.

[docd...@panix.com]

In article <idij97t51t8kap3fi...@4ax.com>,
Louis Krupp <lkr...@nospam.indra.com.invalid> wrote:

[snip]

>When you hear police say things like that, sigh, break out your most
>genial, understanding smile, and relax. They're not talking about
>you.

From http://www.mydfz.com/Paxton/lyrics/wdylis.htm :

--begin quoted text

What did you learn in school today,
Dear little boy of mine?
What did you learn in school today,
Dear little boy of mine?
I learned that policemen are my friends.
I learned that justice never ends.
I learned that murderers die for their crimes.
Even if we make a mistake sometimes.
That's what I learned in school today.
That's what I learned in school.

--end quoted text

DD

[docd...@panix.com]

In article <DOWdnUpoVZ-umAfT...@earthlink.com>,

HeyBub <hey...@NOSPAMgmail.com> wrote:
>docd...@panix.com wrote:
>> In article <se2dnXXWV--15QTT...@earthlink.com>,
>> HeyBub <hey...@NOSPAMgmail.com> wrote:
>>
>> [snip]
>>
>>> "I'm in solid waste disposal," he said. "I'm a Houston police
>>> officer."
>>
>> Notice, class, the utter contempt in the equating of the citizenry
>> with 'human waste'. Note further the absence of such niceties as 'To
>> Preserve and Protect'.
>>
>> Even 'Pride, Integrity and Guts' shows greater courtesy towards those
>> whose tax-dollars allow for the existence of a patrolman's salary.
>>
>
>Heh! Once when escorting a juvenile shoplifter from a store in front of his
>comrads, I asked the store owner "Does he need a tune-up on the way to the
>station or has he been sufficiently beaten already?"
>
>The store owner said, "No, he needs a tune-up."
>
>"Let's go, asshole!"
>
>The look on his friend's face was priceless.

I'm sure it was... after all, Everyone Knows that suspects Absolutely
Never does 'participating in an investigation' involve physical violence.

>
>You do what you can:

[snip]

>Still, the patrol officer TRIED. Upon getting the man out of the patrol car
>and removing the cuffs, the patrol officer got right in the miscreant's face
>and said: "Listen up, you son-of-a-bitch, you touch that woman again and
>you're gonna have ME to deal with. Do you understand, dimwit?"
>
>"You must be nuts," said the driver to the patrol officer. "When I get her
>home, I'm gonna beat her so bad she won't be able to lay down!... Get in the
>car, woman!"
>
>And they drove into the night, living unhappily ever after.

All because the officers involved were so... picky about whom they planted
drugs on.

>
>And to correct the notion that cops are uncaring droids, here's one more.

There are eight million stories in the 79th Precinct's Mailbag... and we
ain't heard none of 'em.

Cops are human and I expect them to be human, with all associated high and
low points. Cops have a position in society which, in many cases, makes
them more than human... and so when an officer of the law abuses a
position I would hope that the debt owed to society is greater than it
would be for a civilian's doing the exact same act.

DD

[Robert Wolfe]

Saurabh,

Richard is very correct when he indicates that it is difficult to
convert Screen Section or DISPLAY/ACCEPT source to another user
interface format and still have the screen behavior work in an
identical fashion. Flexus offers source code conversion services
which allow you to accomplish this type of conversion quickly and at a
very modest cost.

We do convert source programs to Fujitsu NetCOBOL and Fujitsu COBOL
for Windows. This includes both the WindowsNetCOBOL compiler and the
Linux NetCOBOL compiler. In addition, we can convert your Micro Focus
source programs to any compiler you prefer. Our solution can also
convert to COBOL-IT and OpenCOBOL as well.

Flexus has been offering conversion services for several years now and
we have developed and sold advanced character mode and GUI user
interface solutions for COBOL programmers since 1986. Our solutions
are both environment and compiler independent.

The converted source uses COBOL CALLs to our external screen handling
tool. The programming interface will be quite familiar to you and your
programming staff.

In addition, we convert proprietary AcuGT GUI syntax to compiler
independent syntax.

Please contact me at: rtwolfe at flexus dot com for more information.

Thanks.

[jme...@instechnology.com]

On Oct 12, 4:33 pm, anonymous <saurab...@gmail.com> wrote:

Anonymous,
There are several mistakes in explanations of .Net COBOL. Fujitsu's
NetCOBOL for. Net has been around in the .Net environment as long as
the other languages, since the first release of .Net. I worked with it
back then. The migration to Fujitsu netCOBOL for Windows Enterprise
would be easier as it is designed like MF cobol in the procedural
standards. The NetCOBOL for .Net migraation is SUBSTANTIALLY easier
than moving to another .Net language as you are only converting the
flow of the screens, not rewriting the logic completely, which was
most likely developed over many, many years of programming and QA
testing. This will all have to be redone if moving to another .Net
language. The Fujitsu NetCOBOL compilers are $3,300 uSD for each
developer with no runtime license fees. The migration can be easy if
you adhered to the standards, a little more difficult if you were
convinced to use the MF extensions. There are several people who have
somewhat automated the process, even the conversion of the Dialog
manager screens. Alchemy Solutions, Inc., the sole distributor of the
NetCOBOL products can also do this through their services division, at
fairly good prices.
As far as SQL goes, if you are using procobol you should have no
issues with the SQL as this is done to standards by the precompiler
and therefore, the Fujitsu NetCOBOL products handle it without any
issues. Sungard has converted their Banner system, used by most
universities around the world, to Fujitsu's NetCOBOL for Windows and
NetCOBOL for Linux and has been successfully running this for many
years, saving universities hundreds of thousands of dollars.
I would not recommend converting to another language in one jump, as
you will be working on it for several years and it will costs
substantially more, probably 10x or more, to do that. I have done such
a project and wouldn't do it even if paid to.
There are differences in the compiler, mostly MF not adhering to
standards. There may be some items in SQL that aren't the same, but
not sure of the impact of those. Haven't had an issue with any that I
have heard of.
Contact me if you need some assistance.

[jme...@instechnology.com]

On Oct 13, 7:35 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:

Pete,
There is one mistake in your explanation of .Net COBOL. Fujitsu's

[Pete Dashwood]

I remember the release and I became very excited about it. It is a good
product, but so is Micro Focus' Visual COBOL.

It isn't a question of how long it has been around.

It is a question of two paradigms: Procedural and Object Oriented.

While the .Net COBOL compilers DO implement an object oriented solution (and
I commend that), my point is that you don't NEED a .Net COBOL compiler to
wrap COBOL as objects. Both Fujitsu NetCOBOL and MicroFocus NetExpress
understand Objects and components and BOTH of them support COM.


For people who don't plan a long term future in COBOL (and that number seems
to be increasing...) it is decidedly unattractive to make significant
investment in code that is going to be legacy. It makes more sense to invest
that money in training for the future.

>The migration to Fujitsu netCOBOL for Windows Enterprise
> would be easier as it is designed like MF cobol in the procedural
> standards. The NetCOBOL for .Net migraation is SUBSTANTIALLY easier
> than moving to another .Net language as you are only converting the
> flow of the screens, not rewriting the logic completely, which was
> most likely developed over many, many years of programming and QA
> testing. This will all have to be redone if moving to another .Net
> language.

No, it doesn't. (Your NEW development should be in a .Net language or
languages; your existing legacy does NOT need to be rewritten.)

I didn't suggest that you move your existing COBOL to another .Net language,
only that you don't NEED .Net COBOL to move your existing applications to
.Net. Your existing COBOL compiler (NetCOBOL or NetExpress) can do it
easily. The ONLY thing you NEED is interOP services of .Net and that is
provided for FREE from Microsoft, who developed it specifically so that
legacy code can be easily ported to .Net.

I'm currently helping a client move to Relational DB (SQL Server) from COBOL
ISAM and the new system will run in .Net. They are using Fujitsu NetCOBOL
version 7 and PowerCOBOL. There is absolutely no requirement for a .Net
COBOL compiler because they don't intend to stay with COBOL long term. New
development will be in C# and this will be extended probably with the
addition of HTML5 and Javascript to accommodate an easy move to Windows 8.

These days it is becoming normal to utilise a number of languages because
source code is no longer the King that it was in the COBOL era. What matters
is functionality and functionality comes from OBJECTs. Most of us use
objects every day for which we have no source; Windows XP has around 800
objects registered (most as COM or ACtiveX components), but people use them
every day and never think about having no source...Procedural source code
just isn't everything anymore.

(Yes, I know that .Net COBOL can provide objects... but so can standard
NetCOBOL and if you are looking to move off COBOL there isn't much point in
investing in an expensive new compiler for it when the one you have is
perfectly adequate to get you to .Net...)

It is interesting to see that the releases of Visual Studio which will
accompany Windows 8 are NOT focused to a given language. (Like Visual C# or
Visual VB.Net). Instead you can select anything you like and that makes
sense to you. The idea is to leverage the existing skill base. Win 8
applications can be written in C++, C#, VB.Net, Silverlight, Javascript,
HTML5/CSS, and XAML, or any combination of these. (COBOL is not included,
although some vendors may build XAML generating COBOL compilers.) The
resulting applications will run on any windows platform; web based, desktop,
slate or mobile.

Given that many developers have already acquired a good base in things like
HTML, CSS, Silverlight, and Javascript by building websites and web
applications, it seems unnecessary to prolong dependence on COBOL. The
future belongs to layers and objects and it is tiled, not based on COBOL
screen sections or DIALOG panels...

PRIMA's tools AUTOMATICALLY add the .Net wrapping to your existing legacy
code and, Hey Presto! Your legacy runs in .Net. The wrapping layer is the
.Net InterOP services provided for FREE from Microsoft. You could do what
the Toolset does quite easily yourself (and I did when I first started
moving off COBOL) but it is tedious and time consuming. The Toolset does it
in seconds and gets it right...

>The Fujitsu NetCOBOL compilers are $3,300 uSD for each
> developer with no runtime license fees.

Yes, and although I commend the freedom from RTS licence fees, that is still
a $10,000 investment for a small business. Then there is maintenance and
support. And it goes on.

Some people will be very happy to do it and I am not in any way suggesting
these are not good products. People who think they can use COBOL
indefinitely and intend to try and do so SHOULD buy a .Net COBOL compiler.

But there is an option; Start moving off COBOL now. (Sooner or later you
will HAVE to; better to prepare and start stepping in the right direction
BEFORE that happens.)

I'm simply saying that for a SME which is looking for a way off COBOL,
coughing up around $12,000 for a new unnecessary COBOL compiler does not
make much sense.

I'll give you a Toolset for less than half of that. It is a site licence for
as many seats as you like, there is automatic maintenance and upgrade for
life (once the Toolset is installed automatic updates get applied as they
become available and as long as you have authorised them. You can drop back
to a previous release any time by use of Add/Remove programs), AND we will
work with you providing advice and assistance as a centre of competence for
moving OFF COBOL. We have accumulated a good knowledge base for moving off
COBOL, based on a number of successful migrations. Most of the time we don't
charge for this.

The Toolset will get your existing code operating against a relational
database in the .Net environment. Your ongoing development can share the
same database and even use the same DAL objects, and it is language
independent. You are not locked in to COBOL. The database is open and
accessible by any number of standard tools and languages. You continue
running your legacy as you acquire skill in the new development environment.
It is a phased transition with the option of keeping COBOL or not.

In time, .Net will be subsumed by future OS releases which will
automatically contain it (as win 7 does at the moment) and the focus will be
more towards integration of applications, with OS support for all kinds of
functions implemented as Classes. Windows 8 will be the first in this arena
and the Metro interface will slowly replace the whole idea of using windowed
applications. (It has already happened with mobile phones and pads...)

You will run your new applications in a tiled Win 8 UI and your legacy will
still run in .Net using windows but activated from the same tiled Metro
interface until you can get it converted or replace it with new
applications.

In five to ten years time, windowed applications will be looked on the same
way people look on DOS boxes today... :-)

> The migration can be easy if
> you adhered to the standards, a little more difficult if you were
> convinced to use the MF extensions. There are several people who have
> somewhat automated the process, even the conversion of the Dialog
> manager screens. Alchemy Solutions, Inc., the sole distributor of the
> NetCOBOL products can also do this through their services division, at
> fairly good prices.

Platform "migration" from one COBOL to another is really just a waste of
time in my opinion. Migration away from COBOL altogether is the one that
makes sense to me.

The question is whether you can do it without having to lose all your
existing assets. We are addressing that question at PRIMA.

[Pete Dashwood]

jme...@instechnology.com wrote:
> On Oct 12, 4:33 pm, anonymous <saurab...@gmail.com> wrote:
>> Hello,
>>
>> Has anyone successfully converted Microfocus NetExpress Cobol with
>> imbedded SQL (pre compiled with Pro*COBOL) to NetCobol.net from
>> Fujitsu?
>>
>> Can you point a novice (in COBOL) to a valuable place to look for
>> help?
>>
>> Thanks
>

> Anonymous,
> There are several mistakes in explanations of .Net COBOL. Fujitsu's
> NetCOBOL for. Net has been around in the .Net environment as long as
> the other languages, since the first release of .Net. I worked with it
> back then.

I don't believe there are. There may have been some misunderstanding of what
was said by me, which has hopefully now been clarified in my response to
you.

What the Fujitsu .Net COBOL compiler for .Net is and what it does is a
matter of record. It would be hard to make "mistakes" in discussing it.

[Bill Klein]

One significant correciton, see below
<jme...@instechnology.com> wrote in message
news:7411645a-c787-437b...@ff5g2000vbb.googlegroups.com...

On Oct 12, 4:33 pm, anonymous <saurab...@gmail.com> wrote:
> Hello,

>>There are differences in the compiler, mostly MF not adhering to
>> standards.

Can you give any examples of Micro Focus not adhering to the ANSI, ISO or
other COBOL Standards? Micro Focus is (as far as I know) MUCH cloer to the
'85 COBOL Stanard. It does have lots AND LOTS of extensions, but unlike
Fujitsu (alchemy) its "flagging" of extensions is fully conforming to the
'85 ANSI/IS Stanard. Fujitsu, on the other hand, doesn't even accept
"problem reports" on those of its extensions that it does not correctly
flag.

As far as the only CURRENTLY supported by ANSI and ISO Standard, the '02
Stanard, Micro Focus has implmented most of it (not all) and has a dialect
for selecting that Standard.

Fujitsu doesn't support very much of the '02 Stanard. Even its OO support
(which has been mentioned elsewhere in this thread) barely resembles what is
defined in the current ISO Standard.

* * * *
If the intent (not the words) of the original message was to say that much
of the "conversion" difficulties going from Micro Focus to Fujitsu is due
the the extensive set of (well documented and ully conforming) extensions to
the '85 Stanard that Fujitsu doesn't support, then that is certainly true.
Especially when it comes to the HUGE number of MF directives that can impact
run-time behavrior, Funjitsu simply doesn't CLAIM to support many (possibly
most) of them.

P.S. If anyone is interested in using Micro Focus' current products in "'85
Standard" mode (compile and run-time), just remember to use the
Dialect(ANS85),FLAGAS(S)
directives. I think that (probably) close to 100% of such MF code with
compile and run "as expected" with Fujitsu and most other '85 conforming
compilers.

[Pete Dashwood]

Bill Klein wrote:
> One significant correciton, see below
> <jme...@instechnology.com> wrote in message
> news:7411645a-c787-437b...@ff5g2000vbb.googlegroups.com...
> On Oct 12, 4:33 pm, anonymous <saurab...@gmail.com> wrote:
>> Hello,
>>> There are differences in the compiler, mostly MF not adhering to
>>> standards.
>
> Can you give any examples of Micro Focus not adhering to the ANSI,
> ISO or other COBOL Standards? Micro Focus is (as far as I know) MUCH
> cloer to the '85 COBOL Stanard. It does have lots AND LOTS of
> extensions, but unlike Fujitsu (alchemy) its "flagging" of extensions
> is fully conforming to the '85 ANSI/IS Stanard. Fujitsu, on the
> other hand, doesn't even accept "problem reports" on those of its
> extensions that it does not correctly flag.
>
> As far as the only CURRENTLY supported by ANSI and ISO Standard, the
> '02 Stanard, Micro Focus has implmented most of it (not all) and has
> a dialect for selecting that Standard.
>
> Fujitsu doesn't support very much of the '02 Stanard. Even its OO
> support (which has been mentioned elsewhere in this thread) barely
> resembles what is defined in the current ISO Standard.

Be a bit careful here, Bill. Certain aspects of MF COBOL are ONLY available
in the MF implementation and NOT in the 2002 standard.

COBOL standards have been pretty irrelevant since the fiasco involved in
producing the 2002 standard when virtually all COBOL standard credibility
was lost. The way was lost after 1985 and taking 17 years to produce a
standard just meant that nobody was interested any more.

Micro Focus have supported it because their business is largely underpinned
by COBOL (although I believe we will see them diversifying to other
products in the (near) future).

COBOL products from both Micro Focus and Fujitsu, in my experience, are
excellent.

However, do believe that COBOL is not relevant for the future. (It is VERY
relevant as far as legacy applications are concerned... :-))

>
> * * * *
> If the intent (not the words) of the original message was to say that
> much of the "conversion" difficulties going from Micro Focus to
> Fujitsu is due the the extensive set of (well documented and ully
> conforming) extensions to the '85 Stanard that Fujitsu doesn't
> support, then that is certainly true. Especially when it comes to the
> HUGE number of MF directives that can impact run-time behavrior,
> Funjitsu simply doesn't CLAIM to support many (possibly most) of them.

I can see no point to converting between Micro Focus and Fujitsu
implementations of COBOL. Both provide support for .Net COBOL and both have
excellent products.

Why would you do it?

I have to believe that this kind of exercise is politically and/or marketing
motivated.

>
> P.S. If anyone is interested in using Micro Focus' current products
> in "'85 Standard" mode (compile and run-time), just remember to use
> the Dialect(ANS85),FLAGAS(S)
> directives. I think that (probably) close to 100% of such MF code
> with compile and run "as expected" with Fujitsu and most other '85
> conforming compilers.

The original poster is obviously involved with Alchemy and doesn't recognise
value in Micro Focus products.

Having tried both of these extensively, I find little to choose between
them, although I do prefer Fujitsu, mostly because their COM implementation
is better supported than Micro Focus'.

But that is something which is important to me (I like component based
software), and probably isn't important to most COBOL users.

The fact that one of them implements the 2002 COBOL standard (if it does...)
has no benefit to most COBOL users.

It certainly cuts no ice with me... :-)

[Bill Klein]

Pete,
Yes, Micro Focus has EXTENSIONS to its OO support (just as it does for
its non-OO syntax). There is NOTHING "non-Standard" about having extensions
AS LONG AS you provide correct flagging. At least with the currently
supported products, I believe that
FLAG(ISO2002)
will catch those extensions that are not in the '02 Stanard.

Having said that, I do agree that IN GENERAL the Standards have been
"irrelevant" since the US government got out of the business of
A) running certications procedures for "conforming" COBOL compilers
B) stopped requiring the availability of a conforming (certificed)
compiler on all hardware that they bought.

ON THE OTEHRR HAND,
*IF* you want to limit your coding techniques to "confroming source code,
thsi DOES (in almost all cases) guarantee portable source code - which
brings us back to the origin of this thread.
As I said earlier,
*IF* your Micro Focus compiled source code compiles cleanly with
NOMF,Dialect(ANS85), FLAGSTD(H),FLAGAS(S)
then I would expect that the source code WOULD compile cleanly arn run as
expected with Fujitsu compilers with minimal if any changes.

It is my understanding that there actually a FEW "software vendors (whos
source is in COBOL) that actually still do this. Nevertheless, I think the
number barely places a dent into the statement that COBOL stanards are
mostly irrelevant.

P.S. See, however, the original note to which I responded. It was NOT me
who brought up COBOL Standards in this thread.
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:9gkd1t...@mid.individual.net...

[Bill Gunshannon]

In article <9gkd1t...@mid.individual.net>,

"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>
> COBOL standards have been pretty irrelevant since the fiasco involved in
> producing the 2002 standard when virtually all COBOL standard credibility
> was lost. The way was lost after 1985 and taking 17 years to produce a
> standard just meant that nobody was interested any more.

Are you sure it was the 17 year hiatus and not the irrelevance of the
content that killed the interest? I know where you stand on this, but
I still know a lot of COBOL programmers (and a lot of COBOL programs)
and of all the places it tried to elbow its way into COBOL was the one
place where OO really had nothing to offer.

As for programming language standards, as one who has been in academia for
a quarter century, I lost respect for standards bodies when they stopped
standardizing and started trying to drive the bus in directions that were
only of value to academia. And we won't even go into the use of "standards"
as ways to make money!!

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Robert Wolfe]

Pete,

You wrote:

"I can see no point to converting between Micro Focus and Fujitsu
implementations of COBOL. Both provide support for .Net COBOL and both
have
excellent products.

Why would you do it?

I have to believe that this kind of exercise is politically and/or
marketing
motivated."

It's not politically motivated, it's almost always economically
motivated. We support compiler independence, therefore "we have no
dog in the fight" when it comes to the choice of a particular
compiler.......from our perspective, it truly is whatever the customer
wants it to be.

There are still, lots of companies who want to continue to enhance and
maintain their COBOL application using COBOL as the primary language.
I know that you suggest otherwise, but we do speak to companies daily
who have no intention of moving away from COBOL. That's why they call
us.

We talk to companies that prefer COBOL to other languages because
their staff is productive and proficient in COBOL and it costs a
significant amount of money to retrain large groups of programmers.

The reason companies are migrating to Fujitsu COBOL is because they do
not charge runtime distribution fees and that can result in a
considerable decrease in application deployment costs.

From our perspective, it is purely economics, not politics or
marketing.

[snip]

[Pete Dashwood]

Bill Gunshannon wrote:
> In article <9gkd1t...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>>
>> COBOL standards have been pretty irrelevant since the fiasco
>> involved in producing the 2002 standard when virtually all COBOL
>> standard credibility was lost. The way was lost after 1985 and
>> taking 17 years to produce a standard just meant that nobody was
>> interested any more.
>
> Are you sure it was the 17 year hiatus and not the irrelevance of the
> content that killed the interest? I know where you stand on this, but
> I still know a lot of COBOL programmers (and a lot of COBOL programs)
> and of all the places it tried to elbow its way into COBOL was the one
> place where OO really had nothing to offer.
>
> As for programming language standards, as one who has been in
> academia for a quarter century, I lost respect for standards bodies
> when they stopped standardizing and started trying to drive the bus
> in directions that were only of value to academia. And we won't even
> go into the use of "standards" as ways to make money!!
>
> bill

A very good response, Bill.

I think you are right about the content of the standard as well as the time
it took.

It still upsets me when I think back to all the time and energy (not to
mention some very capable people, like Bill Klein) who had their efforts
wasted by poor management and red-tape procedures that meant things could
not progress. There was a refusal to listen and the procedures whereby
people could contribute were just non-viable. It did not encourage community
involvement.

I guess standards are a two-edged sword. Properly used and responsive to a
user community, they are valuable. When, as you noted, the primary reason
for them is revenue generation, that is a whole different matter.

[Pete Dashwood]

A fair response, Bob.

I guess the run time fees are a big consideration for many people.

That one has been discussed here at length over years :-)

I don't doubt what you say (if I was committed to COBOL I would probably be
talking to Flexus too) :-)

Nevertheless, the majority of sites are trying to move off DEPENDENCY on
COBOL and in that arena run time fees don't mean much because you can get
the compiler, IDE, AND distribution rights for FREE, if you DON'T use COBOL.

It's a hard offer to beat.

However, there is re-training involved and some companies simply won't spend
money on training.

Others just haven't realised that the game has changed. The realization is
gradually being pushed onto them as the existing crop of COBOL people retire
or die off.

Nevertheless, I'd be the frst to admit that there is still a valuable
investment in COBOL which many companies won't want to write off. (Of course
many other companies are glad to be shot of it... :-))

Would you be prepared to commit your company to a platform migration ONLY to
avoid runtime fees?

I wouldn't.

I'd want much more value for that amount of aggravation.:-)

It's time for people to consider where they are and where they are going. If
you are going to do a platform migration, it might as well be in a direction
that moves away from COBOL altogether, or at least gives you the option to
do so.

If you can leverage your existing code into a new environment, WITHOUT
remaining dependent on COBOL (as well as getting rid of your run time fees),
that looks more attractive to me than simply swapping the status quo because
of run time fees.

Our clients are doing new development in C# and VB.Net (some are still
using COBOL...) while still retaining the essential core of their COBOL
legacy and running it in the new environment as OO code. They have an
OPTION. Not locked in to COBOL, but able to continue using it if they want
to.

That is the area which PRIMA is seeking to fill.

[Richard]

On Oct 25, 12:59 pm, "Pete Dashwood"

Companies should evaluate based on the actual benefits and costs and
not on dogma such as your advice to them here.

You have no idea how much is being spent on runtime fees in the case
in point. The original enquirer was attempting to get information so
as to evaluate the costs.

All that you have given him is dogma.

At one point you said:

"As for NetCOBOL, well, I simply can't afford it, so it is academic."

Perhaps they can no longer afford it either.

> I'd want much more value for that amount of aggravation.:-)
>
> It's time for people to consider where they are and where they are going. If
> you are going to do a platform migration, it might as well be in a direction
> that moves away from COBOL altogether, or at least gives you the option to
> do so.

That is just more dogma.

> If you can leverage your existing code into a new environment, WITHOUT
> remaining dependent on COBOL (as well as getting rid of your run time fees),
> that looks more attractive to me than simply swapping the status quo because
> of run time fees.

Which is irrelevant to the question.

> Our clients are doing new development in C# and VB.Net  (some are still
> using COBOL...) while still retaining the essential core of their COBOL
> legacy and running it in the new environment as OO code. They have an
> OPTION. Not locked in to COBOL, but able to continue using it if they want
> to.
>
> That is the area which PRIMA is seeking to fill.

Exactly. You are running a business based on clients not using COBOL.

[Clark F Morris]

Of course your clients are committed to the Microsoft environment
which may not meet the needs of other organizations. C# and VB.Net
don't do too well in Unix, Linux or the various "mainframe" operating
systems, each of which provides facilities or benefits not available
in the Microsoft environment. For my personal use the Microsft
environment is the most adequate given my needs and uses. For
businesses and other organizations the choices aren't as simple.

Clark Morris

[Pete Dashwood]

Yes, I should have stated that we are committed to the Microsoft environment
and so are our clients.

I have deliberately refrained from moving to mainframe migration because
there would need to be some heavy investment for us before we could support
it properly. (I also don't think I want to compete directly with Alchemy and
Micro Focus, who have resources I can only dream of...:-))

I have run preliminary tests with creation of RDB and VSAM/KSDS being
converted to RDB and it was very successful, but we generate an OO Data
Access Layer at the same time and that would need to be changed for
mainframe. The layer could be generated as called modules or it could be
generated in Java (for example), or it could even be implemented in SQL as
stored procedures on the actual database, but to do all of that would take
time and money.

At the moment I'm more interested in making sure we can get people to Win 8
and Metro without too much sweat... :-)

[HeyBub]

Robert Wolfe wrote:
>
> There are still, lots of companies who want to continue to enhance and
> maintain their COBOL application using COBOL as the primary language.
> I know that you suggest otherwise, but we do speak to companies daily
> who have no intention of moving away from COBOL. That's why they call
> us.
>
> We talk to companies that prefer COBOL to other languages because
> their staff is productive and proficient in COBOL and it costs a
> significant amount of money to retrain large groups of programmers.
>

You may have a somewhat parochial view of the situation. Companies are not
calling you for help with Visual Basic, C#, or Fortran so there's the
tunnel-vision syndrome...

[Lüko Willms]

Am 25.10.2011 03:15, schrieb Richard:
>> It's time for people to consider where they are and where they are going. If
>> > you are going to do a platform migration, it might as well be in a direction
>> > that moves away from COBOL altogether, or at least gives you the option to
>> > do so.
> That is just more dogma.

Some day down the road they will not find any more programmers
knowledgeable in COBOL who can maintain their COBOL sources.

I doubt that today there is any school, academic institution or any
other teaching outfit which offers courses in "COBOL programming",
anywhere in the world.


Cheers,
L.W.

[Bill Gunshannon]

In article <4ebf928b$0$4150$6e1e...@read.cnntp.org>,

Lüko Willms <lueko....@domain.invalid> writes:
> Am 25.10.2011 03:15, schrieb Richard:
>>> It's time for people to consider where they are and where they are going. If
>>> > you are going to do a platform migration, it might as well be in a direction
>>> > that moves away from COBOL altogether, or at least gives you the option to
>>> > do so.
>> That is just more dogma.
>
> Some day down the road they will not find any more programmers
> knowledgeable in COBOL who can maintain their COBOL sources.

Unlikely. They may not be school trained, but anyone with a programming
background can learn to o COBOL.

>
> I doubt that today there is any school, academic institution or any
> other teaching outfit which offers courses in "COBOL programming",
> anywhere in the world.

Actually, there still are a couple, but as stated above, it is really
irrelevant. Places with a high demand for COBOL can and will (and
some already are!) teach it themselves.

[SkippyPB]

On 13 Nov 2011 12:51:12 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
wrote:

>In article <4ebf928b$0$4150$6e1e...@read.cnntp.org>,
> Lüko Willms <lueko....@domain.invalid> writes:
>> Am 25.10.2011 03:15, schrieb Richard:
>>>> It's time for people to consider where they are and where they are going. If
>>>> > you are going to do a platform migration, it might as well be in a direction
>>>> > that moves away from COBOL altogether, or at least gives you the option to
>>>> > do so.
>>> That is just more dogma.
>>
>> Some day down the road they will not find any more programmers
>> knowledgeable in COBOL who can maintain their COBOL sources.
>
>Unlikely. They may not be school trained, but anyone with a programming
>background can learn to o COBOL.
>
>>
>> I doubt that today there is any school, academic institution or any
>> other teaching outfit which offers courses in "COBOL programming",
>> anywhere in the world.
>
>Actually, there still are a couple, but as stated above, it is really
>irrelevant. Places with a high demand for COBOL can and will (and
>some already are!) teach it themselves.
>
>bill

There remains a large number of schools that teach Cobol. There has
been a resurgance in Cobl classes at the University and Trade school
level. For a list of some, see
http://www.mainframes.com/schools.htm

Regards,
--

////
(o o)
-oOO--(_)--OOo-

"I am logged in...therefore, I am."
Unknown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

[Bill Gunshannon]

In article <cotvb71tqrhj4btpk...@4ax.com>,

Thank you very much for the information. Looks like a chance for
one more attempt get UofS to reconsider. I even told them they
should approach General Dynamics, who has COBOL Intern Positions,
about a formal Internship Program.

[Robert Wolfe]

Bill,

I believe that I also saw that Kraft Foods up in your area is seeking
COBOL professionals.

On Nov 13, 1:27 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
[snip]

>
> Thank you very much for the information.  Looks like a chance for
> one more attempt get UofS to reconsider.  I even told them they
> should approach General Dynamics, who has COBOL Intern Positions,
> about a formal Internship Program.
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves

> billg...@cs.scranton.edu |  and a sheep voting on what's for dinner.

[Bill Gunshannon]

In article <5e9f258a-4e0b-4ca1...@w3g2000vbw.googlegroups.com>,

Robert Wolfe <rtwo...@gmail.com> writes:
> Bill,
> I believe that I also saw that Kraft Foods up in your area is seeking
> COBOL professionals.

Don't know of any Kraft foods places around here and a quick search of
their careers page with the keyword COBOL returns nothing. Got a pointer?

Another comment on the list of schools still teaching COBOL. Notice how
they tend to be clustered around current or former IBM strongholds?

When I worked at West Point, NY we had an intern come in from Marist (which
is in the heart of IBM country). The only language the intern had klearned
at Marist was APL. :-)

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves

bill...@cs.scranton.edu | and a sheep voting on what's for dinner.

[Lüko Willms]

Am 13.11.2011 17:59, schrieb SkippyPB:
> There remains a large number of schools that teach Cobol. There has
> been a resurgance in Cobl classes at the University and Trade school
> level. For a list of some, see
> http://www.mainframes.com/schools.htm

These are 37 institutions, if I counted right, for a country (USA)
with about 300 million inhabitants, and some of the institutions
supposedly teaching COBOL are outside of that country.

I was, of course, especially interested by the entries of
institutions in Germany. The link given for the Leipzig university leads
to an information block about their IMB z9 mainframe, which is called
"jedi", and one does actually find in one page that there is a COBOL
compiler installed. But when one tries to find COBOL courses from the
main page of the informatics institute which operates that mainframe,
the search result is NIL. Try yourself (in English) at
<http://www.informatik.uni-leipzig.de/ifi/en/search.html>

The same applies to the Fachhochschule Erlangen (University of
applied sciences, they call themselves in English). Here is the plan for
the study of "Wirtschaftsinformatik" (commercial informatics), which is
the most susceptible to relate to COBOL:
>
<http://www.hs-esslingen.de/en/the-university/faculties/engineering-management/study-programmes/management-and-information-systems/overview-of-bachelors-degree-program.html>

The courses in software development point to a book on Java, but do
not mention COBOL. You can also use the seach facility at the upper
right corner of that page.

The domain of the third institution in Europe (and German speaking),
a "Höhere Technische Lehranstalt" in Vienna, "http://www.htl-tex.ac.at/"
is not found by the DNS. Maybe it does not exist, or under another name.
There are lots of "Höhere Technische Lehranstalt" in Austria...

I guess the reality of COBOL teaching in the other 35 or so
institutions listed on that webpage will evaporate as quickly as the
ones which I searched.

I do not want to drive you into a depression -- I learned COBOL long
time ago, and liked to work in it -- but we have to face the reality,
which is that COBOL is a language of the past, a dinosaur.


Cheers,
L.W.

[Alistair Maclean]

The last person I encountered learning Cobol was doing so at one of my
previous employers. There was no official course just a 60 page
document detailing syntax and how to use the commands. I don't know
how well the trainee did but it must have scared him off as he left a
few months after completing his first Cobol program.

[Pete Dashwood]

I don't think anyone HAS to face that reality, Lueko.

And there are people here who simply won't. :-)

That's OK

In time, the reality becomes apparent and it doesn't really matter whether
that is today, tomorrow or next year.

Bill G. will try and get and get it taught one more time, and cannot
understand why no-one is listening.

Old-time IBM mainframers who have no use or understanding for objects and
layers will refuse to let it go until, eventually, they are all gone and
their platforms are supplanted by, or subsumed into, the ever increasing
network.

People who make a living selling COBOL compilers will continue talking it up
as if it was still relevant. (While they are looking for ways to diversify
out of it...)

None of it really matters. I predicted it would be gone as a viable
commercial development language by 2015.

I was wrong.

It has already happened.

After being in the top 3 for many years, COBOL is not even in the top 20
development languages.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Although it has picked up a few places since last year it is ironic to note
that Assembly Language is more popular (just...) than COBOL, which
supplanted it for general use around 50 years ago. I guess what goes around
comes around... :-)

Another site that may be of interest (and is relevant to COBOL) :

http://www.rackspace.com/cloud/blog/2011/05/17/infographic-evolution-of-computer-languages/

But none of it is REALLY important.

(It is fair to ask whether program language popularity matters anyhow...I
guess if the skill you have is in great demand you have more chance of
staying employed, but, on the other hand, if the skill you have is not in
great demand then you can charge more for it when it IS needed :-))

If you work on a site that uses COBOL, then COBOL is important to you. If
your career is drawing to a close, then the future of that site, and whether
they stay with COBOL or move off it, is not of any significance to you.

If you are a young person looking for a career in programming then you won't
need Lueko or me to tell you that COBOL will be a pointless waste of time.
If you apply yourself instead to other more relevant languages and
techniques, it is pretty easy to pick up a simple procedural paradigm like
COBOL if/when the need arises. (Unfortunately, the converse is not true and
history has shown that people immersed in COBOL, generally are not capable
of moving easily to an object based paradigm. They tend to invent reasons
not to and support each other in their general denigration of Object
Oriented Programming as being unnecessary (tell that to the 90% of the World
that runs on it...) and just a re-invention of "modular programming", which
it isn't...)

Although my company started out insisting people move off COBOL, we have
modified that position and today we don't really care whether our clients
opt to stay with COBOL or move to something else, AS LONG as they are using
Objects and Layers in the .Net environment. The "layers" part means a three
tier solution, with separation between the Presentation Layer (User
Interface), the Business Logic, and the Data Access Layer.

Our Tools currently generate the Data Access Layer automatically at the same
time as they generate the new Relational Database from the existing COBOL
indexed file base. We are currently looking at getting the Presentation
Layer also separated and generated automatically.

My interest in this has been stimulated with the technical previews for
Windows 8. The new Metro interface is entirely XAML based and if people have
separation between their Business Logic and their Presentation Layer it is
not too hard to generate a XAML equivalent of their exisiting screens.
(Metro is a touch based, cross platform interface. It supports mouse and
keyboard but touch is primary. Metro runs on ANY windows platform; desktop,
web, tablet, mobile phone, without any coding changes being required. Expect
to hear more about it, and XAML, in the next few years.)

Although I would not recommend anyone stay with COBOL long term, mostly
people find out for themselves when they get the maintenance bill for their
expensive COBOL compiler and then realise they could do the same job with a
better free tool from Microsoft.

We offer an option to people who are prepared to "bite the bullet" and move
off COBOL during or shortly after Conversion/Migration. There is then no
need to buy a .Net COBOL compiler, but we really don't care if they don't
take that option. It is about having a choice.

As far as the popularity of programming languages goes, don't be surprised
to see JavaScript trending upwards over the next few years. The combination
of HTML5/CSS and JavaScript as being "quick build" XAML generators is being
touted currently by Microsoft for developing Win 8 applications.

In the Microsoft world, the distinction between desktop applications and web
based ones started blurring with products like Silverlight and WPF (both of
which generate XAML and both of which can be built for the web or the desk).
Now it looks as if these products will become merged under the HTML5
banner. (Silverlight has already been discontinued at the same time as Adobe
discontinued Flash, its main competitor.)

(Note that if you already develop for the Web using ASP.NET and server side
"code behinds" in C# (as I do... the COBOL21 and PRIMA sites are developed
in this way), or C++, or VB.Net, these will still work in HTML5, but now
you can bring the same "code behind" approach to the desktop and other
surfaces. Because it is objects that are actually wired up, the programming
language is unimportant. It is all about layers and objects...The JavaScript
can be run as normal client side script served up on the page, or it can be
used for "code behind" and run on the server.)

It will be interesting to see what the winner of the Language Wars will be,
although, as I tried to outline above, it no longer matters once you are
using objects.

It won't be COBOL.

[Fritz Wuehler]

> Bill G. will try and get and get it taught one more time, and cannot
> understand why no-one is listening.

I'm listening, Bill is one of the few posters in this group (along with you
of course) who hasn't made it into my killfile :)

> Old-time IBM mainframers who have no use or understanding for objects and
> layers will refuse to let it go until, eventually, they are all gone and
> their platforms are supplanted by, or subsumed into, the ever increasing
> network.

Now Pete, COBOL is not the only thing that runs on a mainframe and it is not
going away, objects have nothing to do with it. You'll have to get rid of
FORTRAN, PL/I and assembler until the mainframe goes Java.

> People who make a living selling COBOL compilers will continue talking it up
> as if it was still relevant. (While they are looking for ways to diversify
> out of it...)

It might be relevant, I see ads for UNIX COBOL coders now, haven't seen that
until the last few years. Growth opportunity? ;)

> None of it really matters. I predicted it would be gone as a viable
> commercial development language by 2015.
>
> I was wrong.
>
> It has already happened.

Not everywhere, people are still hiring.

> After being in the top 3 for many years, COBOL is not even in the top 20
> development languages.
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Yawn...really now Pete. That list is for people who think a PC is a
computer. They don't have any idea that companies have things like
mainframes, minis and servers.

> Although it has picked up a few places since last year it is ironic to note
> that Assembly Language is more popular (just...) than COBOL, which
> supplanted it for general use around 50 years ago. I guess what goes around
> comes around... :-)

That's x86 assembly language. Yes, it is more popular than COBOL on a PC. As
I said, the list is useless.

> Although I would not recommend anyone stay with COBOL long term, mostly
> people find out for themselves when they get the maintenance bill for their
> expensive COBOL compiler and then realise they could do the same job with a
> better free tool from Microsoft.

That doesn't make any sense. Microsoft is not the only company and Windows
on Intel is not the only platform in the world. But if you use that "better
free tool" from Microsoft you're stuck on Windows on Intel. I'd rather be
stuck on the mainframe.

ensuing sales pitch snipped

> As far as the popularity of programming languages goes, don't be surprised
> to see JavaScript trending upwards over the next few years. The combination
> of HTML5/CSS and JavaScript as being "quick build" XAML generators is being
> touted currently by Microsoft for developing Win 8 applications.

No doubt scripting languages will grow, salaries and competence in anything
productive will decrease. It's all web now. Gag me with a spoon, dude!

> It will be interesting to see what the winner of the Language Wars will be,
> although, as I tried to outline above, it no longer matters once you are
> using objects.
>
> It won't be COBOL.

It's assembler. You have to have it :)

[Lüko Willms]

Am 15.11.2011 19:12, schrieb Fritz Wuehler:

> Now Pete, COBOL is not the only thing that runs on a mainframe

Sure

> and it is not going away, objects have nothing to do with it.

Investment inertia does. Companies have a stock of running programs,
and it is for them not a light decision to convert it all to a new
environment. But if you look closer, you will see more and more
companies doing it.

> You'll have to get rid of
> FORTRAN, PL/I and assembler until the mainframe goes Java.

Especially speaking of IBM mainframes ... as far as I can see, IBM
has been one of the companies which was in the forefront os pushing Java.

>> > I predicted [COBOL] would be gone as a viable

>> > commercial development language by 2015.
>> >
>> > I was wrong.
>> >
>> > It has already happened.

> Not everywhere, people are still hiring.

I know. Companies do not lightly give up all the investment in
running programs which had grown over several decades. "Don't touch a
running system" is a well know and very well followed rule.

But if companies are looking for COBOL programmers, they are --
methinks -- looking for replacements to their old programmers who retire
to profit from their old age pensions.

> Yawn...really now Pete. That list is for people who think a PC is a
> computer. They don't have any idea that companies have things like
> mainframes, minis and servers.

What is today a "mini"?

Does Data General still exist? Wang? Nixdorf?

>> > Although I would not recommend anyone stay with COBOL long term, mostly
>> > people find out for themselves when they get the maintenance bill for their
>> > expensive COBOL compiler and then realise they could do the same job with a
>> > better free tool from Microsoft.

I think that tehre are few free tools from Microsoft. All they want
to do is sell, sell, sell...

> That doesn't make any sense. Microsoft is not the only company and Windows
> on Intel is not the only platform in the world.

Sure, it is threatened by iOS and Android operating systems.

> But if you use that "better
> free tool" from Microsoft you're stuck on Windows on Intel. I'd rather be
> stuck on the mainframe.

The mainframes you are thinking of -- are they very different from a
multi-CPU machine running microcode on standard Intel or AMD CPUs?


Cheers,
L.W.

[Pete Dashwood]

A good response, Fritz.

I enjoyed it, thanks. :-)

[Pete Dashwood]

The following is a combined response to both Fritz and Lueko.

There are some things anyone reading this should bear in mind:

1. Arguing whether COBOL is still viable is completely pointless. It is for
some people; it isn't for others. And some of us are now in positions where
we really don't care what language is used to build objects.

2. I use Microsoft tools every day and I develop for people who use
MicroSoft operating systems on their computers. I am not employed by MS, I
have no particular allegiance to them, but I do appreciate that they have
made my job easier. In my dealings with them I have found them to be
responsive, helpful, and knowledgeable. I cannot say the same about some
other computer companies I have dealt with. YMMV.

Now read on... :-)

Lüko Willms wrote:
> Am 15.11.2011 19:12, schrieb Fritz Wuehler:
>
>> Now Pete, COBOL is not the only thing that runs on a mainframe
>
> Sure
>
>> and it is not going away, objects have nothing to do with it.
>
> Investment inertia does. Companies have a stock of running programs,
> and it is for them not a light decision to convert it all to a new
> environment. But if you look closer, you will see more and more
> companies doing it.

You can put your head as deeply into the sand as you wish, but the FACT is
that an increasing number of Companies are moving away from COBOL. That
includes mainframe sites.

>
>> You'll have to get rid of
>> FORTRAN, PL/I and assembler until the mainframe goes Java.

And you don't think that's going to happen? :-) Look around... I haven't
seen any commercial sites running Fortran since around 1968 and I know
personally of three IBM Mainframe sites (all in the UK) that moved off PL/1
years ago.

>
> Especially speaking of IBM mainframes ... as far as I can see, IBM
> has been one of the companies which was in the forefront os pushing
> Java.
>>>> I predicted [COBOL] would be gone as a viable
>>>> commercial development language by 2015.
>>>>
>>>> I was wrong.
>>>>
>>>> It has already happened.
>
>> Not everywhere, people are still hiring.

Tell Bill.

And I don't really see any need to defend my statement. When something goes
form being in the top 3 to being 25th, it is reasonable to say it is not
viable. Eeven if it is not quite extinct (and it is not 2015 yet...) there
are many (around 24 to be exact) development languages which people think
are better.

>
> I know. Companies do not lightly give up all the investment in
> running programs which had grown over several decades. "Don't touch a
> running system" is a well know and very well followed rule.
>
> But if companies are looking for COBOL programmers, they are --
> methinks -- looking for replacements to their old programmers who
> retire to profit from their old age pensions.

I agree. But what actually happens is that they then review the whole cost
of maintaining COBOL into the future and the bean counters tell them to bin
it. As long as nothing rocks the boat, things will tick over fine; as soon
as someone retires or they can't get a replacement the whole issue is
brought into sharper focus.

>
>> Yawn...really now Pete. That list is for people who think a PC is a
>> computer. They don't have any idea that companies have things like
>> mainframes, minis and servers.

That is a little bit arrogant, Fritz. There are some very capable people
who really DO understand IT, working in places where they don't run
mainframes. (I have worked with some of them and learned much...)

>
> What is today a "mini"?
>
> Does Data General still exist? Wang? Nixdorf?

Good questions, Lueko.

>
>>>> Although I would not recommend anyone stay with COBOL long term,
>>>> mostly people find out for themselves when they get the
>>>> maintenance bill for their expensive COBOL compiler and then
>>>> realise they could do the same job with a better free tool from
>>>> Microsoft.
>
> I think that tehre are few free tools from Microsoft. All they want
> to do is sell, sell, sell...

I don't think that is fair. It is a different Company than it was 10 years
ago. You could argue that three of their major development tools would be an
IDE, a COMPILER, and a RDBMS. Many companies in the business of IT Tools see
these as bread and butter. (And charge like wounded bulls for them...)

Microsoft have several IDE type tools (Visual Studio, Expression Blend, and
some specialist IDEs for other areas), at least three major compilers (C#,
VB.Net, C++), and two RDBMS (one lightweight (Access) and one industrial
strength (SQL Server)), and ALL of them are available free, although some
will require a fee after 60 days. The three most important ones for me are
Visual Studio, C#, and SQL Server. ALL of these are unreservedly FREE in the
Express Editions. And, contrary to what you might think, the Express
Editions are more than adequate for most development needs. The latest R2 of
SQL Server 2008 is a completely free download and use. All they ask is that
you register it. There is no cost to do so and they never hassle you. There
are NO runtime fees or fees of any other kind; it is a FREE product. So is
Visual Studio Express and so is C#. The only reason you might require a paid
license would be if you need a high performance multi-server industrial
repository with all the infrastructure that goes with that. Most people
don't and if they did they would probably go to Azure and run in the Cloud.

As for "sell, sell, sell", do you know of any company that doesn't do that?
Sales are a necessary part of staying in business.:-)

I can only speak from my own actual experience. Currently I'm at school
learning new stuff that I will need to facilitate movement to Win 8. (mainly
XAML and background concepts on User Interfaces, Graphic Design, User
Experience, and such. I hope to produce better web sites and application
interfaces by the time I am finished.) For "extra credit" (you need to
acquire evaluation credit to progress through the course as succeeding
levels are only available when you pass the lower levels... it is kind of
fun really. I flunked a unit this morning and was so annoyed I immediately
re-did it and passed :-)) you can do a few units on Windows Phone so I'll
probably do that too. The lessons are excellent, I'm enjoying the learning
experience and becoming aware of stuff I had no idea existed. The videos I
am doing are free from Microsoft as part of their Toolbox program. At no
point has anyone started banging the drum for Microsoft and at no point have
I felt compelled to purchase anything.

Having said that, it is on the cards that I'll purchase Expression Blend but
no one is pressing me to and it is absolutely worth the money. Best tool I
have ever seen for what it does.

>
>> That doesn't make any sense. Microsoft is not the only company and
>> Windows on Intel is not the only platform in the world.

Sure, to save me having to put disclaimers on future posts can you take it
as read that I am developing for the Microsoft environment, specifically
.Net and Windows 8? I have a passing interest in other platforms but it is
only passing.

Does my statement make sense now? :-)

(Note that I don't require you to make the same statement regarding your
employment on IBM mainframes; I can deduce it from your post and am not
offended by it.)

>
> Sure, it is threatened by iOS and Android operating systems.
>

You have no idea how ludicrous that statement is. Android may not even be
legal :-)

There is no threat to Microsoft interests from either of these quarters.
They will probably never gain the share of the mobile device market that
Apple and Google are getting but it doesn't matter. They are producing
something that will run across ALL platforms without code changes. People
who like what they have at work will possibly want it on their phone. People
who have a phone will definitely want the same kind of interfaces on what
they have at work. Buying Microsoft will guarantee that, buying other brands
may not. The Metro interface will decide the fate of the company. If it
fails then Microsoft will be in serious trouble. But what I've seen so far
does not look to me like a failed product. When I get a few minutes I'll
post a demo of what I'm talking about.

In five years time, see if you still think they are "threatened" by Android
and iOS. That is a user perception. It isn't shared by anyone I know at MS.

>> But if you use that "better
>> free tool" from Microsoft you're stuck on Windows on Intel. I'd
>> rather be stuck on the mainframe.

We are all happy to be "stuck" on whatever we are comfortable with. I liked
your statement, it was fair and honest and it made me smile :-)

Pete

[Richard]

On Nov 16, 5:12 pm, "Pete Dashwood"

<dashw...@removethis.enternet.co.nz> wrote:

> I don't think that is fair. It is a different Company than it was 10 years
> ago. You could argue that three of their major development tools would be an
> IDE, a COMPILER, and a RDBMS. Many companies in the business of IT Tools see
> these as bread and butter. (And charge like wounded bulls for them...)
>
> Microsoft have several IDE type tools (Visual Studio, Expression Blend, and
> some specialist IDEs for other areas), at least three major compilers (C#,
> VB.Net, C++), and two RDBMS (one lightweight (Access) and one industrial
> strength (SQL Server)), and ALL of them are available free, although some
> will require a fee after 60 days.

If it requires a fee after 60 days then it is _not_ free.

> The three most important ones for me are
> Visual Studio, C#, and SQL Server. ALL of these are unreservedly FREE in the
> Express Editions. And, contrary to what you might think, the Express
> Editions are more than adequate for most development needs. The latest R2 of
> SQL Server 2008 is a completely free download and use. All they ask is that
> you register it. There is no cost to do so and they never hassle you. There
> are NO runtime fees or fees of any other kind; it is a FREE product.

That is simply not true. Windows is not free. To use those products
Windows OS is required. It may be that the run-time is part of that
cost. It may be that one _has_ to (mostly) pay for Windows when buying
a computer at retail. But it is not free.

Also, from what I can tell, the SQL Server client machines require CAL
licences which are not free. (alternately one can pay a $few thousand
for a server licence).

The free products are only free for developers, not for deployment of
applications. Your customers are expected to pay for SQLServer and/or
the associated CALs as well, probably, as having the latest version of
Windows which may cost an upgrade.

> you can do a few units on Windows Phone so I'll
> probably do that too.

The latest Gartner report has Windows Mobile/Phone 7.x in 6th place
with a falling market share.

"""The Gartner report also notes that Windows Phone’s market share
dropped, from 2.7 percent in the third quarter of 2010 to only 1.5
percent this year."""

> >   Sure, it is threatened by iOS and Android operating systems.
>
> You have no idea how ludicrous that statement is. Android may not even be
> legal :-)

That is just pure FUD that Microsoft is paying people to throw around.

The desktop market is in decline as people buy iPads and phones that
can do much of what they want. Because they spend money on these and
use their desktop less they can't justify replacing their old desktop.
So fewer are buying Windows.

If you can't see that this is a threat to Microsoft's revenue then I
don't know what you can see.

> There is no threat to Microsoft interests from either of these quarters.
> They will probably never gain the share of the mobile device market that
> Apple and Google are getting but it doesn't matter. They are producing
> something that will run across ALL platforms without code changes.

That is not true. While it may be that when Windows 8 and Windows
Phone 8 come out, sometime next year, they may use the same tools with
much the same code, it is not true that an application designed for
running on the desktop will run on a phone.

What they have said is that a Windows Phone app, developed to a common
set of features, will run on Windows 8. How useful a phone app on a
desktop would be is yet to be seen.

> People
> who like what they have at work will possibly want it on their phone. People
> who have a phone will definitely want the same kind of interfaces on what
> they have at work. Buying Microsoft will guarantee that, buying other brands
> may not.

Given that the MS market share of phones has nearly halved and is down
to less than 2% it seems that they don't want the Metro interface on
their phones (preferring 5 other systems) and so the conclusion may be
that they also won't want it on their desktops.

> The Metro interface will decide the fate of the company. If it
> fails then Microsoft will be in serious trouble. But what I've seen so far
> does not look to me like a failed product. When I get a few minutes I'll
> post a demo of what I'm talking about.

It is not even a product yet. It may be one in a year or so.

Meanwhile other companies are also developing products.

> In five years time, see if you still think they are "threatened" by Android
> and iOS. That is a user perception. It isn't shared by anyone I know at MS.

Actually there was a meeting a year or so ago where Ballmer did list
Linux as a threat. It is certain that they see Google and Android as a
threat, otherwise they, and their proxies, wouldn't be taking spurious
legal action against them. See Barnes & Noble analysis of the junk
patents that Microsoft is trying to assert.

[Nomen Nescio]

> Especially speaking of IBM mainframes ... as far as I can see, IBM
> has been one of the companies which was in the forefront os pushing Java.

But even today, the APIs available for Java cannot do everything a COBOL
program can do. VSAM is a good example.

> But if companies are looking for COBOL programmers, they are --
> methinks -- looking for replacements to their old programmers who retire
> to profit from their old age pensions.

I know of at least one half billion dollar project to develop a new banking
system in the last 5 years.

> > Yawn...really now Pete. That list is for people who think a PC is a
> > computer. They don't have any idea that companies have things like
> > mainframes, minis and servers.
>
> What is today a "mini"?
>
> Does Data General still exist? Wang? Nixdorf?

iSeries? POWER? OS/400. All running and POWER continues to be developed. And
they even still use RPG!

> The mainframes you are thinking of -- are they very different from a
> multi-CPU machine running microcode on standard Intel or AMD CPUs?

Yes, they are completely different. I guess you never worked on a mainframe?

[Lüko Willms]

Am 16.11.2011 09:59, schrieb Nomen Nescio:
>> The mainframes you are thinking of -- are they very different from a
>> > multi-CPU machine running microcode on standard Intel or AMD CPUs?

> Yes, they are completely different. I guess you never worked on a mainframe?

Your guess is wrong. I did.


Cheers,
L.W.

[Nomen Nescio]

Lüko Willms <lueko....@domain.invalid> wrote:

You don't seem to know about minis either. I pointed out iOS is still out
there, the POWER boxes are the evolution of S/36 and S/38 minis. You seem to
like arguing with people. I see no matter what anyone says, whether he
agrees with you or not, your answer is to disagree with him. Maybe covering
up for general lack of knowledge...

[Robert Wolfe]

Bill,

I'll send you the information that I have via private e-mail.



On Nov 14, 9:48 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <5e9f258a-4e0b-4ca1-8ed8-44b97f468...@w3g2000vbw.googlegroups.com>,

>         Robert Wolfe <rtwolf...@gmail.com> writes:
>
> > Bill,
> > I believe that I also saw that Kraft Foods up in your area is seeking
> > COBOL professionals.
>
> Don't know of any Kraft foods places around here and a quick search of
> their careers page with the keyword COBOL returns nothing.  Got a pointer?
>
> Another comment on the list of schools still teaching COBOL.  Notice how
> they tend to be clustered around current or former IBM strongholds?
>
> When I worked at West Point, NY we had an intern come in from Marist (which
> is in the heart of IBM country).  The only language the intern had klearned
> at Marist was APL.  :-)
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves

> billg...@cs.scranton.edu |  and a sheep voting on what's for dinner.

[Bill Gunshannon]

In article <5c922a94-ef70-4365...@e3g2000vbs.googlegroups.com>,

Robert Wolfe <rtwo...@gmail.com> writes:
> Bill,
> I'll send you the information that I have via private e-mail.

Thanks I'll watch for it.


bill

bill...@cs.scranton.edu | and a sheep voting on what's for dinner.

[Fritz Wuehler]

You asked a question that demonstrates you have no idea what a mainframe is. If
you understood mainframes you would realize they are very different from "a

multi-CPU machine running microcode on standard Intel or AMD CPUs"

What is the reason for your question? Are you just blabbering or did you
have some purpose for asking it?

[Lüko Willms]

Am 17.11.2011 06:14, schrieb Fritz Wuehler:
>>>> The mainframes you are thinking of -- are they very different from a
>>>>> > >> > multi-CPU machine running microcode on standard Intel or AMD CPUs?
>> >
>>> > > Yes, they are completely different. I guess you never worked on a mainframe?
>> >
>> > Your guess is wrong. I did.
> You asked a question that demonstrates you have no idea what a mainframe is. If
> you understood mainframes you would realize they are very different from "a
> multi-CPU machine running microcode on standard Intel or AMD CPUs"
>
> What is the reason for your question? Are you just blabbering or did you
> have some purpose for asking it?

The purpose was clearly visible: to give a hint on the changes in
computing over the past decades, the creeping demise of COBOL being one
of its aspects.

As far as I can see, there are three mainframe manufacturers left
over from "IBM and the Seven Dwarfs": Unisys, Fujitsu (carrying on the
former Siemens BS2000 line, i.e. RCA's TSOS), and of course IBM.

In my view, only IBM would be able to build bespoke CPUs for their
zOS machines, but their byte architecture would fit perfectly in the
byte architecture of Intel/AMD CPUs, so it would be easy for IBM to use
such CPUs, and much more economically than building bespoke chips.
Unisys with their 36 bit and 48 bit mainframe architectures have much
more problems with that.


Cheers,
L.W.

[Nomen Nescio]

Lüko Willms <lueko....@domain.invalid> wrote:

> As far as I can see, there are three mainframe manufacturers left
> over from "IBM and the Seven Dwarfs": Unisys, Fujitsu (carrying on the
> former Siemens BS2000 line, i.e. RCA's TSOS), and of course IBM.

All you need is IBM. In almost 40 years in the business I haven't ever
worked on anything else and I have never been in a shop that didn't have an
IBM machine. I have seen plenty of brand X disks and tapes, but never an
Amdahl or Unisys or Fujitsu box.

> In my view, only IBM would be able to build bespoke CPUs for their
> zOS machines, but their byte architecture would fit perfectly in the
> byte architecture of Intel/AMD CPUs,

This statement is so totally wrong I don't know where to begin.

IBM ISA is nothing like Intel/AMD, nothing like POWER or any RISC ISA on the
market, and nothing like any other common microprocessor ISA.

IBM *already* builds CPUs for z/OS and z/OS will *only* run on those CPUs
and could *never* be ported to any other ISA. Get the Principles of
Operations Manual for z/OS and the ISA handbook for POWER and the Intel
or AMD processor manuals, open them up side by side, and stop taking
drugs. Your comment is totally out of line with reality.

> so it would be easy for IBM to use such CPUs, and much more economically
> than building bespoke chips. Unisys with their 36 bit and 48 bit
> mainframe architectures have much more problems with that.

Word size is the least of the problems. You do realize the whole OS, the
assembler, and all the compilers are based on a specific ISA and to get
all that to work with any other ISA, even if there was anything similar in the
world, which there is not, would require a total rewrite?

You do realize IBM's ISA is big-endian, and Intel/AMD are little-endian? You
do realize all of the disk and tape files and data base contents would be
instantly worthless since IBM's native data types other than integer aren't
available on any other ISA? Intel/AMD can't operate on IBM packed decimal or
floating point data even if they could fix the endianness problem which
itself is far from trivial. Right now you can still read data from files
created in 1964. Under your ingenius plan 50 years of data is instantly
worthless.

Oh, you thought z/OS was a toy like UNIX? No, it isn't. It's a real OS,
optimised to a specific ISA and specific hardware and can't be ported
without a total rewrite of the OS, compilers, assembler, and all the vendor
products ever written. That's a few trillion dollars of R&D and you think
they can do that all over again in a week and use chips from toy computers?
Think again.

Like I said, your question shows you have no idea at all what you're talking
about.

[Lüko Willms]

Am 17.11.2011 16:44, schrieb Nomen Nescio:

> All you need is IBM.

Wow!

> In almost 40 years in the business I haven't ever worked
> on anything else and I have never been in a shop that didn't have an
> IBM machine.

Ah, now I understand the above quoted principal: you lack experience!

> IBM*already* builds CPUs for z/OS and z/OS will*only* run on those CPUs
> and could*never* be ported to any other ISA.

Besides that I don't know what the MUM ISA means in that context, I
got my Byte Assembler (i.e. the one developed by IBM for the /360)
training on a CDC 3300 (CDC = Control Data) emulating an IBM byte machine.

> Get the Principles of Operations Manual for z/OS and the ISA handbook
for POWER and the Intel
> or AMD processor manuals, open them up side by side, and stop taking
> drugs. Your comment is totally out of line with reality.

Whow!

> Word size is the least of the problems. You do realize the whole OS, the
> assembler, and all the compilers are based on a specific ISA and to get
> all that to work with any other ISA, even if there was anything similar in the
> world, which there is not, would require a total rewrite?

No, it would just require some microcode to emulate a byte CPU of the
type which had been used by IBM and a number of other manufacturers. It
is the usual weighing of processing speed vs. development cost.

> Oh, you thought z/OS was a toy like UNIX?

You know that you can run UNIX (or is it Linux?) on a IBM z machine?

Your dismissal of Unix is quite telling.

> Like I said, your question shows you have no idea at all what you're talking
> about.

Maybe I just have more experience of a wider scope than you who has
admittedly never worked with any other computer than an IBM mainframe.


Cheers,
L.W.

[Richard]

There have been some CPUs which could be microcoded to emulate other
CPUs. These were designed from the ground up to do so. Generally they
turned out to be much slower than the ones they were emulating.
Current Intel CPUs cannot be microcoded in this way, it won't change
the instruct set or byte order.

IBM mainframes have been emulated in software, for example the IBM XT/
370 which used a couple of addin boards with a couple of 68000
processors plus some specialised memory accessing hardware for virtual
memory. The 68000s ran emulation software that could in turn run 370
software - very slowly compared to a real machine.

Hercules did write an emulator using top-end Intel based systems. It
seems that it can get to the performance of an entry level zSeries,
but like you can't get 9 women to have a baby in a month, a rack full
of Intel CPUs isn't necessarily a replacement for a mainframe.

> > Oh, you thought z/OS was a toy like UNIX?
>
>    You know that you can run UNIX (or is it Linux?) on a IBM z machine?
>
>    Your dismissal of Unix is quite telling.

Z series can run dozens of Linux instances alongside other workload.
These are versions compiled for the machine.

You can run MS-DOS on a Linux machine using DOSBOX, but that does not
make MS-DOS an equivalent to Unix/Linux.

[Nomen Nescio]

Lüko Willms <lueko....@domain.invalid> wrote:

> > In almost 40 years in the business I haven't ever worked
> > on anything else and I have never been in a shop that didn't have an
> > IBM machine.
>
> Ah, now I understand the above quoted principal: you lack experience!

Ah, now I understand your problem: you lack the ability to read what's
written. You continue to quote poorly and remove the context to "prove" your
point. Unfortunately that makes you look very stupid, since you can't
understand what you read and you are replying to something I never said.

Asshole: in the time I've been working I haven't worked on a non-IBM
mainframe nor have I been in a shop that had a mainframe that wasn't made by
IBM. That was clear but you snipped and misquoted, this is a pattern with
you. I have worked on numerous platforms, but the only thing that is a
mainframe is made by IBM. This is in response to your earlier idiotic
statement. The point is IBM makes enough mainframes and has enough market
share those other companies you mention don't count.

> > IBM*already* builds CPUs for z/OS and z/OS will*only* run on those CPUs
> > and could*never* be ported to any other ISA.
>
> Besides that I don't know what the MUM ISA means in that context

GAME OVER


Now here's the recap for our viewers who might have been fooled by slow-hand
Luko's selective quoting

He wrote:

> In my view, only IBM would be able to build bespoke CPUs for their
> zOS machines, but their byte architecture would fit perfectly in the
> byte architecture of Intel/AMD CPUs,

I wrote:

This statement is so totally wrong I don't know where to begin.

IBM ISA is nothing like Intel/AMD, nothing like POWER or any RISC ISA on the
market, and nothing like any other common microprocessor ISA.

IBM *already* builds CPUs for z/OS and z/OS will *only* run on those CPUs
and could *never* be ported to any other ISA. Get the Principles of

Operations Manual for z/OS and the ISA handbook for POWER and the Intel
or AMD processor manuals, open them up side by side, and stop taking
drugs. Your comment is totally out of line with reality.

He wrote:

> so it would be easy for IBM to use such CPUs, and much more economically
> than building bespoke chips. Unisys with their 36 bit and 48 bit
> mainframe architectures have much more problems with that.

I wrote:

Word size is the least of the problems. You do realize the whole OS, the
assembler, and all the compilers are based on a specific ISA and to get
all that to work with any other ISA, even if there was anything similar in the
world, which there is not, would require a total rewrite?

You do realize IBM's ISA is big-endian, and Intel/AMD are little-endian? You
do realize all of the disk and tape files and data base contents would be
instantly worthless since IBM's native data types other than integer aren't
available on any other ISA? Intel/AMD can't operate on IBM packed decimal or
floating point data even if they could fix the endianness problem which
itself is far from trivial. Right now you can still read data from files
created in 1964. Under your ingenius plan 50 years of data is instantly
worthless.

Oh, you thought z/OS was a toy like UNIX? No, it isn't. It's a real OS,
optimised to a specific ISA and specific hardware and can't be ported
without a total rewrite of the OS, compilers, assembler, and all the vendor
products ever written. That's a few trillion dollars of R&D and you think
they can do that all over again in a week and use chips from toy computers?
Think again.

[Fred Mobach]

Nomen Nescio wrote:

> Lüko Willms <lueko....@domain.invalid> wrote:
>
>> As far as I can see, there are three mainframe manufacturers left
>> over from "IBM and the Seven Dwarfs": Unisys, Fujitsu (carrying on
>> the former Siemens BS2000 line, i.e. RCA's TSOS), and of course IBM.
>
> All you need is IBM. In almost 40 years in the business I haven't ever
> worked on anything else and I have never been in a shop that didn't
> have an IBM machine. I have seen plenty of brand X disks and tapes,
> but never an Amdahl or Unisys or Fujitsu box.

I have seen a number of Siemens mainframes running OS'en like TSOS,
BS1000 and BS2000. Not their BS3000 IBM-compatible OS from Siemens AG
(historical), which was removed after IBM started a trial on that. But
on some of those systems IBM's OS'es could run (because the Assembler
instructions were equal ?).

>> In my view, only IBM would be able to build bespoke CPUs for their
>> zOS machines, but their byte architecture would fit perfectly in the
>> byte architecture of Intel/AMD CPUs,
>
> This statement is so totally wrong I don't know where to begin.
>
> IBM ISA is nothing like Intel/AMD, nothing like POWER or any RISC ISA
> on the market, and nothing like any other common microprocessor ISA.

True.

> IBM *already* builds CPUs for z/OS and z/OS will *only* run on those
> CPUs and could *never* be ported to any other ISA. Get the Principles
> of Operations Manual for z/OS and the ISA handbook for POWER and the
> Intel or AMD processor manuals, open them up side by side, and stop
> taking drugs. Your comment is totally out of line with reality.

While not comparable on speed Hercules seems to do well in their job of
emulation (see www.hercules-390.org).

>> so it would be easy for IBM to use such CPUs, and much more
>> economically
>> than building bespoke chips. Unisys with their 36 bit and 48 bit
>> mainframe architectures have much more problems with that.
>
> Word size is the least of the problems. You do realize the whole OS,
> the assembler, and all the compilers are based on a specific ISA and
> to get all that to work with any other ISA, even if there was anything
> similar in the world, which there is not, would require a total
> rewrite?
>
> You do realize IBM's ISA is big-endian, and Intel/AMD are
> little-endian? You do realize all of the disk and tape files and data
> base contents would be instantly worthless since IBM's native data
> types other than integer aren't available on any other ISA? Intel/AMD
> can't operate on IBM packed decimal or floating point data even if
> they could fix the endianness problem which itself is far from
> trivial. Right now you can still read data from files created in 1964.
> Under your ingenius plan 50 years of data is instantly worthless.
>
> Oh, you thought z/OS was a toy like UNIX? No, it isn't. It's a real
> OS, optimised to a specific ISA and specific hardware and can't be
> ported without a total rewrite of the OS, compilers, assembler, and
> all the vendor products ever written. That's a few trillion dollars of
> R&D and you think they can do that all over again in a week and use
> chips from toy computers? Think again.

While I'm not in the know of IBM mainframes I would like to ask why I
know some options you didn't mention.
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..

[Lüko Willms]

Am 18.11.2011 02:24, schrieb Nomen Nescio:

> Asshole:

Sure, whith this propensity to sling such insults around, you have to
hide behind anonymity.

> in the time I've been working I haven't worked on a non-IBM
> mainframe nor have I been in a shop that had a mainframe that wasn't made by
> IBM.

Exactly. You have no experience at all with other mainframes. Nil.
Nada. You lack experience.


Cheers,
L.W.

[Lüko Willms]

Am 18.11.2011 12:02, schrieb Fred Mobach:
> I have seen a number of Siemens mainframes running OS'en like TSOS,
> BS1000 and BS2000. Not their BS3000 IBM-compatible OS from Siemens AG
> (historical), which was removed after IBM started a trial on that. But
> on some of those systems IBM's OS'es could run (because the Assembler
> instructions were equal ?).

I guess the OS also needs more than just a compatible CPU, but also
an overall machine architecture, of addressing e.g. mass storage
subsystems etc.


Cheers,
L.W.

[Fred Mobach]

That's indeed what Siemens advertised with his I/O subsystems. And the
previous countries behind the iron curtain with their ESER systems (up
to the IBM/390 level).

[Fritz Wuehler]

Fred Mobach <fr...@mobach.nl> wrote:

> I have seen a number of Siemens mainframes running OS'en like TSOS,
> BS1000 and BS2000. Not their BS3000 IBM-compatible OS from Siemens AG
> (historical), which was removed after IBM started a trial on that. But
> on some of those systems IBM's OS'es could run (because the Assembler
> instructions were equal ?).

I realize other companies make IBM clones, some of my coworkers are ex
hardware guys from Amdahl and Unisys. My point to the idiot Juko is those
clones have no market share. I've been in hundreds of installations and
never seen one and AFAIK none of the customers for any of the companies
I've worked for had one either. Juko's talent for misquoting has messed up
the thread. Your question at the end is based on his misquoting and from not
reading what I wrote but rather what he claimed I wrote.

> While not comparable on speed Hercules seems to do well in their job of
> emulation (see www.hercules-390.org).

Speed is an issue for big shops that process millions of transactions an
hour. Hercules is excellent for development and testing but it cannot
support mainframe workloads on available Intel boxes, they can't support the
I/O or terminal networks or coupling facilities, etc. etc. etc.

Another issue is it is not IBM hardware and it's not 100% compatible and IBM
doesn't license anything to run on it. If you read the Hercules mailing list
you will see many errors reported, some are not really errors but some
are. None of that happens on real hardware. And nobody is running production
on Hercules because it's against IBM's license terms. I would not trust my
production on it. It's fine for development on older (out of production
versions) of MVS. People have problems with newer z/VM and the software
development of Hercules will not be able to keep up with System Z.

Hercules runs on cheap hardware that doesn't have the RAS features of IBM's
machines that stay up for years and can hot swap boards and other
hardware. IBM mainframe DASD is far better than the best SAS drives you can
get with a SAN from Oracle. There are other issues besides emulation itself.

If IBM would license their OS to run on Hercules I could see some
non-critical work being run on Intel or SPARC boxes but there are many other
issues such as how to connect DASD, ESCON, etc. and other issues we don't
even know about yet.

There were other solutions like the P/390 and Flex/ES but they were taken
off the market by IBM because it was possible to run small workloads on them
and possibly threaten their hardware sales although performance and
reliability issues were present on those devices as well. The P/390 had a
real 390 processor on board. Flex/ES was an emulator.

Juko's claim was about hardware CPU emulation and I refuted that. In fact
there have been many instances of chipmakers using hardware emulation to
support prior versions of code, architecture etc. and very few of them were
acceptable, even when you're talking about chips from the same manufacturer.
So far not many companies are willing to do the R&D or corp espionage
involved in cloning mainframe CPUs, it's a few billion USD in R&D to get to
the point they are at now. The P/390 wasn't emulation, it was a real 390
architecture chip running on a PC chassis. It had some of the same issues as
other solutions like not being able to connect to a CF and had no ESCON
etc. The Flex/ES box had the same issues as Hercules but had no community
support. Neither is available now.

You are talking about software emulation, which is far far cheaper and
simpler, but has performance, RAS, and compatibility problems. A bigger
issue is neither software nor hardware emulation is going to keep pace with
System Z at the present rate of development, realizing this kind of hardware
development pace is much greater than historically for the architecture. If
you spent money cloning a 370 or a 390 you had many years of product
life. If you try that with z/OS you'll find the expense much to great. IBM
is making sure the OS that runs on your box today will not run on that box 3
years from now. Only manufacturing giants can afford the R&D and
manufacturing to support that. Intel and AMD might be able to, and they
might not. Their business model is totally different, they sell many cheap
things rather than few expensive things. They haven't ever shown the
interest nor the ability to enter the IBM clone market.

[Lüko Willms]

Am 26.11.2011 23:15, schrieb Fritz Wuehler:
> I realize other companies make IBM clones, some of my coworkers are ex
> hardware guys from Amdahl and Unisys.

While Amdahl did, Unisys never made any IBM clones. Unisys is
continuing the mainframe lines of Sperry Univac and Borroughs.


L.W.

[Binyamin Dissen]

On Sat, 26 Nov 2011 23:15:06 +0100 Fritz Wuehler
<fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

:>Another issue is it is not IBM hardware and it's not 100% compatible and IBM

:>doesn't license anything to run on it. If you read the Hercules mailing list
:>you will see many errors reported, some are not really errors but some
:>are. None of that happens on real hardware.

Yes, it does. IBM publishes corrections to the firmnware.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Fritz Wuehler]

I admit I don't know my Unisys from my Univac. I used a Univac 360 or 370
clone years ago and I ASSumed Unisys was carrying on the same thing as
Univac. Thanks.

[HansJ]

On 28 Nov., 11:54, Fritz Wuehler
<fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

Fritz,

as you said, very long time ago, though it was not a 360 or 370 clone.
Most likely you are talking about the Univac 90/30 system.

Regards Hans

[Lüko Willms]

Am 28.11.2011 14:34, schrieb HansJ:
> as you said, very long time ago, though it was not a 360 or 370 clone.

as I said, neither Univac nor Borroughs ever went into that business.
They always had their own operating systems.

> Most likely you are talking about the Univac 90/30 system.

Or 90/70, 90/80 or so, the line which was inherited from RCA, with
RCA's TSOS renamed to OS/9. Siemens called it BS2000, and ICL still
something else.


Cheers,
L.W.

[Bill Gunshannon]

In article <1d06aa7f3bb0ecf9...@msgid.frell.theremailer.net>,

The 360 and 370 were IBM. Univac had the 1100 which has continued life
as the 2200 today.

bill


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves

[Howard Brazee]

On Mon, 28 Nov 2011 07:33:58 +0100, L�ko Willms
<lueko....@domain.invalid> wrote:

>> I realize other companies make IBM clones, some of my coworkers are ex
>> hardware guys from Amdahl and Unisys.
>
> While Amdahl did, Unisys never made any IBM clones. Unisys is
>continuing the mainframe lines of Sperry Univac and Borroughs.

Although, it can be argued that IBM made a Univac clone.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison

[Lüko Willms]

Am 28.11.2011 16:34, schrieb Howard Brazee:
> Although, it can be argued that IBM made a Univac clone.

?? How that?


L.W.

[Bill Gunshannon]

In article <7da7d7h0p8u6ufuhh...@4ax.com>,
Howard Brazee <how...@brazee.net> writes:
> On Mon, 28 Nov 2011 07:33:58 +0100, Lüko Willms

> <lueko....@domain.invalid> wrote:
>
>>> I realize other companies make IBM clones, some of my coworkers are ex
>>> hardware guys from Amdahl and Unisys.
>>
>> While Amdahl did, Unisys never made any IBM clones. Unisys is
>>continuing the mainframe lines of Sperry Univac and Borroughs.
>
> Although, it can be argued that IBM made a Univac clone.

Which univac system did IBM ever clone?

I never saw any similarity, beyond both being computers, between IBM
and Univac systems. Certainly no similarity at the user or programmer
level.

[Howard Brazee]

On 28 Nov 2011 15:53:02 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
wrote:

>> Although, it can be argued that IBM made a Univac clone.
>
>Which univac system did IBM ever clone?
>
>I never saw any similarity, beyond both being computers, between IBM
>and Univac systems. Certainly no similarity at the user or programmer
>level.

Back in the early days, everybody except IBM hired design engineers
and then laid them off when the job was done. The Univac 90-30 was
designed by RCA engineers who were later hired by IBM. I've worked
on it and it is much closer to IBM than it is to, say 1100 series
Univac.

[Nomen Nescio]

bill...@cs.uofs.edu (Bill Gunshannon) wrote:

> In article <1d06aa7f3bb0ecf9...@msgid.frell.theremailer.net>,
> Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> writes:
> > Lüko Willms <lueko....@domain.invalid> wrote:
> >
> >> Am 26.11.2011 23:15, schrieb Fritz Wuehler:
> >> > I realize other companies make IBM clones, some of my coworkers are ex
> >> > hardware guys from Amdahl and Unisys.
> >>
> >> While Amdahl did, Unisys never made any IBM clones. Unisys is
> >> continuing the mainframe lines of Sperry Univac and Borroughs.
> >
> > I admit I don't know my Unisys from my Univac. I used a Univac 360 or 370
> > clone years ago and I ASSumed Unisys was carrying on the same thing as
> > Univac. Thanks.
>
> The 360 and 370 were IBM. Univac had the 1100 which has continued life
> as the 2200 today.

Was the 1100 360 or 370 compatible? I remember writing IBM assembler and it
worked on whatever they were calling a Univac and hiding back there...

[Howard Brazee]

On Tue, 29 Nov 2011 02:09:39 +0100 (CET), Nomen Nescio
<nob...@dizum.com> wrote:

>> The 360 and 370 were IBM. Univac had the 1100 which has continued life
>> as the 2200 today.
>
>Was the 1100 360 or 370 compatible? I remember writing IBM assembler and it
>worked on whatever they were calling a Univac and hiding back there...

No, the 1100 was quite different (not as different as Burroughs). The
90-30 was the Univac model close to IBM.

[HansJ]

On 28 Nov., 16:25, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <1d06aa7f3bb0ecf97d4dcb5a2c874...@msgid.frell.theremailer.net>,
>         Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> writes:

>
> > Lüko Willms <lueko.wil...@domain.invalid> wrote:
>
> >> Am 26.11.2011 23:15, schrieb Fritz Wuehler:
> >> > I realize other companies make IBM clones, some of my coworkers are ex
> >> > hardware guys from Amdahl and Unisys.
>
> >>    While Amdahl did, Unisys never made any IBM clones. Unisys is
> >> continuing the mainframe lines of Sperry Univac and Borroughs.
>
> > I admit I don't know my Unisys from my Univac. I used a Univac 360 or 370
> > clone years ago and I ASSumed Unisys was carrying on the same thing as
> > Univac. Thanks.
>
> The 360 and 370 were IBM.  Univac had the 1100 which has continued life
> as the 2200 today.
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves

> billg...@cs.scranton.edu |  and a sheep voting on what's for dinner.

> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>

Bill,

you are missing quite a few systems, the 9400 series running OS/4, the
90/60, 90/70, 90/80 series running VS/9 (as Lueko mentioned), the
90/30, 90/40 and the system 80 series with a number of different
system running OS/3.

Not to mention the systems that have been available before the low end
9200 and 9300 was introduced. The 9200 and 9300 used to run a TOS
(Tape Operating System - if I recall it correct).

To get back to the COBOL part, VS/9 and OS/3 definitely had a COBOL
compiler from the beginning, I'm not sure about OS/4, at least I did
only write in assembler on that platform.

Regards Hans

[Bill Gunshannon]

In article <6ad168accac2889e...@dizum.com>,

I did IBM up thru the 4300 series and Univac from the 1100 and I never saw
anything compatable between them. I have never seen a Univac mainframe
that could run 360 code.

[HansJ]

On 28 Nov., 16:34, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 28 Nov 2011 07:33:58 +0100, L ko Willms
>

... never ever heard about IBM cloning something from Univac, can you
give me a clue?

[Howard Brazee]

On Tue, 29 Nov 2011 08:27:30 -0800 (PST), HansJ
<hans...@googlemail.com> wrote:

>> >   While Amdahl did, Unisys never made any IBM clones. Unisys is
>> >continuing the mainframe lines of Sperry Univac and Borroughs.
>>
>> Although, it can be argued that IBM made a Univac clone.
>>
>> --
>> "In no part of the constitution is more wisdom to be found,
>> than in the clause which confides the question of war or peace
>> to the legislature, and not to the executive department."
>>
>> - James Madison
>
>... never ever heard about IBM cloning something from Univac, can you
>give me a clue?

Note, I said "it can be argued" - The Univac 9030 was designed by RCA
engineers after RCA decided there was no future in computers. Then
Univac laid them off and IBM hired them. That computer was very
similar to IBM computers. Later on, Univac went in a different
direction.

[Fritz Wuehler]

> I did IBM up thru the 4300 series and Univac from the 1100 and I never saw
> anything compatable between them. I have never seen a Univac mainframe
> that could run 360 code.

http://en.wikipedia.org/wiki/UNIVAC_90/60
http://en.wikipedia.org/wiki/UNIVAC_90/70

You have now! Glad I wasn't imagining things. Looks like UNIVAC bought out
the RCA Spectra line in 1971. The UNIVAC I used was in late 1970 early
1980 timeframe. I didn't do any system programming so I don't know what OS
it used. I wrote application code and I know it used the 360 or 370
instruction set.

[Lüko Willms]

Am 29.11.2011 22:01, schrieb Fritz Wuehler:
>> I did IBM up thru the 4300 series and Univac from the 1100 and I never saw
>> > anything compatable between them. I have never seen a Univac mainframe
>> > that could run 360 code.
> http://en.wikipedia.org/wiki/UNIVAC_90/60
> http://en.wikipedia.org/wiki/UNIVAC_90/70
>
> You have now! Glad I wasn't imagining things. Looks like UNIVAC bought out
> the RCA Spectra line in 1971.

Exactly. Siemens also continued that line with their BS2000 systems.

> The UNIVAC I used was in late 1970 early 1980 timeframe.
> I didn't do any system programming so I don't know what OS
> it used.

That could be this RCA inheritance, or the 90/30, 9400, 9700, or
whatever. The larger systems ran the Univac version of TSOS, which was
called VS/9, the smaller systems had their own operating systems, e.g.
OS/3.

> I wrote application code and I know it used the 360 or 370
> instruction set.

That's what I explained in an earlier contribution to this thread:
CPU-Assembler compatible but not OS compatible. Only the latter would
qualify as an IBM clone, destined and able to run IBM's operating
systems. Neither Sperry Univac nor Borroughs ever tried to enter that
market.


Cheers,
L.W.

[HansJ]

On 29 Nov., 22:01, Fritz Wuehler

<fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:
> > I did IBM up thru the 4300 series and Univac from the 1100 and I never saw
> > anything compatable between them.  I have never seen a Univac mainframe
> > that could run 360 code.
>

> http://en.wikipedia.org/wiki/UNIVAC_90/60http://en.wikipedia.org/wiki/UNIVAC_90/70

>
> You have now! Glad I wasn't imagining things. Looks like UNIVAC bought out
> the RCA Spectra line in 1971. The UNIVAC I used was in late 1970 early
> 1980 timeframe. I didn't do any system programming so I don't know what OS
> it used. I wrote application code and I know it used the 360 or 370
> instruction set.

Fritz,

the 90/60, 90/70 and 90/80 where running VS/9 and are - as you said -
originating from RCA. The "IBM assembler" was basically supported, so
IBM assembler code was easily portable. The 90/30 running OS/3 was
supporting the IBM assembler (a few differences) as well, but the OS
was completely different.

If I recall it correctly, also the 9400 had a very similar assembler
instruction set as IBM.

Regards Hans

[HansJ]

On 29 Nov., 18:08, Howard Brazee <how...@brazee.net> wrote:
> On Tue, 29 Nov 2011 08:27:30 -0800 (PST), HansJ
>

Howard,

you are mixing up the 90/30 and the 90/60 (etc.). The 90/30 was a pure
Sperry Univac development, the 90/60 was the RCA. The OS for the 90/60
was VS/9, very sophisticated at that time and supported virtual
addressing.

Univac abendoned that VS/9 line after a fairly short time and I think
that was a failure.

Regards Hans

[fletzie]

On Wednesday, October 12, 2011 4:33:23 PM UTC-4, anonymous wrote:
> Hello,
>
> Has anyone successfully converted Microfocus NetExpress Cobol with imbedded SQL (pre compiled with Pro*COBOL) to NetCobol.net from Fujitsu?
>
> Can you point a novice (in COBOL) to a valuable place to look for help?
>
> Thanks

I suggest you also present your questions to any of the COBOL related groups on LinkedIn...You will find other opinions that might at least widen your options on how to proceed. Why was the COBOL code created in MicroFocus COBOL and what platform do you wish to use; are you changing platforms? Are you running under Windows now and MF Enterprise Server? You need to take into account all the other services wrapped around your COBOL systems whatever version of COBOL you use...whatever others may say about COBOL, it still runs 75% of the world's transactions per Gartner.