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



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

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.