In article <i0bugaFgk2rU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 13/10/2020 01:52, g??rard Calliet wrote:

Hello,

A general issue modernizing cobol environments is to tranform the set of
indexed files of the application into a relational database.

It is not a trivial issue. There are a lot of proprietary solutions for
that.

Do you know projects or people that worked on this problem in an Open
Source philosophy?

[snip]

The PRIMA solution (MigTSet) analyzes the COPY Books which define the
indexed files, and optimizes them to account for REDEFINES, handles
Group fields, and breaks out OCCURS into repeating group tables, to
produce an optimized Database in 3NF.

But... it Costs Money! In this Brave, New World everything is for free so
I can put it together in a way to *Make* Money!

[snip]

As far as I know, our solution is the ONLY one that actually refactors
the existing access code in your applications into a Data Access Layer
(DAL), fully automatically.

You can have the DAL generated in ESQL or in LINQ. Either way, it is >optimized and transparent.

Likewise, in this Brave, New World is there a need for teaching 'Thou
Shalt Not Compile to The Source Pack' or 'Indices and Data Must Live in Different Houses'?

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <i0hb6tFkr8vU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 3/11/2020 16:58, docdwarf@panix.com wrote:

[snip]

Likewise, in this Brave, New World is there a need for teaching 'Thou
Shalt Not Compile to The Source Pack' or 'Indices and Data Must Live in
Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the philosophy
of separating Data Access from Business Logic has been in force at PRIMA >since the last century and I expounded what I think about this on the
COBOL 21 pages of our web site.

That's exactly my drift, Mr Dashwood, and the reason that nobody spends
time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/11/2020 16:58, docdwarf@panix.com wrote:

In article <i0bugaFgk2rU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 13/10/2020 01:52, g??rard Calliet wrote:

Hello,

A general issue modernizing cobol environments is to tranform the set of >>> indexed files of the application into a relational database.

It is not a trivial issue. There are a lot of proprietary solutions for
that.

Do you know projects or people that worked on this problem in an Open
Source philosophy?

[snip]

The PRIMA solution (MigTSet) analyzes the COPY Books which define the
indexed files, and optimizes them to account for REDEFINES, handles
Group fields, and breaks out OCCURS into repeating group tables, to
produce an optimized Database in 3NF.

But... it Costs Money! In this Brave, New World everything is for free so
I can put it together in a way to *Make* Money!

Not EVERYTHING has a cost... :-)

PRIMA gives away (and has given away) considerable amounts of value in
both information and actual software. If somebody decided to do an Open
Source version of what has taken me personally almost 20 years of design
and programming, I would be happy to talk to them and help where I could.

The way I look at it, we have at least a 15 year head start...:-)

Given that business at the moment is very slow, we might as well be Open
Source anyway... :-)

I am all in favour of Open Source and would gladly be using GnuCOBOL
with our products and tools, if it supported the things we need: OO
COBOL and support for the Component Object Model. (The fact that it
doesn't, is no reflection on Brian and the team that developed it; it is
an excellent implementation of COBOL.)

[snip]

As far as I know, our solution is the ONLY one that actually refactors
the existing access code in your applications into a Data Access Layer
(DAL), fully automatically.

You can have the DAL generated in ESQL or in LINQ. Either way, it is
optimized and transparent.

Likewise, in this Brave, New World is there a need for teaching 'Thou
Shalt Not Compile to The Source Pack' or 'Indices and Data Must Live in Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the philosophy
of separating Data Access from Business Logic has been in force at PRIMA
since the last century and I expounded what I think about this on the
COBOL 21 pages of our web site.

It has always been my personal philosophy and the corporate "culture" of
my Company to help people where we can (first) and to consider paying
the rent after that. I'm very proud that we have never had a
dissatisfied customer, and we have never ripped anybody off. It works,
because we have never had anybody delay payment or dispute it, and most
of our invoices are paid by satisfied clients within a few days of being issued.

see: https://primacomputing.co.nz/primametro/Testimonials.aspx

Pete.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, November 5, 2020 at 4:59:14 PM UTC+13, docd...@panix.com wrote:

In article <i0hb6t...@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:

On 3/11/2020 16:58, docd...@panix.com wrote:

[snip]

Likewise, in this Brave, New World is there a need for teaching 'Thou
Shalt Not Compile to The Source Pack' or 'Indices and Data Must Live in
Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the philosophy
of separating Data Access from Business Logic has been in force at PRIMA >since the last century and I expounded what I think about this on the
COBOL 21 pages of our web site.

That's exactly my drift, Mr Dashwood, and the reason that nobody spends
time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

DD

This is too obtuse for me, I'm afraid.

I took a guess at what you had written and, rather than help me, you added more opacity.

I have no idea what your point is here (though I do understand the things you are talking about... :-)), sorry.

Furthermore, I can't see the posts in this thread in Thunderbird, apart from the original and my reply to it, so it looks like you're being too incoherent for Thunderbird, as well... :-)

I managed to get this posted by accessing the raw newsgroup through Google Groups.

Pete.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <0c5b90f4-41b2-4198-8878-7fa591f078f8n@googlegroups.com>,
aleck tricity <aleck.tricity@gmail.com> wrote:

On Thursday, November 5, 2020 at 4:59:14 PM UTC+13, docd...@panix.com wrote: >> In article <i0hb6t...@mid.individual.net>,

pete dashwood <dash...@enternet.co.nz> wrote:

On 3/11/2020 16:58, docd...@panix.com wrote:

[snip]

Likewise, in this Brave, New World is there a need for teaching 'Thou
Shalt Not Compile to The Source Pack' or 'Indices and Data Must Live in >> >> Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the philosophy
of separating Data Access from Business Logic has been in force at PRIMA
since the last century and I expounded what I think about this on the
COBOL 21 pages of our web site.

That's exactly my drift, Mr Dashwood, and the reason that nobody spends
time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

This is too obtuse for me, I'm afraid.

I took a guess at what you had written and, rather than help me, you
added more opacity.

I have no idea what your point is here (though I do understand the
things you are talking about... :-)), sorry.

I was making references to how hardware and code used to be intimately intertwined, down to buffering records for optimising access.

I get obtuse sometimes, yes.

Furthermore, I can't see the posts in this thread in Thunderbird, apart
from the original and my reply to it, so it looks like you're being too >incoherent for Thunderbird, as well... :-)

I get incoherent *and* Quite Mighty... best of luck, Mr Dashwood.

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello docdwarf!

Thursday November 05 2020 03:59, you wrote to All:

In article <i0hb6tFkr8vU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:

On 3/11/2020 16:58, docdwarf@panix.com wrote:

[snip]

Likewise, in this Brave, New World is there a need for teaching
'Thou Shalt Not Compile to The Source Pack' or 'Indices and Data
Must Live in Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the
philosophy of separating Data Access from Business Logic has been in
force at PRIMA since the last century and I expounded what I think
about this on the COBOL 21 pages of our web site.

That's exactly my drift, Mr Dashwood, and the reason that nobody
spends time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

Hmm, I have a few programs that are still in use that do use this option to help speed up processing - although not so sure how effective it is these
days.


Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 8, 2020 at 6:23:55 AM UTC+13, Vincent Coen wrote:

Hello docdwarf!
Thursday November 05 2020 03:59, you wrote to All:

In article <i0hb6t...@mid.individual.net>,
pete dashwood <dash...@enternet.co.nz> wrote:

On 3/11/2020 16:58, docd...@panix.com wrote:

[snip]

Likewise, in this Brave, New World is there a need for teaching
'Thou Shalt Not Compile to The Source Pack' or 'Indices and Data
Must Live in Different Houses'?

Not quite sure I catch your drift here, Doc. Certainly, the
philosophy of separating Data Access from Business Logic has been in
force at PRIMA since the last century and I expounded what I think
about this on the COBOL 21 pages of our web site.

That's exactly my drift, Mr Dashwood, and the reason that nobody
spends time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

Hmm, I have a few programs that are still in use that do use this option to help speed up processing - although not so sure how effective it is these days.

Vincent

Thanks for clarification and for Vince's comment.

I believe most of us did what we could, back in the Old Days, to make COBOL as efficient as possible, including the measures suggested.

In a time when the solution was an integrated, monolithic one, these measures were very important.

For Network processing (which really is a different paradigm see: https://primacomputing.co.nz/PRIMAMetro/ObjectsAndLayers.aspx)
...they are not so important because the functions they are supporting are separately managed and utilize things that are way more advanced than simple "double buffering". For example, LINQ access uses deferred writes and manages physical access using "
smart" algorithms that are beyond what a Human would code in a normal Procedural environment. (When we benchmarked and tested LINQ against SQL for the same tasks, LINQ was 5 times faster...) It was not achieved by "double buffering" alone, and some of
the result is arguable because the SQL solution (using Fujitsu COBOL for Windows) is required to use ODBC, while the LINQ access completely bypasses this.

I guess it is fair to say that solutions and software have evolved during the working lives of many of us, and things we considered critically important when we were bright-eyed young programmers, have been overtaken by events and "best practices" have
been superseded by even better practices.

I still get enjoyment from computer programming and intend to keep doing it as long as I can see and type, but I also recognize that the world continues to change and new solutions are evolving which will render much of what we did in the latter half of
the 20th century, obsolete and irrelevant.

Pete.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1604769672@f1.n250.z2.fidonet.ftn>,
Vincent Coen <VBCoen@gmail.com> wrote:

Hello docdwarf!

Thursday November 05 2020 03:59, you wrote to All:

[snip]

That's exactly my drift, Mr Dashwood, and the reason that nobody
spends time RESERVE(ing) nn ALTERNATE AREAS in File Descriptors.

Hmm, I have a few programs that are still in use that do use this option to >help speed up processing - although not so sure how effective it is these >days.

As long as the code hasn't been recompiled, Mr Coen, those alternate
buffer areas are still in the load module.

Where those datasets actually live, nowadays... who know? If the Gang in Accounting still signs off on the quarterlies then my part of that job is
long since done... I got paid, their check cleared the bank, the money got spent and turned into... whatever I bought... I wonder if the guy (back
in those days it was almost always a guy) who requisitioned the system got
the promotion he wanted, or what he deserved, or a mixture... and how
that worked out when the company was bought out... and the buying-out
company was later bought out, 18 months later...

... ou sont les neiges d'antan? Life is Good, Mr Coen, and It just keeps Getting Better.

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)