Re: Cobol for Visual sutdio



"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:DQuNk.3$Tx1.0@xxxxxxxxxxxxxxx
Pete Dashwood wrote:
"Nondisclosure007" <nondisclosure007@xxxxxxxxx> wrote in message
news:3e0efcba-4ea9-47a9-b362-084ba97255a4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I've seen the Fujitsu stuff, but is there anything for Visual Studio
2008? a compiler mostly?


People interested in using COBOL with Visual studio might do well to look
at some of these video tutorials:

http://www.microsoft.com/windowsserver/mainframe/training.mspx#cobol.net

This is a series of tutorials provided by MicroSoft, which demonstrates
the use of both Fujitsu (NeoKicks) and MicroFocus toolsets with Visual
Studio as part of a migration away from the mainframe platform.

.... and if Ballmer has his way, a migration away from COBOL ?

Not at all. Microsoft don't care WHAT language you use as long as you run it
on their platform.

If you followed the lnk above you should realise this.


Unfortunately, the videos are not "engaging" (although the presenter is
knowledgable) and there are some problems with being able to read
screens.

This is a factual, fairly dry presentation which I found difficult to
watch, but I hung in there because the quality of the information is good
and the content overall is interesting.

The one I watched showed how to bring a mainframe CICS application into
.NET using ASP.NET to scale the application to the Web.

(He also discusses, in a quite unassuming way, why you might want to do
this...)

While the video may not be "entertaining" it does get the job done and I
developed more warmth for the presenter as I got to know him better :-)

He quoted some impressive companies who have migrated from the mainframe
into .NET but I liked the fact that he was not Evangelical in his
approach.

I see the following two problems with this approach:

1. The tools (from both MicroFocus and Fujitsu) are expensive.
2. Moving COBOL to another platform does not address the underlying
problem with procedural code, which is the paradigm itself.

I am persuaded that the best approach if you are considering migration is
NOT to consider COBOL on .NET as an end point. (It may well be a good
starting point, though.)

Succesful migration WITH A FUTURE means layers (tiers) and objects. (This
means you are not "locked in" to COBOL, but you can still use it if you
want to. You can create objects that utilise the full capabilities of the
.NET Framework in modern languages (neither of the major COBOL for .NET
implemenations can use the full facilities of the environment that are
available through C#, for instance)

That sounds a bit of a sweeping statement. I can understand that as a
F/J user you could make such a statement, but with respect to M/F, are
you generalising or do you have specifics ?

It is a problem with the COBOL language so neither of them can implement it
(even if they wanted to...) Things like reflection, and LINQ are two very
important ones that come to mind immediately. There are others. I understood
from a MicroFocus white paper some time ago that they were not implementing
full COBOL into their .NET offering (neither were Fujisu). This may have
changed since.

The facilities are simply not in COBOL. Any COBOL...


They ain't dumb - for a
price, Fixpacks, they will keep their COBOL products in sync with
dotNet. They had Java OO inter-change classes back when you were
claiming here in CLC you hadn't got F/J support for Java.

I don't know when that would have been. Since version 6 Fujitsu has had
excellent support for Java. (They are currently on version 8).

and still have your legacy COBOL objects
continuing to work. It gives you choice; a direct migration of COBOL from
one platform to another doesn't do that, even though the migration is
quite straightforward using modern tools. (However, such a migration can
extend the life of your COBOL applications...))

COBOL programs are generally single tiered with direct access to data and
direct interaction with the user. Inserting interfaces between
Presentation and Data Access has huge advantages. Using objects means
that each layer is more "granular"; smaller granules means less overall
impact when making changes :-

Wish you hadn't written that. Yours and my concept of 'granules'
(methods) differ widely.

I wish you hadn't written that. It shows you didn't grasp what I'm talking
about.

"Granularity" in this context is not about Methods at all. It is about
objects and classes.

You finish up with several Sections in a method
- to me an absolute No, No !

Had you read more carefully, even with the misunderstanding about Methods,
you would have seen that I was advocating SMALLer as being better.

"Sections in a Method" applies only to COBOL. My comment was about objects
written in any language.


Did you for some $12 get a second-hand copy
of Arranga/Coyle from amazon - most of their methods are no more than a
few lines of code.

Most of mine are not either. In C#, Java or COBOL. (And even in the
occasional VBScript or JavaScript).

What part of "smaller granules means less overall impact when making
changes" did you not understand?

Even BEFORE I ever wrote OO, I learned from programming online systems that
"small is beautiful".

You are really preaching to the choir here, Jimmy.



changes


If you are dismissive of them, let me quote an old
army saying from Mesopotamia days, "They were in Baghdad before you were
in dad's bag". And Wilson Price (I'll get back on that, eventually),
take a look at his F-I-R-S-T Book sat on your bookshelf - can I make it
any clearer.

I don't know what it is you're seeking to make clear. You seem to think I
use multiple sections within methods when writing OO COBOL. I don't, (as a
general rule), never have, and understand why doing so is not good.

I was using small modular programs for CICS, IMS/DC, TASKMASTER, and even
Driver beads on ICL equipment long before Price, Coyle, and Arranga wrote
their books. I was in Baghdad when it was still Mesopotamia... :-)


Agreed his tutorial style examples start with a Procedural
and just flows down the page - take a closer look when he writes methods
in OO classes. Years ago, and be assured with no reference to you, in a
general enquiry from me, I asked how do you feel about a mix of
Procedural and Classes for OO - "Not impressed", he replied. "Get away
from Procedural formats and keep your methods small".

I have always done that. And not just in COBOL. It is the right way to go.

, using encapsulated objects means no regression testing. Data access
can be tuned without impact on program logic simply by optimizing Data
Access objects in the Data Access Layer. (I have been doing this recently
and managed to get from 180 rows per second returned on a cursor, to over
500, without change to application logic and using dynamic SQL...
Multithreading the Data Access Layer is very easy with an OO approach.)

I was fascinated by the inter-change between you and Robert on the above,
the use of 'sets' and 'tables' (???). I'll mention it in 'Last Hurrah
Part 2 - OO Factory'. Even just for info, it sounds like an extremely
interesting concept. Seriously, how do you know that can't be done in OO
COBOL ? Or did you do it using OO COBOL rather than C# ?

I did it in both COBOL (using Fujitsu's ESQL support) and C# where it isn't
ESQL. I never claimed set processing or multi-row fetches cannot be done in
COBOL. ( I have C# code which generates COBOL code to do it, as part of a
COBOL package). I did claim that Resultset processing is not how ESQL in
COBOL is generally implemented. You would have to use an ADO or DAO API to
do it from COBOL in a Windows environment, it would NOT be native ESQL. (I
have never seen it on a mainframe, and to use it on a PC is not the
perceived wisdom, which thinks that cursors are the only way to do
sequential processing.) In C# the best way to access data is with LINQ, but
that is not available in COBOL.


I believe there are some later videos in the set of tutorials above which
deal with OO COBOL and I plan to look at them as soon as I get some time.

Meantime, I am still happy with the Dashwood Model for Migration :-)

(If you haven't already, please see the diagram on:
http://primacomputing.co.nz/cobdata/ShowMe.aspx?ptitle=Process
flowdiagram...&pcontent=images/MigrationProcessOverview.jpg

Get ready to tear your hair out :-). I just looked using your link .

No need for hair tearing... you should simply read the post I made two
minutes after the one you are referencing, when I found out that the
Newsreader had corrupted the link I posted.

What you are seeing is my C# server side code (code-behind) actually trying
to build a page dynamically in accordance with what you asked it. ( a page
for "Process"...:-) It fails dismally of course, but it is a gallant
attempt... :-)

- Blue banner at top with unreadable menu bar because of colour choice.
The word "PROCESS" stands out boldly.
- big white space
- followed by a closing blue banner.

Well, Hey, it's a start... if you ever need a "Process" page... :-)

Guess I just have to stop using Mozilla if I want to see your gems :-).

Nothing to do with Mozilla or Firefox; it will render exactly the same in
IE.

The problem of compatibility has now been cracked and I don't expect to have
that problem again, (unless future releases of IE and or the "others"
implement new stuff that hasn't been stumbled on yet). It is correctable by
some smarter CSS which is what I did.

Correction; I just ran it again before sending this. I noticed the small
'Home' top right, clicked on that and took me to your home page with the
picture of a building being constructed. Didn't go beyond that.


Quite seriously - that other topic "M/F OO COBOL graduates". It could just
give COBOL a shot in the arm. COBOL (Procedural) is NOT a difficult
language to learn; I was completely self-taught.

Sanskrit is not a difficult language to learn either. I know personally of
two Classical scholars who recognise, speak, read, and write it as easily as
they do Greek and Latin. It doesn't have much application at the corner
store (even if the owner of said store comes from the sub-continent...).
Greek and Latin can be useful if you happen to be in Greece or Italy, but
they are no substitute for the modern versions that have replaced them.

The trouble with COBOL is that it is not being implemented as
objects/components. If it were, it would have much more relevance.

However, as your subject in the other thread states "it ain't dead yet" and
I don't expect it to be for some time to come (I'm on record as saying 2015;
I stand by that.) There is an increasing amount of migration across
platforms and also into OO languages going on. This will eventually take its
toll on COBOL.

A press release from MicroFocus stating that they have managed to give away
software tools which the rest of us are required to pay for, to around 50
Universities (given there are estimated to be some 8000 such seats,
worldwide,
http://answers.yahoo.com/question/index?qid=20070819035215AAwl5V4
this is less than 1%), while commendable from an Academic point of view, is
not going to stop the decline of COBOL. It is declining because it isn't
relevant, not because there is anything wrong with it.

Everything I can do in COBOL, I can do faster and cheaper in something else,
and more besides. COBOL is existing currently, primarily because of legacy.
The Multi-billion line code base Gartner claims for it, is being eroded
every year, through Migration (to a new platform, then picking up new
languages that are pertinent to that platform) and Conversion (refactoring
the existing COBOL code base to a different language... often Java).

They mention 2 million programmers. C++ has an estimated 60 million, C# 40
million and Java probably as much as both of them together. (these figures
are suspect; there is no really accurate way to confirm them. But so is the
2 million COBOL programmers... :-))

If somebody can come up with a text, from a developer's point-of-view,
gently easing their way through the OO concepts (as applied to COBOL),
then it might possibly have a fighting chance to disprove all your dire
predictions.

I don't see "dire predictions". I see simply the diminishing use of a 50
year old programming language which is expensive to buy, expensive to
maintain, and limited in its application to modern environments. Get over
it.

You are after all, just one man crying 'Chicken Little'.

You really do delight in spinning stuff I say. I have never suggested the
"sky is falling" just because COBOL is coming into its twilight. It is a
natural and to be expected progression. It would end SOMETIME... I see
exciting stuff in the things that will replace it.

Nevertheless, I agree that if COBOL people picked up OO concepts and OO
COBOL was implemented in more shops, there would probably be a chance of
extending its useful life. Or there might have been 10 years ago. I honestly
believe it is too late now. The problem with that (as I found myself) is
that once you really do get a grasp of these concepts, you realise that
COBOL is unwieldy at it and other OO languages (like Java, C++ and C#)
actually do it infinitely better.

And, no, I'm not the only one. I'm one of the few writing about it in this
forum. Many more are simply voting with their feet.

I am helping some of them.

Think about this:

Suppose you make your living from an application that was written nearly 30
years ago. You maybe maintain a small team of COBOL people to handle the
enhancements and changes that the Marketplace requires. The package is solid
and reliable and has great functionality. It was written originally in COBOL
for green screens and you had it converted to Windows some years back. (It
cost a consderable amount, but it extended the life of the software).
Although it is a niche market, you are not the only software vendor in it.
You have to compete to hold, never mind increase your market share. For 25
years you have built up your client base, been responsive to your customers
and have established yourself as a "player" in the industry.

Now you find your team are having more and more trouble making changes. The
code is "over maintained". Hundreds of monolithic programs with no
separation between Presentation, Business Logic, and Data Access.
Duplication in functions, code, and data access. Each new release has knock
on bugs in it. You go along and do presentations to people. They ask you
about the database you use and you explain it is highly efficient ISAM flat
files. They smile. Your competition visited yesterday and demoed his new SQL
Server based system runnning in .NET with the full Monty. The List Views and
drop downs that your team sweated over they can do in a couple of mouse
clicks, they bind data to controls and have no need of SQL, or database
connections. They process resultsets while your stuff uses READ NEXT...

They ask you what language you use. You tell them "COBOL, it is an ideal
language for commercial development". The smiles turn to sniggers.

You know you have lost the sale.

Now, what would you do?

Rewrite the whole application from scratch using modern tools techniques and
languages?

Ouch! Probably non viable. The cost is more than the Business can afford and
the time needed to do it is longer than you can hang in there for. You have
COBOL people; they have to be retrained, get around the learning curve and
be productive as quickly as possible. Some of them will probably quit
because they don't want to learn another language and can make a good living
running a Help desk for one of your competitors...:-)

So you think about Migration/Conversion. If you could run against a
relational Database, you could use a package like Crystal or StimulSoft to
handle the reporting which is currently embedded in COBOL. Some of your
customers are computer literate and would be very happy to call off their
own reports and run their own inquiries in SQL.

A new release of your system, RDB based, would save a lot of embarrassment
when doing presentations to potential customers. But Migration involves
building a database that is equivalent to your existing file structure,
loading it with your existing data, and changing all the programs to access
the new tables instead of ISAM. Risky, and arduous.

It's a lot of work. Fortunately, I have tools that can automate this
completely, and do it in seconds. I'll happily take on this work as an
outsource, or sell you the tools (for much less than a COBOL compiler for
..NET :-)), and you can do it yourself. The tools also create a Data Access
Layer comprised of objects. (This is the "granularity" I was referring
to...) So, now you have a Release that uses a database and has a two-tier
structure in the design. Integrated Presentation/Business Logic and a Data
Access Layer. The DB is normalized automatically to 2NF, the Data Access
objects can be multithreaded and tuned, performance is good, you can be less
afraid about doing presentations on it... :-)

But it is still far from perfect. You still have COBOL running the Business
Logic and it is convoluted, duplicated, and over maintained. Time to
refactor. Rip it up. Isolate the functions and wrap them as objects. (I use
COM but it could easily be MS's replacement for COM: WCF). Performed code
and called modules are easily reviewed and refactored.)

Visual Studio is a useful tool to help with this operation (it has functions
specifically designed to help with refactoring) but it is not easy to run
COBOL source in it unless you have one of the COBOL compilers for .NET. I
understand it can be done, but I haven't tried it myself yet.

While your team are learning the new OO language (and concepts) they are
refactoring and converting the old code to OO. (The exercise Robert and I
did here recently shows a Fujitsu example of doing this; MicroFocus have the
same functionality although it seems to me it is a little more complex to
build COM objects in that environment. Perhaps someone who has NetExpress
could do the same exercise with Robert's original code which I did in
Fujitsu (wrap it as a COM object) so we can compare the results? (Rene,
Jimmy...anyone?)). (I'd offer to place the resulting object on the web sever
for download, but we'd hit problems with licensing MF runtime...and I'm not
sure if it can be deployed without Application Server...) Maybe you can
confirm whether they have a COM Base class that can be used to build COM
objects, Jimmy?

So now we have Business Logic objects and Data Access objects, but we need
to re-attach the Presentation layer and let this drive the application.
Fortunately, .NET serves us well for this, and it is relatively easy to
convert our old screens to windows forms (or ASP.NET web pages...).

When this process is complete, you have a fully tiered, Object Oriented
system that has leveraged much of your old code, the whole lot runs in a
modern environment and you can add new objects to it in ANY language you
like (including COBOL, should you want to...)

I reckon this is a good approach (and I documented it in the diagram on the
web site), but I'd be interested to hear alternatives, comments, or
suggestions.



I really want to tackle OO Factory and then basically I bugger off out of
here.


Your choice.

If you have given up programming I don't quite understand why you would want
to worry yourself about Factory Classes, but of course, it's entirely up to
you.

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


.

Quantcast