Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 223 since they could introduce variations in program behavior and output that would at the least complicate the validation process and at worst destroy confidence in the correctness of the ported system. Translating TRIM2 modules from FORTRAN to C introduces another potential source of variability. If such a translation were attempted, a large majority of the actual code translation could be done with computer programs, with some manual translation and resolution of specific problems. Such translation would add yet another source of variability to the results of the conversion and could complicate the validation of the port considerably. The advantage of translating the model into C is that C is a far more flexible language. It permits a programmer to define different types of data pointers and to use them to define variables that point to different types of objects in memory. Within a defined set of rules, a programmer can then recast a memory location from one object type to another. This type of language construct can be used to support the variable type of data structures often found in modeling systems. And, while the first version of the translated C code might not take advantage of any of these features, future changes could do so once the basic modules had been translated into their C equivalents. Benefits of Porting TRIM2 Some benefits would accrue to users by porting TRIM2 to a microcomputer environment. Depending on the degree to which the control procedures could be made easy to use, the system might be deliverable to additional users and could be run in a decentralized fashion. Integration of TRIM2 outputs with other microcomputer or UNIX-based tools would allow better use to be made of the outputs. Incremental additions to TRIM2 could be structured to take advantage of the substantial interactive possibilities of the new environment. Finally, some benefit would be obtained by showing that such a port could be accomplished. We believe, however, that an MS-DOS- or UNIX-workstation-based operating environment would not be more attractive for TRIM2 than the current IBM MVS environment for the following reasons, among others: â¢ All TRIM2 procedures and operations are built around the simultaneous processing of large input and output files and have historically relied on a mainframe service bureau, including an off-line tape library, at which to execute jobs. The procedures therefore have made substantial use of off-site operations and were not written to minimize their extent. Unless the port included a substantial revision of those procedures, users of the desktop version of TRIM2 could find themselves saddled with an onerous set of operational duties associated with its use. â¢ TRIM2 relies on a central directory for storage of many entities associated with itâvariable definitions, parameters, and runs. There is no notion of
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 224 public and private parts of the directory; it was originally designed to be used as a central repository for all TRIM2 activity. If multiple copies of TRIM2 were distributed among multiple desktop computer systems, copies of the central directory would also have to be distributed to those systems. Over time the directories could diverge because of different types of activity on each system. It would not matter if the activities of the users were independent. However, if the various users were to cooperate with each other on joint projects, the likely result of attempting to join entities referenced in independent inconsistent directories would be chaos. Since the current model of TRIM2 use includes a number of users in different physical locations using a single CTD, once the divergence in directories began, there would be uncertain ability to combine results of runs and therefore little benefit in decentralizing the operation. â¢ The IBM mainframe version of TRIM2 still contains input/output routines written in assembly language. While this implementation decision reflects relatively inefficient FORTRAN input/output code in the late 1970s, FORTRAN input and output operations are still relatively inefficient. Given the dependence of TRIM2's efficiency on fast sequential input and output, an additional cost of conversion to any other platform (as was the case with the VAX implementation) may be either significantly slower input and output or a laborious assembly-language-to-assembly-language coding task. The basic difficulty in extracting benefits from a desktop version of TRIM2 goes back to the notion of TRIM2 as a piece of capital embodying the technology of the late 1970s as well as the batch technology of the late 1960s. The software architectures of RIM, TRIM, TRIM2, and most if not all of the variants of these systems have all been optimized to run on a central mainframe computing system that relies primarily on batch processing. Moving these systems into a very different environment minimizes their operational strengths and exposes their lack of ability to exploit the new environment. The benefits of porting TRIM2 in its present form as suggested above are moderate at best and justify neither the real costs involved nor the opportunity costs of preempting investment resources that could better be used elsewhere. To the extent that there are benefits in using desktop systems for extensions of TRIM2, they are more oriented toward increasing programmer productivity than assisting user effectiveness. A case can be made for investing in some front-end tools that would help programmers modify and manage the existing TRIM2 system better. Such tools can and should probably be desktop based and linked by network connection to the TRIM2 mainframe host as appropriate. Even though such investments are likely to be short term, they can assist productivity in the short run, which should not be ignored. The underlying model of operation being suggested is one of specialization of function, with the front and back ends of the operation split, specialized, and relinked for the purpose of increasing programming and system management productivity.