Now, you would THINK that there couldn't possibly be any saturated stars in the output allstar list, but you would be wrong. It turns out that some years back "allstar" was modified so that any saturated pixels were ignored in doing the fit, but if there were enough unsaturated pixels left within the fitting radius, it used those instead. Now, that might have been reasonable for some data, but it wrecks havoic on our MOSAIC data where the sinc interpolation in the geometrical correction has left a moire pattern next to saturated pixels. In THEORY there shouldn't be any saturated stars in the input list to allstar, but what happens, invariably, is that some little faint guy is sitting near a saturated star and during the allstar run it migrates to the saturated star. Not good.
unsat.cl takes care of these by dumping the x and y positions from the *als.2 file to "tempalsxy" and running aperture photometry on these positions. Things that show up with "PIER=305" in the output mag file (indicated there was a saturated pixel within the 3.5-pixel photometry aperture) gets put into a file called "badxy". Next a fairly simple FORTRAN program edals.f is called, which creates an *.als.3" file, in which the badxy guys have been eliminated.