Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
In 894315.74051...@web54604.mail.re2.yahoo.com, on 01/09/2010 at 12:49 PM, Ed Gould ps2...@yahoo.com said: Either that or they are afraid that other clients will find out and it will cause a mass migration. Well, if I found out that a vendor had sued for dropping him, I would never risk leasing his software in the first place. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@bama.ua.edu Sent: Fri, January 8, 2010 6:49:52 AM Subject: Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010 Ed Gould wrote: The salesman called me and very nastily said we will sue. I said go ahead and here is our lawyers name phone number. They want to *sue* just because you dropped their product? Yes in fact in the year since I have had another vendor say the same thing. My guess is that they think it will scare the client into renewing. Either that or they are afraid that other clients will find out and it will cause a mass migration. These vendors are desperately crazy! I have no idea if the vendor is around anymore and I could care less. Good that you survived them. These unnamed vendors are probably bored or clueless... :-D Now, if I could get at least some common basic *service* from vendors to start with, but that is another gory topic for other rainy day... Groete / Greetings Elardus Engelbrecht I hear you on that. I have had 2 bad experiences just from Germany alone. One had to do with sending fixes out and expecting the user to hand re-link the lmod outside of SMPE's control. The other one was the typical how dare you question the software. The product about which I wrote the above item was American. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Imagine if Amadeus had gone down on the 1st rather than Sunday ;-) Wouldn't *that* have drawn some heat. Shane ... The BoQ one was the first I saw. That quacks like a Y2K-type problem despite a claim to the contrary. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Ed Gould wrote: The salesman called me and very nastily said we will sue. I said go ahead and here is our lawyers name phone number. They want to *sue* just because you dropped their product? These vendors are desperately crazy! I have no idea if the vendor is around anymore and I could care less. Good that you survived them. These unnamed vendors are probably bored or clueless... :-D Now, if I could get at least some common basic *service* from vendors to start with, but that is another gory topic for other rainy day... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Maybe sue-icidal. :-) Cheers, Martin Martin Packer Performance Consultant, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Elardus Engelbrecht wrote: [snip] Now, if I could get at least some common basic *service* from vendors to start with, but that is another gory topic for other rainy day... Why not now? It's Friday. So you can't get common basic *service* from any of your vendors? Then why not raise issues to management, spell out the problems, change vendors? Are all your vendors reluctant to provide service? What exactly is wrong? Can it be fixed? Are there issues of fraud, kickbacks, nepotism? All of these can be addressed if the issue is important enough. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Steve Comstock wrote: Why not now? It's Friday. So you can't get common basic *service* from any of your vendors? Then why not raise issues to management, spell out the problems, change vendors? Are all your vendors reluctant to provide service? What exactly is wrong? Can it be fixed? Are there issues of fraud, kickbacks, nepotism? All of these can be addressed if the issue is important enough. Good question: (All vendors will remain nameless. No offline queries please.) 1. One of the vendors decided not to continue to have a reseller in our country. Too expensive for them. When we said we will drop their product because we need absolutely 24 hours service from them (WE must deliver 24 hours service to our customers), they just shrugged their shoulders. So we dropped them ice-cold upon end of contract. That was many moons ago. 2. Some vendors are somewhat expensive. They want priced fixed on Dollars which resulted in too expensive for us in Rand. I don't blame them, it is just their overseas HQ who can't see our exchange rate dillema... Also it was many moons ago. 3. One training company (now out of service ;-D ), just couldn't always provide full training schedules and fees when we requested it for our planning. I'm not aware of any cheats, frauds, kickback, nepotism, etc. Today, all our vendors are behaving professionally and friendly without any problems at all. It is just one of my personal pet peeves... ;-D Now let us hear from YOUR pet peeves about vendors... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
During the early 90's I was with two diffiferent software companies. I saw the same leap year problem at both. It was widely reported at other companies. What was amazing was that the problem recurred in 92, 94 and 96 because of 1) bad zaps 2) zaps that were sourced wrong or not at all 3) new code with the same old errors. It got to the point, it was funny if tragic. There are no new bugs. The old ones live forever with new clothes and/or bodies. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 01/07/2010 06:55:06 PM: A variant of what some people have been calling Y2.01K? I have seen reports of systems that think that this year is 2016 instead of 2010. There was some speculation (mostly uninformed) that this might be due to confusion between binary and BCD year numbers (or year offsets). That reminds me of a problem I saw in 1990, in several programs, where leap year logic went wrong due to testing the year number for divisibility by four as if it was a binary number, when it was, in fact, BCD. The one thing that the failing programs had in common was that they were all written in the 1980s. 1980 happened to be a leap year, and the faulty logic got the right answer all the way up to 1989 (Y1.99K, if you like). That same faulty logic would again get the right answer from 2000 to2009, so what I wonder now is whether 2010 might bring deja vu all over again, for some programs written after 2000. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Elardus Engelbrecht wrote: Steve Comstock wrote: Why not now? It's Friday. So you can't get common basic *service* from any of your vendors? Then why not raise issues to management, spell out the problems, change vendors? Are all your vendors reluctant to provide service? What exactly is wrong? Can it be fixed? Are there issues of fraud, kickbacks, nepotism? All of these can be addressed if the issue is important enough. Good question: (All vendors will remain nameless. No offline queries please.) 1. One of the vendors decided not to continue to have a reseller in our country. Too expensive for them. When we said we will drop their product because we need absolutely 24 hours service from them (WE must deliver 24 hours service to our customers), they just shrugged their shoulders. So we dropped them ice-cold upon end of contract. That was many moons ago. So, no problems from them today. 2. Some vendors are somewhat expensive. They want priced fixed on Dollars which resulted in too expensive for us in Rand. I don't blame them, it is just their overseas HQ who can't see our exchange rate dillema... Also it was many moons ago. So, no problems from them today. Pricing is always an issue. Today everyone seems to be focused solely on price, ignoring issues such as quality, flexibility, appropriateness, best fit, and so on. 3. One training company (now out of service ;-D ), just couldn't always provide full training schedules and fees when we requested it for our planning. Ah, but you have alternatives. Ahem. We've been doing training since 1975, one of the longest running training vendors in the mainframe business in the world. We're happy to teach just about anywhere in the world. We've taught in Ireland, Kuwait, Denmark, Singapore, Sweden, Canada, Belgium, the Netherlands and Finland. We've done related work in Japan and England. I've even been to South Africa once (actually talking with folks in IBM and the old ASI affiliate back then). I'm not aware of any cheats, frauds, kickback, nepotism, etc. Today, all our vendors are behaving professionally and friendly without any problems at all. So, maybe, it's not as bad as you first intimated, eh? I don't see a consistent, current problem of not getting common basic *service* from your current vendors out of the discussion above. It is just one of my personal pet peeves... ;-D Now let us hear from YOUR pet peeves about vendors... ;-D Groete / Greetings Elardus Engelbrecht -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Ask about being added to our opt-in list: == == * Early announcement of new courses == == * Early announcement of new techincal papers == == * Early announcement of new promotions == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Steve Comstock wrote: So, maybe, it's not as bad as you first intimated, eh? I don't see a consistent, current problem of not getting common basic *service* from your current vendors out of the discussion above. Thanks for reminding me, I forgot to add this *current* and *consistent* service problem we're currently experiencing. I wanted to add that, but got distracted by other more urgent work... ( I must do my work, you see... ;-D ) To be fair to that vendor, things are now going fine these days fortunately, but we're monitoring this. That vendor wrote some custom application on one of our database systems. Unfortunately it was somewhat buggy resulting into outage and incompatibilities. We have some trouble to communicate to them via e-mails and to get them to fix their software. There are other problems too, but I will not discuss them here. Eventually it boils down to skills shortage and lack of commitment on their part. Most of the times I'm very happy to work with vendors, because we (and other datacentres) are the reason for their existance. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
During the early 90's I was with two diffiferent software companies. I saw the same leap year problem at both. It was widely reported at other companies. What was amazing was that the problem recurred in 92, 94 and 96 because of 1) bad zaps 2) zaps that were sourced wrong or not at all 3) new code with the same old errors. It got to the point, it was funny if tragic. I certainly saw it happen in 1992, but the problem only showed up then rather than 1990 for a different reason. In that system, incorrectly treating a non leap year as a leap year (as in 1990) did not cause any noticeable trouble, while incorrectly treating a leap year as a non leap year (1992) had very visible symptoms. From memory, that problem went a bit like this: Date of 31 December 1992 was presented to the system. One program correctly converted that to day 366 of 1992. It then passed that converted version of the date to another program, the one with the bug, only to have it rejected since according to the second program, there were only 365 days in 1992. Perhaps this bug did cause some incorrect processing in 1990, but if it did, nobody noticed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
On Fri, 8 Jan 2010 09:38:28 -0500, Kirk Talman wrote: During the early 90's I was with two diffiferent software companies. I saw the same leap year problem at both. It was widely reported at other companies. What was amazing was that the problem recurred in 92, 94 and 96 because of ... software that erroneously assumed that all years divisible by 2 are leap years? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
No, The error was only dividing the last digit of the year by 4 to determine if it was a leap year. I.e. 92 is divisible by 4 but 2 is not. Paul Gilmartin wrote: On Fri, 8 Jan 2010 09:38:28 -0500, Kirk Talman wrote: During the early 90's I was with two diffiferent software companies. I saw the same leap year problem at both. It was widely reported at other companies. What was amazing was that the problem recurred in 92, 94 and 96 because of ... software that erroneously assumed that all years divisible by 2 are leap years? -- | Jim Phoenix | Voice: (310) 338-0400 x316 | | Senior Software Developer| Fax: (310) 338-0801| | Phoenix Software International | Alt fax: (310) 337-2685| | 831 Parkview Drive North | jimphoe...@phoenixsoftware.com | | El Segundo, CA 90245 | http://www.phoenixsoftware.com | Opinions expressed by this individual are not necessarily those of the Company. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
No, The error was only dividing the last digit of the year by 4 to determine if it was a leap year. I.e. 92 is divisible by 4 but 2 is not. There must be plenty of ways of going wrong. However, the ones I recall were taking a two or four digit BCD year number, and testing if it was divisible by four as if it was a binary number. For example, in assembler, using a TM instruction to check if the low order two bits were both zero. By that method, or by actually doing a binary divide, X'1980' or X'80' is correctly determined to be a leap year. It continues to work correctly up to 1989 but since X'1990' or X'90' is divisible by four, 1990 is taken as a leap. X'1992' or X'92' is not divisible by four, ergo 1992 is not a leap year ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
A friend pointed out the following document which points out a data loss scenario for sites which have chosen an interesting serialization architecture for their systems. http://www-01.ibm.com/support/docview.wss?uid=isg3T1012005 This document describes situations where it is possible to have in-use temporary data sets deleted by DFHSM during normal space management operations. The environments exposed to this are those that for example may have tried to exclude certain SYS1 data sets from serialization for various [editorial] perverse [/editorial] reasons. Normal customers, with normal serialization environments, are not exposed. If you have an unusual or complex serialization environment, where, for example, you are trying to exclude SYS1 data sets from serialization, you are potentially exposed to the issue described by the link. This is because, last year, temporary data sets were named SYS09365 as their HLQ, but today are SYS10007 for example. If one were to have a mask of SYS1* to exclude data sets like SYS1.LINKLIB from serialization, then last year the serialization would still apply to temporary data sets, but this year would not protect temporary data sets from deletion. Of course, the linked document describes the issue in much greater detail, along with suggested solutions/workarounds. The linked document does not say what I WILL say - that it is my belief that unusual or complex serialization environments are generally ill-advised. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
Similar problem if you have TSS based security. No data loss, but many jobs abending due to no access. CA provided both a PTF, and a sample PERMIT statement to get around the problem. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Thursday, January 07, 2010 3:08 PM To: IBM-MAIN@bama.ua.edu Subject: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010 A friend pointed out the following document which points out a data loss scenario for sites which have chosen an interesting serialization architecture for their systems. http://www-01.ibm.com/support/docview.wss?uid=isg3T1012005 This document describes situations where it is possible to have in-use temporary data sets deleted by DFHSM during normal space management operations. The environments exposed to this are those that for example may have tried to exclude certain SYS1 data sets from serialization for various [editorial] perverse [/editorial] reasons. Normal customers, with normal serialization environments, are not exposed. If you have an unusual or complex serialization environment, where, for example, you are trying to exclude SYS1 data sets from serialization, you are potentially exposed to the issue described by the link. This is because, last year, temporary data sets were named SYS09365 as their HLQ, but today are SYS10007 for example. If one were to have a mask of SYS1* to exclude data sets like SYS1.LINKLIB from serialization, then last year the serialization would still apply to temporary data sets, but this year would not protect temporary data sets from deletion. Of course, the linked document describes the issue in much greater detail, along with suggested solutions/workarounds. The linked document does not say what I WILL say - that it is my belief that unusual or complex serialization environments are generally ill-advised. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
A variant of what some people have been calling Y2.01K? I have seen reports of systems that think that this year is 2016 instead of 2010. There was some speculation (mostly uninformed) that this might be due to confusion between binary and BCD year numbers (or year offsets). That reminds me of a problem I saw in 1990, in several programs, where leap year logic went wrong due to testing the year number for divisibility by four as if it was a binary number, when it was, in fact, BCD. The one thing that the failing programs had in common was that they were all written in the 1980s. 1980 happened to be a leap year, and the faulty logic got the right answer all the way up to 1989 (Y1.99K, if you like). That same faulty logic would again get the right answer from 2000 to 2009, so what I wonder now is whether 2010 might bring deja vu all over again, for some programs written after 2000. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
From: Jousma, David david.jou...@53.com To: IBM-MAIN@bama.ua.edu Sent: Thu, January 7, 2010 2:14:01 PM Subject: Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010 Similar problem if you have TSS based security. No data loss, but many jobs abending due to no access. CA provided both a PTF, and a sample PERMIT statement to get around the problem. David: We had a similar situation but different, this went back 15 years ago. We had vendor X creating permanent data sets but with temporary names. eg sys95xxx.xx etc. For all intense purposes anybody would have thought (and we did) thought these were really temporary datasets. We would find them all over the place ie pre SMS and just not on public volumes, you name it we found them there. I had to run through SMF to figure out who was creating them and ordinarily the jobname would be in those type os data sets but there was a bogus jobname in there. After looking through SMF we thought we had found the culprit but before calling the vendor up I want to make sure. I ended up running a GTF trace on SVC 99 and seeing who was really doing it. I did this as a caution as I wanted to be able to say without argument that the vendor was creating these data sets. I opened up an incident with the vendor and the next day I got a call back asking what the issue was. I gave them a detailed description and offered to send them the proof. The guy at the other end categorically denied the product did such a thing. I packaged up the printouts and sent it off about a week later I got a phone call and it was hostile to say the least. It got down to if you ever repeat this in public we will sue. I went to my boss and he shrugged it off and told me to look around for another package. It wasn't easy but I did find one and when the product came up for renewal we dropped it. The salesman called me and very nastily said we will sue. I said go ahead and here is our lawyers name phone number. I have no idea if the vendor is around anymore and I could care less. The vendors lying and threatening was all posture and trying to make us the customer back down. Needless to say we stayed away from that vendors software from then on. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
On Thu, 2010-01-07 at 17:55 -0600, Andy Wood wrote: A variant of what some people have been calling Y2.01K? I have seen reports of systems that think that this year is 2016 instead of 2010. Like this you mean ???. http://www.theaustralian.com.au/australian-it/eftpos-glitch-not-y2k-bug/story-e6frgakx-1225816534313 Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
A variant of what some people have been calling Y2.01K? I have seen reports of systems that think that this year is 2016 instead of 2010. Like this you mean ???. http://www.theaustralian.com.au/australian-it/eftpos-glitch-not-y2k- bug/story-e6frgakx-1225816534313 Haven't found an English language link, but the EMV chip on new cards is apparently responsible for a quarter of all German card holders being unable to 'identify themselves' to banking terminals. Since January 1st, 2010. It is being blamed on a 'third party programming error' in the chip. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: Possible Data Loss for Temporary Data Sets starting 2010
. . . A variant of what some people have been calling Y2.01K? I have seen reports of systems that think that this year is 2016 instead of 2010. Like this you mean ???. http://www.theaustralian.com.au/australian-it/eftpos-glitch-not-y2k- bug/story-e6frgakx-1225816534313 The BoQ one was the first I saw. That quacks like a Y2K-type problem despite a claim to the contrary. Then I saw the one involving German bank cards, but there are some others like one for SMS messages on Windows Mobile - I think that was where I saw some talk about possible BCD confusion. At this time, if you simply Google Y2.01K you will get a lot of hits. I haven't seen any suggestion that any mainframe software is involved, but it certainly jogged my memory of Y1.99K problems that I encountered. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
