SSDT SOAP Services interference with back-end processing.

A frequently reported problem with the USAS/USPS SOAP services, is the problems they can cause for processing on the OpenVMS system due to file locking.  For example, a USPS user can not run "SAVEPAY" or CHKUPD because a Kiosk SOAP session has a file locked.  Or, a USAS user can not run ADJUST because a USAS Web user has the ACCT file locked.

In this blog post I'll try to explain the conflict between the technologies being used and things you might do to mitigate them.  The SSDT has provided a tool in the RPC layer that you can use to help manage the SOAP users' access to the system, but you may not be aware of it or how to use it effectively.

First, there's a fundamental conflict between what the SOAP service (e.g. the Kiosk) wants and what the COBOL based backend can provide.  The SOAP service wants high availablity, concurrency and up-to-date information.  The COBOL based system (e.g. USPS) is partially batch oriented and wants to protect itself from concurrent updates for critical transactions.  Because the COBOL systems are based in ISAM instead of a DBMS (SQL), there is no way to allow concurrent transactions that are atomic.

For example, if USPS's CHKUPD is posting a check, there are many records that must be updated to complete the transaction (check history, account history, deductions, jobs, etc).  If USPS encounters an error (like a locked record) it does not have a DBMS to "rollback" the transaction so it can start again or abort cleanly  In ISAM, this would lead to a partially posted check (which amost always requires a restore from backup).

For another example, a DBMS system can take a backup from a running production database.  It can take a snap shot of a database while other transactions are being processed.  The backup is taken as a "point in time" as if no partially completed transactions are in process. Applications connected to the database as if nothing has happened. With ISAM, no such facility exists.  If you backup with "/IGNORE=INTERLOCK" you can not be certain that a one file doesn't contain a portion of a transaction not reflected in an other file.

So USPS and USAS are exceptionally paranoid about allowing concurrent access during critical transactions, if we relax these contraints much futher, we risk damage to the systems.  The SSDT has (and is) making changes to the systems where possible to reduce impact on this conflict. For example, the USPS SOAP service hold files open for read/write when not strictly necessary.   We will continue to improve this when possible.

However, there are limits to what we can do and there will always be situations where USPS/USAS can not tolerate concurrent access.  (That is, until the migration to a proper DBMS an be completed.) In these cases, the only choice is to prevent the RPC (web users) from accessing the data files so that back-end processing can occur.

To help with this, the SSDT created the ability for ITC's and districts to define flexible "Disable Periods" for the RPC services.  By placing a file called RPC-SERVICE-CONFIG.XML in OECN$DTA (per district) or OECN$CUSTOM (system-wide), access to the RPC services can be disabled on a schedule.

However, we haven't yet built a user interface for this file, so there's no easy way to create the file other than a text editor.  But such things are easy to do with DCL.  As an exmple, I've attached a DCL script called RPC_UTILS.COM.  This is a relatively simple script that a user could run to disable or enable the RPC services. 

For example, you could add two a USPS Local menu items that did:


A user could select the first one to disable the service and later re-enable it.

Or perhaps you could add the DISABLE to the beginning of SAVEPAY. The procedure is not very clever and you're welcome to tweak it out anyway you want.

Note that this is not a complete solution since it doesn't actually disconnect active users.  But it does prevent new sessions from starting and notifies the user why the can't login.  For example, here's what a Kiosk user would see when it's disabled:

Disconnecting currently active users is another problem without a satisfying answer, but I'll save that for another day.