Hi Jack,

I can't seem to get ATE printing to work at all after updating the A-Shell server version to 7.0.1760.0 (EL7). Let me know if there is anything I could provide to help pin the issue down.

Thanks,
John Andreasen
Diversified Data Software

My usual first go-to when debugging print problems is:

The above assumes that you have a printer init file called AUXLOC containing DEVICE=AUXLOC: and uses SYS:ERSATZ.INI as just an arbitrary sample print file. This should result in the system message window opening up and a bunch of traces appearing. The details will vary depending on your default ATE printer and environment but it should give us enough information to start tracking it down. (Feel free to just post the entire output here.)

Hi Jack,

Thanks for the tip as it helped me realize that the problem is not actually in the ATE printing itself, but rather an operation done by our print SBX that handles it.
So, it is performing an APPEND operation like this to append the prefix and suffix files to the printout.

With APPEND version 2.1(116), this operation completes without an issue.

With APPEND version 2.2(118), it generates this output:
-- Skipping non-existent DSK22:TSKAAB.007[170
-- Skipping non-existent 77]

So, it would appear that it is treating the commas within the PPN specification as filename separators.

Thanks,
John Andreasen
Diversified Data Software

Yikes! The 117 edit did "clean up" the command line parsing, replacing a lot of individual IFs and INSTRs and subscripts with the SOSFUNC: routine Fn'Explode'Ary(). It is passing the FXF_QUOTE flag, but that doesn't do much good if arguments aren't quoted (which does solve the problem, but wouldn't be normal or expected for DEV:FILE.EXE[P,PN] filespecs). I think I'm going to add another flag to that library function to ignore commas within [xxx,xxx]. Stay tuned...

Ok, I think the problem is resolved in APPEND.LIT 2.2(119) which you can get via UPDCUR.

Hi Jack, This seems to have fixed the issue. Thanks!