----- YEAR2000 CFORUM appended at 10:10:55 on 97/11/03 GMT (by DEMVG04 at ELINK) <10352> Subject: shared DASD controllers I looked up all the pruned files but couldn't find an answer to this subject. It was already asked but not answered very clearly. So once more: Does "totally isolated" mean that the use of EMIF and device candidate lists to provide access from an LPAR to a subset of DASD under a 3990-6 controller is also excluded? I have two LPARs, one for production and one for Y2K sharing the same RAMAC, each has access to a subset of these disks (no disk sharing|) they just use the same controller. Will that cause any problems? 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 11:42:56 on 97/11/03 GMT (by GBCCBD13 at ELINK) <10353> Subject: shared DASD controllers Ref: Append at 10:10:55 on 97/11/03 GMT (by DEMVG04 at ELINK) Hi Werner, If you read appends 87 and 91 of this CFORUM they should, I believe, provide the answer to your question. Regards, Peter Smith. This append was created on the External IBMLink system by SEMA Group UK Business Systems Capacity Planning and Management Group Tel +44 121 627 5351 FAX +44 121 627 5300 ----- YEAR2000 CFORUM appended at 16:43:52 on 97/11/03 GMT (by GBAIMI23 at ELINK) <10354> ..... YEAR2000 CFORUM modified at 09:21:04 on 97/11/04 GMT (by GBAIMI23 at ELINK) <10355> Subject: Bypass YR2000 by setting date back Ref: Append at 14:42:34 on 97/07/28 GMT (by ACLARK at EHONE7) The main problems that could be caused by setting the clock back to 1940 are : 1) Regular shutdowns of system will be necessary because of air raids. 2) CPU cycles will be rationed and will only be available at very high cost on the black-market. 3) Effective Data security will only be available between Stones Amusement Arcade and the Novelty Rock Emporium This append was created on the External IBMLink system by Richard Morton, Icom Solutions Ltd. phone: +44 121 356 8383 fax: +44 121 356 0463 IBMMAIL: GBKDFQXF Internet: richard_morton@icom-solutions.com ----- YEAR2000 CFORUM appended at 13:08:19 on 97/11/04 GMT (by DEMVG04 at ELINK) <10356> Subject: shared DASD controllers Ref: Append at 11:42:56 on 97/11/03 GMT (by GBCCBD13 at ELINK) Peter, I've read the append 91 you mention. But I'm still not sure how to interpret the answer Chris gave in this append. What does he mean with >>technically it is possible< Subject: shared DASD controllers Ref: Append at 13:08:19 on 97/11/04 GMT (by DEMVG04 at ELINK) Werner, I certainly took it to mean it would not cause problems. The fact that it was only *recommended* that you do not use this method, and the reasons given, convinced me of this. Regards, Peter. This append was created on the External IBMLink system by SEMA Group UK Business Systems Capacity Planning and Management Group Tel +44 121 627 5351 FAX +44 121 627 5300 ----- YEAR2000 CFORUM appended at 14:47:18 on 97/11/04 GMT (by GBCBHG00 at ELINK2) <10358> Subject: shared DASD controllers Ref: Append at 13:08:19 on 97/11/04 GMT (by DEMVG04 at ELINK) Werner, I have approached the problem from a slightly different angle in that I beleive that the individual devices *must* be hardware isolated from each LPAR such that there cna be no mistaken access by one MVS system to volumes owned by the Y2K system and visa versa. My reasoning is simple. During IPL MVS will access all devices it can as long as it has a logical and physical path to the device. This access could result in corruption or contamination. If the devices reside behind the same control unit, and are accessable via the same paths (say emif) then there is the possibility of this access occuring. If on the other hand the devices are defined with dedicated paths and only those devices accessed by each system are genned for each system then I would consider them isolated - with one caveat - the vendor of the control unit and device may be doing something which the SW or IO subsystem has no knowledge of. For example a 3990 with 16x3390 devices could be setup such that the MVSCP's for each system only know about there own devices LPAR A could have the first 8 and LPAR B could have the second. This would ensure isolation. This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 15:17:22 on 97/11/04 GMT (by GBCBHG00 at ELINK2) <10359> Subject: shared DASD controllers Ref: Append at 13:52:49 on 97/11/04 GMT (by GBCCBD13 at ELINK) Werner, (hit enter on the last append too early)......... We are setting up a 2nd DASD subsystem totally isolated (ie seperate controllers and DASD) from the production system. This is for many reasons, one of which is Y2K date contamination, another is software toleration (one system is MVS/XA and one OS/390 R3). As Peter Smith said, having the Y2K DASD and production DASD behind the same controller is not recommended due to the risk of inadvertant access. This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 07:02:12 on 97/11/06 GMT (by DEMVG04 at ELINK) <10360> Subject: shared DASD controllers Ref: Append at 15:17:22 on 97/11/04 GMT (by GBCBHG00 at ELINK2) Thanks to the two Peters for your help. It's clear now. Bye. 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 10:30:06 on 97/11/06 GMT (by WEIYH at HKGVM8) <10361> Subject: Will Year2000 Testing affect production under LPAR Mode Hello, there Sorry if I ask a dump question here. I am new to LPAR... My customer is considering to set up the year2000 testing on 9672-RA5 together with Production running in the same CPU under LPAR mode. Will this test environment affect the normal operation of production?? There are quite a lot CICS STORAGE VIOLATION in this shop. That's why customer concerns very much whether there is any risk to run this way??? Please Help!! Thanks a lot! Regards, Carmen ----- YEAR2000 CFORUM appended at 13:04:37 on 97/11/06 GMT (by GAD at KGNVMC) <10362> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 10:30:06 on 97/11/06 GMT (by WEIYH at HKGVM8) There is 100% total storage isolation between LPAR zones running on a processor. CICS storage violations are created by transactions running within the *same* CICS region and have nothing at all to do with isolation of storage between LPAR zones. As I have stated on this forum many times- THERE IS NO RISK in running a year 2000 test LPAR on the same processor as production. There is no direct storage to storage, TOD to TOD, or CP to CP communication between LPAR zones. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 12:43:32 on 97/11/07 GMT (by GBCFFC11 at ELINK) <10363> Subject: shared DASD controllers Ref: Append at 07:02:12 on 97/11/06 GMT (by DEMVG04 at ELINK) I have read these appends with interest, and therefore understand the risks, but has anyone actually tried the example that Peter mentioned, about defining in the MVSCPs/HCDs the first 8 devices addreses to LPARA and the second 8 device addresses to LPARB?? Regards, Steve May Cap Gemini 95 Wandsworth Rd London SW8 2HG E-Mail: steve.may@capgemini.co.uk This append was created on the External IBMLink system by Hoskyns Group plc ----- YEAR2000 CFORUM appended at 13:37:12 on 97/11/07 GMT (by GBCBHG00 at ELINK) <10364> Subject: shared DASD controllers Ref: Append at 12:43:32 on 97/11/07 GMT (by GBCFFC11 at ELINK) Steve, The short answer is I have not - we have presently opted for seperate controllers and DASD. But I am fairly sure the configuration is supported I would have to say (as has been said) that this is far from ideal - but then again we may just have to it. This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 14:30:28 on 97/11/07 GMT (by GBCEQG01 at ELINK) <10365> Subject: X-LPAR Corruptions when resetting LPAR Date Ref: Append at 11:31:54 on 97/10/16 GMT (by GBCBHG00 at ELINK) Peter, Sorry it's taken so long to append. We always move the date by ipl and the GMT option. We do not use the SET command as it causes problems with subsystems (Our auto op package will drive timer routines for every time it should have. ie if we go forward 10 hours and have a timer process every 15 mins, this process will be driven 40 times, immediately we forward the date. Also CICS does not detect date changes. it needs to be stopped and started) I hope this helps. This append was created on the External IBMLink system by Simon Hutchings Senior Technical Specialist Nationwide Building Society Tel. 01793-455740 ----- YEAR2000 CFORUM appended at 15:52:16 on 97/11/07 GMT (by GBCAIH00 at ELINK) <10366> Subject: shared DASD controllers Ref: Append at 12:43:32 on 97/11/07 GMT (by GBCFFC11 at ELINK) Yes, We have on EMIF channels with the additional security of making sure that the channels are excuded from the candidate lists. This append was created on the External IBMLink system by Mark Bentham Sema Group Outsourcing Reading 01189 642353 ----- YEAR2000 CFORUM appended at 06:36:20 on 97/11/10 GMT (by 83449535 at EHONE) <10367> Subject: RMDS (5648-048) V2.2 I would like to know whether the abovementioned product is Year 2000 ready. Thanks for your input. Ming Ket IBM Singapore. ----- YEAR2000 CFORUM appended at 13:36:35 on 97/11/10 GMT (by LGENDRON at KGNVMC) <10368> Subject:RMDS Ming, Using the IBM Product Readiness Database, one can determine if an IBM product is Year 2000 Ready (or not). One can access this database at: http://wwwyr2k.raleigh.ibm.com/ I generated a report which stated that RMDS (product number 5665310) is not Year 2000 Ready but that it has a replacement (product number 5648048) which also is Not Ready.The results of the generated report are listed below: PRODUCT: 5648048 REP.MGT.+DISTR.S.V2 S/390 MVS LATEST REL: 2.2.0 READINESS: not ready DATE: N/A REPLACEMENT PRODUCT: PRODUCT: 5665310 RMDS S/390 MVS LATEST REL: 1.4.0 READINESS: not ready DATE: N/A REPLACEMENT PRODUCT: 5648048 linda gendron ----- YEAR2000 CFORUM appended at 15:26:35 on 97/11/10 GMT (by Y2KTSC5 at STLVM6) <10369> Subject: RMDS (5648-048) V2.2 Ref: Append at 06:36:20 on 97/11/10 GMT (by 83449535 at EHONE) We received the following note from the product contact for 5648048: "Version 2 Release 2 of RMDS (product 5648-048) is Year 2000 ready and has been tested as such." The information will be updated shortly into the Product Readiness Database (see URL: http://wwwyr2k.raleigh.ibm.com. You may contact the Year 2000 Technical Support Centers directly via email (y2ktsc@us.ibm.com). Year 2000 Technical Support Center (TSC5) ----- YEAR2000 CFORUM appended at 20:09:11 on 97/11/10 GMT (by GGIESE at TORVM3) <10370> Subject: Hardware & Micro Code Hello, I have an operations specialist working on a year 2000 mainframe hardware assessment for one of our main customers and he has the following questions: "I am looking to clarify whether or not, when the IBM Y2K web site states that a hardware component is Y2K "READY", the microcode (if applicable) is included in that blanket statement. This would be microcode that the customer (or customer service rep.) would install or upgrade from diskette. I would assume that firmware contained on chips within the respective devices would be accounted for as a direct component of the hardware unit and if deficient, would be identified as a required EC. As an example, some time ago, we upgraded the microcode on our 3174 controllers and this had not been done for some time. The IBM Y2K web site gives the 3174 a clean bill of health. Now, no one other than us knows what microcode version we are using so ..... either the microcode is irrelevant to the Y2K issue or the microcode is addressed as a separate issue and thus we have to track that as well. Also, I would assume that some devices just don't care about the date and it is the application software that utilizes the device that are Y2K impacted" I would appreciate any comment regarding this issue. Gordon E. Giese, ISM T & T, Winnipeg, Canada ----- YEAR2000 CFORUM appended at 20:36:02 on 97/11/11 GMT (by Y2KTSC2 at STLVM6) <10371> Subject: Hardware & Micro Code Ref: Append at 20:09:11 on 97/11/10 GMT (by GGIESE at TORVM3) Gordon, Unless maintenance is indicated in the Readiness Report, you can rest assured that none is required. i.e. The microcode fixes for your hardware have no impact on it's Y2K Readiness. All hardware requiring specific levels or microcode are listed as such in the Readiness Database. Year 2000 Technical Support Center (TSC2) ----- YEAR2000 CFORUM appended at 10:25:22 on 97/11/12 GMT (by GBCFFC11 at ELINK) <10372> Subject: shared DASD controllers Ref: Append at 15:52:16 on 97/11/07 GMT (by GBCAIH00 at ELINK) Thanks, for the help, I believed the restricting address ranges approach to specific LPARs should work, but I have not tried it yet. Nice to know it works, before doing it! Steve May Cap Gemini 95 Wandsworth Road London SW8 2HG E-Mail: steve.may@capgemini.co.uk This append was created on the External IBMLink system by Hoskyns Group plc ----- YEAR2000 CFORUM appended at 12:56:35 on 97/11/12 GMT (by LESK at SPPVM1) <10373> Subject: Is VM/ESA 2.2.0 Officially Y2K Ready? Or does it take 2.3.0 (CMS14) to make it Official? Les Koehler IGS/NS - ShowBBS Development Tampa, Florida Sent on 12Nov1997 at 07:56:34 EST ----- YEAR2000 CFORUM appended at 16:08:34 on 97/11/12 GMT (by 83823526 at EHONE) <10374> Subject: support year 2000 for mvs 4.3 I need know if mvs 4.3 has support (ptf's) for year 2000. Some clients want know if it's posible to continue with mvs 4.3 after year 2000. can someone answer this question ? Thanks in advance. ----- YEAR2000 CFORUM appended at 16:34:37 on 97/11/12 GMT (by Y2KTSC2 at STLVM6) <10375> Subject: Is VM/ESA 2.2.0 Officially Y2K Ready? Ref: Append at 12:56:35 on 97/11/12 GMT (by LESK at SPPVM1) Product 5654-030, VM/ESA 2.2, is Year 2000 Ready. Year 2000 Technical Support Center (TSC2) ----- YEAR2000 CFORUM appended at 21:36:36 on 97/11/12 GMT (by GGIESE at TORVM3) <10376> Subject: Product Readiness Report - Question. Hello, According to the IBM Product Readiness Report for a "3370A02" Direct Access Storage device, it is deemed "NOT READY". However, the fields "Action RQRD/Recommended Action/Update Level" are blank. How can we obtain the information required to ensure readiness ? Thanks Gordon E. Giese, ISM T & T ----- YEAR2000 CFORUM appended at 21:51:27 on 97/11/12 GMT (by Y2KTSC5 at STLVM6) <10377> Subject: Product Readiness Report - Question. Ref: Append at 21:36:36 on 97/11/12 GMT (by GGIESE at TORVM3) 3370A02 will not be year 2000 ready. It was withdrawn from marketing in 1988 and therefore will not be year 2000 tested by IBM. Year 2000 Technical Support Center (TSC5) ----- YEAR2000 CFORUM appended at 10:25:30 on 97/11/13 GMT (by CHNVP96B at ELINK) <10378> Subject: Year2000 testing and Sysplex Timer and MAS Ref: Append at 14:46:31 on 97/10/22 GMT (by 86695013 at EHONE) We have set up an LPAR for Y2000. The first attempt was to set local time to 31. December 1999 in the evening. The rollover happened. Of course we got expired Passwords in RACF. Otherwise everything functioned. The experiment will be repeated and more detailed checks will be made. The LPAR is in a SYSPLEX, the other LPAR stayed in 1997. This append was created on the External IBMLink system by Michael Tarjan Telekurs Logistik AG email addr: ch779679 ----- YEAR2000 CFORUM appended at 19:16:47 on 97/11/14 GMT (by TR2 at MHV) <10379> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 13:04:37 on 97/11/06 GMT (by GAD at KGNVMC) From: Ato Bisda Based on a web article that I've recently read, it seems like there's a danger of MVS catalog corruption if you have 2 LPARs (production and Y2K test) sharing DASD and are IPLed with 2 different dates. The article states: "Inadvertent destruction of production data is a real danger. An IBM representative recently reported a situation where a customer was doing their Year 2000 testing in an LPAR. When they IPL'd the LPAR with a date in the next century, it destroyed some of their production data. This resulted from sharing DASD, channels, and drives. There was also a problem with the setup of SMS and Catalogs. Apparently next century dates were written to some production datasets and then a nightly backup deleted the datasets due to a Y2K-related problem with the backup utility. Therefore, it was actually two separate problems, one related to the MVS configuration, and the second to the use of a non-compliant utility. The use of non-compliant(Y2K) utilities within an LPAR are a particularly serious problem since many users will have difficulties in understanding the full implications of separate LPARS. Therefore, it will be dangerous to assume that an LPAR offers more protection than it really does". The article is entitled "All LPARs Down". You can view the full text at: http://www.idsi.net/techbmrs/lparsdwn.htm gad@kgnvmc wrote: > Ref: Append at 10:30:06 on 97/11/06 GMT (by WEIYH at HKGVM8) > > There is 100% total storage isolation between LPAR zones running on a > processor. CICS storage violations are created by transactions running > within the *same* CICS region and have nothing at all to do with > isolation of storage between LPAR zones. > > As I have stated on this forum many times- THERE IS NO RISK in running > a year 2000 test LPAR on the same processor as production. There is no > direct storage to storage, TOD to TOD, or CP to CP communication between > LPAR zones. > > Greg Dyck > MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 19:23:33 on 97/11/14 GMT (by WFARRELL at KGNVMC) <10380> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 19:16:47 on 97/11/14 GMT (by TR2 at MHV) Reply-To: wfarrell at ibmusm10 The date in one LPAR can't affect the date in the other LPAR. However, all recommendations I've seen in this forum and in IBM's Year 2000 planning guides strongly state that you must isolate the DASD that you use for testing. You must not let the production (current date) systems touch online DASD that has future dates. And if you IPL a system with a future date, any online DASD it can touch may also acquire the future date. So, don't worry about date corruption between the LPARs directly, but do worry about indirect problems if you don't totally isolate the DASD used for testing. Walt Farrell Internet: wfarrell@us.ibm.com IBMMAIL: USIB3H89 ----- YEAR2000 CFORUM appended at 22:13:47 on 97/11/14 GMT (by GAD at KGNVMC) <10381> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 19:16:47 on 97/11/14 GMT (by TR2 at MHV) This failure has **nothing** to do with LPAR. **EVERYTHING** about sharing DASD between a production system and a test system. The same failure would have occurred if two separate processors were involved sharing DASD in the same "configuration error". The append of mine you referenced said nothing about DASD; only that CPUs and storage do not have a problem. As I have said many times before in this forum, SHARED DASD IS DANGEROUS when doing Y2K testing. JUST DON'T DO IT. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 22:39:06 on 97/11/14 GMT (by GAD at KGNVMC) <10382> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 19:16:47 on 97/11/14 GMT (by TR2 at MHV) As a side note. The owner's of the referenced URL are trying to sell R/390's. It's not surprising to me that they try to put using LPAR to do it in a bad light. The article gives an inaccurate and incorrect message as far as I am concerned. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 00:19:43 on 97/11/15 GMT (by VMEGLER at SFOVMIC1) <10383> Subject: Clean Management Process Guide Ref: Append at 18:15:14 on 97/10/27 GMT (by Y2KTSC5 at STLVM6) I tried this search, and had no luck... Can someone point me to it again? ----- YEAR2000 CFORUM appended at 15:29:28 on 97/11/17 GMT (by TE1A702 at MEXVM2) <10384> HELLO, MY CUSTOMER IS WORKING ON MVS 522 AND CSP 330, HE WANTS TO KNOW IF THEIR APPLICATION ON CSP 330 CAN SUPPORT THE Y2000. ANY HELP WILL BE APPRECIATE. THANKS A LOT. GABRIEL BERMUDEZ ----- YEAR2000 CFORUM appended at 18:33:07 on 97/11/17 GMT (by GBCBHG00 at ELINK) <10385> Subject: Will Year2000 Testing affect production under LPAR Mode Ref: Append at 22:39:06 on 97/11/14 GMT (by GAD at KGNVMC) Here, here. As has been said many times, and I beleive is being practically experienced, LPAR's do have their place for Y2K time machines. It is the responsibility of the LPAR configurers (????) to ensure that the hardware configuration they define supports their needs and guarentees the integrity of their environments. We are using LPAR's for time machine testing. Anyone else wish to state their support? This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 16:11:50 on 97/11/19 GMT (by Y2KTSC5 at STLVM6) <10386> Subject: CSP Question Ref: Append at 15:29:28 on 97/11/17 GMT (by TE1A702 at MEXVM2) We are not exactly sure of your question. Is the customer asking if CSP 330 is year 2000 ready? If so, we will need an IBM Product ID or Part Number to answer. Product readiness information is available on the INTERNET at URL: http://wwwyr2k.raleigh.ibm.com/ or on the INTRANET at URL: http://yr2kprod1.raleigh.ibm.com/. You may also email us, the Year 2000 Technical Support Center, at y2ktsc@us.ibm.com and give us the product number information and we will be delighted to assist you further. Year 2000 Technical Support Center (TSC5) ----- YEAR2000 CFORUM appended at 14:54:53 on 97/11/20 GMT (by BLGIBSON at ATLVMIC1) <10387> Subject:IMS 4.1 (DB only) compliance issues? We have seen that 4.1 is non-compliant and intend to replace it. However, we would like to understand potential impact of doing the following in the interim: o Testing an IMS 4.1 DB application using Hourglass and setting the date to various 20xx dates o Changing dates in the IMS 4.1 DB to 20xx dates Anyone out there with facts, opinions or guesses? Thanks Bennie Gibson - IBM GS IT Architect - Atlanta, Ga. T/237-4576 ----- YEAR2000 CFORUM appended at 21:48:53 on 97/11/20 GMT (by TMALONE at TORVM3) <10388> Subject: Sharing Tape drives and control units Hello ... My name is Tom Malone and I am an IBM employee in Ottawa,Canada I have been following this forum with great interest for a number of months now, and still have many questions unanswered. However, as this is my first time making an addition to this forum, I will limit my query to one area only. My customer is about to set up a Y2K LPAR in a parallel sysplex environ- ment. They are still contemplating a Y2K Sysplex (but I digress). They have a 3494 Tape Library (unfortunately my experience to date has been limited to STK silos). They are running CA-MIM (similar to GRS I suppose). MIM is used to control who has access to a given tape drive at any one time. Hence LPARA doesn't snatch a tape drive out from underneath LPARB. OK ... Now if I make any incorrect assumptions, please feel free to point them out to me ... 1. A separate Tape Configuration Database (TCDB) will be required for the Y2K LPAR (we don't want to share this catalog do we?) 2. We would want to have separate tape ranges for the Y2K system and the Production LPARs. 3. Any production tapes that we wanted to use in the Y2K LPAR (ie. we wanted to copy data from Prod to Y2K) would appear as foreign tapes in the Y2K system. OK ... Is there an issue with sharing tape drives in the ATL (or outside for that matter) if MIM is acting as referee. The times between the systems are obviously seriously out of whack. MIM can be run with a control dataset on DASD. Certainly we don't want to run this way (shared DASD seems to be such a faux pas). I believe that MIM can be run in memory with CTC's ... although I am not that familiar with the process. I am not too worried about tape data corruption in the silos. But I am not sure how to handle tape drive sharing. Is this an issue or not???? Your comments would be appreciated ..... Regards .... Tom Malone ----- YEAR2000 CFORUM appended at 13:20:30 on 97/11/21 GMT (by GBCDLV00 at ELINK) <10389> Subject: IMS 4.1 (DB only) compliance issues? Ref: Append at 14:54:53 on 97/11/20 GMT (by BLGIBSON at ATLVMIC1) The *BIG* problem for us is that we have to switch from local DL1 to DBCTL before we can replace IMS 4.1. Is there any likelihood/rumour of a Year2000 compliant IMS version supporting local DL1. Chris Kendon This append was created on the External IBMLink system by E Midlands Electric ----- YEAR2000 CFORUM appended at 18:19:30 on 97/11/21 GMT (by ESAMBUC at CHGVMIC1) <10390> Subject: MVS dataset cataloging We have a problem with expiration dates on datasets allocated under MVS. In some cases the expiration date is set to 13/34/99 (!!) and of course this leads to problems. Systems people here tell me this is the ISMF subsystem of MVS (I never heard of this one...) There is some discussion of a so-called NEVER expiration option to prevent dataset migration, and that it might be involved here. Any inputs? ----- YEAR2000 CFORUM appended at 18:27:34 on 97/11/21 GMT (by ESAMBUC at CHGVMIC1) <10391> Subject: DIalog manager /CLIST/ ISPF windowing Is there any windowing capability being added to CLIST processing? For example, VER(&Y,NB,RANGE,87,50,MSG=) ... can this be interpreted as a range check between 1987 and 2050 in some way? ----- YEAR2000 CFORUM appended at 09:53:56 on 97/11/24 GMT (by GBCFDM44 at ELINK) <10392> Subject: MVS dataset cataloging Ref: Append at 18:19:30 on 97/11/21 GMT (by ESAMBUC at CHGVMIC1) Are you sure the date is *really* 34/13/99? If you are relying on ISPF to display the expiry date, check out apar OW28567 which describes this problem. It occurs when a VSAM expiry date of 9999.999 is assigned (which is a perfectly valid keep-forever date). This append was created on the External IBMLink system by Sandy Janas Standard Life, Edinburgh, UK Tel +44 (0)131 245 3526 Fax +44 (0)131 245 3520 e-mail: GBSL1SAJ@IBMMAIL.COM ----- YEAR2000 CFORUM appended at 16:35:41 on 97/11/26 GMT (by TROWELL at WTSCPOK) <10393> Subject: IBM 9672 Y2K Datesource feature The year 2000 Sysplex Test Datesource for IBM 9672 CMOS processors has been installed on our 9672 R75 (G4) and on our 9672 RX4 (G3) processors. It was released with the IBM 9672 driver 98 (DRV98). Even though it is called Sysplex Test Datesouce feature and is required for Sysplex Y2K testing when running on the same 9672 as 'current time' images, it is also useful for non sysplex customer. For the non sysplex customer, it allows for a Y2K TOD value to be set for the Y2K partition via hardware instead of only via software. This means that a customer can IPL with a Y2K value, and even reactivate the partition and again have the Y2K value. Ken Trowell ----- YEAR2000 CFORUM appended at 06:05:13 on 97/11/28 GMT (by E232561 at EHONE) <10394> Subject:customer's question 'what is a problem using non2000 year system' I am making a proposal to the customer of migration to the VSE/ESA V2.2 for year 2000. But the customer disagrees with this migration plan. It's main reason is that there are no concrete instances of the problem that they use VSE system which does not have year 2000 compliance. The customer eager to know a concrete instance of problems when they use VSE system which does not have year 2000 compliance. The customer's environment: S/W VSE/ESA v1.2.3 H/W 9221-150 They do not use cics. They do IPL and shut down and power off everyday excluding December 31, January 1,2,3. The customer had the Year 2000's test The test case is First they set system date with 9221 cpu console, then ipl VSE system. They make sure the VSE system date and time and day of the week. The test case are:Results are: Cpu date 1999/12/31 VSE date 99/12/31 ok CPU DATE 2000/01/01 VSE DATE 00/01/01 Day of the week is OK (same as 2000 year) CPU DATE 2000/01/02 VSE DATE 00/01/02 Day of the week is OK(same as 2000 year) CPU DATE 2000/01/03 VSE DATE 00/01/03 Day of the week is OK(same as 2000 year) CPU DATE 2000/01/04 VSE DATE 00/01/04 Day of the week is OK(same as 2000 year) CPU DATE 2000/02/29 VSE DATE 00/02/29 Day of the week is OK(same as 2000 year) Please tell me the concrete instance of the problem which using VSE that does not have 2000 year compliance. ----- YEAR2000 CFORUM appended at 07:00:30 on 97/11/28 GMT (by MSHEWELL at SYDVMXA2) <10395> Subject:customer's question 'what is a problem using non2000 year system' Ref: Appended at 06:05:13 on 97/11/28 GMT (by E232561 at EHONE) When you try to IPL any non-enabled VSE release with DATE=01/01/00, hoping it is understood to mean Jan 1, 2000, you'll be surprised to see the system date displayed as 01/02/00. On older releases, an unrecoverable loop has also been observed to occur shortly after the system date becomes 01/06/00. Since century information is not shown, you can't really see where you are, but your guess is right: it's January 1900. The suppression of January 1 is just a little programming trick, to compensate for the fact that 1900 wasn't a leap year. Following are some of the known problems in running a non-year 2000 ready version of VSE: o You cannot IPL your system with a date in 2000 and beyond, because The DATE specification only supports a 2-digit year relative to 1900. o VSAM files (including VSAM-managed SAM files) cannot have expiration dates in Year 2000 and beyond, because the expiration year is stored with 2 digits only and is always taken relative to 1900. o Other files can have explicit expiration dates in 2000 and beyond, but the checks for expiration ignore the century, and the date calculation for a retention period across the century transition always yields an early date in 1900. o Also, files with an expiration date of 99/365 actually expire and may be silently deleted on December 31, 1999, although that's normally not what you want. o Recovering or restoring a DL/I data base may fail, because the year in backup and journaling time-stamps has only 2 digits and is always taken relative to 1900. These are just a few examples of known problems. Other problems may occur that we don't even know about, because incorrect date handling - just like a programming bug - may fail in ways that nobody had anticipated. Following I am including a paper titled "Year 2000 tests on a non-current VSE system". This documents the actual testing on a non Year 2000 Ready version of VSE. Introduction ------------ This document is a short description of testing VSE Versions/Releases which do not contain the Year 2000 support at the century transition. The tests were done using a VSE/SP Version 4 system. The results shown here can also be expected on any other VSE system that does not have the Year 2000 support integrated. Please note that there have been problems reported like entering a loop or going into hardwait at certain days in January 2000. Such symptoms did not show up during the test scenarios done to create this report. General Year 2000 information ----------------------------- Support for the following hardware was withdrawn with the announcement of VSE/ESA 1.3 in 1992 and is, therefore, not available for any current VSE/ESA Release: o IBM System/370 models 145, 148, 155, 158, 3031 and 3033 o IBM 4321, 4331, 4341 models 1, 9, 10, 11, 4361 model 3 Year 2000 support is available via PTFs based on VSE/ESA 1.4.2 and VSE/ESA 2.1.3 and is integrated in the refresh releases for: o VSE/ESA 1.4.3 (last release with /370 support) o VSE/ESA 2.2 (requires ESA-capable hardware) The implementation of the YEAR 2000 support in VSE/ESA 1.4.3 mainly was done as a migration aid to allow customers to prepare their applications for the Year 2000. VSE/ESA 2.2 is the strategic VSE/ESA version and should be the target release for all VSE/ESA users. Test equipment -------------- Hardware The test described here was done on an IBM 9371, which is a non-ESA capable processor. VSE had to run in /370 mode. A separate test with VSE/ESA 1.4.3, which had the Year 2000 support integrated, was done on the same hardware without any problems. Software On the 9371 we installed a VSE/SP V4 system without any optional products or applications and concentrated on the behavior of the system at IPL time. In addition we always did a complete bringup of the subsystems POWER, VTAM, CICS, ICCF and performed basic functions like job submission, program development (editing) in ICCF, and system shutdown. Testing and making applications ready for the Year 2000 is an additional step which needs to be performed on an operating system being prepared for the Year 2000 and is not addressed here. During the different test scenarios, we got sometimes messages for equal file ID in catalog or overlap on unexpired file. These are not always mentioned here because they were related to work files and could simply be answered by DELETE. Test scenarios -------------- Century transition The first test we did was to IPL the system with a year 99 specified in the IPL SET DATE command and watch the system behavior at midnight. o We IPLed the system using SET DATE=12/31/99,CLOCK=23/55/00. o The date was correctly set to December 31, 1999 (Friday). o At midnight, the date switched to 01/01/00 (Saturday). o We let the system run for several days without shutdown. o We did a logon to CICS, created a job using the ICCF development environment, and submitted the job. This could be done without problems. o On 01/07/00 we shut down the system. o Then we IPLed the system without specifying a SET DATE command. - The system came up with the date 04/22/13 MONDAY and a time of 17/09/44. - During CICS startup, we got the message: EQUAL FILE ID IN CATALOG for DFHDMPA (replied by DELETE) after DELETE, CICS startup continued normally. o For verification we did another IPL with SET DATE=12/31/99,CLOCK=23/55/00. - Startup went O.K., and a TIME command showed 12/31/99 FRIDAY. - At midnight, the date switched O.K. A TIME command showed 01/01/00 SATURDAY. - We shut VSE down and IPLed without specifying SET DATE. The system came up with the date 04/16/13 TUESDAY. Summary ------- If the system is IPLed in 1999, the century transition is handled correctly. But a subsequent IPL without specifying a date gives a wrong result. IPL at different dates with Year=00 ----------------------------------- Because an IPL without date specification after the century switch always gave a wrong date, we tried an IPL with date specification. o IPL using SET DATE=01/01/00,CLOCK=10/10/00. - IPL completed, but the date was set at 1/02/00. - A subsequent TIME command showed 01/02/00 MONDAY. - The date was wrong by one day, and the day of the week reflected January 1, 1900 (a Monday). o IPL with SET DATE=01/02/00. - IPL completed, but the date was set at 01/03/00. - A TIME command showed 01/03/00 TUESDAY. 01/03/00 was a Wednesday. This error condition showed up until the end of February 00 (1900). o IPL with SET DATE=02/27/00 CLOCK=23/55/00. - JCL date displayed as 02/28/00. - At midnight, the date was altered to 02/29/00 (Wednesday). - The next midnight, it was 03/01/00 (Thursday). o IPL with SET DATE=02/28/00. - JCL date displayed as 02/29/00. - A TIME command displayed 02/29/00 WEDNESDAY. - We got an "Equal file ID in catalog" message. (Reply was DELETE) - Another IPL without using a SET DATE command resulted in a date of 02/28/59 displayed during IPL. But the following JCL date was 02/29/00. o IPL with SET DATE=02/29/00 - We got MSG 0I87D INVALID SPECIFICATION FOR KEYWORD date which is correct because (19)00 was not a leap year. o IPL with SET DATE=03/01/00 - Date displayed at IPL was 02/29/59. - We then used a SET DATE 03/01/00,CLOCK=10/10/00 command. - The date displayed at IPL was 03/01/00. - Output of a TIME command showed 03/01/00 THURSDAY. - We then did a subsequent IPL without a SET DATE command. Date displayed at IPL = 03/01/60 Date displayed by JCL = 03/01/00 TIME command output = 03/01/00 THURSDAY Summary ------- Every IPL using a SET DATE command was handled incorrectly until March 1. It was always one day in advance for the displayed date, but the day of week was displayed correctly according to 1900. There was always a mismatch of the date year displayed at IPL and the date displayed by Job Control. The year 00 was handled like a leap year, but 1900 wasn't one. This was detected when trying to IPL with a date of 02/29/00, which was rejected. No IPL with a correct date could be done between December 31, 99 and March 1, 00. Every specification of a year 00 refers to 1900 when calculating the day of week. Date changing command --------------------- VSE has an (undocumented) TIME command which was introduced to allow time changes (daylight saving time) without doing an IPL. This is an undocumented command because it has to be used with special care in regard to time and date handling by subsystems like CICS. When this command is used with an active CICS, problems with handling journal files and other date related data can be expected. We used this command to just display the time, but also wanted to use it to advance the time after midnight time alteration to shorten the interval up to the next midnight time switch. The result of this command was always wrong, and it never worked as expected. o Using TIME CLOCK=23/45/00 just to change the time resulted in a date change to 06/01/36. o A TIME DATE=01/01/00,CLOCK=10/10/00 sometimes asked to perform the TOD function on the service processor and sometimes didn't. o When TOD was requested, we always ended up in a completely wrong date like shown above. If you have any further questions don't hesitate to contact us. Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@vnet.ibm.com VNET: Y2KTSCAP at SYDVMXA2 ----- YEAR2000 CFORUM appended at 08:09:11 on 97/11/28 GMT (by DEDATE17 at ELINK) <10396> Subject: Sharing Tape drives and control units Ref: Append at 21:48:53 on 97/11/20 GMT (by TMALONE at TORVM3) Hello Tom, on my knowlegde of mim tape sharing (we used for several years, now we switched to MVS AUTOSWITCH function) you cant share tape devices between Y2k and realtime systems, because there are some timestamps in the MIM controldatasets to track the heartbeat of the other systems. You should install seperate tape units which are managed by the Y2K system. In the realtime system these tape units can be driven as manual units, so you have to vary off on Y2k first, before you can do a vary on on realtime system. We have an own STK-roboter system for Y2K and will go this way. I have no knowlegde on an IBM ATL 3495. Hope that helps. This append was created on the External IBMLink system by Thomas Engler, System Programmer DATEV eG, Paumgartnerstr. 6-14, 90329 Nuernberg Tel: 49-911/276-3431 Fax: 49-911/276-5559 Internet E-Mail: Thomas.Englerądatev.de ----- YEAR2000 CFORUM appended at 12:43:36 on 97/11/28 GMT (by E232561 at EHONE) <10397> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 07:00:30 on 97/11/28 GMT (by MSHEWELL at SYDVMXA2) Thank you for your quick answer and I understand what you said. However, the customer have tested year2000 with their machine and resulted NO problems. === Test equipment ============== Hardware 9221-170(which has Year 2000 support integrated) Software------------------- VSE/ESA V1.2.3(Non YEAR 2000) --- Test scenarios ============== First they set date with 9221 cpu console then ipl VSE system without set date command. Results ======= They set date 01/01/2000 with 9221 cpu console The result they could IPLed VSE system dated 01/01/00. The day of the week is same as Year 2000's week.(saturday). They set date 01/02/2000 with 9221 cpu console The result they could IPLed VSE system dated 01/02/00. The day of the week is same as Year 2000's week.(saturday). They set date 01/03/2000 with 9221 cpu console The result they could IPLed VSE system dated 01/03/00. The day of the week is same as Year 2000's week.(saturday). They set date 01/04/2000 with 9221 cpu console The result they could IPLed VSE system dated 01/04/00. The day of the week is same as Year 2000's week.(saturday). They set date 02/29/2000 with 9221 cpu console The result they could IPLed VSE system dated 02/29/00. The day of the week is same as Year 2000's week.(saturday). So my customer eager to know "" what is a problem by using NON current VSE sytem'' Best regards. Nobuko Imon Ext : 120-2735[5644-2735] Mail : HZC-660-A E-Mail : IMON@jp.ibm.com ----- YEAR2000 CFORUM appended at 13:11:37 on 97/11/28 GMT (by GAD at KGNVMC) <10398> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 12:43:36 on 97/11/28 GMT (by E232561 at EHONE) I thought the prior append on this *did* explain some of the problems. If your customer is does not believe he has to move to a supported release then he does not believe it. But are they willing to bet their business on it? Are their customer willing to bet on it? You are aware that most business's who suffer over a week of computer failure go bankrupt? That IBM service *CAN* *NOT* support him with any failures that they do find (and they *will*!). The customer will probably go out of business if they do not take action today. What the customer is suggesting just will not work. If it would then that release of VSE would be year 2000 complient. We made code changes to make other releases work. We would not have made those changes if they were not necessary. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 18:28:10 on 97/11/28 GMT (by GBCBHG00 at ELINK) <10399> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 07:00:30 on 97/11/28 GMT (by MSHEWELL at SYDVMXA2) This is the kind of information that has been needed for a long - long time. Some *real* problems on non-compliant SW. Would IBM care to publish similar known problems for other non-compliant Y2K software ? I know the information may be incomplete - but it may help with the assesment of *required* (by this I mean customer required) levels of software. For example IF (and I emphasise the IF) CICS V2 will function after the clock hits the big 2000, and we know some of the problems *we* can asses the impact or risk of staying on that release. If however it will not function at all - or functions with severe failure (ie loops abends etc) then there should be no assessment - get off it or suffer. What about a change to IBM's list of Y2K compliant SW and HW to have something of the flavour of CICS 1.6 - Untested CICS 1.7 - Tested - Failures are pervasive and risk data integrity. For further detail see xxxxxx CICS 2.1 - Tested - Superficial date anomolies identified - however system will run. For futher detail se xxxxxxxxxx CICS V4.1 Tested - Fully compliant This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 19:03:17 on 97/11/28 GMT (by GAD at KGNVMC) <10400> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 18:28:10 on 97/11/28 GMT (by GBCBHG00 at ELINK) I don't see a list like that ever being published. It would be *very* costly to test the systems comprensively enough to produce the list, let alone doing it in a timely manor. Defining the scope of the problem in words is often difficult, and means different things to different people. The liability issues would probably be something awful, even though IBM has stated that the system was not complient. Greg Dyck MVS BCP Kernel and CURE Support