Server Side Changes in version 1.7

This document describes the server side changes made to the Scheduling GUI to remove mumps transactions. The Scheduling GUI code was changed too in v1.7, mostly to support BMX v4. There is a single bug fix on the GUI side where support for unlinked clinics was broken inadvertently in v1.6.

Introduction and Statement of Problem

There are three issues:

1. The interaction between transactions and locking causes a freeze in GT.M that looks like this:

   GTM[******]: %%GTM-W-MUTEXLCKALERT, Mutual Exclusion subsystem ALERT - 
   lock attempt threshold crossed for region /var/worldvista/globals/mumps.dat.  
   Process 17141 is in crit. -- generated from 0x00002B158FF975CD.
   

The Scheduling GUI did a lock itself outside of the transaction in BSDX07, and Fileman did a bunch of locks internally inside the transaction.

2. Cache users will fail with an UNIMPLEMENTED error if we use the full transaction syntax which is required on GT.M.

3. Long running transactions present a problem to VISTA because unfiled transaction data can overwrite data not done via a transaction which is filed immediately. For example, in a transaction, Fileman creates records using the next available record number and files the data there. If two transactions do that at the same time that are not synchronized, we can overwrite the record; also, code outside of transactions will write the record first.

Due to all of these reasons, I decided to completely remove Mumps Transactions from the Scheduling GUI code.

Summary of Work

6 routines had to be changed: BSDX07, BSDX08, BSDX25, BSDX26, BSDX29, BSDX31. The general approach is as follows: First, we check against PIMS if applicable if we can store the data in PIMS. If we can, we go ahead and

1. File the data in BSDX APPOINTMENT, and then
2. in PIMS, and then
3. run the Appointment Event driver (SDAM APPOINTMENT EVENTS in the Protocol File). This last step is the point of no return.

If we fail in 1, we don't need to roll back anything. If we fail in 2, we need to rollback #1. If we fail in 3, we really don't have any recourse. For practical reasons, I decided that I will handle errors that can be reported to me (e.g. Fileman failing to store data). Mumps level errors I cannot handle gracefully; however, I put code to try to recover in certain places where I thought it would be practical to do so.