Debugging PicLan SERVER-PROCESS Hangs

April 24, 1998

This paper discusses the proceedures to follow to determine why the PicLan SERVER-PROCESS phantom job has stopped operating.

How the SERVER-PROCESS Runs

The PicLan SERVER-PROCESS is a Pick/BASIC program that calls a large number of Pick/BASIC subroutines. It also uses a bit of PicLan assembler code and driver code for it's operation as well. This program runs on the following types of ports:

AP/Pro AP/native Pick/64+ Sequoia PRO: The PicLan SERVER-PROCESS is run on an AP/OA phantom process that is started with the system Z command. If the SERVER-PROCESS fails with a BASIC run-time error or system abort, the system will log the process off automatically.
R83 Upboard: The PicLan SERVER-PROCESS is run on a standard system port that does not have a physical terminal attached to it. It is started with the system LOGON command. If the SERVER-PROCESS fails with a BASIC run-time error or system abort, it will just sit there in the debugger.
Mentor PRO
PC/OS: The PicLan SERVER-PRCOESS is run on a system background port. It is started with the system LOGON command. If the SERVER-PROCESS fails with a BASIC run-time error or system abort, it will just sit there in the debugger.
R91: The PicLan SERVER-PROCESS is run on a standard system dynamic port that does not have any terminal devices assigned to it. It is started with the system LOGON command. If the SERVER-PROCESS fails with a BASIC run-time error or system abort, it will just sit there in the debugger.

What Happens When the SERVER-PROCESS Fails

If the PicLan SERVER-PROCESS fails, PicLan does not stop working entirely. Some PicLan functions do not require the server-processes presence, and some do. The following elements will continue to operate without an active SERVER-PROCESS:

Inbound terminal sessions.
PicLan TCL commands and remote access subroutines:

PL-COPY
PLDOS-IMPORT
PLDOS-EXPORT
PLSUB.PICK(...)
PLSUB.DSG(...)

Other functions do require the SERVER-PROCESS:

Terminal session auto-logon and auto-logoff functions
PL-COPY commands originated from other systems
All network printing functions
VB API functions
Other functions that start on other system and ask for resources from the Pick host

How Do You Know the SERVER-PROCESS has Failed

The most obvious symptom is that something that you need to work is not working. This is most commonly network printing. You can also execute PL-STAT and it will display a warning message if the SERVER-PROCESS is not active and alive.

Why Does the SERVER-PROCESS Fail

This is the most difficult question to answer. The SERVER-PROCESS can fail for all of the reasons that any Pick application program can fail:

A bug in the SERVER-PROCESS code was encountered.
A bug in the data records that the SERVER-PROCESS uses.
The system aborted because of:

A system ABS corruption
GFE
Out of disk space
Out of workspace

In most cases, the SERVER-PROCESS does not fail because of a SERVER-PROCESS internal bug (we try to fix these and most seem to be gone at this point), but instead because of some more general system problem like an abort.

How Do You Diagnose SERVER-PROCESS Failures

The first step in diagnosing a SERVER-PROCESS problem is to run the SERVER-PROCESS where you can see it's output. This means that you need to run the SERVER-PROCESS on a normal, terminal connected, port instead of on a system phantom processes. Doing this takes a couple of steps:

Stop the current SERVER-PROCESS

This may require you to run PL-STOP-SERVER is the SERVER-PROCESS is still working or use the system LOGOFF command if the SERVER-PROCESS is currently sitting in the debugger. You should use the WHERE display to make sure the SERVER-PROCESS is gone. If you cannot kill off the current server-process, you can de-configure the SERVER-PROCESS in PL-CONFIGURE and reboot the host.

Manually run the SERVER-PROCESS in the forground on a standard terminal or network connection that you can watch.

This allows you to run the SERVER-PROCESS in a location where you will see any errors and messages that would be lost if the SERVER-PROCESS were running on a phantom port.

What Port Should I Run the SERVER-PROCESS on During Debugging

While you are trying to figure out why the SERVER-PROCESS is failing, you will need to give it a standard, terminal connected (either serial, console, or network), port to run on. This proceedure will use a Pick login license and will tie up a terminal port for the duration of the debugging operations. The best port to use is probably the system console (port 0), but you can freely use serial connected terminals as well as PicLan workstation connections.

How Do I Start the SERVER-PROCESS Manually Once the Phantom SERVER-PROCESS is Killed

The steps to start the SERVER-PROCESS manually are very simple:

Log to the PIC-LAN account and access TCL
At TCL type:

RUN PL.BP SERVER-PROCESS (E)

The SERVER-PROCESS will run in the forground until you either

Execute a PL-STOP-SERVER on another port
Press the letter X

Now That I See Why the SERVER-PROCESS Fails, What Next

Once you see the SERVER-PROCESS fail, you can use the information that you see to take further action. If you see a GFE or system abort relating to file space, you may need to consider reloading ABS, the PIC-LAN account, or the entire system. If you get a system abort that you do not understand, you should contact your Pick technical support people.

Modular Software does not provide general Pick technical support. On AP/Pro and Mentor PRO platforms, Modular Software only provides technical support as backup to Pick Systems and General Automation PicLan technical support. Users of other platforms can contact Modular Software directly.