----- YEAR2000 CFORUM appended at 07:44:03 on 98/05/04 GMT (by E085209 at EHONE) Subject: DASD CU and SIM destination. Ref: Append at 16:26:30 on 98/04/16 GMT (by CBS at SJEVM5) Hello Chris, I have gotten the following info from our account CSR. 3990-06 ECC89025C 9393-T82 EC Trb4.2.72.1 . Although these levels seem to be a latest GA level, we can see the SIM msg on only one system within the sharing ones. So, will the enhancement be deliverred in the future ? Thanks again for your help. Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 11:43:55 on 98/05/04 GMT (by 61821013 at VIEVM Subject: internal representation of dates (macros) on ES/9000 and AS/400 Hello, we got a question from one of our customers regarding the internal representation of dates in system-macros on these machines. Hermann Augesky Year2000 & EURO Conversion Centre IBM Austria ----- YEAR2000 CFORUM appended at 12:21:56 on 98/05/04 GMT (by GAD at KGNVMC) <1 Subject: internal representation of dates (macros) on ES/9000 and AS/400 Ref: Append at 11:43:55 on 98/05/04 GMT (by 61821013 at VIEVMA) The representation of dates from system services is OPERATING SYSTEM dependent, not processor dependent. For MVS (aka OS/390) this is clearly documented in the Assembler Services Reference in the TIME macro. There is no general answer to the question which you asked. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 07:01:47 on 98/05/05 GMT (by AS103767 at ELINK Subject: TOD, CPC, HMC and Datesource We are planning to start futur date testing in one LPAR that share a 9672-R35 with other curent date images. All OS390 systems. This CPC is connected to a sysplex timer with datesource installed. The Y2K system is XCFLOCAL with ETRMODE=NO. Our plan is to enter future date by oprator cmd at IPL time. Does this work properly for all applications like CICS and IMS? Or I have to use the datesource because CICS and IMS use the CPC time. Also do we need ICMF for single LPAR testing? Your comment is appreciated. This append was created on the External IBMLink system by Kamran Sedghi - Coles Myer LTD, Melbourne, Australia Tel: 61 3 9483 7361 Fax: 61 3 9483 7381 email:kamran.sedghi@colesmyer.com.au ----- YEAR2000 CFORUM appended at 17:08:08 on 98/05/05 GMT (by JDARDIFF at ATLVM Subject: Vendors for Products We are researching a list of products and am unsure who the vendor is for some of the software products that run on the mainframe. Could anyone tell me who the vendor is for some of these products so that we can write to them to find out if they are compliant. Any phone#s or addresses would also be great. Any compliance/testing experiences would also be appreciated. Product Name Vendor Name & Phone # or Address ------------- -------------------------------- CMF DSSUMON DSXMIT2 DRF ICP IOF IXFP POST SAMS:ALLOCATE SAMS:VANTAGE SOFTAUDIT SOLVE SOLVE;NETMASTER STOPX37 VPS VSAM AID VSAM I/O PLUS WSF2/CEF WSF2/ERD WSF2/ESP WSF2/EVT WSF2/STANDARD Thanks, Jeanne Ardiff JDARDIFF AT ATLVMIC1 JDARDIFF AT IBMUSM34 ----- YEAR2000 CFORUM appended at 18:08:31 on 98/05/05 GMT (by LGENDRON at KGNVM Jeanne, I can help you out some. I've listed some of the vendors owning the products in question. Contact can be found using the Global Software Solutions Guide at www.software.ibm.com/solutions/isv Product Name Vendor Name & Phone # or Address ------------- -------------------------------- CMF Boole & Babbage DSSUMON DSXMIT2 GE Information Services DRF ICP IOF IXFP storage technology POST " SAMS:ALLOCATE sterling software SAMS:VANTAGE " SOFTAUDIT ISOGON SOLVE Sterling Software SOLVE;NETMASTER " STOPX37 Boole & Babbage VPS Levi, Ray & Shoup VSAM AID VSAM I/O PLUS WSF2/CEF RSA Data Security WSF2/ERD " WSF2/ESP " WSF2/EVT " WSF2/STANDARD " ----- YEAR2000 CFORUM appended at 07:05:58 on 98/05/06 GMT (by SACCOS12 at ELINK Subject: Guide to setting up a Y2K LPAR Ref: Append at 11:56:17 on 98/04/29 GMT (by DKMAN06 at ELINK) I would like very much to have a copy of the Guide to setting up a Y2K LPAR. My ID: KHUNAIAR@ARAMCO.COM.SA Thanks alot This append was created on the External IBMLink system by Amira AlKhnaizi, System Programmer, Saudi ARAMCO internet id (KHUNAIAR@aramco.com.sa) ----- YEAR2000 CFORUM appended at 10:17:16 on 98/05/06 GMT (by CHAMC29H at ELINK Subject: Software Readiness Report: wrong PTFs mentioned? Product Readiness Report at yr2krept@wwwyr2k.raleigh.ibm.com seems me to present several Release-discrepancies, e.g.: 5685108 NETVIEW/FTP MVS 2.1.0 ("latest release") requires PTF UN99086 that refers to 2.3.0 5665397 SLR 3.3.1 ("latest release"): UN99689 for release 3.4.2 5668805 VS FORTRAN LIB 2.6 ("latest release"): UN99432 for rel. 6.0.2 ff 5668806 VS FORTRAN C/L 2.6.0 ("latest rel."): UN99527 for rel. 6.0.2 ff 5695176 IMS/ESA 5.1 ("latest release") lists several PTFs for rel. 1.5.4 (e.g. UN88640) or 1.6.0 (UQ08299) 5706254 QMF 3.2.0 points to PTF UN90791 that corrects another component (5668721) 5655018 CICS 4.1.0 list APARs ..., PQ14204, PQ14205 that can not be found in SIS. What are the correct informations for the above products? Thanks in advance. Peter This append was created on the External IBMLink system by Peter Rossel Bedag Informatik, CH-3012 Bern (Switzerland) Tel 0041 31-633,25,49 Fax 0041 31-633,26,36 ----- YEAR2000 CFORUM appended at 10:28:18 on 98/05/06 GMT (by CHAMC29H at ELINK Subject: Vendors for Products Ref: Append at 17:08:08 on 98/05/05 GMT (by JDARDIFF at ATLVMIC1) VPS: LRS D-63263 Neu-Isenburg (Germany), Phone +49 (0)6102/79 58-0 E-Mail frankfurt@lrs.com Regards, Peter. This append was created on the External IBMLink system by Peter Rossel Bedag Informatik, CH-3012 Bern (Switzerland) Tel 0041 31-633,25,49 Fax 0041 31-633,26,36 ----- YEAR2000 CFORUM appended at 10:43:25 on 98/05/06 GMT (by 36601943 at EHONE Subject: Software Readiness Report: wrong PTFs mentioned? Ref: Append at 10:17:16 on 98/05/06 GMT (by CHAMC29H at ELINK) Peter, You're confusing the LVLS/ keyword with the Version/Release/Modification- level. Taking IMS as an example. Program ID is 5695-176. Component id is 569517611 R154 is the DBRC component.(JMK5154) This is documented in LY27-9620-00 Diagnosis Guide and Reference (which you should have since you're licenced for IMS V5.1). By the way, for IMS look at UQ15198, UQ15199, UQ15200 and UQ15201 for year2000 support. Dougie Lawson, IBM Basingstoke, UK. (aka 8LAWSOD at IBMGB) ----- YEAR2000 CFORUM appended at 12:01:04 on 98/05/06 GMT (by ELIZAB at KGNVMC) Subject: Y2K App for OS/290 UNIX platform A customer asks: Is there a product such as Target/2000(for MVS) made by Targetfour Limited, for the OS/390 UNIX Platform which allows one to test an Application product for Year 2000 compatability(changing the system date and time) while other applications and users continue to use the current system time and date... Elizabeth Holland Kern ----- YEAR2000 CFORUM appended at 12:39:50 on 98/05/06 GMT (by CHAMC29H at ELINK Subject: Software Readiness Report: wrong PTFs mentioned? Ref: Append at 10:43:25 on 98/05/06 GMT (by 36601943 at EHONE) Thank you very much for the prompt reply. Peter. This append was created on the External IBMLink system by Peter Rossel Bedag Informatik, CH-3012 Bern (Switzerland) Tel 0041 31-633,25,49 Fax 0041 31-633,26,36 ----- YEAR2000 CFORUM appended at 05:00:34 on 98/05/07 GMT (by E085209 at EHONE) Subject: Guide to setting up a YR2K LPAR Hello, can I also share it ? If possible, would you pleaee send it to the following address ? E09506@jp.ibm.com Thanks. Best regards, Shigeki Kimura, IBM Japan, Ltd. ----- YEAR2000 CFORUM appended at 13:24:11 on 98/05/07 GMT (by IL68778 at ELINK) ..... YEAR2000 CFORUM modified at 13:26:30 on 98/05/07 GMT (by IL68778 at ELINK) Subject: The "magic bullet" is here! See today's IBM announcement letter 298-161 RUNTIME ANALYZER FOR MVS AND OS/390 AND MILLENNIUM RUNTIME WINDOWING TOOL FOR MVS AND OS/390 ASSIST IN YEAR 2000 ANALYSIS OF LOAD MODULES Most interesting feature, on line 22 of the announcement: o At runtime, finds and fixes most Year 2000 date problems. Seems like pure voodoo to me, but if it's written in an official IBM announcement letter, it must be true, right? It reminds me of some IBM marketing litterature, a few years ago that said: COBOL/370, the best solution to the Y2K problem. How long will it take IBM to correct the text of this announcement and make it a little more believable? Let's take some bets. Gilbert Saint-flour ----- YEAR2000 CFORUM appended at 01:43:06 on 98/05/08 GMT (by IL13128 at ELINK1 Subject: CADAM We have a customer that is running backlevel VM with backlevel CADAM. They are reluctant to do as I have suggested which is to upgrade the environment to Y2K compliant operating system and application software. They intend to backdate the system to (around) 1972. VM probably won't have any issues with doing that, but does anyone know if CADAM would survive? My concern is in the area of archiving and document retrieval. If they are date stamped, the system would not know what to do with a future archival date. Ray E Shaner ----- YEAR2000 CFORUM appended at 04:06:40 on 98/05/08 GMT (by DLEE at SJEVM5) < Subject: The "magic bullet" is here! Ref: Append at 13:24:11 on 98/05/07 GMT (by IL68778 at ELINK) I'm very involved in the development of both of the referenced Year2000 runtime products, so I thought I'd try to clarify some understandable confusion that might be out in the marketplace. First a warning - this is a rather long append but this is not a simple problem so the length is unavoidable. First I'd like to state clearly that IBM is NOT endorsing runtime solutions over traditional (and safer) source code solutions. But we do recognize that there are situations where traditional source code solutions are not practical and these situations are the intended market for the Millennium Runtime Windowing Tool (which I will refer to as MRWT - not an official acronym - simply to save a bit of typing). In fact we have done everything that we could to make MRWT remediated code be compatible with the Millinium Language Extensions for for COBOL and PLI so that our customers can get to a safer source code remediation base as quickly as possible. Now for a description of what MRWT is. MRWT is a fundamentally two step process 1) Date finding which is a 'runtime' (but iterative and involves user judgement) step to find S/390 instruction level instructions that are subject to Year2000 incorrect calcuations. 2) "Instrumentation" of the load module/load modules that will alter the functionality of the S/390 instructions that are subject to Year2000 incorrect calculations. I'll start with a very high level description of the date finding process. This process involves 'emulation' of the user application (in a test environment) under control of the MRWT 'hypervisor'. This process will be most efficient when the user can identify a large percentage of the dates at the source code level, but obviously the targeted user set for MRWT says that this will not be possible in many cases. The hypervisor has the ability to see the operand value of every executed instruction in the user's application. Keeping in mind that (from MRWT's perspective) a 'date' is a specific operand of a specific instruction in a user's load module, MRWT identifies dates in two ways (I'm simplifyng things here, but this is essentially a correct statement). 1) An operand of an instruction likely to be involved in a date mani- pulation has a value consistent with one of the date formats that MRWT understands (we are still working on exactly what this list of formats will be). These are 'marked' as suspect dates. 2) An instruction 'touches' an operand that references a storage location that currently contains a value that has been marked as a suspect or known date. For example a comparision operation (often either a 'CP' or 'CLC') where one operand is a known or suspect date will cause the other operand to also be a suspect or known date (assuming that it had no date status going into the instruction). Note that this gets a bit more complex in the case of a subtract operation where one operand being a date does NOT necessarily mean that the other operand is a date (it could also be a duration such as 'find the year that is n years prior to the year in operand #1'). There is alot going on here as date values 'walk though' (and get wiped out) memory and get referenced by other instructions, etc. But in the end the user is presented with a list of known and suspect dates for approval or rejection. When source code (or more precisely listings) are available, MRWT will reflect its findings at the source code level but obviously there will be many cases where this will not be possible. For those of you who have bothered to look at generated COBOL code you no doubt know how many compiler generated temporary variables (no direct source code equivalent) there are so the MRWT user will have to deal with base/displacement variable representations in all cases. The process is then repeated until additional interations yield no additional dates. At this point the date finding process is complete. MRWT now knows where all the 'dates' are (recall that a date is a specific operand of a specific instruction at a specific location in a load module). MRWT also knows the format of these dates. MRWT will then 'instrument' the user's load module with ITRAP instructions at each location involving an instruction subject to a Year2000 incorrect calculation. Now for a brief side trip into ITRAP and PROGRAM RESUME. ITRAP is a new instruction being released in the G5 machine (if you don't have the latest hardware all Year2000 ready levels of MVS will provide a first level interrupt handler that will simulate the instruction for you). This instruction is what I call a 'fancy branch' that will cause a direct transfer of control from the instrumented instruction (which was overlayed by MRWT as part of the remediation process) to the MRWT fixup area. The fixup area knows the overlayed instruction (ITRAP has architected support for this piece of the process) and knows the date format/formats involved. The MRWT fixup area then will window the affected operands prior to performing the instruction that was overlayed and then (when applicable) 'windown down' the results prior to returning control to the application via the new RESUME PROGRAM instruction (again with MVS simulation when you are not running on the latest hardware). To slightly overstate things this is like "bolting the Millennium Language Extensions (MLE) functionality directly onto your load module". I want to emphasize that this compatibility was intentionally and carefully designed to allow our customers to get to a permanent source code solution as quickly as possible. IBM is NOT recommending that users remediate their enterprise using MRWT. But we do recognize that there are cases where traditional source code solutions are not practical and this is the intended market for MRWT. Dave Lee IBM Software Group Santa Teresa Lab, San Jose, Ca. ----- YEAR2000 CFORUM appended at 08:08:26 on 98/05/08 GMT (by TROWELL at WTSCPO ..... YEAR2000 CFORUM modified at 21:42:31 on 98/05/08 GMT (by TROWELL at WTSCPO Subject: TOD, CPC, HMC and Datesource Ref: Append at 07:01:47 on 98/05/05 GMT (by AS103767 at ELINK) > We are planning to start future date testing in one LPAR that share a > 9672-R35 with other current date images. All OS390 systems. I assume you mean by future date testing, being a Y2K test date and time. > This CPC is connected to a sysplex timer with datesource installed. I assume that because you have a sysplex timer attached to this processor, that some of the images on this processor are part of a multisystem sysplex (so far so good). > The Y2K system is XCFLOCAL with ETRMODE=NO. So now, what I read that you are saying is (with some assumptions), that even though your installation is a multisystem sysplex installation you do not intend to run the Y2K OS/390 image as part of a multisystem sysplex. This is OK, as long as that is what you want, and IT WILL BE HOW I ANSWER THIS FORUM QUESTION. > Our plan is to enter future date by oprator cmd at IPL time. Does this > work properly for all applications like CICS and IMS? Or I have to use > the datesource because CICS and IMS use the CPC time. Also do we need > ICMF for single LPAR testing? Now a little confusion has crept into your forum entry, but this is what forums are about to clear up any misunderstandings. 1. Yes you can enter the date and time during the IPL process, and it is OK to do it that way. But not only must you understand how to get the date and time to a Y2K date and time but you must understand - your OS/390 CLOCKxx member option must include - PROMPT - what Y2K test date and time to enter - for OS/390 you MUST enter a ** GMT *** value not a Local value - don't reply with a local time, just use your a normal CLOCKxx TIMEZONE entry to get your correct local time offset. For 31/12/1999 in Melbourne that is EAST 11 hours - how YOU can get the Y2K test date and time back to the current date and time, for your Y2K HARDWARE IMAGE - the best way is to deactivate and then activate your Y2K image - what other actions will get it back to current date and time - powering off/on the 9672 - deactivating and then activating your 9627 CPC - activating your 9627 CPC - at the next IPL, if PROMPT is in effect Please be aware that once you have set this Y2K image to a Y2K test date and time, unless you do something to reset the date and time back to the current date and time, the date and time after the next IPL will still be a Y2K test date and time. But it will be advanced by the correct elapsed time since it was set. So if you set the Y2K test date and time to 12/31/1999 18:00 (GMT), then 48 hours later if you were to IPL, your Y2K image GMT time will be 1/2/2000 18:00 (GMT). 2. Your question. > Does this work properly for all applications like CICS and IMS? Or > I have to use the datesource because CICS and IMS use the CPC time. Some more confusion here. After the operator responds to the clock PROMPT with a ***** GMT ****** value (I hope you are understanding when I say a GMT value that you know what I mean, because I DO!!!!!!!! really mean a GMT value), the Y2K OS/390 system will the issue a SET CLOCK instruction and this will cause the Y2K logical images CPC TOD to be set to the operator entered Y2K test date and time value. This will have no effect on the 9672 CPC TOD (the real hardware one), therefore the other images on this processor are not effected by the Y2K test date and time change. If you do what I have stated (GMT GMT GMT GMT GMT), then yes, CICS and IMS will work with the Y2K test date and time. You could use the Sysplex Test Datesource feature, but two things you said makes it, that either you don't want to, you said "the operator will enter the time at IPL time" or you are missing a point, why use datesource to have a Y2K date/time and then have the operator change it again. Also the Sysplex Test Datesource feature is a must for a Y2K Multisystem sysplex, this is NOT you, because you stated that you are XCFLOCAL. 3, Your question > Also do we need ICMF for single LPAR testing? I am sorry I cannot resist in saying to you "what has this got to do with the price of Mars suntan coal". If I have confused you, well you have confused me with your question. ICMF is an option to give you a Sysplex CF function, sysplex, as in sysplex, as in sysplex, BUT ! you stated you were XCFLOCAL which is NON-SYSPLEX !!!. So the simple answer to this part of your forum entry is: NO ! You like all the requesters need my Y2K presentation. This WILL be placed on the INTERNET by next Wednesday. It is out on the INTRANET and can be obtained by IBMers 'http://wtscpok.itso.ibm.com/~redweb/s390tod' The following character ~ as shown before REDWEB in the above URL is a TILDE character. Ken Trowell ----- YEAR2000 CFORUM appended at 13:09:42 on 98/05/08 GMT (by NL5RCC03 at ELINK Subject: ISPF-variables In ISPF there are date-variables like ZJDAT, ZDATE, ZYEAR etc. ZYEAR gives the year in 2 digits, ZSTDY in 4 digits. ZJDAT and ZDATE also give the year in 2 digits, but for these two variables there are no equivalents that give the year in 4 digits. Is there a reason for this? (our version of ISPF: ISPF for Version 1 Release 3 of OS/390). Wim Holterman. This append was created on the External IBMLink system by RCC ----- YEAR2000 CFORUM appended at 13:34:23 on 98/05/08 GMT (by GAD at KGNVMC) <1 Subject: ISPF-variables Ref: Append at 13:09:42 on 98/05/08 GMT (by NL5RCC03 at ELINK) ZJDATE is replaced by ZJ4DATE and ZDATE by ZDATESTD. You need the fix for APAR OW28914 to get these variables. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 14:57:55 on 98/05/08 GMT (by ZOOT at KGNVMC) < >Subject: Y2K App for OS/290 UNIX platform > >A customer asks: > >Is there a product such as Target/2000(for MVS) made by Targetfour >Limited, for the OS/390 UNIX Platform which allows one to test >an Application product >for Year 2000 compatability(changing the system date and time) >while other applications and users continue to use the >current system time and date... > >Elizabeth Holland Kern Elizabeth, Did you ever get a response to this question? Try this web site for a list of ISV products that IBM maintains that the vendor (not IBM) claims to be Y2K-ready. This list includes apps, Y2K tools & services,... but might very well contain a test tool for UNIX. Maybe with some searching what's in there you'll find your answer. http://www2.software.ibm.com/solutions/ISV/Year2000.nsf Enjoy, Don Pizzuto ----- YEAR2000 CFORUM appended at 07:00:42 on 98/05/11 GMT (by AS103767 at ELINK Subject: TOD, CPC, HMC and Datesource Ref: Append at 08:08:26 on 98/05/08 GMT (by TROWELL at WTSCPOK) Hello Ken and thanks for your update. I think I didn't put enough detail but all your assumptions are correct. >- WHAT Y2K TEST DATE AND TIME TO ENTER >FOR OS/390 YOU MUST ENTER A ** GMT *** VALUE NOT A LOCAL VALUE >DON'T REPLY WITH A LOCAL TIME, JUST USE YOUR A NORMAL CLOCKXX > TIMEZONE ENTRY TO GET YOUR CORRECT LOCAL TIME OFFSET. >FOR 31/12/1999 IN MELBOURNE THAT IS EAST 11 HOURS >YOU COULD USE THE SYSPLEX TEST DATESOURCE FEATURE, BUT TWO THINGS YOU >MAKES IT, THAT EITHER YOU DON'T WANT TO, YOU SAID "THE OPERATOR >ENTER THE TIME AT IPL TIME" OR YOU ARE MISSING A POINT, WHY >DATESOURCE TO HAVE A Y2K DATE/TIME AND THEN HAVE THE OPERATOR >E IT AGAIN. ALSO THE SYSPLEX TEST DATESOURCE FEATURE IS A MUST In my note I meant enter y2k date by operator OR datesource. From your update I understand the real GMT date/time must be entered and not the local Melbourne time as GMT. Thank you again. This append was created on the External IBMLink system by Kamran Sedghi - Coles Myer LTD, Melbourne, Australia Tel: 61 3 9483 7361 Fax: 61 3 9483 7381 email:kamran.sedghi@colesmyer.com.au ----- YEAR2000 CFORUM appended at 18:58:33 on 98/05/11 GMT (by RATHOMAS at BOSTO Subject: Readiness Report Problem A customer informed me that when he tries to access the Product Readiness function, he gets an error message that states: APPLET Yr2KSwMain can't start. java.lang.NullPointer.Exception I know he's not the only one, because I saw the problem reported in RETAIN, but with no resolution. Any idea what's causing this and what he can do to fix it? Thanks. Rich Thomas (rathomas@us.ibm.com) ----- YEAR2000 CFORUM appended at 19:57:57 on 98/05/11 GMT (by CHO at CANVM2) <1 Subject: YYMMDD key field with COBOL Internal Sort Hello, my customer has a YYMMDD field as part of a sort key. I understand that DFSORT has a parameter to handle the 2-digit year. But the customer is invoking an Internal Sort from VS COBOL II. Is there a way to handle the 2-digit year please? Thanks in advance... Betty Cho - IBM Canada. ----- YEAR2000 CFORUM appended at 04:15:31 on 98/05/12 GMT (by AS103298 at ELINK Subject: TBSORTing date fields We have a number of applications that use TBSORT to sort variables containing a date field (in the format YY/MM/DD). Is there any way to ensure that TBSORT processes these fields correctly when we reach the year 2000 ??? Thanks, Sharron Dewhurst Westpac - Sydney This append was created on the External IBMLink system by Westpac Banking Corp ----- YEAR2000 CFORUM appended at 07:25:10 on 98/05/12 GMT (by HRKUMME at HAMBVM Subject: YYMMDD key field with COBOL Internal Sort Ref: Append at 19:57:57 on 98/05/11 GMT (by CHO at CANVM2) Betty, have a look at the DFSPARM dataset to override DFSORT parameters, this may accomplish what you want without touching the source. Bernd Kummer ----- YEAR2000 CFORUM appended at 08:22:58 on 98/05/12 GMT (by SIANNYG at SYDVM1 Subject: Guide to setting up a Y2K LPAR Ref: Append at 00:14:05 on 98/01/31 GMT (by TROWELL at WTSCPOK) Appreciate very much if you could send me a copy for the above subject. Thank you. Gandasasmita, Sianny Lotus Notes: SIANNYG@th.ibm.com ----- YEAR2000 CFORUM appended at 10:56:57 on 98/05/12 GMT (by 83816326 at EHONE Subject: Runtime Analyzer & MRWT for MVS & OS/390 Hello, I have just read the announcement letter 298-161 about these products and i would like to know about the relation they have with these other: VA COBOL MLE for MVS ( or for OS/390) VA PLI MLE for MVS The question is if it will be necesary to use these last products in order to get the advantages that it seems to provide the RUN TIME ANALIZER and the MILLENNIUM RUNTIME WINDOWING TOOL. Is the run time analizer independent of the other products?? or perhaps, first of all you need to use VA COBOL MLE and VA PLI MLE in order to mark dates????. Please, what will be the relation of these products with the windowing code you can get with the last ready versions of COBOL for MVS and PLI for MVS compilers??? I am working in a customer that is interested in all these subjects, and i have been attempting to try the MLE with the new versions of COBOL & PLI compilers, but I can not yet see results, because i need to use VA MLE Cobol and VA MLE PLI in order to active the new compiler options. I supposed ( and i was wrong) that it will be posible to mark the date fields manually. Please, I will thank any comment to clarify the relation among these products and the possibilities to get any avantage of them, isolated or together Thank you, very much ----- YEAR2000 CFORUM appended at 11:21:29 on 98/05/12 GMT (by GAD at KGNVMC) <1 Subject: Runtime Analyzer & MRWT for MVS & OS/390 Ref: Append at 10:56:57 on 98/05/12 GMT (by 83816326 at EHONE) These tools *DO* *NOT* require the Visual Age versions of the compilers. The fix capability they provide is COMPATIBLE with the MLE extensions of the VA compilers to allow for easy migration when you do have them and are ready to make source level changes. The tools work with programs compiled by several different levels of the compilers, including but not limited to the VA versions. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 14:20:32 on 98/05/12 GMT (by YAEGER at SJFEVMX Subject: YYMMDD key field with COBOL Internal Sort Ref: Append at 19:57:57 on 98/05/11 GMT (by CHO at CANVM2) Yes, you can use the DFSPARM data set to provide DFSORT control statements with Y2x formats and a fixed or sliding century window. For complete details on DFSORT's Year2000 features, including how to use them from COBOL, visit the DFSORT home page at URL: http://www.ibm.com/storage/dfsort/ or download my SORT2000 paper from the DFSORT FTP site at: ftp://index.storsys.ibm.com/dfsort/mvs/ Frank L. Yaeger - DFSORT Team (Specialties: ICETOOL, OUTFIL, Y2K :-) => DFSORT/MVS is on the WWW at http://www.ibm.com/storage/dfsort/ ----- YEAR2000 CFORUM appended at 02:14:34 on 98/05/13 GMT (by Y2KTSCAP at SYDVM Subject: TBSORTing date fields TBSORT does not use any data-typing so is unable to process a column as anything other than an ASCII string. The only clear solution is to expand the field to include the century. 2-Digit encoding could also be used where the year is converted from decimal to hex. 1900 + X'FF' = 1900 + 255 = 2155 eg 2000 is represented by '64' The problem with this is that you will have convert the dates as they are entered into the table and then interpret them when they are read. Year 2000 Technical Support Centre y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 10:05:47 on 98/05/13 GMT (by GBCDKT04 at ELINK Subject: TBSORTing date fields Ref: Append at 04:15:31 on 98/05/12 GMT (by AS103298 at ELINK) If you wish to sort YY/MM/DD in ascending order then (as long as the years are from 90 to 09) you can do it by sorting the first digit of YY as DESCENDing and then the second digit as ascending within that grouping Thus 9x will come before 0x, but 01 before 02, and 97 before 98, and 99 before 00. I know nothing about TBSORT, but the logic works for a PIPELINE sort. This append was created on the External IBMLink system by John Illingworth Systems Programmer Wm Morrison Supermarkets PLC Bradford, Yorks. 01274 362139 gbmorr04@ibmmail.com ----- YEAR2000 CFORUM appended at 10:55:10 on 98/05/13 GMT (by 73800362 at EHONE Subject: EREP MVS V3 R5, problems with 'period from to' dates Hello there, Customer recently installed MVS 5.2.2 that comes with EER3500 (erep for MVS). THey are performing y2k testing by setting the GMT clock to 2000.001. The software summary report, shows the following: REPORT DATE: 001 00 PERIOD FROM: 001 00 TO: 124 98 The period seems to reversing the years. Is there an apar that addresses this? As well, on the 'Physical Error Report', the dates are: REPORT DATE 001 00 PERIOD FROM 001 00 TO 001 00 But the Date indicates 124/98. Meaning the information being displayed is for 124/98 instead of 001/00. Please advise, thanks. Lena. ----- YEAR2000 CFORUM appended at 11:25:51 on 98/05/13 GMT (by GAD at KGNVMC) <1 Subject: EREP MVS V3 R5, problems with 'period from to' dates Ref: Append at 10:55:10 on 98/05/13 GMT (by 73800362 at EHONE) To my knowledge, it was decided that no changes would be made to EREP in support of year 2000. It was understood that reports would be strange across the 1999/2000 boundary but that was decided to be acceptable. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 13:26:02 on 98/05/13 GMT (by Y2KTSC5 at SJEVM5 Subject: Readiness Report Problem Ref: Append at 18:58:33 on 98/05/11 GMT (by RATHOMAS at BOSTON) Have your customer report the problem accessing the Product Readiness Database according to the following information: To report problems experienced with the Year 2000 Readiness Application, contact the help desk in the United States at (919) 254-2100 or send e-mail to RTPAIX@us.ibm.com and mention "Year 2000 application" in the subject line. (Internal NOTES users can send notes to: RTP.AIXHELP@VM) When reporting a problem by phone or e-mail, please provide the following information: Your name and telephone number Your e-mail address Location (URL) the problem is occurring on Make of web browser (i.e. Netscape, IE) and browser version number Description of the problem by trying to answer the following questions: 1.What is the problem? 2.Is any message being displayed? 3.What message is appearing in the status line of the browser? 4.Does the problem occur EVERY time the application is accessed? 5.How long does it take before the error appears? 6.Have you been able to successfully use other Java applets? Questions on the Year 2000 readiness of specific products not available i in the Readiness Application or questions on the reports produced by this application should be direct to the IBM Year 2000 Technical Support Center Year 2000 Technical Support Center (TSC5) ----- YEAR2000 CFORUM appended at 15:49:38 on 98/05/13 GMT (by Y2KTSC3 at SJEVM5 Subject: YYMMDD key field with COBOL Internal Sort Ref: Append at 19:57:57 on 98/05/11 GMT (by CHO at CANVM2) >Hello, my customer has a YYMMDD field as part of a sort key. >I understand that DFSORT has a parameter to handle the >2-digit year. But the customer is invoking an Internal Sort >from VS COBOL II. Is there a way to handle the 2-digit >year please? The easiest way is to use the newer compilers and the Millennium Language Extensions. When you define a SORT key as DATE FORMAT YYXXXX you will get a windowed date field sequence from the SORT. Millennium Language Extensions are not available in VS COBOL II, but your programs will compile without change using the newer compilers. For more info: http://www.software.ibm.com/ad/va2000/va2kmle2.htm You can also do it manually using your own SORT control statements, see the DFSORT web page at: http://www.storage.ibm.com/storage/software/sort/srtmy2p.htm Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 01:35:53 on 98/05/14 GMT (by 73800362 at EHONE Subject: EREP MVS V3 R5, problems with 'period from to' dates Ref: Append at 11:25:51 on 98/05/13 GMT (by GAD at KGNVMC) When you say that the 'strange erep' reports are acceptable, am I to assume that the contents are correct? Just the dates are wrong? For instance, when the report reads 'PERIOD FROM 001.00 TO 124.98', the information is 'not' from Jan 01 1900 to May 04 1998. But instead May 04 1998 to Jan 01 2000? Correct? THis is extremely important. Please advise, thanks. Lena. ----- YEAR2000 CFORUM appended at 03:14:56 on 98/05/14 GMT (by MSHEWELL at SYDVM Subject: EREP MVS V3 R5, problems with 'period from to' dates Ref: Append at 01:35:53 on 98/05/14 GMT (by 73800362 at EHONE) Lena, When using Environmental Report Editing and Printing (EREP) (EREP for OS/390 and MVS (5658-260); EREP for VSE (5656-260); and EREP for VM (5654-260) ), to produce reports where the records have been created in both 1999 and 2000, special handling is necessary to prevent problems and minimize customer impact. Because EREP data on a single LOGREC tape spans a relatively short period of time, be aware of the following limitations when processing EREP reports which include both 1999-December-31 and 2000-January-1. o Input of the DATE parameter is restricted to a 2-digit-year specification. If you do not use the DATE parameter, and the data on a given LOGREC tape includes from both 1999-December-31 and 2000-January-1, the output is sorted with data from the year 1999 after the data from the year 2000. o EREP does not properly process date selection if the range includes both 1999-December-31 and 2000-January-1. Therefore, if you desire to select report entries for such a range, you must create two reports. On the first report specify "DATE=(yy.ddd,99.365)" and on the second report specify "DATE=(00.001,yy.ddd)". Regards, Mark. Year 2000 Technical Support Centre - Asia Pacific. y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 08:11:57 on 98/05/14 GMT (by 83816326 at EHONE Subject: Trying MLE Hello, My environmet is the following: OS/390 V2R2 LE 1.6 COBOL FOR MVS & VM V1 R2 (with PTFs to de ready to use MLE and get windowing code) PLI for MVS &VM Our customer is interested in trying MLE, but they would like to see results in some program application before buying the VA COBOL MLE for MVS & VM and VA PLI MLE for MVS & VM We have marked the date fields in data structures in a program source code and the program is all right compiled while you have inactived new options(ie. NORESPECT,WINDOW) But if you active these options you get the following message at compile time: IEL0900i U The PL/I millennium language extension (mle) product must be installed and accessible to the compiler to use RESPECT(DATE) compiler option. Compilation Terminated It means you need to have VA COBOL MLE and VA PLI MLE products installed in order to try MLE advantages, but it is difficult to say that they must have the products before see some testing. Please, do you Know if there is a posibility to simulate the use of this products before to buy them? I know that it is imposible to get them in demo. Thank you very much for any comment about. ----- YEAR2000 CFORUM appended at 12:50:34 on 98/05/14 GMT (by GBCAGE94 at ELINK Subject: Withdrawal of Non-Year 2000 ready products IBM Have just issued an announcement letter detailing products to be withdrawn from marketting as they are not Year 2000 ready. There are over 5000 products across all platforms being withdrawn. The announcement letter is ZP98-0359 I would like clarification of what "Non-Year 2000 ready" actually means. Is it known that the products ** will not work ** ? Or is it that they have just not been tested ? Or are there other criteria ? The reason for the question is based upon a previous series of questions in this same forum (appends 129, 130, 131, 132, 137 & 140) which were along the lines of; If the product won't work then we have to upgrade, however if the product may work we have to do risk assesment to determine if we should upgrade. We need the information to make informed choices. In some cases it may not be possible to upgrade, although it may be desirable. This append was created on the External IBMLink system by Peter Gammage Email: peter_gammage@standardlife.com Standard Life Phone: (UK) 0131-245-7024 ----- YEAR2000 CFORUM appended at 15:06:54 on 98/05/14 GMT (by BROOKS at SJFEVMX Subject: Withdrawal of Non-Year 2000 ready products Ref: Append at 12:50:34 on 98/05/14 GMT (by GBCAGE94 at ELINK) > The announcement letter is ZP98-0359 How can I get a copy of this announcement letter? cheers... Russ BROOKS at SJFEVMX 8-276-0158 (aka: rlbrooks@pobox.com) ----- YEAR2000 CFORUM appended at 15:46:28 on 98/05/14 GMT (by WMORGAN at SFOVMI Subject: Withdrawal of Non-Year 2000 ready products Ref: Append at 15:06:54 on 98/05/14 GMT (by BROOKS at SJFEVMX) All IBM Announcements are publicly available off of the IBM web page at http://www.ibm.com. Click the 'NEWS' tab and then click Announcements. In fact, this particular one is highlighted on the page under Withdrawals. But, one can search for any letter Bill Morgan WMORGAN at SFOVMIC1 ----- YEAR2000 CFORUM appended at 20:31:32 on 98/05/14 GMT (by WILL at RALVM6) < Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 20:15:52 on 98/02/25 GMT (by GAD at KGNVMC) <10432> This is in reference to Gregs answer concerning the GMT clock in LPAR a few months back. I'll paste the answer since it came from a February append. "Any program running in a LPAR partition will *always* get the time associated with that partition. Many people say they use the "physical" time in the processor, when they mean they are using STCK to obtain it. This, however, always returns the partition logical time which *is* the physical time as far as that partition is concerned." Sorry to be going backwards in time here, but does the same apply in regards to the logical GMT clock when running as a guest image under a VM/ESA host as with running in LPAR? In other words, from a logical GMT clock perspective, is running a Y2K test under a VM guest the same as running under LPAR. As I understand, the logical GMT clock presented to the VM guest works in the same manner as the logical clock presented to an LPAR image. Each VM guest runs off a logical GMT clock that can be changed at the guest level only effecting that guest.Similar to the 9672 Datesource function, with VM/ESA 2.3.0 we can also use the VM CP SET VTOD command to sync the logical GMT clocks between the guest images, useful for Y2K testing under VM. Thanks for any clarification. Will Patton ----- YEAR2000 CFORUM appended at 15:15:37 on 98/05/17 GMT (by IL68778 at ELINK) Subject: Withdrawal of Non-Year 2000 ready products Ref: Append at 15:46:28 on 98/05/14 GMT (by WMORGAN at SFOVMIC1) > > All IBM Announcements are publicly available off of the IBM web > page at http://www.ibm.com. > Click the 'NEWS' tab and then click Announcements. In fact, > this particular one is highlighted on the page under Withdrawals. I did this and found a "Hardware Withdrawal - Non Y2K-ready products" letter which lists a few dozen PC and other hardware products, not the 5000 software products I was expecting. > But, one can search for any letter I searched for ZP98-0359 and go no hits. Where is it? Gilbert Saint-flour ----- YEAR2000 CFORUM appended at 03:48:17 on 98/05/18 GMT (by JFRANCIS at GDLVM Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 20:31:32 on 98/05/14 GMT (by WILL at RALVM6) >Sorry to be going backwards in time here, but does the same apply in >regards to the logical GMT clock when running as a guest image under >a VM/ESA host as with running in LPAR? In other words, from a logical >GMT clock perspective, is running a Y2K test under a VM guest the same >as running under LPAR. > >As I understand, the logical GMT clock presented to the VM guest works >in the same manner as the logical clock presented to an LPAR image. Each >VM guest runs off a logical GMT clock that can be changed at the guest >level only effecting that guest.Similar to the 9672 Datesource function, >with VM/ESA 2.3.0 we can also use the VM CP SET VTOD command to sync the >logical GMT clocks between the guest images, useful for Y2K testing Your understanding is correct. Although it may appear that a guest is obtaining the real TOD clock when issuing a STCK instruction, VM/ESA's guest architecture applies the virtual machine's clock offset when a guest issues a STCK. This permits multiple guests to be running under the same VM host system, each with a different "virtual" date/time setting if desired. John Franciscovich VM/ESA Development ----- YEAR2000 CFORUM appended at 08:12:02 on 98/05/18 GMT (by NLX5958 at NLVM1) Subject: Withdrawal of Non-Year 2000 ready products Ref: Append at 15:15:37 on 98/05/17 GMT (by IL68778 at ELINK) > I searched for ZP98-0359 and go no hits. > Where is it? "P-letters" are an EMEA form of announcement. In the USA, they issue "Ivory Letters" with a totally different numbering scheme. You will only be able to find the items you want by a subject/keyword search. Alan Hakim, IBM Nederland. ----- YEAR2000 CFORUM appended at 09:07:07 on 98/05/18 GMT (by 36601943 at EHONE Subject: Withdrawal of Non-Year 2000 ready products Ref: Append at 15:15:37 on 98/05/17 GMT (by IL68778 at ELINK) Gilbert, I found this in the USAnnouncement system. I think it is the Ivory letter equivalent to EMEA plet ZP98-0359. NUMBER 998-126 DATE 980512 CATEGORY LS00, GD00, WS00, CM00, GI99 TYPE Withdrawal Dougie Lawson, IBM Basingstoke, UK. (aka 8LAWSOD at IBMGB) ----- YEAR2000 CFORUM appended at 11:51:47 on 98/05/18 GMT (by MORT at PK705VMA) Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 20:31:32 on 98/05/14 GMT (by WILL at RALVM6) As a followup to John's append, I would just mention that this STCK offset is the same technique that LPAR uses for independent clocks. So running under VM/ESA or under LPAR is pretty equivalent as to the TOD clock appearances. However, VM/ESA might open up a few more "holes" possible to the VM/ESA clock. There are certain DIAGNOSE commands that you could issue from the guest image that might indicate the time as VM/ESA knows it (which is the time associated with its logical partition, since you mentioned VM/ESA is running in an LPAR). I hesitate to mention this, because it doesn't seem like a big deal - there isn't too much chance that this would contaminate your guests, as these privileged DIAGNOSE instructions wouldn't be too accessbile (and only accessible when running under VM/ESA). However, I just wanted to mention a possible difference in the belief that information is always a good thing. Eric Morton P/390 microcode ----- YEAR2000 CFORUM appended at 16:08:37 on 98/05/18 GMT (by HACK at YKTVMV) < Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 11:51:47 on 98/05/18 GMT (by MORT at PK705VMA) <10596> Well, the issue is relevant to CMS users, because CMS uses DIAG X'00C' for most purposes -- but uses STCK to determine the TOD value expected at local midnight. I don't know of any consequences of a possible mismatch -- I have run CMS with nonstandard TOD from time to time, but usually only relatively briefly while bootstrapping another system. Another difference is between Rexx and EXEC 2. Rexx uses DIAG X'00C' as the source of its time() and date(), but EXEC 2 uses STCK for &TIME and &DATE. Michel. ----- YEAR2000 CFORUM appended at 17:16:38 on 98/05/18 GMT (by MORT at PK705VMA) Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 16:08:37 on 98/05/18 GMT (by HACK at YKTVMV) Yes, I was referring to the possibility of it corrupting MVS or VSE guests as being slight, since I haven't heard of anyone running CMS under LPAR! (If you've done it Michel, you can spare the horror stories...) Eric ----- YEAR2000 CFORUM appended at 18:47:45 on 98/05/18 GMT (by HACK at YKTVMV) < ..... YEAR2000 CFORUM modified at 22:47:38 on 98/05/19 GMT (by RAINBOLL at ELINK Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 17:16:38 on 98/05/18 GMT (by MORT at PK705VMA) <10598> fsddfafsasdfasfsfsafsd on CP (i.e. incapable of running stand-alone) since about 1971, so there's indeed no worry about CMS running directly under LPAR. My comments were with respect to the similarity of TOD virtualisation between LPAR and VM. Some operating systems other than CMS are aware of VM, and can use some CP services (e.g. paging assistance) when they detect running in a virtual machine. There exists the *possibility* of having authorised programs that know about VM, and *might* use DIAG when available. ----- YEAR2000 CFORUM appended at 09:42:10 on 98/05/19 GMT (by GBCDKT04 at ELINK Subject: Which Clocks informations can a program get in a Year2000 LPAR ? Ref: Append at 18:47:45 on 98/05/18 GMT (by HACK at YKTVMV) If you want to test CMS for Y2K without using LPAR then it must be under a second level VM system which has OPTION TODENABLE in its directory and has set date and time when it is IPLed. Any DIAG from that CMS will only go to the second level CP which will have a shifted date. This append was created on the External IBMLink system by John Illingworth Systems Programmer Wm Morrison Supermarkets PLC Bradford, Yorks. 01274 362139 gbmorr04@ibmmail.com ----- YEAR2000 CFORUM appended at 09:45:19 on 98/05/25 GMT (by 73800362 at EHONE Subject: Y2K readiness for products. Can you tell me if the follwoing products are y2k ready: 1. 5668-989 4700 Host Support (HFS1902) 2. 5668-935 RM4700 (HMR1202) Thanks. ----- YEAR2000 CFORUM appended at 18:52:39 on 98/05/25 GMT (by 62479255 at EHONE Subject: DCAF and IBM Hardware. Ref: Append at 13:16:27 on 98/04/15 GMT (by AS103187 at ELINK) Hi John, Now YOU remain even silent ... Did you ever get an answer? Or is it still "under research"? Jan Vanbrabant, VANBRABJ at BRUVMIS1 ----- YEAR2000 CFORUM appended at 22:33:44 on 98/05/25 GMT (by AS103187 at ELINK Subject: DCAF and IBM Hardware. Ref: Append at 18:52:39 on 98/05/25 GMT (by 62479255 at EHONE) ello Jan >Did you ever get an answer? Not yet >Or is it still "under research"? I sincerely hope so. I suppose it is time to rattle the cage of IBM Oz again. We have been told that IBM stands by its statement that these systems are Y2K ready. I also beleive that IBM will address the issues. What I haven't been told is when! Cheers, John P.S. It would have been nice if someone from the labs for both 3745 and S390 had been able to append here. This append was created on the External IBMLink system by John Johnston phone +61 2 9902 5910 Technical Consultant (VTAM and NCP Sysprog) fax +61 2 9902 5111 Westpac Banking Corporation______________internet jjohnston@westpac.com.au Sydney, Australia ----- YEAR2000 CFORUM appended at 02:01:50 on 98/05/26 GMT (by ALANDP at SYDVMXA Subject: Y2K readiness for products. This is an extract from the summary report of the Year 2000 status of these products. PRODUCT READY REPLACEMNT NUMBER PRODUCT DESCRIPTION STATUS RELEASE PRODUCT ------- ------------------------- --------- ------- ---------- 5668935 4700 CONTROLLER RESOURCE NOT READY 1.4 5668753 5668989 4700 FINANCE COMM. SYSTEM READY*# 9.0MVS/9.0VSE If you would like a full Product Readiness Report or some more information, please contact the Year 2000 TSC at the address below. Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 09:00:26 on 98/05/26 GMT (by 62479255 at EHONE Subject: DCAF >< Year2000 Hi, I would like to revitalize the question: "What about DCAF & Year2000?" Strange things happen: - first DCAF is superseded by TME 10 Remote Control - then annt. letter ZA98-0143 of March 10 announces with big fanfare that TME 10 Remote Control is now Year2000 ready. How? By NOT including anymore the non-year2000-ready code of DCAF ³³³ The other way around, this means that DCAF = NOT year2000 ready. - next annt. letter ZA98-0218 of 7 May about the G5 9672 remarkably says Please note that the DCAF product can no longer be ordered and is no longer supported, but existing DCAF controllers can still be used. - and finally ZP98-0359 of 12 May withdraws from mktg more than 3000 products which are not Year2000-ready with the effective withdrawal date being August 12 of this year. Under them: DCAF My simple question is: ---------------------- When will we, IBM/TIVOLI, come out with a firm plan for a supported + a Year2000-ready product? Not only for the S/390 servers, but also for 3745/3746, ESCON directors,... I append this in the YEAR2000, HCD and TIVOLI forum's; I prefer answers in YEAR2000. Jan Vanbrabant, VANBRABJ at BRUVMIS1 ------------------------------------ Extract from the announcement letter "New IBM S/390 Parallel Enterprise Servers - Generation 5 (TM) Models" (LETNO ZA98-0218 DATE 980507) REMOTE OPERATIONS: The System/390 Parallel Enterprise Server and Coupling Facility hardware systems management products support remote operations in a variety of ways over a variety of communications connections. In each case, the objective is to enable a human or programmed operator to monitor or control a remote system in essentially the same manner as if the operator were at the same site as the remote system. Remote operations include: o Hardware Management Console Operation of S/390 Parallel Enterprise Server - Generation 5, using: - An SNA protocol flowing over either a Token-Ring or Ethernet LAN, or - A TCP/IP protocol flowing over either a Token-Ring or Ethernet LAN. The systems connected by these LANs may be distributed over any geographic extent supported by interconnected LANs. This provides ideal support for consolidating the operation of remote data centers using existing networks. This is the suggested option for continuous remote operation of S/390 Parallel Enterprise Server - Generation 5 systems. o Remote manual operation of a Hardware Management Console: The Hardware Management Console may be remotely operated over SDLC, Token-Ring, or Ethernet connections using either SNA or TCP/IP protocols, by utilizing the target portion of the integrated Distributed Console Access Facility (DCAF) product. To use this option, a personal computer is required with OS/2, Communications Manager/2 (CM/2) or TCP/IP support, and the controller portion of the DCAF product. Please note that that the DCAF product can no longer be ordered and is no longer supported, but existing DCAF controllers can still be used. ----- YEAR2000 CFORUM appended at 13:06:48 on 98/05/26 GMT (by IRENEG at DKIBMVM Subject: Y2K Product Readiness Question from customer - Are product numbers 5771-ABA SONORAN SERIF 1.1.2 ( HZC1200 ) 5771-ABB SONORAN SANS SERIF 1.1.2 ( HZD1200 ) both Y2K READY. The Y2K Product Readiness Database only shows information about Rel 1.2.0 Irene Groendahl / Y2K Team IBM Denmark ----- YEAR2000 CFORUM appended at 08:00:20 on 98/05/27 GMT (by ALANDP at SYDVMXA Subject: Y2K Product Readiness > Question from customer - > > Are product numbers 5771-ABA SONORAN SERIF 1.1.2 ( HZC1200 ) > 5771-ABB SONORAN SANS SERIF 1.1.2 ( HZD1200 ) > both Y2K READY. > > The Y2K Product Readiness Database only shows information about > rel 1.2.0 These products do not use dates so there are no Year 2000 issues with them. This applies to all versions including 1.2.0. Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@au1.ibm.com ----- YEAR2000 CFORUM appended at 17:26:15 on 98/05/28 GMT (by JJACOB at TOROVM1 Subject: Tool to get software and hardware inventory of PC's One of the things I am involved in my customer is year2000. We need an inventory of the PC's. Is there a tool, preferible unser DOS boot diskettes that will give me hardware and software inventory? Jose L. Jacob jacob@vnet.ibm.com (905)316-3228 tl886