MaskKeeper, it should be noted, is a kind of garbage collector, night watchman and repair shop for mask data. It runs early in the morning and late in the evening, and its purpose is twofold: to issue notifications (both routine and warning) about mask events, and to tidy up or repair mask data if inconsistencies are detected. If an observer has entered two masks with the same GUIname, MaskKeeper will fix this and send a warning message. If ingestMask should somehow fail before it assigns a millseq code, MaskKeeper will fix this. If a mask is incomplete or inconsistent, MaskKeeper should notify the Observer and the Mavens.
This code is attached to the blueprint in two places. First it is assigned (as above) to any unmilled (status 0) blueprint (update the millseq field in MaskBlu table). When the mask has been successfully scanned and associated with its bar code, its status changes to 2. The new record inserted table Mask (metal masks) records not only the barcode assigned to this milled instance of the blueprint, but also the guiname and the millseq code. So this is the second association of blueprint and millseq. Both guiname and millseq are also engraved into the mask surface.
One of the many things that MaskKeeper does is to check the millseq codes for recent masks (those which are not marked as 'milled'). Every blueprint which has not been milled, or is marked for remill by resetting its status to 0, should have a millseq. If any of these do not have one, MaskKeeper assigns the next available sequence code.
For any mask that has been scanned (a record w/the same millseq, bluid now exists in table Mask), the millseq code in the blueprint should be nulled out. MaskKeeper makes sure that for all blueprints for which a matching record exists in the Masks table (BluId, guiname and millseq must all match), the status is set to 2 and the millseq nulled out.
Thus the blueprint only has a millseq code during the period between its submission as part of a mask design, and MaskKeeper's recognition that the scanning process is completed for this mask.
If the blueprint is marked for remill then it will be assigned a new millseq on MaskKeeper's next run.
The next millseq to use was at one time inferred from the MaskBlu and Mask tables, but this proved unreliable. Therefore it is now derived from a one-record table 'millseq', which stashes the last used value. Any app that assigns millseqs needs to update this table when it is done, with the current "high water mark".
Obviously we do not want conflicting access to this table, which might cause an overlap in seequence and duplicated sequence codes.
As we noted above, ingestMask usually assigns millseq codes to blueprints after ingestion. Therefore it's important that the two apps don't tread on each other. Knowledge of MaskKeeper's cron schedule is hardwired into ingestMask so that it will not interfere with MaskKeeper's assignment of millseq codes. It will skip this step if the time is within one hour of the cron times for MaskKeeper.
Special Case: If a mask is marked for remill in Hawai'i, locally, perhaps in case of an emergency, then it receives a special Hawai'i sequence code, which consists of "@" plus the 2nd char of the next valid mill sequence code. Thus if the last mask marked for milling was coded RF, the next valid codw would be RG. If a mask were marked for remill by the official method (web page) then the remilled mask would be RG; but if the remill were requested in an emergency, locally at Keck, modifying the mask status flag on waiaha, then a "temporary" mill sequence code would be assigned: "@G"
de@ucolick.org