Subprocedure Basics

[Guest.Visitor]

My first language was C and I formerly wrote programs in C on the AS/400 for IBM. I always use subprocedures in any new RPG programming. What I don't like about them is they are not entirely isolated pieces of code as they should be. In C, the file (if declared in the main procedure) is never global. Also, any variables declared in main are not global. You do have the option to make these global outside of main if you wish. This is not the case with RPG. All file fields and all main procedure variables are ALWAYS global. So, passing parms from the main procedure to a subprocedure is redundant. I do use the parmater feature to keep the code understandable and easier to maintain, but it is not required when calling from the main procedure. The only true subprocedure funtionality occurs when you call one subprocedure from another. I do make a habit of prefixing all variables in the main procedure with gv_ (global variable) and all varibable in any subprocedure with lv_ (local variable). IBM should fix this "global" issue in RPG.

[R.Cozzi]

Subprocedure Basics

I see your point. In C, if I code this:

 void main() { char myVar; foo(); } void foo() { int nCount = 0; ... } 

I can not access myVar from within foo(). But if I code this:

 char myVar; void main() { foo(); } void foo() { int nCount = 0; ... } 

I can access myVar. I suppose it depends on one's perspective. In RPG IV, if I code this, I get similar results:

 H D myVar S 10A C eval *INLR = *ON C callp main() P main B D main PI D nCount S 10i 0 /free foo(); return; /end-free P main E 

Certainly there are a number of other issues with the poor implementation of RPG IV that would bother a non-C programmer. But I don't think this is one of them.

[Guest.Visitor]

Subprocedure Basics

Hi Bob! Great article! Here is a sub-procedure question I've been wrestling with... I used a sub-procedure to edit some fields on an DDS screen in an interactive program. If the field is invalid the RI and PC attributes are set on the screen. I've conditioned the attributes with an indicator. What I can't figure out is how to have the sub-procedure update the global level indicator set so the screen indicators are turned on correctly (setting indicators in the sub-procedure only seems to affect the sub-procedure level indicators). Is there a way to do that without passing an array into and out of the sub-procedure, or are sub-procedures not the way to go in this case? Thanks, Paul

[R.Cozzi]

Subprocedure Basics

If you move to the INDDS (Indicator Data Structure) instead of the *INxx method, you should be able to "set on" an error condition within your subprocedure. Simply code INDDS(myINDDS) or similar on your File spec. This is similar to coding an INFDS keyword. Then create a data structure that is 99 bytes in length. That data structure (whose name also appears on your INDDS keyword) now represents the indicators used in the display file. That is, position 23 of the INDDS is indicator 23 in the display file. So, for example, if you code something like this:

 FEDITCUST CF E WORKSTN Indds(myIndDS) DmyINDDS DS D fldErr 1N Overlay(myIndDS:23) 

You can access FLDERR (which is now mapped to indicator 23 in the display file) from within any subprocedure in "this" source member. However, when you use INDDS, you can ONLY access the display file's indicators using the INDDS subfields. Setting on *IN23 when an INDDS is used, will have NO impact on the display file.

[brianmay]

Subprocedure Basics

Have you tried defining the indicators into a global data structure? For Example: Then you wouldn't be trying to set *in03 in the subprocedure, you would instead be setting the global variable EXIT in the subprocedure. Plus you get meaningful names for your indicators. I have not tried this specifically but based on your description of the problem this may work for you. Let me know how this works out.

---

Code

[brianmay]

Subprocedure Basics

I think Bob's example and mine are accomplishing the same thing. I was actually not aware that the keyword he used worked to do the same thing.

[lance napier]

Subprocedure Basics

The "NoMain" H-Spec directive seems to eliminate several of these issues. I tend to go that route for "heavier" subprocedures. It isolates the file buffers from any Main program's file buffers. A NoMain subprocedure does have "global" variables, but instead of being accessible from other sub procedures, they act as static variables that retain values between subprocedure calls...which at times is extemely useful.

[H.Boldt]

Subprocedure Basics

Bob wrote: "Certainly there are a number of other issues with the poor implementation of RPG IV that would bother a non-C programmer." Care to elaborate on that point, Bob? Cheers! Hans

[Guest.Visitor]

Subprocedure Basics

RPG programmers still don't quite understand subprocedures Bob, don't be discouraged. Here, we have a 15 year experience programmer that still codes:[*]Double assignations (see example below).[*]Double comparaisons (see example below).[*]Reversed, illogical comparaisons (see example below).[*]Unindented lines in FREE format.[*]All upper or all lowercase variables and opcodes.[*]Endless loop sucking +95% of CPU.[*]RETURN without setting on INLR.[*]And so on... So, you think that "senior" programmer will bother learning subprocedures? Actually, I hope not.

---

Code

[Guest.Visitor]

Subprocedure Basics

Hi Bob! That is an elegant solution. It should work great. I need "upgrade" my copy of your book to version 4! Thanks, Paul Stagnoli

[Guest.Visitor]

Subprocedure Basics

I really don't get to code much these days, but there are times, perhaps virtually every sub-procedure, when I would like to specify in a sub-procedure that it can not access any global variables. In other words, if I use a variable in the sub-procedure I have to declare it, so I don't forget a declaration and accidentally use a global field. I guess separate source file solves this, but that is more work. I suppose in some ways I'd like to see the default that sub-procedures can't access global variables and you have to add a directive to say that they could. Or maybe it is getting late and my mind has gone...

[MQueue]

Subprocedure Basics

I think that we shouldn't be complaining about global variables, they are doing what they are supposed to do. We should be asking for local variables to the main procedure. Perhaps any variables defined before the main procedure interface would be considered global and those after would be considered local.

[R.Daugherty]

Subprocedure Basics

If what I read here about a subprocedure called from a subprocedure not having axxess to globals (and I don't know if that's true or if I misunderstood), then create an interface prototype same as your subprocedure prototype and precede the name and parms with i_. Call the i_ subprocedure and let it call the subprocedure. The interface subprocedure could be used to do things where access to globals would be desirable, such as perhaps error handling on return from the subprocedure. The original subprocedure it calls could not then be modified to add in access to globals, if I understood correctly. rd

[H.Boldt]

Subprocedure Basics

SamL wrote: "... I would like to specify in a sub-procedure that it can not access any global variables." RPG's current scoping rules are pretty much consistent with practically all other compiled languages. Cheers! Hans

[R.Cozzi]

Subprocedure Basics

Hans, No. I don't think we need to have another thread on feature syntax or implementation that goes nowhere. But thanks for the offer.