----- YEAR2000 CFORUM appended at 12:08:28 on 97/12/01 GMT (by DEGRZ417 at ELINK) <10401> Subject: Y2K Literature Where can I found information about all the different "clocks" in the maschine/software like: Local TIme, GMT, Hardware time (any more ?) ? This append was created on the External IBMLink system by GRZ Ulrich Schmitz Germany 0441/4004201_ DEGRZ417 at IBMMAIL ----- YEAR2000 CFORUM appended at 12:42:09 on 97/12/01 GMT (by TROWELL at WTSCPOK) <10402> Subject: Y2K Literature Ref: Append at 12:08:28 on 97/12/01 GMT (by DEGRZ417 at ELINK) Please sent me the name of your IBM representative and I will sent them a softcopy of this information. I will be placing this information in an IBM tools directory so IBMer so IBMer can get it from there. Our Redbook SG24-2070 (due to go to the publishers this week) also covers this item. Ken Trowell ----- YEAR2000 CFORUM appended at 12:51:29 on 97/12/01 GMT (by HK at STUTVM1) <10403> Subject: Y2K Literature Ref: Append at 12:08:28 on 97/12/01 GMT (by DEGRZ417 at ELINK) For the operation of the clocks see the redbook SG24-2070 'S/390 Time Management and IBM 9037 Sysplex Timer'. You see it best from the redbook site http://www.redbooks.ibm.com and click on 'Redpieces' or directly from HTPP://www.redbooks.ibm.com/sg242070/y2000.html . Enjoy Herbert Kratzer ITSO Boeblingen ----- YEAR2000 CFORUM appended at 13:19:22 on 97/12/01 GMT (by CHALF82M at ELINK) <10404> Subject: Y2K Literature Ref: Append at 12:08:28 on 97/12/01 GMT (by DEGRZ417 at ELINK) GG66-3264 IBM 9037 Sysplex Timer and System/390 Time Management. This append was created on the External IBMLink system by Ciba-Geigy AG Basel Th.Kunovits System Programmer MVS Tel. 0041 61 697 67 16 Fax. 0041 61 697 47 28 ----- YEAR2000 CFORUM appended at 14:29:20 on 97/12/01 GMT (by LEOT at TOROVM1) <10405> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 19:03:17 on 97/11/28 GMT (by GAD at KGNVMC) A "known" problem is that any cleanup code that deletes "old" files may wipe ALL files going from YR 99 to YR 00, simply because any code that calculates the age of a file must take this into account - most cleanup routines I have looked at did not. Any other code (operating system/program products/customer programs) that uses dates (specifically the year) is likely to fail in an unpredictable way. A lot of programmers have used 97,98 and 99 as special indicators. (For example: 99 to indicate a date in the future.. This will fail in 1999, when the future suddenly arrrives..) Please also note that a system which is fully YR2000 compliant in the hardware, operating system and program products code levels is NOT automatically YR2000 ready. All customer programs MUST be checked for YR2000 compliance as well. YR2000 compliance in the base hardware and software only provides a basis for the customer programs that allows those programs to be made YR2000 ready. Leo Traarbach. ----- YEAR2000 CFORUM appended at 20:26:19 on 97/12/01 GMT (by ZAGORSKI at KGNVMC) <10406> Subject: Y2K Literature Ref: Append at 12:42:09 on 97/12/01 GMT (by TROWELL at WTSCPOK) Ken, Is there any way to get a softcopy of this redbook. If so please send it to zagorski at kgnvmc. Thank you. Mike Zagorski IBM Poughkeepsie LE Development ----- YEAR2000 CFORUM appended at 23:01:00 on 97/12/02 GMT (by FSTEPHEN at STLVM1) <10407> Subject: IMS 4.1 (DB only) compliance issues? Ref: Append at 13:20:30 on 97/11/21 GMT (by GBCDLV00 at ELINK) > 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. Yes, there is "likelihood" that a product supporting Local DL/I will be announced during the first quarter of 1998. For details one must wait for the formal announcement, although mention was made of this offering in the Supplemental Information Section of the recent Announcement of IMS V6.1. Steve Perry IMS Development ----- YEAR2000 CFORUM appended at 13:06:12 on 97/12/03 GMT (by GBCBHG00 at ELINK) <10408> Subject: customer's question 'what is a problem using non2000 year system' Ref: Append at 19:03:17 on 97/11/28 GMT (by GAD at KGNVMC) Greg, I understand that the comprehensive testing would be costly, and I am not suggesting that for a moment. What I was implying is that if their is any known information on why a particular peice of software or hardware is non-compliant then it would be graet to know about it. In some cases this information may have come from testing - in others it may be knowledge of the code. From a business perspective we have great difficulty in convincing that the effort and cost is justified to move off software. If we can say it definatelly won't work because of ..... we have hard evidance to support the need. 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 17:07:29 on 97/12/03 GMT (by GBCAMS01 at ELINK) <10409> Subject: EMIF and DASD isolation. Many previous appends have *strongly* recommended DASD isolation between Production and Y2K systems. What about using EMIF to define devices to either the Prod or Y2K LPARs using I/O device candidate lists ? Would this fall into the category of DASD isolation or is there a risk of data contamination in this situation ? This append was created on the External IBMLink system by Iain McArthur ANFIS plc GBVTFDPJ @ IBMMAIL 0141-275 9290 ----- YEAR2000 CFORUM appended at 17:48:09 on 97/12/03 GMT (by 36601943 at EHONE) <10410> Subject: European Monetary Union Is there a customer forum for EMU and EURO issues yet? (Is there an IBM internal forum?) Dougie Lawson, IBM Basingstoke, UK. (aka 8LAWSOD at NHBVM2) ----- YEAR2000 CFORUM appended at 13:26:29 on 97/12/04 GMT (by WOODHULL at RALVM17) <10411> Subject: Testing for Year 2000 DB2 Dates What tool can we use to over-ride the DB2 current date in PLI batch programs to simulate a future date (ie. 01/01/2000) ? We have been told to use a test tool called TICTOC, but this tool only overrides the PLI date - it doesn't let us modify the existing DB2 date. Does anyone have any suggestions for testing purposes ?? Gary Woodhull t/l 529-4909 (732)329-4909 WOODHULL at RALVM17 ----- YEAR2000 CFORUM appended at 19:19:23 on 97/12/04 GMT (by SBYCFLB at EHONE7) <10412> Subject: Testing for Year 2000 DB2 Dates Ref: Append at 13:26:29 on 97/12/04 GMT (by WOODHULL at RALVM17) Hi, If you're talking about SQL DATA/TIME service requests, Xpediter/Xchange from Compuware has support for this. It does require a ZAP to the DB2 database region. Since I haven't installed this support (zap) here, I can't say much about how it works though. George C. Berg - MVS systems programmer Ralphs Grocery Company - Compton, California ----- YEAR2000 CFORUM appended at 21:01:15 on 97/12/04 GMT (by TROWELL at WTSCPOK) <10413> Subject: EMIF and DASD isolation. Ref: Append at 17:07:29 on 97/12/03 GMT (by GBCAMS01 at ELINK) Yes I have seen a number of forum entries suggesting that you should isolate your production and Y2K DASD to prevent CONTAMINATION. But none of these forum entries have ever been clear on what the root cause of the contamination would be. Would it be DASD hardware failures, DASD method of operation at the CU, SCP software failures, or operational/procedure failures? The first one DASD failure just must not happen and this is not just for Y2K but for normal production. DASD method of operation, the only time the SCP 'in effect' sends a DATE to the DASD CU (and not to the DASD as data), is with the SPID. But for this to cause problems means that there would also have to be a hardware failure, and if it were the case then we would see see dynamic pathing problem, and this must not happen also for production systems that are normally sharing DASD. Now if you are concerned about the others and you really want to block SCPs from getting to the DASD, then yes you can, in an EMIF environment, where these DASD CHPIDS are defined as SHARED, use the HCD 'explicit' function against the production devices and not include the Y2K logical partition in the DEVICE CANDIDATE LIST. So my answer to you is yes you can use the EMIF explicit function, to isolate the production DASD for the Y2K partition. In answering you I am not saying that I support any of the reasons as to why you want to isolate these devices other than as safe practice and not because of hardware or software failures. Ken Trowell ----- YEAR2000 CFORUM appended at 13:08:09 on 97/12/05 GMT (by BEGENB09 at ELINK) <10414> Subject: Testing for Year 2000 DB2 Dates Ref: Append at 13:26:29 on 97/12/04 GMT (by WOODHULL at RALVM17) Gary, We are facing the same problem. I already asked a similar question on this forum. If you take a look at append #109 and related discussion, you may already get some answers. God Luck, Alex Breesch This append was created on the External IBMLink system by Alex Breesch Generale Bank Belgium Development Support tel. +32.2/565.43.44 fax. +32.2/565.24.20 e-mail: alex.breesch@gbank.com ----- YEAR2000 CFORUM appended at 13:47:08 on 97/12/05 GMT (by WFARRELL at KGNVMC) <10415> Subject: EMIF and DASD isolation. Ref: Append at 21:01:15 on 97/12/04 GMT (by TROWELL at WTSCPOK) Reply-To: wfarrell at ibmusm10 The contamination issue relates to dates in the VTOCs of the DASD volumes if you don't isolate them. Any DASD that the test system touches while it has a future date set may end up with DSCB entries, VVDS entries, etc. with that future date. If the production system then makes use of that DASD, it may decide to expire, delete, etc. the data which it considers very old (since it won't recognize the dates as future dates). Walt Farrell Internet: wfarrell@us.ibm.com IBMMAIL: USIB3H89 ----- YEAR2000 CFORUM appended at 17:59:48 on 97/12/05 GMT (by BLGIBSON at ATLVMIC1) <10416> Subject:COBOL74 experiences? We have already converted an application that had a number of COBOL74 programs and found the only issue we had to deal with was the ACCEPT DATE command. We windowed current dates and all else worked with no problems. Has anyone else out there renovated COBOL74 code and did you find anything other than ACCEPT DATE to be concerned over? I'd really like to exchange information on this matter. Thanks Bennie Gibson - IBM GS IT Architect - Atlanta, Ga. T/237-4576 ----- YEAR2000 CFORUM appended at 00:35:33 on 97/12/06 GMT (by TROWELL at WTSCPOK) <10417> Subject: EMIF and DASD isolation. Ref: Append at 13:47:08 on 97/12/05 GMT (by WFARRELL at KGNVMC) Yes I agree 100% with what you stated. I just was hoping that the people who keep on stating that there is 'contamination' would say what they think the reason is for the contamination, and to be aware that it is NOT hardware reasons as some of the appends have stated. In your case I would say it is operational reasons, that the devices belonging to a Y2K system should not be online to other systems and other system devices should not be online to the Y2K system. There are a number of ways to prevent this from the weakest way to the strongest way: 1. have the devices online but just don't use them - dangerous - still requires control over space allocations 2. have the devices placed offline by MVS - still weak as they can be brought online 3. have the devices defined offline to MVS in HCD - still weak as they can be brought online 4. define the device to the hardware (channel subsystem) but not to MVS (no no no) - no, please DO NOT do this, because if a device goes hot and sends in many interrupts it can effect the performance of the channel subsystem and MVS will not be aware of this situation (we have seen these cases where 1000s of I/O status presentations were made for 1 device each second for hours, no one is aware and the performance of the CPC dropped to less than 20%) 5. don't have the production devices defined to the Y2K hardware image and don't have the Y2K devices defined to the production images at the HARDWARE level (channel subsystem level) - it is very safe not to define the DEVICE to the hardware providing that if you are still accessing other devices on the same CU from this CPC that you have defined the CU address range correctly to HCD. - the only way that you can then get to this device, is by doing a Dynamic I/O reconfiguration change - for this case (5) it is OK to have the devices defined to MVS as MVS will never be able to get them online while they are not defined to the hardware *** this is the best PRACTICAL way of operating for Y2K testing ** PS If the device goes hot for this definition case, there will an IOS163 message. IOS163 message is a QUALITY MESSAGE not a quantity message (there is only 1 off them per device) and the customers as a normal practice should react to them 6. don't have any physical/logical connectivity to the the production devices from the Y2K hardware image and don't have any physical/logical connectivity from the Y2K devices from the production image - this may sound ok, but in an ESCON world it is very hard to do if all the devices are in the same physical location. So yes, I agree with isolation for Y2K testing, but there is a need to understand why this is the case, and then how to isolate. I am defending the hardware side and at the same time pointing out how I would recommend the devices be defined to H/W and S/W for Y2K testing. Ken Trowell ----- YEAR2000 CFORUM appended at 10:10:42 on 97/12/08 GMT (by 72437085 at EHONE) <10418> Subject: product readiness report for customer xyz After changes were made at November 17, 1997 I was not able to produce readiness reports for customers. The application tells me "Your browser might be turned off or might not be Java-enabled" and instructs me to download either Microsoft Internet Explorer or Netscape. After having downloded and installed Netscape and rebooted my system the same message appears. What is the problem with the readiness report application ? This worked before the named date. Thank you in advance. Horst Winkelmann ----- YEAR2000 CFORUM appended at 10:50:06 on 97/12/08 GMT (by 62479255 at EHONE) <10419> Subject: product readiness report for customer xyz Ref: Append at 10:10:42 on 97/12/08 GMT (by 72437085 at EHONE) Horst, Make sure that C:-JAVAOS2-DLL is in your LIBPATH statement and that C:-JAVAOS2-BIN is in your PATH statement. After my ThinPad platform changed, I was having the same problem and that fixed it. From a previous post in this forum: Look in your CONFIG.SYS and make sure that: LIBPATH includes x:\JAVAOS2\DLL PATH includes x:\JAVAOS2\BIN and that your CLASSPATH statement includes the njclass.zip file along with the other Java stuff. The default looks something like this: SET CLASSPATH=x:\NETSCAPE\njclass.zip;x:\javaos2\lib\jempcl10.zip;.- (Substitute x: in the above with the appropriate drives for Java and Netscape.) * Last week & this very same w/e I did an exhaustive Y2K compliancy study & all worked fine with me. Jan Vanbrabant, VANBRABJ at BRUVMIS1 ----- YEAR2000 CFORUM appended at 20:00:41 on 97/12/08 GMT (by DEAK at BLDVMA) <10420> Subject: Year 2000 testing options We have 2 large applications written in PL/I, Assembler, and VisualAge Generator, that use IMS/DC,DB and DB2 running in an MVS sysplex environment. Are there any options/tools avaiable for testing these applications that would negate the need for a Y2K LPAR? Is a Y2K LPAR the only option for thoroughly testing these applications and simulating the Year 2000? ----- YEAR2000 CFORUM appended at 22:00:23 on 97/12/08 GMT (by GGIESE at TORVM3) <10421> Subject: PC BIOS Upgrades. Hello, Is there a Year 2000 PC BIOS forum ? (I found a BIOS forum in the IBMPC conference, but no specific year 2000 forum). I am looking for tools or knowledge on how our client can identify their PC BIOS manufacturer (mostly IBM PC's) and how they can obtain BIOS upgrade kits for them. I understand that some local IBM BBS's contain BIOS upgrades, but are these upgrades available via the Internet ? Thanks Gordon Giese, ISM Year 2000 Project Manager (204) 941-2063 ----- YEAR2000 CFORUM appended at 16:25:51 on 97/12/10 GMT (by CWXN299 at ELINK) <10422> Subject: PC BIOS Upgrades. Ref: Append at 22:00:23 on 97/12/08 GMT (by GGIESE at TORVM3) > There is a site at http://www.computerexperts.co.uk/pc2000/ which offers a "PC TESTER FREE DEMO" I've downloaded it but not tested it. I think it's for DOS only. There are other useful links at www.year2000.com David Seibert (248) 737-7300 x 8441 Facs (248) 737-7564 DB Specialist, Rexxist ..... Compuware Corporation Dave_Seibert@Compuware.com or IBMMAIL(USSGNK96) ----- YEAR2000 CFORUM appended at 19:37:05 on 97/12/10 GMT (by WEINMANN at LEXVM2) <10423> Subject: Database Aging Tools for AIX/Oracle I would appreciate if anyone could point me to any tool(s) that I could use to "age" data contained in tables within an AIX/Oracle database environment. I want to be able to create "images" of my database with certain fields moved ahead (or possibly backward) in time to do Y2K testing. You can send replies to me off-line as follows: Internet mail -----> weinmann@us.ibm.com within IBM --------> WEINMANN@IBMUSM20 Thanks. Tim Weinmann ----- YEAR2000 CFORUM appended at 15:52:50 on 97/12/11 GMT (by V2KILLMC at CCPVM1) <10424> Subject: Year2000 Compatible We are running some ancient PLI programs, which in some cases haven't been re-compiled since there inception(mid 1975 forward). In some cases source was lost and in others we don't know if we have the current source. Would these programs have to be re-compiled to be compatible to the PLI PTF which address the resolve for the Yr2000 concern? The sources run in the hundreds and there wouldn't be enough hours in the next couple of years to accomplish. Thanks ----- YEAR2000 CFORUM appended at 16:13:29 on 97/12/11 GMT (by ELDERON at STLVM20) <10425> Subject: Year2000 Compatible Ref: Append at 15:52:50 on 97/12/11 GMT (by V2KILLMC at CCPVM1) They don't need to be recompiled, but they do need to be relinked after the PTF is applied. Peter Elderon ----- YEAR2000 CFORUM appended at 17:10:32 on 97/12/11 GMT (by IL68778 at ELINK) <10426> Subject: RPG II and RPG III solutions We're looking at Y2K solutions for RPG II on VSE and MVS and RPG III on AS/400. Namely, we'd like to find pointers to the following: 1. Impact Analysis tools 2. Tools for changing the code 3. Techniques: is Windowing practical in RPG? 4. Experiences, Stories (Success or Horror) Thanks in advance. Gilbert Saint-flour Automated Migration Services IBMMAIL(USS24LG4) IBMLINK(IL68778) ----- YEAR2000 CFORUM appended at 06:03:00 on 97/12/12 GMT (by ALANDP at SYDVMXA2) <10427> ..... YEAR2000 CFORUM modified at 06:22:40 on 97/12/12 GMT (by ALANDP at SYDVMXA2) <10428> Date: Fri, 12 Dec 1997 From: allanp@ibm.net We run VSE/ESA 2..1, CICS 2.3, DMS CICS/vs 1.4.1 and DOS COBOL/VS and DL/I. Due to some CICS assembler macro level code at the front of our system we could not migrate to DMS/CICS/vs 1.5. We have subsequently found out that even if we did DMS does not support COBOL/VSE exits and as such we canot use COBOL/VSE for our Y2K project ie migrate program from DOS COBOL to COBOL/VSE. We have looked at whether we could put in intermediate programs but this just adds to the effort. Fortunately there are no database redesign issues. New common date handling programs (CICS and batch) have been written. We have COBOL/VSE and LE/VSE installed for a VAgen project to rewrite part of the Insurance system above but this is proving to be quite a large task. We also cannot find a suitable course on COBOL/VSE and LE/VSE (N2027 looks good but it's for MVS?), this may allow us to fully appreciate just what we can do with the new COBOL. Any thoughts would be appreciated. How are other DMS CICS users handling the Y2K project. ----- YEAR2000 CFORUM appended at 13:45:45 on 97/12/12 GMT (by LPATON at GNKVM) <10429> ..... YEAR2000 CFORUM modified at 14:20:21 on 97/12/12 GMT (by LPATON at GNKVM) <10430> Subject: CMS LISTFILE Ref: None. | Received a HELPCMS offline, thanks. I don't have access to a Year2000 compliant version of CMS so would appreciate some help on this question. I am aware that LISTFILE has been updated with new operands...FULLDATE, ISODATE and SHORTDATE. However, what about the BEFORE and AFTER options ?. Have they been extended to an 8 digit date parameter or left as they are and use a windowing technique, or driven off the ISODATE etc operand or what ?. I would like to consider this when programming a LISTFILE command. Anyone have a CMS LISTFILE help they could send me which explains the y2k compliant version. Les Paton (InterNet les_paton@uk.ibm.com) ----- YEAR2000 CFORUM appended at 19:24:38 on 97/12/12 GMT (by VINING at RCHVMX2) <10431> Subject: European Monetary Union Ref: Append at 17:48:09 on 97/12/03 GMT (by 36601943 at EHONE) IBM LAUNCHES EURO WEB SITE October 30, 1997 http://www.europe.ibm.com/euro IBM has launched a web site that concentrates solely on the euro and the challenges and opportunities it presents to Europe's companies as they prepare for the Single Currency. John Downe, EMU Executive, explains the need for the site: "We are seeing a lack of corporate preparedness where euro is concerned. This site presents a gateway to a wealth of information on the euro (as well as its implications) and allows companies to compare their preparations against the knowledge that IBM has acquired through helping companies across various industry sectors prepare for euro". The site, which carries a mountain climbing theme, is divided into four main sections: o The Euro Centre: A valuable information source on the euro. This section is an evolving collection of articles, research, Q&As, implementation advice and useful links. o The Challenge: Provides a clear overview of the situation as it stands. There is a concise explanation of Economic and Monetary Union (EMU) as well as a timetable for implementation and an overview of how it will affect companies. o Equipment Check: The most daunting problem facing an executive tasked with preparing his/her organisation for euro is the diversity of business areas affected. o Your Guide: Explains the role that IBM can take in preparing a company to be competitive in the euro zone. IBM's four-phase approach, called EuroPath, is mapped out: Business Impact Assessment and Strategy Detailed Plans and Functional Requirements Implementation Other aspects examined by 'Your Guide' include the management of concurrent Year 2000 projects, education and training of staff, use of call centers for staff and customers and the development of industry specific solutions. IBM is regularly speaking at conferences and seminars, sharing its knowledge on preparation for the euro. A schedule of events is provided in this section. Perhaps the above is what you are looking for, Bruce ----- YEAR2000 CFORUM appended at 10:38:09 on 97/12/15 GMT (by 36601943 at EHONE) <10432> Subject: European Monetary Union Ref: Append at 19:24:38 on 97/12/12 GMT (by VINING at RCHVMX2) Nope. I found that. What I'm looking for is EURO FORUM or EURO CFORUM. Dougie Lawson, IBM Basingstoke, UK. (aka 8LAWSOD at NHBVM2) ----- YEAR2000 CFORUM appended at 15:24:50 on 97/12/17 GMT (by GBCBHG00 at ELINK) <10433> Subject: EMIF and DASD isolation. Ref: Append at 00:35:33 on 97/12/06 GMT (by TROWELL at WTSCPOK) Ken, On your first point as to 'the reason for the contamination', I agree that they are *probably* operational and not hardware related. However if you review this forum no-one has been able to quantify the reasons and risks. We therefore must er on the side of caution and must recommend isolation. On your second point of how to isolate how would you propose that this is done in an LPAR environment where all LPARS are on the one CPC and all DASD is on one subsystem ? We have to (under some circumstances) run in this configuration and see that only options 3 or 4 are valid. Option 3 is not secure enough (ie vols can be varied online) and I must admit untill your note I was not aware of the risk of option 4. Our situation is somewhat further complicated in that the software levels of our LPARs are at significant extremes, and the isolation is not just to guarentee integrity from date contamination but also for software contamination. Our production images are MVS/XA and MVS/ESA V3 the target Y2K images are OS/390 R3. In an environment such as this - what other alternatives are there apart from options 3 or 4. 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 23:43:52 on 97/12/17 GMT (by TROWELL at WTSCPOK) <10434> Subject: EMIF and DASD isolation. Ref: Append at 15:24:50 on 97/12/17 GMT (by GBCBHG00 at ELINK) Peter Use point 5 in my previous append. This rule (suggestion) has been there since 1981 when 370-XA came into being. The rule is if a CU is connection to a system always define the CU address range to correctly match the full address range that the CU can respond to. For the devices we would prefer to have both a subchannel in the hardware and a UCB in the software. But once you do that then someone can bring the non Y2K device online, which for the flow of this append, people do not want that to happen. So the reaction maybe to not provide the UCB, that is what I do not like, and have recommended people NOT do, since 1981. This is because if you have a UCW (subchannel) and NO UCB, then the subchannel will not be ENABLED by software. This being the case if I/O status is then presented it will cause the channel and channel subsystem to go through actions of finding out what to do with the status, this costs some time, but LOTS of time if it happens in the thousands. At the same time there is no architected way of reporting this. So no one is aware that it is happening unless it happens to impact performance then people ask, whats wrong ? There is an architected way of reporting this condition when this is no subchannel for the device, a CONFIGURATION ALERT CRW, and IOS will put out the quality message. Why this condition is not reported when the subchannel is there but disabled, is because this condition can occur when MVS goes though I/O recovery and 'boxes' a device, it (MVS) just does not want to hear from the device anymore. But when boxing the device MVS did inform the user. We expect customers to take an action for BOXED device messages, CONFIGURATION ALERT messages, MALFUNCTION ALERT messages, and HOT I/O recovery messages. Not just to look at them and say, "oh one of those". So your question, what to do? Use option 5 in my append. For EMIF shared devices use the HCD EXPLICIT function to 1. Control the device to be ACCESSED by a partition: include that partition in the EXPLICIT DEVICE CANDIDATE LIST ------ 2. Control the device to be NOT to be ACCESSED by a partition: do not include that partition in the EXPLICIT DEVICE CANDIDATE LIST ------ I underline DEVICE because there is a CHPID candidate list, and for the way you asked the question all the partitions would be in the CHPIDs ACCESS and CANDIDATE list. If a device is REACHABLE (another HCD term) from a partition, AND INCLUDED in the DEVICE CANDIDATE LIST there will be a subchannel build for the DEVICE (and useable when at least one path to the device is online). If a device is REACHABLE (the HCD term) from a partition, AND IS NOT INCLUDED in the DEVICE CANDIDATE LIST there will be NO subchannel build for the DEVICE. So for Y2K selective DASD device isolation on a Y2K and PRODUCTION shared CU, use the HCD device explicit function, to provide the isolation. We do not expect a DASD CU to be sending CU specific status as Device status on a path when a DEVICE does not have a path group to that system. The DASD CU is allowed to send CU specific status as CU status on a path using an offline device if there is a path group build on that path to at least one device on the CU. Sorry that the reply is so long but there are ramifications to everything that is done, and all this has been thought through over the years by the IBM central systems architecture groups, IOS designers and the IBM DASD CU designers. The idea is to have a correctly supported system recoverable to nearly (if not all) everything, ie have an answer to any, what if? There will be information going out on the Internet in the next few weeks on this subject. I/O isolation in a Y2K environment. Ken Trowell ----- YEAR2000 CFORUM appended at 00:02:34 on 97/12/18 GMT (by VMEGLER at SFOVMIC1) <10435> Subject: EMIF and DASD isolation. Ref: Append at 23:43:52 on 97/12/17 GMT (by TROWELL at WTSCPOK) Peter, I can vouch that everything Ken Trowell says is fact.... He knows the hardware and the microcode better than some of the designers do, and has been known to identify their bugs and tell them how to correct them! Hello, Ken! It's been a while! Remember channel path group id's at NAB with VM/XA sharing 3490's with other MVS's? Veronika Megler ----- YEAR2000 CFORUM appended at 11:04:23 on 97/12/18 GMT (by GBCBHG00 at ELINK) <10436> Subject: EMIF and DASD isolation. Ref: Append at 00:02:34 on 97/12/18 GMT (by VMEGLER at SFOVMIC1) Veronica and Ken, I don't doubt what Ken is saying either - I met Ken over 10 years ago in Australia in the AMP (Ken - not that you will neccessarilly remember me). At that time, and to this day, I consider Kens hardware knowledge to be the best I have experienced. The last append has a lot of detail which I will digest. My HCD knowledge is limited (basic migration of MVSCP/IOCP) and some reading is required. 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 13:22:30 on 97/12/18 GMT (by FUNSP at KULVM) <10437> Subject: Y2K testing & sharing an RVA subsystem Hi, I'm raising this same question on both the RAMAC forum as well as the Y2K forum. A customer of mine would like to know what is the best method to share the same RVA subsystem between a Y2K testing LPAR and a production LPAR. They have just installed an RVA subsystem and intend to share it between a 9672-R15 LPAR (for Y2K testing) and a 9121 LPAR (running a production MVS 5.2.2). It was explained to them that as long as the functional devices are defined as mutually exclusive to both LPARs, each of the LPAR will not see the other's devices and therefore cannot accidentally vary them online. This should be sufficient and save enough to prevent the Y2K testing from affecting the production environment (correct me if I'm wrong). They therefore plan to define the RVA as follows: 1) The first 128 devices (x00-x7F, for controllers with CUADDR=0 & 1) are defined to LPAR A. The other controllers and the remaining 128 devices are not defined to this LPAR (not even at HCD hardware or IOCP level). 2) The address range of x80-xFF (for controllers with CUADDR=2 & 3) are defined to LPARB only. Controllers with CUADDR=0 & 1 and the associated devices (x00-x7F) are not defined to LPARB (not even at HCD hardware or IOCP level). Any comments about this approach? Any better ideas? Thanks in advance, Fun ----- YEAR2000 CFORUM appended at 19:09:58 on 97/12/18 GMT (by ESAMBUC at CHGVMIC1) <10438> Subject: Y2K LPAR question (again ..) I reviewed the numerous forum discussion points on LPAR testing for Y2k and I agree that, given total DASD isolation, the separate LPAR is by far the best way to go. The question has been posed to me, though, of software expiration problems: if I IPL the LPAR for, say, 03/01/2002, might this trigger some security violation for a system-software license, say MVS or CICS? After all, our theoretical LPAR would have an image of current production object. Options: LOG YEAR2000 APPENDS SENDTO KGNVMC TOOLSMVS IBMMVS YEAR2000 CFORUM Subject: One MORE LPAR question ... ----- YEAR2000 CFORUM appended at 22:26:07 on 97/12/19 GMT (by CBS at SJEVM5) <10439> Subject: EMIF and DASD isolation. Ref: Append at 15:24:50 on 97/12/17 GMT (by GBCBHG00 at ELINK) The reasons why we in the storage systems divison recommend isolation are almost entirely operational and, if you're using even vaguely current hardware, are not hardware related (since the hardware is not sensitive to dates). As a general rule, we recommend that you not share storage systems between production and Y2K test systems. Most larger customers prefer to do that anyway, regardless of Y2K, to prevent test workload from impacting production workloads. The risk when sharing a subsystem is that it could be all too easy for an operational error to bring a test volume online to the production system. As Walt said, the production system might see a future date and do something unwise (or if the Y2K system saw an old date, it too might do something unwise). Equally, future dates might contaminate data in the production (not Y2K-tested) applications with potentially disastrous results. The costs associated with these potential accidents are far greater than the relatively trivial costs associated with obtaining more storage instead of sharing one box. Truly careful customers ensure that the Y2K test system is completely isolated from the production system and so has no physical links to it at all. If a smaller customer wants to shar a subsystem, I believe that using the capabilities of HCD to limit some volumes to particular partitions is the best way to proceed. One reason not to share a control unit is that service information messages are generally sent to only one host system. To get a full picture, you need to combine ERDS (LOGREC) data from all systems and that might not be a desirable thing to do with a Y2k and production system. More likely, SIMs could just get lost on the test system but they might be significant to the production system. I believe that we have changed the microcode so that SIMs are now sent to all systems, which reduces this 'problem'. Chris Saul, Storage Systems Division, San Jose http://saul.sanjose.ibm.com/ ----- YEAR2000 CFORUM appended at 22:29:35 on 97/12/19 GMT (by CBS at SJEVM5) <10440> Subject: One MORE LPAR question ... Ref: Append at 19:09:58 on 97/12/18 GMT (by ESAMBUC at CHGVMIC1) I don't know of any IBM software that expires in the manner that you describe but some non-IBM software most certainly does. You'd need to contact the vendors of that software to get an appropriate license code. Chris Saul, Storage Systems Division, San Jose http://saul.sanjose.ibm.com/ ----- YEAR2000 CFORUM appended at 22:30:47 on 97/12/19 GMT (by CBS at SJEVM5) <10441> Subject: Y2K testing & sharing an RVA subsystem Ref: Append at 13:22:30 on 97/12/18 GMT (by FUNSP at KULVM) I believe we dealt with this question in the other (IBM-internal) FORUM. Basically, what you propose would work (but is not what we advise; see other appends). Using HCD isolation would provide you with a greater level of granularity than CU-level but CU-level may be all you need. Chris Saul, Storage Systems Division, San Jose http://saul.sanjose.ibm.com/ ----- YEAR2000 CFORUM appended at 02:30:38 on 97/12/22 GMT (by PBAPETE at SYDVM1) <10442> Subject: EMIF and DASD isolation. Ref: Append at 23:43:52 on 97/12/17 GMT (by TROWELL at WTSCPOK) Ken, do you know the URL where this information will be placed??? Ian Peters, Enterprise Systems, Perth, WA ----- YEAR2000 CFORUM appended at 14:07:04 on 97/12/22 GMT (by GBCBHG00 at ELINK) <10443> Subject: EMIF and DASD isolation. Ref: Append at 11:04:23 on 97/12/18 GMT (by GBCBHG00 at ELINK) I think I have now got my head around using HCD to restrict access to devices at the hardware level using device candidate lists. Not only have I learned something new about HCD, but I have learned the same for native IOCP (ie non-HCD) - the use of PART/NOTPART on the IODEVICE statement to control same. However - and the subject may have to change here - the HCD device candidate lists and the IOCP PART/NOTPART statements appear to apply to shared channels only. In my case the controls need to be applied to both parrallel and escon. In our shop we have an OEM 3990-3 look-alike with 8 escon and 8 parrallel channels. Behind it are genned 256 devices (128x3380's and 128x3390-2's). On this subsystem we run 4 MVS images (A, B, Y2KA & Y2KB). Image A is MVS/XA, B is MVS/ESA V3, Y2KA is OS390 R3 and Y2KB is OS390 R3. We therefore need to isolate A & B from Y2KA & Y2KB for date contamination and software contamination. Images A & B reside on the first 32 addresses and are driven by the parrallel channels. Images Y2KA and Y2KB are on the rest driven by EMIF'd escon. All images reside on the one CPC. How can we define the devices such that images A & B can *ONLY* access the first 32 vols, and images Y2KA & Y2KB con *ONLY* access the rest. If I understand it correctly HCD device candidate lists and IOCP PART/NOTPART will not help in this instance. 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:39:08 on 97/12/22 GMT (by GBCAIH00 at ELINK) <10444> Subject: EMIF and DASD isolation. Ref: Append at 14:07:04 on 97/12/22 GMT (by GBCBHG00 at ELINK) Peter hi, If you are talking HCD you cannot define parallel and serial on the same control unit definition but that actually helps in this case. What we have done in a similar setup is to define 2 control units and use the chpid candidate lists to prevent reconfiguration of the chpids between lpars. The only other trick involved is to start the unit addresses on the second controller definition to match the real unit address. See the warnings about this type of setup earlier in the conference re SIM alerts etc. This append was created on the External IBMLink system by Mark Bentham Sema Group Outsourcing Reading 01189 642353 ----- YEAR2000 CFORUM appended at 04:37:45 on 97/12/23 GMT (by TROWELL at WTSCPOK) <10445> Subject: EMIF and DASD isolation. Ref: Append at 14:07:04 on 97/12/22 GMT (by GBCBHG00 at ELINK) There a number of conditions to be understood in answering this forum entry. IBM S/390 processors and the definition support (HCD) for the processors WILL support the attachment of different CU interface types (ESCON and Parallel) from a CU to CHPIDs (ESCON and Parallel) on the same processor. But to be able to use these different CU interface types at the same time from the same processor they have to be defined to different logical partitions and they must even be defined using different CU numbers, which when they (the CUs) are defined to the devices they must end up being in different logical CUs. Also use only ONE Device numbering scheme. Device number range to cover the all the devices on the CU can be device numbers xx00 to xxFF. For the Parallel CHPIDs (only to this OEM CU) define some of the Parallel CHPIDs to partition A in the ACCESS list. If you make these CHPIDS RECONFIGURABLE you should use a CANDIDATE list and limit the reconfigurability of all these CHPIDS to partition B (and A who is already in the access list). Define the rest of these Parallel CHPIDs to partition B in the ACCESS list. If you make these CHPIDS RECONFIGURABLE you should use a CANDIDATE list and limit the reconfigurability of all these CHPIDS to partition A (and B who is already in the access list). For the Parallel CU definition it is vendor dependent on how many CUs you define to support the 8 Parallel channel paths, and this will effect the path selection ROTATION order. As I do not know what it is for the OEM CU I am only using 1 Parallel CU definition for this reply. So put all 8 Parallel channel paths in this Parallel CU definition, and define the CU unit address and range as 00,256. For the devices you want accessible from partitions A and B on these Parallel channels and the Parallel CU, define the 3380 devices starting from device number xx00 for 32 (xx00,32). With the above definition only partitions A and B can access the first 32 devices on this CU and this will be via the parallel channels. For the ESCON CHPIDs define both partitions Y2KA and Y2KB in the CHPID ACCESS list and no other partitions in the CHPIDs, CHPID candidate list. For the ESCON CU definition it is vendor dependent on how many CUs you define to support the 8 ESCON channel paths, and this will effect the path selection ROTATION order. As I do not know what it is for the OEM CU I am only using 1 ESCON CU definition for this reply. So put all 8 ESCON channel paths in this ESCON CU definition, and define the CU unit address and range as 00,256. For the devices you want accessible from partitions Y2KA and Y2KB, on these ESCON channels and the ESCON CU, define the 3380 devices starting from device number xx20 for 96 (xx20,96) and define the 3390 devices starting from device number xx80 for 128 (xx80,128). You may leave the device explicit definition option as NO (in this case). Partitions A and B have no CHPID access therefore they do not need to be explicitly prevented from accessing these devices as the devices are not REACHABLE from those partitions. I think this entry should have gone in the MVSHCD forum not the YEAR2000 forum, as this is a I/O definition question not a Y2K question. Ken Trowell ----- YEAR2000 CFORUM appended at 12:55:31 on 97/12/23 GMT (by GBCBHG00 at ELINK) <10446> Subject: EMIF and DASD isolation. Ref: Append at 04:37:45 on 97/12/23 GMT (by TROWELL at WTSCPOK) Ken, Thank you for your comprehensive responses. The IOCP/MVSCP decks which are used for these devices effectively contain the definitions that you have - except that they do not specify CHPID Candidate lists. In this case that is acceptable, as to bring the devices online would require channel reconfig - not just device vary. As you have said CHPID candidate lists would ensure full isolation as LPAR A & B's CHPID's would not be able to go to LPAR Y2KA & B (nor visa versa). My confusion stemmed from the fact that although the CNTLUNIT defnitions specified the entire address range the IODEVICE statments did not. This led me to beleive that I would be missing UCB's. If I now understand correctly the IODEVICE definitions result in the full range of UCB's (xx00-xxFF) being generated on each MVS system with accessability to these devices controlled by the hardware at subchannel level. Again, thanks for your time and clarification. 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:51:52 on 97/12/23 GMT (by TROWELL at WTSCPOK) <10447> Subject: EMIF and DASD isolation. Ref: Append at 12:55:31 on 97/12/23 GMT (by GBCBHG00 at ELINK) Peter Point one. You are not saying what you are using to control the hardware device definitions for the processor, IOCP or HCD. I always make the assumption in todays day and age that people are using HCD, but I cannot tell clearly from your forum entries. Point two You have a mix of MVSs and OS/390 here. Your MVS/XA cannot be supported by HCD, it requires either an IOGEN (MVS/XA 2.1 if you are that old) or MVSCP (MVS/XA 2.2 and later). You then state IOCP/MVSCP, what is the IOCP deck being used for and why do you have one if all 4 MVSs and OS/390s are running on the same processor and the OS/390 partitions are HCD users (at least for the software device support). HCD would be the recommended way of supporting your I/O devices to the hardware on this processor. Your MVS/ESA system, is it 4.1, 4.2. 4.3 or 5.1 or 5.2, without knowing this again I do not know if you are a MVSCP user for your MVS/ESA system or a HCD user, 4.1 to 4.3 can be either. The I/O rule is: Define to an MVS image at LEAST what you have defined in the hardware partition that the MVS is running in. So if you max out each of your MVSs to 256 devices, and limit access at the hardware partition level to the devices you will be OK (as per what has been said before). But always have the CU defined as 00,256 to the hardware processor, for the ESCON CU(s) and the Parallel CU(s). Point three If you are using HCD to support your devices to MVS/ESA and OS/390 in the same IODF, are you then using the same CONFIG.ID for these systems or different ones. If the same CONFIG.ID then defining the 32 x 3380 devices in this CONFIG.ID, (for MVS/ESA) and then the 96 x 3380, plus 128 x 3390 in this CONFIG.ID (for OS/390), means that there will be 256 UCBs for MVS/ESA and OS/390. If different CONFIG.IDs are used (2, one for MVS/ESA and one for OS/390), then its up to you (if you want 256 UCBs) to define the 32 x 3380 to the correct LPARs but in both CONFIG.IDs and then define the 96 x 3380 plus 128 x 3390 to the correct LPARs but in both CONFIG IDs. For MVS/XA if you want the 256 devices put them in your MVSCP input file. I think these appends are going beyond a Y2K question and is becoming an education session in I/O definition in a mixed MVS and OS/390 environment for DASD. But hopefully these appends have answered all your questions in this area. Ken Trowell ----- YEAR2000 CFORUM appended at 17:01:11 on 97/12/23 GMT (by GBCBHG00 at ELINK) <10448> Subject: EMIF and DASD isolation. Ref: Append at 15:51:52 on 97/12/23 GMT (by TROWELL at WTSCPOK) Ken, Yes the information provided has answered all of my questions and has been quite enlightening. Although not directly related to Year 2000 I beleive that the information will be of direct relevance to those of us on Year 2000 projects who require to setup multiple MVS images with isolated HW configurations. Again thanks for your detailed responses and clarification. 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 17:08:54 on 97/12/23 GMT (by CBS at SJEVM5) <10449> Subject: EMIF and DASD isolation. Ref: Append at 17:01:11 on 97/12/23 GMT (by GBCBHG00 at ELINK) I'll repeat my advice that if this really is a 3990-3-type control unit, I believe that you are making a false economy and would be better served by getting another similar control unit and disk storage, which people would probably practically pay you to take off their hands. Older operating systems where you do not have the same control that you have with HCD just increase the chances of a costly mishap. Chris Saul, Storage Systems Division, San Jose http://saul.sanjose.ibm.com/ ----- YEAR2000 CFORUM appended at 09:54:23 on 97/12/24 GMT (by GBCBHG00 at ELINK) <10450> Subject: EMIF and DASD isolation. Ref: Append at 17:08:54 on 97/12/23 GMT (by CBS at SJEVM5) Chris, Your advice is well understood. The subsystem is a RAID subsystem emulating 3990-3 with large ammounts of storage. Unfortunatelly obtaining another (or its equivalent) are out of the question. One of the reasons for these discussions is to allow us to make informed decissions on the risks. The information I now have enables me to assess the risks and implement the best configuration on the equipment which is currently available to me. 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