× 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.


  • Subject: RE: Externalize DB/IO (was What Counts as Technically Slick?)
  • From: jpcarr@xxxxxxxxxxxx
  • Date: Mon, 9 Apr 2001 21:42:23 -0400


>It can go to extremes. Once a colleague of mine had to write conversion
>programmers for a lot of DB-files to fill in a new added field. Because
our
>standard required to use external file servers, he wrote a conversion that
>reads sequentially the file, called the server (using an external DS),
>filled the added   field with the value supplied (with a parameter),
called
>the server again for update and read the next record. To do this
conversion
>he wrote an application that calls two programmes that opens the same file
>and that read the same record. I will spare you my comments on that, but
>those are obvious.
>Carel Teijgeler


Carel;
That's why  I quoted Einstein.   "Make things as simple as possible, but no
simpler"
Alot of "mechanical" programmers do not know when to stop.

I have been doing a session at COMMON for a few years entitled
"Externalized I/O using SQL".

>http://www.ignite400.org/news/news2001030901.htm
>Scott,
>That's a link to an article by IBM's Phil Coulthard.  It endorses the
>Model-View-Controller architecture that we're essentially talking about.
>Nathan M. Andelin

Both Phil and Jon Paris have seen my session and we have talked about the
technique numerous times.
In fact,  I read the quote from Phil out loud in New England User group
seminar last week to my attendee's before my session.(Phil was in the other
room doing his session at the time.)  I am a great believer in the
flexibility of it.

Now then,  Where to use encapsulation, and  how far to go?  Do we
"Smalltalk" our RPG programs(by having every line of code a function call)
?     What is the payback in each situation.

There is no "One size fits all shops"  answer.   There are guidelines, and
ideals.  But as I said before the devil is in the degree to which we
implement them.

If  I asked ten men/women to chose the best looking girl/guy out of a crowd
of 20,  You'd get more than 7 unique answers.

Beauty is an ideal,

Ask 10 programmers the best way to implement a coding ideal,  you'd get 10
different programs.

I still traditional Opcodes in programs where simplicity warrants.
However,  using my External I/O function and passing it the Where and Order
By SQL clauses,  I can do dynamic selection and ordering that you simply
cannot dream of doing using F-specs and opcodes.  Period.  (with multi-row
fetchs even).

We started using this one I/O routine for an Inquiry to let the user stay
in the driver seat and pick the selection clause and ordering.   We then
started using the same routine in Report programs.

And last month,  we used this 3 year old routine from a Visual RPG program
!  Powerful leveraging of existing code.

I still use chains,  Reads, and Setlls also I would like to remind you.

What is right for your shop?  You will have to decide.  Weigh the
flexibility vs the obscurity.

You gotta be a pragmatist.

John Carr
http://www.400school.com



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.