Table of Contents
Previous Go to Robert Ramey Software Development Home Page next

4. Calling PSORT from Another Program

Postman's Sort can be called from most programming languages using standard DOS system calls. This permits the postman's sort to be called as if it were subroutine or overlay. Included on the distribution disk are programs which demonstrate how this is done using Microsoft C/C++. Building A Custom Sorting Utility

4.1. Building A Custom Sorting Utility

Included on the Postman's sort distribution disk is a file DBSORT.C. This program illustrates how a new sorting utility can be created using Microsoft C to call the Postman's Sort as subprogram. This program uses the PSORT to make a general purpose sorting utility for dBase III/IV files. dBase III/IV files have there own unique structure which can be summarized as follows:

file header record 32 bytes one record for each field 32 bytes fixed size data records ... fixed size data records control-Z dbsort implements the following command line syntax: dbsort <input >output <field name> ... Nothing else is required because dbsort extracts the rest of the information that PSORT uses from the dBase header records.

dbsort works in the following manner:

a) Reads the file header from the standard input and writes them to standard output. Data record size and other information is saved from the file header.

b) Reads the field descriptor records and writes them to standard output. Field names, positions and types are recorded in a table.

c) Processes the command line looking for field names.

d) Prepares a command line for PSORT. This command line has appropriate parameters for field location, key collating sequences etc.

e) Executes PSORT using a standard DOS system call and waits for it to terminate. Standard input/output files are passed to PSORT in their current state.

f) The standard output now contains the sorted file. dbsort adds a control-Z on the end to be compatible with dBase.

Since dbsort builds a table containing all the information from the dBase field descriptors, the only information that dbsort requires in its command line is the field name. Thus a dBase version of the Postman's sort has been generated which doesn't require any information from the operator other than the field name. Larger Programs

4.2. Larger Programs

The previous case was a small program compiled with the small memory model. It allocates no extra memory from DOS leaving plenty of memory available on most machines to load the PSORT.EXE and use for sorting.

When applications become larger, less memory is available for called programs such as PSORT. When a PSORT is executed, memory is required to load the executable as well as perform the sorting. Lack of memory will seriously degrade the performance with PSORT. ctest.c is a program designed to simulate the situation where an application requires a large amount of memory so that amount available to a executed program such as PSORT is limited. The command line syntax for ctest is:

ctest [<reserve memory>] <command line> If no reserve memory argument is specified, the program ctest will simply execute the program command line using the spawn function call in the C runtime library.

If a numeric value for reserve memory is specified, ctest does the following:

a) Allocate the indicated K bytes of reserve memory

b) Using malloc() allocate as many 1 K chunks of memory as possible

c) Free the reserve memory

d) Spawn the rest of the command line

e) Exit the program

This is used to test how much memory the various versions of the postman's sort require as well as to demonstrate the appropriate procedure to use to be sure that enough memory is available to run a called program. The following command executes PSORT with 200K available memory:

ctest 200 psort <t10kv >out -k 'a'-'z' This tries to execute the same with only 80K available memory. ctest 80 psort <t10kv >out -k 'a'-'z' It will fail with an out of memory message. Reducing memory requirements

4.3. Reducing memory requirements

If there is a shortage of available memory in which to run PSORT the following alternatives may be used:

a) If the program is to run on a 80386 processor, use PSORT3 . This is the 80386 protected mode version of the Postman's sort. It will use all available conventional and extended memory and 32 bit instructions to make sorting even faster. It requires only 30K conventional memory to run. This can be demonstrated by using ctest:

ctest 30 psort3 <t10kv >out -k 'a'-'z'

b) If the program is to run on a 80286 or better processor, use PSORT2 . This is the 80286 protected mode version of the Postman's sort. It will use all available extended memory. It requires only 80K conventional memory to run. This can be demonstrated by using ctest:

ctest 80 psort2 <t10kv >out -k 'a'-'z'

c) If neither of the previous two options is available, the buffer sizes used by PSORT may be reduced from their default values of 30K. Also memory allocation segment size can be reduced from its default value of 30K. Memory requirements can thus be reduced to around 128K depending on the keys and type of records to be sorted. Performance of PSORT may be seriously degraded in such an environment.

ctest 128 psort <t10kv >out -k 'a'-'z' -bs 4 -wb 4 -rb 4 -l 4