On LINUX/ASHELL 5.0.1000.9
PRINT (at the ASHELL dot prompt) accepts print commands to non-existent printers, and acts like the file was printed, but of course it isn't. Example: PRINT XXXZZZ=test.lst yields the message TEST.LST, Total of 1 file submitted, XXX disk blocks.

The error is properly logged in the SPOOL.LOG file. It seems reasonable to expect PRINT to display an error message in this circumstance (and even more helpfully, a list of valid printers).

Sorry for letting this one slip through the cracks. The problem is independent of the operating system. A-Shell is satisfied as long as there is a printer init file for the specified printer name (XXXZZZ in your example). Beyond that, it pretty much shirks any responsibility for determining if the eventual outcome was reasonable or not.

I guess the argument for not bothering to figure out if the real print queue exists is that there is no law stating that a PRINT or SPOOL command must hook up with a real print queue known to the OS. It's really just a matter of forming a command line and then executing it.

The SPOOL.LOG just captures the stdout/stderr of the command line formed from the DEVICE statement and the lpr command. So even though the error messages are logged, A-Shell isn't exactly aware of it. That said, PRINT.LIT could go back and read the SPOOL.LOG and in the case of an error message, report that to the screen. That's a good idea and I may just add that to PRINT.LIT.

SPOOL.SBR, on the other hand, never returned any status, so it isn't clear what we should do with any error messages returned from the spooler. In the GUI environment, I suppose the message could be sent to the debug message window, but in the text environment, there is no such window, and there might not even be a status line. We could just output it to the screen, but it is common for XCALL SPOOL to occur at the end of a program just before returning to a menu, such that the screen message would probably never be seen.

The problem exists when the presumed printer ini file does NOT exist. Which is, to my mind, the big problem. In A-Shell 5.0.1000.9, on a LINUX host, when at the A-Shell dot prompt I enter,
PRINT XYZ=SRVEML.TXT
I get,
SRVEML.TXT
Total of 1 file submitted, 16 disk blocks

SRVEML.TXT exists, but I have no printer ini files named either xyz.ini or xyz.pqi on my system.

If I try printing SRVEML.XXX, which does not exist, I get a "%No files printed", which while not fully descriptive of the problem, is good enough to make me aware that something went wrong.

As for SPOOL, it seems to me it should have an optional return argument tacked on at the end, which could be used to report various printing problems that SPOOL/EZSPL detects.

I probably would have added a return parameter to EZSPL/SPOOL a long time ago, except that:

a) SPOOL already has 10 optional parameters, so it wouldn't be very easy for programmers to access the new parameter and thus probably not be used much.

b) Because the mechanism never returned any status, the implementation would need a substantial amount of work to see that a consistent and meaningful status was returned. Also, every application that prints would need to be modified to check for the return status and do something sensible with it.

Those problems are not insurmountable, but aren't trivial either.

As for PRINT.LIT not complaining if the printer init file doesn't exist, that seems like a more fundamental complaint, although I think it arises from a decision (or half-baked idea) some years ago to allow printing directly to an OS print queue with default options (bypassing the A-Shell printer init file). For example, if I have a CUPS print queue named bro but no printer init file named sys:bro.ini or ashcfg:bro.pqi, I can still print using this command:

.print bro=sys:ersatz.ini

You can see this in the opr:spool.log:

lpr -Pbro -#1 /vm/miame/dsk0/001004/ersatz.ini

If I try the same thing with xxx instead of bro, then I see the error in the spool.log:

lpr: The printer or class was not found

That's not to say that PRINT couldn't check to see if the printer existed, but it seemed more efficient and modular to centralize that kind of logic within the core A-Shell printing logic, rather than in a wrapper function like PRINT.LIT or SPOOL.SBR. (Which might have been fine, except for the lack of a way to return status.)

You make a good argument that the current design is lacking. It's not completely clear, though, what your objective is. If you want to get an error message on the screen where people can see it, we could just have the central print routine copy the same message that now goes into SPOOL.LOG to the screen (or in the case of ATE, to the debug message window). But while that might make sense for you, I'm not sure it makes sense for your end users. Returning a status code might make more sense to the application designer, but do you really want to go back and add that logical to all your printing routines?

Perhaps some kind of test-print function that you could use when defining a new printer to verify that it exists and that you can actually make output appear on the device?

Good points that I did not fully consider, I'm folding my tent and leaving the scene.

It isn't a problem in the big scheme of things, it was the contrast of what happens when I try to PRINT a non-existent file and what happens when I try to PRINT to a non-existent printer that jumped out at me. And I never realized I could print directly to a system printer without having a related printer ini file. And, I knew that dealing with the issue in SPOOL would be difficult, I just thought it was trivial with PRINT.

Thanks for the commentary.