TechTip: An Easier Way to Process Level Breaks

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Please let me explain why I use the cycle. I use it as a tool. If I have to write a program that requires level break processing or even a simple report without level breaks, I use the cycle. Why? because it is efficient and the one best way to code in RPG for that given circumstance. I write lots of code in lots of languages, C++, VB, VBA, Java, all flavors of RPG, COBOL, blah, blah, blah. Any of these languages are just tools. That's it. Nothing more. Lets not make this a religious discussion. Any of us should be able to learn any new languages and techniques. but, we should also be able and willing to learn techniques within old languages. I have yet to write a single line of free-form RPG code because none of muy clients wants me to. Currently, I'm working on old COBOL applications for a client. Why? Because the pay's the same. If they want me to code in a language I don't know, I will learn it. BTW, nothing is ever really new and modern. Sure, the interface can change, green screen vs. gui vs. web, but, regardless of the language or its newness, they all have to do the same things: 1) accept input, 2) do something with that input, 3) present output and/or store it somewhere. That's it, no magic, just Input, Processing, Output. After that, it's just syntax. Thanks for letting me vent a bit.

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
It's good to hear that there are so many of you out there that remember the RPG cycle...I was beginning to think I was the only one. On the other hand, I have not actually used level indicators or (remember these?) matching record indicators in a VERY long time. Which is, I think, the root of the debate here. There are those of us who know the detail workings of the RPG cycle and those that don't. In my mind, the question comes down to who is going to be supporting (read: debugging) the code? Since "new" RPG programmers are not likely to know or use the RPG cycle, all of us should write code that can be maintained by anyone. Unless of course you want be chained to maintaining your own code?

[dchristie]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I never took CL in college, so I should have demanded that the shop that hired me 18 years ago not code in it. Same for DDS, UIM ..... If we are so worried about the new programmers, we should stop RPG immediately. Anyway, I forgot to mention that I liked the article anyway.

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Jeff- I don't see any of those SQL types chained to their code. I am learning SQL on basically, a as needed basis to integrate their code in a multinational project using every feature of ILE and RPGIV that I ever read about. This project reads like the index of an ILE and RPGIV dictionary, they have found a way to use every entry. Do I complain? Do I hesitate? No. I do what I think would have been very hard at its easiest 5 or 6 years ago when I started doing this. I look up what I need to know how to do. Way back, I would have needed to find the shop library and hope the manual was there. Now there are working examples of almost anything that has ever been done available in many places, and the internet is a good choice: IBM site, rags, forums, etc. So, if something works, and there is no shop standard against it, there is no longer any excuse about something being too hard for someone else to learn. We are all pros? Are they all pros? I haven't digested the article yet, I found the responses too interesting since I have just really discovered how valuable the cycle can be to me, my company, and my client. I can't imagine me starting a new project and after being given some code to work with, telling the client, 'I don't like this code, you have a snippet here that goes back to the dinosaur days of Java, Java 1.1.'

[J.Pluta]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Before you all actually lynch poor Doug, let me jump in here. There are valid reasons when the cycle is NOT appropriate, the most obvious being when the data can come in in different orders (e.g., the user controls the data sequence). In that case, levels don't work so well, but something like Doug's technique can be generalized to handle the breaks. Joe

[rdbas400]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I rarely deviate from cycle processing when using level breaks. One of the most important things I learned on my second programming job was: let the computer do most of the work...period.

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
It may get away from save fields but what could be easier( other than the cycle) than this: I know this is simplistic and kind of pseudocode in places but I an not at my work! I purposely left out the levelbreak SR's because they only roll the counts or totals and renew the saves: far easier to read than the partial keys, especially for someone that may have to maintain the code after you write it. I personally am stuck debugging a mishmash of old RPG III and RPG II code that was converted to RPG IV and it is a PAIN.

---

Code

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I got the breaks backwards, sorry about that

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I can't believe you actually posted this! What a waste of memory!

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
Why not structure your level breaks into subroutines, easier to read and less hassle. If you can't code it this way, then you obviously haven't stayed up with the times and RPGIV is no place for level break indicators, tags, and goto's. You start using level break indicators and people will fall back into legacy coding. Just don't do it! As Chris Rock would say!

[J.Pluta]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
This last post of yours is just a tad offensive. Doug posted a technique and used a skeleton program to do it. His technique will work regardless of the number of key fields at each level, and is consistent throughout. You can use this skeleton and customize it to your own particular environment. Once done, you can then optimize it however you want. The phrase "I can't believe you actually posted this!" is pretty jarring here on the MC Forums, especially in response to someone who's gone through the trouble of writing something for all of us to use. My own opinion, take it for what you paid for it. Joe

[David Abramowitz]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
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

[Guest.Visitor]

TechTip: An Easier Way to Process Level Breaks

** This thread discusses the article: TechTip: An Easier Way to Process Level Breaks **
I am not usually one to get involved with bickering on forums but... GET A GRIP PEOPLE! Doug has provided a useful tool. If you choose not to use it then fine. However, if you choose not to use it and then feel compelled to bash the usefulness of the tool and/or the skill level of the author then I, for one, would rather not hear (or read) about it. Or better yet, if you've got so many brilliant ideas of your own then write your own TechTip. (i.e. put up or shut up) Jeff