Before you begin coding your Smalltalk programs with the intent of running them on a server, it is important to recognize the differences between workstation and server, especially mainframe, processing. Server platforms provide a much more powerful, robust operating environment than the workstation. With multiple users running jobs on a server frequently and simultaneously, time, namely CPU time, becomes an important factor. For software developers intending to write Smalltalk programs that will run on a server, performance is a major issue.

There are some coding hints that will speed up your program's processing. The most important of these is maintaining a steady state program. Much of the CPU time that is spent on a server comes during image initialization. Each time a Smalltalk program is run, the image must be initialized, which requires system resources. In transaction environments such as CICS, to circumvent the Smalltalk cost of image initialization, creating a program that will serve as the workhorse for your system is an important consideration. Such a program would remain resident in memory; thus each time the transaction is entered--after the first image initialization--it will not suffer the image initialization cost.

For example, let us consider a banking system running on AIX under CICS Transaction Server that will allow customers to deposit, withdraw, or transfer money into or out of their accounts. This can be done in many different ways. Each time a transaction is invoked, it receives new working storage, which is Smalltalk-initialized storage. Therefore, by invoking a transaction many times, CICS will initialize working storage for every transaction, even though the transactions perform similar processing.

Instead, build a server transaction that understands all the transaction types. Let's say this server transaction will access data on DB2. The server transaction will be written to stay resident in CICS memory; that is, it is initialized once and, when it completes, it does not terminate. To do this, we'll use the CICS DELAY command. The purpose of this server transaction is to process subsequent requests from ad hoc Smalltalk client transactions.

When a customer keys a client transaction into their interface, two things will happen: one, customer information, transaction type, and amount will be placed into a temporary storage queue, and two, the delay on the resident server transaction will be cancelled. The server transaction, having been initialized only once, the first time it was called, receives the CICS CANCEL command, wakes up from its delay, and reads the information from the temporary storage queue. It sets about its task, verifying that the customer is permitted to access the specified accounts, then performs the transaction type for the amount indicated. When processing completes, the server transaction performs another CICS DELAY command. In this way, it remains resident and you minimize CPU time by avoiding repetitive image initializations.

A program similar to the one mentioned above is available as a sample. See Loading sample Applications for more information.