Time Marches On

It has been a long time since my last entry. Much has happened since then. I made two 2100 mile round trips by car back to Michigan, both of them in connection with my mother, who passed away in June at the age of 98. Other personal situations have cropped up too.

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 40th 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.

One Response to “Time Marches On”

  1. Buck Says:

    I don’t ever translate fixed to /free. Fixed RPG is a separate language, with its own nuances. /free RPG is a separate language, with its own nuances. Simply re-formatting it as /free doesn’t magically transform the fixed form nuances into /free form nuances. MOVE is one of those op-codes that is so overloaded that it can be very difficult to understand unless you are intimately familiar with the fields involved. Is MOVE CHAR5 CHAR7 intentionally leaving those two bytes intact, or did the original programmer mean MOVE(P)? Not easy enough to automate, that’s for sure, no matter what toolkit is involved.

    It’s interesting that you don’t use service programs. Yes, they do add another layer of complexity but for me at least, the calculus falls in favour. I probably need to take a step back. I like functions. Rather than code CALL GTOJ PARM PARM, I like to see eval julian = gtoj(mmddyy) I use functions because I think in functions, so the mapping makes personal sense to me.

    The chances that I’m going to use this function only once are vanishingly small, so I tend to put utility functions like this into a service program. I’ve adopted a single signature rather than trying to keep multiple signatures and that has made my life a lot simpler.

    I don’t generally use functions vs CALL in order to tweak performance. In our line of work, the only way tweaking calcs will buy you performance is when you’ve already tweaked the I/O. I can recall one or two times in 32 years where I had to optimise calculations. All the rest of my optimisation efforts go into reducing I/O. Makes sense, right? How many million calculations can the CPU do while it waits for the platter to spin around to the right sector?

    I like functions because I think that way, and 10 characters just aren’t enough to name a function properly. I respect that other people have a different opinion, which is one reason I like reading your adventures. Another view is always a good thing to have.

    Thanks for sharing and thanks for this latest. Always something to think about here.

Leave a Reply