Dear DDJ,
In the article "Date Compression and Year 2000 Challenges," by Robert L. Moore and D. Gregory Foley (DDJ, May 1998), I was surprised to see the Windowing concept referred to as a preferred method for meeting the much closer Year 2000 deadlines. Surprising, only in that I've previously suggested the same method, and your discussion of the approach shows I'm not totally out of touch with reality.
In Robert and Gregory's discussion, one aspect of Windowing may benefit from an alternate approach.
In dealing with sorting of Y2K-deficient data, they mentioned an interpretive program would need to be activated for converting non-Y2K data into a sortable Y2K- compliant format. A secondary interpretive program would then need to be written for converting the sorted Y2K-compliant output back into its native format. Instead of this approach, if achievable, the following would be preferred.
Have the OS sort utility modified to include a sort option that incorporates a Windowing interpretation. In the JCL, a one-byte field would indicate that sort requires the sort Windowing option. This field (code) would be available for each sort field. As with Windowing, the sort parameters would contain a singular field for specifying the Windowing (pivot) year. The sort would perform an on-the-fly Y2K interpretation while sorting the data, without actually modifying or expanding file contents.
I realize many OSes may be in use and are no longer upgradable. With the billions of dollars which will need to be spent on Y2K compliance, I would think enough clout could be established to coerce someone to make the required modifications.
An alternative, the interpretative programs (used before and after each sort) described in the article could be designed to utilize the JCL passed codes, similar to the sort parameters context in order to determine which fields need to be converted. By using variable parameters of this nature, it wouldn't be necessary to write a separate set of programs for each sort.
Storing the pivot year in the Working Storage Section was also recommended. If only one program needed modification for Y2K compliance, that would be great. However, thousands of programs are going to be modified. To adhere to a Sliding Windowing concept, storing the pivot year in Working Storage would require massive modifications just to affect a new Window. Perhaps a singular file containing the definition of the Windowing method/period could be created (for storage of any periodic variable data). Then each affected program would open the file, extract the windowing data, then store the data in Working Storage.
After this was integrated into all programs utilizing the Sliding Windowing concept, modifying the pivotal year file would simultaneously affect all programs.
Wayne H. Wilhelm
whw96sv@cardnet.stark.k12.oh.us
Dear DDJ,
One problem with all the compression schemes mentioned by Robert L. Moore and D. Gregory Foley in their article "Date Compression and Year 2000 Challenges" (DDJ, May 1998) is that human readability is lost. ASCII only makes use of the seven least significant bits of each word. Using the most significant bit from each of the six characters used to represent a date by the MMDDYY method, and using a base year of 1900, we can extend the present method to 64 centuries. Hopefully in that time we can work out a better system. Dates printed by a routine that strips off the most significant bit will still be human readable.
Lloyd C. Brown
Lloyd.Brown@gat.com
Dear DDJ,
I congratulate Robert L. Moore and D. Gregory Foley on their clear, well-written article "Date Compression and Year 2000 Challenges" (DDJ, May 1998) that focuses on the fundamental engineering problem of the Y2K "situation." At work, I have had to complete many spurious Y2K forms and questionnaires from customers who just don't get it, and who have latched on to the four-digit year as a mantra to protect themselves from Y2K ruin. With Robert and Gregory's article, perhaps I can teach them to converse rationally about the subject (one can always hope).
However, I was disappointed about a slight omission in the discussion -- the issue of backward compatibility of storage. As mentioned in the article, there are two goals in programming a Y2K fix: to provide a representation for all dates the system could possibly need, and to do this with a minimum of programming effort (including software maintenance). The authors also mention that compression methods can reduce the amount of coding required to fix Y2K problems. You can reduce that effort even further if you don't have to convert all your persistent data to a new representation.
All of the compression methods provided in the article use the entire "value space" of each representation. As such, they all collide with the legacy representation. For example, the six characters "012001" could mean January 20, 1901 (MMDDYY) or January 1, 1912 (CYYDDD) or January 20, 12337 (MMDD 16b-year). So there is no way to examine a date to determine the encoding scheme used. Implementing these representations requires that all existing data be converted before the new software may be used, and that the old software is fully retired before the change.
Namespace techniques can be used to remove this burden, by designing the new representation to be complementary with the legacy representation. As mentioned in the article, the MMDDYY format makes very sparse use of the 48 bits required for storage; all of the methods described by the authors can be modified to exclude the normal MMDDYY representations from their "value space" and still retain sufficiently large ranges of dates. For instance, modify the CYYDDD format so that values of C start at "2"; values of "0" and "1" would indicate data in the old format. This still provides 900 years of dates, but allows the program to read data in both CYYDDD and MMDDYY formats. Similar tricks will work with each of the other formats described -- I leave the details as an exercise to the reader.
By using a backward-compatible compression scheme, the need for updating existing data sources to the new representation is removed. To implement the fix, we only need to reprogram the data interface (read from/write to storage), possibly adjusting the internal date format and user output to account for the increased range of dates. Then release the revised program to users. In my experience, this is the minimum effort required to correct a Y2K deficiency.
Curtis S. Carney
awiggin@slip.net
Dear DDJ,
In "Building Distributed Applications with Java and CORBA" (DDJ, April 1998), Bryan Morgan does a good job with outlining to intricacies of CORBA. I do find, however, that I cannot agree with some of his statements and findings.
First, CORBA is not a vendor-independent operating system. The Object Management Group (OMG) never intended CORBA to replace the core operating system of any node in an n-tier client/server environment. Bryan's statement can leave someone thinking that CORBA can replace NT or UNIX. Had Bryan stated that CORBA provides a vendor-independent environment for interobject management across a network, I would have agreed with him.
Secondly, the proper use of the Internet Inter-ORB Protocol (IIOP) is somewhat of a religious war among CORBA proponents. Bryan flippantly discusses IIOP as a "wire-level protocol that resides on top of TCP/IP." He further states that IIOP "lets one vendor's CORBA 2.0-compliant ORB exchange objects with another's." Bryan is certainly stating the promise of IIOP rather than the fact. Let's look at the facts:
CORBA is certainly the wave of the future. Since CORBA is an evolving specification, it is important that forethought and prudence are used to ensure that we build feature-rich and robust object-based client/server applications. As Java replaces C++ as the developer's tool of choice for building client/server applications, we must create greater awareness of what is real and doable, versus what is promised.
Richard S. Kravchuk
richard.kravchuk@ey.com
Dear DDJ,
Thanks to Al Stevens for the info in his April 1998 "C Programming" column on how to solve the problem with a window that could either be maximized or minimized. I had a clean install of Microsoft office on my machine. The only problem was that Microsoft Photo Editor refused to be anything but maximized or minimized. After reading Al's column, I searched the registry and found InitialPosition=65500,2,66112,565. I deleted that and all is well now. Not a big deal, kind of annoying, so I never went too far in finding out the problem.
Kevin Peck
KPeck@bridge.com
DDJ