Folks

I stumbled onto this document that is dated June 15 1999. So here are a few snips that caught my eye. Now I have NO experiance in such matters but it has been interesting to understand the complications that IT folk have to deal with. Since IBM is a major player in the IT world, this document might actually have some interest in the forum. (WOW). Most of the snips involve the actual rollover planning. The part about the differant time zones and time manipulations is quite interesting. Any commentary from the IT types would be welcome. I didn't post this for the polly and doomer mentality, just to bring a bit more depth to understanding the rollover. One comment. This looks like the rollover will be labor intensive. I have that right?

Here agian we have a valuable document in PDF format. Stupid

I like photoshop from Adobe, one of my favorite comp. tools but if you want to convey infomation isn't HTML better than PDF? What am I missing here? Alot of the real relevant information is posted on PDF Documents. Most don't read them. Waste of information.
 
 

http://www.ibm.com/ibm/year2000/rollover.pdf
 
 

*Pages 1--63 from v1.0d.lwp* Planning for the 1999 to 2000 Rollover of IT Systems

prepared by: Year 2000 Global Initiatives IBM Corporation

Chapter 1: Considerations For Getting Started
 

For many computers, there may actually be two rollovers for the system to handle: local and universal time. That is, while the time and date displayed on the screen may be in local time, this is often computed from Greenwich Mean Time (GMT) or Universal Time, Coordinated (UTC) 5 , based on the local time in Great Britain. In this case (and where the local time is not equivalent to UTC), systems will undergo two separate rollovers, one at midnight New Year's Eve local time and the other occurring prior to or after that point, depending on whether your local time is ahead or behind UTC (see Table 2). At each of these rollovers, your equipment and programs will, if active, need to be able to continue to properly handle the time and date. For programs that are active (or that may be subsequently invoked to manipulate data from this period), they must be able to process correctly dates from the two millennia. If your system or applications use one method of time keeping for some dates and the other for others, this exposure may be further complicated by data creation dates, modification dates, and processing dates that crisscross the millennium boundary during the time between midnight UTC and midnight local time.

For some systems, the transition into 2000 could occur at three or more moments (UTC, local time, and remote rollovers). Because of their connections through networks and data transfers with devices in other time zones or that use different methods of time keeping through networks and data transfers, some systems will encounter a series of rollovers as the day progresses. The first of these rollovers could be as early as the stroke of midnight New Year's Eve in Auckland, New Zealand (noon on December 31st UTC time), when the first time zone enters 2000; that transition would be 7 a. m. on December 31st for an organization in New York. The last rollover may not be until the final time zone leaves 1999 ---for example, 6 a. m. New Year's Day in New York.

Defining the Clock Transition Period You will need to consider all sources and sensitivities to date rollovers to determine when your significant rollover( s) occur and what actions you should take. For example:

* Do your systems use UTC, and if so, is your local time different from UTC? If so, compute when midnight UTC will occur in your local time.

* Do you receive or send data across time zones and does this create an exposure? If so, compute when midnight at the remote point will occur in your local time. Be sure to consider mobile users.

Snip

Chapter 1: Considerations For Getting Started 16 6 For example, you should understand the requirements and process to declare a disaster during the Rollover period since some providers have announced that Year 2000 problems are not themselves sufficient to invoke their services. 17 If you do not have these in place, you may find it difficult to develop a comprehensive Rollover Plan. In some cases, you may find that you will need to revise these plans for Year 2000 issues before the Rollover Plan can be completed.

When to Start Planning Depending on the complexity of your environment, the detail of the current documentation of your operations, and the number of operational actions you desire to take, developing a Rollover Plan can be a very complex project. It may involve a great deal of additional research on requirements and interdependencies, building assumptions about uncertainties, negotiating among a number of internal and external organizations, and collectively reaching decisions.

The process of collectively reaching decisions itself should not be underestimated. Rollover planning is a project that cannot be undertaken in isolation. For example, IT, aware of the system dynamics and the system risks, needs to work with the business process owners --the users and their management --to decide what the business risks and flexibility are. Each needs to build its assumptions based on the capabilities and concerns of the other. To make progress, you may find that many of the decisions initially require general direction from senior management; but as you better understand each situation and can form a collective picture, you may find that for a variety of reasons, many of the decisions becomes exceptions and a better strategic approach develops. All of this takes time.

Snip

Assessing the Vulnerability of Critical Resources to Year 2000-Related Problems

Normally, you are concerned both about the unavailability of applications (because then you are not supporting your organization's processes) and a failure of or damage to any of the resources that support them (since these are the tools by which you provide computing services). Stated differently, you are concerned both for the end product as well as the well-being of the resources in the chain that deliver it. What this chapter is intended to help you focus on is the need to take special precautions to deal with any Year 2000 problems. To do so, you need to understand how the year 2000 could impact these resources.

The Year 2000 issue arises because some equipment and programs have counters or logic that track, represent, or make decisions based on date information and may not correctly process dates later than 1999. For equipment and programs that do not correctly process the post-1999 dates, their results could be unpredictable and their impact could ripple widely from application to data, application to application, system to system, and organization to organization.

Snip

ransitioning from 1999 to 2000 A problem could arise because of the inability of a process (or a part of a process) to properly operate while spanning the millennium (that is, starting in 1999 and not ending until after 1999). This "work" could range in size from something as small as a task, to a transaction or job, to something as large as the steps of a business process (such as your company's payroll process). First, this means that you should understand if your work is susceptible to problems that arise from some portion of it occurring on two different sides of the millennium boundary 8 and then consider developing a plan to contain that susceptible portion in a single millennium (during your investigation, be sure to account for mobile workers and remote applications). Second, in a networked environment with remote processors, not only is work more likely to cross the millennium at some point, but it could also cross back and forth across the millennium boundary several times. This could be because the work is performed in two different time zones 

 For example, a business process that refers twice to date data may be confused if date data is converted between the millennia. 21 possibility with client-server applications); or, it could be because data (files, data sets, tapes, etc.) is created in one time zone and used in a different one.

In many cases, this issue of multiple years should be no different than what happens at the end/ beginning of any year. However, what makes this issue worthy of note this year is that many programs have changed from assuming that all two-digit dates are in the 1900's to either a four digit date, two digit date encoding, 9 windowing, 10 or some kind of data conversion. If there are data format changes, data representation changes, or new assumptions about data meaning that go into effect in 2000, then work crossing the date boundary could cause problems.

Snip

Understanding your Reliance, 12 Exposure, and Contingencies for Facility Services The term "facility services" includes floor space, power, lights, air, cooling and heating, and water. Power is critical to the operation of all IT equipment. Depending on the type of equipment and the ambient room temperature, air conditioning can also be vital. And many older and larger models of IT processors cannot operate without cooling water.
 

In order to assess the risks to your IT equipment from fluctuations and failures in your facility services, you should understand the following for all (including remote servers, communications equipment, and end user workstations) of your IT equipment:

* the amount and type of power required * the operating temperature range and its relationship to the outside weather during the Rollover (for example, can you vent the equipment directly with outside air in the event of a loss of air conditioning?)

* whether key equipment requires chilled water, and if so, whether it uses a closed-loop, chilled water system or a fresh water supply.

With an understanding of these requirements, you can investigate the safeguards in place to assure their provision during the Rollover Plan period.

IBM's Year 2000 ready hardware and software are designed to operate without interruption through the millennium rollover. 13 Consequently, they do not need to be shut off prior to the date rollover. However, since power spikes, disruptions, and "brownouts" can be detrimental to computer equipment (systems, components, peripheral equipment, and networks), you should consider the stability, reliability, and availability of power to your equipment 14 and balance this with the implications of unavailability and additional problems that may be caused by a planned shutdown.

Determine the extent to which your critical resources are protected by a special power supply. For example:

* Is your equipment connected to a power supply that will shield it from brownouts and disruptions in the power infrastructure if any should occur? Will it provide the correct power level for the duration of the outage?

* Will your power supply provide power to all of your equipment? If not, does it cover your critical components and do you have plans for the orderly shutdown of the non-critical components and the operation of your IT systems using only the critical components?

* Will it provide enough power and notice to allow for an orderly shutdown of applications and equipment if it cannot maintain the correct power level long enough?

* Is it sufficient to also support the facility to the extent needed by your staff? If your equipment is connected to an emergency power source or power conditioning equipment, review the last test results and the maintenance schedules and schedule a test of this equipment

Be sure also to consider remote devices, such as servers, routers, and workstations, that can be located in other states or countries.

Snip

First, look at the likelihood of the power failing. Based on your past experience and your confidence in your supplier, you decide that there is a small but significant risk that the power may fail around midnight local time. A power failure would affect all work done in that location. >From your prior disaster planning work, you know the estimated cost of an outage to your organization. You consider the following options:

* take no action, maintain application availability, and possibly incur an unplanned outage. * install a backup power system (a preventive action that eliminates the vulnerability). * take a data backup close to midnight (a precautionary action) and leave the system running; if the power fails, you will spend a predictable time recovering the application and perhaps longer if there are equipment problems as a result of the unplanned shutdown.

* undertake some degree of a shutdown (a precautionary action) that requires a planned outage but during a period of low impact to the organization and that reduces the recovery time; in addition, you consider whether the planned outage will expose you to additional problems at restart.

By looking at the cost of each alternative, you select the one best for your organization.

-- Brian (imager@home.com), June 21, 1999

Answers

Brian,

Gee, if a number of programmers have already screwed up the Y2k leap year situation, imagine how many have not caught all these time zone change scenearios during code remediation. The airlines sure are tied into this sort of problem, but I can think of many others as well. Of course IBM wouldn't be flagging this sort of thing unless it was considered a real trap for some software. Good post.

-- Gordon (gpconnolly@aol.com), June 22, 1999.

Gordon

It is an interesting mental diversion eh? The PDF file has lots of relevant information topping out at 160 K of just text on prepping for the rollover. What impacts me is the manpower for this over a 48 hr. period. Will the programmers and who ever else show up if there is a risk for their families. The power co's didn't seem to reassure IBM. Lots of info on power loss, particularly brown outs.

-- Brian (imager@home.com), June 22, 1999.

Worth repeating... <:)=

"logic that track, represent, or make decisions based on date information and may not correctly process dates later than 1999. For equipment and programs that do not correctly process the post-1999 dates, their results could be unpredictable and their impact could ripple widely from application to data, application to application, system to system, and organization to organization."

-- Sysman (y2kboard@yahoo.com), June 22, 1999.

Sysman,

Good point, and good reminder. You don't suppose that IBM has been buying a little consulting time with Hamasaki again, do you?

-- Gordon (gpconnolly@aol.com), June 22, 1999.

In other words we don't just have one roll over but multiple roll overs all in a 24 hr period.?? Thats it!! I just went to a 10 and now I have to sharpen the pencil and start a new list starting with another 500 lbs of wheat, more paking powder, salt, seeds and a big dog. Damn....! I am with Milne 100% now. I love toast but this is a bit much.

Taz....who has her tits in twist!!........again!

-- Taz (Tassie @aol.com), June 22, 1999.

In other words we don't just have one roll over but multiple roll overs all in a 24 hr period.?? Thats it!! I just went to a 10 and now I have to sharpen the pencil and start a new list starting with another 500 lbs of wheat, more baking powder, yeast,salt, seeds and a big dog. Damn....! I am with Milne 100% now. I love toast but this is a bit much.

Taz....who has her tits in twist!!........again!

-- Taz (Tassie @aol.com), June 22, 1999.

Typical IBM-ese.

Sysman will probably concur on this - I found it odd that the article did not say "The results may be indeterminable" (IBM's favorite dodge to stating what type of failure mode something may go into).

What I mean by "typical" is this: IBM is still a very large TOP- HEAVY organization which uses "quantity" as a measure of performance in all cases. This is just another case where a committee was formed to produce a statement that is nothing more than a re-hash of many other documents already produced. In other words - It's just the work of someone(s) trying to justify their existance to Big Blue.

To address any more of the article beyond Contingency Planning-101 and Year-2000 Remediation-101 would actually be a waste of all of our time.

Yours in COBOL... Dino!

-- (COBOL_Dinosaur@yahoo.com), June 22, 1999.