One of our shy developers has posed this question, which seemed worthy of a public posting:

Under Ashell/Unix LPT##.INI files have the COMMAND=… option to execute a NATIVE command - such as cp $FILE /vm/miame/dsk0/071070/ (and 071070 happens to be our SAMBA: dir regardless of which LOG created the printed file).

Question – Is there anything in the LPT##.INI options that would (after the above COMMAND= made a copy of the printed file to SAMBA:) issue an ASHELL command – such as MOVE PRT1:=$FILE’AS’AMOS’FILESPEC (which in this case would resolve to MOVE PRT1:=PRT0:[71,8]FILENAME.PRT)?

Note that the reason a second COMMAND=… line (if it is even possible to issue multiple COMMANDs in a .INI) would not work is that there are many 0710## directories and a native mv command does not let us “wildcard” and embedded part of the $FILE’s specification (i.e. no mv $FILE /vm/miame/prt1/071*/).

I checked all available documentation and COMMAND= was all I could find. If what we are looking for already exists then fine. If not it is no big deal and we will just perform the desired MOVE (i.e. MOVE PRT1:[]=PRT0:[]*.IVC) nightly as part of cron processing.

The COMMAND= feature of the printer init file turns out to be so useful, including for operations entirely unrelated to printing, that further enhancements to further exploit it might be called for.

As it stands, only one COMMAND= is supported. (If you put multiple ones in the printer init file, only the last one will be processed.) Also, if the printer init contains a DEVICE statement, then the COMMAND operation will always take place first, i.e. before printing. Which leads to one suggested enhancement: a second COMMAND that takes place after printing (which would be useful for archiving printfiles after printing, although you can always archive them first and then print them from the archive location.)

I'm open to further options here, although for the immediate situation, the one workaround that you have available is to replace your COMMAND=cp $FILE ... with a custom SBX (e.g. COMMAND=SBX:MYCMD,... that executed all of the necessary operations by means of xcalls to HOSTEX, AMOS, MIAMEX, etc. You can pass a couple of dozen additional parameters to the XCALL so you aren't particularly limited there. You can even print from the XCALL, although you have to be careful not to print back to a printer that will cause an infinite loop.

Does that work for you? There are some sample printing subroutines (aka "print filters") in the [907,29] directory of the SOSLIB to use as a starting point.

Shy! Obviously you have never been around us after a couple of beers!

As far as the immediate solution - yes, a SBX:MYCMD (based off of PFILTR.BP[907,29]) would work fine to do the necessary parsing and building of either native commands or Ashell commands (for the copy and move). Thanks. However, since this question was originally asked it now appears we will be sending these files directly to a web service so that question is now moot (but I'll keep it in mind for future requirements).

As far as enhancements to the lpt's .INI options - well, more is always better!
- Multiple COMMAND= statements do come to mind, and if you could specify whether each executed before or after the DEVICE then so much the better. My suggestion would be to just have them execute in whatever order the user placed them in the LPT##.INI file (especially with the complication added by multiple DEVICE statements, see below)
- How about an ASHELL'COMMAND= option to issue Ashell commands (such as COPY and MOVE). This would probably mean that we would also need something like $ASHELL'FILE so we had the Ashell format filespec to work with (maybe quoting $FILE would do the same thing? i.e. "$FILE"). The nice thing about this would be that we could then use Ashell wildwards which are sometime a lot more handy than native unix commands (an example would be ASHELL'COMMAND=MOVE PRT1:[]=PRT0:[]$ASHELL'FILE
- Once or twice multiple DEVICE statements would have been handy where we always needed to print something to multiple printers (say a receiving report to the warehouse printer and then a copy to the accounts payable printer)

I'm sure others will also have lots of additional useful enhancements.