Tweet
David, I have to agree with you. I have a favorite screwdriver in my tool kit at home. It has a nice soft sponge-like grip and allows me to change the head from a medium Phillips head to a big Phillips head. It also has flat bladed tips for using those kinds of screws. It's relatively small, light and can fit in my pocket when I need it to. I just love this screwdriver. In fact, I bought 5 of them so I can have one in the garage, one in the den, one in the kitchen and in the bedrooms. However, if I need to put in 100 dry wall screws using my favorite screwdriver will create a lot of work for me. I have a power hand drill with a screwdriver bit in it. It has the same abilities as the hand held screwdriver, two Phillips and two flat blade tips, but it's clunker. It doesn't feel as good in my hand and I certainly can't put it in my pocket. And, it must be plugged in and can't be used everywhere. But I do use it when it's needed. Moral of the story, use the right tool for the right job. Just because a new tool comes along doesn't mean it necessarily replaces the old tool. They may just compliment each other. And, to the topic: There's certainly nothing wrong with using level breaks as a control mechanism in RPG. I just like the thought that there are many ways to accomplish the same task. What one person likes another might not like. What I do think is wrong is to imply that simply because one person chooses a different method of accomplishing the same task that they are immediately labeled as "behind the times" or "not with it." Labeling of people is never a good practice. Once you start going down that slippery slope you'll soon be labeling people for other attributes that you may dislike. chuck Opinions expressed are not necessarily those of my employer. "David Abramowitz" wrote in message news:6ae58d1f.23@WebX.WawyahGHajS... | When the "Times" requires that I exert a far greater effort, than previously required, then the "Times" certainly does not enhance the programming process. | | Level breaks are a tool that is included with RPG IV. | | I will use whatever tools are available to me to ensure that the job is completed better, cheaper, faster, and more accurately. | | Dave
-
-
TechTip: An Easier Way to Process Level Breaks
ditto... -
TechTip: An Easier Way to Process Level Breaks
Hi All, First, please forgive my bad Latin; it's supposed to be the plural of "Causus Belli" reason for war; but probably incorrect. Anyway, due to all the fuss about Doug's Level Break article, I went back this morning and actually read it with the attempt at really understanding it; which took a while. My assesment is, yes, it is a nice technique (one that I have not seen before) that finally frees us from coding the tiresome hold fields in writing level break programs. Yes, we still have the cycle available, but I'm not sure that the level indicators are usuable in /Free form RPG. At any event, you cannot use the level indicators with files that are not opened as primary or secondary input/update files; which situation I have run into quite often. In such cases, we need a solid, ready-to-use template to handle level breaks. Doug's is certainly such a solution. I would hope that any rudeness on this forum would be unintentional. I am sure I have been rude too in the past; but again, I hope not willfully! I use the cycle occasionally, but I prefer to do without it. And, in the programs I see at work, the cycle is encountered less and less often. It's nice that IBM still supports it in RPG/IV, but thank goodness there are other ways to do things (My prejudice showing here). Rich HartComment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
** This thread discusses the Content article: TechTip: An Easier Way to Process Level Breaks **
0Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
... or we can use the RPG cycle. Why find ways to complicate a program just to avoid the cycle? If it's for fear that programmers won't understand it, then hire new programmers.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Use the cycle to your advantage by processing L1, L2, L3 breaks. Ya, I know, we are no longer suppose to use indicators. But, the cycle is very useful. If I need to use level break processing, I get away from "modern" constructs and use the cycle. It's much easier to read a program written that way.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Why make a mountain out of a Mole Hill, just use the cycle, ' L1, L2 with Detail and Total Time, its simple and works perfectly with out a lot of excess Coding, unless you are getting paid by the wordComment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
What ever happened to all those "old" programmers who took advantage of some of the most productive components in RPG? Using the level indicators as they were designed takes all the guesswork and interpretation out of the code. There's no "if" something, then something else, and exsr something else... just simply if L1 is on, then the associated field changed. RPG has defined L1 on the C'specs to allow for total time processing, header time processing, and allows the same on the output specs. It even takes care of that problem with the first record by the way its cycle is defined. It skips the total processing on the first record... and you never have to worry about cleaning up after the last record... LR also sets on all the other control break indicators. I'm behind all of you who use RPG as it was first designed. There is optimization built into the basic cycle that you can't get by coding around it. Obviously there are great advantages to some of the new functions available in ILE RPG, but we shouldn't ignore the fact that the old capabilities are still there, and have their place.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
It's nice to present a refresher in partial key processing, but I wish the author had given credit to Bob Cozzi, who explained the technique in his first book on the modern RPG language back in the 80's. It worked beautifully for many years but does need some care to work in free-form (you have to relieve your EOF condition immediately before a subsequent read). On the topic of the '80's: RPG cycle? Get real. Check your calendar. No one who has come out of school in the last 10 years has ever heard of the RPG cycle. If we want to convince people that RPG is still a viable and useful language and get some youth back into the cadre of programmers, we've got to use RPG in its up-to-date form where it looks like a real language to Java and VB programmers. Level indicators certainly do not accomplish that.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Yikes! I think you are about to start something... These cycle debates can go on and on.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Why reinvent the wheel...which is the shape of a cycle, come to think of it!Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
This is VERY humorous reading. I am wondering if the article author would have guessed this much "discussion" would be generated? While I attempt to look at all views presented, I have to agree with the comment that if we continue to use 1970 coding techniques we will be viewed just like all these "old" COBOL programmers. I see "purist" COBOL code everyday in one of our packages. I HATE IT. I have to say that using the cycle should be considered "purist" RPG code. I hold classes to teach the COBOL people RPG twice a week. I have mentioned the cycle only during the "evolution" lecture. At my company, we are attempting to use SQL in our COBOL programs so to make it efficient and easy for any programmer (who can read SQL OR has access to an SQL book) to maintain the code if we are gone. The same technique is being implemented in our RPG programs. This allows both COBOL and RPG programmers to maintain all our code. A litmus test I have used when I was the hiring manager included creating a program using the cycle and duplicating the code not using the cycle. Amazing how many RPG programmers with less than 5 years don't know what the cycle is, much less how to use it. I think we should ALL embrace the modern methods. Yes, it causes us to type more, to have to produce more code. BUT, if you do not evolve, you die. just my 25 cents worth.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I'm one of those 'new programmers' with six years of RPG. I took RPG at Cinci State. No review of cycle. Just be aware its out there. Maybe you won't have to use it. That's what we got. Well I'm contracting and last week the client needed a handful of programs asap with level break processing. The manager here, a coding manager, did the file processing and gave me a quick lesson on the cycle. My question is: if Java programmers had a similar tool that was a easy to use, a model in simplicity, and a model of effecient use of the box, would they hesitate to use it? Maybe the question should be: Why can't Java and SQL types learn the cycle, at the same time RPG programmers have to learn all kinds of things that are less effecient, and more time consuming? Maybe we need to be more vocal about what is modern. Since when does modern mean, less effecient on all counts. This brings up the real question: Where is the future of this box for the present programmers. Our future seems to be to prepare the applications for cheaper programmers to come in a do their stuff, their way.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Let me jump back on the soapbox for a moment. 'This brings up the real question: Where is the future of this box for the present programmers. Our future seems to be to prepare the applications for cheaper programmers to come in a do their stuff, their way.' What I meant to say is the realization that has hit me. Our future seems to be to prepare the applications, that we have written to run optimally on our box, for takeover by cheaper generic performing plug and play programmers who all code the same way, no matter what box has to process the code. So, we won't all be flipping burgers, we will all be cashing the same size check as the burger flippers.Comment
-
TechTip: An Easier Way to Process Level Breaks
** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I agree 100% with "ctibodoe". If Java had a cycle, we would be forced to use it, no matter how "old" it was. Believe it or not, RPG DOES have many pluses to it. It is a really good mixture of old and new. I can be an older programmer who knows, appreciates, and uses the cycle, and I can also me a younger programmer, who knows nothing about the cycle and codes appropriately. To me, the cycle is a lifesaver, and helps me be more productive by having to code less and make the machine do more. Less coding means less time debugging. Less coding also translates into lower programming error rates because there is less code to maintain. I have looked at Java (not programmed in it). Take a look at the program source. Can you quickly understand what the program does? Compare it to RPG or COBOL. They may be old languages, but they are easily understood and changed. When I am under the gun because "the client is screaming and the report HAS to go out today or else they will terminate the contract" having an RPG or COBOL program to maintain allows me to make fixes quickly, and the cycle allows me to add breaks very easily. Not using the cycle is like telling me I can't use a highway to go to work because it may be too dangerous or the signs not easily readable. But I can't spend the extra time going to work using the side streets because it takes longer, even though the ride may be more scenic. Get the picture? And I have yet to meet ANYONE who can tell me that in a well organized shop, RPG is less productive and gives less functionality as Java. I can't think of anything I can do in Java that cannot be done in RPG. Sure Java requires programming standards be implemented, but in a well run RPG shop, with standards that are followed, where's the Java advantage? My Java instructor, agreed to that! And he also said the AS/400 (at the time) was the best platform to run Java on. So where's the difference, except in the age of the programmer? Sorry for the rambling!Comment
Comment