I can speak for one vendor only.
![[bigsmile]](/data/assets/smilies/bigsmile.gif "[bigsmile] [bigsmile]")
When one considers client server, the question is usually:
When considering all the hardware and software between the actual user, presumably at some sort of terminal, and the data that is of interest to the user, where do I place the 'network'?
In the 'old days' the network was just the means of wiring dumb terminals to a central computer. This was and is not considered client/server, though there was a surprising amount of computing going on in some of those dumb terminals.
The wiring of the 'old days' can now be replaced by the internet (or intranet), with a desktop computer behaving as a dumb terminal, often by using
telnet or some other terminal emulator program. This is
not considered client/server -- but we are getting closer.
The first adaptations of COBOL to networked PCs was not client/server but rather a network of
cooperative peers.. In this model, which is still in widespread use, each PC is running the entire application but is cooperatively sharing a set of data files located on one or more computers.
It is helpful here to digress for a moment to understand how each PC dealt with the data files.
Consider a complex file structure such as an indexed file, which contains not only the actual data records, but also structures (often implemented as B trees or B+ trees) that allow the associative lookup on keys which distinguish indexed files. When an application program READs a record in an indexed file, the file system library must first find where the record is within the file. This usually requires several physical reads to search the B tree structure stored in the file, followed finally by a read to get the data record.
In the
cooperative peer model, all of these physical reads occur across the network shared by the peers. This model exposes at least two inefficiencies. First, each of the physical reads experiences the sum of the network latency and the disk latency. Second, as the number of users is increased, the network can become saturated. These inefficiencies were a target for the client/server model - the
client/server file system.
The
client/server file system inserts the network not at the physical read level described above, but instead at the
logical READ level. In this model the COBOL READ request is sent across the network to a centralized file server computer. The file server computer does all the physical reads necessary to find the desired record, and sends the desired data record back across the network. This model thereby eliminates a number of round trips over the network, thereby increasing speed and improving apparent network capacity as measured in users. There are some other efficiencies that might be a side benefit, such as more efficient caching of the file's data thereby eliminating some physical reads and their associated disk latency.
Examples of the
client/server file system include Pervasive's B-trieve and RM/COBOL's InfoExpress. Micro Focus and AcuCOBOL also have client/server file system offerings.
End of part 1. I must get some work done.
I will try to come back later today with additional client/server implementation possibilities. Question to "This Forum's Top Experts" -- should I turn this into a FAQ (after peer review, of course)?
Tom Morrison
