Had some recent oddities printing to what we call "system" printers off of our linux servers. These are most often legacy serial devices that we have connected to com ports or parallel ports, or even network -> serial devices.

In any case, the problem was that our reports were only compressing to 17cpi randomly even though we were sending the esc codes each time. We do this as a separate spool file... so we send a file to the spooler with just the compression codes, then the report, then another file to set the printer back to base 10cpi.

Like i said, it was working totaly random... after a careful look at the spool.log in 1,2 i discovered that the order that ashell and/or linux was picking up the files was sometimes reversed.. i.e. the report would get sent to the spooler first, then the esc codes, then the reset codes... even though the program was indeed sending it in the correct sequence.

The problem appeared to be in the timing the files were being sent to the spooler from ashell to linux. Adding a 1 second sleep between file requests has resolved this. So it was a timing issue of some sort.

Just wanted to pass this little morsel along in case anybody else fell into this same trap.

To avoid this problem in the past, we've always appended the "set options" and "reset defaults" files to the primary file. Then spooled only the single composite file, which is then always processed in the proper order.

Hmmm... Yes, I can see this happening. The "problem" is that, for reasons which, ironically, had to do with a need to support an application that issued thousands of rapid-fire spool requests while the user potentially swapped between PolyShell jobs, the actual submission of the file to the spooler is done in a forked job. So, in your case, the sequence of events would have been:

Fork child to spool file 1
Fork child to spool file 2
Fork child to spool file 3

Apparently the Linux job scheduler doesn't always play "fair", i.e. respect "first forked, first run" order.

Your sleep solution, although not particular elegant, is probably good enough (although I would reduce it from 1 second to maybe 1/10 of a second). A better solution, in my opinion, would be to use the PREFIX and SUFFIX features in a printer init file, to force the leading and trailing esc sequences to be bundled in a single print request. This would also eliminate the possibility of another job getting it's print requests interspersed with yours.

I could probably force A-Shell to wait for the completion of each forked child, which would be a good solution in your case, but would somewhat undermine one of the reasons for doing it this way, which was to minimize the slowdown of the main job while submitting a bunch of print requests in sequence. (Admittedly, that is a rare situation, but on the other hand, even without your sleep, it is still possible for two jobs to submit print requests simultaneously, and thus you could get a sequence like:

Job1 Print Request 1 (17 CPI)
- Job2 Print Request 1 (17 CPI)
- Job2 Print Request 2 (report)
- Job2 Print Request 3 (10 CPI)
Job1 Print Request 2 (report, now in 10 CPI!)
Job1 Print Request 3 (10 CPI)

PREFIX/SUFFIX would eliminate that possibility.

Good idea Steve.. never had an issue under amos, or linux for that matter until a few mos ago.. so perhaps a re-tool of this ancient routine is in order.

PS: do you do an xcall amos,append or is there an xcall out there that does this more elegantly?

Steven's solution is, of course, always going to work too. I can appreciate that it might be harder to retrofit into your application though, since you may want to delay making choice of printers until after the printfile has been created. You could add a post-report-generation, but pre-spool-submission routine that would make a new file with the prepended/appended codes, but that's exactly what the PREFIX and SUFFIX options in the printer init file would do for you.

So in theory you could implement them minimal change to the app. Although it would still probably require getting rid of the logic to submit the initialization and reset files, and instead to have more logical printers (i.e. each with a printer init file to set the proper PREFIX and SUFFIX commands.)

thanx 4 the feedback... we do have the ability to select the printer after file creation so that may be an easier fit.

We have used the PREFIX/SUFFIX for years and it has been very nice.

In your answer to your question Frank, yes, we generally use XCALL AMOS,"APPEND /I ..." to do the append. However, when the program is invoked from a DO file, we sometimes invoke APPEND there. We also use /PREFIX and /SUFFIX when that makes sense.

Correct me if im wrong, but if we go to using prefix/suffix do we have to have the codes stored in a separate file and then link them to each printer.ini file as applicable?

I believe you are correct. For each type of page setup you would have create a setup file, which would be referenced by /prefix. You would also need 1 restore defaults file to be referenced by /suffix. Then you could either specify the prefix and suffix files in your XCALL SPOOL statement, print statement in a DO file, or associate them with specific printer ini files.

In our print sbx, we create a "DSK00:[011,003]+UCS(jd'jobnam)+".PFX".
In that file we place the needed ESC stuff.
Then in the spool statement we include that filename.

We do not use suffix's because we all agreed to always send ESC setup's and the printer's are not used by any other application than ours.
But I am sure you could do the same with a suffix, maybe even have a default one to put on the spool line.

Just 2 cents, have a nice evening, if you east coasters are reading this at home, take a break.

I concur, and would underline Steven's point that you can pass the names of the prefix and suffix files as arguments to XCALL SPOOL, which might be the easiest way for you to adopt it, since it would not require creating any new printer init files, and would only require removing the extra XCALL SPOOL calls and adding the two new arguments to the one XCALL SPOOL call that remained.

Thanks much gents, and excellent suggestions... will be working on this in the morning.