Multi-threading

[chris_alc]

Hello all,

Looking for advice/perspective on possibly multi-threading an application I'm writing for a client. The main controllers for the application run on a 7.2 IBM i system, but it makes a lot of network calls with high latency especially in some batch processes. I've used multi-threading in similar situations before on other platforms, however, I've never used threads in IBM i and was reading the manual and... yikes.

The vast majority of the IBM i application is written in C++ with some RPGLE for direct I/O with files. The I/O is done exclusively in SQL, though. Everything, including RPGLE code, is in procedures and service programs--no program calls, no OPM, no cycle-main modules--except for start-up commands.

I have not been paying much attention to activation groups or control boundaries. I think everything runs in *CALLER at the moment so I think that means everything is running QILE. I also read multi-threading is not allowed in interactive jobs so I guess I'd have to put a wrapper around user commands to submit them to a new job and also mourn the loss of getting console output for anything in a thread? Perhaps there's more.

So I'm curious if anyone has experience multi-threading? Tips or considerations? I'm not opposed to submitting jobs for each network request, but there could be thousands in a given run and I was hoping to be as resource-efficient as I could. Plus, I hate to gum up job tables if I don't have to, and I have worked for clients where that has become an issue, believe it or not.

Thank you in advance!

[Scott Klement]

I don't see any good reason not to use threads, assuming you have the skills to keep things threadsafe. That is where the problems usually are -- that people do things like share a static variable between threads, and don't serialize it.

The SQL access is probably not threadsafe. I encourage you to research this, but I don't think it will be -- so anywhere you do SQL access you'll need to serialize access.

but as I understand it, your main issue that you are using multi-threading for is to handle network latency, and for that it will work fine.

I don't see why activation groups have anything to do with console access. But, regardless of threads, you should never be doing ILE work in the *DFTACTGRP. Instead, you should be always using a true ILE activation group (QILE is acceptable). No, *CALLER does not mean it is running in QILE, unless the routine that calls them is in QILE. It means that it will run in the same activation group as the routine that calls it.