Re: Development Standards -- MIDRANGE-L

+1 Paul

You mention that advantages of service programs are not available - I think this assumes that these are all RPG III or before - but the cycle is just as much a part of RPG IV, as you know.

When one does not use the cycle, things like level-breaks need to handled explicitly in the program - one might say that the level of abstraction is removed when one does not use the cycle - often, we WANT to increase abstraction.

This is a choice one makes - i admit to generally keeping a set of saved values to manage control levels, especially when I use embedded SQL.

I also admit to having been confused by key specifications in an F-spec for an internally described file. Hey, I was there when studying RPG II for a couple weeks - heh - in 1989!

For me the thing to do has become to write new stuff in a linear fashion as much as I can, to continue to use the cycle for file opens, and to understand existing code we have from the last 30-40 years, enough that I can maintain it.

Of course, it IS nice to at least have written a matching record program once! But things like matching records really controls the order of records read, as you are describing here. And putting ID values in I specs, well that's an IF on a field.

So maybe it'd be useful to have a map between what features of the cycle can look like or correspond to in programming only with externally-described files and in a linear fashion.

For newbies (and vets) who have to work with older code - you will benefit GREATLY from reading the charts that describe what the cycle does - and you MIGHT even be amazed at what you now have to do to accomplish what that process does.

Cheers
Vern

On 12/11/2016 9:42 AM, PaulMmn wrote:

I take issue with your comments that the style of a 'cycle' program is significantly different from 'linear' programs.

In every 'linear' program you create your own 'cycle'-- whether it's a do-while or a do-until, you're telling your program to loop until a certain condition occurs.

In a 'cycle' program the logic of the loop assumes you're going to be processing a series of transactions, probably read from a file. So the cycle just hands you the input records one-at-a-time. Then your logic does something with them.

As far as being harder to read and more difficult to maintain-- that depends on the programmer, and whether the programmer used 'spaghetti bowl' logic. I'm sure there are just as many hard-to-read linear programs as there are hard-to-read cycle programs!

In a linear program certain blocks of code are conditioned by the data being read-- is this an order header or a detail line? You can use the same logic in a cycle program. You can use subroutines. You can chain and print on-demand.

Monoliths are what they are-- it's the programmer that builds them! Deciding what goes in a single program is what the programmer/developer's responsibility.

I grant you, that you don't have the advantages of service programs (although you can use a call, with its extra overhead).

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx

.

At 12:23 PM +0000 12/11/16, Joni V. wrote:

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