We have many background jobs running and cases where Users get up from their desks and elave themselves in screens with records locked (ie: isam files). This can create issues for a file that is used by all applications. It brings things to a screeching halt. We have dealth with this internally in our code logic with exception of MSGBOX. If the User is in a message we cannot control any time out. I can write a replacement routine for MSGBOX, but that would mean making lots of code changes. Is there a simple way of adding a TIMER feature like INFLD has to MSGBOX?

This question is complicated by the fact that there are multiple implementations of MSGBOX.SBX.

Originally there was an external MSGBOX.SBX (source included in [907,20] of the SOSLIB), but somewhere in the middle of the 5.0 development cycle we folded it into the ashell executable). However, at the same time, it was made to detect whether you had an AUI support (i.e. A-Shell graphic support via A-Shell/Windows or ATE) and if so, it transfers the request to the client which displays a regular Windows message box. Adding a timer to that would be nice, and something I've had on my to-do list, but it requires some low-level finagling and would require updating the A-Shell and ATE executables.

In 5.0.984.1, MSGBOX began to detect true background job status (job launched in Quiet Mode , or uses piped input or otherwise doesn't have a real terminal device attached), and in that case just logs the message to the ashlog.log file and continues as if the user had responded with YES (when YES is an option), or ABORT (if the choice is Abort/Retry/Ignore), or CANCEL (for Retry/Cancel), else OK. I'm not sure why you're not getting that effect. Perhaps you aren't really using XCALL MSGBOX? Or are on a version prior to 5.0.984.1? Or your "background" jobs don't meet the test we are using for "background"? Assuming it's the latter, and you're getting a message box that looks something like this...


...then it would be quite simple to change the implementation. The recommended procedure would as as follows:

1. Add an ALIAS to the miame.ini so that XCALL MSGBOX gets redirected to a different subroutine name (i.e. don't use the internal MSGBOX.SBR):

ALIAS=MSGBOX:MSGBX2

2. Create a MSGBX2.SBX in Basic which implements the same parameter list/interface as the existing MSGBOX. You can use the existing MSGBOX.BP mentioned above as a starting point. For convenience, I've uploaded a copy with a 30 second timeout already implemented (see note [110] for the single-line patch):

MSGBOX.BP (source to MSGBOX.SBX) *
TSTMSG.BP (test program)

* You'd need to rename the MSGBOX.SBX to MSGBX2.SBX (or whatever you choose to use in the ALIAS statement).

Another approach (instead of a timeout) would be to detect that the job is running in background and just log the message instead of doing the XCALL MSGBOX. This would short-circuit whatever the issue is that is preventing the built-in MSGBOX from detecting that you are in background. Typical techniques for detecting background status are:

a) Use XCALL GETUSN to see if the machine$ is a real terminal device or a background device.

b) Use XCALL GETJOB to look at the job name. (In the default naming scheme, background job names start with TAS while foreground jobs start with TSK, but you may also use the -j jobname command line switch to assign specific names to specific background tasks, which makes them easier to spot in the SYSTAT.)

c) If your "background" jobs belong to a limited set of programs that are always run in that mode, you can key off the program name (also returned by GETJOB.SBR).

Jack, you the man!
We use the common "background" quiet mode as well as our own system background jobs which truly are not your interpretation of background. Modifying MSGBOX as you've done should do the trick.

Much appreciated. Enjoy your day.

One last thing. Can you direct me to the latest MSGBOX.MAP download. Since RJ left Compupay I think this stuff has not been updated like he always did. I am afraid I have an old version. Several functions do not work correctly.

Here you go: MSGBOX.MAP

According to the edit history, it hasn't been touched since 2006, so I'm not sure if that's going to fix your issue, but in any case, there's not much critical in there. (Mostly it's old-style MAPped variables used to define symbolic values, which in modern A-Shell Basic we would use DEFINE for.)

Thanks. I'll post my results later. Much appreciated.

Thanks for the source MSGBOX.MAP which was more up to date than what we had. However, there is an issue with the latest MSGBOX.MAP you gave me. I found:

MAP1 MSGBOX'MISCFLAG'DEFINITIONS
MAP2 MBMISC'dflt2,b,2,256
MAP2 MBMISC'dflt3,b,2,512

was changed to:

MAP1 MSGBOX'MISCFLAG'DEFINITIONS
MAP2 MBMISC'dflt2,b,1,256
MAP2 MBMISC'dflt3,b,1,512

which is why I could not get the default buttons to work. My earlier version has this as B,2 which works, of course. B,1 is leaving these as zero. You may want to change this back.

So, far I have been able to write a routine with a time out that is functioning perfectly for our needs.

Thanks again.

Ouch! Thanks for the heads up. Problem now fixed and re-posted:
MSGBOX.MAP

Of course, the real solution to this kind of problem is to just use the defined symbols (MBMISC_DFLT2, etc.) which are defined in ASHELL.DEF. Not only are they immune to size issues and are true constants (can't be accidentally changed at runtime), but also don't take up any space in the program unless they are actually referenced.