----- YEAR2000 CFORUM appended at 09:35:33 on 98/04/01 GMT (by NEILAJ at WINVMD) Subject: CICS212 y2k enquiry Ref: Append at 12:28:45 on 98/03/27 GMT (by GAD at KGNVMC) ******* Warning VERY LONG APPEND ****** Contrary to the referenced append from Greg, the key points that need to be corrected are: 1. CICS 2.1.2 has been Year 2000 tested IBM Hursley - under a given set of conditions - see detail below. 2. CICS 2.1.2 does NOT go into endless loops nor does it have any other MAJOR operating errors - it will basically run to Spec apart from some functions (Described in more detail below). 3. The CICS 2.1.2 Log records DO NOT use 2 digit dates, all recovery operations from Application, CICS, System, Hardware, DASD failures etc all perform to Spec 4. CICS 2.1.2 has been fairly extensively analysed and there were NO integrity exposures found 5. CICS 2.1.2 in NOT Year 2000 Ready, because many interfaces are 2 digit, for example FORMATTIME, INQUIRE VOLUME etc. These items were all addressed during the development of CICS/ESA 4.1 during 1992. Your question is I believe, was can anyone provide some insight of running CICS 2.1.2 into and after the Year 2000. The following with the caveats is the best information that I have available at present. IBM has no plan or intention to ever provide any new releases or functional enhancements to CICS 2.1.2. Therefore IBM strongly recommends users of CICS 2.1.2, migrate to the supported Year 2000 Ready replacement products, either CICS/ESA 4.1 or CICS Transaction Server for OS/390. CICS/MVS Version 2 is Not Year 2000 Ready and is no longer supported by IBM. Running Not Ready products, like CICS/MVS V2 after the millennium will add an element of risk to your business. The level of risk will depend on a number of factors, including levels of hardware, software and the ability of your applications to cope with the millennium change. CICS/MVS was designed for MVS/X A and S/370 hardware whereas the minimum required level of hardware and software for S/390 Readiness is Enterprise Systems Architecture (ESA). However, recognising that some customers require guidance to help prioritise their Year 2000 migration activities and some may not complete all of their migration from CICS/MVS V2 before the Year 2000, IBM has performed a limited amount of analysis of CICS/MVS 2.1.2 at a 12/96 service level. What follows is the result of this analysis. The analysed environment was limited by the following conditions: 1. CICS/MVS 2.1.2 was run in conjunction with IBM ready hardware and software at current service levels 2. The software stack employed was an IBM only stack. No third party or ISV software was not included - This is potentially very significant as the main ISV software that works with CICS 2.1.2 is itself not ready - No product runs in isolation. 3. Only CICS Command Level applications were considered because CICS Macro Application Programming Interface (API) has no access to date and time information. If you have Macro applications that are Date and Time sensitive then you MUST verify the source of that information. Many Macro applications will typically use CSAJYDP (or CSASTYDP) for Date information. Now, while for CICS/VSE 2.3 (Which is ready and and which continues to support Macro) CSAJYDP was enhanced for Year 2000 - the equivalent support has NOT been added to CICS/MVS 2.1.2. However, the following information on CICS 2.1.2 is not guaranteed to be complete and thus the behaviour of this old release is unpredictable. Significant changes were made in CICS/ESA V4.1 for Year 2000 and these fixes will not be retrofitted to prior releases. The known problems are not major functional errors, they are less serious involving incorrect date displays and so on. Some problems are transitory and only persist across the 1999-2000 boundary. These can be avoided by shutting down the system in 1999 and restarting it in 2000 or in some cases by avoiding the use of certain functions such as CICS Message switching. If despite this situation, users decide to run CICS 2.1.2 which is an unsupported and Non-Year 2000 Ready releases after 1999 then they should carefully assess their installation needs and check the required CICS functionality against the list of limitations given below. They should also ensure that they perform a comprehensive system test. In providing this information about CICS/MVS 2.1.2, IBM in no way endorses or recommends that customers attempt to operate this product in the 21st century. Note: That while CICS 2.1.2 may continue to function within their specifications, with the identified limitations, in the 21st century, applications produced to run on them may not operate correctly if those applications contain date sensitive logic and if that logic is not updated to deal with the century transition. CICS Internal Operations ======================== All internal operations should work as specified, except for the following: CICS Message Switching - CMSG ----------------------------- The CICS supplied transaction CMSG which allows a user to send messages from their terminal to one or more destinations, uses a 2-digit year which is specified via the DATE keyword. The use of this keyword to schedule a message in 1999 for delivery in year 2000 causes a problem, or use at all in the 21st century will cause a problem. Attempting to send such a message will produce a CICS error message - "DATE ALREADY PASSED" However, use of the "+d" form to say deliver this message in "d" days will function correctly. CICS Statistics Utility Program - DFHSTUP ----------------------------------------- The CICS Statistics Utility program has a hard coding of the "19" so all dates will be printed as 19XX. In addition, there is a date algorithm used to determine the day of the week etc, and therefore this always assumes that the 2 digit year relates to 1900. So the day of the week would be report incorrectly for example CICS will determine that the 1st of January 2000 is a Monday and not a Saturday because the 1st of January 1900 was a Monday. CICS Software Interfaces ======================== All interfaces should work as specified, except as noted below. EIBDATE ------- The CICS EIBDATE provides access to the current date in the packed decimal format, and it can be updated by use of ASKTIME. If CICS/ MVS 2.1.2 is being run on ESA level system then EIBDATE will contain a century indicator as discussed below, otherwise it will not: - ESA - 0CYYDDD+ - Non-ESA - 00YYDDD+ Where "C" is the century indicator and can be interpreted as follows: - 0 = 20th Century - 1 = 21st Century - 2 = 22nd Century - etc Therefore the following dates would be represented as shown. - 31st December 1999 = 0099365+ - 1st January 2000 = 0100001+ - 31st December 2000 = 0100366+ FORMATTIME ---------- Only provides a 2-digit Interface. INQUIRE VOLUME DATE for Standard Label Tapes ------------------- This CICS function only returns a 2-digit year for the DATE keyword. It does however return the correct value, for example 00 for 2000. CICS Human Interfaces ===================== CICS uses mainly a two-digit date when displaying or reporting dates. These dates are not ambiguous in that the actual date can be inferred from the context in which the date is used. The exception to this are discussed below. CICS Master Terminal Transaction - CEMT -------------------------------- The CICS master terminal transaction (CEMT) exhibits the problem which was resolved in CICS V4. Namely, that there is a routine which causes suppression of leading Zeroes on any display. The result is that if you were to use CEMT of the first of January 2000; date "00.001" displays as: - "1" and similarly the 29th February 2000 will display as: - "60" CICS Execution Diagnostic Facility - CEDF ---------------------------------- The CICS execution diagnostic facility (CEDF) displays the EIBDATE. The problem with CEDF is similar to CEMT in that leading zeroes are again suppressed which provides a "correct" but ambiguous display. -------------------------- I hope the above is of help to you and answers your question. Bottom line is that IBM does not under any circumstances, advocate, warrant or sanction the use of Non-Year 2000 Ready Products after 31st December 1999. Further information on CICS and the Year 2000 can be found on both our Internal Web Pages at - http://w3.hursley.ibm.com/ts/year2000) - http://w3.hursley.ibm.com/ts/cics/year2000) and our external Web pages at: - http://www.software.ibm.com/ts/year2000). - http://www.software.ibm.com/ts/cics/year2000). The changes made to CICS/ESA 4.1 for Year 2000 are included within our external web pages. Cheers Arthur Arthur Neil CICS Development IBM Hursley, England ----- YEAR2000 CFORUM appended at 13:15:47 on 98/04/01 GMT (by AS103187 at ELINK Subject: DCAF and IBM Hardware. After seeing and experiencing the lack of response on the various product CFORA, I have decided to ask this here! There is a Year 2000 issue here, but also an issue of IBM's hardware support. There are various pieces of IBM hardware in the field that IBM has said are Year2000 compliant. My company's interest is in the area of :- 1 3745-31A with 3746-900 2 9672-RX3 with accompanying HMC. It is my understanding that IBM has said that these HARDWARE devices are Y2K compliant. It is also my understanding that in this context HARDWARE constitutes the physical hardware, and the software running on the supplied hardware. For want of something better, I will use the term 'support processor' to refer to the PC devices supplied by IBM to manage the 'big iron'. These support processors are for all intents and purposes PC's running OS/2, and they use DCAF for remote management. (In the case of the 9672, DCAF is also used to communicate between the HMC and the support element, which in reality an IBM Thinkpad). So we have an environment in which (in DCAF terms) there is an OS/2 TARGET workstation, and an OS/2 CONTROLLING workstation. DCAF used to be a separate product, but was taken under the TME environment as part of TME 10 Remote Control. So far, so good! IBM have provided for OS/2 on the target and the controlling workstations, as well as providing support for the new MS operating systems (WIN95 as target and NT as target AND controlling). Do I have that bit correct? Now for the problem! IBM have now announced that TME 10 Remote control is now Year 2000 ready with, what seems to me, an expedient by removing the DCAF portion as it it is not Y2K compliant. How can IBM on one hand say that their HARDWARE is Y2K compliant, but on the other say that one of the underlying pieces of software is not? What (if any) are IBM's plans to allow for remote control of their own HARDWARE devices (3745 Service Processor and 9672 HMC in our case)? A secondary issue here is that the base OS/2 running on these support processors is also out of servoce ( or soon will be). If any of this is announced, please point me to the announcement letters. I also don't think that this organisation is 'Robinson Crusoe', there are others that have expressed concern on the other CFORA. Thank you, John This append was created on the External IBMLink system by John Johnston phone +61 2 9902 5910 Technical Consultant (VTAM and NCP Sysprog) fax +61 2 9902 5111 Westpac Banking Corporation______________internet jjohnston@westpac.com.au Sydney, Australia IBMMAIL ID:- AUWBCRJJ ----- YEAR2000 CFORUM appended at 13:22:29 on 98/04/01 GMT (by AS103187 at ELINK Subject: CICS212 y2k enquiry Ref: Append at 09:35:33 on 98/04/01 GMT (by NEILAJ at WINVMD) What a great append!!!! Whilst giving no guarantee, this info will certainly allow the cutsomer to make a valued judgement and risk assesment. Wish we could get more information about other products in a similar vein. It can be done!! This append was created on the External IBMLink system by John Johnston phone +61 2 9902 5910 Technical Consultant (VTAM and NCP Sysprog) fax +61 2 9902 5111 Westpac Banking Corporation______________internet jjohnston@westpac.com.au Sydney, Australia IBMMAIL ID:- AUWBCRJJ ----- YEAR2000 CFORUM appended at 15:53:15 on 98/04/01 GMT (by MARCE at IBMFR) < Subject: DCAF and IBM Hardware. Ref: Append at 14:15:47 on 98/04/01 GMT (by AS103187 at ELINK) I read this question in a few fora and I tried to look for an answer. Here is what can be said for the 3746: There are investigations underway to replace DCAF to provide remote access to the 3746 Service Processor. Nothing has been decided yet. I hope we will get the right information within weeks. From: Jean-Pierre Marce ----- YEAR2000 CFORUM appended at 11:57:08 on 98/04/03 GMT (by GBCAYX01 at ELINK Subject: FTP from the "future" Can anyone see any reason NOT to FTP test results from our Y2K LPAR to our current-date test LPAR? We're trying to get data back to the real world, without using shared DASD and we believe FTP will help speed up the process. We have FTP for Netview and TCP/IP available to us. This append was created on the External IBMLink system by John Prayle +44 (0) 1274 759 619 +44 (0) 1274 759 790 fax ----- YEAR2000 CFORUM appended at 17:30:55 on 98/04/03 GMT (by RS0111 at ELINK) Subject: Guide to setting up a Y2K LPAR Ref: Append at 12:31:54 on 98/03/25 GMT (by WZ02198 at EHONE7) Any luck on getting internet access setup for this presentation yet? John Bellomy bellomy@ibm.net ----- YEAR2000 CFORUM appended at 11:49:20 on 98/04/06 GMT (by LESK at SPPVM1) < Subject: FTP from the "future" Ref: Append at 11:57:08 on 98/04/03 GMT (by GBCAYX01 at ELINK) I'd be concerned if you're using Netview FTP/VM. Support for it will end on 31Dec98 and it is not Y2K Ready. Also, if you're going TO an MVS system with future dates that's a nono. Les Koehler IBM Global Services ShowBBS Development Tampa, Florida Sent on 6Apr1998 at 07:49:20 EDT ----- YEAR2000 CFORUM appended at 11:51:23 on 98/04/06 GMT (by WFARRELL at KGNVM Subject: FTP from the "future" Ref: Append at 11:49:20 on 98/04/06 GMT (by LESK at SPPVM1) Reply-To: wfarrell at ibmusm10 Won't it all depend on whether the file transfer (either via GET or PUT) uses future or current dates on the system you transfer the data to? Unfortunately, I don't know how GET and PUT treat the dates. They might use the output system's date, or they might use the input system's date, and I don't know which. Walt Farrell Internet: wfarrell@us.ibm.com IBMMAIL: USIB3H89 ----- YEAR2000 CFORUM appended at 13:01:06 on 98/04/06 GMT (by DEMVG04 at ELINK) Subject: FTP from the "future" Ref: Append at 11:49:20 on 98/04/06 GMT (by LESK at SPPVM1) Les, can you please be more specific why it's not possible to FTP to a Y2K-MVS? Thank you. This append was created on the External IBMLink system by Werner Kuehnel Mannheimer Versicherung AG. Germany Tel.++49-621-4574885 Fax ++49-621-4574046 Email kuehnewe@mannheimer.de ----- YEAR2000 CFORUM appended at 15:20:55 on 98/04/06 GMT (by GBCAYX01 at ELINK Subject: FTP from the "future" Ref: Append at 11:57:08 on 98/04/03 GMT (by GBCAYX01 at ELINK) I should have added - both systems are OS/390. The Y2K 'future date' LPAR is OS/390 2.4 . The other, test, LPAR is OS/390 1.2. File transfers would be in both directions. This append was created on the External IBMLink system by John Prayle +44 (0) 1274 759 619 +44 (0) 1274 759 790 fax ----- YEAR2000 CFORUM appended at 17:44:36 on 98/04/06 GMT (by LESK at SPPVM1) < Subject: FTP from the "future" Ref: Append at 13:01:06 on 98/04/06 GMT (by DEMVG04 at ELINK) I didn't say it wasn't *possible*, but my append was rather terse... I should have pointed out that MVS can get very upset if future dates are encountered. Les Koehler IBM Global Services ShowBBS Development Tampa, Florida Sent on 6Apr1998 at 13:44:36 EDT ----- YEAR2000 CFORUM appended at 19:21:40 on 98/04/06 GMT (by ARNASON at SFOVMI Subject: NCP-VTAM Time Machine Interface How much risk is there in attaching a production 3745/NCP to a VTAM within a Time Machine if the NCP is 'owned' by the production VTAM? (Twintailed, channel attached). Does the answer change if the network is 'owned' by a CMC VTAM and connections to the application VTAMs (including the time machine) are via channel to channel? Do NCP and VTAM try to maintain clocks in synch? Are there any NCP-VTAM flows which include a time-stamp? XID? Has anyone out there tried to attach a time machine into an existing production network? Any pertinant information would be very helpful and appreciated here in Portland, Oregon. Calvin ----- YEAR2000 CFORUM appended at 19:46:59 on 98/04/06 GMT (by ACLARK at ELINK) Subject: NCP-VTAM Time Machine Interface Ref: Append at 19:21:40 on 98/04/06 GMT (by ARNASON at SFOVMIC1) IBM/GS runs our network - we run the Y2K machines as seperate subareas on two of our production 3745's. There's several other systems in each of the 3745's. We haven't seen any impact. The LU's people logon from are still owned by the production VTAM. The Y2K machines obviously have their own local applids that can be conencted to. I too would be interested in hearing of areas in VTAM that may be timestamp sensitive and should be specifically tested. ------------------------------------- Adrian Clark - Sears Canada Inc. IBMMAIL(CASRSAJC) / aclark@null.net ----- YEAR2000 CFORUM appended at 22:42:50 on 98/04/06 GMT (by GAD at KGNVMC) <1 Subject: NCP-VTAM Time Machine Interface Ref: Append at 19:46:59 on 98/04/06 GMT (by ACLARK at ELINK) Go look at http://www.software.ibm.com/year2000/y2ktestsystem.html/ and read the section on communication products. There is some considerations and options you must specify to prevent problems, but properly done it is safe. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 13:03:26 on 98/04/07 GMT (by GBCAGE94 at ELINK Subject: Netview and C/370 Year 2000 conflict. We are planning to install an OS390 2.5 System PAC for which we have to make a choice between certain products. In particular between Netview V3.1 (5655-007) which is our current release and Netview V3.2 (or TME 10 Netview for OS/390 - 5697-B82). Both are currently supported and will be supported through Jan 31 2001 (IBM Year 2000 Maintenance/Serv ice statement - wwwyr2k.raleigh.ibm.com/service.html). However Netview 3.1 needs C/370 Library (5688-188) which is not year 2000 ready and has an end of service date of Q4 1999. I do not want the TME 10 Netview, and to remain supported I do not need it. What is IBM's recommendation. This append has been be cross posted to the LE conference. This append was created on the External IBMLink system by Peter Gammage_________________________Email: peter_gammage@standardlife.com Standard Life_________________________Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 03:49:08 on 98/04/08 GMT (by SOEGENGF at SYDVM Subject: Hardware not in Readiness Database The following products were not found in the Readiness Database: 9022-01A, 9023-001, 9027-001,9309-001 and 9525-B04. Are these products Y2K ready ? Thanks, Frank Soegeng ----- YEAR2000 CFORUM appended at 05:02:19 on 98/04/08 GMT (by ALANDP at SYDVMXA Subject: Hardware not in Readiness Database The ES/9000 boxes were tested along with the parent ES/9000 (9021-9X2) which is "Year 2000 Ready". 9022-01A - Processor Controller 9023-001 - Power Sequence Unit 9027-001 - Power & Coolant Dist. Unit The 9309-001 is a rack enclosure with no date functionality The 9525-B04 is a colour monitor that was withdrawn in 1995 and we have no information on that. I will research and answer off-line. In future, please direct product readiness requests to the Year 2000 Technical Support Centres (the Australian email address is listed below) Regards Alan Place Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 05:30:30 on 98/04/08 GMT (by SOEGENGF at SYDVM Subject: Hardware not in Readiness Database Ref: Append at 05:02:19 on 98/04/08 GMT (by ALANDP at SYDVMXA2) Thanks Alan.. in fact I also sent the same question to the AP email. Apologies for forgetting to mention it in my append. Frank ----- YEAR2000 CFORUM appended at 18:04:32 on 98/04/08 GMT (by ARNASON at SFOVMI Subject: Time Machine Setup Times First of all my thanks to Greg Dyck and Adrian Clark for their help on the NCP/VTAM question !! For those who have gone through the process of creating an MVS time machine, could you share with the forum about how much calendar time it took? In particular, now long did it take to create the Y2K tomorrow box. That is, from the time you began creating the LPAR, until all the products were installed, licensing/RACF issues resolved, VTAM network connections made, and initial versions of programs/data installed with necessary prep work like DB2 binds, etc. how much time passed ??? I am going to append this question to the forum as well. The numbers I have heard up to now are 3-6 months. Is that your experience as well? ----- YEAR2000 CFORUM appended at 00:51:36 on 98/04/09 GMT (by TROWELL at WTSCPO Subject: Time Machine Setup Times Ref: Append at 18:04:32 on 98/04/08 GMT (by ARNASON at SFOVMIC1) We are an IBM internal site, and we have been through creating a Y2K system environments a number of times. So I think the answer to you for the 1st time was 8 man days. Now its hours for OS/390. Maybe so quick because we are always creating new system environments. We also trash the systems and all other DASD volumes after testing. Our Y2K systems are network connected (mostly through OSA-2 adapters). We have little licensing problems. We did some of the tests with a sysplex, and we did get another sysplex timer for some of our test cases. We also used the IBM 9672 Sysplex Test Datesource. We also did a few VM tests, for really testing our 9672 time impacts. I do not see why you would think it should take you 3-6 months, to get a Y2K system environment. Plan what you want to do, plan the hardware requirements, plan the Y2K time support, sort out any licensing problems, copy the systems, make required IPL/System changes (all our products were Y2K ready, so there was no planning time for this). Invoke the Y2K hardware changes, IPL and then test. We have always used shared DASD CU and shared processors, and now we also use the 9672 Datesource feature. We were mostly exercising the IBM 9672 hardware and SCP (OS/390). Ken Trowell ----- YEAR2000 CFORUM appended at 13:00:09 on 98/04/09 GMT (by AS103187 at ELINK ..... YEAR2000 CFORUM modified at 13:02:28 on 98/04/09 GMT (by AS103187 at ELINK Subject: Time Machine Setup Times Ref: Append at 00:51:36 on 98/04/09 GMT (by TROWELL at WTSCPOK) I think the 3-6 months time frame is in the PLANNING and (probable) hardware acquisition time. As you may be aware, my company had to go out and purchase new CPU's and DASD to provide the Y2K time machine(s). Even after the new hardware was on the floor, it took about 2-3 weeks elapsed before we had MVS running in the future. Now for more re-assurance as to network stuff... VTAM/SNA wise, we connect to the Y2K time machines via SCTC's, and twin-tailed 3745's (actually, there are 3 'current time' CA attached VTAMs, plus our CMC, plus the Y2K time machine that have SSCP-PU sessions with the NCP). We have seen no problems with this. All 3270 type access, be it real terminal, or via a session manager application to the time machines is from the 'current time'. (JES2) NJE is also used between the current time and the Y2K systems. 'Data movers' ( XCOM,NET/MASTER FTS) also successfully copy data between now and the future ( after all, the files are opened and closed at each end in their own time era) and vice-versa. What the applications do with the data is another matter, and is one of the things we are testing! We also have boundary network devices ( NT servers) running in the future attached to the 1998 machines with sessions to the IMS's and CICS's running on the time machines. ( After all, in this context, VTAM and NCP are just transporting data). TCP/IP wise, the Y2K systems talk to 'current time' systems via SCTC's. In this environment, FTP is used as a data mover. There is no shared DASD between 'current time' systms and the Y2K systems, nor between the Y2K time machines. In summary, Time will be needed for planning and implementation. Plan for extra hardware (DASD at least) It it quite safe to connect Y2K systems to 'current time' systems via SNA or TCP/IP. NCP can be owned/activated by VTAMs with differing times. This append was created on the External IBMLink system by John Johnston phone +61 2 9902 5910 Technical Consultant (VTAM and NCP Sysprog) fax +61 2 9902 5111 Westpac Banking Corporation______________internet jjohnston@westpac.com.au Sydney, Australia IBMMAIL ID:- AUWBCRJJ ----- YEAR2000 CFORUM appended at 17:31:09 on 98/04/09 GMT (by ARNASON at SFOVMI Subject: Time Machine Setup Times Ref: Append at 13:00:09 on 98/04/09 GMT (by AS103187 at ELINK) John and Ken, thank you very much for your help regarding time machine setup times and VTAM connections. I had meant to erase the 3-6 months statement from the append, but hit PF5 (which I thought was split/join) and sent it off instead. I didn't want to prejudice the answers. But let me tell you where I got the number. I attended the QAI testing conference in Orlando last November and spoke with a rep from a LARGE insurance company that was already well underway with their remediation plans (had begun in 1995), another retailer, and a defense department agency. And they all agreed on the 3-6 month estimate, as did a systems programmer from a very large retailer in Canada earlier this week in an e-mail to me --- I hope that report will get posted here in the forum as well. The reasons for the 3-6 month period are all different - sometimes it is a strange hardware setup, sometimes it is figuring out how to manage parallel software changes when Y2K is not the only regulatory 'must-do' project in the pipeline, ALWAYS (except perhaps at an IBM internal site) it is a problem of handling RACF or other security product 'expirations', sometimes it is the licensing problem, sometimes it's data aging problems ... where I am working right now it is a combination of the need to expand the data center (due to the 1 Terabyte of DASD the the test system will need), the problem of change management ... which is more an organizational challenge than a technical one...and simply getting everyone on board (operations, tech support, scheduling, y2k project office, test team, development, senior management) is usually difficult. I would expect that an IBM internal site would be able to get up a test system much faster than at a 'live' datacenter that is operating a moving 'operational' target. Getting MVS up on an LPAR with a new future date is the quickest part of the total in my experience. In any case I encourage anyone else reading this to share your time machine setup experiences with the great congregation of interested parties out here ! I am especially interested in the NUMBER of times time machines are needed to be reset (requiring restore of a previously created image of the system synchonized to a particular date) during a Y2K test. Is anyone out there FINISHED yet? And thanks again to those who have already appended! Calvin Arnason ----- YEAR2000 CFORUM appended at 00:04:40 on 98/04/11 GMT (by Y2KTSC3 at STLVM6 Subject: Tools for converting/aging VSAM data Ref: Append at 16:18:23 on 98/03/30 GMT (by EDGERLY at WASVMIC1) >Does anyone know of any tools that will assist with >converting VSAM files from two-digit to four-digit year format? The easiest way is to find a program in your shop that accesses the files in question and cut out all of the logic except OPEN, READ, and WRITE. Allocate a file that is the same as your 2-digit year file except for record length, and use that as your OUTPUT file. Copy the File Definition of the 2-digit year file in your program and give it a new name and 4-digit year dates. Then just a few statements: (I am using COBOL as an example) OPEN INPUT OLD-INPUT-FILE OPEN OUTPUT NEW-OUTPUT-FILE READ OLD-INPUT-FILE CALL CEEDAYS USING OLD-INPUT-FILE-DATE, OLD-PIC-STRING, LILIAN-RETURN, FC MOVE CORRESPONDING OLD-INPUT-REC TO NEW-OUTPUT-REC CALL CEEDATE USING LILIAN-RETURN, NEW-PIC-STRING, NEW-OUTPUT-FILE-DATE, FC WRITE NEW-OUTPUT-REC CLOSE OLD-INPUT-FILE NEW-OUTPUT-FILE This code can then be customized to do smart windowing based on whether the date is a birth date (window far in the past) or a maturity date (window extending into the future). Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 01:11:54 on 98/04/11 GMT (by GAD at KGNVMC) <1 Subject: Tools for converting/aging VSAM data Ref: Append at 00:04:40 on 98/04/11 GMT (by Y2KTSC3 at STLVM6) You could use DFSORT FIELD=COPY with OUTREC to alter the record format in the positions where the date is and insert constants, and write it to a new larger record size file. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 14:03:12 on 98/04/11 GMT (by YAEGER at SJFEVMX Subject: Tools for converting/aging VSAM data Ref: Append at 01:11:54 on 98/04/11 GMT (by GAD at KGNVMC) To expand on Greg's append: DFSORT's Year 2000 features might be of help. You can use new formats (Y2C, Y2Z, Y2S, Y2B, Y2P and Y2D) and a fixed or sliding century window with OUTFIL OUTREC to transform character, zoned decimal, special indicator, binary and packed decimal two-digit year dates to character four-digit year dates. My SORT2000 paper gives complete details on these features. You can browse SORT2000 on the DFSORT home page at URL: http://www.ibm.com/storage/dfsort/ or download text and Postscript versions from the DFSORT FTP site at: ftp://index.storsys.ibm.com/dfsort/mvs/ Frank L. Yaeger - DFSORT Team (Specialties: ICETOOL, OUTFIL, Y2K :-) ----- YEAR2000 CFORUM appended at 12:20:24 on 98/04/15 GMT (by GBCAGE94 at ELINK Subject: OPC/ESA 1.3 5695-007 I require urgent clarification of IBM's posistion regarding the maintenance and service status of this product. We recently had an IBM System Check 2000 done which indicated this product as year 2000 ready. It is (or was until today) still a current supported product. Based upon this and IBM's Year 2000 Maintenance and Service statement (wwwyr2k.raleigh.ibm.com/service.html) this product should remain current and in software service until January 31 2001. As a result it has been ordered in an OS/390 2.5 System Pac which is currently being buillt for us by IBM. We have however received a discontinuance of Program Service for this product with effect of 16th October 1998!!!!!! Which is correct? Support to 16th October 1998 or Jan 31 2001. I have asked our IBM rep to look into this and will cross post this to OPC forum (if there is one) This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 12:53:09 on 98/04/15 GMT (by GAD at KGNVMC) <1 Subject: OPC/ESA 1.3 5695-007 Ref: Append at 12:20:24 on 98/04/15 GMT (by GBCAGE94 at ELINK) The discontinuance of 5695-007 was announce in letter 997-238 on September 16, 1997. This announcement preceded the announcement of continued support through January 31, 2001, and thus takes precedence over the later announce since the later announce stated it applied to all products which had not already been announced for discontinuation. Have I confused you yet? Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 13:16:27 on 98/04/15 GMT (by AS103187 at ELINK Subject: DCAF and IBM Hardware. Ref: Append at 13:15:47 on 98/04/01 GMT (by AS103187 at ELINK) Well, after some research, and speaking to the Tivoli people here in OZ, there seems to be some way out of this situation. TME10 Remote control (without the DCAF portion) can have an OS/2 'target workstation'. In this environment, the 'controlling workstation' is running NT. The transport mechanism used in the TME 10 RC environment is TCP/IP. (Native) APPN does not appear to be an option. Is ANYNET ? This is my interpretation of the issues IBM will need to address. The Service processor for 'A' model 3745's will need to run an IP stack. (There is already an IP stack running on the HMC). The appropriate TME 10 Framework and PC agent will need to be installed on the SP and HMC. (For migration purposes, can this co-exist with DCAF?) As the OS/2 versions running on the HMC and the SP are not Y2K compliant and are, or will be very shortly, out of support they will have to be upgraded. IBM will have to announce a change to the environment that the cutomer will have to supply to allow remote management of these devices. ( Will IBM also contribute to the customers costs in making this change? ) - or - Can IBM really assess what is not Y2K compliant about the DCAF and OS/2 environments that it has supplied as part of the HARDWARE and then make some form of risk assessment? (In this case, I think that the non Y2K issue here is probably down to some log function only supporting 2 digits for the year. So what? we will not be making financial decisions based on these logs) It may be a 'manageable risk', although a statement to that affect by one part of IBM could open up issues in another. This is what has happened here! On one hand, IBM has claimed their hardware is Y2K compliant, but the underlying software has been declared not Y2K compliant by another division. Although I am aware that these CFORA are not 'official channels', I am quite surprised by the silence here! The Y2K teams seem to respond quite quickly ( but I suppose this is if they know the answer). I must assume this issue is still being researched. Cheers, John This append was created on the External IBMLink system by John Johnston phone +61 2 9902 5910 Technical Consultant (VTAM and NCP Sysprog) fax +61 2 9902 5111 Westpac Banking Corporation______________internet jjohnston@westpac.com.au Sydney, Australia IBMMAIL ID:- AUWBCRJJ ----- YEAR2000 CFORUM appended at 13:26:57 on 98/04/15 GMT (by AS103187 at ELINK ..... YEAR2000 CFORUM modified at 13:37:00 on 98/04/15 GMT (by AS103187 at ELINK Subject: OPC/ESA 1.3 5695-007 Ref: Append at 12:20:24 on 98/04/15 GMT (by GBCAGE94 at ELINK) >I have asked our IBM rep to look into this and will cross post this to >OPC forum (if there is one) There is an OPCESA CFORUM. If you can't see it, I can cross-post for you. If you want the post done, I probably won't be in a position to do that before 2200 15 April (UTC). ³ Peter found it. Cheers, John ----- YEAR2000 CFORUM appended at 15:35:32 on 98/04/15 GMT (by GBCAGE94 at ELINK Subject: OPC/ESA 1.3 5695-007 Ref: Append at 12:53:09 on 98/04/15 GMT (by GAD at KGNVMC) Greg, Confusion is my middle name. However, the OPC folks have advised that the Discontinuance of Service was for OPC/ESA 1.3 5695-007 and did not include OPC/ESA 1.3.1 5695-007. We are actually 1.3.1 and are therefore still covered. The missinterpretation (gulp) of the IBM Reclassification Of Service note was mine in that I had wrongly read it to mean that DoS for 1.3 included 1.3.1 This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 18:36:07 on 98/04/15 GMT (by MACASTRO at SPOVM Subject: AIX products readiness Ref: Append at 04:40:07 on 98/03/18 GMT (by LAURAG at SYDVMXA2) Hello Laura, I saw the following in: http://www.software.ibm.com/year2000/papers/aixy2k AIX Version 4, All Releases IBM is planning to identify new fixes required for AIX Version 4, and re-organize the APAR ordering numbers for ease of use. These will be identified by 30 April 1998. Please obtain the updated version of this document at that time. The same for AIX 3.2.5. This seems different from your previous append: Product Description Status APARs ------- --------------------------- ------------ ----------------------- 5756030 AIX earlier ver. than 3.2.5 NOT Ready 5756030 AIX VERSION 3.2.5 READY w PTFs IX59790,IX59438,IX59591, IX38473,IX68094,IX55509, IX67400 5765393 AIX VERSION 4.1.0 -> 4.1.5 Ready w PTFs IX60645, IX69580 5765655 AIX VERSION 4.2.0 Ready w PTF IX62015 5765655 AIX VERSION 4.2.1 Ready (NO PTF needed) 5765C34 AIX V4 INCLUDED WITH RS/6000 (Re-packaged) See 5765-393 for AIX V4.1.0 -> V4.1.5 (IX60645, IX69580) 5765-655 for AIX V4.2.0 (IX62015) 5765-655 for AIX V4.2.1 (NO PTF needed) Could you please help us? Marcio A. Castro - macastro@br.ibm.com PSS - Product Support Services - Brasil ----- YEAR2000 CFORUM appended at 02:10:30 on 98/04/16 GMT (by E085209 at EHONE) Subject: YR2000 Test machine. Hello, I have visited to the following site. ==> http://www.software.ibm.com/year2000/changesysdate.html/ . It covers many hints and tips and very useful ! It states that the Year 2000 test machine cannot include LPARs which contain members of a different sysplex with a different date. . But, why do not mention the IBM 9672 Sysplex Test Datesource feature for this solution ? Thanks a lot in advance for your help. Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 02:24:18 on 98/04/16 GMT (by E085209 at EHONE) Subject: DASD CU and SIM destination. Hello, the following description is existed in the YR2000 Web site. ===> http://www.software.ibm.com/year200/controlunits.html/ >> For a DASD controller, the SIM is presented to all >> attached systems if the latest microcode updates have >> been installed. . As this enhancement is very attractive, would you please let me know which kind of "microcode update" is needed to achieve this ? We have 3990-6 and 9393-T82. Thanks a lot in advance for your help. Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 04:04:23 on 98/04/16 GMT (by LAURAG at SYDVMXA Subject: AIX products readiness Ref: Append at 18:36:07 on 98/04/15 GMT (by MACASTRO at SPOVMSIB) Marcio, Since my referenced append was posted on this forum, additional information has been reported which identified new Year 2000 issues in AIX which will impact all ready versions of the AIX operating system. Problems occur in specific AIX commands and in certain programs provided with AIX. None of the problems, however, is expected to impact internal data integrity. They appear in lesser-used parts of AIX and in some "sample" programs provided with AIX. Nevertheless, they will require corrective fixes. These additional corrective fixes are currently being tested and the specific PTF requirements for AIX Year 2000 readiness is planned to be available at the end of April, 1998. As such, IBM has amended the Year 2000 Readiness status of AIX Operating Systems AIX 4.2.1 and AIX 4.3.0 - previously listed as Year 2000 ready without PTFs are now Year 2000 ready with the application of PTFs, details of which will be provided by April 30, 1998. All other AIX releases which have been listed as Year 2000 ready with the application of specific PTFs will now require additional PTFs, details of which will also be provided by April 30, 1998. The Product Readiness Database (http://wwwyr2k.raleigh.ibm.com) and the RS/6000 Year 2000 website (http://www.rs6000.ibm.com/solutions/y2k/) will be updated with the new information as soon as it becomes available. Regards Laura Grinham. Year 2000 Technical Support Centre - Asia Pacific Internet : y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 11:35:51 on 98/04/16 GMT (by 62479255 at EHONE Subject: project 'Houdini' ??? Hi, My customer asked me about an IBM (confidential?) project called 'Houdini'. It would be a kind of spy sw which would detect which version would run on the system & wether it would be Year2000 compliant or not. This makes me a bit think of 'EDGE Portfolio Analyzer', but there is no secrecy or confidentiality on that, since it's available for a year now. Elaborating on 'wether it would be Year 2000 complinat or not' I interpret this as that this piece of sw would go and look after the 2-YY digit built-in or intrinsic DATE functions. I don't think EPA does this. I don't know either if it is rather a library analysis tool than a real-time monitoring one. Does 'Houidini' mean something to one of you, so that I could liberate my customer from his chains... Jan Vanbrabant, VANBRABJ at BRUVMIS1 PS Also appended in PL/I & COBOL FORUM; best place to answer is here in the YEAR2000 forum.. If valuable answers would be posted in one of these 2 other fora, I'll engage myself to put them here. ----- YEAR2000 CFORUM appended at 11:49:00 on 98/04/16 GMT (by GAD at KGNVMC) <1 ..... YEAR2000 CFORUM modified at 12:04:29 on 98/04/16 GMT (by GAD at KGNVMC) <1 Subject: project 'Houdini' ??? Ref: Append at 11:35:51 on 98/04/16 GMT (by 62479255 at EHONE) Houdini was "pre-announced" at Share in Los Angeles as the "Year 2000 Runtime Analyzer/Fixer", though that will not be it's final name. Is has also been disclosed under letters of confidentiality to a number of customers. The official announce should occur in a few weeks. It is not appropriate to discuss the product any further at this time in an open forum. If you need more information contact Steve Carre in Fishkill (Steve Carre/Fishkill/IBM@IBMUS). Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 16:26:30 on 98/04/16 GMT (by CBS at SJEVM5) <1 Subject: DASD CU and SIM destination. Ref: Append at 02:24:18 on 98/04/16 GMT (by E085209 at EHONE) Make sure that you have the most current licensed internal code in all of your control units. Your service representative can assist you in checking to make sure that you are up-to-date. Chris Saul, Storage Systems Division, San Jose http://saul.sanjose.ibm.com/ ----- YEAR2000 CFORUM appended at 11:12:04 on 98/04/17 GMT (by NL5AAB09 at ELINK Subject: YR2000 Test machine. Ref: Append at 02:10:30 on 98/04/16 GMT (by E085209 at EHONE) Hello, As I understood from the presentation at the Parallel Sysplex Leaders Council in march, the Datesource is not yet announced (together with the G5). At that time it wasn't 100% guarenteed that the function would be delivered. Best Regards, Peter Smit ABN AMRO Bank Netherlands This append was created on the External IBMLink system by ABN AMRO Bank ----- YEAR2000 CFORUM appended at 11:16:44 on 98/04/17 GMT (by E085209 at EHONE) Subject: YR2000 Test machine. Ref: Append at 11:12:04 on 98/04/__ GMT (by ________ at ________) Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 11:20:24 on 98/04/17 GMT (by E085209 at EHONE) Subject: YR2000 Test machine. Ref: Append at 11:12:04 on 98/04/17 GMT (by NL5AAB09 at ELINK) Hello Peter, I have adviced that the new function was available in 9672-Rx5 (G4 Server). Was it not a correct info ?? Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 12:12:52 on 98/04/17 GMT (by DHONDY at PK705VM Subject: YR2000 Test machine. Ref: Append at 11:12:04 on 98/04/17 GMT (by NL5AAB09 at ELINK) The LPAR Sysplex Test Datesource enhancement was announced 4Q97. Here are some details: The enhancement is available on 9672 G3, G4, and Multiprise 2000 processors. The software support for this enhancement is provided in APAR OW28604. The driver level must be 98G, whether one has a G3 or G4 processor. NOSHIR DHONDY S/390 Parallel Center Poughkeepsie ----- YEAR2000 CFORUM appended at 18:31:36 on 98/04/17 GMT (by MA00613 at ELINK) Subject: y2k/changesysdate.html/ - not all there? I've gone to the year2000/changesysdate.html/ web page, but when I click on any of the links, the page does NOT change. I've tried it in 3 different operating systems with 3 different browsers... anyone else have this problem? Larry Kahm Heliotropic Systems, Inc. e-mail: kahml@ibm.net "to boldly break software that no one had thought to before..." ----- YEAR2000 CFORUM appended at 18:41:08 on 98/04/17 GMT (by GAD at KGNVMC) <1 Subject: y2k/changesysdate.html/ - not all there? Ref: Append at 18:31:36 on 98/04/17 GMT (by MA00613 at ELINK) Tis viewable at http://www.software.ibm.com/year2000/changesysdate.html with no problems. I think some stuff got moved from www.ibm.com to www.software.ibm.com, and that has confused people. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 03:19:53 on 98/04/19 GMT (by TROWELL at WTSCPO Subject: YR2000 Test machine. Ref: Append at 11:12:04 on 98/04/17 GMT (by NL5AAB09 at ELINK) The 'Sysplex Test Datesource' function has been announced an shipped to the field. It is available on 9672 R4, R5, 2003s and ASP 3000. It was shipped to the field on R5 4Q97. This function allows a customer to run a Y2K test sysplex with 2 or more members a the multisystem sysplex, and with all th members of this sysplex in the same Y2K ""Datesource Group"". However all the members of the datesource group must be on the same CMOS processor. What you heard at the March meeting was things in addition to this. Please wait awhile to hear more. Ken Trowell ----- YEAR2000 CFORUM appended at 11:30:54 on 98/04/20 GMT (by NL5AAB09 at ELINK ..... YEAR2000 CFORUM modified at 13:10:17 on 98/04/20 GMT (by NL5AAB09 at ELINK Subject: YR2000 Test machine. Ref: Append at 03:19:53 on 98/04/19 GMT (by TROWELL at WTSCPOK) OK, it's clear to me Best regards, Peter Smit This append was created on the External IBMLink system by ABN AMRO Bank ----- YEAR2000 CFORUM appended at 10:58:07 on 98/04/22 GMT (by DEMVG04 at ELINK2 Subject: FTP from the "future" Ref: Append at 17:44:36 on 98/04/06 GMT (by LESK at SPPVM1) Sorry for reopening this subject, but we'll start our Y2K LPAR very soon and we also propose to do FTP mainly from production LPAR to Y2K LPAR, may be the other direction too. After reading all the appends it's still not clear for me where the problem is. When I ftp a file then it will be allocated in the target system with the date of the target system. The only contamination I can imagine are the statistics of members of a PO dataset. They will contain the "other" date. Is this a serious problem? Are there any other things we have to take into consideration? This append was created on the External IBMLink system by Werner Kuehnel Mannheimer Versicherung AG. Germany Tel.++49-621-4574885 Fax ++49-621-4574046 Email kuehnewe@mannheimer.de ----- YEAR2000 CFORUM appended at 23:27:28 on 98/04/23 GMT (by MRYSTEPH at TORVM Subject: Date calculations Ref: none My client has several REXX programs that calculate number of days between dates. No one can tell me who wrote them and they 'just work'. All of these use a formula that includes (monthn * 3055) % 100 What is the significance of the 3055 constant? It does not seem to have a year 2000 exposure but I would like to know what the formula means It seems to be connected to figuring out how many leap years are between the dates but I can't be sure. Maxine Rystephanick ----- YEAR2000 CFORUM appended at 10:25:46 on 98/04/24 GMT (by NLX3951 at UITVM1 Subject: Date calculations Ref: Append at 23:27:28 on 98/04/23 GMT (by MRYSTEPH at TORVM3) Hmm.. 3055/100 is close to the average number of days per month, like (29+4*30+7*31)/12 is 30.5. The additional .05 might be to cause rounding. You will probably need to look at where this is being used. Rob van der Heij ----- YEAR2000 CFORUM appended at 19:23:05 on 98/04/24 GMT (by BARD018 at EHONE7 Subject: Date calculations Ref: Append at 10:25:46 on 98/04/24 GMT (by NLX3951 at UITVM1) There are 97 leap years in every 400 years. Therefore, the average days per month is: (365 * 400 + 97) / (400 * 12) = 30.4368 Chen-yu Hu C. R. Bard, Inc. Murray Hill, NJ, USA chen-yu.hu@ccmail.crbard.com (908) 277-8512 ----- YEAR2000 CFORUM appended at 21:35:51 on 98/04/26 GMT (by NLX3951 at UITVM1 Subject: Date calculations Ref: Append at 19:23:05 on 98/04/24 GMT (by BARD018 at EHONE7) Yes, the 30.5 as average days per month would be for leap years only. Rob van der Heij ----- YEAR2000 CFORUM appended at 11:51:09 on 98/04/27 GMT (by 84867245 at EHONE Subject: IBM Plan for 12/31/1999 etc. We currently run a risk assement about the progress in a year2000 project The following questions were raised from customer regarding IBM products: 1. We read the definition of YEAR 2000 READY. What process must be done by an IBM product(lab) to be YEAR 2000 READY (how visible is that for a customer)? 2. One can assume that arround year end 1999 begin 2000, customers worldwide will have more need for support from IBM.... Does IBM plan special attention for the support structure (level1 and up incl. labs, e.g. no vacation, normal working days instead of time off for New Year). Many thanks in advance for clarification Best regards Peter Ramisberger ----- YEAR2000 CFORUM appended at 11:58:58 on 98/04/27 GMT (by ACLARK at ELINK) Subject: Date calculations Ref: Append at 23:27:28 on 98/04/23 GMT (by MRYSTEPH at TORVM3) If this is running on VM and the system is at ESA 2.2 or above then you may want to look at using the new extensions to Date() which finally allows you to manipulate dates other than today. I don't know if this got carried over to other REXX platforms yet. ------------------------------------- Adrian Clark - Sears Canada Inc. IBMMAIL(CASRSAJC) / aclark@null.net ----- YEAR2000 CFORUM appended at 13:01:12 on 98/04/27 GMT (by GBCAGE94 at ELINK Subject: IBM Plan for 12/31/1999 etc. Ref: Append at 11:51:09 on 98/04/27 GMT (by 84867245 at EHONE) I would also be interested in the answer to the 2nd question. This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 13:08:40 on 98/04/27 GMT (by GBCAGE94 at ELINK Subject: Bringing in the New Year early.... Whilst reading some recent Y2K mail regarding early close downs, I had an interesting idea. Given the concerns that are expressed about people not wanting to have their new year celebrations interupted by solving the problem (ie being on site or on call etc), can anyone see any problems with having our mainframe (MVS) computers bring in the century early? Say for example at lunch time on Friday 31/12/1999 (or earlier if it is a bank holiday as is being muted in the UK), we shut down our machines, set the clock to 23:45 and let New Yaer happen early. Not as a test, as the real thing. Processing can be performed (all be it actually 12 hours earlier than normal), and problems identified and raised with vendors (who of course will be available until at least 17:00 ;-). After 12 hours work, we can take a brake to celebrate the New Year with confidance. On Sunday 2/1/2000 at lunch time we shut down the operating systems and reset the clocks back to real time (machine clock will actually be 24:00) and let them sit idle for 12 hours. We then IPL and all is back to normal. The objective (or benefits) being to have problem identification started whilst staff and vendors are still available and sober, and to allow people to celebrate as close to normal as possible without the thought that they may be called at 00:05 on 1/1/2000. This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 13:57:52 on 98/04/27 GMT (by JDH at CANVM2) <1 Subject: Bringing in the New Year early.... Ref: Append at 13:08:40 on 98/04/27 GMT (by GBCAGE94 at ELINK) Now let's see how the ATM (banking machine) customers would like it if all ATMS were shutdown for 12hours and they needed a little extra cash for Taxi fare home... ;-))))) John ----- YEAR2000 CFORUM appended at 16:46:24 on 98/04/28 GMT (by GBCAGE94 at ELINK Subject: Bringing in the New Year early.... Ref: Append at 13:57:52 on 98/04/27 GMT (by JDH at CANVM2) The only reason I considered it was that in our environment that would not be a problem. Our online business is not 7x24 (yet). It therefore lends itself to this approach. This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 20:22:11 on 98/04/28 GMT (by EELLS at KGNVMC) Subject: IBM Plan for 12/31/1999 etc. Ref: Append at 11:51:09 on 98/04/27 GMT (by 84867245 at EHONE) Without making any official IBM commitment, I think it's safe to say you can expect us to have more people than usual both at work in the support center and on call in case they're needed. John Eells OS/390 Gateway IBM Poughkeepsie ----- YEAR2000 CFORUM appended at 11:56:17 on 98/04/29 GMT (by DKMAN06 at ELINK) Subject: Guide to setting up a Y2K LPAR Ref: Append at 09:16:54 on 98/02/05 GMT (by GBCAGE05 at ELINK) Ken I would very much like a copy of your foils about: Guide to setting up a Y2K LPAR. My E-mail is kahÃmanbw.dk Regards Anker Hansen This append was created on the External IBMLink system by Anker Hansen MAN B&W DIESEL A/S ----- YEAR2000 CFORUM appended at 13:14:54 on 98/04/29 GMT (by SAKC3II at ELINK) Subject: Guide to setting up a Y2K LPAR Ref: Append at 11:56:17 on 98/04/29 GMT (by DKMAN06 at ELINK) Please include me also. Send a copy of your presentation foils to: aschwart@jalden.com Many thanks. Alan Schwartz John Alden Systems Company. ----- YEAR2000 CFORUM appended at 13:26:16 on 98/04/29 GMT (by SAKC3II at ELINK) Subject: Defining Devices to Y2K Lpar I am in the process of defining my test lpar in HCD. I have my own isolated Dasd, my own consoles and dedicated terminal. We have some Storagetek tape drives not in a silo and made those chp's reconfigurable so they can be used. I have a 3800-3 printer on its own chpid. Does anyone know if there would be a problem if this channel was also made reconfigurable so the printer could be swung over to the test machine? What other methods are being used to handle reports generated by testing (NJE, Spool Offload)? Alan Schwartz John Alden Systems Company. ----- YEAR2000 CFORUM appended at 14:42:37 on 98/04/29 GMT (by GBCAGE94 at ELINK Subject: Defining Devices to Y2K Lpar Ref: Append at 13:26:16 on 98/04/29 GMT (by SAKC3II at ELINK) John, I can't see a problem with the printer reconfigurability, but I would be concerned about the STK Silo's. I don't know much about them (someone else is responsible for our silo's), but I beleive there is a control dataset which goes with the silo indicating slot storage and location information. If you intend to reconfigure the drives to enable use of the silo, then I beleive the control datasets will need to be shared between your Y2K and production images. This is a non-starter. This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 15:32:32 on 98/04/29 GMT (by ZAC3ST13 at ELINK Subject: Defining Devices to Y2K Lpar Ref: Append at 14:42:37 on 98/04/29 GMT (by GBCAGE94 at ELINK) The STK drives are not in a silo so they should not be a problem either. You can put STK drives that are in a silo on to a Y2K system,BUT there must be NO connection from the Y2K system to the robotics(command path) then the cds dosn't have to be shared.This setup then requires the operators issue mount cmds from a system that is connected to the Library.This setup is supported by STK. P.S The operators would also have to issue dismount cmds. This append was created on the External IBMLink system by Kevin Buckfield Systems programmer(MVS) Standard Bank SA Buckfield K@ceo.sbic.co.za:smtp / zasbs82s:ibmmail KevinB@mailexcite.com ----- YEAR2000 CFORUM appended at 19:01:11 on 98/04/29 GMT (by EELLS at KGNVMC) Subject: Managing and Identifying Y2K Service This is the text of a WSC FLASH that should go out during the next week or so: Year 2000 SOURCEIDS and Enhanced HOLDDATA ----------------------------------------- For orders placed after 1 May 1998, the SOURCEIDs delivered in ESO and CBPDO, and the Enhanced HOLDDATA delivered on ESO, corrective service tapes, and from the Enhanced HOLDDATA website will be enhanced to include information about PTFs for Year 2000. These enhancements make it easier to install all in-house PTFs for Year 2000 support, and to identify uninstalled Year 2000 PTFs and unresolved Year 2000 PTFs. IBM plans to make these enhancements available in other service deliverables during 1998. New YR2000 SOURCEID: -------------------- PTFs that provide Year 2000 support or resolve Year 2000-related problems will be assigned a SOURCEID of YR2000. PTFs that are assigned SOURCEIDs for other reasons will continue to have those SOURCEIDs assigned in addition to YR2000, with the exception of PTFs assigned HIPER. After receiving a CBPDO or ESO containing the new ++ASSIGN statements, all PTFs having the SOURCEID YR2000 can be selected for installation as a group by including them in the SOURCEID operand of the APPLY command: APPLY SOURCEID(YR2000,HIPER...) GROUPEXTEND . New YR2000 HOLDs and HOLDCLASS: ------------------------------- Product FMIDs, in addition to being held for HIPER APARs, will also be held for Year 2000 APARs. The holds for HIPER APARs will continue to be assigned a HOLDCLASS of HIPER. The holds for Year 2000 APARs will be assigned a HOLDCLASS of YR2000. To identify unresolved Year 2000 APARs on your system, you can use SMP/E's REPORT ERRSYSMODS command. (You can sort the report's output to consolidate the unresolved Year 2000-specific information.) REPORT ERRSYSMODS is available on all supported releases of SMP/E and OS/390. If you have OS/390 Version 1 Release 3 with IR35282, or OS/390 Version 2 installed, fixing PTF information will also appear in the report: REPORT ERRSYSMODS ZONES(target_zone,target_zone,...) . To bypass the Year 2000 holds when installing a product, you can code the BYPASS operand of the APPLY command: APPLY S(fmid,fmid,...) BYPASS(HOLDCLASS(YR2000)) ...any other parameters documented in the program directory. SCHEDULE OF AVAILABILITY AND OTHER SOURCES OF INFORMATION: ---------------------------------------------------------- The new SOURCEID will be assigned in ESO and CBPDO by May 1998. Information about the new SOURCEID will be included in: - The ESO Memo to Users included with any ESO ordered after 1 May 1998 - The installation instructions on File 2 of ESO and corrective service tapes - The CBPDO Memo to Users Extension included with any CBPDO ordered after 1 May 1998 - The ESO Overview and Installation instructions web page at: http://service.software.ibm.com/390hdmvsinst.html The new holds for Year 2000 APARs will be added to Enhanced HOLDDATA by May 1998. Enhanced HOLDDATA is already included in ESO and on corrective service tapes, and is also available from the Enhanced HOLDDATA website at this URL: http://service.software.ibm.com/390holddata.html Enhanced HOLDDATA is scheduled to be included in CBPDO later this year. You can find more information about Enhanced HOLDDATA from these sources: - The Enhanced HOLDDATA website at the URL listed above - The ESO Memo to Users included with any ESO order shipped after March 1998 - WSC FLASH 9812, "Enhanced HOLDDATA" (Note: When CBPDO includes Enhanced HOLDDATA, the CBPDO Memo to Users Extension will also be updated.) John Eells OS/390 Gateway IBM Poughkeepsie ----- YEAR2000 CFORUM appended at 23:29:26 on 98/04/30 GMT (by CYLYIU at ISSCAUS Subject: Guide to setting up a Y2K LPAR Ref: Append at 13:14:54 on 98/04/29 GMT (by SAKC3II at ELINK) Please include me also. Send a copy of your presentation foils to: cylyiu@au1.ibm.com Thanks.