From Newsgroup: comp.lang.cobol

"opencobolide" is free open source software by Colin Duquesnoy. It is
written in Python for Linux/Unix, Mac OS, and Windows. The Windows
version includes a prebuilt GnuCOBOL compiler.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/4f38d4fc/

---begin quote---

New release of the "preferred" IDE: OCIDE 4.7.6 (including Arnold's
2.0rc2 MinGW BDB build on Windows)


Simon Sobisch - 9:00 AM 12/30/2016 (USA Central time)

Quoting Colin from https://github.com/OpenCobolIDE/OpenCobolIDE/releases/tag/4.7.6

New features:

add -W and -Wall compiler flags
add an help button next to the compiler flags settings, the help
shows a dialog with the output of cobc --help
add buttons to change order of copybooks and libraries in compiler settings
improved indentation in fixed mode (TAB/SHIFT+TAB)
add support for going to a section using F7
updated list of COBOL keywords for GnuCOBOL 2.x users
updated bundled GnuCOBOL version on windows: now at GnuCOBOL 2.0rc2 (build made by Arnold Trembley, can be downloaded here: http://www.arnoldtrembley.com/GnuCOBOL.htm)

Fixed bugs:

fix TypeError: start_process() got an unexpected keyword argument
'cwd' when running a module with cobcrun
fix OutputWindow backend cannot import pyqode (search not working
in output window)
fix occasional RuntimeError: wrapped C/C object of type
CobolCodeEdit has been deleted
fix MemoryError when reading log file
fix [Unhandled exception] UnicodeEncodeError when getting cursor
position in bytes
fix change to Encoding leads to empty editor window
fix Preferences->Run misses a label/link for "run in external terminal"
fix goto (F7) sometimes going to a wrong identifier

This is a very nice release - if you are of the IDE type: get it, If
not: have a look at it in any case :-)

---end quote---

http://opencobolide.readthedocs.io/en/latest/whats_new.html http://opencobolide.readthedocs.io/en/latest/download.html https://launchpad.net/cobcide/+download

https://launchpad.net/cobcide/4.0/4.7.6/+download/OpenCobolIDE-4.7.6_Setup.exe




--
http://www.arnoldtrembley.com/

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 31/12/2016 11:43 p.m., Arnold Trembley wrote:

"opencobolide" is free open source software by Colin Duquesnoy. It is written in Python for Linux/Unix, Mac OS, and Windows. The Windows
version includes a prebuilt GnuCOBOL compiler.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/4f38d4fc/

---begin quote---

New release of the "preferred" IDE: OCIDE 4.7.6 (including Arnold's
2.0rc2 MinGW BDB build on Windows)

Simon Sobisch - 9:00 AM 12/30/2016 (USA Central time)

Quoting Colin from https://github.com/OpenCobolIDE/OpenCobolIDE/releases/tag/4.7.6

New features:

add -W and -Wall compiler flags
add an help button next to the compiler flags settings, the help
shows a dialog with the output of cobc --help
add buttons to change order of copybooks and libraries in compiler settings
improved indentation in fixed mode (TAB/SHIFT+TAB)
add support for going to a section using F7
updated list of COBOL keywords for GnuCOBOL 2.x users
updated bundled GnuCOBOL version on windows: now at GnuCOBOL 2.0rc2 (build made by Arnold Trembley, can be downloaded here: http://www.arnoldtrembley.com/GnuCOBOL.htm)

Fixed bugs:

fix TypeError: start_process() got an unexpected keyword argument
'cwd' when running a module with cobcrun
fix OutputWindow backend cannot import pyqode (search not working in output window)
fix occasional RuntimeError: wrapped C/C object of type
CobolCodeEdit has been deleted
fix MemoryError when reading log file
fix [Unhandled exception] UnicodeEncodeError when getting cursor
position in bytes
fix change to Encoding leads to empty editor window
fix Preferences->Run misses a label/link for "run in external terminal"
fix goto (F7) sometimes going to a wrong identifier

This is a very nice release - if you are of the IDE type: get it, If
not: have a look at it in any case :-)

---end quote---

http://opencobolide.readthedocs.io/en/latest/whats_new.html http://opencobolide.readthedocs.io/en/latest/download.html https://launchpad.net/cobcide/+download

https://launchpad.net/cobcide/4.0/4.7.6/+download/OpenCobolIDE-4.7.6_Setup.exe

Good stuff, Arnold!

I would love to download and play with this but I really don't have time
at the moment. (It has gone onto a list of TODOs and I hope I can get
around to it sometime in the coming year.)

Having a simple download available makes it a lot more viable than
having to navigate the intricacies of building and running it
yourself... The majority of potential users for this will just want to
use it and not have to become environmental support people for it.

I also viewed your home page from the link provided and see we share
some interests... (guitar and ukulele :-))

Welcome to retirement!

I'm not allowed to retire gracefully as people keep giving me stuff to
do :-) There is something nice about being able to write code from your armchair and I have decided I will not take any more jobs that require
me to wear shoes...:-) There is a major new product release coming up
for PRIMA (PowerCOBOL to .Net Migration) and that'll keep me off the
streets for a while but once it is ticking over I plan to slow down a bit...

Had one of the best Xmases ever with a few friends, good food, good
booze, and sunshine... Didn't touch a computer for 2 days, despite some
stuff that was gnawing at me to solve... :-) I have decided to pace
myself in 2017 and not just work obsessively on every problem that comes along. I had a mentor once who told me: "Amateurs try to solve
everything on day one, burn themselves out and make mistakes;
professionals pace themselves and recognize the value of letting their subconscious work on something while they sleep."

I was never able to implement this very sound advice and it's now time I
did.

GnuCOBOL deserves support and I look forward to the day when it can
compete fully with the likes of Micro Focus and Fujitsu. For me, the
lack of Component Object Model (COM) support makes it a non-starter for
any kind of serious use but I hope that won't always be the case.

Best wishes with your GNUCOBOL endeavours,

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

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On Monday, 2 January 2017 12:03:07 UTC+10, pete dashwood wrote:

On 31/12/2016 11:43 p.m., Arnold Trembley wrote:

"opencobolide" is free open source software by Colin Duquesnoy. It is written in Python for Linux/Unix, Mac OS, and Windows. The Windows
version includes a prebuilt GnuCOBOL compiler.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/4f38d4fc/

---begin quote---

New release of the "preferred" IDE: OCIDE 4.7.6 (including Arnold's
2.0rc2 MinGW BDB build on Windows)

Simon Sobisch - 9:00 AM 12/30/2016 (USA Central time)

Quoting Colin from https://github.com/OpenCobolIDE/OpenCobolIDE/releases/tag/4.7.6

New features:

add -W and -Wall compiler flags
add an help button next to the compiler flags settings, the help
shows a dialog with the output of cobc --help
add buttons to change order of copybooks and libraries in compiler settings
improved indentation in fixed mode (TAB/SHIFT+TAB)
add support for going to a section using F7
updated list of COBOL keywords for GnuCOBOL 2.x users
updated bundled GnuCOBOL version on windows: now at GnuCOBOL 2.0rc2 (build made by Arnold Trembley, can be downloaded here: http://www.arnoldtrembley.com/GnuCOBOL.htm)

Fixed bugs:

fix TypeError: start_process() got an unexpected keyword argument
'cwd' when running a module with cobcrun
fix OutputWindow backend cannot import pyqode (search not working in output window)
fix occasional RuntimeError: wrapped C/C object of type
CobolCodeEdit has been deleted
fix MemoryError when reading log file
fix [Unhandled exception] UnicodeEncodeError when getting cursor position in bytes
fix change to Encoding leads to empty editor window
fix Preferences->Run misses a label/link for "run in external terminal"
fix goto (F7) sometimes going to a wrong identifier

This is a very nice release - if you are of the IDE type: get it, If
not: have a look at it in any case :-)

---end quote---

http://opencobolide.readthedocs.io/en/latest/whats_new.html http://opencobolide.readthedocs.io/en/latest/download.html https://launchpad.net/cobcide/+download

https://launchpad.net/cobcide/4.0/4.7.6/+download/OpenCobolIDE-4.7.6_Setup.exe

Good stuff, Arnold!

I would love to download and play with this but I really don't have time
at the moment. (It has gone onto a list of TODOs and I hope I can get
around to it sometime in the coming year.)

Having a simple download available makes it a lot more viable than
having to navigate the intricacies of building and running it
yourself... The majority of potential users for this will just want to
use it and not have to become environmental support people for it.

I also viewed your home page from the link provided and see we share
some interests... (guitar and ukulele :-))

Welcome to retirement!

I'm not allowed to retire gracefully as people keep giving me stuff to
do :-) There is something nice about being able to write code from your armchair and I have decided I will not take any more jobs that require
me to wear shoes...:-) There is a major new product release coming up
for PRIMA (PowerCOBOL to .Net Migration) and that'll keep me off the
streets for a while but once it is ticking over I plan to slow down a bit....

Had one of the best Xmases ever with a few friends, good food, good
booze, and sunshine... Didn't touch a computer for 2 days, despite some
stuff that was gnawing at me to solve... :-) I have decided to pace
myself in 2017 and not just work obsessively on every problem that comes along. I had a mentor once who told me: "Amateurs try to solve
everything on day one, burn themselves out and make mistakes;
professionals pace themselves and recognize the value of letting their subconscious work on something while they sleep."

I was never able to implement this very sound advice and it's now time I
did.

GnuCOBOL deserves support and I look forward to the day when it can
compete fully with the likes of Micro Focus and Fujitsu. For me, the
lack of Component Object Model (COM) support makes it a non-starter for
any kind of serious use but I hope that won't always be the case.

Best wishes with your GNUCOBOL endeavours,

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

Some interesting not really Cobol discussion going on here.
I am interested in diet - previous thread.
Cobol person retirement is of great interest.
Moving to retirement has entered my picture. So I currently have a Family Trust
and can distribute income to legally reduce tax. I have recurring income and say about 6 active clients of which 2-3 are requesting new modifications and support. I also have a self managed super fund.
There has been a natural evolution to retirement with 2 previous clients moving
to new software for complex reasons but both are running my software in read-only mode with an annual fee.
Both these clients have a high regard for my services and we remain on good terms Their move to new products results in higher on-going costs.
By cooperating with their move to new software I gained some extra income for producing CSV files.
I am talking Australia. Ones principle place of residence is not assessable for
assets or pension. I am expecting a change on this.
My software base could be assessed at over a million dollars but annual revenue
indicates $30,000 to $40,000. So what do I do going forward? One option is to sell the business for sub-prime value and another is to get two children (in their 30's) to become directors.
So my thinking is to cash-up on assets, move to a more expensive principal place of residence, divest of my company to children and start receiving a pension.
Any Comment?

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On Saturday, 31 December 2016 20:43:17 UTC+10, Arnold Trembley wrote:

"opencobolide" is free open source software by Colin Duquesnoy. It is written in Python for Linux/Unix, Mac OS, and Windows. The Windows
version includes a prebuilt GnuCOBOL compiler.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/4f38d4fc/

---begin quote---

New release of the "preferred" IDE: OCIDE 4.7.6 (including Arnold's
2.0rc2 MinGW BDB build on Windows)

Simon Sobisch - 9:00 AM 12/30/2016 (USA Central time)

Quoting Colin from https://github.com/OpenCobolIDE/OpenCobolIDE/releases/tag/4.7.6

New features:

add -W and -Wall compiler flags
add an help button next to the compiler flags settings, the help
shows a dialog with the output of cobc --help
add buttons to change order of copybooks and libraries in compiler settings
improved indentation in fixed mode (TAB/SHIFT+TAB)
add support for going to a section using F7
updated list of COBOL keywords for GnuCOBOL 2.x users
updated bundled GnuCOBOL version on windows: now at GnuCOBOL 2.0rc2 (build made by Arnold Trembley, can be downloaded here: http://www.arnoldtrembley.com/GnuCOBOL.htm)

Fixed bugs:

fix TypeError: start_process() got an unexpected keyword argument
'cwd' when running a module with cobcrun
fix OutputWindow backend cannot import pyqode (search not working
in output window)
fix occasional RuntimeError: wrapped C/C object of type
CobolCodeEdit has been deleted
fix MemoryError when reading log file
fix [Unhandled exception] UnicodeEncodeError when getting cursor position in bytes
fix change to Encoding leads to empty editor window
fix Preferences->Run misses a label/link for "run in external terminal"
fix goto (F7) sometimes going to a wrong identifier

This is a very nice release - if you are of the IDE type: get it, If
not: have a look at it in any case :-)

---end quote---

http://opencobolide.readthedocs.io/en/latest/whats_new.html http://opencobolide.readthedocs.io/en/latest/download.html https://launchpad.net/cobcide/+download

https://launchpad.net/cobcide/4.0/4.7.6/+download/OpenCobolIDE-4.7.6_Setup.exe

--
http://www.arnoldtrembley.com/

Here is another thought. I suspect this is controversial and may elicite comments.
Cobol native ISAM files are my preference for many reasons.
Consider this: If you obey some generic database and the client wants to move to a new software product then you may be omitting an income stream to assist the client to move to new software. It is a bit of a cheap shot but I tend to believe that discrete ISAM files provide a better solution and faster performance.
An assumption of mine is that one language and one data storage method is best.
So one can do Cobol as the main language and native ISAM files. Moving to web programs COBOL plus HTML5, CSS3 and Javascript can provide many base features.
One can even do another language.
Once a client gets into multi-languages and multi-database methods then their costs exponentially increase. This is extremely common such as much failure with the Australian Tax Office where their base is Cobol.
I persist that COBOL is a good single language for business processes and that discrete ISAM file are the best storage method. One reason is the idea of multi-client and multi-database. I investigated this and found that the simple Cobol ISAM method allows switching and one has to spend more money to get databases that allow this.
Object Oriented programming is just more gobbledegook. One can program Cobol with copy modules and black box design for background programs or sub-routines. I have proven that with COBOL one can have Front-end programs and Back-end programs. The back-end is an object that can be reused for either interactive web apps or installed desktop apps. The back-end is part of the notion of object oriented.
I have also proven that one can employ a report program that is two pass with user selected choices of selection and sort fields. This eliminates the need for a generic report program such as Crystal reports. I could say much more.
In other words, we can get object oriented design without object oriented programming.
Further, the idea of clients moving from COBOL and ISAM creates "grist for the mill" or a fresh income stream. Admittedly a cheap shot and the better is the best language and the best data storage method. After much research, I am still
not finding any agreement about the best language and best data storage method. Very tentatively posted.
Greg

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 1/1/2017 8:03 PM, pete dashwood wrote:

On 31/12/2016 11:43 p.m., Arnold Trembley wrote:

"opencobolide" is free open source software by Colin Duquesnoy. It is
written in Python for Linux/Unix, Mac OS, and Windows. The Windows
version includes a prebuilt GnuCOBOL compiler.
(snip)

Good stuff, Arnold!

I would love to download and play with this but I really don't have time
at the moment. (It has gone onto a list of TODOs and I hope I can get
around to it sometime in the coming year.)

Having a simple download available makes it a lot more viable than
having to navigate the intricacies of building and running it
yourself... The majority of potential users for this will just want to
use it and not have to become environmental support people for it.

I also viewed your home page from the link provided and see we share
some interests... (guitar and ukulele :-))

Welcome to retirement!

I'm not allowed to retire gracefully as people keep giving me stuff to
do :-) There is something nice about being able to write code from your armchair and I have decided I will not take any more jobs that require
me to wear shoes...:-) There is a major new product release coming up
for PRIMA (PowerCOBOL to .Net Migration) and that'll keep me off the
streets for a while but once it is ticking over I plan to slow down a
bit...

Had one of the best Xmases ever with a few friends, good food, good
booze, and sunshine... Didn't touch a computer for 2 days, despite some
stuff that was gnawing at me to solve... :-) I have decided to pace
myself in 2017 and not just work obsessively on every problem that comes along. I had a mentor once who told me: "Amateurs try to solve
everything on day one, burn themselves out and make mistakes;
professionals pace themselves and recognize the value of letting their subconscious work on something while they sleep."

I was never able to implement this very sound advice and it's now time I
did.

GnuCOBOL deserves support and I look forward to the day when it can
compete fully with the likes of Micro Focus and Fujitsu. For me, the
lack of Component Object Model (COM) support makes it a non-starter for
any kind of serious use but I hope that won't always be the case.

Best wishes with your GNUCOBOL endeavours,

Pete.

Pete,

Thanks very much for the kind words. I've only been retired about four
months now, and besides building GnuCOBOL for Windows I've been taking a
lot of Adult Continuing Education classes at the local Community College district, playing guitar & Ukulele a little more often with my friends,
and I'm planning on playing Duplicate Bridge again.

There's also a free online course on Python from my local public library system that looks interesting.

While I enjoyed coding in COBOL, I don't miss being on call 24x7 at all!

Best wishes to you, too!

--
http://www.arnoldtrembley.com/

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 3/01/2017 3:33 p.m., Greg Wallace wrote:
<snipped>

A brave post, Greg.

As such, it deserves a reply... :-)

Here is another thought. I suspect this is controversial and may elicite

comments.

Cobol native ISAM files are my preference for many reasons.

"many reasons"...?

Consider this: If you obey some generic database and the client wants to move

to a new software product then you may be omitting an income stream to assist the client to move to new software. It is a bit of a cheap shot but I tend to believe that discrete ISAM files provide a better solution and faster performance.

Need to be sure I understand you here...

Client wants to move to a new software product.

If his current product is RDBMS based, and the new one is too, it's a no-brainer. But if his current product is ISAM based, you have the
chance at a revenue stream in converting his data for him?

I don't actually see our clients as "victims", rather as "partners" we
work with, to get them better options.

While I appreciate that they pay us money, that is far from the main
criterion in how I view them.

I would do a data conversion for free if the end result was better for
them, meant they had more options in choosing packages and programs, and
they retained us for consultancy and support.

When the new PowerCOBOL Migration package is released I am already
looking at how we could do a database conversion using our existing
tools, on the new COBOL code-behinds for the Windows Forms. Clients move
to .Net (are no longer dependent on PowerCOBOL for screen design and scriptlets) and also get an optimized database in 3rd Normal form which replaces their legacy ISAM files, AND, they can keep COBOL or mix it
with other languages.

Some of the elements of that mix may well be provided free or very
cheaply to encourage them to move.

OK. Different folks have different views.

An assumption of mine is that one language and one data storage method is

best. So one can do Cobol as the main language and native ISAM files. Moving to
web programs COBOL plus HTML5, CSS3 and Javascript can provide many base features. One can even do another language.

When you "assume" you make an "ass" of "u" and "me"...

Your assumption has no basis in fact. What do you mean by "best"? There
are advantages and disadvantages in using a single language (data
storage methodology) and in using different languages for separate parts
of the development.

I had a request for a new component the other day from a client who is
totally (Power) COBOL based. What it needed to do was completely
unsuitable for COBOL (I can't give details, but it involved control and command of electronic systems), although I probably COULD have forced
COBOL to do it. Why force it? I wrote it in C# and implemented a COM
interface so it could talk easily to COBOL. The source code is a
fraction of what it would have taken to do in COBOL and it can use
libraries and facilities that are just not available to COBOL out-of
the-box. It gets invoked from COBOL with no problem at all and no-one
cares what language it is written in. It does what it does. That's the
whole point of component based design.

While I respect your right to your opinion, you must respect mine to
disagree.

Once a client gets into multi-languages and multi-database methods then their

costs exponentially increase. This is extremely common such as much failure with the Australian Tax Office where their base is Cobol.

I agree it is a very common story when proper training is not undertaken
and the COBOL guys are just expected to know and understand a completely different paradigm. The fault is not with languages or storage
mechanisms; it is with poor management and under-investment.

You might as well blame someone who has spent a lifetime making dugout
canoes with an adze, because their chain saw doesn't work so well when
they use it like an adze.

I persist that COBOL is a good single language for business processes and

that discrete ISAM file are the best storage method.

And I insist that you must define "best" before that statement has real meaning.

One reason is the idea of multi-client and multi-database. I
investigated this and found that the simple Cobol ISAM method allows
switching and one has to spend more money to get databases that allow this.

Having worked with all of the major RDBMS over the last 30 years I can
tell you I have NEVER paid anything for a RDBMS. So how do you arrive at "spend more money"?

My favoured RDBMS currently is SQL Server (although ALL of them are
pretty good...) and it handles multiple clients and multiple databases simultaneously with no problem. It is also FREE... (unless you want to
use it to run a commercial server farm or enterprise of similar nature.)

Object Oriented programming is just more gobbledegook.

Yes, so is Swahili, to someone who doesn't speak it.

Yet to somewhere around 80 million people in South East Africa who use
it as a lingua franca, it is an open book.

The world has voted with its feet on OO programming and design; there
are very sound reasons why it is so popular.

OO COBOL was added to the language in one of the most amazing feats of software engineering I have ever seen, but it was largely wasted because
few people realized what they could do with it. (the "adze mentality"
noted above.)


One can program Cobol with copy modules and black box design for
background programs or sub-routines.

Sure. But you can't dynamically instance multiple copies of those
modules, or use them as dynamically instanced load-levellers across a
network.

I have proven that with COBOL one can have Front-end programs and Back-end

programs.

We were doing that in 1970 with Foreground 1 and 2 running on IBM
mainframes. But the WAY we did it then and the WAY we would do it now,
are completely different. Computer science has evolved, OSes and
computer hardware have evolved, field experience has been gained, and
the practitioners of today are better informed than we were in the
1960s... The procedural paradigm of a central processor controlling
everything has been joined by other paradigms, more suited to networking
and the processing of events as and when they happen...

You CAN still have Front-end and Back-end programs as you say. The
question is: "Does that model suit the increasingly diverse ways that
people want to do business, given that it is no longer the ONLY option available for multi-processing?"

The back-end is an object that can be reused for either interactive web
apps or installed desktop apps. The back-end is part of the notion of
object oriented.

If you choose it to be. (And without being pedantic about precise
technical definitions...)

I have also proven that one can employ a report program that is two pass with

user selected choices of selection and sort fields. This eliminates the need for a generic report program such as Crystal reports. I could say much more.

In other words, we can get object oriented design without object oriented

programming.

I don't think so, but I agree it may be arguable.

Further, the idea of clients moving from COBOL and ISAM creates "grist for

the mill" or a fresh income stream.

Well, it certainly does as far as my business is concerned. The whole
idea is to get people moved on to a place where they are able to open
their data repositories to standard software and not have to write a
COBOL program every time somebody wants to know something.

I don't really mind what language(s) they want to use and if they choose
to stay with COBOL that is their decision. We give them options.

We keep our prices reasonable and fair and provide tools that save man
years of work. If you have ever had to do a few data migrations manually
you would know that it is a considerable cost and it is tedious and
error prone. Automating it means it can be done quickly and accurately
and for a fraction of what it would cost to do manually.

Admittedly a cheap shot and the better is the best language and the best
data storage method. After much research, I am still not finding any
agreement about the best language and best data storage method.

Have you thought about why that is so?

The fact is that different tasks and projects may require different
tools. Why would you close your options down to saying:"There is only
one and it is the best"?

Business is NOT about what software development language(s) you use.
There are many more pertinent factors than just that one.

Very tentatively posted.

Don't be afraid... this is a friendly place :-) But, as Doc Dwarf once observed, if you only want agreement, perhaps the debate should be with
a mirror... :-)

Pete.

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

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

In article <0e0b0ed0-ceec-4124-9e0b-8318bc0f56bf@googlegroups.com>,
Greg Wallace <gregwebace@gmail.com> wrote:

[snip]

Cobol person retirement is of great interest.

Moving to retirement has entered my picture.

Tread with care, Mr Wallace... I believe Mr Gunshannon took steps in a direction he called 'retirement' recently and is now looking for more entertaining engagements.

A more informing way to phrase this change of existence (existential
crisis) is 'what would I like to see myself doing differently?'

DD

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

<snipped>

I am interested in diet - previous thread.

Cobol person retirement is of great interest.

And a full discussion of it is really off-topic in this particular thread.

So, I have started a new (OT) thread and responded to your post.

Pete.

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

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On Tuesday, 3 January 2017 18:09:00 UTC+10, pete dashwood wrote:

On 3/01/2017 3:33 p.m., Greg Wallace wrote:
<snipped>

A brave post, Greg.

As such, it deserves a reply... :-)

Here is another thought. I suspect this is controversial and may elicite

comments.

Cobol native ISAM files are my preference for many reasons.

"many reasons"...?

Consider this: If you obey some generic database and the client wants to

move to a new software product then you may be omitting an income stream to assist the client to move to new software. It is a bit of a cheap shot but I tend to believe that discrete ISAM files provide a better solution and faster performance.

Need to be sure I understand you here...

Client wants to move to a new software product.

If his current product is RDBMS based, and the new one is too, it's a no-brainer. But if his current product is ISAM based, you have the
chance at a revenue stream in converting his data for him?

I don't actually see our clients as "victims", rather as "partners" we
work with, to get them better options.

While I appreciate that they pay us money, that is far from the main criterion in how I view them.

I would do a data conversion for free if the end result was better for
them, meant they had more options in choosing packages and programs, and
they retained us for consultancy and support.

When the new PowerCOBOL Migration package is released I am already
looking at how we could do a database conversion using our existing
tools, on the new COBOL code-behinds for the Windows Forms. Clients move
to .Net (are no longer dependent on PowerCOBOL for screen design and scriptlets) and also get an optimized database in 3rd Normal form which replaces their legacy ISAM files, AND, they can keep COBOL or mix it
with other languages.

Some of the elements of that mix may well be provided free or very
cheaply to encourage them to move.

OK. Different folks have different views.

An assumption of mine is that one language and one data storage method is

best. So one can do Cobol as the main language and native ISAM files. Moving to
web programs COBOL plus HTML5, CSS3 and Javascript can provide many base features. One can even do another language.

When you "assume" you make an "ass" of "u" and "me"...

Your assumption has no basis in fact. What do you mean by "best"? There
are advantages and disadvantages in using a single language (data
storage methodology) and in using different languages for separate parts
of the development.

I had a request for a new component the other day from a client who is totally (Power) COBOL based. What it needed to do was completely
unsuitable for COBOL (I can't give details, but it involved control and command of electronic systems), although I probably COULD have forced
COBOL to do it. Why force it? I wrote it in C# and implemented a COM interface so it could talk easily to COBOL. The source code is a
fraction of what it would have taken to do in COBOL and it can use
libraries and facilities that are just not available to COBOL out-of
the-box. It gets invoked from COBOL with no problem at all and no-one
cares what language it is written in. It does what it does. That's the
whole point of component based design.

While I respect your right to your opinion, you must respect mine to disagree.

Once a client gets into multi-languages and multi-database methods then

their costs exponentially increase. This is extremely common such as much failure with the Australian Tax Office where their base is Cobol.

I agree it is a very common story when proper training is not undertaken
and the COBOL guys are just expected to know and understand a completely different paradigm. The fault is not with languages or storage
mechanisms; it is with poor management and under-investment.

You might as well blame someone who has spent a lifetime making dugout
canoes with an adze, because their chain saw doesn't work so well when
they use it like an adze.

I persist that COBOL is a good single language for business processes and

that discrete ISAM file are the best storage method.

And I insist that you must define "best" before that statement has real meaning.

One reason is the idea of multi-client and multi-database. I
investigated this and found that the simple Cobol ISAM method allows switching and one has to spend more money to get databases that allow this.

Having worked with all of the major RDBMS over the last 30 years I can
tell you I have NEVER paid anything for a RDBMS. So how do you arrive at "spend more money"?

My favoured RDBMS currently is SQL Server (although ALL of them are
pretty good...) and it handles multiple clients and multiple databases simultaneously with no problem. It is also FREE... (unless you want to
use it to run a commercial server farm or enterprise of similar nature.)

Object Oriented programming is just more gobbledegook.

Yes, so is Swahili, to someone who doesn't speak it.

Yet to somewhere around 80 million people in South East Africa who use
it as a lingua franca, it is an open book.

The world has voted with its feet on OO programming and design; there
are very sound reasons why it is so popular.

OO COBOL was added to the language in one of the most amazing feats of software engineering I have ever seen, but it was largely wasted because
few people realized what they could do with it. (the "adze mentality"
noted above.)

One can program Cobol with copy modules and black box design for
background programs or sub-routines.

Sure. But you can't dynamically instance multiple copies of those
modules, or use them as dynamically instanced load-levellers across a network.

I have proven that with COBOL one can have Front-end programs and Back-end

programs.

We were doing that in 1970 with Foreground 1 and 2 running on IBM
mainframes. But the WAY we did it then and the WAY we would do it now,
are completely different. Computer science has evolved, OSes and
computer hardware have evolved, field experience has been gained, and
the practitioners of today are better informed than we were in the
1960s... The procedural paradigm of a central processor controlling everything has been joined by other paradigms, more suited to networking
and the processing of events as and when they happen...

You CAN still have Front-end and Back-end programs as you say. The
question is: "Does that model suit the increasingly diverse ways that
people want to do business, given that it is no longer the ONLY option available for multi-processing?"

The back-end is an object that can be reused for either interactive web
apps or installed desktop apps. The back-end is part of the notion of
object oriented.

If you choose it to be. (And without being pedantic about precise
technical definitions...)

I have also proven that one can employ a report program that is two pass

with user selected choices of selection and sort fields. This eliminates the need for a generic report program such as Crystal reports. I could say much more.

In other words, we can get object oriented design without object oriented

programming.

I don't think so, but I agree it may be arguable.

Further, the idea of clients moving from COBOL and ISAM creates "grist for

the mill" or a fresh income stream.

Well, it certainly does as far as my business is concerned. The whole
idea is to get people moved on to a place where they are able to open
their data repositories to standard software and not have to write a
COBOL program every time somebody wants to know something.

I don't really mind what language(s) they want to use and if they choose
to stay with COBOL that is their decision. We give them options.

We keep our prices reasonable and fair and provide tools that save man
years of work. If you have ever had to do a few data migrations manually
you would know that it is a considerable cost and it is tedious and
error prone. Automating it means it can be done quickly and accurately
and for a fraction of what it would cost to do manually.

Admittedly a cheap shot and the better is the best language and the best
data storage method. After much research, I am still not finding any agreement about the best language and best data storage method.

Have you thought about why that is so?

The fact is that different tasks and projects may require different
tools. Why would you close your options down to saying:"There is only
one and it is the best"?

Business is NOT about what software development language(s) you use.
There are many more pertinent factors than just that one.

Very tentatively posted.

Don't be afraid... this is a friendly place :-) But, as Doc Dwarf once observed, if you only want agreement, perhaps the debate should be with
a mirror... :-)

Pete.

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

I have to admit that I have trouble posting a simple reply to a post but here goes.
Hi Pete
So complex over so many opinions. In short, I say Object Oriented Programming (OOP) is obscure.
"While I respect your right to your opinion, you must respect mine to disagree."
I totally agree.
"In other words, we can get object oriented design without object oriented programming."
Pete: I don't think so, but I agree it may be arguable.
So I am in arguable.
I am currently in negotiations for a move to a new accounting system. I try to assist and export Tab Delimited data files. These can be opened in a spreadsheet. They are self defining if they are third form normalized and have column headings that explain the field. The new system can migrate data. I am trying to supply the best possible format and TAB delimited seems better than CSV or XML.
If you have a clever RDMS data base and the new client has a different one, I suspect that the best possible intermediate format is Tab Delimited text files. So take a scenario, the new system is on a different computer system. So connection is not possible. One can send TAB delimited text files by email attachment.
The remote programmer working with a different language can import these files to his chosen data base.
So you get a scenario where two systems are not connected. The Language at both
ends is different. The Database at both ends is different. The best migration of data seems to be convert to a best text format.
Finally, this is language independent. It does not matter which system is Cobol.
If understand your thrust, it is about supplying a database method that does not need third party custom programming. Have you considered that losing a customer moving to a new system may provide more "grist for the mill" if you don't have such a clever database solution?
That is a side-track because I still believe COBOL discrete ISAM files are the best for a customer. If they want to move on then it is "grist for the mill". with reservations
Regards
Greg

SEEN-BY: 154/30 2320/100 0 1 227/0

From Newsgroup: comp.lang.cobol

On 10/01/2017 6:18 p.m., Greg Wallace wrote:

On Tuesday, 3 January 2017 18:09:00 UTC+10, pete dashwood wrote:

On 3/01/2017 3:33 p.m., Greg Wallace wrote:
<snipped>

I have to admit that I have trouble posting a simple reply to a post but here

goes.

Hi Pete

So complex over so many opinions. In short, I say Object Oriented Programming

(OOP) is obscure.

And I respond that it isn't, once you take a little time to understand
it. (I used the Swahili analogy... everything is a mystery if you can't
read and write...) I have been wanting for a very long time now to run a straightforward tutorial on it and cut through the jargon but I simply
haven't had the time. It will go onto the new whiz-bang refurbished
PRIMA 21 web site as soon as I get a chance to write it.

"While I respect your right to your opinion, you must respect mine to disagree."

I totally agree.

"In other words, we can get object oriented design without object oriented

programming."

Pete: I don't think so, but I agree it may be arguable.

So I am in arguable.

Obviously, results are what matter. It is stupid to have a "religious
war" over a particular programming language or paradigm, as long as you
get the results you need with whatever you use. The only danger here is
that your vision becomes limited by "what you know" and there is no
pushing of the envelope or personal growth expansion. ("Everything I
want to do, I can do in COBOL." is a perfectly valid statement but it
betrays an extreme lack of vision or desire to explore, and it means
your applications will be limited to what you are comfortable with...)

I am currently in negotiations for a move to a new accounting system. I try

to assist and export Tab Delimited data files. These can be opened in a spreadsheet. They are self defining if they are third form normalized and have column headings that explain the field. The new system can migrate data. I am trying to supply the best possible format and TAB delimited seems better than CSV or XML.

Again, you don't define "better" so I suspect it means "what I have
spent most time learning". I would strongly disagree but my approach, background, and tools are different from yours.

I figured out about 7 years ago when faced with using networks that
included mainframes, PCs and Macs, that XML (and, more recently, XAML, although XAML Is more specialized...) is simply ideal as a lingua franca
for computers. It has the advantages of being readable by Humans and
readable by any system that can utilize text, it has had a couple of
decades to iron out the bugs and is stable, but, best of all, I can
create and access it with LINQ. It is REALLY very simple to create a transportable, computer sensible, document and the added bonus of being
able to interrogate it just like a database at the "other end" puts the
little tin hat on it, for me.

A typical case in point, the current effort at PRIMA for PowerCOBOL
migration requires PowerCOBOL screens to be analyzed and dissected at
run time, so that the controls and properties they contain can be
reproduced in a different environment. Investigating, designing and
finally understanding how to do this took a large amount of time and
effort, but that's just the beginning. Once we have this information, we
need to generate Designer code from it so that the old PowerCOBOL sheet
can be replicated in a completely different environment. It was very
tempting when I first achieved this, to pass the data about the screen,
in memory, to the Windows Designer so it could generate a Windows Form
from it. But what if the "target" environment ISN'T Windows Forms? I
needed some kind of "description" of the PowerCOBOL Sheet in a language
that was understandable by a Human but readable by a system, so it could
be used to generate a new screen in any number of environments. XML,
driven by LINQ is perfect for this.

Here's a cut-down sample for an, admittedly, pretty basic Form (This was generated by the new tool in milliseconds, using LINQ):

<?xml version="1.0" standalone="yes"?>
<!--PowerCOBOL Form description generated by PRIMA Tool XPCForm.-->
<Project ProjName="MaestroNet" ModuleName="AUC170">
<Form FormName="AUC170A">
<Text>Maestro c||digos postales</Text>
<Dimensions>
<TopY>00277</TopY>
<TopX>00618</TopX>
<Height>00152</Height>
<Width>00358</Width>
</Dimensions>
<Colors>
<Forecolor>DEFLT</Forecolor>
<Backcolor>ECE9D9</Backcolor>
</Colors>
<Controls>
<Control CtlName="CmFrame1">
<CtlOrgName>CmFrame1</CtlOrgName>
<Type>Frame</Type>
<Text>Datos</Text>
<Parent>AUC170A</Parent>
<Dimensions>
<TopY>00040</TopY>
<TopX>00008</TopX>
<Height>00072</Height>
<Width>00344</Width>
</Dimensions>
<Colors>
<Forecolor>800080</Forecolor>
<Backcolor>ECE9D9</Backcolor>
</Colors>
<TabNDX>008</TabNDX>
</Control>
<Control CtlName="CmStatic2">
<CtlOrgName>CmStatic2</CtlOrgName>
<Type>Static Text</Type>
<Text>Poblaci||n</Text>
<Parent>CmFrame1</Parent>
<Dimensions>
<TopY>00020</TopY>
<TopX>00036</TopX>
<Height>00018</Height>
<Width>00060</Width>
</Dimensions>
<Colors>
<Forecolor></Forecolor>
<Backcolor></Backcolor>
</Colors>
<TabNDX>010</TabNDX>
</Control>
<Control CtlName="CmStatic3">
<CtlOrgName>CmStatic3</CtlOrgName>
<Type>Static Text</Type>
<Text>Provincia</Text>
<Parent>CmFrame1</Parent>
<Dimensions>
<TopY>00044</TopY>
<TopX>00036</TopX>
<Height>00018</Height>
<Width>00060</Width>
</Dimensions>
<Colors>
<Forecolor></Forecolor>
<Backcolor></Backcolor>
</Colors>
<TabNDX>011</TabNDX>
</Control>
<Control CtlName="PAUC142">
<CtlOrgName>PAUC142</CtlOrgName>
<Type>Text Box</Type>
<Text></Text>
<Parent>CmFrame1</Parent>
<Dimensions>
<TopY>00020</TopY>
<TopX>00104</TopX>
<Height>00018</Height>
<Width>00204</Width>
</Dimensions>
<Colors>
<Forecolor>000000</Forecolor>
<Backcolor>FFFFFF</Backcolor>
</Colors>
<TabNDX>003</TabNDX>
</Control>
...
etc.

This is a Spanish application for dealing with postal addresses. The
important thing here is that I can access this file (XML Document) as if
it were a database, using LINQ to XML:

1. List the children of a given control...

var kiddies = from x in XML.Descendants
where x.Element("Parent") == "CmFrame1"
select x.Attribute("CtlName");
foreach(string child in kiddies)
{
...process each name in the list of control names returned...
(All the controls placed on the Frame called CmFrame1...)
}

I was going to do some more examples, but I think you can see for
yourself that everything in the XML data stream is accessible, in any
way you want to access it.

If you have a clever RDMS data base and the new client has a different one, I

suspect that the best possible intermediate format is Tab Delimited text files.

Not for my money... using ORM (Object Relational Mapping) with LINQ you
could directly transfer data from the source DB to the remote Target
one; no "intermediate format" is required. The different structures are
mapped by an Object Mapping generated by a standard tool in Visual
Studio; you don't even have to write the code for that.

So take a scenario, the new system is on a different computer system. So

connection is not possible.

I really love it when IT guys say "not possible"... :-)

What it translates into is: "I don't know how to do that..."

During my career I was called on several times by various companies in
various countries to confirm whether it was actually "not possible" to
do something (after their tech people said it wasn't possible, but they
REALLY wanted to do it... :-)) In one case it was IBM who said it was "impossible" on their 370 mainframe. 3 weeks later I demoed the system
running what they said was impossible and they threw up their hands in
horror and said: "We won't support that; you must have bent our standard software." (I hadn't...) After all was explained, (and they got a little lecture in "lateral thinking") they didn't even have the grace to
apologise and just said: "Well, of course it is possible if you do it
like THAT..." I'm smiling now just thinking about it... :-)

Back to case-in-point...


You'd use ODBC for the physical link (I have yet to meet a RDBMS
(commercial or Open Source) that has NO ODBC driver) and, if both
platforms support LINQ (and more and more are every year) you'd use the
ORM mentioned earlier.

If it REALLY wasn't possible then you'd code a few lines of LINQ to
export the DB on the source machine as XML, and import it directly at
the target. In the unlikely event that the RDBMS won't import XML, you
could read it as bare XML or use LINQ to import it if LINQ was available.

One can send TAB delimited text files by email attachment.

As you can XML, but you'd probably FTP the XML...

The remote programmer working with a different language can import these

files to his chosen data base.

Careful... not EVERY database supports Tab delimited or CSV direct
import. I don't know ANY that won't import XML directly.

So you get a scenario where two systems are not connected. The Language at

both ends is different. The Database at both ends is different. The best migration of data seems to be convert to a best text format.

There certainly has to be a common text based language. I'd use XML.

Finally, this is language independent. It does not matter which system is

Cobol.

If understand your thrust, it is about supplying a database method that does

not need third party custom programming. Have you considered that losing a customer moving to a new system may provide more "grist for the mill" if you don't have such a clever database solution?

That is a side-track because I still believe COBOL discrete ISAM files are

the best for a customer. If they want to move on then it is "grist for the mill".

Fair enough... :-)

Pete.

(Disclaimer: I wrote this during a break. I haven't tested the code
samples, so consider them as examples that are "something like" what
would be required.)

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

SEEN-BY: 154/30 2320/100 0 1 227/0