But where to you start with it? Let’s get our feet wet …

Configuring your IBM SaaS Instance

When you recieve your subscription details, you have to create an IBM Cloud SaaS Instance for your new Bob subscription.

• Go to: https://ibm-cloud.console.saas.ibm.com

• Log in with the IBM ID that has received the subscription details

• Create a SaaS instance and add the subscription to it

  

You don’t have to add users or admins here - but you can. But these users/admins have nothing to do with IBM Bob - they only have usage/management rights for your SaaS instance.

Configuring your Bob users

Now we have to configure our Bob users and teams.

Also this step has to be done with the primary IBM ID that has recieved the subscription details and has set up the SaaS instance.

• Start here: https://bob.ibm.com/admin/

  

• Select your newly created instance and continue:

  

• In the next steps, create your users (using their IBM IDs) and your team(s):

  

  On the users page, you can give some IBM IDs admin rights, so they can manage the team, users, spending limits, etc. I really recommend to have at least 2 users with admin rights.

  

  At the team page you can not only manage, how the spending limit should be per team, but also for each individual team member.

Use your Enterprise subscription in the Bob IDE

This last step is for each user. Most probably the users already participated in the free IBM Bob Trial. And this means, that their IBM ID already has a SaaS instance and a Team associated. So each user might have to switch the team, to use the Enterprise subscription.

• After logging in click on the small gear to open the Bob Settings:

  

Now you should be able to use the Enterprise subscription that are associated to your IBM ID.

Finally

As our team had a bit of a hard time to get this all going, I hope this helps others to get their Enterprise subscriptions going.

Also when you participated in the free IBM Bob Trial and make a individual subscription later, you might have to switch the “Team” in the Bob IDE, as your paid subscription and the free trial may use different “Teams”.

The installations works the same way, as with RDi 9.8. So if you want to know more, just read my posts about this:

• Rational Developer for i 9.8 - Tips and Tricks
• RDi 9.8 vs. Windows 11 24H2

Most of the tips and tricks are still valid - but also read the following tips which are special for RDi 9.9.

Problems with special or national characters in the source code?

I’m from Germany, and we have a few national characters which occationally also end up in our sources. But sometimes we also have problems with chars like # in our RPG sources, which are caused by the new Java runtime, that RDi 9.9 is using. The new JRE uses UTF-8 as it’s default, but RDi still depends on Windows Code Page 1252.

In that case, LPEX marks perfectly fine code as incorrect - but the code compiles without problems.

You simply have to make a change in your RDi.ini, which you find in the installation directory of RDi 9.9:

Insert this directly after the line `-vmargs’:

-Dfile.encoding=CP1252

It seems that people in the US and UK don’t have this problem - so just test, if you have syntax errors flagged in LPEX which compile fine - this might be your solution.

RDi UI langague

The national language translations for RDi are quite good - much better than back at version 9.8.0.0. But even as I work in Germany, I like my RDi in English.

To use RDi 9.9 in English, you also have to edit your “RDi.ini”:

Adter the line plugins/org.eclipse.equinox.launcher.win32.win32.... just add the followinf 2 lines:

-nl
en

To be continued …

Mit den diesen beiden Zeilen wird RDi 9.9 auf die Default-Sprache Englisch gesetzt.

In that screen shot there is no Bob icon in title bar (right of the Search field) and the IBM BOB view is not visible.

If you see this, after you have installed IBM Bob, you are not alone - try the following steps to fix the issue.

The temporary(!) solution

We all hope, that IBM will address the problem with a fix soon - but as long as there is no fix, you can try this workaround:

1. Open Finder and go to the folder where you installed IBM Bob. Normally it should reside in the folder „Applications“.

2. Right click on the IBM Bob app and select „Show Package Contents“. As you maybe already know, applications on macOS are special directory structures - so called “Packages” - that contain all resources an app needs to run. With „Show Package Contents“ we dive into that directory structure.

3. In the folder that opens, navigate to the sub-folder „Contents“, “Resources”, “app”, “extensions” and lokate the subfolder “bob-code”:

   

4. Right click on the folder “bob-code” and select “Get Info” from the context menu. You see, that “everyone” has “No Access” to that folder - and those missing permissions seem to be the problem. Close this Info window.

5. Now right click on the top sub-folder “Contents” and select “Get Info” from the context menu.

6. Click on the small lock icon in the lower right corner of the Info window and enter your password to make the permissions editable. The small lock has to be “open” to change anything.

7. Change the permissions for “everyone” to “Read Only”.

8. Click on small circle with the 3 dots and select the “Apply to enclosed items” and confirm it. This may take some seconds, as the permissions are now written to all subfolders and files in the application package.

9. Close the Info window and your Finder window and try start the IBM Bob app again. It should work now.

An alternative way to change the permissions is to use the command line tool chmod - open a Terminal window and enter the following command:

$ sudo chmod 0755 -R "/Applications/IBM Bob.app"

If you renamed the app to something else, replace “IBM Bob.app” with the name of your app. The -R flag means “recursive”, so it will change the permissions for all subfolders and files. The 0755 is the octal representation of the permissions, which means “read, write and execute for the owner, read and execute for the group and others”.

I hope this helps! Let me know if you have any questions.

In post - and at least 2 upcoming posts - I want to discuss and describe the common options that we have, to gracefully end our procedures, programs, service programs or jobs, even when an error or exception occurs or the job is ended unplaned.

First we take a look not only at the most modern option, but also at easiest to implement - the ON-EXIT statement in ILE-RPG.

Running an exit routine after your procedure with ON-EXIT

In 2016 ILE-RPG was extended with the ON-EXIT keyword/statement. It creates a “sub-procedure” inside your own procedure - and this “sub-procedure” is executed whenever(!) your procedure ends - whether it’s a normal end (by using return) or an abnormal end (by an exception).

Even when the job, in which your procedure runs, is ended with *IMMED the ON-EXIT section will still be executed.

Here a small example to see how easy this is:

**free
ctl-opt actgrp(*new);

myProcedure();
*inlr = *on;
retrurn;

dcl-proc myProcedure;
  dcl-pi *n ind extproc(*dclcase);
  end-pi;

  dcl-s isAbnormalEnd ind inz;

  snd-msg *info 'This is the '+%proc()+' procedure ...';

  return *on;

  on-exit isAbnormalEnd;
    snd-msg *info 'This is the ON-EXIT procedure called '+%proc(*onexit);
    if isAbnormalEnd;
      snd-msg *info 'Procedure '+%proc(*owner)+' ended abnormal!';
      return *off;
    endif;
end-proc;

So whenever this procedure ends, the ON-EXIT block is executed. If the procedure is ending abnormal - i.e. due to an exception - the flag isAbnormalEnd in set to *ON. You have to declare the isAbnormalEnd indicator (boolean) variable - it can be procedure local or globally declared.

What happens is, that the ON-EXIT sub-procedure is executed, whether a RETURN is executed or an unhandled exception occurs. Exceptions that are handled by a MONITOR group or by an E operation extender will NOT trigger the ON-EXIT procedure.

Please try it - compile the program and call it. In the job log you should see 2 messages:

  This is the myProcedure procedure ...                         
  This is the ON-EXIT procedure called _QRNI_ON_EXIT_myProcedure

As you can see - after the RETURN, the ON-EXIT sub-procedure was executed - and isAbnormalEnd was NOT active.

ON-EXIT when an exception occurs

Now we want to test the abnormal end - so we modify like this:

**free
//...
dcl-proc myProcedure;
  dcl-pi *n ind extproc(*dclcase);
  end-pi;

  dcl-s isAbnormalEnd ind inz;
  dcl-s num int(10) inz;

  snd-msg *info 'This is the '+%proc()+' procedure ...';

  num = num / num; // -> exception will occur

  snd-msg *info 'Just before RETURN from '+%proc()+' ...';
  return *on;

  on-exit isAbnormalEnd;
    snd-msg *info 'This is the ON-EXIT procedure called '+%proc(*onexit);
    if isAbnormalEnd;
      snd-msg *info 'Procedure '+%proc(*owner)+' ended abnormal!';
      return *off;
    endif;
end-proc;

If we compile and call the program now, you will receive an exception message, and the follwowing messages in your job log:

  This is the myProcedure procedure ...                          
  Attempt made to divide by zero for fixed point operation.      
  The call to myProcedur ended in error (C G D F).               
? C                                                              
  This is the ON-EXIT procedure called _QRNI_ON_EXIT_myProcedure 
  Procedure myProcedure ended abnormal!                          
  Application error.  MCH1211 unmonitored by ON_EXIT at statement 0000000017, instruction X'0000'.                             

Nice - even as our procedure never reached the RETURN statement, the ON-EXIT sub-procedure is still executed. But this time, isAbnormalEnd is set to *ON.

ON-EXIT when the job or program is ended forcefully

What happens, when we end the program or job forcefully. Like with SysReq option 2 or with an ENDJOB command. So let’s modify our procedure again - this time with an endless loop:

**free
//...
dcl-proc dcl-proc myProcedure;
  dcl-pi *n ind extproc(*dclcase);
  end-pi;

  dcl-s isAbnormalEnd ind inz;
  dcl-pr sleep uns(10) extproc('sleep');
    seconds uns(10) value;
  end-pr;

  snd-msg *info 'This is the '+%proc()+' procedure ...';

  dow *on;
    snd-msg *info 'Inside the endless loop ...';
    sleep(5); // sleeping for 5 seconds
  enddo;

  snd-msg *info 'We should never reach this ...';
  return *on;

  on-exit isAbnormalEnd;
    snd-msg *info 'This is the ON-EXIT procedure called '+%proc(*onexit);
    if isAbnormalEnd;
      snd-msg *info 'Procedure '+%proc(*owner)+' ended abnormal!';
      return *off;
    endif;
end-proc;

We compile the program and call it form the command line - it will run endlessly, so we interrupt it with SysReq 2 - and we find this in the job log:

  This is the myProcedure procedure ...                         
  Inside the endless loop ...                                   
  Inside the endless loop ...                                   
>  *SYSTEM/ENDRQS                                               
  This is the ON-EXIT procedure called _QRNI_ON_EXIT_myProcedure
  Procedure myProcedure ended abnormal!                         

Like in the case of the exception, the ON-EXIT gets executed, and isAbnormalEnd is *ON.

Now submit the program into the background with SBMJOB CMD(CALL PGM(ON_EXIT)) JOB(ON_EXIT) and check for the running job with WRKSBMJOB. Find your job, and use option 4 and F4. You can end the job with OPTION(*CNTRLD) or with OPTION(*IMMED) - it doesn’t matter.

If we inspect the printed job log, we will also find the messages from the ON-EXIT sub-procedure - even when we used OPTION(*IMMED).

This means, that *IMMED is not so instantly as we always thought. Our ON-EXIT sub-procedure, and also all other ON-EXIT sub-procedures in the call-stack will be executed, even when we try to end the job as fast as we can.

What else can ON-EXIT can do?

Inside the ON-EXIT sub-procedure you have several options. You get the name of LR original procedure with %PROC(*OWNER). Whereas %PROC(*ONEXIT) is returning the name of the ON-EXIT “sub-procedure” - in our case this is _QRNI_ON_EXIT_myProcedure.

An interesting option is, that from inside the ON-EXIT sub-procedure, you can also return a completly other return value, than that of the original procedure. If you don’t code a RETURN in ON-EXIT or if that RETURN is conditioned (like in our example) the original return value is returned.

Inside the ON-EXIT sub-procedure you have access to all variables defined inside the owner procedure. You can also access all global variables. This means, the ON-EXIT sub-procedure runs in the same scope as the owner procedure.

When can we use it?

The ON-EXIT opcode is available for every procedure. In the case of a main procedure, it’s only available in linear main procedures - meaning those, that are indicated by the control keyword MAIN(...).

You cannot use ON-EXIT inside a cycle main procedure - those where you have to set *ILR to *ON to end the program (like in our example). But you can use them in each and every procedure that might get called from than cycle main procedure.

ON-EXIT finally

The ON-EXIT sub-procedure is by far the easiest and most straight-forward solution, to clean up. I use it all the time - closing files or SQL cursors, checking for correct execution, logging errors and addition information and much more.

In the following post in this series about exit procedures we will have a look at an API that not only works with linear procedures, but also with cycle main procedures - and any other type of call stack entry. So stay tuned.

I hope you enyoyed this post - and if you have questions or ideas - I have opened the Discussions page of this repository - so, if you like, leave a comment.

And after meticulously reporting all my “Champions Activities”, I was not SOOO surprised this year, that I was selected to be an IBM Champion again for 2026.

So now again - I’m an IBM Champion for 2026, and will try make the best out of this year.

You can opt to make your compiles in batch - so your session is free to do other work. And when the compiled finnishes, it will send you a message whether the compiler job finished successfully or not.

Now you can set your message queue to *BREAK - which means, that your session will get interupted and the message appears on the screen. Nice, you know in real time that the compiler weas successful - but you were interrupted. OK set your message queue to *NOTIFY - you will see a small MW (for Message Waiting) at the bottom of your session, when the compiler was finished - but you can’t see, if the job completed successful or not.

Wouldn’t it be nice, to see the result - without being interrupted?

I don’t remember, where and when I have seen this “trick” first - but is was somewhere in the early to mid 1990s, and I use it since then. And when I searched for it lately, I hard a hard time, finding the tip somewhere online, so I thought, it would be good to have it in my blog.

I haven’t invented this idea - and sadly, I also don’t know who exactly has - so I have to give credit to the unknown programmer who saved me a lot of time in the last 30 years - Thank You!

But now dive in …

Creating a Break Message Handling Program

First, we have to create a small CLP / CLLE program that will handle the messages for us.

PGM (&MSGQ &MSGQLIB &MSGMRK)
DCL &MSGQ TYPE(*CHAR) LEN(10)
DCL &MSGQLIB TYPE(*CHAR) LEN(10)
DCL &MSGMRK TYPE(*CHAR) LEN(4)

DCL &MSGID TYPE(*CHAR) LEN(7)
DCL &MSGDTA TYPE(*CHAR) LEN(1000)
DCL &MSGDTALEN TYPE(*DEC) LEN(5 0)
DCL &MSGF TYPE(*CHAR) LEN(10)
DCL &MSGFLIB TYPE(*CHAR) LEN(10)

RCVMSG MSGQ(&MSGQLIB/&MSGQ) MSGKEY(&MSGMRK) +
       RMV(*NO) MSGDTA(&MSGDTA) +
       MSGDTALEN(&MSGDTALEN) MSGID(&MSGID) +
       MSGF(&MSGF) MSGFLIB(&MSGFLIB)

/* handle normal and abnormal job completion messages */
IF (&MSGID *EQ 'CPF1241' *OR &MSGID *EQ 'CPF1240') DO
  SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +
            MSGDTA(&MSGDTA) TOPGMQ(*EXT) +
            TOMSGQ(*TOPGMQ) MSGTYPE(*STATUS)
  GOTO FINITO
ENDDO

/* all other messages require user intervention */
DSPMSG MSGQ(&MSGQLIB/&MSGQ)

FINITO: ENDPGM 

The parameters for a break message handler program are defined by the system. The is pretty straight forward. First, the program receives the message with the correct marker from the message queue.

If the message is a CPF1241 (Normal End) or CPF1240 (Abnormal End) it sends the message out again as a status message - this will show up in the message line of your interactive session.

If it’s any other message, the program will simply to a DSPMSG of the Message Queue - which means, the message will break through.

Compile this small program to your personal library or anywhere you want it. For the rest of this post, we will assume you compiled it as YOURLIB/BRKMSGHDL.

Attaching the Break Message Handler to your Message Queue

Next, we need to attach our break message handler program to our message queue. The best is, to do that when you sign-in - in the initializing program (INLPGM) of your user profile.

Check with the command CHGPRF if you already have an INLPGM. If this is the case, you can add the commands to it - otherwise create a new one.

PGM

DCL &MSGQ TYPE(*CHAR) LEN(10)
DCL &MSGQLIB TYPE(*CHAR) LEN(10)

/* get current users message queue */
RTVUSRPRF USRPRF(*CURRENT) +
          MSGQ(&MSGQ) MSGQLIB(&MSGQLIB)
MONMSG  MSGID(CPF0000)

/* attach the break message handler to the msgq */
CHGMSGQ MSGQ(&MSGQLIB/&MSGQ) DLVRY(*BREAK) +
        PGM(YOURLIB/BRKMSGHDL)
MONMSG  MSGID(CPF0000)

ENDPGM

First, the program retrieves the message queue of the current user.

Next, it tries to change the message queue to *BREAK and attaches the handler. This is not a permanent change, because it lasts only as long, as that session is logged in.

And it only works one time - only the first logged in session can attach the break message handler program. This is the reason why a MONMSG CPF0000 after that command is prefenting any error messages.

It’s also a good idea to have a MONMSG after nearly every command in your INLPGM - otherwise the program could fail, you might be unable to log in.

Compile this program to your personal library or where you want it. Let’s assume you compiled it as YOURLIB/STARTMEUP.

Changing your User Profile

The last step is to attach the initializing program to your user profile.

CHGPRF INLPGM(YOURLIB/STARTMEUP)

The command CHGPRF can be prompted with F4 if you like - the INLPGM is something like the .profile in typical *nix operating systems. It is executed when a user logs in.

Finally

If anything works correctly, you can sign-off and sign-in again. Try the command SBMJOB CMD(DLYJOB DLY(5)) JOB(TESTMSG) - after 5 seconds (or so) you should see a message Job ... completed normally in the status/message line of you session.

The completion messages stay in your message quere - so if you ever miss one, you can always look with DSPMSG.

As long as I can remember, I used this trick - and I hope it will help you too.

If you have questions or ideas - I have opened the Discussions page of this repository - so, if you like, leave a comment.

• IBM i 7.6 Technology Refresh 1
• IBM i 7.5 Technology Refresh 7

As always the TRs are packed with new features, but I want to highlight one, that is my personal favorite.

The SQL INSERT statement gets a new named columns syntax for the VALUES clause. But before we have a look at this, let’s look at the syntax of the INSERT statement as we know it.

The traditional INSERT statement syntax

The SQL INSERT statements purpose is to create new rows in a table. The traditional and standard syntax is which looks familiar since 1992:

insert into mytable (column1, column2, column3)
values ('Value 1', 2, 'Value 3');

If you don’t want to supply values for every column of the table, you list the table columns in parentheses and the values in VALUES clause - exactly in the same order.

If you have lot of columns and a lot of values, this is a common source for errors. And here the new syntax, that is introduced with the new TRs, will be a huge improvement.

The new INSERT named columns syntax

You can read about the new syntax here: Inserting rows using the values clause

But let’s look at a short example first:

insert into mytable values (
  column1 => 'Value 1',
  column2 => 2,
  column3 => 'Value 3'
);

This syntax looks a bit like a SQL procedure oder function call with named parameters. You don’t list the columns after the table name. Instead you use the a construct like column1 => value1 inside the VALUES clause to bind the value directly to a column name.

And at first look, it doesn’t add any new functionality to INSERT. You still have to write every column name - you still have to write every value. But from my point of view, it’s much easier to read - especially when you look which value goes into which column.

And if you are embedding a SQL INSERT statement into RPG code, it really makes it also much easier to maintain, as you simply can add one line for a new column, instead of have to touch the column list and the value list.

exec sql insert into mytable values (
           column1 => 'Value 1',
           column2 => 2,
           column3 => 'Value 3',
           column4 => 4            // added new column
         );

With this change the INSERT now looks more like an UPDATE statement, where you usually have one line per column/value pair.

Finally

So what do you think about the new syntax? Yes, I know - it’s not SQL standard (at the moment) but it’s really so much better to read. And I really hope, that the SQL standard is adopting this syntax soon.

Will you adopt it?

Sadly, there is no mechanism in ILE-RPG that helps with automatically running a procedure when a service program is loaded. But lately I stumbled over a “gem” in IBM i Info Center that describes a way, to create exactly that - and the hero in this tale is: C++

The problem

Here is the source code of a small service program.

**free
ctl-opt nomain;

dcl-proc initSrvpgm export;
  dcl-pi *n extproc(*dclcase);
  end-pi;

  snd-msg *info %proc()+': initializing service program ...';
  // do some initialization
  return;
end-proc;

dcl-proc doSomething export;
  dcl-pi *n extproc(*dclcase);
  end-pi;

  snd-msg *info %proc()+': doing something ...';
  // do something 
  return;
end-proc;

Let’s assume the initSrvpgm procedure is initializing some global variables, is setting up something in QTEMP or is registering an activation group exit procedure with the CEE4RAGE2 API.

Now you would have to call initSrvpgm() in each program that uses your service program. And you would have to call it exactly once - because in our example, you only want to register the activation group exit procedure once, as it only should run exactly once, when the activation group ends.

This is rather inconvenient and also error prone. If the developer forgets about it, the initialization isn’t done - or maybe worse, it’s done twice.

The solution

We need some code, that is automatically executed, when the service program is loaded and activated. But sadly neither ILE-RPG, ILE-COBOL, ILE-CL nor ILE-C have a mechanism or construct to do that.

But there is another ILE family member that can do exactly this: ILE-C++

extern "C" void initSrvpgm(void);

class InitSrvpgmClass {                    
  public:                              
    InitSrvpgmClass() {      
      initSrvpgm();  
    };
};                                    

InitSrvpgmClass dummy;

This code should be in a member of type CPP (or an IFS source file with .cpp extension).

You would compile it with the CRTCPPMOD command to a module. And then bind both the ILE-RPG and the ILE-C++ module with CRTSRVPGM to a service program. And if a program that is linked to the service program is loaded, the service program also gets loaded - and like auto-magically the initSrvpgm procedure gets called.

You can even hide the ILE-RPG procedure initSrvpgm from being called by someone else, by leaving the export out of the binder language source. But since it has to be called by the C++ module inside the service program, it still has to be flagged as export in the RPG source code, to work.

The page in IBM i Info Center is recommending that you create the module only once, and always use the same module and the same procedure name for the init procedure in RPG. But I prefer to have a separate module for each service program, as I also like to prefix the procedure names of my service programs.

At this point you are free to stop reading - in fact, up until now, I haven’t written anything, that you cannot read on the page in IBM i Info Center. But in the next chapter, I will at least try to explain, why or how this mechanism works.

The explanation

Now let`s go through the C++ code, to find out, what exactly happens.

The first line reads as:

extern "C" void initSrvpgm(void);

This is simply a C/C++ function prototype for our ILE-RPG procedure. As C++ is a case-sensitive language, and I have used the keyword extproc(*dclcase) with our procedure, the case has to match exactly the external procedure name or export.

Without the extproc(*dclcase) keyword, the prototyp would have to be INITSRVPGM, as ILE-RPG is normally exporting every procedure in UPPERCASE. But I like camelCase - not only in my source code - also as the exported procedure name.

The next part is:

class InitSrvpgmClass {                    
  public:                              
    InitSrvpgmClass() {      
      initSrvpgm();  
    };
};                                    

Here, we define a C++ class. Without going into too much details, C++ is an object-oriented language, and a class is some kind of template that can mix data (like a data structure) and code (like procedures, but called methods). Those classes (“templates”) are later used to create an object (a “variable”) of that class (“type”).

The part with InitSrvpgmClass() { ... } is a class constructor method, that automatically gets called, when a new instance of our class - meaning a new variable of that type - is created. A constructor method must always have the same name - including matching case - as the class itself - because your know … C++ is a case-sensitive language.

The last part is:

InitSrvpgmClass dummy;

This is simply a module global variable definition. In C++ you can declare variables outside of your functions - and exaclty like ILE-RPG those variables are global to the module. And those variables are “initialized” at the moment, the module is loaded.

And here the trick - as we defined a class constructor, that constructor code is executed in the very moment, where the variable is initialized - … when the module is loaded. And because our constructor is calling our ILE-RPG procedure initSrvpgm(), our ILE-RPG code is also executed - … when the (C++) module is loaded.

So that Kind of Magic is simply an object-oriented feature of C++, which we are exploiting shamelessly for our own advantage.

Finally

As long, as your initialization doesn’t need any parameters from the calling program, this technique is quite useful, and you will never have to think about calling your initializer.

So I hope you found our little excursion into C++ and object-orientation entertaning and easy to follow.

If you have questions or ideas - I have opened the Discussions page of this repository - if you like, leave a comment.

Even if many IBM i appications run in a very closed envorinment, SQL injections can be real threat. So in this post, we explore a clever combination of SQL parameter markers and SQL indicators, that can help you to create injection-safe dynamic SQL statements.

The problem: user-input in dynamic SQL statements

With dynamic statements in SQLRPGLE you always have to be careful with user-inputs. Users can enter malicious data like ' or 1=1-- - and if this code is “embedded” into a dynamic SQL statement, it can be harmful.

So since long, every SQL evangelist ist preaching to use SQL parameter markers - e.g. ? - in dynamic SQL, and strictly avoid ebedding user entered strings into the SQL statements.

So with this kind of code, you obviously can get into trouble:

exec sql prepare stmDelete using 'DELETE FROM MYTABLE WHERE COL1 = '''+%trim(myVar)+'''';
exec sql execute stmDelete;

If myVar contains ' or true -- the SQL statement will evaluate to:

DELETE FROM MYTABLE WHERE COL1 = '' or true --'

And as everything behind the SQL comment -- is ignored, all rows in MYTABLE will get deleted.

One solution might be, to search for “forbidden” characters like ' oder strings like --. But then your users will be unable to search for exactly these characters or strings. So thats an “sub-optimal” solution.

The real solution is, to avoid embedding strings and simply use ? parameter markers, instead of appending strings into the statement - like this:

exec sql prepare stmDelete using 'DELETE FROM MYTABLE WHERE COL1 = ?';
exec sql execute stmDelete using :hostVar;

The ? markers in the statement get their values during the EXECUTE or OPEN (for cursors) statement. During the execution the values are “insertet” in a typesafe way, and the are never “embedded” into the statement. So even a value like ' or 1=1-- will be entered as a value into the statement - and therefore treated as literal data, not as SQL code.

Really dynamic SQL statements

But what do you do, if your statement is “really dynamic”? I mean, if e.g. your WHERE conditions are created at runtime depending on user input. In this case, you probably don’t know, how many ? markers you will have in the end?

But there is also a solution for cases like this - SQL indicator variables!

Let’s look at a dynamic SELECT statement with parameter markers like this: 

selectStmt = 'SELECT MYTABLE.* +
              FROM MYTABLE  +
              WHERE MYTABLE.COL1 = ?';
if searchVal <> *blank;
  selectStmt += ' AND MYTABLE.COL2 LIKE ''%'' CONCAT TRIM(CAST(? AS VARCHAR(100))) CONCAT ''%''';
endif;

The problem is, that you would have to code different OPEN statements for the cursor - depending on whether the searchVal is *BLANK or not.

But SQL has a solution for that problem - SQL indicators! So here our new code:

dcl-s col2ind int(5) inz;

selectStmt = 'SELECT MYTABLE.* +
              FROM MYTABLE  +
              WHERE MYTABLE.COL1 = ?';

if col2val <> *blank;
  selectStmt += ' AND MYTABLE.COL2 LIKE ''%'' CONCAT TRIM(CAST(? AS VARCHAR(100))) CONCAT ''%''';
  col2ind = *zero;
else;
  col2ind = -7;
endif;

exec sql prepare stmSelect from :selectStmt;
if sqlcode = *zero;
  exec sql declare csrSelect cursor for stmSelect;
  exec sql open csrSelect using subset :col1val, :col2val :col2ind;
endif;

As you can see, the value of col1val and col2val are only used with the OPEN statement.

The magic is done by the clause USING SUBSET. Depending on the indicator col2ind for host-variable col2val, the OPEN statement gets executed in two different ways:

• col2ind = 0 -> open csrSelect using :col1val, :col2val
• col2ind = -7 -> open csrSelect using :col1val

In the second case, the host-variable col2val in the USING SUBSET clause is completely ignored. Therefore also the second ? marker shouldn’t be present in the prepared statement.

And now the “funny” part - you can mix host-variables with and without indicators in the USING SUBSET clause as you like. You only have to make sure, that in the end:

• You have exactly the number of host-variables without -7 indicator as you have ? parameter markers
• The sequence of the host-variables in the USING SUBSET clause is exactly matched to the sequence of the ? parameter markers

But why of all things are you using trim(cast(? as varchar(100)))?

I’m using the somehow unnecessarily complex trim(cast(? as varchar(100))) to insert the parameter marker. And you may ask why?

And the reason for this is simple - our variable col2val is supposed to be of type CHAR(..), and we want to trim leading and trailing blanks from the value, to make our LIKE search.

But there is a problem with that - you cannot code TRIM(?) in dynamic SQL directly. Due to an unresolved error in dynamic SQL, some scalar functions don’t accept ? parameter markers directly - and sadly TRIM is one of them. So we are wrapping the ? marker in a CAST and this avoids the problem.

Of course you can avoid that, if you simply use a host-variable of type VARCHAR with and already trimmed value in it. Instead of trim(cast(? as varchar(100))) you would then simply code ?.

Maybe IBM is fixing this in the future - but even when they do, it won’t affect your statements, that still use CAST.

Is this only for OPEN statements and dynamic SQL?

  Short answer: No!

Somehow longer answer: You can also code UPDATE and INSERT statements with a variable number of ? parameter markers, as EXECUTE also supports the USING SUBSET clause. And you can even use the -7 indicator in static SQL - here an example:

exec sql update mytable
         set mytable.col1 = :col1val,
             mytable.col2 = :col2val :col2ind
         where mytable.id = :id

If the indicator col2ind is set to -7, the statement will be executed like this:

exec sql update mytable
         set mytable.col1 = :col1val
         where mytable.id = :id

Conclusion

Avoiding SQL injections is not so hard using indicators in dynamic embedded SQL. You should really use this trick at least with all character/string inputs.

Thanks for reading.

If you have questions or ideas - I have opened the Discussions page of this repository - if you like, leave a comment.

More information / Links

• Info Center - SQL Indicator variable special values
• Info Center - OPEN Statement
• Info Center - EXECUTE Statement

The reason seems to be connected to cyber security package SentinelOne - since users that don’t use that software mostly have no problems.

Until now, I don’t know of a fix for Windows, RDi oder SentinelOne that permanently works - but here are some tips, that might help.

The problem

Even if RDi or iACS seem to run, they crash without a warning after an undefined runtime. On some machines RDi doesn’t start at all.

Updating to RDi 9.8.0.4

If possible, you should definitly upgrade to the latest RDi version 9.8.0.4 before you start the upgrade to Windows 11 24H2.

Go here to find some information about RDi 9.8.0.4

White-listing RDi.exe in SentinelOne

It seems, that simply white-listing the file RDi.exe on your machine in SentinelOne helps, and RDi doesn’t crash anymore. But this doesn’t help with other Java based applications like iACS. You would have to white-list all of them, which might be inconvinient.

Installing an alternative Java runtime

Using an alternative Java runtime seems to work too - and I achieved good results with Amazons Corretto Java,

• https://aws.amazon.com/de/corretto

  Amazon Corretto OpenJDK Version 21

After installing the new runtime, you have to configure RDi to use it, instead of its own JRE. Before you do this, you should make a backup copy of the file RDi.ini in the RDi installation directory.

Now open the file RDi.ini with your preffered text editor.

Find the line after -vm - here you find the path of the JRE, that RDi should use. Replace the path (normally starting with plugins/com.ibm.semeru) with the path to the JAVAW.EXE of your newly installed JDK - e.g. that might be:

C:\Program Files\Amazon Corretto\jdk21.0.6_7\bin\javaw

Of course your path can vary because of another JDK version.

You also have to remove the line reading -vmargs.

After that, a double click on RDi.exe should start RDi and it should work.

Known problems

1. Whenever your Amazon Corretto JDK is updated, it’s installed in new directory with the current version number. So you will have to change the VM path in RDi.ini after every JDK update.
2. With every update of RDi the RDi.ini is overwritten - so you will have to make the changes every time again.
3. In RDi the LPEX editor sometimes signals syntax errors in RPGLE code, that are in fact no errors. E.g. LPEX will signal an syntax error for a variable name like #something - but the RPGLE compiler accepts this variable name.