I'm trying to implement EZSPL features for the first time, and things
are not working as I want them to work.

The objective:

Print a print file with embedded PCL commands three times to three
different paper trays in a RICOH printer with four trays. I have and
have tested the applicable PCL commands for each tray, so I figured
EZSPL could handle this problem if I called it three times with the same
file name, just varying the PREFIX field as needed for each call. I
have, of course, created the argument table as outlined in the ASHELL
Manual, Rev E02.

The problem. I can't test directly on my system, as I don't have
the same printer. I'm printing from LINUX using lpr through a WINNT
machine that has the printer connected on the parallel port. I'm
pausing the printer and looking at file contents in the
\WINNT\SYSTEM32\SPOOL\PRINTERS\ directory. The embedded PCL commands are
in the data file, but nothing from the prefix string. There's a related
header file, but I think that file is for control only and would not
(and I've verified does not) contain any PCL commands.

Any ideas where my problem may lay?

I'm guessing that you are using the XCALL SPOOL "New Format", i.e.:

(Note that XCALL SPOOL is equivalent to XCALL EZSPL, since SPOOL is implemented as an ALIAS to EZSPL.)

I just tried this myself and it appears to be a bug.

However, you can also specify the "Old Format", and that does work:

I'll look into fixing the bug in the next update, but it you want a more immediate solution, I suggest using the old format shown above.

Another alternative would be to create multiple spooler init files, each specifying a different PREFIX= statement. Note that when PREFIX or SUFFIX is specified (and non-null) in the XCALL SPOOL statement, they should override the setting in the printer init file.

Here are a couple of debugging suggestions:

Use SET TRACE LP ON. The displaying tracing information will allow you to see if the prefix and suffix are being processed. Under UNIX/LINUX, the relevant parts of the tracing display would look something like:

Under Windows, you'll still see the first line indicating the name of the prefix and suffix files, if applicable, but you won't see the concatenation lines because A-Shell/Windows sends the file(s) directly to the printer device driver (so there's no need for a temporary file.)

Under UNIX/Linux, you could then just examine the temporary file directly to see if your prefix is there. The temporary file is then passed to the lpr command to print.

Under Windows, you could change the output device of the printer driver to FILE: if you wanted to be able to examine the output directly.

Finally, remember that under UNIX/Linux, the OPR:SPOOL.LOG file will show details about the spool commands issued, along with any error messages that would have been displayed by the lpr command.

Well, this is more confusing, but I'm close to getting the results I want. First, I read but then forgot that PREFIX and SUFFIX are file specs, not the actual printer codes to be executed. Seems to make it more complex, but then there can be no carping about ONLY 28 bytes that way. So, I changed my program to follow directions.

what I found was that it doesn't work with the OLD format, but does indeed work with the NEW format, which seems to the opposite to Jack's findings. Hmmm!

Now to get rid of the end of line character in my prefix file that vue adds automatically, and I think I'm home...

All is working, but I'd like to add a request that PREFIX and SUFFIX fields allow for the actual codes to be executed, as an alternative to specifying disk files that contain the codes. That would keep things simpler in my case, and eliminate the need for yet more disk files to be managed.

I'm not sure what to make of the question of which method works and which doesn't. (Suffice to say some more testing and possibly debugging is in order here...)

As for the idea of allowing you to put the actual codes into the 28 byte PREFIX or SUFFIX parameters passed to SPOOL, I'm not sure that I understand how this would simplify things. As it is unlikely that you'd want to hardcode those strings into your program, it would seem that you'd have to store them somewhere in a file. Granted, you might have one big file with all of your printer code information in it, but it doesn't seem to me that much more complicated to store a series of prefix/suffix files in the ASHCFG: directory along with your printer init files. Note that if you used the approach of creating multiple printer init files which themselves specified the prefix/suffix files, then your application wouldn't need to explicitly deal with the issue at all. (Of course that creates even more file proliferation!) (On the other hand, that's a very UNIX-like approach to configuration parameters.)

Putting that aside, and ignoring for the moment the limitation of the existing 28 byte field sizes and question of how to distinguish between a string of printer codes and a filespec, it would seem that if you could do it in the PREFIX/SUFFIX parameters passed in XCALL SPOOL, you ought to be able to do it in the PREFIX= and SUFFIX= parameters in the printer init files as well. The problem I have with that is what syntax to allow. If one was to embed raw ESC sequences in the printer init file, that would make them inconvenient to print or otherwise manipulate. Other possibilities are hex octets, or C-style "escaped" characters. Each of these requires more documentation, coding/parsing, and testing than seems ideal just to avoid additional files. But I'll consider it.

Finally, on the matter of the trailing CRLF that VUE seems to insist on, I have little doubt that removing it would interfere with someone else's designs. My suggestion would be to create the files using a simple utility program rather than VUE.

After taking another look at my test program, I saw that it wasn't working with the "new format" XCALL SPOOL because of a typo in my test program. So at this point I say that it works as documented in both formats, and can only assume that you must have had a corresponding typo in your test program which prevented the old format from working.

Sorry for all the fuss. All is working fine using the new format, and I'm "in production." As for embedding the actual printer codes in the prefix and suffix fields, it was just a random thought that seemed reasonable to me at the time I was coding, but on balance the existing scheme provides greater flexibility and the benefit of my off-hand request, if there is any, is certainly not worth the cost of implementation. Sail on! Thanks for the comments. It was nice having just the feature needed in ASHELL when I needed it.