On indicators

RPG has, since the beginning of time, supported a set of indicators — one byte characters that can be either *on or *off. These are popular but really shouldn’t be used any more. Being named *IN01 to *IN99 makes for indicators whose function is unclear and you are much better off using built in functions and explicitly defined fields.

There is an exception, of course. When dealing with display files, you have no choice but to use indicators to determine what keys have been pressed. Even here, though, it is a good idea to overlay the indicators with human readable field names.

This is how I do it:

 * Global variables
d IndicatorPtr    s               *   inz(%addr(*in))
d                 ds                  based(IndicatorPtr)
d iExit                   3      3
d iRefresh                5      5
d iAdd                    6      6
d iCancel                12     12
d iValidCmdKey           25     25
d iError                 30     30
d iPageDown              26     26
d iSflInit               80     80
d iSflEnd                81     81
d iSflEmpty              82     82
d iSflPosCursor          83     83
d iSflDeleted            84     84
d iProtectKey            90     90
d iProtectData           91     91

So *IN03 is mapped to field iExit, *IN05 is mapped to field iRefresh, and so on.

With the indicators defined in this way, I can write code like this:

p Main            b
d Main            pi
 /free

     // Identify the current program
     program = RtvProgram();

     // Main processing loop
     dou iExit = *on;
         WorkWithMessageDescriptions();
     enddo;

     return;

 /end-free
p Main            e

Note also that this Main procedure is not setting on the *LR indicator. This is because, in the header spec, I have a named main procedure:

h main(Main)

Using this tells the compiler that I am not using the RPG logic cycle and that processing should start with procedure Main. Not only does this allow me to abandon setting on *LR but also reduces a lot of the progeram’s overhead.

Flattr this!

Kittens

We appear to have another pair of twins in the house. Not human ones this time, which is why we can get away with giving them names like Chili and Pepper.

They seem to have settled in pretty quickly, though.

Flattr this!

Give me convenience, or give me death

GNOME Foundation partners with Purism to support its efforts to build the Librem 5 smartphone

The GNOME Foundation has provided their endorsement and support of Purism’s efforts to build the Librem 5, which if successful will be the world’s first free and open smartphone with end-to-end encryption and enhanced user protections.

Emphasis mine.

My GNOME desktop is great and provides a UI that could easily be ported to a mobile device. I would certainly like to see a truly open smartphone succeed. However, I am skeptical of the chances of this one, not for any technical or functional but because of the sheer size of the Android and Apple ecosystems.

Anyone trying to get into the smartphone market faces the same Catch-22: the user base isn’t big enough to appeal to app developers and the paucity of apps deters people from migrating to the platform.

The current duopoly is not fixed forever, but it will take a company the size of Samsung to break it.

Flattr this!

Pelty McPeltface

File this under inevitable, but still funny.

The neighbouring Belgian towns of Neerpelt and Overpelt are to merge and a new name is being sought for the merged municipality.

The final decision as to the new name is in November, at which point we will discover whether or not the local Limburgers will find themselves living in Pelty McPeltface.

Flattr this!

Using regular expressions in DB2 for i

Regular expressions have been supported in DB2 for a while now and, while they are not something I often need, there are times when they come in very handy indeed. A simple example involves cleaning up some data so that it can be exported from an old (poorly maintained) database to a new, shiny one that (I’m promised) absolutely will be used.

The database in question is an employee master and, in order to protect the innocent, I have both simplified it and changed the names for the purpose if this example. There are only two fields to worry about empnumber and empname, which represent the employee number and name respectively. There are a couple of issues to address. The first one is that the empnumber is ten characters in the old database but five numeric in the new, so I need to ensure that all the numbers fit.

The second issue is that this database has been very poorly maintained. If you allow someone to enter a character in a numeric field, they will. And they did.

Here’s an idea of how the database looked:

EMPNUMBER   EMPNAME
00001       Bugs Bunny
OOOO2       Elmer Fudd
0000000003  Daffy Duck
-4          Speedy Gonzales
00005       Sylvester

As you can see, there are lots of ways in which the employee number can be invalid, and these have all been very well explored. And watch out for Elmer Fudd — he’s a bit confused about the difference between letters and numbers.

Fortunately REGEXP_INSTR is your friend:

The REGEXP_INSTR returns the starting position or the position after the end of the matched substring, depending on the value of the return_option argument.

So all I need is a regular expression that identifies which employee numbers are five digits followed by spaces, and which aren’t. And here it is:

select * from employees
where regexp_instr(empnumber, '^\d{5}\s+$') != 1

There are several optional parameters but I only need to use the source string (empnumber) and the pattern expression. The expression I am using looks for digits in the first five characters followed by spaces to the end of the field. And this is the result:

EMPNUMBER   EMPNAME
OOOO2       Elmer Fudd
0000000003  Daffy Duck
-4          Speedy Gonzales

I told you that Elmer Fudd was tricksy.

It should also be possible to use REGEXP_REPLACE to automate some of the cleanup, but you really do need your business users to buy in before you go down that particular rabbit hole.

Flattr this!

Quoridor

One game that was brought out quite frequently over the summer was Quoridor. A large part of this is that, with nice solidly wooden pieces on a nice solid wooden board, there is no risk of anything blowing away while we wait for the barbecue. But the game itself is also very playable indeed.

The rules are simple. The game is played on an 9×9 grid and the object is to get your pawn from one side of the board to the other. On each turn you can either move your pawn or place a wall to hinder your opponent, but not completely block access to the opposite side. And that’s it.

As with the best of abstract games, a very simple set of rules allows for a great deal of depth in the actual play. In the case of Quoridor, the trick is to place walls to ensure that your opponent has to follow the longest path possible while also preventing them from lengthening your path too much (that rule about not completely blocking access to the other side — it can lead to all sorts of mazes).

It’s a quick game to play as well, with each game taking no more than 20 minutes to play. Given that the boys are 7 and 10, this shortness ensures that neither boredom nor frustration have any time to set in. On the downside, it means that we haven’t (yet) needed to explore the four-player version.

But we will.

Flattr this!