Still another example of the human factor being one of the greatest hindrances in solving computer problems - the willingness to see what one expects to see and to make assumptions.

I was writing a report that required me to accumulate data into arrays in the program, which, associated together in a data structure, could then be sorted appropriately with a SORTA statement. Below this, I had defined a separate, somewhat unrelated data structure.

In the array data structure, properly defined by the way, was an account number, followed by a short name. When I printed the report, to my surprise I found the account number slopping over into the short name and practically missing in the account number field

I have WDSC, the PC program that color codes fields and opcodes and creates outlines of the code, including a cross-reference of the fields in the program. The cross references indicated only one spot where the account number and name fields would be updated. The update was airtight, as far as I could see, when I ran the program in debug. But at the point just before the second element of the arrays were to be updated, the first elements of the arrays were already changed!

I then looked a little more carefully at the “watch” facility of the debugger, which allows you to tell the debugger to tell you when the value of a specific field changes. After the first element of the array was filled, I told it to watch for when the first element of the account number changed. I then told the program to continue. Then the cursor stopped- at my input file definition!

“Now, what’s going on?” I said to myself. The file was externally defined, but one field from the file was used in the data structure below the data structure defining the arrays. I looked at that data structure, and everything seemed to be in order. I checked other things, and I came back to that data structure and puzzled over it. And then I saw. The line (with the DS in it) that forms the initial definition of the description had an asterisk in column 7 - for some reason along the way, I had commented the line out and neglected to remove the asterisk when I was done.

With that asterisk in the definition line, its data structure fields that followed became associated with the array data structure above. The field thus overlaid the first 11 bytes of the data structure array, which included the account number and name. The field was read in, and the arrays changed.

Even with the color coding of the editor, I completely missed the asterisk. I had seen what I expected to see - the DS in the appropriate column. I missed the asterisk. Now, one could say that this is an argument for using the // freeform notation for comments and devising a new, freeform, keyword style form for field and data structure definition. But there is more to it.

I would submit that, no matter what precautions we take, the human factor will come into play. At some point, no matter what notation we use, the problem being handled will become sufficiently complex that the human writing the program will start making assumptions so he can handle the volume of concepts and data coming in, and he will see the concepts in his program that he expects to see- even if they are not there.

Sometimes it’s best just to take a break.

In our small town, the local post office made a request of the townspeople that they install mailboxes at the curb so that mail can be delivered from vehicles rather than hand-carried up to the house. (This request has not been well-heeded, but that is another issue.)

For many programmers, especially those with normal manual skills and brains, this would not be an earth-shaking task. My programming teacher, for example, could not only program, but he could change a transmission, remodel his basement, bake cheesecakes for sale to restaurants, and brew his own root beer. Not me. My manual skills are minimal; I can do many things that others can do, but not as well, and it takes me a lot more time.

Anyway, I asked the reasonable question, “Where exactly should the box go?” The directions from the post office, to a normal person, may have seemed clear: “The box should be 6 inches from the curb, and the bottom of the box should be 42 inches from the ground.” But the problem: The curb does not rise from right angles from the street. The curb arcs about 90 degrees, so the the top of the curb ends about 7 inches horizontally measured from the bottom of the curb. In other words, the top of the curb is already 7 inches from the street. Do I hang it 1 inch over the edge of the curb to get 6 inches from the street, or do I put it 6 inches from the top edge (13 inches from the street)? The top of the curb is about 7 inches higher than street level. Do I put the box 42 inches from street level (35 from ground level) or 42 inches from ground level (49 from street level)?
My wife asked the maillady. She said that she thought that it was 42 inches from ground level. ( An opinion, not a ruling. No help.) The post is designed to be driven into the ground. After obliterating the first inch or so of the post with my sledgehammer, I sawed off the ruined post end, dug the hole and put the post in. Now that the post was in the ground and the adjustable mailbox support was in place, I looked more closely at the instructions that came with the mailbox post. It said, ‘The bottom of the mailbox should be from 41 to 45 inches from street level; check with your local postal service.’ Mildly better; but it gave me a four inch range, and copped out by telling me, in the end, that the post office was the final authority.
I can just see me writing a program with that level of lack of precision. In effect, I am being asked to wing it. Unless you are writing a program for your own amusement and edification, when you are writing programs YOU CAN’T WING IT! You are not allowed to make assumptions. Almost every mistake I have ever made as a programmer has been a result, at some level, of erroneous assumptions, whether at the coding, testing, or implementation level. In other words, mistakes come in programming when you make human assumptions, when even for just a moment you forget that the program, and therefore the computer, does what you TELL it to do, not what you WANT it to do. For most programs, especially when being used at a business level, “ALMOST CORRECT” IS NOT GOOD ENOUGH.
This is especially true when dealing with financial applications. In my experience, the best person to talk to when developing specifications for a program is an accountant or other financial specialist. They seem to have a special appreciation for precision, even if they don’t know a lick about programming computers. And if a report is $10 off, or even 10 cents off, they want to know why. And that is a good thing. I appreciate that.
I think that most programmers can relate to what I have just said. What amazes me is that you can have people who can deal with uncertainty in most other tasks but don’t tolerate it in their programming (my teacher, again, being an example). I need strict specifications in almost everything in my daily life. ( I once spent 15 or 20 minutes trying to decipher a wordless, picture-only description of how to install windshield wiper blades.)
So how did I resolve my problem? I put the mailbox about 6 inches from the top edge of the curb (about thirteen inches from the street) and about 46 inches from street level (about 39 inches from ground level). Why? Because, since the box will probably never be filled from a vehicle at street level, I should do it for the walking mail carrier. I winged it. Fortunately, the height can be adjusted later, if needed.
All very imprecise. And all very unsatisfactory.

I think of things to put into this every day while I’m at work. Unfortunately, I’m at work when I get these ideas, I don’t make a note of it, or I get too tired when I get home, and the idea evaporates.

One idea that has managed to sustain itself until this evening was an observation on the state of programming in the real world – that is, outside my insulated IBM-i world. Of necessity, even my client must run outside programs and communicate with the outside world, and that is when the sadly amusing state of the computing world presents itself.

I listen as others talk about having to get new systems working on the new Windows 7 boxes. I listen to them go through the song and dance about installing this driver or that, and how it becomes difficult to keep the existing programs running when you get new hardware or install new software or both. After a while, you notice that it’s a new rendition of an old song with new singers and a new group of orchestras.

In the IBM-i world, of course, this stuff is nonsense. We are currently running programs that were written back in the 70’s and 80’s. With this IBM minicomputer (as it used to be called) family, it made no difference. The programs might need to be recompiled when you changed machines, but you didn’t need to create a new version of it- you only did it if you wanted to. No wasted effort. Nothing about the programs had to be changed if the operating system changed versions. But in the Windows world (and I believe in the Linux world too), there are no such guarantees. This always puzzled me when I looked out at my Windows.

And it has touched my world. I played a little bit with VisualAge RPG, and one of my coworkers ran with the idea and wrote an entire system, albeit a relatively small one, using VARPG to talk to our AS/400. (I know, I know. It’s not what it’s called now, but it’s the name most people in the industry identify it with.) We thought it was a very slick piece of work, even though we were aware that IBM wasn’t exactly pushing it. All we knew is that it was a very easy way to leverage our RPG skills into the Windows world. The users loved it.

But now, as time goes on and we get Windows 7 machines in, we have to make sure that if the system goes on a Windows 7 machine, it must be set up to run in XP-compatibility mode. But how long will that last? How long will it be before another “advancement” in Windows takes that option away from us? How long before it no longer becomes “cost effective” for Microsoft to have an environment in which our programs can be run? Then we either have to rewrite them in another language, or we encase them in a virtual machine where it no longer matters what the outside world (operating system) is. I suppose I should be thankful that we at least have that option.

And you can tell that the mindset of the computing world in general is that somehow this is a good thing. Throwaway software. They worry about 32-bit and 64-bit software and the incompatibilities inherent in them. But it’s “progress”. I call it wasteful – but who am I? Just a grunt programmer in an increasingly less popular computing ecosystem.

Sorry, but I don’t have any solutions. I hope somebody does.

I could not hope to make much of an impression on that forum and accomplish anything more than stir up the pot of contention. It is much better to make a one-sided argument here. Anyone who cares to argue may feel free to do so.

The matter of the naming of my favorite machine is to me a matter of importance. As some in that discussion pointed out, that machine continues to be called AS/400 even today, even though IBM gave up on that name a long time ago; but the name still appears in IBM documentation along with other names for it (iSeries, for example) that IBM has given up on.

The Ford Motor Company long ago created a vehicle it called a Ford. It also makes, or has made other brand names like Mercury and Lincoln. The Ford Model T was a roaring success. When the time came to upgrade its model line, did the company take the attitude, “This model will look nothing like the Model T, and certainly nothing like the first cars Mr. Ford created. We don’t want people thinking of those old cars when this new one comes out. We need to call it a Henry! Or perhaps use his initials- the HF1900+”? No, they recognized the value of a brand name. To give another example, very soon after they discontinued the Ford Taurus, they brought the name back and gave it to another car, to give that car credibility.

To call the machine we use an AS/400 is recognition of its stability, which is likely a function of both hardware and operating system software. Only ignorant people outside the computer business would seriously think that calling it by its original name would imply that it only works in a dumb-terminal environment. I prefer to think that people in the computing business, in the world’s IT departments, are not that stupid. It’s a computer, for heaven’s sake. We can make it do whatever we want it to. People who run Windows XP, Windows Vista, or Windows 7 do not expect to encounter the General Protection Faults they encountered in Windows 3.1, just because they are all named Windows. If people who think like that are actually in responsible positions in the IT departments of their companies, I fear for the future of those companies.

That is probably enough about marketing stupidity. I am not a marketer, and I have not had training in it. It just seems obvious to me that if they felt there was such a burning need for a name change, they could have come up with some name that held onto the good reputation and name recognition it had engendered. Perhaps some variation that held onto to the “AS” prefix.

Readers of past entries may perhaps be aware of my feelings on some other topics I mentioned, like free-format languages. The C language, for example, is one of the most non-intuitive languages I have ever looked at. Its only claim to virtue is its popularity, which stemmed from from the fact that C, which really is an “old” language, came riding in as a free language used in association with Unix, and its use was seeded way back when by free distribution to college Computer Science students.

Free- format, as represented by C and other languages – as well as freeform RPG- is not a virtue in itself. See my earlier discussions on this subject.

It has been a problem that RPG is viewed as an IBM midrange language only. It may be too late to dispel that impression. I think it would be a great idea if IBM would release VisualAge RPG to the open-source community. The community would expand its use with a whole lot more vigor and enthusiasm than IBM seems ready to do. I think they would have an Internet HTML-style interface ready very quickly – much more quickly than IBM could or would by itself- and IBM could borrow the ideas back for use with the midrange box. The file access operations even now available in RPG (fixed format or free) are much more rich and elegant than just about any other language. Another language often used for data access is SQL; while I like its ability to pull together data sets, its single record access syntax (not to mention actual speed) to me seems positively kludgy compared with RPG.

But what do I know? I’m just a grunt programmer in a small town in the center of the U.S., old enough to retire, though I probably won’t, as least voluntarily, for a long time. My range of experience is nowhere as wide, and my education not nearly as deep, as that of many whose opinions I read and often value, though I have been in the business for over 30 years.

I view RPG pragmatically; compared with any other language I can conceive of on the midrange, it is a supremely elegant file access and data manipulation language, especially in its RPGIV incarnation. Any further attempts to make it look like another language like Java or C or Pascal would be positively a waste of time and energy. It is bloated enough already.

I think there is no reason why RPG could not be known and used by a wider range of the computing community. I can only wonder why this has not been so. People will not come to the IBM midrange to use PHP or Java. Programmers need to understand the virtues of RPG. And I can say that even though I haven’t the faintest idea how to go about doing it.

If someone does not do something to encourage the use of RPG, it will mean the eventual asssimilation of the IBM midrange (read AS/400, IBM i, iSeries, or whatever you want here) into the IBM conglomerate, since RPG has been so intimately connected with the individuality of the IBM minicomputer since its inception. The oldtimers will have to support RPG until it fades away, and I may be the last RPG programmer, being called in to fix one last program, to determine where that last GOTO goes to.

I don’t know why, but just out of the blue I started to mess around with the service program concept. I must have 15 or 20 variations on date conversion routines: GTOJ for MMDDYY to Julian, ISOTODOW for inputting an ISO date (CCYYMMDD) and outputting the day of the week, and ISOTOVBG for inputting ISO and outputting a spelled-out date (in the format September 30, 2010) are just a few of them. Somehow I guess I felt that there was a natural grouping evident there that ought to be respected.

So anyway, I began exploring service programs a bit more. I think my main objection to modules was the fact that compilation would be a three-step process- compiling the two modules separately with CRTRPGMOD, then using CRTPGM to create the final program. I considered this to be an incredible nuisance. But I pressed on and put all my date modules into one service program. I then discovered that there was a way in the header specifications to use a “binding directory” to join the main program to modules. I found out how to put service programs into a binding directory, then reference the modules from there.

The final step was freeing myself from a misconception about the use of service programs. The article I was using for reference only referred to the use of CRTPGM. I found, though, that once the binding directory reference was inserted into the H spec, I could use CRTBNDRPG, just like I always do, so it could be a one-step compilation again. This was important beyond simple ease of use, because a number of other programs I had written, including my file/program cross-reference system, provided for recompilation of programs when requested. Before, the few programs that had external subprocedures always bombed on the CRTBNDRPG compile, and I could think of no easy way to create the proper CRTRPGMOD/CRTPGM combinations automatically. That is partly why I had retained the old CALL/PARM syntax, so I would not have to deal with that issue. Now, my problem has been solved.

So maybe there is hope for me yet.

At my place of work, I continue attempting to gradually upgrade the system. In addition to my assigned projects and troubleshooting, I am attempting to use more modern techniques; but I find it interesting to look back and see what things I have tried and not tried to do.

One thing that comes to mind is that I am no longer determined to find a way to gradually move code to free-format. If I write new code, it will probably be in RPG-free; but I am no longer attempting to translate fixed format to free. The job is just too daunting; so many of the old programs are just hideously loaded with indicators, and to do a direct conversion, using Linoma’s RPG Toolbox, creates code that would, especially to a neophyte, be even more confusing than its fixed format parent. With proper use of the toolbox we can eliminate left-hand indicators while leaving it in fixed format, and the tool does a very nice job of cleaning things up.

In another context, I am making changes that effectively are advancing beyond RPGIV as presently constituted. Using IBM routines CEESCEN, CEEDAYS, and CEEDATE, I am trying to free the system from its self-imposed reliance upon a century that runs from 1961-2060 for 2-digit years, as well as the ILE RPG range of 1940-2039 for 2-digit years. The boldest move, of course, would be to change all date references in the data files to at least an 8-digit year, if not actual date formats; but in ancient code from multiple systems, that would take a prohibitive amount of time to convert hundreds of files and programs to do this. What I have done instead is create a number of programs based upon the IBM programs above to quickly do date conversions. In doing this, I am implementing a sliding century, such that the two-digit dates will always reference a century that references the current year as the 40^th year of the century. Currently, this means that my floating century is 1971-2070. In ten years, it will be 1981-2080.

A typical call would be: To convert Gregorian (MMDDYY) to Julian, we would call:

CALL ‘GTOJ’

PARM ING 6 0

PARM JUL 5 0

You may note that I am using the RPGIII/RPG400 style of calling the program rather than using the one-line form: CALLP(ING:JUL), which involves the creation of appropriate prototypes. The program GTOJ, for instance, does consist of a module DCONV, which sets up and runs the IBM routines, and module GTOJ, which sets up the input and output for DCONV. They are then combined into program GTOJ. All the routines ultimately use DCONV.

However, I could not see the point of the extensive housekeeping involved in making the programs that call GTOJ and the other programs modularized. You, of course, have to create prototypes for each of the programs (about 15 of them, at last count). Of course, I could put them all in one service program, which to my mind creates another layer of unnecessary complexity. The chief justifications for this seem to be performance and the ability to catch inconsistencies between parameters of the called and calling programs. To me, these are not sufficient reasons. In this installation, performance will never be an issue. Trust me. Our new machine (stupid word processor! I can’t put our favorite machine’s name here – OpenOffice keeps trying to capitalize it) runs at least 10 times as fast as the one it replaced. As for parameter checking, any errors last until the first test is run, after which they are corrected.

Another thing that I have cooled on is attempting to get away from MOVE, etc , in existing code. New code that I write contains very few MOVEs, except for enabling date arithmetic. I just don’t see the point in changing existing code to remove MOVE, unless by doing so I can make the code clearer. IBM has not implemented MOVE in freeform, so I don’t see a meaningful amount of existing RPG code being moved to freeform. This means that any RPG neophyte is going to have to learn to deal with both freeform and fixed RPG formats in his maintenance programming.

So time marches on. We continue to watch the progress of IBM with its initiatives regarding RPG, and we wait to see what impact it will have on our day-to-day work. In a small installation like ours, I don’t think we will ever be cutting edge.

Such was the case a few weeks ago. I was debugging a program, and I wanted to to check the results of a basic calculation. I had changed the processing to no longer use a particular field. This field was defined in the input specifications (it was not externally defined). As I stepped through the calculations, I wanted to check the field, so on the command line I entered EVAL FIELD1. The result? It was blank.

I said to myself, “This is ridiculous- it can’t be!” It was part of the key to the file, and the file had no blank keys. I checked the value of KEY1, which included FIELD1 (that is, it included the data in the record encompassed by FIELD1. It looked normal. This was exasperating. I know that data in input specifications are stored in different areas of memory, even if they describe the same spot in the data record. But the field was blank. There were other fields that encompassed the same record space; some were blank, some weren’t.

I was vaguely aware that there was some sort of keyword in the H specifications you could use to eliminate unreferenced fields. But that would mean that I shouldn’t be able to debug it at all; it should give an error if I tried to EVAL it. And I didn’t use that keyword. I had one of my fellow programmers look over my shoulder as I ran the program in debug again. He didn’t have any idea what was going on either.

After all of this, we brainstormed a bit. I had no reason to suspect it before, but we thought: what if it is not showing up in debug because it is not being used? We could find nothing in the IBM RPG language documentation that something like that is done; but I inserted a dummy calculation: EVAL FIELD1=FIELD1.

Voila! The field now showed up, filled with data, in debug.

The most disagreeable part of it all was that I couldn’t find this behavior described anywhere in the documentation. I spent a little time Googling the situation – and sure enough, others described this behavior of the debugger. Apparently it is some kind of attempt to optimize the debugger. If you don’t use the field, the value is not filled in the debugger.

My reaction was, “Why bother?” Why assume that, just because another line of code doesn’t reference it, that I’m not interested in it? (This is an old program, by the way.) If the field is part of the file’s definition, it should be assumed that I’m interested in its value. I haven’t been able to find the documentation in a text document that describes how to use the debugger. The documentation may say something about it – if there is documentation. I couldn’t find anything in the help text for the debugger that described my situation. And I would think that a debugger, which deliberately allows you to sit at a line of code as long as you want, would be the last and least thing you would need to have optimized.

But all of this speaks to a larger issue. Is this system getting too big? Is there any person around that actually knows everything about the behavior of the RPGIV compiler and its supporting programs, like the debugger? I don’t mean someone who knows where to look for the information (assuming of course that it’s even all written down), but someone who actually knows all this stuff, right down into all of the nooks and crannies, like this thing with the debugger, where some programmer or low-level committee apparently arbitrarily decided that we didn’t need to see the value of an unreferenced field in the debugger? If such a person exists, hide him from the world for six months and make him update the manuals so they include everything IN A COMPREHENSIBLE AND COMPREHENSIVE FORMAT.

I don’t pretend to know the answers to these questions. I don’t pretend to know the solutions to these problems. Maybe I’m just stupid. Maybe I just don’t know where to look. But I have for some time labored under the delusion that I have some measurable level of intelligence and that it shouldn’t be this hard to figure these things out.

This is a rant without a suggested solution. I can’t write my own compiler or supporting documentation. But it just strikes me that when Niklaus Wirth and a colleague can write a non-trivial graphical operating system (Oberon) in just over 12000 lines of code in under 200K of space, other people just as smart could make these systems we work with (possibly) smaller and (certainly) more comprehensible. Maybe it’s too late. I hope not.

Batch file processing used to be the way to process data; but eventually the report became less important and the screen more so. Now, as SQL is used more and more, with SELECTs and the use of a cursor, pseudo-batch processing has come more into vogue.

With that in mind, we felt it was time to take a radical step to make batch processing more elegant. We have implemented in the latest release of RPGIV a new facility we have chosen to call “the RPG cycle”.

With the RPG cycle, by declaring a file (using new file descriptors in the F specifications) as “primary” or “secondary”, you no longer need to issue explicit READ instructions. The compiler assumes you want to read the file or files from beginning to end. If only one file (primary) is used, you don’t even have to tell the system what file is being referred to. If a secondary file is also used, you use numbered Boolean variables or flags to identify a calculation as being associated with a particular file.

We have also made it possible for the programmer to designate up to nine subgroups for totaling and other calculations associated with the subgroup. If a field designated as a subgroup identifier changes in value, the input data is held in buffers until calculations affecting that subgroup and all lower level subgroups have been completed in ascending level order (from 1 to 9). There is NO need to save data in “hold fields”; the system handles all of that. These field changes are known as “level breaks”, and the calculations associated with them are called “level break calculations”. The changes are referenced or indicated by Boolean variables L1 through L9 (L standing for level). “LR”, now used to designate end of file (Last record) will activate all previous calculations and output for all levels in ascending numerical order.

You can process files one after the other, or you can emulate SQL joins by associating related fields in the files with another Boolean variable called “matching record”, or MR.

You can still use READ and CHAIN to process files, without reference to the cycle; using the new features of the cycle is entirely optional. You can also, within the cycle, read other files using CHAIN and READ operations.

The beauty of the new process is that you don’t have to save the “level break” fields to process group totals. The system takes care of all the details. We have thus created a powerful, flexible system for batch file processing.

Early reports from beta testers indicate a high level of appreciation for, and excitement about, the possibilities of the new process.

Another new feature that has had programmers excited was enhancement of the printing functions of RPG. Now that PDF support has been implemented, the fact that printing is still important has been given more emphasis.

We have been rethinking the whole print process, in an attempt to make it easier. In particular, it was felt that page overflow could be handled more elegantly. With this in mind, a new concept called “fetch overflow” has been implemented.

Suppose you have heading output that depends upon your overflow indicators, defined as Boolean variables OA through OG, plus OV. With an appropriate entry in your output specifications, you no longer have to test for overflow in your calculations and write code to generate the output. The system checks whether overflow has occurred when the detail output is about to print. If it detects the overflow flag on, it outputs the heading lines designated to print at page overflow, then prints the detail line that triggered the process.

If you set on the overflow flag in your *INZSR subroutine, your first page headings will print the very first time a detail line set for “fetch overflow” is encountered. Page control then becomes almost completely automatic. You no longer have to use EXCEPT output to print headings.

Of course, you can still generate headings by testing for overflow manually, or you can count lines on the page. RPGIV retains flexibility in this area.

We are extremely proud of the innovations in this release, and we are confident that the user community will also be happy with them.

The IBM RPGIV Compiler Team

Update: April 15, 2010

Reaction to the upgrades has been enthusiastic, even exuberant. A typical response has been “We love it! It’s great! RPG READ and SQL DECLARE CURSOR are so 20^th century.”

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.

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.