Subprocedure Basics

[Artiztik]

Subprocedure Basics

I have just gotten in the habit of creating a subproc called Main. Then the only true mainline code is a call to Main. From within Main, any variables you declare will be local to Main and you'd have to pass them to other subprocs to use them elsewhere. Then globally defined fields remain globally defined for a reason.

[H.Boldt]

Subprocedure Basics

Bob wrote: "No. I don't think we need to have another thread on feature syntax or implementation that goes nowhere." Then you're pretty much guaranteeing that your concerns will go nowhere. Which begs the question: Why make a loaded comment like "Certainly there are a number of other issues with the poor implementation of RPG IV that would bother a non-C programmer." if you're not prepared to defend it? But not to get into any specifics, are your concerns: a) things which you, Bob Cozzi, find annoying; b) things about the language that you don't fully understand; c) features of the language which exist because they've always existed in the language; d) needed features which are missing from the current language; or e) genuine issues about the current definition or implementation of the language? Cheers! Hans

[Guest.Visitor]

Subprocedure Basics

Quiz a) things which you, Bob Cozzi, find annoying. Although Bob sounds personally irritated to add flavour to his articles, I think he focus is professional. b) things about the language that you don't fully understand. You are kidding c) features of the language which exist because they've always existed in the language. That is more like me who whines about the legacy junk coming from RPGII, although I earn a livelihood salvaging that junk. d) needed features which are missing from the current language. Well he does complain about the absence of Native GUI, I would discount this. e) genuine issues about the current definition or implementation of the language. I think he is pointing to a "similarity with anamoly". I would think it would have been more consistant with C behavior if a build-in subprocedure would access the Global Variables but not an external subprocedure. However he has discounted that as a non-issue. So I fail the quiz.

[H.Boldt]

Subprocedure Basics

a) How professional is it to make provocative statements like "Certainly there are a number of other issues with the poor implementation of RPG IV that would bother a non-C programmer."? And then not standing up to defend it? b) Face it, even the best of us make mistakes, eh? d) I know others have advocated a native GUI, but has Bob? I thought he was into CGI GUI's these days? e) Along with this point, there are things that Bob has suggested but have been considered and rejected by those responsible for the language. Complaints in this category need to be put to rest. What's my point? I suppose I'm just tired of people like Bob who praise RPG as if it were the second coming, and then come out with comments like "the poor implementation of RPG IV". Cheers! Hans

[Guest.Visitor]

Subprocedure Basics

As for your first para, Bob's phrase is as professional as his old saying, "RPG developers simply do not get it, because they are not real life application developer". Okay I am putting words in his mouth but he has always been using this pissed off tone for the past 10 years. He is just adding spice to his articles. As for your last para, I have been jumping up and down about /free. Then I also whine about what I call "Legacy junk carried from RPGII". I guess we are desperate guys who can see our boat sinking. We yell to everyone on how great RPG is, and then turn around and tell you guys how pathetic job you have done! Unreasonably high expectations you think? So I guess the answer is E. He is re-raising the points that you have already considered and rejected.

[R.Daugherty]

Subprocedure Basics

I wouldn't care if RPG /free became C and/or Java with inline functions for the RPG opcodes, ala AS/400 Toolbox for Java. It just isn't any big deal. It's just syntax. Oh wait. RPG returning multiple parm values is a big deal. rd

[Guest.Visitor]

Subprocedure Basics

I must try this--having a Main sub-procedure should keep maintenance and support programmers from messing up carefully crafted code. Though I bet most of them will complain about it. Though it kind of reminds me of the EXSR BEGIN EXSR MAIN EXSR EXIT style of coding which I generally find adds little to the structure of the program.

[Guest.Visitor]

Subprocedure Basics

It seems this discussion is focusing on using non-exported subprocs (not defined with keyword EXPORT). I have always had the opinion that subprocs were primarily a good idea if you want to create containers of logic (toolbox tools) so that other programs can use them. Defining them in service program modules with keyword NOMAIN is standard stuff here in our shop (similar to how java classes often have no need for using the main method.) However, if you just have something like a monolith RPG program that needs reusable logic to itself that is not really reusable to other programs, then you may as well stick with subroutines. Of course, subprocs still can be useful in this context if you understand them enough. But don't just create non-exportable subprocs just for the sake of trying to be ILE savvy when it's not necessary. Also, a big omission about local variables from Cozzi was the *STATIC keyword, which retains values after the subproc returns. It's interesting that some other languages also support this, but java does not within class methods. Static in java means something very different to classes.

[R.Daugherty]

Subprocedure Basics

Even if used locally, isolating the local variables out of the global pool and having at least a nod at defining dependent input and return parms is worth the prototype effort over subroutines, although I do the equivalent with comments in subroutine headers. On the other hand, how far do you think Java would have gone if every time someone wrote a method they had to define another interface definition for it in the class? Not far, that I can tell you. Some people don't have as much tolerance for bs as I do, and I don't have much. For my jobs site server system I did write a few subprocedure modules that I binded into some programs, which is a middle ground to duplicating the code or externalizing in a service program. But the tradeoff of isolating some code from main server programs in exchange for additional job complexity of scaling service programs with server instances wasn't even close to worth it. And even at that, subprocedures do nothing more than we've done for decades with called RPG programs returning with *INLR off. So the parms are checked at compile time. Big whooptidoo. One test call tells you if you've hosed up your parm list. Plus it's granular, only that used is called into the job. With service program/DLL/grabbag method collections architecture, it actually hinders reuse as calling something in it brings the whole enchilada with it. Do that for a few widely scattered routines and you'll bring half the enterprise in to your job. So no surprise, surveys show very little actual reuse in OO land after all these years of listening to the gurus chant their mantras. And no commensurably superior enterprise software development, or for that matter enterprise software. We need to get a clean interface from ILE RPG to web pages and other UI thick and thin, including 5250 using all its features, callable from RPG, and standardize on it, knowing IBM is useless with their own agenda. I've seen enough here to know we probably have it or are close to it, we just haven't standardized on it yet. rd

[R.Cozzi]

Subprocedure Basics

Well, I'm pretty thick skinned, and as such, don't mind people using their freedom of speach to state things that I agree or disagree with. If somebody says "I think there's a number of problems with xTools so we won't buy them" I would, as you did, probably ask the person what they were, but also go back and look at it and see if they are right and try to infere what they meant. For example: I still teach RPG IV. The two biggest challengs for me are (A) The inconsistency with which features are implemented (examples to follow) and (B) the fragmented nature of the languages (i.e.,g release by release enhancements that don't work on *PREV). Just today I talked with a major software vendor on the iSeries and asked them why they didn't start using RPG IV until just recently (in the last few months). "We were concerned about the fragmented nature of the implementation. Some features work on V5.1, some on V5.2, other on V5.3. We can't sell software like that." That's my biggest bitch at the moment. On the "A" item... well I've got work to do and bitching about it doesn't/hasn't helped, so as I said, why bother?

[R.Cozzi]

Subprocedure Basics

Hans,

>with the poor implementation of RPG IV...

I've tried to understand why my comments caused you some concern and I went back an read what you quoted and I think "with the poor implementation of RPG IV" is the phrase that pays. Mostly it was a poor choice of words. To me the problem isn't the implementation as in the way the underlying code is written, but with the user-interface and the fact that this issue is exaggerated by the release-to-release incompatibility of the language.

[B.Morris]

Subprocedure Basics

I agree, I've often thought that would be very useful. It could be handled by a GLOBAL keyword on the P-B spec where you list the globals that your subprocedure is allowed to use. GLOBAL(*NONE) would mean that your subprocedure couldn't use any globals. No GLOBAL keyword would mean the same as GLOBAL(*ALL), to be upward compatible.

[H.Boldt]

Subprocedure Basics

Bob: I understand your concerns. And actually, I don't disagree with them. Regarding the "release-to-release incompatibility of the language", first, to be clear, the issue is only with backwards compatibility. Heck, that's always going to be a problem. And it's a problem with practically all other languages and software products, so there's nothing unique with RPG there. People want enhancements. If there aren't at least a few good enhancements each release, RPG fans will wonder if their language is being ignored by IBM! The other issue is with inconsistent design from release to release. That is for example, first we add date operations in fixed form calcs. Then they're added to expressions and that form is then the recommended style. I think that's a fundamental systemic problem, and it happens with software products that are a) designed by a small committee; b) designed by committee who's members change every so often; and c) designed with resource contraints such as time and manpower. For every enhancement done to RPG in the past 25 years (in my personal observation), the enhancement made a lot of sense at the time, for specific design and resource planning reasons. But over the past quarter century, the cumuluative effect has been a hodge-podge. Compare with some other languages developed under similar conditions. At first, Java had AWT. Then, Swing. Contrast with some other languages developed under different conditions. Languages like Perl and Python are designed under the control of one BDFL (benevolent dictator for life, for those who don't know that term). As a result, even through many releases, they can maintain a sense of consistency. Furthermore, the BDFL often has a good idea of where he sees his baby going in the future and can steer the language towards that vision. Plus, there are usually few hard schedule constraints. Non-commercial projects like that can release when the developers think it's ready. Anyways, I don't see the situation re RPG improving any time soon. What's in the language now has to stay in the language. Like I said, people seem to want improvements on each release. But I've always felt that it would be better for either a) no enhancements (other than those required by the OS; or b) massive investment to develop an "RPG V" with all the quirks eliminated and really necessary improvements added. But hey, you know how much influence I have now on the language! Cheers! Hans

[MCWebsite.Staff]

Subprocedure Basics

** This thread discusses the Content article: Subprocedure Basics0

[B.Morris]

Subprocedure Basics

Using INDDS isn't the same thing as basing a data structure over the address of *IN. You define and use the subfields the same way, but otherwise, they are very different. With INDDS, the subfield at say position 3 has no relationship to *IN03. With the based DS, the subfield at position 3 is exactly the same storage as *IN03. Using the INDDS method, you can keep your display file indicators separate from your program indicators and possibly more important, you can keep the indicators for displayfile1 separate from displayfile2.