Output device localization, Spool style

If all goes to plan I’ll be talking about a global  printer project at ASUG 2018/Sapphire.  To whet your appetite on a dry subject, some thoughts on device localization. Not regional character sets/code pages or administrative requirements for shipping addresses, but the pop-up label that tells someone where the output is going.  User experience, if you will.

In SPAD (print spool administration, there are 2 classic location fields.  Our legacy systems have a character limit (TSP03D or wherever) of 64 characters.  Trying to insert longer strings via the RSPOXDEV API won’t generate an error message, the extra characters are silently trashed.  I found this out by editing the text programatically.  Fortunately we have lots of exports.

(the last field should say “1st Floor/…”)

United States of America/Philadelphia/PA/2715 South Front St./1st Floor/PSD Center
1234567890123456789012345678901234567890123456789012345678901234

Sometimes the location would simply indicate “near Bob’s / Alice’s office”.  Great if they are still around, not so great if no one in the area knows who that may have been.  Other localization markers such as “Second Floor” or “Finance” might have been true once and now the printer is in the hallway in the basement.

Well, so what, you might ask?  People will figure out when their reports don’t go where they expect, and adjust somehow.  Not friendly customer service, so what can be done?  There’s usually if not always a system of record.  If you’re lucky, just the one, and the upload and download via a friendly interface is possible.  If you’re the normal unlucky one like me, you make your own luck by coding around the damage,

SPAD export fields:

 PASTANDORT = "Location Warehouse 1 HP Laserjet"
 PAMSG = "Location Warehouse 1 HP Laserjet"

Then with a key value (I prefer PADEST, but NAME may be a factor, do a string index in the language of your choice, substituting the official data for the ad hoc entries found “in situ”.

One snag I hit was the looked-up value had the widest geographical values (such as country, region or town) on the left side of the string.  Entering that into the fields above risked losing the most significant digits, as it were, as users already know what country or building they’re in.  They want to know which floor the printer is on.  So I had to reverse the fields in first in last out stack fashion.

I used Perl, as it was one of the possible text editing options and maybe the quickest to deploy in different OS scenarios.  Okay, Perl that generates SQL. Not using DBD or DBI.

Split, then Reverse.

 
 print " update prtr set location = '", $f_location, "' where printer = '".$f_prtr."' ;\n";
 # reversed string
 # PSD Center/1st Floor/1646 Sulphur Spring Road/MD/Baltimore/United States of America/
 @s_location = split "/", $f_location;
 @r_location = reverse @s_location;

It works, if not highly elegant.

What’s missing is the full interface specification and quality control checks, so funny spelling or other data issues are noted for correction.  And the workflow for when offices are shuffled.  And the GPS units that are in all the cool devices these days.  There should be a field for that, don’t you think?