Automating the production of bibliographic records for MEDLINE

Links to Feeds:
Publications	RSS
CEB News	RSS

CEB Projects

page

Automating the production of bibliographic records for MEDLINE

10.2 Admin workstation

When an error occurs, i.e., when a particular journal issue or any of its individual article pages encounter a problem at one of the stages in the workflow, a supervisor ("administrator") has to decide on a corrective step. The Admin workstation software, written in Visual C++ (6.0), allows the supervisor to check on the status of a journal issue in the workflow, and in the event of an error, to request that a process be repeated for a particular journal issue or a page. Every process in the workflow records an error in the ErrorReport table in the MARS database and the process stage is set to 9998 (error stage) in the WorkInProgress (WIP) table. The supervisor uses the Admin module to check the error and decides which MARS process needs to be redone. He/she sends the journal issue back by changing ProcessID and ProcessStage in the WIP table, and switching the integer bits of the PageMasks. The supervisor may also request a particular operator to redo a process by changing the OperatorID.

The Admin application is designed to look like Windows Explorer with split windows containing four views, one on the left, and on the right three views which may be switched back and forth for convenience. On the left, the Tree View displays the journal issue affected (MRI number) and its pages. The three views on the right window include: the Error Info View displaying the error information; the List View that opens two other views (List Info and Report Info) to display detailed information pertaining to the journal issue and the individual pages affected; and the Mask View displaying the current page mask settings of the individual pages.

Admin is also designed to adapt to changes in the MARS workflow. Since the workflow may be changed by modifying the ProcessQueue table in the MARS database, Admin builds the data presented on its GUI in line with the new workflow.

Figure 10.2.1 Tree View showing the journal issues affected (Error MRIs) and those inspected.

Figure 10.2.2 Error Info View on the right displays the information on journal issues or individual pages.

Figure 10.2.3 List Info view

Figure 10.2.4 Report Info view

Figure 10.2.5 Mask View displays Page Mask. The masks can be set up so the 32-bit integer is set for reprocessing.

The functionality of Admin is as follows. The supervisor selects a particular journal issue (MRI) on the tree view, and information related to that MRI is displayed: the PageID, PageSequence, NumberZone, FirstPage are displayed on the first view, LabelID, LabelField, LabelType, Confidence (if page is selected on the tree view).

The Information View displays MRI, current process, current stage, module message, user message, error information, and error solution. The new process and new stage are displayed in a combo box to assist the supervisor to choose a new process for reprocessing the journal issue.

The supervisor can use the Mask View to set up the PageMask by clicking on the Select Solution button after he/she sets the new process mask or a new process id or process stage. A dialog box appears to allow the supervisor to choose the pages that need reprocessing. The Mask View shows which process(es) failed and requires to be redone. The information pertaining to the new choices will be saved to the database for reprocessing.

Admin is designed so that a separate thread checks the ErrorReport table every 3 minutes for a new record. If one exists, it will be added to the tree automatically. Also, a blinking red light indicates there is at least one error to be handled.

Other actions the supervisor can take include:

Double clicking on the MRI in the tree view activates an embedded Label Browser that can be used for browsing the data.
Double clicking on Page in the tree view results in displaying the image of that page on a modeless dialog box, so the supervisor may move from page to page to load the corresponding image
Double clicking on the Label (bibliographic field) in the list view results in a display of the text in that label in a modeless dialog box.
Using the Transfer Data/Object dialog box, the supervisor can transfer data from one server to another.
Using the System Type Check dialog box, the supervisor can check whether the journal issue is compliant (amenable to automated processing) or not

A future functionality will be an audit trail to keep track of all the actions of supervisors when using the Admin system.

10.3 Crash Patrol

Since any downtime in a production system is a serious matter and needs to be minimized, it is important to have an automated alert in case of failures. The purpose of the Crash Patrol subsystem, implemented as a multi-threaded Windows C++ application, is to alert the supervisors and technical support personnel automatically in case a MARS daemon fails. This module is designed to give a quick warning of the crash of an executable program, and complements other database-centered techniques that also detect deadlock or inactivity, though more slowly. When such a crash occurs, Crash Patrol sounds an audible alarm through the facility's speaker system. The alarm volume may be customized for each process that is monitored. Remote notification by email is also possible. To use this feature, the current implementation requires installation of the Windows NT/2000 SMTP Server, though for the future, a version that handles SMTP more independently might better allay security concerns.

Crash Patrol also has the capability to restart crashed programs, although most of the MARS daemons have been programmed to restart without manual intervention. If restart is requested, Crash Patrol will sound an alarm only if the restart fails.

Upper window. The main window of this dialog application has, at the top, a snooze bar to turn off the alarm sound. A button (Alarm Reason) offers textual information about why the alarm sounded, although with experience this may be quickly elicited from the lower "Processes to Watch" window. The top list pane shows all processes running on the machine, similar to the Task Manager in Windows NT/2000; system processes can be screened out. This pane is initialized at startup and then refreshed either manually or at a desired frequency. Substring search within this list is the detection mechanism. The lower pane shows seven MARS daemons. For each, a traffic light is either green if it is running, red if it has stopped, or gray if it does not matter (indicated by toggling "Watch?" to "No"). Toggling of the Yes/No columns is done with buttons at the bottom.

Lower window. This window appears on pressing the "Details" button in the main window. The example shown here is while exercising the alarm not with the real Pattern Match, but with Notepad. The restart command line shown has bad-text "notepadx.exe" (instead of, say, "notepad.exe") to test failure to successfully restart the process, leading to alarm triggering.

page

Return to top