Last update:
December 1, 1998
Over a year ago, when I was implementing password security in Pragma 5, I was thinking that it would be nice to have a small program on a server that would authorize the various workstations to run. In other words, to implement a network security. But even a quick look at the problem showed that the effort was not worth just to implement a security scheme. After all, security is mainly for our benefit (our meaning Logical and dealers) and not for the end user. So the project got shelved.
A few months ago Renato Cevoli asked me if I had any plans to make PFM a client server system. I was taken by surprise. Why make PFM client server when Btrieve already is client server (with B-request)? As an added push Renato nonchalantly added: "after all, it is just a big cut and paste orgy for you".
For those that are new to Logical let me explain what Renato meant. Back in the stone age of computing, in the year 1979 or thereabouts, Logical (then known as Logical Machine Corporation) started to develop what was then marketed a year or two later under the name of Goliath, the Logical Fileserver. The logical Fileserver was one of the first, if not the first client-server computer system.
The Fileserver consisted of a centrally located computer with up to (in the last models) 48 serial ports to connect with a serial cable up to 48 workstation computers (not dumb terminals) running the Pragma language. All the external files (and that is the origin of the name "external") were located on the Fileserver. When a workstation wanted some data, it would send over the serial cable the request to the server. For instance, if a workstation needed the first record in the file "ADDRESSES" it would simply ask the Fileserver to GET the FIRST record in the file ADDRESSES. The Fileserver would then do all the dirty work ( including record locking when needed) and send back the data of the first record, together with the status of the operation ("OK", "record not found", etc.) to be put into the noun EXTERNAL ECHO. Now simply substitute the Logical Fileserver with a network server and you have today's client server model. What Renato meant with a cut and paste orgy is that all the code necessary to send a request (GET FIRST ADDRESS, etc.) is still there, both in Pragma 4 and in Pragma 5. The only part missing is to send these requests through the network to a program on the server (the Fileserver) that then acts on these requests and sends the results back. One of the added benefits of client server computing is that the network traffic is reduced and the speed and safety enhanced.
The idea was appealing. Last Summer I asked Manfred Donimiersky what he thought of the idea but he said that it was not as simple as I envisioned since we would have to cut up the requests in packets that conformed to the network protocol, etc., etc. A typical byte-bender answer. So I shelved the idea again.
In September we started having the file corruption problems with PFM and Windows NT servers. Our clients that are using Btrieve and Brequest are not at all affected by the issue. Client server is the logical long range (pun intended) answer. Amidst all those problems Renato asked me: "When will Pragma 6 be available?". Pragma 6? OK. We tried an April fool joke last year, announcing Pragma 6, but in many instances the joke fell flat because I did not realize that April fool's days is not celebrated everywhere (in Spain they have something similar, but at the end of December or thereabouts). I told Renato that it was a joke, but he was serious. "You should enable Pragma for the Internet and Intranets" he said.
Sure. I need to write protocols for TCP-IP just as I need a hole in the head. That by itself is a lifetime job. But few days later I happened to be in contact with the Canadian company that had supplied us the code for the grid. I have a good working relationship with them and their support was and is superb. What if they could help? An e-mail later I receive the answer: their ultimate TCP-IP was just what the doctor ordered. No byte bending, no reinventing warm water (a favorite Italian expression). Thus the Goliath 5 project was born. The goal is to make PFM perform in a client-server mode on network. Then across the Internet. Admittedly, a very ambitious program.
I intend to keep a log of my (mis)adventures implementing Goliath 5. I know that I am going out on a limb if for some unforeseen reason the concept should fail or not work. But what the heck.
November 5, 1998
I receive the whole TCP-IP package via Internet from Canada. It is big and overpowering file. After reading helps for a few hours I want to do something practical. The first thing to do is to change the protocol of my network NET BEUI to TCP/IP and then add an Intranet. About one hour later I "ping" from my computer the network server and get the desired answer. See the Pragma 5 Manual "Installing an Intranet" for more information.
November 10, 1998
I have programmed the examples of the FTP client and FTP server provided by Dundas software, the Canadian company that provided the TCP/IP package. The examples are well written, but of course Murphy gives a helping hand (if anything can go wrong it will). The one time the examples do not exactly specify where to enter a new function in a module I add it in the wrong place. After an e-mail with Canada the matter clears up and everything works as hoped. I am on top of the world. My only gripe is that I had to enter all the code myself by hand. The examples supplied do not use the Microsoft Foundation classes but the old SDK (Software Development Kit) which are as user friendly as a bear with a thorn in his foot and to me just about as useful. And to add insult to injury they do not even compile with the new version 6.0 of the C++ compiler.
November 12, 1998
The examples of the FTP client and server work OK. They are bare bones but work. But now what? The instructions sent by Dundas come to a screeching halt. Where do I continue? How do I add things? I have to start plowing through the Dundas code. Luckily it is fairly straightforward, but I start to think that someone in Dundas has a sadistic streak.
My only consolation is that this way I really get to know their code.
December 1, 1998
I have finished the first useful version of Goliath and Pragma. At this point Goliath works on my network and grants the security to my two workstations.
The project was actually fairly straightforward to implement. I had a false start that cost me two days before I separated the granting of security tokens from a normal connections. It also seems to make more sense to have Goliath work always and only inhibit the dispensing of security.
What took a fairly long and boring work was to convert the filemanager module of Pragma from C to C++. This was necessary because I absolutely do not want to use old C code in Goliath. A wrong casting drove me nuts for a whole day, but the new filemanager seems to work. Whenever I change a module from C to C++ I get the impression that the execution of that code gets faster. I suppose it is just a psychological reward for countless hours of cutting and pasting.
Now the next big step is to test Goliath in the real world.
