Once upon a time we decided that a barcode on top of the inventory tracking report would be very helpful. Indeed it is, but the report was just a good old fashioned text spool file. To add the barcode we switched from O specs to an “Advanced Function” Printer File.
The barcode printed beautifully and production increased, but for some reason positions 1-3 were overtyping. Checking the printer file everything seemed in order. The first field is 1 digit starting in position 1. The second field is 11 starting in position 3. Couldn’t be simpler, right?
Well, remember that this is AFP. If you don’t tell the printer exactly where to print each character it’ll make a guess & have fun doing so. What it did in this case, AFAICT was to attempt to print column 1 at the absolute right edge of the paper. Since the printer we were using couldn’t print right to the edge it had some fun and printed everything that would have fallen into the margin as soon as it could - in column 3. Easy fix: CHGPRTF and set the margins to .1!
That worked and the overprinting ceased but here’s the bug: When viewing the spoolfile through DSPSPLF the 400 argues with itself on where to display the data. Despite printing in column 1, the first field appears in column 4. No big deal except the report is 132 wide and now columns 130-132 are not displayed at all. That’s right, the data prints, but doesn’t display. For this reason I’m calling it a bug. AFP has been around for a few decades now and I don’t see any reason that DSPSPLF can’t correctly display the AFPDS spool files.
Now that I’ve said that I’m sure someone will remind me of a better way to get around having to set the margin. Some obscure compile option on the Printer File perhaps? Some configuraton on the writer? Hey, if you know - share the wealth!
Until next time…