A number of users have made various inquiries about availability of extensions to the PicLan SERVER-PROCESS. Some users have also requested access to the source code of the SERVER-PROCESS so that they can implement extensions themselves. The purpose of this paper is to discuss the run-time environment that the PicLan SERVER-PROCESS operates in and the design constraints placed upon it.
The PicLan SERVER-PROCESS is a single Pick program (mostly written in Pick BASIC) that is responsible for servicing multiple, possibly simultaneous, requests. The reason that the PicLan SERVER-PROCESS is implemented as a single process is simple. The first PicLan implementation, Pick PC R83, had a very limited pool of PIBS and did not support phantom or background processes. The design of the PicLan SERVER-PROCESS is an implementation of a classic queue-driven "state machine" implemented in Pick BASIC. The term state machine refers to a programming style where lengthy programming processes are broken up into a number of smaller steps between which the "state" of the operation can be saved and later restarted. This state machine approach allows the PicLan SERVER-PROCESS to internally multi-task, giving processor time to multiple operations, all while in the confines of a single Pick process.
The PicLan SERVER-PROCESS operates on a number of different "commands". Some commands are simple, are executed to completion, and then are forgotten. Other commands are more complex and may be broken up into many steps. While a command is waiting to be executed, it is placed on a run-queue. Other commands that wait for external events like network traffic may be placed on a sleep-queue. Each command type is designed to execute independently and with the possibility that other, possibly identical, commands may be requested concurrently.
The PicLan SERVER-PROCESS is implemented in Pick BASIC with the assistance of programming tools and extensions that are unique to Modular Software and PicLan. The principle programming tool in use is Modular Software "pre-compiler" (the PC verb from our Full-View product). This is a BASIC compiler front-end that allows the definition of new BASIC syntax statements that make managing a program like the PicLan SERVER-PROCESS much easier.
To illustrate the use of the pre-compiler, PicLan functions tend to make extensive use of Pick assembler user exits that subsequently call PicLan driver code which executes at the level of Pick monitor code. The syntax of user-exits within Pick BASIC can be quite cumbersome, so the pre-compiler is used to remove this apparent complexity of user-exit coding. This is the user-exit coding on R83 to allocate a PicLan network connection (the equivalent of plan_alloc_plcb(...) ).
S$ = OCONV( CALL.DRIVER.EP:FN.ALLOC.PLCB:'0000':OCONV(PORT.TP),'MCDX')'R%2':'00':OCONV(PORT.NO,'MCDX')'R%4',CALL.DRIVER.MD)
IF S$[1,4] = IPX.SOCKET.NO THEN
ERR = 0
RES = OCONV(S$[5,4],'MCXD')
IF RES > 32768 THEN
RES = RES - 65536
END ELSE
LOCATE(RES,RESOURCE.LIST,1;T$$$) ELSE
RESOURCE.LIST<1,-1> = RES
END
END
END ELSE
ERR = 1
RES = 0
END
IF NOT(ERR) AND RES >= 0 THEN
This is obviously a bit hard to type every time. With the pre compiler, this same code is entered as:
PL_ALLOC.PLCB PORT.TP,PORT.NO THEN
The pre-compiler is only a part of the programming environment implemented for the PicLan SERVER-PROCESS. A number of helper support routines are implemented both in Pick BASIC and assembler to facilitate network communications buffering, management of run and sleep queues, and management of system resources like buffer space and network communications handles.
The PicLan SERVER-PROCESS is not implemented as a single Pick BASIC program. To do so would be cumbersome at best, and in all likelihood impossible because of run-time size limitations within Pick BASIC itself. The current PicLan SERVER-PROCESS comprises 30 separate BASIC source-code files totaling about 80K. Each module tends to deal with a specific type of SERVER-PROCESS command. For example, PLSP.EVENT.OUTBOUND.PRINT.JOB deals with sending Pick print jobs over the network to other systems. All of the SERVER-PROCESS components share an included BASIC COMMON area for the sake of programming efficiency.
PicLan SERVER-PROCESS commands that are broken up into multiple parts are managed as "states". A state is a set of data elements that completely defines the status of a command as it is being processed. PicLan SERVER-PROCESS states are designed so that they can be stored within a single multi-attribute dynamic array and possibly written to a temporary file if necessary. When a command is running, if there are no other commands waiting, a single state is held (or cached) within the PicLan SERVER-PROCESS program. If other commands are waiting, the running state is swapped with the new state. For an operating system, this would be called a "context swap", and the same terminology applies to the PicLan SERVER-PROCESS. One command's state is written to a temporary disk file and then replaced with another command's state at which point execution is resumed. Due to the nature of Pick BASIC, this form of multi-tasking is strictly non-preemptive and is quite granular in nature, but it does accomplish the required goal of multiple concurrent processing with reasonable response time.
The inherent nature of the SERVER-PROCESS and the requirement that it's operation be reliable and uninterrupted make it difficult for user-development of SERVER-PROCESS functions. Users frequently ask for extension to SERVER-PROCESS functions and over time, some of these have been implemented. Slave and routed printing are examples of user-driven SERVER-PROCESS functionality. The important factors in determining what types of functions are to be added to the PicLan SERVER-PROCESS is whether such functions make sense within PicLan as a product. Does the new functionality make sense for most or only a small sub-set of the installed user base. Can new functionality be documented and understood in a reasonable fashion. Can the new functionality be implemented within the single-process constraint that the SERVER-PROCESS executes. Some of these issues are not minor.