Dear DDJ,
I read with interest the letter from Irwin Scollar in the May, 1997 issue of DDJ and would like to respond to his misadventure.
Since 1994, Europay International, Mastercard, and Visa have been preparing member banks for the year 2000 and its effects on card issuance and their acceptance at point-of-sale terminals.
However, some terminals (owned by the banks themselves), as Mr. Scollar found out, have not yet been upgraded to read cards that show the year 2000 or beyond as an expiration date. I would like to point out that the problem of nonacceptance of Mr. Scollar's card had nothing to do with the "Mastercard Verification Computer" or the brand, but rather with the software located at the retailer, in this case, the airline's point-of-sale terminal.
The life cycle of every card currently being issued, again regardless of its brand, extends the expiration date to the year 2000 or beyond. That is why Mr. Scollar's other, older card (in this case, a Visa), which had an expiration date prior to the year 2000, was accepted.
All the payment organizations and banks are working diligently to ensure that year 2000 issues are resolved as quickly and smoothly as possible. We must, however, accept that given the huge scope of such an undertaking, there will be some bugs to shake out.
We regret it became necessary for Mr. Scollar to make a long-distance call to get a response on why his card didn't work. Normally, the bank issuing the card should resolve such a matter for him.
I would be grateful if Mr. Scollar could advise us of the retail location where the rejection occurred so that we can advise the appropriate bank to correct the situation.
Richard Tischler
Europay International S.a.
Waterloo, Belgium
Dear DDJ,
The story about Harvey Alter's Y2K invention (mentioned in Jonathan Erickson's "Editorial," July 1997) is amusing but sad. I fear for the intellectual quality of the U.S. with things like that happening. "Subtract twenty or more years." Heck, why not just subtract 100? Then we would be back in 1897...what a hack...sigh.
Woody Baker
knapper@beacontools.com
Dear DDJ,
In Michael Swaine's May 1997 "Programming Paradigms" column, I read for the nth time the statement "VisiCalc introduced the concept of the electronic spreadsheet." I have to tell you that it ain't so.
In the early '70s, I was using Omnitab II on the CDC 6600 at the University of Texas. The program came from what is now NIST, then the National Bureau of Standards, and was a full-fledged spreadsheet. Input and output were suitable for a teletype interface, but the spreadsheet metaphor was fully developed.
I quote from NBS Special Publication 701:
OMNITAB was conceived by Joseph Hilsenrath in the early 1960's....The heart of the OMNITAB design was the universal worksheet concept and the use of very simple English-like instructions to perform scientific calculations on data in columns of the worksheet. (...) A complete description of the first Version of OMNITAB, which was programmed for the IBM 7090, is given in...National Bureau of Standards Handbook 101; 1966.
No doubt VisiCalc was the first commercially successful spreadsheet, but it was certainly preceded by Omnitab. On the other hand, a descendant of Omnitab is still commercially available as Minitab. Fortran source code for the last version of Omnitab, Omnitab 80, is still available by ftp from NIST. So I would say that Omnitab is the oldest available spreadsheet ever, probably one of the oldest continuously available programs of any kind.
Steve Tedder
stedder@tulsix.utulsa.edu
Dear DDJ,
In his column "How do I create My Own Security Manager?" (DDJ, June 1997), Cliff Berg describes the implementation of a Java Security Manager that uses thread groups to restrict access to valuable system resources for untrusted code. Unfortunately, this manager does not work. For objects that implement the finalized method, it is unspecified in Java on which thread the Java Virtual Machine will execute this method before the object will be garbage collected. The following code skeleton shows how to exploit this hole:
class BadClass { public void finalize() {
if (Thread.currentThread() == some system thread) {
do something bad
} else {
new BadClass();
}
}
The finalized method just checks which thread it is executed in. If this is some unrestricted system thread, it does what it wants; otherwise, a new object instance is created with the hope that the "child" will be more lucky in escaping from the thread-group sand-box established by the Security Manager. So after the first instance of BadClass is created by untrusted code, sooner or later it will get a chance to cause damage.
Such security holes can be prevented but it would require a different approach to the SecurityManager implementation, for example, one that is used in current Java-enabled browsers. It is not easy to write the correct SecurityManager. For example, even after extensive testing, Netscape Navigator 3.0 was released with a bug in the implementation that was addressed only in 3.01.
Igor Boukanov.
igor.boukanov@fi.uib.no
Dear DDJ,
Just a note of thanks to Al Stevens for his "C Programming" column on DScope (DDJ, March 1997). It was quite interesting. I can especially relate to it since I too am using a One Touch II system. However, I didn't know that the manufacturer would provide a cable and software for it. Thanks for the info on interfacing the One Touch system. I am going to try it.
Dick Bender
rick@vms.cis.pitt.edu
Dear DDJ,
I read Al Stevens' "C Programming" column on DScope (DDJ, March 1997) with great interest. I have had a similar problem trying to get the control codes for my Kenwood R-5000 shortwave receiver. I figured I could get Al's code, compile it, and connect my old 386 machine between my controlling computer and the radio. But first, a bit of background...
I am in the USAF and have experience in wideband/Satcom maintenance and I'm now working in personnel database management. I am also going to school at night working on a CMIS degree at the University of Maryland.
I have a couple of shareware and commercial programs to control my radio, but have had a desire to write my own as I am taking programming courses. We use Linux on the school network and I have it running on two of my home systems. I will be trying to write the program for Linux. The problem was that I didn't know the control codes to send to the radio to change the functions. I didn't want to send arbitrary codes in fear of destroying an expensive radio. I downloaded Al's code and compiled it the first time. The first problem I ran into, however, was that the radio is hard jumped to 4800 baud, and Al's program didn't support it. Reviewing his code, I added one line in Al's case statement between 2400 and 9600 baud and recompiled. After trying it again, I got data! Thanks for this program. I am on my way to documenting the codes used to control the various functions of my radio. I have also used it to monitor a few other programs, such as Fast Lynx, an old DOS-based LAPLINK style program. It is very educational.
I appreciate the fact that Al specified the compiler and other relevant information needed to compile the code. I have tried in the past to use code from magazine articles only to find that they used a third-party library I didn't have or something along those lines. Since I am "playing" with Linux a lot, I like to include statements in the start of my code specifying what version the compiler and libraries were when I compiled the program. I think this will help in the future if someone else wants to use the code or I "improve it" and it won't work with a newer version compiler or new libraries.
Bryon Wagner
wags@netcomuk.co.uk
Dear DDJ,
Just a quick note to say that I liked Al Stevens' column on DScope very much. I did a similar thing on a CP/M computer ages ago and guess what -- it's called "DScope." Don't worry, I will not be letting any lawyers loose!
One thing though: A potentional problem is the fact that you are routing the COMM through the PC. This results in a retransmission delay of at least 1 character time. This can cause problems that you are trying to find with a protocol to go away or cause new ones.
A much simpler approach is to simply not disrupt the "link under test" at all. Just wire the two transmission lines to the receive inputs of your monitoring PC. Your software will only have to receive, never transmit. It is perfectly legal to connect more than one receiver to a RS-232 transmitter. You can make yourself a nice little adapter cable for this. Try two back to back D-9 male and female (to insert into the COMM line) plus a bit of wire and two additional plugs to go to the monitoring PC.
Want an encapsulated COMM API, do you? Well, it's easy. Get rid of MFC and/or OWL and make the bold (but beautiful!) move to Delphi or, if you can't stand Pascal, embrace Borlands C++Builder and download one of the many Delphi comms components. Most work just fine and are an absolute pleasure to work with. Fully buffered fast comms is only a few mouse clicks away. Be careful though -- Delphi or C++Builder will change your thinking forever!
By the way, my old CP/M DScope is still standing faithfully in the corner waiting for opportunities to debug some wayward protocol.
Rainier Lamers
Johannesburg, South Africa
rainier@questek.co.za
DDJ
Copyright © 1997, Dr. Dobb's Journal