Back to résumé.    Résumé



          NYSE / NMS Operations Requirements and Standards: System Design    
For the document SIAC/NYSE Operations Requirements and Standards for software, Jerry Hait and I wrote a rough draft based on our own experience and suggestions from an Operations vice president. After the paragraphs were drafted, we met with the Operations managers responsible for running the systems. Sometimes we held meetings to get the comments from a group; sometimes we met with them in indivdual interviews. Their comments were recorded using Word's tracking function, so that senior management could see where requirements came from. This page is the marked-up draft; scroll down or click here for the published version.
 
 
 
 

20





          NYSE / NMS Operations Requirements and Standards: System Design    

NO SOD DEPENDENCIES ON OTHER SYSTEMSIt must be possible to initialize any system at Start of Day (SOD) without waiting for any other system to be initialized. An application might need to wait for configuration or initialization data from another application; for example, Display Book (DBK) requires configuration from Post Support Systems (PSS) and initial data from Super Designated Order Turnaround (SDOT), but DBK can be brought up independently and be ready for that data when it is sent.
 
DISCRETE AND REVERSIBLE SOD, EOD AND IMPLEMENTATION PROCEDURESMost applications have SOD, End of Day (EOD) and implementation procedures. Applications must be designed so that when any of these procedures are run, Operations has the ability to go back to the previous step and repeat the failed step, and not have to rerun the entire procedure from the beginning. For example, if it is necessary to reverse and repeat a late step in a system's SOD procedure, it should not have to be necessary to re-initialize that system. The intent is that Operations must be able to run these procedures as quickly as safety will permit.

In some cases scripted procedures cannot be broken up into steps, and must be run from the beginning. In that case Development must design applications keeping in mind the constraints of time and the imperative that if a procedure is run twice, it must not have a bad effect (such as destroying production data). See Repeating a Procedure Must Not Be Harmful, page 13.
 
SOD DIFFERS FROM WARM STARTApplications must be designed so that if the Operator runs a full Start of Day (SOD), the application will run a true SOD, not merely a warm start, even if the application is already partly or fully initialized. If it is necessary to run a SOD intraday, data in volatile application memory may be lost to the application, but can be recovered and processed by gap filling and the use of checkpoints or pointers, which tell an application at what point to resume processing a queue or safe-store file. See warm start, page 77.
 
  Back to résumé.

20