CLIENT/SERVER 2

[mfcobol2002]

Respected Gentlemen,

I have been reading a lot on CLIENT/SERVER in Cobol and me I think am not understanding anything.
Using a net containing a Server Windows or Novell and workstations windows, how to have a true CLIENTE/SERVER using the native base COBOL? Explaining better, which options and resources should use so that that approximated of what it happens in SQL, in other words, the processing in the server and just the displays in the stations.

respectfully

 

[hansie]

Hi,

I don't know exaclty what you mean, but we are using for almost 20 years the most elementary form of client server !!

Client : telnet
Server : unix with a cobol runtime

Hans

 

[k5tm]

I can speak for one vendor only.

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

 

[k5tm]

Minor addendum to Part 1:

The client/server file system probably more closely resembles "what ... happens in SQL" than the examples to follow. Most SQL client/server implementations insert the network at the logical SQL statement level. A SQL statement will be sent across the network to the SQL server, which will retrieve the result set (for example), and the result set is sent back across the network. Of course, given stored procedures and the like, a lot can be done with this model.

Tom Morrison