After a service is started on a computer, the service must:

• Verify any command-line parameters passed to the service by the calling process.

• Register a signal handler to interpret opcodes passed by requesting applications. For more information, see Differences in 16-Bit and 32-bit Services.

• Set its state to SERVICE_INSTALL_PENDING, by calling the NetServiceStatus API, to notify any requesting applications that it is not ready for use.

• Complete any other initialization procedures previously defined by the service.

• Notify the LAN Server software that installation is complete by calling the NetServiceStatus API and setting its state to INSTALLED.

The NetServiceInstall API processes the executable file specified in the IBMLAN.INI component of the service by calling the OS/2 DosExecPgm API and passing the string of parameters made up of IBMLAN.INI parameters and information passed to the cmdargs parameter of the NetServiceInstall API.

The DosExecPgm API runs the service in detached mode, preventing handles from being passed to child processes and preventing screen- and keyboard-oriented calls except through pop-up functions. A service inherits the environment of the parent process, the NetServiceInstall API.

If a service includes more than one process, the process that the DosExecPgm API initially runs (referred to as the main service process) is the only process that receives standard signals from the NetServiceControl API. The main service process is the only one that can issue calls to the NetServiceStatus API. A service can transfer the responsibilities of the main service process to another process by setting the PID component of the service_status data structure (passed to the NetServiceStatus API) to the process identification number (PID) of the main service process candidate.

After receiving control from the DosExecPgm API, a service validates the parameters passed from the IBMLAN.INI file. If the parameters are not valid, a service notifies the LAN Server software by calling the NetServiceStatus API and ending execution. Otherwise, the service installation continues.

After verifying parameters, a service must start a signal handler that communicates with the NetServiceControl API. Using the signal handler, a service specifies its current state (such as INSTALL_PENDING or INSTALLED) so that the LAN Server software can enable other applications to use the service properly. The signal handler must register a function for the FlagA signal, the SERVICE_REC_SIG_FLAG opcode, by calling the DosSetSigHandler API.

After a service specifies its current state as INSTALLED, another application can change or query the state of the service by calling the NetServiceControl API. With this function, an application can pass an opcode specifying one of four actions to take. The actions are defined in the SERVICE.H header file, as follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³SYMBOLICCONSTANT ³VALUE³MEANING ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ SERVICE_CTRL_INTERROGATE ³ 0 ³ Request for general information. ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ SERVICE_CTRL_PAUSE ³ 1 ³ Pause the service. ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ SERVICE_CTRL_CONTINUE ³ 2 ³ Continue a paused service. ³
ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
³ SERVICE_CTRL_UNINSTALL ³ 3 ³ Shut down a service. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

A service can define its own set of valid opcodes. Opcodes that are not valid should default to another opcode such as SERVICE_CTRL_INTERROGATE. The LAN Server software defines the following limits:

• A service that does not accept the SERVICE_UNINSTALL opcode cannot be removed at any time.

• While in the SERVICE_INSTALL_PENDING state, a service can receive only the SERVICE_UNINSTALL opcode.

In the following pseudocode, an application and a service communicate by means of a signal handler and the LAN Server software: Application LANServer Service
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Application calls ³
³ NetServiceControl,³
³ specifying an ³
³ opcode to perform ³
³ a particular task.³
ÀÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÙ
³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ ³ Opcode is sent ³
ÀÄÄÄÄÄÄÄÄij to the specified ³
³ service. ³
ÀÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÙ
³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
ÀÄÄÄÄÄÄÄij Signal handler ³
³ interprets opcode. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÙ

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³Performs the task ³
³defined by the opcode.³
ÀÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÙ

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³Calls NetServiceStatus ³
³to clear the control ³
³semaphore and, if ³
³required, change the ³
³state of the service. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÙ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³
³Updates service ³ ³
³information table ³ÄÄÄÄÄÄÄÄÄÙ
³according to current ³
³state of the service.³
ÀÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÙ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³
³NetServiceControl ³ ³
³returns with the ³ ³
³appropriate information³ÄÄÄÄÙ
³about the service's ³
³current state. ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

If performing the task takes a long time (more than a few seconds), the service should make intermediate calls to the NetServiceStatus API.