I am using ATE on a WINDOWS server.

I used 5.1.1118.2 and PRINT.LIT 3.0(123)
If I do PRINT FILE.TXT/PREVIEW it is using EZTYP when it should be using APEX.

I used 5.1.1120.2 and /PREVIEW then went into APEX but XCALL SPOOL with SWITCHES=524288 still used EZTYP.

What am I missing?

I must confess that the combinations of local vs. remote, text vs. gui, ate vs. zterm, server=windows vs. server vs. unix vs. server=client, eztyp vs. apex, spool vs. ezspl vs. print, print=print, print=preview+print, print=preview only, print on server, preview on client, preview on server, print on client, etc. have become too much for my to keep straight.

As I recall, the last time we visited this issue, the problem was you were getting APEX but you wanted EZTYP. Now, it appears we have the opposite. I'm not sure which makes sense. In the ATE environment, it's not clear, because in order to preview, you must get the file to the client, and the typical way to do that is by printing it to the local AUXLOC: device. Once you do that, you lose the ability to print back to the original server context, unless the clients and server share printers (which I realize, in your case, is true.)

In trying to figure out what makes sense, I'm not really sure what XCALL SPOOL with the 524288 (PREVIEW) switch should do. Should it always try to preview the file before printing it? If so, then it pretty much has to use EZTYP in the telnet case, since APEX can only run when the print file exists within your local GUI context (which it doesn't here, because it's on the server and APEX is on the client). So using EZTYP instead of APEX actually makes sense from the perspective of A-Shell (if not necessarily from the perspective of the user). As I said before, in order to get it to APEX, we would normally print it, but if the printer you specified was not AUXLOC:, printing it is going to actually print it to a printer, and APEX will never see it.

The reason why PRINT AUXLOC=FILE/PREVIEW works is that PRINT.LIT uses EZSPL.SBR instead of SPOOL.SBR, and EZSPL.SBR has an additional switch, OPTIONS = %h80000000 (2147483648) that forces preview to override printing.

Whether that makes sense I'm not sure, although I can feel your pain that it is confusing as hell for PRINT /PREVIEW to end up with a different result than XCALL SPOOL using the PREVIEW switch. It's tempting to make them identical, but not being able to hold all the combinations in my head, I don't really want to embrace something I don't quite understand.

So here's an alternate proposal. I'll add a new flag to the SPOOL.SBR SWITCHES parameter, SSW_APEX (4194304 or &h400000), which may be combined with SSW_PREVIEW (524288 or &h80000) to defer the interpretation of the preview flag until such a time as APEX can actually handle it (that is to say, if in the server/ATE environment, until the file has been transferred to the client.) This will prevent EZTYP on the server from grabbing it.

Note that this will only work, and only makes sense, if combined with a printer that uses some form of DEVICE=AUXLOC:. Otherwise, the file will just get printed and APEX will never see it.

For the local windows case, the flag will treated as equivalent to the regular PREVIEW flag.

This will be in 5.1.1121.8+.

In the meantime, you can always do what PRINT does, which is just use the "new format" of SPOOL,

PRINTER = "AUXLOC"
SWITCHES = 524288
XCALL SPOOL, FILE$, TABLE

Where TABLE is a structure, shown in the docs:

MAP1 TABLE
MAP2 PRINTER,S,64
etc.

Yet another alternative would be to invoke APEX via some means other than XCALL SPOOL. You could, for example, transfer the file to somewhere visible by the client (it's probably already there anyway) and then force ATE to print it from its side, bypassing the server side of printing entirely, using TAB(-10,AG_XFUNC). You'd have to write a simple wrapper SBX, perhaps called APEX.SBX, which just spooled the specified file using the PREVIEW flag. This would actually be more efficient than printing the file from the server to APEX, since that method requires outputting the entire file via the auxport channel of the telnet connection.

How do I get the new version of EZSPL without needing to update to a version of Ashell that has the beta ISAM code?

I tried the following:

?TAB(-10,54);",ATECRT,,,524288";CHR$(127);
?TAB(-1,82);
..............
?TAB(-1,83);
?TAB(-10,54);",";CHR$(127);

Why didn't that work?

Unfortunately, EZSPL.SBR is embedded within A-Shell, so you can't update it independently of any other part. However, I don't see what the problem is with your alternate approach. I tried it here, using 5.1.1120.2 on both sides and it seems to work fine, i.e. prints the file to ATE and previews it in APEX. And I confirmed that it was the 524288 that forced the preview, because my Preview Preferences were set to default=off, and when I remove the 524288, it prints to the ATECRT device but without preview.

If you want to debug this, open the debug message window and activate the LP and ATE traces, and also check the Debug checkbox in the Connection Properties Printer dialog, then run your program. You should see something like this:

0 07:22:30 TAB(-10,54);,ATECRT,,,524288
1 07:22:30 Setting KS_HOLD for tab(-10,54)
2 07:22:30 De-mangling env var from C:\DOCUME~1\joaquin\LOCALS~1\Temp to [C:\Documents and Settings\joaquin\Local Settings\Temp]
3 07:22:30 Preview launch: "c:\vm\rel51-ate\bin\ashw32.exe" -i "C:\Program Files\MicroSabio\ATE 5.1c\MIAME.INI" -n -e -atecfg "ASHPIC" -pv1032 -debug PRINT ATECRT="C:\Documents and Settings\joaquin\My Documents\APEX\pr7358.tmp"/SW:524288
4 07:22:30 TAB(-10,54);,
5 07:22:30 TAB(-10,49);
6 07:22:30 Releasing KS_HOLD

When you say it didn't work, what exactly do you mean?

Here is what I got...

0 14:01:01 TAB(-10,54);,ATECRT,,,524288
1 14:01:01 Setting KS_HOLD for tab(-10,54)
2 14:01:01 De-mangling env var from C:\DOCUME~1\ams\LOCALS~1\Temp to [C:\Documents and Settings\ams\Local Settings\Temp]
3 14:01:01 TAB(-10,54);,
4 14:01:01 TAB(-10,49);
5 14:01:01 Releasing KS_HOLD
6 14:01:01 Releasing KS_HOLD

Does it then print the file? The only condition I can see that might stand in the way of the "Preview launch..." is if the ATE Preview Preferences were set to Never.

Note that as originally envisioned, the preview feature was a sort of user-control adjunct to printing, and thus the user has the ultimate say over whether it is enabled always, never, or whether the application will be allowed to control it. There has been some discussion of providing a means for the application to override the user (i.e. to force the user to preview something, even if the user set his/her preview preference to never), but nothing has been done within A-Shell because Stephen Funkhouser contributed a utility to the SOSLIB to allow the application on the server to reset the ATE user's Preview Preference settings directly. So if that's the problem, perhaps therein lies the solution.

Otherwise, give me a few more details on how I might reproduce the situation here.

One final note: you can also activate the "Preview launch: ..." trace message by setting any of the following TRACE flags: DEBUG, XDEBUG, XCALL, AMOS, FOPEN, or GDIPRT. The method I mentioned above, of checking the debug checkbox in the ATE printer properties may be misleading, and thus I'm not 100% sure whether it tried to launch the preview and failed, or whether it didn't try. So it might be worth testing that again. If it isn't trying to launch the preview, then it should be printing the file, and further details about that would appears in the trace dialog. Since you didn't mention that, I'm suspecting that it tried to launch the preview but the command failed. And in that case, having access to the exact command line will be critical (and conveniently available if we can get the trace message to display.)

FYI - I just posted a "final" update of 5.1 prior to the ISAM enhancements - 5.1.1121.9 - to the usual places (Update Center and http://www.microsabio.net/dist/51dev/ ). For anyone looking for recent patches but scared of the ISAM enhancements, this is your last chance to get up to date.

Here is the resulting log with the other switches set.....


0 07:31:30 TAB(-10,54);,PRINT1,,,524288
1 07:31:30 Setting KS_HOLD for tab(-10,54)
2 07:31:30 file=, passthru=0, ptr=PRINT1, mimesize=0, switches=524288
3 07:31:30 Aux print: switches=80004(524292), ptrfile=, ptrname=PRINT1
4 07:31:30 De-mangling env var from C:\DOCUME~1\ams\LOCALS~1\Temp to [C:\Documents and Settings\ams\Local Settings\Temp]
5 07:31:30 Preview launch: "m:\miame\bin\ASHW32.exe" -i "m:\miame\MIAME.INI" -n -e -atecfg "APPLIED MICRO" -pv8 -z PRINT PRINT1="C:\Documents and Settings\ams\My Documents\APEX\pr7BC.tmp"/SW:524292
6 07:31:30 TAB(-10,54);,
7 07:31:30 file=, passthru=0, ptr=, mimesize=0, switches=0
8 07:31:30 TAB(-10,49);
9 07:31:30 Releasing KS_HOLD
10 07:31:30 Releasing KS_HOLD

The file does not print nor preview.

I tried opening a local session and did PRINT FILE/PREVIEW with the same result.

Well we are least getting close. Take the line that starts with "Preview launch:" and cut and paste it into the Start..Run command line. But remove the "-z" switch. Then you be able to see some kind of error message.

If not, and still no message, remove the -atecfg and -pv8 switches as well, or even just open a loacl session and see if can just print that pr7BC.tmp file.

Also, please reconfirm that the version of PRINT.LIT is 3.0(123). (Prior versions did not support the /SW:### switch, which I added for this purpose to make it easier to pass switches numerically from the XCALL SPOOL on the server side to the PRINT command used to launch the preview.

It returned "file not found" and there are no .tmps in that folder.
When I changed the name to a .apf that was in the folder an ashell screen pops up quickly and says "1 file deleted"
The target file did indeed disappear from the folder.

I think it is all starting to make sense.

You may be able to blame Jorge for this.

Actually, he pointed out that the delete flag was being ignored by APEX, and that was causing an accumulation of junk in cases where print files were being created solely for the purposes of a one-time preview. (Normally the delete switch is handled by the printing logic.)

Anyway, the one thing that I failed to reproduce in your environment is the fact that the ATE client disk environment and the A-Shell/Server disk environment are one and the same in your case. In such a case, the theory that ATE can delete any file it prints because it must be a temporary copy is not really valid. (Normally, ATE has its own temporary copies of print files sent by the server, so there is no reason not to delete them after printing.)

That said, I'm still a little confused over why the delete is taking place before the preview rather than after, but I think I can track it down now, and I'm sure it's related to the "fix" to have previewing "obey" the delete switch.

I will, however, reiterate that this method of printing is rather Rube Goldberg-ish. You're opening up the printfile on the server, and transmitting it to the ATE client over the telnet/TCP channel, where ATE writes it back to it's disk, which is actually the same hard drive as the server's disk, via a network mapped drive). As ATE saves its "local" copy, Windows copies it back to the server via the network redirector (over another TCP channel), completing a rather senseless loop.

It would be much cleaner to just tell ATE to preview and/or print the file from its original location. Admittedly, there is no obvious switch to do that, but a relatively simple print filter should be able to accomplish this. Just create a printer init file on the server that has no DEVICE, or perhaps uses the DISK: DEVICE (to copy rather than print the file), and insert a COMMAND=SBX:ATXPRT.

Then create an ATXPRT.SBX which uses AG_XFUNC to send ATE just the parameters needed so that it can print/preview the file from its present location.
You would then need an SBX to receive and process that command (perhaps even the same as the ATXPRT.SBX but with different params).

OK, so maybe that's a bit complicated too, but the concept is fairly simple: rather than "sending" the file to ATE, send it a message telling it to print file XYZ using printer ABC and switches 123. If you want me to create such an SBX, I would be happy to do so.

Obviously I need to fix the delete issue, but that is going to require an update, while the SBX approach requires no update at all.

AHA! Now (that I've connected to the target system) I can see the problem. Your TAB(-10,54) command is telling ATE to use a printer called ATECRT (or in one of your examples, it was PRINT1). But both of those printer init files are set to use DEVICE=AUXLOC: That makes sense on the server side, but you aren't printing on the server side. (Your test program is outputting the file to the aux port via TAB(-1,82).) So here's what's happening:


Icon 1 posted August 05, 2008 04:46 Profile for Joe Leibel Send New Private Message Edit/Delete Post Reply With Quote Here is the resulting log with the other switches set.....


0 07:31:30 TAB(-10,54);,PRINT1,,,524288

This is telling ATE that the next time we send it a file via the aux port, we want it to be printed to the ATE printer PRINT1 using switches 524288.

Then you're using TAB(-1,82) to open the aux port and sending it the print file. When you close the port with TAB(-1,83), ATE finishes capturing the file into a temporary file called:

%MY DOCUMENTS%\APEX\pr###.tmp

It would normally then just spool it via it's own XCALL SPOOL, FILE$, "PRINT1", 524292 command, but because it sees the preview switch set, it instead decides to launch a new session (so that the preview operation won't tie up the ATE session). So it does that via the simple(!) command line:

"m:\miame\bin\ASHW32.exe" -i "m:\miame\MIAME.INI" -n -e -atecfg "APPLIED MICRO" -pv8 -z PRINT PRINT1="C:\Documents and Settings\ams\My Documents\APEX\pr7BC.tmp"/SW:524292

So that launches a new instance of A-Shell which attempts to fire up the preview by using:

.PRINT PRINT1="C:\Documents and Settings\ams\My Documents\APEX\pr7BC.tmp"/SW:524292

PRINT.LIT passes it to SPOOL/EZSPL, which sees that you want to preview, and it starts by doing the pre-preview processing which creates the APF file. At some point, the fact that the AUXLOC: device makes no sense in the local PC environment causes the print/preview operation to abort, but the tmp file gets deleted, leaving the APF file.

Probably it should detect and make this problem more clear. Definitely in fact. But you've essentially tried to create an infinite loop by forwarding a print file via the aux port to ATE and then telling it to print to its aux port.

The solution here is simple: change your TAB(-10,54) command at the start to reference an ATE printer that exists and makes sense in the ATE context (i.e. not AUXLOC:).

This kind of self-referential recursive confusion is the downside of trying to make ATE and A-Shell/ATSD share the same environment.

Well that was an easy fix to a tough question.
Changing the ATECRT.INI to DEVICE=PROMPT: did the trick.
Thanks Jack

Easy to fix, perhaps, but excruciating to find.
As of 1122.2, A-Shell/ATE will display a warning message box if you attempt to print to AUXLOC: from a local/client context (where AUXLOC: makes no sense), and then it will treat it like PROMPT:

To clarify what was happening before, AUXLOC: was handled like a valid but null print device. A-Shell dutifully sent the file to the aux port via TAB(-1,82), but the terminal emulation within A-Shell/Windows (i.e. the PCTDVG driver) just discards the output.

So after what appeared to be a successful print operation, the delete switch was processed, deleting the tmp file.

A couple of addendums to this topic:

1. As of 5.1.1122.2, AUXLOC: is treated like PROMPT: if encountered within a local/client/ATE copy of A-Shell.

2. A new SOSLIB routine, ATEPRT.SBX, has been created to facilitate printing/previewing in the ATE environment where ATE has direct access to the files to be previewed or printed. This can happen in any ATE environment where ATE is able to mount the server's disk and has compatible DEVICE and ERSATZ definitions, or where the server is able to specify the native ATE-relative filespec of the file to print (whether or not the server can actually see the file). In these cases, as mentioned above, it is at best silly to go through the motions of transferring the file from the server to the client via the aux port when the client can already see it directly, and at worst, impossible (i.e. where the server knows the PC-based printfile spec but can't access it, which might be true in a PC-based printfile archival scheme). ATEPRT.SBX acts like SPOOL.SBR, except in the ATE case, where it passes the filespec to ATE and tells it to print it directly.