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



When I learned RPG in the early 80's, the instructor went over the cycle and I think we did one program. After that, it was always structured programming (as much as RPG supported it at the time).

Level break programs are easy to do without the cycle. Now, with %kds(dsKey : <# of keys>), it is even easier. You really don't even need saved variables. I have one with about 10 level breaks. So easy to do with %kds() and reade.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power

 
 





From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> on behalf of Jon Paris <jon.paris@xxxxxxxxxxxxxx>
Sent: Monday, December 12, 2016 4:42 PM
To: Midrange-L Midrange-l
Subject: Re: Development Standards
 
Sorry Mark - I guess I have too many "fight the cycle" programs to ever want to see cycle programs in common usage.

And again - I am only concerned with maintainability. What is a perfect cycle program can be a nightmare that needs a rewrite after a few dozen updates. 

We don't have to code the sheets and punch the cards any more as others have noted.


Jon Paris

www.partner400.com


Partner400 - Your partner in iSeries education
www.partner400.com
If you are looking for the very best in IBM i* Education, Consulting and Mentoring services you have come to the right place! We are dedicated to helping our ...

www.SystemiDeveloper.com


System i Developer - Home Page
www.systemideveloper.com
Welcome. Welcome to System i Developer, a consortium of top experts and educators on IBM i technology. If you develop or manage RPG/DB2 applications, we can help you ...


On Dec 12, 2016, at 1:18 PM, mlazarus <mlazarus@xxxxxxxx> wrote:

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


Partner400 - Your partner in iSeries education
www.partner400.com
If you are looking for the very best in IBM i* Education, Consulting and Mentoring services you have come to the right place! We are dedicated to helping our ...

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.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.