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



Hi Tom,

<snip>
Yet we have no problem accepting the implicit "Cycle" that's a fundamental
aspect of SQL set-at-time processing.
</snip>

There is no implicit cycle in SQL. It may be there, but its not implied. The
consumer of set-based SQL does not need to know how it works to use it. The
cycle is different. There is only cycle code in SQL when using cursors, and
that is explicit and handled in the same way as handling full procedural
files. What are the points of the SQL cycle? What indicators do you set in
your RPG program to allow you to gain control as the DBMS retrieves each row
from the left table in a statement using a left outer join, but prior to the
join? Why would you want to?

<snip>
We _expect_ developers to understand it.
</snip>

But its EASY to understand SQL - it is a character based scripting language:
"select mycolumn from mytable where myothercolumn = "This Value". What's
hard to understand there?

<snip>
I'm not clear on when/why one language is acceptable for "Cycle"
encouragement and another must be considered to be 'obscuring' or confusing.
</snip>

We encourage it when it is useful and relevant. The cycle and primary files
are not useful to me and SQL is. It is as simple as that. Anyway, this is
not language based - both are used in RPG. I choose SQL and full procedural
files because the cycle and primary files offer me nothing I need that full
procedural files and SQL offer me. As I process full procedural file reads
and SQL cursor fetches in a similar manner I find it easy to use both.

Before we forget - the RPG cycle was invented to allow accountants to print
monthly sales reports for their managers without having to "program"
anything. It was nothing more than a 1970's report wizard. Once computers
moved beyond printed output RPG added functionality for workstations. To me,
they should have created a new language and left the "report generating
wizard" to keep the accountants happy. Why have cycle code for a screen
processing program? Why have cycle code for a program which consumes a web
service? I would not ask this question of full procedural files or SQL
because they are both useful and relevant. They are also both easy to use.

We have expanded the use of the detail section of the cycle beyond all
recognition. We more or less entirely inhabit this part of the cycle, with
the exception of using *INZSR, *PSSR and*INLR. We have created full
procedural files. We have added workstation files. We have added embedded
SQL. We now have service programs without main procedures. Why do we have
all these things? Because a bog-standard RPG program with primary and
secondary files just isn't enough. We added them because we need them. Put
it the other way - do you think we would be clamouring for the cycle if we
didn't have it? Do you think IBM would be pounded into submission and add it
if it wasn't there? Would we be getting excited at the arrival of cycle code
in V6R1? I certainly wouldn't. But that's my opinion and mine alone.

I think this thread is probably dead now.

Cheers

Larry Ducie




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.