[Home]David Kra's Protocol Converter

FlowBasedProgramming | RecentChanges | Preferences

DavidKra writes:

In the Series/1 minicomputer of the 1970's and 1980's, there were TP monitors, CF (Communication Facility)for the EDX operating system and CM for the RPS operating system that could also implement message driven FlowBasedProgramming. All of EDX was one address space. I don't know about RPS.

In 1981 I built a system using CF that consisted of several programs that sent messages to each other. One caught messages from dialin users and passed them to programs communicating on leased lines (one SDLC, one BISYNCH) to different mainframes, using different protocols. For each input message the program also sent an activity-tick message to an inactivity monitor watchdog program. Another sent a different message to the watchdog every minute. If the watchdog got n minute-minder messages with no intervening activity ticks, it issued commands to disconnect and reset the dialin port and the host link.

Other programs intercepted system messages and did other automated operator tasks. It ran unattended for years.

I had [the] IBM Systems Journal article in mind when I developed that system [this refers to the 1978 article on FBP entitled "Data Stream Linkage Mechanism", IBM Systems Journal Vol. 17, No. 4, 1978].

EDX and CF had a big following and have been ported to other machines and operating systems. See http://www.cipher.com/embedded/systems_integration/s-1_conversions/replacement.html.

This Series/1 CF (Communication Facility) based system [referred to above] didn't have a formal name. It was a one-of-a-kind protocol converter that supported two downstream lines and two upstream lines. If I recall [David writes], each downstream line was dedicated to a matching upstream line.

The downstream links supported insurance agents' minicomputers emulating the dial protocol of the BISYNCH single terminal 3275 Display & Control unit. The BISYNCH DIAL 3275 protocol was the bastard offspring of a mixture of 3271 multidrop leased BISYNCH and 3780 dial BISYNCH. The error handling protocol was very stateful and unique.

The upstream host computers did not support this protocol. One upstream link was to a TP monitor that did support multidrop leased line BISYNCH 3271. The other upstream host link used leased line 3270 SNA protocol. Neither had a clue about supporting dialing in, unintentional disconnect, prevention of the next caller from resuming where the previous caller left off, idle time out, etc.

FlowBasedProgramming | RecentChanges | Preferences
This page is read-only - contact owner for a password | View other revisions
Last edited February 9, 2005 8:56 pm by PaulMorrison (diff)