I've got PDF-XChange installed on a WINDOWS machine, and I've added pdfprt.ini as my printer ini file on my LINUX server per the documentation. But LINUX (CUPS) has no idea what to do with something sent to that printer, because I haven't added the pdfprt (or PDF-XChange) printer to my CUPS configuration. What should I do to cover that base? My understanding is that the PDF-XC... software is for WINDOWS only.

The whole flow of this is not clear to me. The application is to add the appropriate GDI commands in the report file, which then gets passed to the GDI processor in ASHELL via XCALL SPOOL. (Does PRINT at the ASHELL DOT accomplish the same thing?) But were is the output of that process?

I assume I cannot pass the GDI commands directly to PDF-XC... on the WINDOWS machine (at least it didn't work when I tried it.)

So, bottom line, what is ASHELL doing with the output that needs to be passed to the WINDOWS machine?

You have basically 2 options to access PDF-X from A-Shell/Linux:

1. If you can count on the workstation running ATE, you can use aux port printing. For this, your pdfprt.ini on the Linux side should contain something like:

DEVICE = AUXLOC:PDFX

Whenever a file is printed to the "PDFPRT" spooler on Linux, (and yes, it works pretty much the same way whether you use XCALL SPOOL, File$, "PDFPRT" or PRINT PDFPRT=), the A-Shell interface to the printing subsystem will redirect the file to ATE aux port and tell ATE to pass it on to the client-side spool queue named "PDFX". You'll need a PDFX.INI on the client side which contains something like:

DEVICE = PDF-XChange
PASSTHROUGH = OFF
etc.

The main downsides of this approach are that every workstation that will request a PDF document needs to be running ATE, and you have to make sure to set up an appropriate printer init file for PDF-X printing on every workstation. (You can use ATSYNC.LIT for this, or ZTXFER.LIT, or ATEAPX.SBX, or a variety of other methods.)

2. You can use AshLPD. In this case, you need to designate a single PC on the network as your AshLPD workstation, and it must be running the ASHLPD.LIT utility. On the server side, you set up ASHLPR, and modify your PDFPRT.INI file to use it, something like:

COMMAND = SBX:ASHLPR,0.192.168.1,100:31515

This would invoke the ASHLPR print filter (BAS:ASHLPR.SBX), telling it to pass the file to the ASHLPD server at 192.168.1.100 on port 31515. ASHLPR scans the print file for auxiliary files (such as //IMAGE commands referencing other files), sends the auxiliary files and then the print file itself, along with instructions to ASHLPD to print it. In this case, the print queue name on the ASHLPD side matches that used on the server side (PDFPRT in your example).

ASHLPD takes some fiddling with, has very poor documentation, and only makes sense if you configure your PDF reports to not require any user intervention, since there wouldn't normally be anyone monitoring the ASHLPD server. The upside is that it only requires PDFX to be installed on the one machine running ASHLPD. Also, it offers archival, and the ability to reprint a file, even to a different printer.

Both of the above methods bypass CUPS entirely, which is another advantage (since CUPS is often difficult to configure/manage/debug).

ASHLPD does support the standard LPD protocol, so you could create a CUPS network printer pointing to it if you really wanted to. But that approach isn't really recommended because it's very difficult to debug and can't possibly support auxiliary files, which are common with GDI printing.

A long time later: I got that down (I'm using ASHLPD), and I'm getting ready to go into production. Is there a favored way of getting newly-created PDF files back to the LINUX machine, so I can send them off for digital signatures?

My thinking is I need to have an FTP server running on the WINDOWS PDFX machine, and my ASHELL application needs to FTP into the machine a second or two after the file is send to the PDFX machine to pickup the new file. Is anybody doing something more elegant?

how about using samba on the linux machine and having the pdfx machine create the files on the network drives?

I 2nd that motion. All in favor - bump.

I think I would have to agree with that, although with the proviso that you set up a special A-Shell 'device' (perhaps SMB0) to separate it from your DSKn devices, so as to confine any adverse performance or other Samba side effects to just that one 'device'.

If, for some reason you can't accept Samba and prefer the file transfer approach, but don't like the idea of setting up an FTP server on the AshLPD PC, another alternative would be run a second A-Shell process on that machine that supported a file transfer mechanism.

An example implementation of such a mechanism can be found in the TCPXFR program in the SOSLIB. The server side can be launched in background to listen on a specified port for transfer requests, and the client can be launched via XCALL HOSTEX (or even XCALL TCPXFR) to initiate a transfer. I've found it useful in situations along these lines where I didn't want to have to deal with a third-party FTP server, passwords, etc.

Thanks for the good ideas. I like the SAMBA idea. I'll review them with the person who maintains the WINDOWS machine, which I can't access directly.

But I'm wondering what Jack is thinking when he writes about confining "any adverse performance or other Samba side effects to just that one 'device'".

I'm certainly no expert on this, but my sense is that making a UNIX directory available to remote Windows machines via Samba imposes a layer of overhead on essentially all accesses to the files in that directory. (It is easy to demonstrate this effect with regular Windows file sharing, even within a single computer; I'm basically assuming that the same factors are at work with Samba, where the inter-machine communication is further complicated by differences in the UNIX and Windows views of the file system.)

Aside from general performance overhead, there is also a potential for operational anomalies arising from the differences between Windows and UNIX operate on files. Windows, for example, will prevent you from erasing a file that is in use, while UNIX will not; emulating that behavior may require some tricks, like tinkering with the privilege bits, that could lead to strange errors on the A-Shell/UNIX side that are difficult to debug. In particular, I remember an incident a few years back at a large site in which the privilege bits for certain files kept getting "corrupted"; we eventually discovered that it was caused by the Windows backup software which was re-interpreting one of the privilege bits as if it were the Windows "archive" bit.

So my recommendation is that instead of mounting the entire /vm directory under Samba, you instead create a separate tree, perhaps /vm/smb0, and just mount it. Define it as a logical A-Shell device separate from your other DSK devices, and just use it for files that need to be shared with Windows. In your case the operations on those files will be relatively simple (Windows side writes PDF files there, UNIX side reads), so the potential complications mentioned above are reduced to a minimum.

Thanks for the further insight.

We have been using samba for a long time with no problems. But we do not mount or map the Linux server on the PC's.

We have /vm samba mounted then we have the PC address it as:
\\HOST'IP\vm\miame\etc...

We have been using this method to aquire signature.jpg's from a signature pad app on the PC that we launch from ashell and the app writes the file to the server.

We have used this method to have PC's read deposit files from the server also.

But Jack's is a good suggestion to just share/mount a certain area of the server then address that from the PC. any PC.

Have a good time/day.
Ken

Your comment reminds me that perhaps an even better alternative in John's case would be to make the PC be the Samba server, and the Linux box the client. That probably wouldn't make any sense for the signature capture case (presuming that there are many PC's with a capture device, so it wouldn't make sense to have many servers and one client). But in the AshLPD case, the PC running AshLPD really is a "server" (a print server), and there is probably only one of them.

Good Point.

I'm in testing mode on my development server, and I've been using smbclient from the LINUX side to grab a file I want from the ASHLPD server, and that is working. I'm not sure that will be my final solution.

My big question right now is, how to I suppress the file display (view) and confirm activity by the ASHLPD server? This has to be automatic, no waiting for somebody to confirm things on the WINDOWS machine. I've checked Never, Minimized, and Just Exit in Preview Preferences, yet still the preview screen pops up and it waits for user input.

And one more question, do I have any control over the naming of the PDF output file? If I send the same text file over a second time, I want ASHLPD to overwrite the previous PDF file, and to not generate a new file name. Can I do that?

I'm confused about the preview (APEX) display issue. Simply checking the Never option should be sufficient to turn it off. Are you sure it's the APEX preview and not the PDF viewer we're talking about? Does it still happen if you use the File > Exit [No] option to drop to the dot prompt and then just use the PRINT command to print some sample file? (Enter .ASHLPD to resume)

As for controlling the naming of the PDF output files, yes, you should be able to do that with //PDFX commands. For example:

//;save file
//PDFX,Save.Type,2
//;stifle the dialog
//PDFX,Save.ShowSaveDialog,0
//;specify explicit filename to use
//PDFX,Save.FullFileName,\\server\dir\myfile.pdf
//;overwrite if it exists
//PDFX,Save.WhenExists,1
//;don't launch the PDF viewer
//PDFX,Save.App.Run,0

I'm talking about the preview function in ASHLPD. I print to my pdf printer in LINUX, ASHELL sends the file to ASHLPD on the Windows server, which "prints" the file to the PC-XChange 'printer' for conversion.

I see now that the preview and confirmation process is part of PC-XChange and not ASHLPD, which has done it's job by this time. So I'll look there for the solution.

And thanks for the tip on file naming.

It took some tinkering to get it all running smoothly, but my application can post to the ASHLPD virtual PDF printer and retrieve the PDF file back using Samba (smbclient) in a second or two. I didn't create any special shares, I just "login" to the WINDOWS machine, using the appropriate share name and password, and pull over completed files, as needed. My application will do an error message if it can't find the completed file in about two seconds.

I'm glad to see that what theoretically sounds optimal (having the AshLPD server also be the file server, so that Linux can be the Samba client and doesn't have to share any of its filesystems), also turns out to actually work in practice!