Tips and Techniques: Getting Started with Procedures

[MCWebsite.Staff]

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
** This thread discusses the Content article: Tips and Techniques: Getting Started with Procedures **
0

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Looks like more work! What are (sub) procedures really buying me? Thanks, Joohn d. AZ

[gwilburn@hobbyhouse.com]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
See these articles that Mr. Cozzi has also written on the subject. The idea is using code w/out having to include it inside many, many programs. You have ONE piece of source, instead of a copied subroutine throughout many pgms. Let's Write a Procedure Let's Build a Procedure

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Parameterized access to a function (your own "BIF"), local variables, compiler checks parm compatability - not runtime, can protect parm values from being changed, easier to debug, safer to change program, more reusable code, can be used by other programs if in a service program, better for MVC architecture than a SUBSR, etc. For example, when you need to store a part number in field such as SavePart, in a subsr, how do you know that global field is not already being used elsewhere in program? Do you create a SavePart2 just be safe? No problems in a procedure - a SavePart defined there can only be seen by that procedure. Or if you call a program, do you pass a parm specific for that program CALL in case the called program decides to inadvertenly change the parm value? And you get to keep your job if you know more so it won't be outsourced. Do a google search if you really seriously want to know more. Regards, Chris

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
I appreciate the expertise and article from Robert Cozzi. As I have gained alot from articles such as these. However i have to disagree with; "Subroutines have limitations but are faster to call. They are faster to call because there is no call; there's simply a GOTO (under the covers)" Subroutines are a form of "Structured Programming". "GOTO's" are not. How anyone can compare an internal subroutine as a Goto is beyond me. We all know Goto's & Tags are early age coding and sloppy coding at best. Goto's do not return without another goto, subroutines do. Its a top-down approach to coding and very efficent using subroutines. I am not sold yet on these Procedures & Service Programs. Yes it has advantages over some of our subroutines and Call-Parm we use today "If Used Properly" and within a controlled enviroment. It will serve someone well given the proper situation. But I can also see programmers creating Service programs and procedures for meaningless reasons just for the fact of doing it. Sort of like defining fields with the LIKE command or using Field Reference File, a way to scatter information everywhere in whatever manner and believe its organized. Its always great to maintain others adventures in coding, taking a simple program and adding more external procedures that will take up more time to maintain. When it all could have been done right there..inside the program. Now lets throw in the sys/38 binding and linking procedures now available.... Hip-Hip Hurray!!

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
wpauliot wrote: > "Subroutines have limitations but are faster to call. They are faster > to call because there is no call; there's simply a GOTO (under the > covers)" > > Subroutines are a form of "Structured Programming". "GOTO's" are not. > How anyone can compare an internal subroutine as a Goto is > beyond me. Read again what he wrote and understand what he wrote. He did not say anything at all about structured programming, nor about sloppiness. He wrote about speed. And he is correct, a subroutine is basically a code segment begun with a tag and ended with a goto. Bill

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Bill Wrote: And he is correct, a subroutine is basically a code segment begun with a tag and ended with a goto. I understand when you put in these terms. I just read about a comparison between subroutines & goto's. while "under the covers" it may be, but its not manually coded as such and he was talking about coding, not what the machine code interprets.

[R.Daugherty]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
I think it's more like an internal stack return is faster than an external stack return, and then you have the issues of binding which if done make a module internal, no? I don't know why GOTO has to enter the discussion. I've done my share of GOTO's, both in 8086 and Basic. I was an assembler programmer for 10 years. On the other hand, I just rewrote an 8,000 line 8086 Double Deck Pinochle program in Java retaining the same logic structure and did it without so much as a tagged break, so GOTO's don't have to be sloppy. They're just the ENDxx, LEAVE, and ITERs,or at least should be. rd

[buck.calabro@commsoft.net]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
> Looks like more work! What are (sub) procedures really buying me? For me, the biggest gain is locally scoped variables. Far and away, local variables have made me a more effective programmer. One can get the same effect from standalone programs but who has really done that? Has anyone here written a few hundred standalone programs to perform various utility type functions, like date conversions? For whatever reason, it's just mentally easier to write a library of small procedures and place them in a service program than it is to write the same library of standalone programs. --buck

[R.Daugherty]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
I've seen through the years an RPG equivalent of "local" variables. Someone would write a subroutine and define work variables on the right side to use in the routine. Technically they were global but practically they were local. I guess the odds of someone unwittingly defining the same name elsewhere with the same type were not real large either, although that could happen. I've read through the years of the goal of writing hundreds of centralized business logic routines to call from everywhere but I've never seen or heard of it being done. I've also read the same thing about resuse through OO and read that that also doesn't happen like people planned. Is it like IBM's perpetual point and click programming tool rollout, something that seems like it should be a great thing but isn't? rd

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Ralph, Local variables in a procedure is a compiler rule. "Local" variables in a main line subroutine has to be enforced by the next green horn programmer, not the compiler. Obviously it better and safer to let the compiler manage this. As far as code reuse. I write and use procedures in service programs. Now you know someone that does use it. Are you familiar with the concept of MVC? Do you believe in it? Or do you prefer monolithic RPG programs? And how do you feel about Java on the iSeries? Do you think any business executive (CEO, CFO, CIO, etc) today would buy a business computer today that doesn't support Java? Regards, Chris

[David Abramowitz]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Several years ago, I decided to go through my clients program libraries in order to make a determination where there was redundant code that could be replaced by a universal routine. In this case a called program. Out of 2,400 programs, eight sub-programs were written. In point of fact, there was not that much universality. Going to other shops, I have had similar findings. Dave

[R.Daugherty]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Chris, I agree with Dave's findings below. It also applies to Java open source. I collected millions of lines of open source Java to analyze and look for how OO made a difference in reuse. I didn't find it, just incorporation of logic modules at the subsystem level, actually a little less granular that our program level reuse. Do you have a large amount of business logic extracted out to service programs and called from the equivalent of multiple ERP modules? If you don't, then I still haven't seen it. As for the Java thing, since Java is available on every computer, I don't think it's possible to buy a computer without Java. Whether that business uses it or not is a different question. Typically, an honest appraisal of reality generates Luddite inferences. I've heard a lot of talk for the last 15 years about the wonders of OO reuse and common business logic servers in procedural languages, but I haven't seen it. I'm always happy to see talk show up as reality, but no one has educated me yet. In fact, an examination of common IT happy talk shows that they remain myths. Whether it be San Francisco or the FBI's J2EE on Oracle Virtual Case File or any number of happy talk IT nirvana of the future massive disasters, it shows that IT happy talk is clueless. I think we here and experts such as you and Dave operate in the real world, so this is where happy talk meets the road. rd

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Ralph, Honestly, this is programming 201. Any business rule that needs to be shared across applications such as "get the warehouse hierarchy quantity available for part" (or could be in the future) gets put into a callable program "black box widget". Otherwise, if you have that business rule redundantly coded in 10 different programs and the rule changes, you get to find all 10 programs and modify all of them in the same way and test all 10 and install all 10. What if the next programmer only find 8 of those 10 programs? And the next programmer only finds 7 of those programs? You get the idea. Which method do you use? Please answer. Since you don't know anyone that uses this encapsulation, I think you've excluded yourself too. My point about Java is that if IBM hadn't ported Java to the iSeries, the platform would be old technology and would have died and we'd all be looking for new jobs. So, I don't get it when people complain about having Java on the iSeries, even if they don't use it. As far as OO, Java is all OO. If you use Java, you use OO. For example, everything (well, except primitive data types) is ultimately extended from the Object object. But, I keep it simple and use basic J2EE, and call these same "black box widgets" for the backend. See the beauty of that? Putting business rules into callable objects lets you bolt on different user interfaces too. Or are you striclty green screen? Regards, Chris

[David Abramowitz]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Chris, Please read my previous post. I happen to be an advocate of business rules. But these are usually in databases not program logic. I have searched for program logic redundancies, and I have done this in many places. There is not a lot of it. And no, I do not have to do massive changes if a rule changes. Dave