Re: RPG Cycle (was Multi-Occurring DS)

One of th first struggles with magnetic media was the idea that a record could be other than 80 or 96 columns long. The idea of chaining records together was absolutely mind boggling. Given that information then you can easily understand that MR and L1 must be relatively simple concepts; after all, we novices "got it". :)

Buck wrote:

Eric wrote:

You're probably right... I just sort of made that up as I went along, but I was simply trying to illustrate that constructs such as level breaks are easily reproduced in the modern paradigm.
I'd like to clarify that I do not necessarily think cycle dependent programs are inherently evil, but rather that it takes siginicantly more effort to understand the implications of cycle dependent features. First and foremost, the cycle forces the developer to make use of indicators to drive their logic. Now, I'll admit that as far as indicators go, the Lx and Mx indicators are pretty descriptive as to their function, but one must still have a full understanding of when and how those indicators get flipped. There is no opcode that describes these activities, so clarity of intent is not expressed in the resulting code.
Additionally, I personally find doing MR logic in the cycle to be counter-intuitive. When I want to know if fileB has record subset matching the key from fileA, it feels much more natural to me to use chain or setll to determine if this relationship exists. It feels UNnatural for me to have logic in my program that says: If I've read from fileA, but not from fileB yet, then do nothing. The cycle has forced me into a design that feels awkward and counterintuitive.

FWIW, I'm not trying to take anything away from anyone. If the cycle works for you and your shop, then good for you. Just don't be surprised if someday you can't find seasoned veterans of RPG who can maintain this code....

The funny part about the cycle discussions is that the RPG cycle was intended to be used by business people, not programmers. It was intended as an easy way to create reports from card/tape based 'databases.' If you had never heard of MR, you'd understand it within a minute of actually observing a card reader at work. With random access, many situations could be moved from MR to CHAIN. Whose of us with CHAIN brains struggle to deal with the days when all problems were solved with READ. The stuff isn't hard in any absolute sense. Thousands of people wrote tens of thousands of programs using only MR, L1 and indicators. Programs that worked and solved business problems.

Maintenance is as much a problem for RPG as it is for C. There are some pretty obscure C techniques floating around in production and there's no easy answer except that some day, someone in that shop is going to learn about MR enough to make the mod or rewrite the thing so they never have to look at indicators again.
--buck