Re: Development Standards

Jon,

It's not so much that you *can't* do it, but rather how much easier it is and with considerably less code. Here are my top 3.

The most obvious and probably the most used feature would be level breaks. It is so much easier for RPG to do all that logic behind the scenes for me. I recall working on one of of those "non-cycle (aka manual)" level break programs that had quite a few levels, at least 6, IIRC. The amount of extra code got in the way. Debugging it took a long time. The error had to do with, you guessed it, an issue with the level break logic.

The next one is matching records, which I use pretty rarely, but when needed is fantastic. The amount of code saved is substantial. When written properly, it is quite easy to follow and understand, even if one doesn't fully understand the whole matching records capability.

The last one, which I have used maybe a half dozen times is look ahead fields. It has very limited use, especially since it does not support externally described files, unless defined as internally described within the program. But when it fits the problem it reduces a lot of buffer saving and restoring.

-mark

On 12/12/2016 12:40 PM, Jon Paris wrote:

I don't understand this at all Rob. I can't think of a single thing the cycle does that I cannot match in a non-cycle program. There no "special sauce" there that I am aware of.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 12, 2016, at 8:59 AM, Rob Berendt<rob@xxxxxxxxx> wrote:

While I've not done a cycle program in a long time I will agree they are
terrifically efficient. The blocking inherent in them is awesome. I had
to do a bunch of manual adjustment of blocking to come even close to what
a cycle program could do. I posted some time trials a long time ago to
this list


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Joni V."<joni_vanderheijden@xxxxxxxxxxx>
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
Date: 12/11/2016 07:25 AM
Subject: Re: Development Standards
Sent by: "MIDRANGE-L"<midrange-l-bounces@xxxxxxxxxxxx>



As a young one, the problem I have with cycle programs is not that I don't
understand them or can't use them.

- They lead to monolithic programs

- Are harder to read

- More difficult to maintain

- Blocks the use of newer features

- The style of a cycle program is significantly different from linear
programs.


So taking the arguments above into account, our more experienced / older
technical experts agreed to disallow them in our coding standards.

I have seen one new cycle program in the last four years, it was a
one-shot program for a migration of the database where almost all records
from a file had to be updated. I have to admit it was very performant.

Joni
________________________________
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxx> on behalf of Jeff
Crosby<jlcrosby@xxxxxxxxxxxxxxxx>
Sent: Sunday, December 11, 2016 12:46
To: Midrange Systems Technical Discussion
Subject: Re: Development Standards

On Sat, Dec 10, 2016 at 10:20 AM, Raul A Jager W<raul@xxxxxxxxxx> wrote:

If we, old ones, where able to learn it, the young should be able to. It
is a tool specially designed to generate reports, probably the best in

the

industry, why not use it? The fact that other languages don't have it,

is

a dis advantage that we do not need to copy.

Agree 100%. Take the "don't use the cycle" to it's logical conclusion and
you're saying "Don't use feature X because it's not available in every
language out there."

And no, the cycle is not the answer to every programming issue.



--


Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com<http://www.dilgardfoods.com>

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.