Progress
External Program
Interfaces


Overview Of Named Pipes With Progress

Named pipes provide a general exchange mechanism for text data, and there is no practical limit to the types of data you can exchange using them. Any data you can access as a character string within Progress, you can read or write to a named pipe. For example, you can use named pipes to issue SQL requests to a Progress session from within a spreadsheet program and receive the resulting data in the spreadsheet. As such, you can use named pipes to implement some of the capabilities provided by Progress Host Language Call Interface (HLC) and Embedded SQL/C (ESQL/C).

Figure 4–1 shows a typical named pipe scenario.

Figure 4–1: Typical Named Pipe Scenario

The message handler procedure acts as a server for a non-Progress application acting as requestor. The server reads each incoming request, processes it, and returns the results through a second named pipe. The messages can contain SQL statements, Progress statements, procedure names, or anything that your message handler procedure can manage.

Access From Progress

Progress accesses named pipes already created on your system; Progress does not create named pipes itself. Progress treats a named pipe the same way as it treats a text file. The Progress 4GL statements INPUT FROM, OUTPUT TO, DISPLAY, SET, EXPORT, and IMPORT all access named pipes and files identically.

Named Pipes and Files

Named pipes combine the features of files and unnamed pipes. Like a file, a named pipe has a name and any process with appropriate permissions can open it to read or write. Thus, unrelated processes can communicate over a named pipe. Like an unnamed pipe, a named pipe behaves like a first in/first out (FIFO) queue. A reading process reads and removes from the pipe the first unit of data written to the pipe that has not been read.

Uses For Named Pipes

The scenario in Figure 4–1 illustrates important core concepts, but it is a relatively simple example of what you can do with named pipes. For example, you can design your message handler procedure to handle requests from more than one non-Progress application user at a time. Another idea is to design a message handler that manages multi-line requests as well as single-line requests. This makes it possible for the requests to include, for example, Progress FOR EACH blocks.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095