Author Archives: Paul

Editing RPGLE source members with Vim

I am very fond of the Vim text editor and will use it, out of preference, whenever possible. This includes writing RPG (and, obviously, RPGLE) programs on the IBM i. The only downside here is that, while Vim supports syntax highlighting for a multitude of languages, RPG isn’t one of them.

For a long time, I have relied on the syntax files written by Martin Rowe back in 2014. These, however, are getting more than a little long in the tooth. So, since I have a little time on my hands, I have started putting together a new set of syntax files which, hopefully, will be able to keep up with any new developments.

It’s all very early days so far, but you can find the Vim RPG Syntax highlighter here.

Feel free to download it and use it. And if you have any improvements to make or suggest, I would love to hear from you.

Flattr this!

Away forever

AOL has announced that it is shutting down AOL Instant messenger on December 15th. I’m rather surprised as I hadn’t realised that either AIM or AOL were still a thing.

The last away message

I do remember AIM though, and I even had an account on there back in the day, and it was certainly great at the time. So much so that everyone was on AIM.

And then it went the way of every proprietary network on the internet — superseded, ignored and now abandoned.

Flattr this!

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!