× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 21 December 2013 03:47, CRPence wrote:

matches some ideology. And unlike what I seem to infer from what the
opposite camps are alluding... Adding CmtCtl is not nearly impossible,
nor is adding CmtCtl always as simple as merely adding COMMIT(*the_lvl)
or the COMIT kwd to the file(s) in a RPG program.

I myself think the 'camps' were simple misunderstandings. The 'CC is
hard' side meant only that adding CC to an existing, long in the tooth
application requires study. The 'CC is easy' side was referring to
the specific case of the OP where CC is the compiler default, and the
workaround (exec sql set option commit *none) is about as much work as
implementing CC. Once I understood the context for Dieter's remarks,
his position seemed less dogmatic. But that could be me. I agree
with him that CC is underutilised in the midrange space and like you,
I believe it has places where it can be applied to good effect. In my
opinion, it is easier to design that in from the start than to
retrofit. Additionally, retrofitting requires more care the older the
application is.

Like all programming,
what is done should be by-design and be what has been tested to be
functional in conjunction with the other features of the application...
and according to most management, also be in-budget.

'By-design' is the hard part when you begin employment with a company
in 2010 and the application base was laid down for the most part in
the 1980s and 1990s. The history of the midrange is perverse when it
comes to 'by-design' as it was originally targetted not toward CompSci
graduates, but to businesspeople who could write their own RPG
programs, 'administer' the system without a DBA, a security officer or
a system (OS) programmer.

Let's face it, applications written back then were for the most part
adequate, but informal might best be used to describe the design
process. And since then, both IBM and the programming community have
spent an inordinate number of hours ensuring backward compatibility -
the OS still to this day allows the 'load, sort, print' paradigm to
operate completely unchanged, right down to the I specs that describe
the columns the RPG programs use to read and the O specs the RPG
programs use to write. The programming community doesn't want to
re-do all of the work done back then when adding something new (like
changing from time clocks to card swipes) and so the 'database' that
was designed by accident continues to be used in 2013.

The upshot of this history is made plain when we look at the
experience of the programming community. How many of us are still
self-taught? How many have 'learnt' by copying existing code,
existing DDS? When the code base has exactly zero examples of
commitment control, how many RPG programmers will immediately try to
implement CC in a project? Related in a way is the problem of adding
constraints. I can do an ADDPFCST easily enough, but every single one
of the existing RPG programs will throw an I/O error if a constraint
gets violated. Why? Because no one ever puts the 'error' indicator
on an I/O operation. Of course, existing code reads a detail record,
adds a total, writes a detail record and at L1 time writes the header.
That's not going to work very well if I add RI to the tables.

Back to your point, 'by-design' is the key phrase. If we had more
applications that were intentionally designed, we'd be able to adapt
more readily to ever more modern techniques. But we don't for the
most part have that luxury. We have collections of files we call a
database, but they weren't intentionally designed that way - they grew
organically, haphazardly, accidentally - and more often than not, they
DIDN'T grow specifically in the name of backward compatibility. Now,
many (most?) of us aer in the precarious position where modernising
isn't as simple as refactoring as we go; it's going to be a long
complicated process involving intentional design - design which takes
time. And that time is what makes 'in-budget' potentially problematic
as we try to sell a modern database with ephemeral benefits to
management who see us and our time as an expense to be reduced,
minimised rather than given free reign.
--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.