We've been using AUXLOC:apex on the server-side for APEX viewing for a long time. This doesn't provide any related file transfer mechanism, so I'm testing using a custom print filter SBX (DDSPRT.SBX) to make these resources available on the PC prior to the preview operation.

This works well with one issue, APEX is blocking the application. DDSPRT is calling XCALL ATEPRT to actually spool the file. ATEPRT is calling itself via AG_XFUNC, and this is the point that is blocking.

I can't figure out a good way around this. Any help would be much appreciated.

Hey Stephen - can't you add file transfer mechanism in a GDI command? If not, why not just transfer the file manually prior to your print routine?

I'm not sure what command you're referring to for the files to transfer, but we have 400-700 page GDI documents that contain potentially hundreds of auxillary //XTEXT files to be printed. This document is generated hundreds of times with some variation depending in each. DDSPRT performs a very efficient auxillary file transfer using AG_FTPSYNC; which, is a file level sync protocol that uses one sFTP connection and is orders of magnitude faster than transferring the files all the time. It also has to re-write the //XTEXT commands in the copy of the file transferred to ATE so that they reference the correct directory on the PC.

I'm not sure I completely understand, but I suspect that the issue is the Force Main Window To Wait? option in the Preview Preferences.

Normally, in the ATE environment, that option is forced off, because it never seemed like a good idea to me to allow something like APEX to block the application on the server.

But by using XCALL ATEPRT, you're bypassing the normal ATE printing logic, so that from APEX's perspective, this is just a normal Windows print operation.

In A-Shell/Windows, the option Force...Wait option is available to be set either way. You can easily test if this is the issue by just manually resetting the option. If that fixes it, you can just force the PVwinstate setting in the ATE registry to 0 (Foreground, no-wait). You probably already have a utility for that, but if not, you can use the SETATEREG.BP utility from the 907033 directory of the SOSLIB .

That setting is off. Before creating a new thread I found Frank\'s thread referring to that setting, so unfortunately I had already checked that. I created a new thread because the cause of the issue seems significantly different. Plus, the difference in environments.

Interestingly, the preview settings in the APEX Window shows the "Wait.." option disabled just as it is from the ATE menu.

I can trap that this is APEX and not use ATEPRT. I tried this, but couldn't figure out how to get to work any better.

Ok, new theory (also connected to Frank, but in a different way). Maybe this is connected to the patch in 1399.6 (server side) to force the server/app to wait for an indication from the client, after an AUXLOC print request, indicating that it is ready for further output.

The feature was inspired by an issue that affected Franks application, whereby the users could get stuck in a modal dialog launched by a printer driver (such as a driver that created PDF files or something like that). This was causing the application to get AUI_CONTROL timeouts in subsequent GUI requests.

To help debug if this is the case, try enabling the ATE and LP traces on the server side, and then wait 10 seconds in APEX before closing it. Then check the log for the time sequence of these traces:

The tab(-10,88) <> is the request for the client ACK; as you can see in the above example, the response is immediate (even though sat in APEX for awhile before exiting). That should be the normal case, but yours is obviously not following the expected pattern.

The other possibility is that the delay is from waiting for the response to the tab(-10,AG_XFUNC) command which launches ATEPRT. The traces should help clarify that.

I didn't see a tab(-10,88) <> in the trace, but I know for sure I was waiting for a response in the tab(-10, AG_XFUNC) as I had traced that.

I figured out how to get it to work. In DDSPRT I tested for the original printer being "APEX", and then created a DEVICE=AUXLOC:apex logical printer .pqi for the application to XCALL SPOOL to. This launched APEX without it being modal.

I guess another workaround would have been to just change the AG_XFUNC to AG_XFUNC2 and remove the wait for the response.