Vertex 2000: Post 2 of 2
This is the second of two posts regarding BMR Software's Vertex 2000 product. See the first post for appropriate disclaimer and background information.
****
Vertex 2000, the tool:
For simplicity's sake, let's call Vertex 2000 ... VTK.
Most vendor solutions attack the Y2K problem by changing source code. V2K uses a different technique that is commonly called a 'techie-trick', or 'bit-twiddling'. I won't go into the details here because it requires an indepth understanding of IBM mainframe architecture. That's beyond the scope of SI's investment forum content.
For those of you interested in the nitty-gritty technical details, contact me via email (tedennis@sedona.net for you lurkers who can't access my profile). I'll be glad to answer your questions, or forward your request to BMR Software if I can't answer it. Or, you can check out the BMR Software web site at bmrsoftware.com and email directly. They have been very responsive when I have had the need to communicate.
V2K works by 'zapping' (changing the instructions of) an executable load module. There is an external utility called the 'Enabler' that reads a load module, finds instructions that V2K thinks are related to date manipulation, modifies those instructions to invoke their proprietary routines, then rewrites the load module. The 'Enabler' also modifies the load module so it will initiate their proprietary routines when the module is executed.
The demo process was executed against a non-Y2K compliant COBOL II program (DEMOCALC) that was written to show the flexibility of V2K. It contains several (30) contrived Y2K situations that need to be handled. DEMOCALC uses an input text file containing dates in various formats, and the output is a report showing whether or not various compares and arithmetic operations worked as expected. DEMOCALC uses a 50 year window for handling all 2 digit years (50 or less is 20xx, 51 or greater is 19xx).
The demo went as follows:
1) Execute DEMOCALC in its native condition (pre-V2K) as produced by the COBOL II compiler and Linkage Editor (the utility that produces an executable load module from object code that is produced by the compiler). The DEMOCALC output showed several Y2K failures, as was expected.
2) 'Enable' DEMOCALC (see discussion of the 'Enabler', above). This was done with a V2K utility that put the V2K 'hooks' into the load module.
3) Execute DEMOCALC in its enabled condition. The output showed the same Y2K failures as prior to the enablement. This was to demonstrate that the enablement did not affect the execution of the load module. Thus, you can implement V2K changes prior to modifying any existing data.
4) 'Bigitize' the input data. This involves running a V2K utility that takes the decimal display dates and 'bit-twiddles' them so that the V2K proprietary routines can determine which century they are in.
5) Execute DEMOCALC in its enabled condition. The output showed that all of the Y2K failures had, indeed, been corrected.
Tah-dah! It works! That's all we need to know, right? V2K is the silver-bullet, right?
Well, in a word .... no. And, to be fair to BMR Software, they don't claim V2K to be a silver bullet.
It successfully handles decimal display dates, as was predicted by a few of us techies on the SI threads. Other data formats are not quite as black and white (more on this below).
Like any other newly developed product, it works well in the environment where the developers focused their efforts. It executes in an MVS (IBM's primary mainframe operating system) COBOL II batch environment. Other environments are in development ... CICS was specifically mentioned. Other environments will present them with additional challenges and surprises. The consulting group that developed the toolset is very proficient in Assembler, systems programming, and database handling, so I think they will be able to solve the majority of programming challenges that face them, given enough time ... which is in short supply.
At this particular time, V2K supports only COBOL II (also known as COBOL/370 and MVS COBOL), so many of the environmental issues surrounding the various other compiler versions are not a problem. The various versions of the compiler generate different startup routines and produce a different load module structure. (For you techies, yes it does run in 31 bit mode.)
V2K does nothing for other languages (Assembler, PL/I, etc.) or platforms (only mainframe MVS is supported). No databases were mentioned as being supported, but that doesn't mean they aren't. Note that 'bigitizing' data in a data base could cause severe repercussions for the database vendor supplied utilities that know nothing about 'bigits'. I don't know how anybody would go about circumventing that problem.
In response to a couple of nitty-gritty questions I asked regarding situations that the 'Enabler' might not be able to handle (like non-character display data), the answer was that V2K comes with an API (Application Program Interface) to allow programmers to access their proprietary routines. This allows 'ad hoc' programming of situations that are not supported by V2K. Programming ... meaning source code changes ... would be required. In my opinion, it would behoove BMR Software to make alliances with automated code change vendors that could make these changes for them. It would seem simple enough to define a 'rule' that the automated changer could use to invoke V2K's routines, assuming the automated code changer has a flexible 'rules' definition capability. Also, the tools that do 'bridging' could be used to do the 'bigitization' process. None of these actions is a piece of cake, but they are all doable.
'Bigitizing' date data will cause the existing tester/debuggers (a tool that allows a programmer to step through their source code interactively and view the values of data fields) to go haywire in the display of the user's data. There are at least 4 companies that produce them (CA, CPWR, VIAS, and a private company named Cole Software). Alliances should be made with them to recognize the 'bigitized' dates and handle them correctly. As it is, at least 3 of those debuggers will declare that the 'bigitized' dates contain invalid numeric data (according to the rules of IBM architecture, the 'bigitized' dates are not valid packed decimal data).
Up until now, there had been very little (almost nil) technical data available regarding V2K. In prior posts about V2K, I had 'guessed' about some of the technical inner-workings of the tool. Most of those guesses were correct. I was wrong about the way the V2K tool 'hooks' the object code. They have hooked it in a much cleaner way than I had guessed. Pretty sneaky, but technically sound. (Techies: It involves fiddling with the COBOL II Vector table, which was my second guess.) Supporting only COBOL II made their technique possible. To support other languages and other versions of COBOL, the more likely technique would have been the way I originally guessed. If they extend their support to other languages, it will be interesting to see how they go about it. (Techies: That's where the register usage issue and addressability will become a major problem.)
I think there's a good chance that the existing 'hook' technique will have problems in an optimized COBOL program, but don't know that for sure. If it has a problem, just turning off the 'optimize' option should alleviate the problem. I would also expect this technique to have problems with programs that have been 'CA-OPTIMIZER'd. Again, simply turning off optimization should alleviate the problem. These are environmental issues, not technical stumbling blocks. I think a client would be willing to de-optimize their code to make it compliant, if that was their only option.
They also circumvented one of the other technical issues I had with the 'PACK'/'UNPACK' sequence by performing the 'PACK' and 'UNPACK' operation themselves with their bigitizer (as I had postulated when I first brought up the issue).
One of the closing statements made by Bob Bemer was that V2K is a 'stopgap' measure. It will give users some time to correctly fix the Y2K problem, which he admits is the 4 digit year. Per Bob, the bigit method has the following advantages:
1) It is relatively easy to 'phase in' (you can intermix bigitized and non-bigitized data and programs)
2) It helps identify year values for the post-2000 program fix
3) It can be implemented rapidly, which gives time to rewrite the code that the bigit method doesn't support directly
4) It helps alleviate the pressure of getting it all done on time.
V2K is going into a Beta site next week (week beginning Jan 19, 1998).
This completes my review of Vertex 2000. If you have questions, please ask.
Regards,
TED |
