Hi everyone, This is directed to all you printer experts out there.

We have a customer running ATE and AIX/Ashell and they now have a printer with three paper trays, and would like 3 printer/queues set-up depending on what paper they would like to print on, any one know the best way to do this now?

I created a test LPT55.INI with the following here on our test system, but wondering 1) is BIN= an actually INI command, and 2) does the INI or a PQI file need to be transferred locally to the PC before ATE even knows about it.

Thanks.

I know this is a bit of a hack, but we install the printer 3 times under windows, each with its own default tray, then the user selects the printer based on the tray.

Steve, I use bin= in my pqi files. I create a pqi file on the fly each time I send a print job to a printer. I don't use ATE, so I don't know the answer to that.

Thanks Guys,

I think I may go Herman's PQI route, just now wondering does the PQI need to be transferred locally for ATE to know or is it clever enough for just the one copy on the server.
(Wish I had a duel tray printer here to try this!)

Most laser printers have 2 bins. The regular paper bin and 'manual' feed. That should be good enough for a test.

Thanks Tom, I may wonder about the office to see if I can borrow/use someone laser printer.

Unfortunately, the BIN command must be in the local (i.e. ATE/client) PQI file - putting it in the server's INI doesn't accomplish anything. (Same goes for most other printer init commands, i.e. ORIENTATION, PITCH, etc.)

It might seem like a good idea if any such commands included in the server's printer init were forwarded to the client automatically, but the downside of that is adding to the confusion of who's in charge. Taking for example, Frank's technique, what would we expect if the local printer configuration for LASB3 defaulted to BIN3, but the server's printer init contained BIN=2? It's not UNreasonable to give the server the upper hand, but it does take away the ability for a new user to come along and decide that for her local printer, what the server calls BIN3 is really BIN1.

And that capability was a fundamental assumption in the design of the scheme. In other words, the idea is that the application would define a number of logical printer queues with names (corresponding to printer init file names). In the case of printers visible to the application server, users or site administrators could then edit those logical printers to associate them with physical printers. In the case of ATE, we have a second level of indirection, whereby the site admin on the server might declare that the RECEIP printer will be redirected to the ATE client, while still allowing each ATE client to have some control over how it routed requests to print on the RECEIP printer to a physical printer.

But, whenever you have a hierarchy like that, there will be situations where you'd like to change the order of control (in this case, allow the server to override client printer settings). (We already have that in the case of SWITCHES, which if specified by the application, should override any conflicting switches all the way down to the local printer.)

I suppose we might compromise by having the server's printer init settings only override the client's printer init settings that hadn't actually been specified. (I say partially, because that would still take away the local power of Frank's solution.) But even setting that aside, printing is already too complicated, and having another level in the hierarchy isn't likely to simplify it.

If we just accept the scheme the way it is, then what you'll have to do is transfer the PQI file from the server to the client prior to printing. One approach would be to use ATSYNC. Another would be to use MX_FILESTATS to check if the ATE copy of the PQI existed, and only perform the transfer (perhaps with ATEAPX.SBX or AG_FTP) if it didn't. (In fact, you could argue that any time the server printed to a logical printer for which the ATE client did not have a local definition, the server's PQI would be transferred to the client.)

In the case where they both exist but are different, it would take a judgment call to decide whether the server's copy should replace the client's. I would argue for the other way around, to allow the client to customize the printer configuration based on local knowledge that the server can't possibly have. But admittedly the mechanism for local editing of PQI files falls a bit short of "intuitive".

This is a bit of a murky area, in that there are too many ways to get from A to B, but all of them require more programmer work than seems ideal. Perhaps ATE should support a built-in printer init editor, making it easier for users to customize local printer settings. I've resisted that because the PQI/INI scheme is so wonderfully open-ended, that any attempts to create a proper form/editor for it would mean a lifetime of updating that routine. Also, any such editor that was comprehensive might well be too complicated for the average user to navigate anyway.

But, as always, I'm open to suggestions. Anything that can make it easier for users to get the kind of output they want, where and how they want it, has got to be a good thing.

As a postscript, APEX seems like a big step in that direction, but mostly deals with the kind of issue you raise by leaving to the user to configure the printer via the printer selection/properties dialogs, which is less than ideal for repetitive and other situations where the application really does know better than the user.

OK now I know i'll first have a little play here and see if I can drop some code into our Spooler subroutine to see if its ATE and a PQI file exists, if so, transfer it locally.

It looks like I did very much this a few years ago (and you have just reminded me) when creating our PDFX.SBX and I see I can use lots of the same code:

and

Thanks for the pointers.

OK using something similar to the above code I now lookup if a LPT{printer}.INI in SYS: exists on the AIX server, if so I transfer it to the local PC and this all works.

(I do have to change the printer name to say LPT1X.INI if the printer is between 1 and 9 on the server otherwise its an invalid windows file name)

Now I created a SYS:LPT0.INI on our AIX server with:
When I print this does copy the LPT0.INI to the ..\ATE\dsk0\001004 folder correctly.

But I would of expected it now to print out in Landscape? or even apply an auto pitch? but it looks the same as it did before.

Am I wrong, or any pointers to what im missing..
Thanks.

PS.
Im currently using .INI files in [1,4] and there are no PQI files in [1,7]

I think the problem here is that you are putting an LPT0X.INI file in [1,4] on the ATE client (good so far), but you are not telling ATE to use that printer. Instead, you've told it to use \\STEVEX\HP1120c, so it doesn't know to look at the LPT0X.INI file.

There is an unfortunate complication here, in that the printer init on the server and the printer init on the client cannot possibly be the same. The one on the server should specify DEVICE=AUXLOC:xxxxxx while the one on the client, called xxxxxx.INI or xxxxxx.PQI, should specify DEVICE=, plus all the other Windows-specific options, like BIN.

My recommendation would be to set up a parallel LPTxx.ATE file for each of your LPTxx.INI files on the server, where the .ATE version contained the ATE printer setup for that printer.

Or, perhaps you can just parse out the DEVICE=AUXLOC:xxxxx command in the server's printer init to determine the xxxxx name for the client printer init, and then send it. (This would also allow you to fix the LPT0-LPT9 problem without another set of special logic just for it.)

In other words:

1. The server wants to print to LPT1.INI

2. So it looks at SYS:LPT1.INI to get the associated ATE printer name following the AUXLOC: (and if there is no AUXLOC:, then it's a server-connected printer and nothing more to do.)

3. Otherwise, it locates the xxxxxx.ATE file, perhaps conveniently stored in ASHCFG: on the server, and transfers it to the client as $ATE\dsk0\001007\xxxxxx.PQI

4. Then XCALL SPOOL, file, "LPT1" (as normal)

Another variation would be to handle the above logic in a COMMAND=SBX: routine included into the printer's LPTxx.INI file. It could then perform steps 2 and 3 above, so the application wouldn't have to do anything special.

ah! I see now...
OK I think im giving my self a C.O.W here

Meanwhile, tomorrow i'll parse out the DEVICE=AUXLOC before transferring the file, hopefully that may do the trick? i'll rather not create any other setup/.ATE files unless I really have to as I know they get forgotton over time so causing more C.O.W's in the future.

What might be nice would be to support some kind of ++IF WINDOWS, or maybe ++IF ATE conditionals in the printer init file, which would allow you to have two sets of parameters in one printer init. (For the most part, the Windows-specific stuff is ignored by A-Shell/UNIX, but I'm not sure how you can get around the fact that the DEVICE= statement will need to be completely different between the server and client versions of the printer init.)

Perhaps while you're parsing the file to get the AUXLOC: parameter, you can just create a new Windows/ATE version of the original printer init on the fly.

OK, getting there...

Here's a new example LPT1.INI on our AIX server:

What's PCPRINTER= you ask? well...

When the printer is selected in the Madics spooler I parse the INI file and completely replace the DEVICE=AUXLOC:LPT1 with a new syntax I made up called PCPRINTER= creating a:
DEVICE=\\STEVEX\HP DeskJet 1120C

This is currently saved in DSK0:[7,999] as LPT1X.INI and finally transferred to $ATE\dsk0\001004\LPT1X.INI

and...

Now im seeing the effects of the other switches like FONT and ORIENTATION etc finally...

The true test will be at the customer on his multi bin printer.

Question, can any one see a reason why I cant use PCPRINTER= in the Server's xxx.INI file, or maybe we can come up with a more common syntax.

...Getting there...

A-Shell ignores printer init statement that it doesn't understand, so you should be safe leaving your PCPRINTER= in the server-side init file.

(Of course, since the statement only has meaning to you, you could also comment it out, unless you're using INIX.SBX to parse it, in which case INIX would ignore any commented entries.)

As for the LPT1 vs LPT1X, I'm not sure where you are applying that transformation, but maybe you should have just used DEVICE=AUXLOC:LPT1X directly? (Or, maybe just add an X to all of the Windows-side printer init files, eliminating the need for some logic to decide whether to add an X or not.)

Ah OK so its safe to add a X to the end of any printer number, even say LPT50X.INI (I thought it was only LPT1 to LPT8 used by Windows) that will save a few lines of code.

Thanks the help, and i'll give it a go at a customer next week.

Everyone have a fun weekend.

Im back to this, and while trying to set-up a LPT1 on the customers system that points to a network printer im getting a "Windows printer [LPT1] not defined on this work station" now as my local PC's LPT1X.INI say's DEVICE=\\STEVEX\HP Laserjet P2050 Series PCL6 does this message really mean it is unable to find the "HP Laserjet P2050 Series PCL6" printer/queue? - then i'll know what direct to look next. Thanks.

and this screen shot is from the customers LPT4 on their system and for testing (via VPN) pointing it to my own Desktop's HP DeskJet and get a similar message.



Im trying to decide if its my set-up, or printer network naming issues and access.

The problem is not the DEVICE definition on the windows side, but on the server side. (You need to replace AUXLOC:LPT1 with AUXLOC:LPT1X)

AYKIK (As I know you know), when you ask Windows to lookup or open "LPT1.INI", it ignores the ".INI" and tries to open up the port device LPT1.

Perhaps you were thinking that A-Shell/Windows automatically added "X" to the end of any filename starting with LPT plus a digit? Perhaps it even did that in the DOS version (I don't remember), but there is no such built-in workaround logic in A-Shell/Windows. You have to avoid the illegal filenames by not using them.

ah, OK yes I was thinking Ashell (ATE) automatically added an X to unsupported windows file names like LPT1, changing it to AUXLOC:LPT1X soon sorted that here in house.

Trying it at the customer over VPN looked like it worked far better well, til I got a:
but hopefully thats just because im over a VPN and not on their network.

The downside I got the customer to try and he said: "We get an error message "A shell has encountered a problem and needs to close down" doh, so the story continues, and I think i'll have to work out some RemoteDesk with him to get to the bottom of that. Otherwise, I think we are getting close to a solution.

Thanks for pointing us in the right direction.

Not sure what the A shell has encountered a problem and needs to close down message was as when I tried it over a remote desktop connection on a new ATE install (well 1182.2) and yay it printed fine. They are all currently on 1174.4 (AIX Ashell version 1166.1), anyway they will re-try it again when they are in the office next week. But I have a feeling from talking to someone there my BIN=UPPER still printer to the lower paper tray.
we shell see.....

Finally I can close this off with it finally printing out to the right printer tray, this was after all the above and a little printer debugging/ATE tracing to find we needed: BIN=USER5

Glad to hear it. I should have commented on your previous post, but figured (apparently correctly) that you knew how to debug the BIN naming problem. It's worth clarifying it though, in case the problem and solution weren't clear:

BIN names (e.g. UPPER, MIDDLE, etc.) are not reliable. Printer manufacturers and driver writers have free reign to assign names any way they like. In order to come up with the correct name (or number) for a particular tray on a particular printer, start with a guess (i.e. BIN =UPPER) and then use SET TRACE LP ON (see Printing Troubleshooting Techniques ) and print a sample. This will display the list of valid names and associated numbers (as shown above). Then, unless the names are clear and obvious, you may need to use a bit of trial-and-error to determine which name goes with which physical bin.

Thats what I did to get the list of USER codes and the trays , just that SET TRACE LP ON did not help on ATE (as that's server side) I had to enable them on the Client/ATE side: LP and I think I also needed ATE or another one to get the complete printer BINs/debug/trace output.

Good point. So, just to be thorough (for anyone else reading this):

To enable the LP (or any other trace) on the ATE side, Control+Shift+DoubleClick somewhere on the ATE window, choose the Show Debug Dialog option, then right click on it to access the individual trace options.

A little follow-up on this:

My UNIX Printer INI File looks a little like this:
My SPLPQI SBX creates the following from it and prints via ATE:
All fine.

But the side effect is we are getting a lot of Unrecognized printer init command in the UNIX ashlog.log file, can these be supressed in any way?

Snippet from Customers ashlog.log.

One way would be to comment them out, but in a way that your SPLPQI.SBX would recognize as meaning that you wanted to include them in the PC version, e.g.:

The other way would be for me to remove the logging of such "errors" entirely (although then you might overlook a typo or other problem and waste a lot of time trying to debug it).

Good idea, I may well look into that... Thanks.