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


  • Subject: RE: An odd thing
  • From: "Walden Leverich" <walden@xxxxxxxxxxxxxxx>
  • Date: Mon, 5 Jan 1998 17:17:46 -0500
  • Importance: Normal
  • In-Reply-To: <C5B3CC77F280D111BF140060084031B9@Taylorcorp.com>

Sorry, maybe it's because I spend much of my programming time looking at
Synon generated RPG, but I find the first example easier to read than the
second. In the do-loop process it's easy to see everything that is
occurring, but in the cycle you have to remember everything the cycle does
for you. Also, using the cycle I'm passing through all my C specs for each
record (ignoring subroutines, and conditioned statements) so it's much
easier for another programmer to insert a line of code that screws
everything up. My vote: Kill the cycle and use do loops.

</Hypocrite mode on> Having said that, many of my one-off programs use the
cycle. </off>

-Walden

> -----Original Message-----
> From: mcsnet!midrange.com!midrange-l-owner@Mcs.Net
> [mailto:mcsnet!midrange.com!midrange-l-owner@Mcs.Net]On Behalf Of Stone,
> Brad V (TC)
> Sent: Wednesday, December 31, 1997 11:50 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: An odd thing
>
>
> It's sad to hear that a shop would look down upon using the cycle and be
> so close-minded that you would be fired if you used it in production.
>  (You may have been exaggerating, but still...)  Using the basics of the
> cycle is easy.  For example reading a file, or doing level breaks.  I
> would much rather code level breaks with the cycle than by hand.  One
> must learn to cherry-pick the best parts of the cycle to use to make your
> job easier.
>
> One thing I have started doing on level breaks is this:
>
> CL1  EXSR $L1
> CL2  EXSR $L2
> etc...
>
> this seperates things and doesn't clutter the code witht he left handed
> indicators.
>
> Here's another example... Which is easier to read?
>
> A)  simple example with no cycle
>
> C   READ FILE   69
> C   DOW (not *IN69)
> C   WRITE OUTPUT
> C   READ  FILE   69
> C    ENDDO
>
> B) same example using cycle
>
> C   WRITE OUTPUT
>
> It speaks for itself in most cases.
>
>
>  ----------
> From:  Bruce Guetzkow
> Sent:  Wednesday, December 31, 1997 10:03 AM
> To:  bvstone
> Subject:  RE: An odd thing
>
>
> Paul:
>
> Just a few comments about the RPG cycle -
>
> 1)  It is unique to RPG.  No other language that I know of has this =
> inherent cycle.  One can "easily" (relatively) convert programs from =
> COBOL to FORTRAN to BASIC to (pick-your-favorite).  But to convert =
> to/from RPG using the cycle takes special knowledge (job security?) that
> =
> only RPG programmers have.  Even those of us that no longer use the =
> cycle for processing, still use the cycle for file opens/closes (at =
> least some of us do), so there is still some RPG-specific knowledge =
> required, but far less, making RPG programs much more convertible and =
> understandable for non-RPG programmers.  (BTW...I don't use indicators =
> in the left-hand columns either, no matter how many of those old =
> programs still have my name on them!)
>
> 2)  The RPG cycle isn't the easiest thing to learn.  It took me a week =
> to figure out how to get the date and time on page 1 of a report using =
> the cycle and the 1P indicator.  I had to call a friend and he had to =
> _tell_ me...I never did figure it out on my own!
>
> 3)  Having said the above, I _do_ use the cycle for one-time programs =
> that do _not_ go into production.  Using the cycle for production =
> programs here is "verboten"...the quickest one-way-ticket to the =
> unemployment line I know of!
>
> The cycle had its place, but I think that place is now in the past.
>
> Bruce Guetzkow
> Team Coordinator, Applications Development
> Highsmith Inc.
> W5527 Highway 106 P.O. Box 800
> Fort Atkinson, WI  53538-0800
> Tel (920) 563-9571  Fax (920) 563-7395
> EMAIL bguetzkow@highsmith.com
>
>
> Bradley V. Stone
> bvstone@taylorcorp.com
> http://prairie.lakes.com/~bvstone/
> "I was on fire... and I was dry!"
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


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.