|
boothm@ibm.net wrote: > RANT(*AGHAST) > > Can this be true? I am sitting here absolutely flabbergasted that anyone >would teach RPG and not require a thourough grounding in the cycle. > > RANT(*LARGE) > > The concept is so simple, and the results so predictable that any one that >ignores the cycle is ignoring one of RPG's greatest strengths. Additionally, >there is so much cycle code out there right now, how can an instructor not >teach the cycle? How can a programmer claim to be an RPG programmer and not >understand the cycle? > > RANT(*LARGER) > > Are these people that started with a C course in college and feel they are >the last great cowboy and its up to them to preserve the Code of the West by >rolling their own? > > RANT(*OFF) > > In <415593AAC1B1D111B21100600856D2080E2902@TECHNOCRATS01>, on 04/06/99 > at 10:16 AM, Colin Williams <Williamsc@technocrats.co.uk> said: > > >Remember, many RPG programmers have not used the logic cycle much, if at > >all. So why introduce code that going to take someone a week to > >understand > > -- > ----------------------------------------------------------- > boothm@ibm.net > Booth Martin > ----------------------------------------------------------- > Booth I had a 12 week course in RPG II, using the cycle, back in 1984. I also had a 12 week course in COBOL at that time. Given the choice between COBOL and RPG II...I would choose COBOL. RPG III, 400, or RPGIV on the other hand...offer the structured programming concepts which RPG II does not. Given that the newer RPG is much less wordy than COBOL and much more prevalent on AS400 I haven't written any COBOL since about 1986. I've been coding in RPG III, 400, and IV since that time. One of the shops I started out at was Samsonite Corp. Corporate Office. Samsonite had many COBOL and RPG Guru's. It was one these guys that taught me the joys of structured RPG and i've been writing code that way ever since. However...I have run across a vast amount of RPG II cycle style code...I don't see much of it any more....THANK GOD. All I can say is....if you like using the cycle and it works for you...fine. Personally I hate it. Probably because I have seen very few cycle type programs that were simple and straight forward. They may have started out that way but they sure didn't end up that way. Another thing...an RPG Report program with level breaks , written on an AS400 is about the simplest thing there is for a programmer to learn, code and make a living at. Everywhere I have worked I have been complimented on my coding style. EVERYONE understands it, no questions asked. With me, it is not that I don't understand the RPG Cycle. I understand it all too well. The cycle forces me into it's FIXED logic. What if I revisit this code later and requirments have changed and now I come to find that I will need to read this file forwards, backwards...start in the middle...start at the end....READE by key...etc...etc...etc... Let me ask you this How many News/400 Tech writers do you see expounding on RPG Cycle coding ? How many expounding on structured code using structured op codes...etc ? Now ask yourself why that is Then Study some simple well written RPG programs that don't use the cycle. The benefit to me is all to obvious. I bet if you look back a few years, like when RPG III initially started out and the new op codes were added at that time....check out some News/38 from that period...you will find articles galore on this subject. These guys explain it better than I can. I have seen so much ugly RPG to the point of requiring me to double up on my medication at times. This may account for some of my disdain for cycle coded programs. The proof for me is in all the compliments I have received from those that have worked with my code. I'm not talking about writing the most scientifically complex stuff. As an RPG programmer I can do just fine. I don't about know about Java...i'm sure I could learn some of that to a degree. I don't think there is any other language out there that is as easy as RPG and CL along with OS400 and DB2/400. My point is...like the report program example I posted...hey, it's just a simple report program...in fact..it is so simple that there is no need to even discuss whether it should be cylce coded, or structured coded...it's just a simple computer program...period. Course if I later have to start chaining to other files...print two detail lines instead of one, followed by the constant..."THE AS400 IS COOL"...stop halfway through the file then begin reporting to the same print file from records from another file...etc...etc..etc... It would still be simple Not so if I had to first get rid of that dreaded INPUT PRIMARY stupidity. If your going to create a program using input primary then you are in effect saying this program will never require full procedural processing of that input primary file. Fat Chance But...do whatever you like...having to rewrite RPG is one of the things that keeps us employed. The benefits of not using the cycle are there for those that want to take advantage of them. The real crime in all of this discussion is to begrude those of us that take good advice from the very best AS400 pro's in the world...and follow it. That's about all I have to say on this. The way things are going these days...if you can spell RPG...your my best friend. : ) Happy Coding -- Jim Welsh Programmer/Analyst Halkey-Roberts Corporation - St. Pete FL 727-577-1300 x279 http://www.netcom.com/~jimwelsh/welcome/welcome.html mailto:jimwelsh@ix.netcom.com +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@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 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.