Ceci est une ancienne révision du document !
NOTE: Parts 1-6 are FCM#105-110 In the early days of computers, a company called Digital Equipment Corporation (DEC) created its 32-bit VAX computer using OpenVMS as its operating system. Because a VAX/VMS computer is so reliable, there are today - after more than 25 years - still a large number of them in use. But, in the end, even these reliable computers will have to be replaced. As described in part 1 (FCM#105), you could migrate from VAX/VMS to Linux, as the way Linux works is largely compatible with OpenVMS. If you use Pascal as your programming language, you will find that Lazarus/Free Pascal is a good replacement. But there are technical functions used in OpenVMS with no apparent replacement in Linux. In this article, I will update you with improvements and experience since my last article. Early retirement? In the conclusion of part 6, I told you that I was going into early retirement. That was a big mistake. Two years later I was approached for a position in Vienna where they had a few 20 year old Alpha’s and now I am working there for three years already. And if I listen to the customer, I get the idea that I will be working there long after my retirement.
File version numbers In part 4 of my article, I told you that “If your project is depending on this behavior (the file version, not the crashing), you will have to change your programs. Either by adding a version number to the name or type, or by changing your project in such a way it will no longer depend on the file versions.” My very first potential customer (my current job) was heavily relying on these file version numbers. One job is being started many times with different parameters, so many log files are being created with the same name. So I changed my file handling routines to use version numbers. As Linux does not have an equivalent, I solved it by adding (and expecting) the file version number as a part of the filename in the format “;1234”. As this is a string, and not a 16-bit number, the restriction of the maximum of 32767 is lifted. That might cause problems in a project that relies on that maximum, but that’s something for the future. Another issue with log files of batch jobs is that if you ask the system what the log file of job xxxx is, you will get the filename and location only. You have to use tricks like writing a token in the current log file and search through all versions for that token to find the file version number. This made me change my implementation of the batch by including the file version number as soon as the job starts.
Graphical DCL debugger When trying my first real migration, I ran into difficulties. Not knowing if my implementation of DCL is wrong (yes, I found a bunch of bugs), I needed a way to see what’s going on while a script is being executed. The normal way to debug a DCL script is to put in some write or show commands. But this is very tedious and you have to put the commands in at exactly the right points, which you do not know upfront. If only you could debug a DCL script the same way you would debug a program. I have created exactly that. A graphical application with breakpoints, watchpoints, and a continuous display of symbols, local and global. You can specify a break on exit, to determine which exit point a routine takes (including error exit). So you have the opportunity to see what the value of the local symbols are on exit (or the cause of the error). I wished I had this application years ago.
Codasyl database extensions In part 6 I told you about a different kind of database: a network database called DBMS32. In fact I should have called it a Codasyl database. This kind of database has been around longer than relational databases, and even had a normalization committee. My implementation is loosely based on the formalized specification. When my customer was facing the problem that a chain of jobs took way too long (6 – 7 hours), I started a feasibility study to see if I could do it better using my Codasyl database instead of Oracle. And of course I ran into the limitations of a Codasyl database. As it is designed for speed, it is not suitable for large sets of data. But I didn't give up and tweaked my implementation to handle millions of records and introduced indices to keep the speed. Oracle uses special tables for indices that need to be updated. Those tables can get fragmented, so it helps to do a rebuild once in a while. But that can take more than an hour, and the tables that use these indices are blocked during that time (a problem that is very current at my customer). In my implementation, the build is so fast (less than a second) that I decided to do it on-the-fly instead of stored. The end result was a processing time of less than half an hour, so more than 10 times faster. I was also telling you about a graphical application to replace DBQ, the database interface program. I have extended this application with a graphical representation of the interlinked data, with the possibility of moving records (with your mouse) within a list to change the order.
Conclusion As you can see, I haven’t been inactive in the last 5 years. My new job is challenging, time consuming (up to 10 hours a day plus on the weekends), and is challenging all of my competences, but can also be boring from time to time. So if you have a new challenge for me, like speeding up your application by using my implementation of a Codasyl database, you can always send me an email or contact me through LinkedIn.