TechTalks Transcript
Y2K Issues and Strategies
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Dave Kohler [DK] |
March 11, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for Spring of 1999 and to this session on Y2K issues and strategies. You are here because it's time to discuss the core technologies in your future.
This is Judith Boettcher, your CREN host for today, and I'm pleased to welcome the technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known Web and all-around Information Technology expert.
Welcome again, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of technology Webcasts. The job of the technology anchor is to engage our guest expert in a lively technical dialogue that will answer the questions you'd like answered and to ask those very important follow-up questions. You can ask our guest expert, Dave Kohler, your own questions by sending e-mail to expert@cren.net anytime during this Webcast. If we don't get to your question during the Webcast, we'll provide an answer in the Webcast archive.
Not since the conversion from Roman numerals to Arabic numerals has anything to do with numbers perplexed us as much as the Y2K (or Year 2000) problem. Even the switch from BC dates to AD dates, though a much more difficult change, seems to have been done without dire warnings about the failure of the air traffic control system, long outages of electricity and ATMs unable to deliver money. Certainly, the fact that back then there were no airplanes, electric generators, ATMs or even computers kept the things that could go wrong to a minimum. And there were of course no newspapers, radios, CNN and the Web to warn us about the horrible things that would surely happen.
Today, there are about a million Web pages that refer to the Y2K problem. Over 1,000 of them refer to the U2K crisis. One of them says, "On January 1, 2000, millions of computers all over the world will freeze up and stop functioning." But this is not the most dire warning. Nor are all or even most of the Websites full of warnings. A few, such as www.storablefoods.com, which is trying to sell their food storage systems, are commercial attempts to make money off this problem. Most sites, however, contain useful, reasoned plans and discussions of what needs to be done to face the Y2K problem.
As you surely know, the Y2K problem was caused by programmers using two digits for the year -- for example, '62 instead of 1962 -- to save the cost of what was, in the '60s, very expensive memory. The cost of fixing this problem in the US alone is estimated to be about $500,000,000,000 and to take about 9,000,000 person months. How could saving two bytes cost half a trillion dollars to fix? Obviously, you will be paying for some part of this, both directly at your college or university, and indirectly in the added cost to everything you buy -- not to mention the extra $60,000,000,000 of your money that the federal government is expected to spend to fix this problem.
Are all your systems and all the world's systems ready? The Senate Special Committee on the U2K Technology Problem doesn't think so. What steps do you need to take to make sure that you'll have all the bases covered, and what are the downsides of you or others not getting the problem solved in time? Will there be widespread chaos? (Check out www.y2kchaos.com.) Or will there be business as usual? Are we heading for a real crisis or, as Franklin Delano Roosevelt said, do we have nothing to fear but fear itself?
There are right now only 295 days, seven hours, 56 minutes and 50 seconds remaining until January 1, 2000. But we've pulled our guest expert, Dave Kohler, away from the front lines of doing battle with Princeton University's Y2K problem. He's here today to try to help us answer these questions and many others on today's Webcast of TechTalk.
Judith?
JB: Thank you very much, Howard, and out of those one million Websites that you mentioned, I'd like to remind our listeners that some of David's favorite sites are in fact listed up on the Website so they can take just a tiny peek into what's all out there in the world of Y2K.
Let me now introduce our expert for today, Dave Kohler. Dave is the Director of Distributed Management Systems at Princeton University. Dave has been in that position since 1995, and in this role, he is responsible for the migration of the University's central administration systems to a distributed computing environment. Dave's career in Information Systems began in 1973, and he has worked for both corporations and higher education. And before his current assignment at Princeton, he also held similar positions at Cornell University and Stanford.
Welcome, Dave, and thanks for being here on TechTalk and for talking to us about Y2K issues and strategies.
DK: Thanks, Judith, and thank you, Howard. And I guess once again, Howard has summarized the issue so well that I'm not sure that there's going to be anything left to discuss!
HS: Oh, but Dave, I'm going to ask you immediately to do that.
DK: All right.
HS: I gave my summary of what I thought the Y2K problem was. I wonder if you could tell us what your view is. I mean, you're not going to just say, "Yep, you've got it"?
DK: Well, I guess that -- you know, it's very interesting, watching and looking at all the experts you have on the different topic areas, and here I'm an expert on a problem that by definition goes away within the next nine or ten months! But it's clearly -- as you mentioned, it was the way the programmers took care of their year dates for years and years back in the '60s. I guess we started this because the cost of computing and the cost of storage was so high. I think it was about $36 a megabyte back then, and now it's just (as you said) about five cents. And so we had to be very careful with resources.
If you actually look back at the way IBM operating systems handled things at the time, it was very difficult to get four-digit years, even if you were doing a program at the time. And of course, many programs were keyed off of the date and time for doing their function. So we basically built this bomb into a system that now is about to go off -- and we have now nothing to thank but ourselves to actually fix this now.
HS: You said that the IBM operating systems have the problem kind of built into them. Weren't they aware, even in the '60s, that that was going to be a problem?
DK: Well, you know, one would think. I think that as a person who actually programmed way back then, I think that we all believed that anything we were writing in those times would be replaced two, three or four times before we got to the Year 2000. I think that the IBM operating systems were built on efficiency models as well. And we actually, at Princeton, got our upgraded IBM operating system model for Year 2000 compliance in about 1997.
HS: Just two years ago.
DK: Just two years ago, that's correct.
HS: Wow!
JB: In terms of everyone solving the problem, Dave, when we were getting ready for the talk today, you mentioned two particular strategies that most systems are using to solve the problem. Did you want to just summarize those two real quickly?
DK: Well, there's several different approaches you can take if you actually have access to what we call the source code -- the programming languages that we've been using. The first (which is certainly the one that everybody would like to see because it lasts for all time) is to actually update all the data files with the actual two digit dates, so anything you have in your archives -- anything you're using today -- will expand from two-character years to four-character years. Now that happens to be quite an undertaking because then you also have to convert all of your data files -- and you have to convert all your programs, file sizes, those kind of things -- to read that.
The other one (that's more of a patch, I guess you could say -- the one that's going to get us through perhaps the next 30 or 40 years) is to actually use a windowing technique. That's to anchor or use a pivot date -- let's say 1950 -- to decide that any date that you read in the program that is above 50, you would presume that the first two-digit would be 19 and anything 50 or below, you would have appended 20 to the front to make it 2000, for instance. So that's a way to patch it for a time, and of course, that means we have to do something to it the next 40 years, but at least we get a pass without so much work and we don't have to work on the data itself.
HS: That would kind of mean -- I mean, you could keep changing that pivot point.
DK: That's exactly right.
HS: You could avoid the problem forever by just continuing to make that change.
DK: That's correct. You could actually do it again later, depending on -- and actually, you actually choose a pivot point sometimes based upon the application itself, whether it's more apt to be doing ages of alumni vs. something that's happening right now in Accounts Receivable, for instance. So you can certainly continue to do that again, if you wanted. (You know, whether we want to bring COBOL programmers out of retirement in the year 2050 or not is up to somebody else to decide. Fortunately, I will not have to worry about that.)
HS: We seem to have made this mistake in terms of the longevity of programs back in the '60s.
DK: That's correct.
HS: Do you think that the programs we're building today, are they going to be around 40 years from now?
DK: Well, you know, there's all these things that are rolling over, if you will --I mean, we've talked about how UNIX clocks in 2036, I guess, will roll over, the GPSs that will roll over in August of this year, even (as we mentioned) Windows 98 has now been reported as having some Year 2000 problems. So it's not something that we automatically test for all the time, although it should be much more in our awareness cycle right now. But it's possible that there are other things we're doing where we're not accounting for those kinds of things.
HS: Dave, I think this brings up the issue, and we've actually got a couple people already sending us notes about this issue, and that is, when we say something is Y2K compliant, what do we really mean by that?
DK: Well, I guess what I mean by that is the program that's actually performing some function for you will continue to function exactly as it had when we hit January 1 of 2000. It's not the actual millennium as we know it, but it will do exactly what it's purported to do after we hit the Year 2000. So if you're doing an amortization schedule, if you're doing a billing, if you're doing calculation of ages -- whatever it is, it has to function correctly, not only in 1999 but in the Year 2000 and beyond as well.
HS: You said "in the Year 2000 and beyond." I've talked to lots of folks who seem to just check to see if the Year 2000 works and don't seem to check beyond. I assume that's a bad strategy.
DK: Well, it's certainly the first strategy. But you know, we've actually had Year 2000 problems in our applications even before this because we had to admit classes of 00 and 01, etc., already. So we've had other programs that we've actually had to fix in advance of this. But of course, this is when all the operating environments will also face the Year 2000 problem. But we've actually tested now with January 1, we've tested leap year of 2000, we've tried some specific dates beyond that, but it's certainly worth testing a couple different dates just to make sure that you have all the code. And you know, Year 2000 remediation is mostly a testing kind of thing because of not only unit testing but integrated testing as well.
HS: Talk a little bit more about integrated testing.
DK: Well, you know, we talk about our systems here, you know, and you could have one program that would malfunction and it might not even show up until way downstream. I mean, we're hoping when -- if a program does malfunction, the best thing that could happen is it stops running. The worst thing that can happen, of course, is it continues to run and then produces erroneous results.
And oftentimes, we have systems that pass data from one system record to the next, and it may be a system third-down-the-line that actually will now really be affected by that data, where somebody else in the middle might not be noticing the date. So that's why we have to do both unit testing, meaning not programs specifically but all the flow that's in there has to be tested as well.
JB: Have you been doing some of this testing already at Princeton, did you mention, Dave?
DK: Yes, we have. We have about 18 systems that we're doing our Y2K remediation effort on. And so far, we have now finished all of our mainframe systems in terms of the coding, unit testing and integrated testing on all these on the mainframe environment. And now we're running them currently right now in a Year 2000 emulated environment, where the clock is set ahead. We're setting it to specific dates and so we're going through our test streams again, presuming we're in the Year 2000 or beyond.
JB: Wow! What kinds of things have you discovered or have come to light with this type of integrated testing?
DK: Again, it's the same kind of thing where, just because one set of programs seems to be working okay, you really have to see if everything in the whole stream works.
And when we find problems downstream, we have to go back up to the source and fix them, so the one advantage to us of having done this is that we have some very good test streams now that we never had before. We had to build those as a base because we used an outside consultant to help us with some of the code changes. So we had to actually have our test base first, before we gave them the code, so that when they were finished, they could say, "Now the same test system works with all the code that's been changed."
JB: Okay. So these test streams actually give you a solid base, then, to adding in additional systems as needed to test to see whether it's working or not?
DK: Well, we certainly hope so. Fortunately, our customers have been heavily involved in testing sort of all the things they've learned over the years that have created problems with dates -- and they put those into the streams as much as possible.
You know, we may miss one or two things, but we certainly have it so that the systems will, indeed, work, and we'll be testing again probably the weekend of January 1 and 2 again. You know, thank goodness it's a weekend, right?
JB: Dave, for somebody who's not in the middle and hasn't been doing all this testing, have you identified some likely weak spots that people might want to look for in these -- I mean, between the mainframes and the workstations and the PC desktop levels?
DK: Well, that's a broad question. I guess that, depending on where people are --
JB: You want to narrow it down?
DK: Yeah, let's start with mainframe applications first and then we'll talk about some of the other problems that are related to PC and desktops.
JB: Okay.
DK: I think that in the mainframe area, I think if people were just starting right now (and knowing what we now know about what all the layers of the system that we have to take a look at, you know), I think the most important thing is to look at these systems and prioritize them either by business criticality or career criticality.
HS: What do you mean by career criticality?
DK: Well, you know, I'm going to make sure that January 1, our payroll system is running.
JB: Is that saving your career?
HS: (Inaudible).
DK: Well, it would be career limiting, for instance, for me to have some things running and not payroll.
HS: Right. Maybe life limited as well.
DK: Yes. That's right. You know, I think it really is just to make sure, out of all of them, which ones have to be done and ready and which ones could be done through some kind of backup plan or manual effort or something. Try to do some triage on these things first just to see which ones are going to be most susceptible.
There are tools to go through and see which ones have the most number of lines of code that have any dates in them, for instance. You know, for instance, the Princeton Portfolio mainframe apps had about 3,000,000 lines of program code and about four percent had a date somewhere in them.
HS: So obviously, you had to look at all 3,000,000 lines of code.
DK: That's correct. I mean, we had to go through everything and find those, and then we only looked at the lines that had a date-specific. And we actually didn't have to do much with ones where it was just date being put on a title because we don't care as much about the cosmetics of it.
But anyplace that had any kind of algorithmic work with the date, we had to take a look at and figure out what it was doing and then use the windowing technique or the expansion technique.
HS: Dave, when the software was your own, obviously, you can go in and rewrite it yourself or your group rewrites it. You can go in and you can fiddle with the thing. But a lot of the software that you use was not written by you -- it's written by IBM or Microsoft or somebody else. How do you deal with all the vendors being Y2K compliant? I mean, how do you know that they are?
DK: Well, I guess that's -- there's several sets of vendors you want to be thinking about, too. Not only the IT vendors, but also just vendors of any kinds of goods and services to your campus.
But the IT vendors have all been putting up their own Websites about where their products stand, what they plan to do. Often you'll find patches, for instance, if it's a desktop kind of thing, that you can actually download and try, you know. And you have to set the clock ahead and give it a try before you really are sure that it's working. But it's really something where you have to rely on them to get that product done because we get object code only, and then you have to look and try it.
But I would suggest that anybody who has anything from a vendor, to try it. You know, you really have to start saying, "Now let's process a transaction as if it was the year 200 and beyond" and see what happens, because I think without that, you're never assured that they really have done it.
HS: When you talk about kind of just checking the clock, we have a question in from Karen Vanderly, and she asks an interesting question. She says, "When you go into the control panel and check time and date and it goes past the Year 2000, does that mean your computer is Y2K ready?"
DK: Well, it certainly means that it understands that it's the Year 2000. Now, that doesn't mean the applications are Year 2000 compliant. The PC areas -- I mean, the Macintosh has for a long time talked about the fact it's Year 2000 compliant, and there have been some Websites that say, "Well, except for maybe these minor nuances." But they believe that it's all set up for Year 2000.
The older PC's have a BIOS problem (input/output system), and you can download fixes for that for free from the various vendors' Websites. So you can pretty much get to the point where your PC will work after the Year 2000 and come up and the date and time will work.
The question is, will your applications that you want to use recognize that and actually use them effectively? Or if you've written your own spreadsheets, if you've written your own documents that are actually using the date and time. I've done some amortization schedules in Excel that I know won't work beyond the Year 2000 because I have not put the right kinds of traps in for that.
HS: I imagine there's lots of cases where people are using things like Excel or other spreadsheet programs where they're pulling down university data and then fiddling with it. I mean, to them, it looks like a university system even though they're using desktop software.
DK: That's correct. And it's very likely because if it's still pulling down two-digit years, if there's any computations done in Excel based upon that -- in other words, if you have a birthdate and today's date and you want to calculate somebody's age, they'll go from 50 to minus 50 overnight.
And so the question is, what happens then? How does it sort, how does it report? So anytime you're doing any kind of internal calculations that are looking at a date, I think that people have to take a look at those things.
HS: What about hardware, Dave? We've been talking a lot about software. Are there problems with the hardware that are Y2K related?
DK: Well, I think you're talking probably getting us into the embedded chip area?
HS: Well, I wondered about things like modems or you know, the insides of CPU's, but yeah, embedded chips as well. But what about the other stuff? Do I have to throw away my modem because it's going to be Y2K incompatible?
DK: You know, I'd say it's unlikely. I mean, I guess, we try to forecast when we talk about embedded chips and what we have in there. I mean, some of them have clocks in them. We have to forecast what the operation would be if we now are looking at the chips. You know, the biggest problem that people are talking about embedded chips is nobody can (as you know) look at the code. I mean, it's in the firmware -- it's out there in operations somewhere.
HS: Right, except for the people who built the thing.
DK: Right, and even then, we don't know exactly where they are and what's happened to the code that they used at one time because it's generated kind of code. So that's the one that becomes more interesting in terms of forecasting because at least I can look at mine and I know what I'm going to have to work on. But with embedded chips, we don't know whether someone's put in some nice little traps in there to look at today's time and compare it with last time we looked -- and if it's not a positive number, you know, then there's something else wrong and it shuts the thing down.
So you know, I'm not going to panic and say all these embedded chips are going to break. I just don't think that many of them would have ever needed to look at the clock, for instance. But we talked about maybe 6,000,000,000 of them out in the world, you know. If just a few of them don't work, we know we have to do some remediation. There's going to be things that won't --
HS: Where do we find these things? I'm wandering around the university -- where am I going to bump into these embedded chips in a way that's going to affect me?
DK: Well, I mean, you know, people have talked about elevators as a problem. You know, they've talked about electricity -- any kind of utilities. I've read things about whether the water pumping stations that sense pressure changes and they're looking at -- these are still real-time things, and so the possibilities of them shutting down are there (I mean, in terms of those kinds of things shutting down). So anything that are in those things, any experiments that are going on campus that have real-time systems associated with them could have some problems.
I think that one of the areas that Princeton doesn't have to deal with as much as other campuses are in the hospital and med school areas, where you have an awful lot more lifesaving equipment and life-tending equipment, if you will, that has to be checked. And I know I've seen some Websites and information on those where the vendors themselves are saying, "This is compliant, this is not compliant."
But of course, people get very nervous in the vendor community now and don't even respond sometimes to your inquiries any more because of fear of litigation.
HS: Talk to me about litigation. If a university does not get all its systems Y2K compliant, what kind of legal problems could they be facing?
DK: Well, you know, we're forecasting a lot of things that may happen or could happen -- but you know, we have the responsibility to house people and feed them. And so we get many of the things on this campus from outside vendors, whether it be food, whether we're buying electricity, whether we're bringing in water. All those things have to be in place and functioning to house individuals.
And of course, it is wintertime in the northeast, and of course all those things are a concern of people. Many campuses I've seen are now delaying the start of their semester just to make sure that everything -- I guess there's two reasons. One is they have a little bit longer to check out all their systems, but number two is they're concerned more about travel. And some foreign students have already said that they were not going to be traveling over that particular period of time. So they wanted to put off the beginning of the semester if they were going to start January 3.
JB: So when are schools planning on starting with the folks that you've talked to then, Dave? I mean, is the sixth or seventh or tenth?
DK: Some are a week, some are just several days, depending on which ones have more time to do. And I've seen a couple different ones that have mentioned that -- and there's actually a lot more talk on the university Websites and things like that about what they're planning to do. So more people are talking about it. Princeton starts even later than that, so we're on break -- so we don't have as much of a problem in terms of pushing it back.
JB: So when are the students coming back to the Princeton campus, for example, then?
DK: I'm not sure of the exact date of that year, but it's usually in the teens somewhere.
HS: Yeah, they never come back anyway around the turn of the year.
DK: They come back for exams first, and then there's an intersession week, and then they're off, so it's not -- you know, we don't start right up on January 3.
HS: But if -- I mean, is this idea that there might be outages of electricity or telephone service or water or security systems? I mean, if that's a real possibility, how could universities plan for something like that? Like having no electricity or telephone service?
DK: Well, you know, I guess I have to say it's a possibility, and I guess even the Congress report last week indicated that people should (this is now sort of on the personal issues, I mean) be careful about making sure you're ready for that and plan as if it's a blizzard. And I've said for a long time, we have to plan as if this is a blizzard hitting us.
HS: I can hear the schools in the south saying, "How do you plan for a blizzard?"
JB: Well, they plan for hurricanes. I can speak for that!
DK: Right, we do a change to hurricane and that's exactly (inaudible).
HS: So for you folks in the south, Dave meant hurricane.
JB: That's right. You get a lot of candles and you get a lot of water.
DK: That's right. And that's what people are -- you know, even the Congress has said that's probably a reasonable thing to do. And expect spot outages. But you know, the power grids are such that there's a lot of flow between them -- and I think that's where the concern has been all along on whether we'll have outages in services (or any kind of thing like that) is that the interconnectedness of many of the things we do in terms of just-in-time deliveries can affect in strange ways. I mean, you know, shut down a car line. Could be a vendor that's way far removed from the production process that's not producing the parts that they need, so it is a possibility.
Now, the question is, what do you do about that? I mean, I think that every university (and I know that we've been talking about it here) should have a set of contingency plans depending on how minor or severe this might be. I think that you have to prepare for that, and that's really a business issue. That's an issue that says, "What will we do if we're out of power and water for a week? What's our game plan? How will we notify people?" I think there's a lot of institutions that are starting to put these into place right now just because no one really knows for sure.
JB: And from what you said earlier, at least universities might have the option to tell students not to come back for a few more days, right?
DK: That's correct. Many are doing exactly that. I've even seen some airlines that say they don't plan to fly that first week. You know, so that's an --
JB: So that fools the folks that fly on January 8, then, after they think it's all been fully tested, right?
DK: Well, I think that the biggest concern is the ground control -- the air control system, traffic control system. It's not the planes themselves. They believe they're going to fly fine. But they're not sure they're going to have traffic control up to speed. And there's a big Website on the government testing all its own systems, and the FAA has not been proven that that's going to work just yet.
JB: But before we get too far afield, we did have a question come in from Jill Hope from New York University, and she asks a question that relates back to the testing that you were talking about before, Dave. She was asking, are there any precautions that you would recommend that one take when testing and preparing for these kinds of tests?
DK: Well, I guess I would certainly err on the side of more testing than less. We have found that -- you know, if you're looking at the whole system, many people have mentioned that 45% of the whole project is testing. (much more than I would have expected going into it, you know). It's, you change the date and you run it once and that's fine. But you really want to have a very good test plan that tests the many facets of the application, so I would say to err on the side of doing more than you actually think is necessary and putting as many different scenarios in place -- both in your base testing and your future testing. That's good for the long term as well.
JB: Jill didn't mention backup or anything, but maybe that's part of what she was thinking about, too, is how do you -- when you test your systems, how do you make certain that you don't do anything to them so that you can't go back?
DK: Ah! The first rule is "Do no harm," you mean. Yeah, that's correct.
What we've done in our environment is set up a separate -- several separate environments on our mainframe and put some pretty good walls between our current production systems and these new test environments, and we've copied some programs and data over. We've done a lot of work in tests. We have another production lookalike version that we run things, but we don't touch anything in the other systems at all. I mean, we just can't -- we don't have write-access from one to the other one. So we really do want to prevent that because we actually would do damage. It turns out that one of the problems with the old system is the VCM catalog, which if we from the new environment tried to write to it, it would really mess it up.
So it's very important to separate your testing. And if you're doing sort of a PC version of testing, I would actually try to get another machine to do it on.
HS: (inaudible) Dave, that you're doing a lot of regression testing. I mean, I think anybody's experience doing programming is that if you make a change to any part of the program, that you have the possibility -- in fact, the probability -- of adding new bugs that are unrelated to the problem you were going out to solve.
DK: Again, I guess that now your test plan is to make sure that it works -- not only just for this, but for any upgrades. I mean, we have to do technology upgrades often, and so having a very extensive test plan that you can run or you can run on behalf of your customers, I think, is the right thing to do. And as much as you can get into it -- and whether you're doing regression testing or just looking at a bunch of different scenarios, at least you have an idea of what you're trying to test for.
JB: Dave, it sounds like you have really been -- you are really close to being ready for the millennium. What about the universities, perhaps, who feel as if they're kind of behind and that they haven't gotten such a good start on it? Do you have any advice, if they are kind of coming from behind, what they ought to be focusing on right now?
DK: Well, I guess in some respects it's that triage that we talked about, because if you're starting right now, there's a very good chance you won't have the ability to really do it well. I mean, we've been at this for two years, and it took us almost a year to really get set up for it because you have to start from the bottom. We had to get another mainframe to get additional capacity, we had to put in all the new operating system and get the mods in so they worked with our environment and then started work on the applications. So it does take awhile to get all the layers of the onion in place.
So again, I would make sure that, number one, the most important, the mission-critical systems are done first. And I would also have all my contingency plans in place, saying that, "Gee, you know, we might not get this all done. If that's the case, what should be do?" In other words, this office can do it manually, we have another way to do some of the business we're talking about. You know, Princeton should be good at this because this is our third rollover to a new millennium coming up.
HS: A third?
JB: A third? Oh, my goodness.
DK: We did it in 1800 and we did it in 1900. Now we're doing it in the Year 2000.
HS: Oh, at Princeton! Right. Of course, when we rolled over to 1800, we didn't have the systems we have now.
JB: Yeah, I wonder how many students were there? Dave, do you know that?
DK: I guess I don't know the number. It probably was one building, I think, at the time.
HS: Dave, we have a question from Dick Atlee of University of Maryland (actually, this question came in before the broadcast). But Dick is talking about the role of universities, and what he says is, "Given the traditional role of universities as educational institutions, is there a role for them in raising to the level of active civic discourse in their communities the problems and issues of Y2K affecting the viability of local communities in order to insure that these issues are addressed adequately by local governments?"
JB: That's a big question, isn't it?
DK: That's a real (inaudible) question. It's a tough question because, you know, there are two sides to this that you can get involved in.
And I'll tell you what we've done, what I've done personally. We have consulted both with our borough and our township, because it's been reported that state and local governments are behind in terms of where they should be. We've consulted with them in that we've spent hours with them saying what we're doing, you know, not necessarily what they should do, but what we've found -- the kinds of things we're doing, what we think about the vendors. Very similar to the conversation we're having here today. We sat down with the mayor and the township officials, so they have a different environment, of course. They don't have a big mainframe. They have a lot of Local Area Network kind of things. And they plan to now do some things with upgrading their own desktop machines and doing their own testing.
So we're trying to be -- this is the town and gown thing. We're trying to be very much supportive and help them. We don't want to cross the line to do things, you know, because we don't want to take ownership of some of the things that's there. And so I think that, if we can help them with any kind of intellectual knowledge that we have so far and the kinds of things we've found and pointers to Websites. We gave them a nice manual we got from the Department of Energy that we found on the Web -- or Department of Education, excuse me. It shows what other people are doing, good templates, where you would start. There's a lot of sort of how-to's you can find on the Web and they weren't aware of those things as well. So we try to help them along as best we can.
Personally, I've met with the community where I live and asked them about where in the spectrum they want to be. Do they want to be -- first of all, are they going to have their systems up and running (which they believe they will), to all the way over to are they going to provide, you know, a backup facility for people for food and shelter and things like that, should anything happen to the community? And that's something they have to decide for themselves. And do they have the resources to do that thing, and should they be more involved in awareness for the whole community? So it becomes much more of their own decision, where they want to play in that spectrum.
But I think that the best thing to do is to be information providers, you know, build as much awareness. I think try to prevent what I think is going to be the inevitable panic mode that's going to happen -- that the media will induce. And I think that's important for people to be as aware as they possibly can be about everything that's going on so they don't overreact to these things.
HS: You were doing some things personally with the township, but I wonder if there's some role that educational institutions at a higher level ought to be playing to try to get people not to do the silly things that they're going to do, which I believe are going to cause a lot of the problems. I mean, if everybody goes out and takes money out of ATM's, there obviously won't be enough there for everybody to have some, and if everybody runs to the stores and buys up bottled water, we'll obviously run out. We'll run out of anything that people go out and buy in large quantities.
DK: That's right. And I guess part of that's going to happen anyway. The government has already, I guess, printed a lot more money just to prepare for that inevitability.
If I knew, for instance, exactly what was going to happen, then I could be a voice of reason. Since I don't know -- since I don't have a good sense of exactly what's going to happen, it might be nothing happens to something really does happen. If we don't make that right call, you know, we might offer the wrong kind of advice.
So I think that some of the stuff is really your own personal view of what's going on. I mean, for instance, I don't think there's any reason to take lots of money out of the bank because what good is money if there's no goods and services? I think there's a lot of things you wouldn't even think about doing. I don't plan to go to the bank and get a lot of money out.
HS: But a lot of people would suggest that the reason to take money out (assuming there is something you could buy with it) is that the communications systems that are used to process credit cards won't work and therefore your credit cards -- I mean, normally, I don't carry much cash with me because I carry my credit card with me. Who needs cash? But if I knew my credit card wasn't going to work, I might feel differently about cash.
DK: I think that's why we have to keep up to date. This month is the big Wall Street financial community tests -- big integrated tests that are going on for the EFT funds and things like that. And I'm not going to worry too much. If they come back clean, I'm not going to worry about the banking.
And sure, I think that somebody recommended having an extra two weeks of cash on hand that you might not have already had for some goods and services. But I don't think that going and taking all of your money out of the bank and putting it under your pillow is necessarily a good thing, either.
HS: Obviously. Even if people take two weeks of cash out of their ATMs,if they're normally carrying, say, one week of cash, that extra week of cash over the quarter of a billion people living in the United States is a huge amount of money.
DK: You're absolutely right.
HS: There's no way the ATMs can deliver that.
JB: It sounds like what you were saying, Dave, is that the financial systems are doing all this preliminary testing as well so that we may, in fact, know ahead of time whether there's likely to be a problem?
DK: I think that we will know much more and the financial community will know much more about it shortly. I mean, because we have to get that done.
But Howard is also right. We're going to have enough doom-and-gloom scenarios that are going to be on the nightly news that people will still go and do this. And the government is preparing for this. But again, I think in our own circles of people we can be the voice of calm, because I don't think that's a necessary kind of thing.
JB: We did have another question come in, Dave, that takes us back to when we were talking about some embedded systems. We've been talking about, you know, financial systems and other admin systems, and Paul Primrose has a question regarding whether there's anything that Princeton is doing to, and I'll quote from him here, "remediate the large amount of embedded systems related to university research."
DK: Well, I'll tell you, you're getting beyond my realm of expertise. We have, at Princeton -- our EDP audit function is the one that's been working with all the departments in terms of awareness, in terms of getting feedback. And we have some directives from NSF and those kind of things that are going out to each of the departments.
So I can't give you a definitive response on what exactly has been happening in sort of the real-time experiment areas. Certainly, we know a lot more about the PC areas -- we know what's needed to be done. We have some checklists for people and some tools that people can use, but when you get down to the real-time experiments or embedded chips, I can't tell you. I don't even know exactly how you would go about testing all those things.
JB: Paul, did you want to mention on the Websites --
HS: Dave.
JB: I'm sorry, that was Paul's question. Right. Dave, on your favorite Y2K sites, are there a couple that are focused on some of these areas with toolkits and all that might be helpful to folks?
DK: Well, again, the first one I look to all the time is the one I mentioned, which is year2000.com. There's another one I found recently. It's y2ktoday.com, which has updates every day from different media sources -- how the financial people are doing, how's health care doing, how's the government doing?
And each of those has lots of different pointers to get you to areas where there are vendors who will sell you something -- services, sell you tools, offer freeware, etc. And I think you also mentioned the Educause site for Y2K, and many of the universities that you can go to there will also post some of these links to free tools and you can download them.
HS: Also for our listeners, if you have a search engine that you prefer, go off and search on some of the Y2K related issues and you'll discover that there are millions of sites out there. You may be able to find many that we're unable to suggest here.
DK: Right. There's an awful lot of how-to's and where-to-start and those kind of things. But there's also, as Howard has also said, there's some crisis sites that you can find that'll make your head spin. So I'd stay away from those right now.
HS: Yeah, but again, there's plenty of sites your search engines will turn up that are quite reasoned. And if you have some specific problem, you'll probably discover that somebody out there has already been through the problem and has created a Website that discusses the thing.
DK: That's absolutely right. I think that this is one time when the Web has been very, very helpful -- for me, anyway, because I'm able to find how people have done things and what tools are available, what vendors. Oftentimes vendors will give you sort of a checklist about how they would go about doing things, so it gets you at least into the game, so to speak.
HS: Dave, back in the '60s, we did this silly thing: We saved two bytes because bytes were very expensive back then. Is there anything like that that we're doing right now that's equally silly -- that's going to get us into trouble in the near future or far future?
DK: Again, we have to look at everything that rolls. But in some respects, anytime we're using a proprietary toolset for some of the work we're doing, we are painting ourselves into a corner. I mean, not that there is a silver bullet out there -- that everything's going to be open and standard (even though we're trying to move in that direction). But anytime we use something that's proprietary as an application development tool or an environment, etc., we by and large know that that has a limited lifespan.
HS: So all the people who are using PeopleSoft, for example.
DK: Well, I would say that any application vendor in the past has been known to be replaced someday by something else. So it's not that that's the wrong thing to do, because, you know, it depends on what your business needs and what are the benefits of that thing now.
But if people said, "Gee, our decisions don't last, don't stand the test of time," that's true. I mean, we have to presume, I think, that we are going to start replacing these things with maybe a greater frequency than we did before to avoid this. I mean, we never expected our old 1960s vintage systems were still in production use for something. We expected they would be replaced.
HS: Well, in fact, though, ones that you've made U2K compliant are going to continue to be used, aren't they?
DK: They are for us, until the year 2002.
JB: Well, we're getting close to the end of our session. We've got a question that's coming in, and interestingly enough, he is already in the Year 2000 because he has his machine set to March 11 in the Year 2000. But he has a question regarding just how we go about testing at the PC level, Dave. And he was asking for any help -- perhaps on a software package -- that you could recommend that would aid IT departments with this kind of testing at the PC level.
DK: Again, there are several, and I can't recommend them because we have now Year 2000 compliant desktop machineries in all of our administrative organizations. We upgraded them all last year. It wasn't the main purpose of it, but while we were doing things to move, we decided to replace many of our systems as well as remediate, so we are doing PeopleSoft. We are moving some systems off the mainframe, etc., so we wanted our desktops upgraded. So there have been tools that we've tried downloading from vendors on the Website. So I'm not going to recommend one because I haven't tried one myself. I'd rather have tried it to recommend it.
But the sites have different freeware tools to use, and I think it's a matter of just looking at and trying them out. If you're already running and somebody's already running their clock on March 11 of the Year 2000, their machine works. So their job is now just to make sure all their applications work. And I would say, if they're working fine right now, there's not going to be an issue because he's already ahead of the game.
JB: Well, this person is -- I'm sorry, I don't know that I mentioned his name. He's Sean Magnuson and he's a computer specialist, so he obviously has responsibility for more than one machine -- so what he was looking for was some tools to help him solve these problems.
DK: There's some that can do -- and I would check out some of the university Websites first. That's where I've found them before and referred them to our EDP auditor. Where they said, "Here's the freeware that we've used to do the following things." So this is one where I don't think one expert here is enough. I think an awful lot of people have done this.
I was just at an Ohio State Website today and they have a nice issue about what their compliance statements are and what they're doing to remediate, etc. And then they have other pointers, so there's an awful lot of them through that Educause Website that you can look at to find the tools that they recommend and have used. I think that's the key, because you can go out and look at all the tools, but another university recommending them for people to use, I think, is the best thing to do.
JB: Okay, that sounds good. We're getting -- in fact, I think we're just about close to closing up here. Howard, do you have a final question?
HS: Yeah, I do. Dave, I noticed we are, in fact, 46 minutes closer now to --
DK: Thank you, Howard!
JB: And we did the 50 seconds, too, right?
HS: Yeah, I could give you the seconds here because I have this crisis counter on my screen right now. But I wondered, Dave, on 1/1/2000, when I'm off partying or whatever I'm going to be doing then, assuming that parties still work --
DK: First weekend here, and our second weekend here for the majority of the people will be the January 1 weekend, and we expect to be in that Saturday to try everything. It turns out Princeton has a Cogent facility, so we expect we'll have electricity here, too.
HS: If their embedded chips work.
DK: That's right. So we'll have people in here that weekend, you know, to test all the systems just to make sure before everything has to come back up on Monday.
So we have our scenarios, we can run through them very quickly. We've done it now multiple different times, so we're actually getting pretty good at this. But we'll have one more test for ourselves to say, "Now that we've actually flipped, even though we've emulated before, we never have been here before." And so we're going to run it again and bring people in and that'll be their fun for the New Year's.
And I guess that having people not travel on the 31st or something is probably a good thing for me to recommend as well.
JB: Okay, we've got one other question that came in from one of our listeners, Dave, and I think maybe we'll just go ahead and take it since it's a pretty critical one. And that is from Nancy Wooters at Duke asking how successful has Princeton been at engaging senior management in the identification of critical areas and then the development of contingency plans for those areas?
DK: The first part of it is, I think we've been very successful engaging senior management because an awful lot of this is now coming from the board level. Many of the board are in corporations that are going through these things, so it's been heightened there. So our president and our cabinet hears it from the board -- "What are we doing?"
We've been actually directed to say, even though we might replace some of these systems only six months later, "Don't worry about it. Fix them first, then we'll worry about replacing them." So we've got a lot of direction when it comes to the board in terms of what to do and actually spending the money to be able to do that.
There have been many discussions so far about contingency plans. I'm not privy to those, but I know that the VP of technology has been on some of the discussions about what are we going to do about facilities. Each area is taking responsibility for doing its own scenarios and testing and what their contingency plans will be. I haven't seen any written item, but it's been high on the agenda of people to actually plan for that.
JB: Okay, sounds good. So actually, it came indirectly. You didn't have to get that by (inaudible).
DK: It actually was. As we started bringing it up, so did the rest of the world bring it to Princeton, so we didn't have to do a big sales job for our community.
JB: Okay. Before I do the final closing, Howard, Dave, any other final comments?
HS: No. Obviously, we are going to have interesting -- how many hours, 295 days, seven hours, nine minutes and 49 seconds here to look forward to.
JB: All right, very good, Howard. Dave?
DK: I guess this has been fun. I guess if it helps anybody sort of get on with it, I would say even though we think people are behind, there's still a lot can be done. So I would not hesitate to start, unless your resume is already in a Year 2000 compliant computer system.
HS: Wow, I guess I better work on that.
JB: Okay. Very good.
I'd like to thank all of our Web participants for being with us here today for this time with Dave Kohler. You can still send follow-up questions to expert@cren.net and Dave will answer them individually or on the Web.
Be sure to mark your calendars for March 25, two weeks from today, and the TechTalk will feature a return visit with guest expert Ken Klingenstein from the University of Colorado addressing the really tough question of "Where are we with middleware?" Plan on joining this session and inviting your friends and colleagues as well.
Check the Website for upcoming spring experts and, as always, we welcome suggestions and feedback on what and whom you would like to see and hear on TechTalk.
Thanks to everyone who helped make this possible today: the board of CREN; Dave Kohler our guest expert; technology anchor Howard Strauss; Web content producer Terry Calhoun; Harold Ansell and Lee Perlis of CREN for operational support; Paul Bennett and UM Web services for encoding; and all of you for being here. You were here because it's time.
'bye, Dave. 'bye, Howard.
HS: Thank you, Dave, and thank you, Judith. 'bye-bye.
DK: 'bye, Howard.
JB: Take care. 'bye-bye.
