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



As much of a pain as subfiles are to program (or maybe it's just me)

Feel your pain, but I do think it is mostly perspective, from my view.
For the most part, if we inherit the code - it is what it is.

Perspective: Subfiles were a dream for me, myself also from the S/36
coding /migrate point of entry. But the main reason is, I was
comparing it to raw CICS coding which I did in my other session (we
could not afford a screen generator). It does not get much deeper than
macro assembly, had enough of that.
It was like night and day (to me) to get the same job done with
subfiles / display files vs. ASM.

Moving forward to now, I really expect anything 'new' in I/T
(generally) to be as simple as:
def_list mylist columns()
show screen
handleevent screen IO
select list mylist parms(modified)
do work
endselect
Loop or next

- I want all of that stuff handled under the covers. Much like the
'cycle' on steriods.

My view may have been quite different without the cycle early on, it
is a good lesson in how to make coding better if possible. I had some
RPGII programs that would exceed compile limits with 1 more file
statement. I spent days.....making small tactical changes then testing
testing testing. I would say that is expensive (or used to be anyway).
I only mention this to demonstrate that simple is better to me. I can
do that same program with much less code now, but probably more
modules and a bucket full of generated code I do not care about.

If "simple coding" can be done, why not demand simplicity, life being
as short as it is. True, it is not easy to do this over your old
codebase, so in reality you stay at that level or "mix" the new and
the old, or get windows. (that part was a joke)

The only drawback I see with the evolution of this 'abstraction from
complexity' is no runtimes will ever again be as thin/fast as CICS
screens & the like, but then again, it is perspective. We seem to be
able to tolerate mega programs on our local PC to code iSeries
screens/modules with, where we have no clue what is happening under
the covers.

The CPU's are so fast now the only thing that seems to matter is being
able to get done and go on to the next thing (productivity gains?).
Most anything will run fast enough unless we botch the I/O. The
simpler the format (I listed above) should have lower QA issues, the
whole spectrum of issues that we deal with
constraints/analysis/training/maint/etc.

---Mark

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.