Re: Multi- Occurrence Data Structure

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