Portation Notes

This section describes some of the more important points which should be considered when porting ESROP to a target environment.

Unresolved Symbols

If all ESROP layer modules are linked together, the symbols listed in Table 2.5 are unresolved for the ESROP module.

The remaining symbols are associated with the Open C Platform[1] which contains detailed information about each of these facilities.

Table 2.5: Unresolved Symbols of ESROP

Symbol	Module
DU_alloc	Data Unit Module
DU_free	Data Unit Module
DU_link	Data Unit Module
G_duMainPool	Global Module (integration of all modules)
INET_in_addrToNsapAddr	Internet Module
INET_nsapAddrToin_addr	Internet Module
INET_portNuToTsapSel	Internet Module
INET_tsapSelToPortNu	Internet Module
NM_incCounter	Network Management Module
N_sapAddrCmp	Network Service Access Point Module
PF_crc16	Public Facilities Module
QU_init	Queue Management Module
QU_insert	Queue Management Module
QU_move	Queue Management Module
QU_remove	Queue Management Module
SAP_selCmp	Service Access Point Module
SEQ_elemObtain	Sequence Module (mem allocation for lists)
SEQ_elemRelease	Sequence Module
SEQ_poolCreate	Sequence Module
TMR_cancel	Timer Management Module
TMR_create	Timer Management Module
TMR_getData	Timer Management Module
TMR_getDesc	Timer Management Module
TM_hexDump	Trace Module
TM_open	Trace Module
TM_prAddr	Trace Module
tm_loc (TM_loc)	Trace Module
tm_here (TM_here)	Trace Module
tm_trace (TM_trace)	Trace Module

Configuration

Several compile time constants must be configured before the ESROP module can be used. These constants are either defined by ESROP or ESROP User. Some of these configuration parameters can be statically changed at run time by changing the ESROP configuration file. The following table is the list of these configuration parameters.

Table 2.6: ESROP Configuration Parameters

Symbol	Definition
ESROP_K_UdpSapSel	UDP SAP selector (currently 2002)
ESROP_SAPS	Total number of SAP entries.
ESROP_INVOEKS	Total number of concurrent invocations
INVOKE_PDU_SIZE	Invoke PDU size
NUMBER_OF_TIMERS	Maximum number of timers
MAX_SAPS	Maximum number of active SAPs
MAXBFSZ	Buffer size of Data Unit module
BUFFERS	Total number of DU buffers
VIEWS	Total number of DU views

Tracing

To facilitate the portation process of ESROP, some tracing capabilities have been built into this product.

To enable the tracing feature, the compile time constant TM_ENABLED must be defined.

Tracing level can be controlled through definition of trace masks in the ESROP configuration file.

Differences Between Unix and MS-DOS/Windows Portations

The major differences between the Unix and MS-DOS/Windows portations are isolated to several discrete locations in the code. These differences are discussed in the following sections.

Multiple Processes vs. Single Process

The most significant difference between the two portations lies in the manner in which an ESROS user communicates with ESROS itself. Under Unix, ESROS runs as a separate task. There may thus be one or more ESROS users that invoke ESROS primitives via an interprocess communication mechanism provided by the UPQ_BSD_ module.

MS-DOS, of course, does not support such a mechanism. Therefor, ESROS and ESROS users are linked together as single executable. This is the same for Windows. As explained in the previous sections, ESROP has a call-back interface to the upper layer. However, there are two different API's available to the ESROS user (see Section , ESROS API). In the case of applications that use the Call-back API, the inter-process communication module is eliminated for one-process model. In the case of Function Call API, in place of the interprocess communication mechanism, there is a a module that emulates the UPQ_BSD_ facilities. This module, named UPQ_SIMU_, uses disk files to simulate the interprocess communication mechanism.

The developer of an ESROS application who has to port between these two environments will be chiefly concerned with the ESROS user's make file. Under Unix and for two process model, the ESROS user application is linked to the UPQ_BSD_ library. Under MS-DOS it is linked to the UPQ_SIMU_ library. In addition, the MS-DOS user must link to the libraries containing the ESROS code. The following excerpts illustrate this principle.

Libraries used building Unix ESROS user application as a separate process

USER_SH = $(LIBS_PATH)/esro_ushcb.a 
UPQ = $(LIBS_PATH)/upq_bsd.a
GF = $(LIBS_PATH)/gf.a

Libraries used building MS-DOS ESROS user application in one process with Function Call API

USER_SH = $(LIBS_PATH)\esro_ush.lib
PRVDR_SH = $(LIBS_PATH)\sp_shell.lib
UPQ_SIMU = $(LIBS_PATH)\upq_simu.lib
UDP_IF = $(LIBS_PATH)\udp_pco.lib
ESROP_SH = $(LIBS_PATH)\esrop_sh.lib
PROT_ENG = $(LIBS_PATH)\esroprot.lib
GF = $(LIBS_PATH)\gf.lib

Libraries used building MS-DOS ESROS user application in one process with Call-back API

UDP_IF = $(LIBS_PATH)\udp_pco.lib
ESROP_SH = $(LIBS_PATH)\esrop_sh.lib
PROT_ENG = $(LIBS_PATH)\esroprot.lib
GF = $(LIBS_PATH)\gf.lib
SF = $(LIBS_PATH)\sf.lib
FSM = $(LIBS_PATH)\fsm.lib

Scheduler Module (SCH_)

SCH_ module can be used for scheduling the program's modules.

One of the common usages of SCH_ module is scheduling of further processing within the same module. This happens most often to prevent re-entry to non-re-entrant code. For more information about the Scheduler module refer to OPEN C Platform document.

Timer Module (TMR_)

The TMR_ module defines a model and an interface for providing timer facilities to Open C Layers, regardless of the environment, provided that all implementations of the TMR_ module conform to the interface defined here. For more information about the Timer module refer to OPEN C Platform document.

FLEX & BISON

FLEX is a DOS portation of the lex utility commonly found on Unix systems. BISON is a DOS portation of the yacc utility. These utilities are used in the compilation of the ESROS Scenario interpreter, ESROSSI.