Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Y2K (Year 2000) Stocks: An Investment Discussion -- Ignore unavailable to you. Want to Upgrade?

To: tom rusnak who wrote (7148)	10/26/1997 8:44:00 PM
From: TEDennis	Read Replies (1) \| Respond to of 13949

tom (the lower case one) ... Other than stating specifically that what the opinions I post are partly based on what I read in a public forum and partly based on experience, what else can I do to disclaim knowledge of Bemer's solution and whether or not it's worth a darn? In response to emails from a couple of concerned posters who are stockholders of companies with much emphasis on Y2K, I posted my opinions of the technical data that was available to public access. From what was available, I extrapolated what I would have done if I'd been in the same predicament as the developers of the solution, and posted the concerns that became immediately obvious to me. I stated they were my opinions, and stated that no guarantees of correctness were provided. I also stated that the "techie-trick" solutions being developed (and there are several) should be used only as a last resort. I still believe that. The intangible long term costs of relying on these techniques are higher than most people realize. As a migration tool to get past "the" date, they offer some promise of success. But, they are certainly not guaranteed, and in my opinion, the risk of failure is too great. It's the old risk versus reward argument all over again. I don't want my bank using techie-tricks, nor do I want any of the firms that I invest in using them. What guarantee do we have that the developers of these techie-tricks will catch all required data and code interactions? None. The same could be said of source code change solutions, but at least the programmers have control over any problems that might be encountered. Not so with techie-tricks. You have to get the vendor involved. And, there still exists the problem of passing data to and from sites that might be using different solutions. Major gotcha. The only way to fix those instances is to create bridge programs on both sides that convert to/from 4 digit years to/from whatever method each side is using. Ugly. Inefficient. Error prone. My opinions, of course. Yes, I'm a purist. And a perfectionist. And, any number of other terms that aren't permissible to use in a public forum. I don't think I was 'belittling' Mr. Bemer or his suggested solution. I do think I was providing readers of these threads some balance to what was otherwise a one-sided argument. Readers here know that I'm a word-class technical skeptic. So far, I don't think they've had reason to be disillusioned with my opinions. Hopefully, it will give them food for thought. Nobody should take anybody's word in an online forum. It's a discussion medium and nothing else. Regarding the method of intercept, I'm glad to hear that BMR is responding to your emails. Since they state they're not using the "invalid opcode" method (that was a reasonable guess on my part; I think you would agree), then they have some other interesting challenges to attack concerning linkage registers, as I mentioned in a followon post. Good luck with the trials you're holding in Australia. I hope you succeed. And, you know you can always call on me for suggestions to help you over those technical issues you're bound to encounter. I will, of course, expect to be included on the IPO. Wishing you success in business and family matters, TED

To: tom rusnak who wrote (7148)	10/26/1997 9:44:00 PM
From: TEDennis	Read Replies (2) \| Respond to of 13949

tom: OK .. one more quickie, then I'll drop this ... The COBOL syntax provides the "IF NUMERIC" construct to allow programmers to 'pre-edit' data for numeric content. This was (and still is) used frequently to filter out bad input data from being saved in files or being used in calculations. Invalid data will cause all sorts of ugly things to happen to program logic. Like abends, for one. The old COBOL compiler's implementation used to check fields for numeric content by linking off to a COBOL runtime routine that did the following (I'll word this in English so non-techies can play along) ... 1) Move all zone bits of the input field (x'F-F-F-F') to a work area. 2) Compare work area contents to '000000' (x'F0F0F0F0F0') 3) If work area = zeros, then the field is numeric. If not ... (and it won't be for bigitized fields) then it's NOT numeric and the IF NUMERIC test will fail. So, any solution that fiddles with the zone bits will have to also prepare a 'replacement' runtime routine that 'allows' Bigits. But, if the purpose of the routine was to filter out invalid data, and Bigits are actually 'invalid' zoned decimal data ... uh .... well, I think you get my drift. How does the replacement routine know what's invalid, and what's 'real' Bigit? By the way, I think there is at least one version of the compiler that expands the zone-check inline ... so there's no call to a runtime routine. Or, maybe that's a compiler option to optimize the object code for performance. I don't remember (getting older, you know). And, of course, there are lots of assembler programs out there that do the same test-for-numeric process (it's an example in the Assembler Programmer's guide!). What will happen when they look at a 'bigitized' field? Need I say more? 4 digit expansion. Yep. That's the ticket. Sure is a pretty day. TED