Problem solve Get help with specific problems with your technologies, process and projects.

Coding forward, stepping back

New programming techniques have their advantages, but sometimes older methods better fit the bill.

I understand that the only constant is change, but having acknowledged that, change is not necessarily for the better. Coding styles change. Certainly, my code today doesn't look like the same code I used on the S/3 Mod 15D. And I expect it to change even more in the years to come. I am also reconciled to the fact that sometimes you have to take a step back to make a leap forward.

I have seen Jon Paris and Susan Gantner's articles on procedure prototyping. I have read Cozzi on coding recommendations. They all rate high on my list of authoritative sources for iSeries application development. In the milieu of technical publications, these people get high marks for style. Sorry, production deadlines do not recognize style points. Not even from the Russian judge!

Free-format RPG, or fixed-column RPG? Does anyone out there really believe that your customers (programmer types, these are the people you refer to as users) give a damn which format you chose to use to develop applications? I recall reading an article on how far superior procedure prototypes were to parameter lists. I've a question for anyone who wants to debate the point. When presented with a working application, can you tell by looking at your screen whether the application presenting the display used a parameter list or a procedure prototype? (Neither can the application customer.)

Is it technically superior? Does it execute faster? Moore's Law is not at its limits, and with HP's announcements in February on 'cross-bar latch' technology, it suggests those limits won't be exceeded for years to come. The issue of working faster is not an issue. Is it easier to maintain? Does it produce code that is easily interpreted and modified? Because the best return on investment in any software endeavor is ease of maintenance. You do not want to trade machine throughput for programmer throughput. Making a process faster for the machine at the expense of lengthier maintenance is not a good trade in the life cycle of the application.

Let's explore a real-world, not-for-a-trade-publication example.

This is just a test. You have 1 minute to look at the following source code and determine the following:

  1. Does it invoke an external program or a bound procedure?
  2. What is the system name of the process being called?
  3. Which arguments are input to the process?
  4. Which arguments are received as output from the process?
  5. What are the attributes of the variables?

409.0 GetFunction(fpgmid:fpnlid:fkeyds:fkeyid:fmacro);

This is an example of a free-format RPG application that passes parameters to an application and expects some results in return. Yet this instruction tells you virtually nothing of itself. This is recommended practice; free-format; prototyped. It doesn't look anything like RPG III. Certainly, anyone programming in Java or JavaScript would be more comfortable with the syntax than an RPG developer circa 1986. Is commonality one of the goals of application development? (Actually, yes, there is a payback.)

It's time for another quiz. Take a look at the code below. You have 1 minute to look at the source code and determine the following:

  1. Does it call an external program or a bound procedure?
  2. What is the system name of the process being called?
  3. Which arguments are input to the process?
  4. Which arguments are returned as output from the process?
  5. What are the attributes of the variables?

0404.00 C                         CALL      'ISD570CL'                       
0405.00 C                         PARM      FPGMID          PPGMID            10
0406.00 C                         PARM      FPNLID          PPNLID            10
0407.00 C                         PARM      FKEYDS          PKEYDS             1
0408.00 C     FKEYID              PARM                      PKEYID            10
0409.00 C     FMACRO              PARM                      PMACRO            45

If you have spent anytime at all as an RPG programmer, it shouldn't take longer than 30 seconds to interpret the code. Save your breath, I hear the 'yeah, but,' already coming from the disciples of the gurus leading us into the future. There are advantages to procedure prototyping, particularly on the machine level. The new format is far more consistent with the syntax of other development languages. (I've had some of my recent code compared to VB. Qualified DS field names used in free-format with BIFs do tend to resemble VB dot notation.)

The new style may benefit the compiler operations and may help leverage the underlying machine processes. In terms of code maintenance, this is an improvement? I have to find the copybook (Copybook? Didn't programmers use that in the 70s?) containing the prototype definition to learn the nature of the process being called, whether it uses EXTPGM or EXTPROC. I have to track down the service program, or bound process, to examine the procedure interface for the exact variable attributes. And I might need to examine the D specs to determine the attribute of the data variables on the procedure call. (The CONST option on the prototype arguments will allow differences between the variable definitions used by the procedure call and the procedure prototype signature. For example, a local variable defined as 7-digits, 2-decimals, may be used as an argument for a parameter defined as 9-digits, 2-decimals by a procedure interface with the use of CONST as an option on the parameter.)

Take a look at the following examples. The examples above have one thing in common. They are all code taken directly from working applications. (Yes, they work, even though I wrote them.) At first glance, it isn't easy to tell the difference between JavaScript, RPG, and Java. They are all remarkably similar. Without comments, they are all equally as cryptic. Is cryptic one of the goals application developers should strive for? Yes, I know, when we move to a completely GUI development tool with drag-and-drop capabilities, that won't be an issue. It seems like I've heard that since 1995.

1.

for (i=11; i>=0; i--) {
  this.gMonth = i;
  this.gMonthName = Calendar.get_month(this.gMonth);
  vCode = this.getMonthlyCalendarCode();
  this.wwrite(this.gMonthName + "/" + this.gYear + "
"); this.wwrite(vCode); }

2.

for x = 1 to 36;                        
   if %subst(arr(x):1:1) = 'A';         
      arr(x) = 'F' + %subst(arr(x):2);  
   endif;                               
   if arr(x)<> *blank;                  
      info(i) = arr(x);                 
      i = I + 1;                         
   endif;                               
endfor;  

3.

for (int i=0; i < columns; i++) {

    rs = getParameter("C" + i);
    if (rs != null) {
      try {
          values[i] = Integer.parseInt(rs);
      } catch (NumberFormatException e) {
          values[i] = 0;
        }
    }
    if (values[i] > max) 
      max = values[i];
}

Yes, this is the 21st Century. But despite having GUI tools, programmers still wind up spending a lot of time looking at, and attempting to interpret, code. If they didn't, trade publications wouldn't count code snippets as one of their drawing cards now would they?

Take a look at the program call in free-format and fixed column again. You can change the nature of the of the free-format statement for the better by assigning variable names that give hints about which parameters are input and which are output. But the question is, how can you enforce such a standard? Writing the naming convention as part of your standards document will get you close, but there is no program mechanism to insure its compliance.

410.0 GetFunction(pgm_In: pnl_In: key_In: ID_Out: macro_Out);

Refer to the fixed format example again. The variable names are immaterial; you could call them Bob, Ted, Carol and Alice, and it does not change the interpretation of the instructions. The structure of fixed-format CALL ensures a standard compliance by its very nature.

0404.00 C                   CALL      'ISD570CL'                       
0405.00 C                   PARM      PGM_in        PPGMID           10
0406.00 C                   PARM      PNL_in        PPNLID           10
0407.00 C                   PARM      KEY_in        PKEYDS            1
0408.00 C     KEYID_Out     PARM                    PKEYID           10
0409.00 C     MACRO_Out     PARM                    PMACRO           45

To be fair, the fixed format code could be made more cryptic. I didn't have to use factor 1 and factor 2 fields. I did not have to define the length of the variables on the PARM statements. But I can. And I did. Other than writing a chapter of a book to describe the event, the instructions are self-explanatory.

Does this mean I'm not going to code using free-format -- that I'm going to eschew using procedure prototypes? No, of course not. There are advantages to free-format code, not the least of which is a syntax that more closely resembles the spoken language (and thus the language we think in). Procedure prototyping does offer considerably more flexibility than fixed-format parameters. All this comes with a caveat, however. With free-format and procedure prototyping, the burden of clarity and consistency is left to the individual programmer. The structures that once helped avoid ambiguity have been removed.

Yes, as Robert Zimmerman once sang, "Times, they are a changin' ". But change is not in and of itself good, or bad. (Does anybody remember New Coke?) Understanding the nature of the changes to an application development tool/language and using those changes to good advantage requires forethought. Just because you can, doesn't mean you should. Unless standards are in place to provide an application development structure that helps a programmer avoid ambiguity, changes are simply changes, and they may actually reduce productivity rather than enhance it.

One last thought: Management is not interested in technology; management is interested in profits. Few businesses will subsidize change for the sake of change.

-------------------------------
About the author: Steve Croy is a programmer at USXpress Enterprises Inc. in Chattanooga, Tenn.


Dig Deeper on RPG iSeries programming

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataCenter

Close