CHASER is implemented in the Eastern District of Michigan as a trusted procedure of CaseMgt as understood by the invoke utility.
The files that make up the CHASER distribution were originally intended to be scattered throughout the ICMS directory structure, which would complicate maintenance by blurring the distinction between ICMS files and CHASER files. Modifications have been made to allow CHASER to function properly with all of its files located in or under $DBPATH/../chaser so there is no problem with identification.
Much of what was originally distributed through various CHASER files has been centralized in the trusted script itself, $MIED_INVOCATION.proc/chaser. Environment variable settings, e.g., for the common CHASER directories, are set here rather than duplicated in multiple CHASER scripts.
with no additional arguments produces the usual CHASER menu. The $CAPDIR/chaser script has been modified so that a user not in the CHASER authorization file is given access to docket sheets instead of being completely refused access. Therefore, CHASER is available to all users for docket sheet inquiry, without any need to mess with the authorization file unless a given user needs other CHASER reports as well.
CaseMgt chaser pmo.incruns the incremental Pending Motions extractor. The trusted script uses the submit scripts in $CHASER/hostfiles to do the work, but makes some common arrangements beforehand. The trusted script arranges for each extraction to be timed and for a full log of its activity to be mailed to a responsible user. That user's name appears only in this one place, rather than scattered through several scripts. The trusted script runs the extractor with a reduced CPU priority ("positive niceness") so that CHASER extractors will not siphon time away from user-requested reports that might be running at the same time. Also, the trusted script redefines the batch command so that, when it is used by the submit script, it will properly place the job on the appropriate queue with an appropriate title.
The trusted script will run an extractor only for a user with dbmaint authorization; see get_auth(unify) in our trusted procedure manual pages.
While the $CHASER/hostfiles/*.submit scripts, and their companions $APPDIR/*.split are used for extraction, they have been heavily modified to run more efficiently, reduce storage space consumed by intermediate files, perform processing steps concurrently where possible, and include all diagnostic output in the single mail message sent to the responsible user for easy reference. These modifications resulted in submit scripts that are, almost paradoxically, shorter and clearer than the originals.
The modified extractors depend on the existence of the following fifos (named pipes):
The fifos need be created only once; they are reused and never removed. Accidental removal of one of these fifos should be considered as a possible cause if an extractor stops working.
The index files themselves live in the directory $CHASER/index and have been renamed for clarity. The file once called case.flat (derived from the 'cases' relation) is called case. What was called party.flat is derived from the 'person' relation and is now called person. What was called prid.flat comes from 'ptycas' and is now called party; it includes records from 'ptyaka' as well as 'ptycas', allowing users to locate cases given a party's alias name.
A fourth index file, longname, contains information from the ICMS prlname table, allowing users of the Web-based query system to look up parties by the longer, more readable names. This capability has not yet, however, been added to the older SDLP daemon used so far only for a text-based user interface.
The index files are generated by merging records selected from ICMS by SQL with records from a (growing) set of "master index" files produced when cases are archived from the database. Additional files in the master index format can be created by conversion from non-ICMS sources such as Courtran and, if placed in the appropriate directories, will be merged in as well, creating a completely integrated index.
The person and party supplementary files will need some way to distinguish ICMS person ID's from Courtran ID's, since the sets are not necessarily disjoint. Since the set of Courtran IDs will not be growing or changing with Courtran out of the picture, it is possible to simply renumber the Courtran IDs consecutively, starting with the next available "per" counter value in ICMS, and bump the ICMS counter by the number of Courtran IDs. That approach effectively reserves a "hole" in the ICMS person numbers and merges the Courtran persons into that hole.
An earlier version of the index generating scripts depended on intermediate files created from the master index files in a separate step during archiving; these files would be strategically presorted to reduce the work done during nightly index generation. Although the performance was speedy, that approach was less comprehensible and more vulnerable to careless procedures; moreover, it was finally determined that the original design for the intermediate files did not include enough currency information to guarantee that the merging done overnight would be correct. Therefore, the current implementation rebuilds the inverted index files directly from the masters, slower though it may be, and the old supplement directories have been eliminated.
It is worth noting that the slowness of the current implementation is mostly due to the interpretation overhead in the Tcl language, and is roughly 95% user-cpu cycles; this means the index generator should respond very well to increases in CPU speed such as are expected in cyclical replacement.
The addition of supplemental index information to the nightly index runs is described above. Using this information, the PACER 'flatinq' program provided with CHASER is able to look up archived and Courtran cases as well as the cases CHASER was designed to provide. When a docket sheet is requested, flatinq calls the 'dodocket' script, which has been modified to take advantage of the merged docket fiche access system developed by this court in May of 1992. The modified dodocket then calls /courtshare/mied/icms/docketfiche/getdkt, which is a component of the docket fiche system developed entirely at this court, but which works and looks (from the "outside") exactly like the 'getdkt' script provided with PACER.
Some CHASER report formatters (i.e.
the modules that actually interact with
CHASER users, as distinguished from report extractors) have been or are being
converted into a form compatible with the ICMS report supervisor so that they
will ultimately be requestable from ICMS as well as from CHASER. Likewise,
the ICMS report supervisor is being modified to simplify requesting other
ICMS reports from within CHASER. These capabilities should be available
shortly after we go live with 93CC01 ICMS. Details of the ICMS-compatible
CHASER formatters can be found in /courtshare/mied/chaser.rpt.
Authorizing Users
The original "judgefile" was not in third normal form, since there was an entry per user, but each entry contained complete information on the associated judge. With multiple users authorized for a given judge, the judge information would be redundant, and updates to judge information would have to be made in many places. Without any authorized users from a given chambers, CHASER would have no record of the judge.
Judge information doesn't need to be in that file at all, since it can be obtained directly from the ICMS database. This simplifies updating judge information: it only needs to be done within ICMS.
The only per-user information needed is the user's identification, the menu to use (doshort or dofull), a y/n indicating whether the user can select a different judge to report on, and a judge's initials if applicable. This information is kept in a standard authorization file as used by our UNIFY trusted procedures, $MIED_INVOCATION.auth/chaser. This file can be edited with the command:
$ CaseMgt auth chaser