Perhaps the easiest way to describe MOSES is that it is not very smart, but it has a good memory. In other words, MOSES must be told to do everything, but remembers almost everything that it has been told. As definition, the things MOSES is told to do are called commands, while the place the results are stored is called the job database.

While all instructions to MOSES are called commands, it helps to separate instructions into the categories: commands, descriptions, and questions. One issues commands to MOSES to accomplish tasks, issues descriptions to define a system for analysis, and asks questions to find out the results of the commands. The database consists of the union of all descriptions issued and the results of all commands. When one asks a question, the answers are obtained by querying the database. While MOSES can be utilized in both "batch" and "interactive" environments, it is perhaps best to view all commands as being issued from a terminal. Since the results of all previous commands are available in the database, it is no more difficult to produce a set of results by making several small runs as it is to make one big one.

The majority of the system which will be analyzed is defined to MOSES by a set of descriptions contained in the "INPUT" file. These descriptions are commands in what is called MOSES Modeling Language, and are processed by the program whenever instructed by the user. When the Modeling Language is processed, the description is converted into an internal model within the job database so that the model has to be processed only when it has been altered.

After a model database has been generated, the user is free to perform simulations. Before proceeding, however, one may wish to alter the definition of the system from that defined by the modeling language. The type of things which can be altered are: the weight of the bodies, the connections among the bodies, or the environment. When the system is altered, the changes are again remembered until the system is altered again. Thus, one can perform numerous simulations on the same basic system without rereading the model. When one issues a simulation command, the simulation is performed, the results stored in the database, and control is returned to the user. No reports are automatically produced, and no questions are asked, so that simulations can easily be performed in the background. To obtain reports of the results one must enter one of the sections of commands which were designed to answer questions about the results of simulations. These sections of commands are called Post-Processing Menus or Disposition Menus. In these sections of the program, one may be asked questions himself, so it is best if these tasks are performed interactively.

The database structure of MOSES allows for "seamless" restartability. One can terminate the program at almost any point and resume execution later with no loss of information. This structure and the root file concept discussed later free the user from having to worry about naming, reconnecting, and remembering the names of "restart files", and provide superior performance to previous systems. Since nothing is necessary to restart the program, nothing further will be said about it, but the capability is one of the primary features of MOSES.

While MOSES is initially not very smart, it can learn. In other words, the user can teach the program how to perform many commands when a single one is issued. This capability is implemented by allowing users to define "macros". These are really sets of commands which the program associates with a single name, and any time the name is issued as a command, the entire set will be executed, thus freeing the user from the tedious task of issuing many commands.

The flexibility of MOSES may, at first, overwhelm a new user, but with a little experience one quickly learns to enjoy the power of the system. In the sections which follow, all of the features of MOSES will be discussed. In many cases, the utility of a feature may not be apparent when it is discussed. The primary reason is that there are many facets of the MOSES language which are not really necessary, but are quite useful once one has mastered the basics. Thus, instead of worrying about how each feature is to be used, one should proceed throughout the manual briefly to get a "general feel" of what one can accomplish and how to do it. The next step is to carefully look over the samples supplied with this installation to see how typical problems may be attacked. The next step in solving a problem is to create a simple problem which has all of the attributes of the real, complex one to be solved and to use it as a prototype in understanding. It is always easier to use small problems to complete ones understanding than it is to cope with both understanding the program and with the details of a large problem.