RPG and Programming

My recent experience on the forum on Bob Cozzi’s RPGIV website underlined the fact that I am not in contention for the title of “World’s Best RPG Programmer”. I posed a question that involved the use of APIs and prototypes, and I submitted my sample code. I got my question answered, but not before it was made very clear to me that my abilities as to APIs and prototyping were considerably below cutting edge.

How do you get to be a good programmer? You have to be intelligent, which can mean you have to know when to be as stupid as the computer. You have to be intolerant of errors. And you have to be willing to learn from your mistakes, as you will make thousands of them.

But beyond these basic qualities and attitudes, other circumstances may determine how deeply you will get into the more arcane aspects of your chosen programming language that will allow you to be among the “best”.

For one thing, your circumstances have to be such that you are exposed to advanced programming techniques. This will likely also be a function of your intellectual curiosity. But perhaps just as importantly, your circumstances have to be such that you will actually have a need for these techniques. You may never be in a position where you will need to access user spaces. While you may see some benefit to variable length fields, you may not see any burning need to start using them. And while much of the benefit of ILE is built around things like APIs and prototypes, it may well occur that your site simply does not need a wholesale conversion of code to make use of called procedures.

As it happened, my experience above came as a result of a need for them. Two-digit years are still used on my system. In calculating the maturity date of a 30-year loan written in 2010, I bumped up against the ILE default for two-digit date fields (1940 to 2039) and got an “invalid date” error when I attempted to generate 3/15/40 to represent 2040. To get around this, I decide to use an API I was aware of, CEESCEN, which allows you to float the 100 year range you want to use for the 100-year period in question. This is used in association with APIs CEEDAYS and CEEDATE to allow you to format dates in numerous different formats. (Google the API names for details.)

However, I was not familiar with how to set up the prototypes needed, and as a result I made some stupid mistakes that leaped out at the knowledgeable participants in the forum, especially Bob. But anyway, with some help, I got the prototypes and program calls to work.

But my learning things like these are in response to a specific need. I don’t have a burning need to learn all or even a substantial portion of the APIs available. I simply don’t need them. The fact is that I am getting paid to write production code, not specifically to “learn new things” . And the fact is also that I am not in a position where I can spend a lot of time outside the workplace learning new stuff, since family and other personal needs and circumstances have first claim on my time.

Other people, by reason of education, career choices, and the employers they happened to have, may have had open to them early in their careers opportunities to work on truly advanced concepts that I never was exposed to and likely never will be. Of course, their being smarter than me, not to mention better educated early on, would also make this more likely My task being to maintain and upgrade code that was from the 1980’s and 1990’s in style, if not always in vintage, I will likely be kept busy doing that for the balance of my career. I like to think I’m good, but I’ll never be the best.

But sometimes, to old codgers like me, it’s difficult to know just how far to go. In previous posts I have written about my vaguely negative feelings about freeform RPG, and I have written very clearly about how I feel about IBM’s unwillingness to implement the MOVE instruction in freeform RPG, pointing out how this can only hinder conversion of old code and diminish acceptance of the new RPG dialect.

Case in point, a program I was working on today. I was writing code to implement formatting of a six-digit account number based upon the rightmost 6 digits of an 11-digit number. It was based upon some old code (the usual situation where I work), but the old code was hideous. The old program consisted of about 15 lines of MOVE and MOVEL statements. I said, this has got to go.

So I contemplated the best way to do it. I could set up a data structure and put pieces of the account number into that, using EVALs or MOVEs,with dashes embedded as needed. But that didn’t seem quite elegant enough. I have been working harder to modernize my own code, so I finally broke it down to these two possibilities, as illustrated in this test program. The result I am aiming for is the number formatted as 01-234-5.

     H DFTACTGRP(*NO)   ACTGRP(*CALLER)
     D BACTNO          S             11  0 INZ(99999012345)
     D ACC6            S              8    INZ(*BLANKS)
     D NUM6            S              6  0 INZ(0)
     D ACCW            C                   '0  -   - '
     C/FREE
       EVALR ACC6 = %EDITW(%DEC(%SUBST(%EDITC(BACTNO:'X'):6:6):6:0):ACCW);
      /END-FREE
     C                   MOVE      BACTNO        NUM6
     C                   EVALR     ACC6 = %EDITW(NUM6:ACCW)
     C                   EVAL      *INLR= *ON

One way mixes the old and the new, with an old-fashioned MOVE to the smaller field, followed by a new-fangled %EDITW BIF using a predefined edit word. The other goes full-bore new age, with one grand set of embedded functions. To get the 11 digit number in string form so I can substring it, I use %EDITC with an X edit code, which does the conversion. Next, I %SUBST (substring) the last six characters. I then use %DEC to convert those six characters back to numeric. Finally, I apply the %EDITW function to format those six digits as desired. (I would be interested in finding out about a shorter way to do it.)

But I have a problem with it. In an earlier post, I pointed out that the ability to create long, complex functions in freeform is not necessarily a virtue. The mere fact that I felt the need to explain it here indicates that I am not comfortable with it. The code is short, but I do not feel that it is clear. On the other hand, while the the two-line version using MOVE is short and sweet, and uses a BIF, it would force me to get out of freeform to use the MOVE; stylistically, that also seems wanting.

Since the thrust of my thinking is in trying to modernize the code so future generations of converted C programmers won’t be freaked out by the C in column 6, I am leaning toward the one-line version. But I don’t like it. It’s ugly.

I was going to discourse on another topic, but a response to Buck (to whom I apologize, along with Bill, for being derelict in checking my site’s e-mail), who commented on my previous post, demands a reply. He feels that lack of formal education, while being a contributing factor, is only a contributing factor; rather, it is the midrange habit of being exposed to one programming language.

Actually, I am inclined to agree. The isolation in RPG is real. But we also do well to consider the background of the situation. The earliest IBM minicomputers, the System/3, had as its programming language RPG II. That was it. Small businesses who wanted that computer worked in that language- at least, I’m not aware of others used on the machine, besides assembler.

When the System/34 came out in 1977, the choice of compilers widened. BASIC, COBOL, and Fortran became available. But still, RPG dominated. I’m not surprised that Fortran and BASIC popularity did not rise. But COBOL was big at the time. However, RPG was already a business-oriented language, so COBOL was not really needed from that standpoint, and RPG was perhaps felt to be more terse and easier to learn. Then too, COBOL programmers were already being kept busy keeping the IBM mainframes humming, so there were probably not an excess of them floating around. COBOL has never been much more than a peripheral language on the IBM midrange; useful probably only to those whose business already depended in some way on COBOL, perhaps having COBOL talent already available.

In addition, and perhaps most important of all, The System/34 had no need to talk to the outside world unless it were to another IBM minicomputer or mainframe. There was no need to handle HTML; there was no HTML, because there was no Internet.

This is not to say that RPG was a perfect language. String manipulation beyond the realm of MOVE and MOVEL was very difficult. The two things the designers never got right until RPGIV came along were string manipulation and date arithmetic- being able to get the date 30 days after today, for instance. (One thing I will never comprehend is why they have never been able to enable multiple dimension arrays. In earlier days in a different environment, trying to emulate multiple dimension arrays was a real pain.)

But since the programmers had no other languages to work with, they bent RPG to their will. They created these plug-ugly array- manipulation routines to piece together strings. And they created complex routines to do date addition and date format conversion. We must not forget the famous “magic numbers” - to convert a date in month-day-year for mat to year-month-day, for instance:

MMDDYY MULT 10000.01 YYMMDD. I am still reminded of the RPG programmer of my acquaintance who, with the help of engineers, created sines and cosines and other functions in RPGII.

Now, there may have been elegant functions created in C for such purposes as string manipulation and mathematical functions. But once RPG routines were developed, the C functions were not needed. It really didn’t matter. They couldn’t use C anyway. If you knew what you were doing, you could write assembler subroutines – but that was it. I don’t think RPG couldn’t even call COBOL programs; at least the techniques were not well known for doing so.

So when ILE came around, much of the motivation for calling the now-available C routines was missing. We didn’t need them. RPG routines were already doing the work. Unless there were some performance considerations, programming managers would probably take a dim view of programmers who ripped out the ugly-but-tried-and-true RPG routines just for their own amusement. One could make a valid argument that those routines were a maintenance nightmare. But unless management had a good deal of foresight, this might be a difficult thing to prove to management’s satisfaction.

And yes, programmer inertia was also a factor. My shop has had IBM midrange machines since the 1970’s, and AS/400s since the 90’s. But the first RPGIV program was written on this system in 2007, by me after I arrived.

But now, the IBM midrange does have to deal with the outside world. My company already has an Internet presence, and we quite frankly don’t have to know PHP or Java or the other languages in vogue in order to make the business work. All we have to do is make sure our Internet provider gets the necessary data. And RPGIV provides the necessary tools to alleviate some of the issues that plagued us with earlier versions of RPG. If we need outside routines like APIs or C or Java or Rexx, they are easy enough to call. I have expressed myself in earlier posts about my ambivalent feelings about freeform RPG.

But mentioning freeform brings us to the topic of: How do our employers find replacements for us fixed-format loving old codgers when we retire? That is a topic for another time.

I have been thinking a bit about how our backgrounds, educational and otherwise, may determine at least to some extent the style we use in our programming and indeed perhaps the language we use.

One of my fellow programmers (about my age) graduated from college with a background in computers. Almost immediately he was able to find a position programming in COBOL, then in ALGOL, which is a block-structured language with a relatively free format. He continued to do well at various positions; ultimately, he came to where I work, with many years of experience in programming, but none in RPG. The style here could be described as a blend of RPGII, RPGIII, and RPG/400; fixed format to the core, loaded with indicators. He learned RPG from the ground up in that environment. Sometime after I came along, he was shown freeform RPG.

I, on the other hand learned RPGII from a book and practical experience. I had no computer background when I started to learn. I was of an inquisitive spirit, though, and I advanced in my use of RPG as the language itself improved. I too ultimately became acquainted with freeform RPG.

Now, who do you think uses freeform RPG whenever he can, especially on new programs? You might have guessed it was my partner- if you did, you’d be right. RPG was actually stifling to him; given the freedom to use free format RPG along with the BIFs that work well with it, he has been liberated. On the other hand, as you may judge from this blog, I just have not seen the light or the point. When I write code for new programs, it is in fixed format RPGIV.

We learned to love the way we learned programming, and so our preference now is to do it the way have always learned it, just better.

Illustrating the point that the way we learn to program is greatly influenced by our programming origins was a discussion I just read on an RPG forum about the significance of certain characters when writing CL (Control Language on the AS/400). Instead of indicating a “not equal” test by the common expression *NE, the code used the combination ^=, where the ^ is really a character I can’t find on my keyboard, but looks like the upper-right-hand corner of a rectangle with the top leg longer than the right. The character, as it turns out, is the “logical not”, a character often used in Boolean algebra.

Now, I don’t know who originated that code. Some experienced programmers, though, just did not know what it meant. Therein may lie a tale.

During the time I learned, many if not most of my fellow programmers were not products of any kind of computer science curriculum. They did not learn BASIC or Fortran first, and usually not COBOL, though this was a bit more common. They learned RPG as their first language. They did not learn “computer science concepts”; many, like me, either never attended college or did so only briefly. They may have started as a computer operator, or maybe at another position in their company. Usually it was a small company; it had the smallest capacity IBM computer available, the System/3, or System/32, or System/34. Something about the programming process intrigued or excited them; they persevered, and they advanced.

As time went on, though, and RPG increased in importance, people with a background in computers and computer science began to program RPG. For a long time, they would prove to be stifled if they expected to program like they originally learned to program in other languages. And where the original programmers may have simply accepted, for example, the RPG cycle, and comprehended it entirely, by the time the System/38 came around, programmers who started learning RPG as RPGIII on the System/38 evidently found it mind-boggling.

I can’t count the number of times I have found a test for LR (last record) in the RPG detail cycle in code (usually written by programmers who came from the 38) using an input or update primary file. Unless explicitly set on with a SETON instruction, the LR indicator will never be on during the detail cycle. A programmer who started with RPG II would automatically know this – it would be a part of his upbringing. A programmer who started with a background in computers later would not necessarily know this. This would cause problems if the programmer intended to base output on this indicator test. Usually it would mean that last record calculations and total output would be missing.

Another difference in outlook comes with file processing. A programmer raised on RPGII (usually in a small shop) doesn’t mind the system reading files (primary and secondary) without him telling it to. But I have noticed in discussion forums that people raised on other programming languages (usually learned in college) seem to get bent out of shape if they don’t explicitly get to do the file reading themselves. They don’t really comprehend that this really is quite an advanced feature, much closer to SQL than Pascal.

It would be interesting to find a survey of programmers that told what level of education they had when they first started programming professionally. I would suspect that as a group, RPG programmers would have a slightly lower level of educational advancement than, say, a C or Java programmer. This would especially be true if they surveyed the most experienced RPG programmers. But then, it is results that matter. RPG programmers do not write compilers – we process information so that humans may comprehend it.

From time to time I read that the language we speak to some extent controls the way we think. Someone more versed in such things may be able to describe how this is true with natural languages, but I have found this to be especially true with computer languages. A recent chunk of code I came across while working on a program at my place illustrates this point.

The point of the routine is to add a particular quantity to a total a number of times defined by a variable field.

Now, to most modern programmers, this is a trivial task. A classic DO loop will do the trick quite nicely. But this code was not written in a modern language. It was written in RPGII, which didn’t have  DO and END opcodes to use.

But first, we will render how the code, as it appeared in the program, could have been coded using DO:
(The field names have been changed. The number of times the quantity would be added is NOTMES; the quantity to be added is TOTQTY; the quantity TOTQTY is to be added to is GDTOT.)

     C                       IF        *IN03=*ON AND *IN49=*OFF
     C                       DO        NOTMES
     C  TOTQTY               ADD       GDTOT         GDTOT
     C                       ENDDO
     C                       ENDIF
     

Now, you read above that it was written in RPGII. Here is how it could have been rendered in RPGII:

     C  N03
     COR 49                      GOTO      EIF001
     C                           Z-ADD     0             X
     C        LUP001             TAG
     C        X                  ADD       1             X
     C*  25 SET ON IF X<=NOTMES
     C        X                  COMP      NOTMES                  2525       <=
     C   25   TOTQTY             ADD       GDTOT         GDTOT
     C   25                      GOTO      LUP001
     C        EIF001             TAG                

But this is not even nearly how the code was written.
In early RPG, apparently programmers were apparently taught to use an indicator to test for every possible condition- a different one for every condition. And, apparently, the concept of a loop did not occur to this programmer. The value of NOTMES could be as high as 5, so, by George, we must test for every value from 1 to 5, and deal with them accordingly. When I dug into the code and got to comprehend what it was doing. I was absolutely stunned. What follows is the code as translated into RPGIV, so the number of lines would be slightly more than in the original code; but the old code looked just as bad:

     C     TOTQTY        ADD       GDTOT         GDTOT
     C  N49NOTMES        COMP      2                                      75
     C  N49NOTMES        COMP      3                                      76
     C  N49NOTMES        COMP      4                                      20
     C  N49NOTMES        COMP      5                                      05
     C*  IN RPGII, NEXT CALC WOULD TAKE 4 LINES
     C   03
     CANN49
     CAN 05
     COR 03
     CANN49
     CAN 20
     COR 03
     CANN49
     CAN 76
     COR 03
     CANN49
     CAN 75TOTQTY        ADD       GDTOT         GDTOT
     C*  IN RPGII, NEXT CALC WOULD TAKE 3 LINES
     C   03
     CANN49
     CAN 05
     COR 03
     CANN49
     CAN 20
     COR 03
     CANN49
     CAN 76TOTQTY        ADD       GDTOT         GDTOT
     C*   IN RPGII, NEXT CALC WOULD TAKE 2 LINES
     C   03
     CANN49
     CAN 20
     COR 03
     CANN49
     CAN 05TOTQTY        ADD       GDTOT         GDTOT
     C   03
     CANN49
     CAN 05TOTQTY        ADD       GDTOT         GDTOT

I’m sorry, but I’m afraid but I don’t have any profound insights as to how that monstrosity could have been avoided; but in a weird way it gets the job done. There is a certain strange creativity about it. The logic is:
1. Add the quantity once.
2. If it needs to be added 2,3,4, or 5 times, add it again.
3. If it needs to be added 3,4, or 5 times, add it again.
4. If it needs to be added 4 or 5 times, do it again.
5. If it needs to be added 5 times, add it again.

The most basic Computer Literacy class in middle school today would teach the better way, but such classes weren’t around then. And for those who learned that early, it’s probably the way they did it for the next thirty years.

Oh, my.

The rather slow acceptance of freeform RPG since its inception has been intriguing to me. For that reason, a recent discussion on  the RPGIV forum has been interesting. Bob Cozzi, a well-known RPG expert, posed a question about how long it took to actually code the implementation of freeform to Hans Boldt, who evidently was on the team at IBM that developed the original implementation.
Hans said that it only took about 1 PM (person month?) to actually code it, but considerably more time was spent in planning. I can believe this. The planning discussions must have been particularly interesting.
One of the biggest things that have slowed acceptance of freeform was the non-implementation of MOVE and MOVEL. This is also the opinion of Cozzi and others in the field. Mr. Boldt touched on this and other issues.
Boldt’s first design included implementation of all opcodes. Others in the group, one in particular, argued vociferously against it. Boldt eventually came around to their way of thinking. As he said, “That design point meant we didn’t have to worry about those goofy multi-part factors.”  (I’m not clear on what that means, exactly. But anyway…..)
Once that was established it was just a matter of deciding which to implement and which not. GOTO was thrown out because, as stated in Nicklaus Wirth’s famous title for Edsger Dijkstra’s article on GOTO, “Go To Statement Considered Harmful”. I could quibble about that, but since it’s been probably 4 or 5 years since I last put a GOTO in a program, there wouldn’t be much point in arguing.
With MOVEL and MOVE however, Mr. Boldt doesn’t understand why people are so attached to those opcodes. He says, “It’s hard to see how these opcodes can be missed given the other options available by free-form opcodes.”
To a certain extent, I agree with his comments. I myself have used MOVE/MOVEL very seldom in the last several years. New opcodes have for the most part been very workable. Using EVAL and many BIFs, I get along very nicely. When EVAL gets a little tedious, I often create data structures to put together data in the desired patterns.
The problem is, I am talking about new code. Old code from the 70’s, 80’s and early 90’s did not have all this neat stuff available. About all you had for data manipulation was MOVE and MOVEL, along with their cousin MOVEA, along with perhaps data structures. From my observations over the years, I would say most programmers did not avail themselves of the help even data structures could provide; they did their work with MOVE(L). We are not talking about an easily disposable opcode like FORCE; we are talking about opcodes that appeared in almost every non-trivial RPG program before RPGIV, and most of the trivial ones. They used the opcodes to change data types (from alphanumeric to numeric and back). Above all, they used MOVE to manipulate strings, piecing together long strings from five or six (or more) smaller ones. One can complain that this is a very kludgy way of doing things, but this is all we had to work with. I would suspect that there are millions, if not tens of millions, of MOVEs in the legacy code sitting on today’s AS/400s (or whatever we’re supposed to be calling them today).
So what do we do in freeform once MOVE is taken away from us? As pointed out in the post I referenced yesterday or the day before, we must choose among 10 or 15 alternatives, depending on what we want to do - which in a sense is a demonstration of the power of the opcode. There is no easy conversion; it is not the same thing as changing  KEY   CHAIN    MASTER  to CHAIN KEY MASTER; . I don’t think even artificial intelligence could do even close to a good job of determining the best conversion; Linoma tried, but some MOVEs are just untranslatable without human eyes and brains to analyze them.
Therein lies the problem. If you rule out MOVE in freeform, a human must determine the best way to translate it to freeform. It simply isn’t financially practical to spend resources changing massive amounts of fixed-format code to freeform by hand, and the utilities available for automatic conversion do not do a clean job. You can use Linoma’s software; you can use Websphere’s conversion facility, which does not handle the MOVE and does not even attempt to do the indentation; there may be other utilities around. In the end, to convert legacy code, you can convert it to a degree automatically, but you will still be left with MOVEs to contend with by hand. You end up with ugly flipflops between free and fixed format that may even be harder to read and deal with than the original fixed format code.
It is very nice to say, that when we modify a program, we will also change it to freeform. But that is a slow way of converting what might be hundreds, or even thousands, of programs on your system. Remember, converting a MOVE to something else is not the same as reformatting a CHAIN; it must be carefully tested.
So, while freeform may ultimately win out, it could have been done a lot more readily if MOVE had been implemented in freeform. The more I think about it, I wonder if someone’s ego got in the way, someone who said, “I am going to teach these plebeians how programming SHOULD be done, instead of using these operations that no other reputable programming language uses.”  (Down, XFOOT, down!!!  Don’t bite him!)
And to think it could have been avoided by allowing the conversion of  MOVE  STRING1   STRING2  to the freeform equivalent:  move   string1    string2.

I didn’t think I’d be considering free-format RPG so soon as a final solution for the current RPG programs on the system at work (some of which date back to the 70’s), but a number of interesting events have taken place.
Our IBM representative made us aware of a software package that accomplishes the conversion of RPGII, RPGIII, and RPG400 programs into true RPGIV. This means (among other things) ditching the left-hand indicators and attempting to really use more modern operation codes. If you are at all familiar with what would be necessary, you can appreciate how difficult this task would be without some kind of automation. The painstaking code changes and testing would be incredible on a code base of any size.
This package is called RPG Toolbox, from Linoma Software.
So we downloaded the trial version, which allows 10 source conversions from another RPG dialect - or even RPGIV that has simply been converted from an older format using IBM’s CVTRPGSRC utility. CVTRPGSRC simply reformats old code into RPGIV syntax; it does not attempt to modernize it. We converted a source member with a lot of left-hand indicators, and we were impressed how it converted into a reasonably neat format without those indicators. What really impressed me was that it would attempt to convert a series of MOVE statements, which was commonly the method used to piece together larger fields, into EVAL statements. This could be a dangerous technique, but the RPG Toolbox utility carefully analyzes the code to make sure it is safe. In the manual, it describes how it makes decisions about code conversion; if one is interested in this product, that person would do well to download and read the manual before making decisions about what the program should do in the course of conversion.
I also had an inspiration- why not use it to convert RPG IV to freeform? In earlier posts, I have declared my reservations about how valuable freeform is. But, if it’s easy, why not live dangerously? So I tried converting one of the RPGIV programs in my file cross-reference system to freeform. The results were impressive. It looked VERY good. The more I looked at it, the more I liked it. So I said to myself, why not convert ALL our code to freeform?
But then my younger cohort brought me back down to earth. He wasn’t so sure that would be a good idea. So we converted the old-format code referred to above into freeform. The results were messy. There was much code that simply could not be converted, often involving the MOVE and MOVEL opcodes. (I have also commented on this previously.) When this happens, the free-format code is enclosed in a /FREE - /END-FREE set of compiler directives and the code drops back into fixed format. Switching back and forth between free and fixed can be maddeningly ugly.
So I have backed off the idea of a total conversion to freeform RPG. But we still feel that converting our code to a clean RPGIV that uses as much as possible of RPGIV’s modern syntax and opcodes would certainly be a good thing; and it appears that it would be relatively safe. We have ordered the software. Where the conversion of a program to freeform would not create too messy a result, we can still convert it.
I was also surprised to learn how quickly the most experienced one on our crew would take to freeform. He first started programming in ALGOL; so freeform is not really that much of a leap for him. He has in the past several weeks written new programs in freeform RPG, of his own free will. My other partner has a Pascal/Java background; so freeform would come “naturally” to him. I am the one who will take some getting used to the idea.

Subfile processing is an integral part of RPGIV data entry and data display. To be a real pro, you need to handle them properly. There are any number of ways to build and maintain them. Depending upon your level of expertise, you can do really sophisticated data processing tasks with subfiles. (Yes, I know that phrase data processing is so 1970’s.)

Dealing with them at my place of employment is an ongoing task. My two fellow programmers, though having much experience in programming, are relatively new to RPGIV. To help enhance their skills, one of them bought the excellent book by Kevin Vandever, “Subfiles in RPGIV”.

One of them was using it to help him build the first subfile program he had ever written from scratch. And wouldn’t you know, his techniques were different from mine! And the author had used my technique when he first started programming subfiles, but he had found a better one. Oh, my.

For the uninitiated, subfiles are a way to handle update and display of data files, by allowing you to display multiple instances of data in (usually) a columnar format, then treat each line as a separate data record. In RPGII, subfiles were not available; to process it, you had to plug your file data into arrays of information, each data field in an individual record linked by being the same array element in multiple arrays.

Anyway, the author recommends a technique that is clean and efficient. He uses the DDS keyword SFLNXTCHG to allow the programmer to flag for further processing data in a record that has been changed. The operating system keeps track of changes, and this allows the programmer to process only those subfile records that have been changed by the programmer. This is done by using the READC (Read Changed record) RPG opcode. Using SFLNXTCHG with an indicator allows the programmer to mark a line of data as “changed” when it processes the second time around. If one entered erroneous data in error, and the program would not accept it, the data would still be marked as “changed” and the record would be read the next time around by the READC opcode, even if the data entry person did not correct or change the data.

My approach, the way Mr. Vandever set aside, is to keep track of the number of records (entries) in the subfile. To process the subfile, I CHAIN to each subfile record by relative record number, whether it is changed or not, and process the data as needed. I can do this as many times as desired.

Why do I do it my way? Because I’m an ignorant so-and-so, I guess- or at least I was when I was learning many years ago how to program subfiles. I vaguely remember attempting to use READC to process only changed subfile records. However, I was not aware of the SFLNXTCHG keyword; and when I would read a subfile record and find an error, I couldn’t see how to tell the system to process the record the next time around. Suppose the screen had five subfile records displayed. I changed two records, and one of them was in error. Once I fixed the one in error and the program looped through with the READC opcode again, it would not pick up the correct one from the previous pass because it couldn’t tell it has been changed! When I saw an example of the CHAIN technique, I realized that it would always work, so I stuck with that technique.

So do I change now to the more efficient technique in the future? Wellll…. probably not. Being a creature of habit, for one thing; and the fact that changing my technique will not gain me all that much and would make the “read subfile” task more complex.

But what about all the unnecessary CHAIN operations, which on a large subfile mean an awful lot more subfile accesses than necessary? If you have read my blog from the start, you might remember when I told about a hissy fit  I had when I worked on a program where a previous programmer read a detail data file by CHAIN instead of READ and increased the processing time by a factor of 10 – from 15 minutes to 2.5 hours.

I suppose that I have been corrupted by the greased lightning bottled in the latest machines. In my file cross-reference program, I load source files into subfiles so that you can drill down into the subfile and find out file characteristics, even view the data in the file by putting the cursor on a file name and clicking a function key. When I tell the system to display source, it can put 9,999 lines of source to the subfile in less than a second. Why sweat the difference in processing one record with READC versus, say, 12 when using CHAIN? In a large installation with hundreds of users on a slower machine, perhaps it would be a concern- but not now. My concerns about performance are pragmatic, not ideological. As I have said before (as a matter of fact, in that previous blog post I mentioned above), I don’t sweat over nanoseconds.

Also, at least with reference to my cross-reference program, using READC is irrelevant. I do not change the subfiles in any way. They are simply a jumping-off point for further processing. I use EXFMT (which means write the format, then accept input) to display them, but only to allow the input of a right-click or a command key or a search argument to use with a command key.

A minor quibble would also be that an edit that relied on READC would catch only errors that had been introduced by the current data entry operator. There is no way to guarantee that the data in the subfile is error-free when it is first displayed, especially if the data is also updated by other programs. If you edit every line, you can check for errors in all the data, including preexisting errors.

So my partners are free to use the new techniques, but I am not likely to choose to do so in the future.

I finally found the article I read back in the 80’s about “Why You Should Learn to Program“, by Chris Crawford, an Atari game developer at the time. Evidently he had spoken on the subject somewhere; afterwards, he put his notes essentially into article form; he then felt it necessary to flesh it out with additional material.

At first glance, though, this seems to clash with the message of Peter Norvig, who either works at or has worked at Google, in his article (which I also find authoritative and based on good research) ” Teach Yourself Programming in Ten Years “. These two articles present somewhat contrasting views of the craft of programming; but I find them complementary.

Mr. Norvig’s view is the kind of view that I would expect of professional programmers. He believes that programming that not something that you can learn from a “Learn Language X in 21 Days” kind of approach. In fact, he even mused that 10,000 hours would possibly be a better view of the matter than ten years.

However, in giving his recipe for learning to program, his recipe, which obviously will involve hard work, mentions a very important first step: ”  Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.”

He obviously believes it should be fun. And so it should. Even if it comes relatively easily, it will almost certainly bring one a degree of frustration, if for no other reason than that you must, for any nontrivial task, explain what you want to the computer in excruciating detail.

Which brings us to Mr. Crawford’s thesis, consisting of three main ideas on why each of us should learn to program:

1. Recreation.

2. To learn the importance of clear communications.

3. “Learning to program will make you a better thinker.”

I leave you to read the article to get the details of his argument.

Where Mr. Crawford and Mr. Norvig differ are in the goals. Mr. Norvig’s recipe is for a master programmer, who could and would be paid well for mastering his craft- even if he still is doing it for fun. Spending 10,000 hours learning to program is serious stuff.

Mr. Crawford, in contrast, recognizes that there are professional programmers who will be paid well for their work; however, you don’t have to be good enough to write programs for money, to write programs. He gives the illustration of the man who takes pictures of the Golden Gate Bridge and his family while on vacation. A professional photographer would likely take a technically “better” picture and put it on a postcard for the man to buy; but he prefers his picture, because he did it himself. A person need not be a master finish carpenter to enjoy doing his own woodwork. As Crawford says, programming is not nuclear physics; anyone can do it.

He recommended BASIC in his article; even he now backs away in this respect from his 1985 recommendation. The Wirthian languages (Pascal, Modula-2, Oberon) might be better choices. There are free Pascal compilers around; if a visual environment is more your speed, try Delphi; you may be able to find earlier versions for free. You can even try Visual Basic, if that suits you. Both BASIC and Pascal were originally designed as teaching languages; if programming interests you, try one of them. (Look for them; Google is your friend.)

The main thing is, the sooner you can get payback for your learning efforts, the better. For me, RPG allowed quick output, quick results at the start. That made up for the times of frustration that could and would come later.

I highly encourage you to read these articles, which give you a good perspective of the entire programming experience. Mr. Crawford, in particular, may just incite you to find out how pleasurable the ability to program can be.

Who is responsible for creating software that works? Where should the responsibility lie?
In large software corporations, programmers will occasionally lose sight of this. A Microsoft e-mail involving Bill Gates and Moviemaker is instructive here.
This kind of situation, of course, is probably not unique to Microsoft. But still, who should be the one in charge of software quality? In this case, someone a lot lower in the hierarchy than Bill should have caught the errors and corrected the problems. And I don’t mean the project leaders, either.
I submit that each and every programmer is responsible for software quality, and he or she should be aware that the software he writes should never just be “good enough”. The software he writes should work as it is expected to work, and certainly not crash when it is being used as it is supposed to be used. This is not to say that your software will be bug-free; that may not be possible to guarantee. The next bug in your program (and obviously, we are dealing with non-trivial programs here) probably just hasn’t been found yet. But programs should not crash and burn under the most simplistic of test conditions. (I’ll never forget the time I double-clicked on the WordPerfect icon on my Windows 3.1 desktop and got an “Illegal operation” error.)
Recently, I was making some revisions to my file/program cross-reference programs. It was a substantial change striking to the source of the data I used in my program. When this was done, whole chunks of my program were commented out, to be removed later entirely once the new code was tested. Errors started popping up all over the place. (Never forget that a “bug” is not some creepy-crawly that got caught in your code; it is an ERROR.) I was actually trying to get work done that more directly relates to my job- which is not to create utility programs. I was trying to get a project done with my utility as an aid, and if it wasn’t crashing the programs, it certainly wasn’t acting as it should.
But I was taking it personally; if I write a program, it is supposed to work as designed. My program may not do everything it might ultimately be able to do; but what it does, it should do right. If I right-click on a program name, it should bring up the source for it- look in the right place for it- not tell me it can’t find it or bring up the wrong one. When I click on a file name in a program and hit the appropriate function key, it should show me the file and field description or even the data; it must not lie to me and say the file is not there, and it certainly should not crash because I performed some subfile operation wrong.
What should be the first line of defense against errors, then? It should be the individual programmer. He should consider errors unacceptable. Bugs should not become “features”. He should be willing to beat on his code, test it by as many avenues as possible. Often it is best to forget you are the programmer and just USE the software as the individual user would. If you test it in “programmer” mode, you may tend to not test it in situations where the logic is more complicated and likely to fail; to save face with yourself, you might test it in “safe” areas under ideal conditions rather than push it to its limits.
Consider it a matter of pride. Beat on the program yourself. If errors are to be found, you be the one to find them, not the user. Consider it a matter of dishonor when a user finds an error. You may not be able to prevent users entirely from finding errors; but don’t let their finding errors be the accepted mode of software quality. Whether the tester be the user or some testing team, make their work as light as possible.
Don’t let “Bill Gates” find your errors. You find them.
Take it personally.