----- YEAR2000 CFORUM appended at 07:24:37 on 97/07/02 GMT (by NL5OTR01 at ELINK) <10117> Subject: 3270/pc FTP for TSO From: John Been I like to know if there are Y2000 problems with respect to the IBM 3270/pc FTP for TSO (5665-311). Thanks in advance for your help, John Been This append was created on the External IBMLink system by Cliff Jackson Otra Information Services The Netherlands tel : +31 20 5450825 ----- YEAR2000 CFORUM appended at 07:42:54 on 97/07/02 GMT (by MSHEWELL at SYDVMXA2) <10118> IBM 3270/pc FTP for TSO (5665-311) is Year 2000 ready from V1R1M2 and onwards. Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@vnet.ibm.com VNET: Y2KTSCAP at SYDVMXA2 ----- YEAR2000 CFORUM appended at 13:17:38 on 97/07/02 GMT (by 70616111 at EHONE) <10119> Subject: OSI/CS According to the Year 2000 & 2 digit dates, the product OSI/CS 5685-014 for MVS needs to migrate to V1R2. Can you tell what are the year 2000 changes from V1R1 so that we can estimate the impact on customer applicat Daniel Giraudeau ----- YEAR2000 CFORUM appended at 09:31:11 on 97/07/04 GMT (by NL5OTR01 at ELINK) <10120> Subject: compliant versions of IBM products not in Y2K guide From: John Been Is there someone who knows the compliant versions of the following products? Cache RMF Reporter 5798-DQD COBOL/2 1.4.0 5668-958 DB2 PM 4.1 DB2 4.1 5695-DB2 Distributed Computing Environment 5655-064 ICFRU 5798-DXQ Office Vision Host Client / MVS (1.1.1, 1.1.2) 5799-FFW Open Edition MVS (UNIX) PL/I (ESA 4.3 Version) System Object Model for IBM Host 5715-003 Videotex commonitor prot 5785-WTX Videotex frame proc supp pc 5777-WFP Visualgen applgen MVS opt 5648-083 Visualgen developer 5648-040 Visualgen workgroups services 5648-076 Thanks for your help, John Been This append was created on the External IBMLink system by Cliff Jackson Otra Information Services The Netherlands tel : +31 20 5450825 ----- YEAR2000 CFORUM appended at 13:03:25 on 97/07/07 GMT (by Y2KTSC9 at STLVM6) <10121> Subject: compliant versions of IBM products not in Y2K guide Ref: Append at 09:31:11 on 97/07/04 GMT (by NL5OTR01 at ELINK) TYPE MOD SERIAL DESCRIPTION YEAR2000 READY ---- --- ------ ---------------------- -------- 5798 DQD Service withdrawn 1996-Ju N - Replaced by : 5645 001 Y* OS/390 V1R1 5668 958 COBOL/2 1.4.0 N - Replaced by : 5688 194 Y AD/Cycle CODE/370 V1R1 5655 102 DB2 Performance Monitor(P Y* 5695 DB2 DB2 V4R1 Y* 5655 064 OpenEdition DCE Appl Supp Y 5798 DXQ Integrated Catalog Forwar Y 5799 FFW Service withdrawn 1996-Au N 5655 064 OpenEdition DCE Appl Supp Y 5688 235 PL/I for MVS & VM V1R1 Y 5715 003 System Object Mo N - Could not find this product. Perhaps you are refferring to the following product: 5696 822 Y SOMobjects for MVS V1R1 5785 WTX Videotex commoni N - No references in U.S. to this product. We will check with Europe 5777 WFP Videotex frame p N - No references in U.S. to this product. We will check with Europe 5648 083 Visualgen applge Y 5648 040 Visualgen develo Y 5648 076 Visualgen workgr Y - A 'Y' suggests that the product is Year 2000 Ready. For software, this report suggests that only the exact listed version, release and modification are Year 2000 ready. - A 'N' suggests the product is not Year 2000 Ready or has not been tested and you should assume, therefore, it is not ready. - An '*' in the Year 2000 Ready column indicates PTF's, APAR's, EC's or SEC's may be required. IBM Year 2000 Technical Support Center (TSC9) ----- YEAR2000 CFORUM appended at 14:35:54 on 97/07/07 GMT (by 75407614 at EHONE) <10122> Subject: compliant versions of IBM products not in Y2K guide Ref: Append at 13:03:25 on 97/07/07 GMT (by Y2KTSC9 at STLVM6) 5785-WTX and 5777-WFP VTXCS are withdrawn from marketing in the announcement letter ZT91 2340. Thus IBM have no plans to test them for Year 2000. EMEA Y2K TSC ----- YEAR2000 CFORUM appended at 15:03:26 on 97/07/07 GMT (by Y2KTSC2 at STLVM6) <10123> Subject: DB2/2 1.x Ref: Append at 10:28:15 on 97/06/27 GMT (by JGREIG at GNKVM) Johan, Service for DB2/2 1.2 was withdrawn 12/31/1996. We have no access to information on this release. It's possible that someone in DB2/2 support could answer your question. Year 2000 Technical Support Center (TSC2) ----- YEAR2000 CFORUM appended at 16:23:30 on 97/07/07 GMT (by 86201999 at EHONE) <10124> Subject: MVS/ESA 5.2 My customer has MVS/ESA 5.2 installed on a 9672-R11 machine. They have only one application on this machine and it is not important for this application to have 2 or 4 digits. Their concern is about Operating System. MVS 5.2 does not support Year 2000. They want to know, what happens in 1/1/2000 , if they stay with MVS 5.2. What kind of impacts will occur on the operating system. I know this is a general question, but if you have a summary sheet, or a document you can suggest will be useful. I gave them a brochure, but it is too general. They need some bullets to see what will happen on their system. They will decide accordingly to move to OS/390, or not. Thanks, Sibel Aydin ----- YEAR2000 CFORUM appended at 17:12:22 on 97/07/07 GMT (by GAD at KGNVMC) <10125> Subject: MVS/ESA 5.2 Ref: Append at 16:23:30 on 97/07/07 GMT (by 86201999 at EHONE) MVS/ESA V5 *does* support year 2000 with appropriate service installed. Keep in mind, though, that there is more to this than just MVS. You also need to think about a whole host of other products that make up the operating system as a whole. The base control program, ie MVS, is just a small though important part of the whole. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 19:16:12 on 97/07/07 GMT (by HELENE at NYCVMIC1) <10126> Subject: Tools for ADSO, FOXPRO, CLIPPER Does anyone know of any parsers or scanners that can be used for ADSO, FOXPRO or Clipper. Thanks a lot, Helene Schiffman (Helene at NYCVMIC1 or 8-243-4283) ----- YEAR2000 CFORUM appended at 20:47:56 on 97/07/07 GMT (by PABLOF at LASVM1) <10127> Subject: Windowing tool for Mainframe COBOL Hi all. I was wondering if anyone has some clue on a tool that supports windowing under COBOL-MVS. The tool should be approved for IBM use, and also, should be fast (i.e. automatic). The need for speed is due to the potential amount of LOCs. Thanks in advance. Pablo Fernandez. ----- YEAR2000 CFORUM appended at 21:08:34 on 97/07/07 GMT (by CREMA at STLVM1) <10128> Subject: Windowing tool for Mainframe COBOL Ref: Append at 20:47:56 on 97/07/07 GMT (by PABLOF at LASVM1) >Hi all. I was wondering if anyone has some clue on a tool that supports >windowing under COBOL-MVS. > >The tool should be approved for IBM use, and also, should be fast (i.e. >automatic). The need for speed is due to the potential amount of LOCs. > >Thanks in advance. > >Pablo Fernandez. I'm not sure what you are asking, but if it's for GUI interface tool, we have IBM VisualLift for MVS, VM & VSE (5648-109) announced 9/13/94 US announce letter 294-531. Alice Crema IBM COBOL Family Support ----- YEAR2000 CFORUM appended at 08:01:54 on 97/07/08 GMT (by 83200470 at EHONE) <10129> Subject: VSAM Catalog and Year 2000 . Hello, I have heard that the old VSAM catalog(not ICF catalog) will not be year 2000 complient. Kindly confirm . Your comments are highly appreciated . Thanks.. Raad Dulaijan ----- YEAR2000 CFORUM appended at 08:30:16 on 97/07/08 GMT (by 86603407 at EHONE) <10130> Subject: VSAM Catalog and Year 2000 . Ref: Append at 08:01:54 on 97/07/08 GMT (by 83200470 at EHONE) Hello Raad. Yes I can confirm this. VSAM Catalogs will NOT be supported past year 2000. I've heard this from several sources. Nigel Bentley UK Level 2 SSD Software Support - Warwick. ----- YEAR2000 CFORUM appended at 08:41:25 on 97/07/08 GMT (by DEDATE17 at ELINK) <10131> Subject: Temporary access to Y2K-DASD Hello there, we want to set up following Y2K-testing scenario: 1:1 Full Volume Copy of our DASD (User-Pool and System-Pool) Own Masterconsole, no terminals. Accessing TSO2000 via VTAM-CTC No Shared Tapes, no Space-Management Configuring CHPs to DASD offline from production system Changing System-Parms (not going in SYSPLEX, not accessing ETR) IPLing the Y2K-System (same volids as in production system) with date 2000 or more. Is this a way to go ?? (Isolated enough?) Another question: When stopping the Y2K-System, is it possible to vary the DASD online to the normal production system ?? Thanks in advance This append was created on the External IBMLink system by Thomas Engler, System Programmer DATEV eG, Paumgartnerstr. 6-14, 90329 Nuernberg Tel: 49-911/276-3431 Fax: 49-911/276-5559 Internet E-Mail: Thomas.Engler¹datev.de ----- YEAR2000 CFORUM appended at 10:57:54 on 97/07/08 GMT (by GAD at KGNVMC) <10132> Subject: Temporary access to Y2K-DASD Ref: Append at 08:41:25 on 97/07/08 GMT (by DEDATE17 at ELINK) Your test scenario looks good to me. I find your last question unclear, however, since you said the DASD would all be duplicates. **ANY** DASD that has been used by a Y2K test system should be DSF initialized before being brought online and used by a production system. That will ensure that no dates in the far future remain on the volume to be accessed by the operating system. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 11:29:20 on 97/07/08 GMT (by GAD at KGNVMC) <10133> Subject: VSAM Catalog and Year 2000 . Ref: Append at 08:01:54 on 97/07/08 GMT (by 83200470 at EHONE) It is *clearly* stated in announcement letter 295-464 published on 95/10/31 that VSAM catalogs and CVOLs will not be year 2000 compliant, and no attempt will be made to do so. It was announced in letter 293-148 published on 93/03/16 that DFSMS 1.1 was stabilizing the VSAM catalog and CVOL support and this is a result of that stabilization. I believe that we looked at this, despite the announced stabilization, and there were technical reasons (no space in the records!) that prevent these functions from ever being made year 2000 compliant without a large amount of code and testing which was not considered justified. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 12:09:31 on 97/07/08 GMT (by NL5OTR01 at ELINK) <10134> Subject: PTF UW23079 From: John Been At this moment we have the application "CAS90" of Computer Associates. We heart that it is necessary to install an IBM PTF UW23079. Is this true??? Thanks in advance, John Been This append was created on the External IBMLink system by Cliff Jackson Otra Information Services The Netherlands tel : +31 20 5450825 ----- YEAR2000 CFORUM appended at 13:33:21 on 97/07/08 GMT (by PABLOF at LASVM1) <10135> Subject: Windowing tool for Mainframe COBOL Alice, Thank you for your response. But my question was pointing to a Year 2000 Tool that fixes the source/data code using the windowing technique, sliding or fixed window. Thanks and regards, Pablo Fernandez. ----- YEAR2000 CFORUM appended at 13:36:48 on 97/07/08 GMT (by DEDATE17 at ELINK) <10136> Subject: Temporary access to Y2K-DASD Ref: Append at 10:57:54 on 97/07/08 GMT (by GAD at KGNVMC) Thanks for quick response, my last question was about bringing some volumes online to the production system, since the Y2K system is no longer running. This way i want to go: Make a new label like FRE123 on the volume, config CHP online and vary the volume online. I want to use this scenario only for some parmlib changes or something easy like that. NO spacemanegement and NO further use of this datas on the volume will be done. Are some stupid changes possible, or should i take your last statements quite strange ? (DSF init,when back to production) What can happen, when there are "no" accesses to this volume (remember, there is a new label on it) Thanks in advance This append was created on the External IBMLink system by Thomas Engler, System Programmer DATEV eG, Paumgartnerstr. 6-14, 90329 Nuernberg Tel: 49-911/276-3431 Fax: 49-911/276-5559 Internet E-Mail: Thomas.Engler¹datev.de ----- YEAR2000 CFORUM appended at 15:15:32 on 97/07/08 GMT (by CREMA at STLVM1) <10137> Subject: Windowing tool for Mainframe COBOL Ref: Append at 13:33:21 on 97/07/08 GMT (by PABLOF at LASVM1) >Hi all. I was wondering if anyone has some clue on a tool that supports >windowing under COBOL-MVS. > >The tool should be approved for IBM use, and also, should be fast (i.e. >automatic). The need for speed is due to the potential amount of LOCs. > >Thanks in advance. > >Pablo Fernandez. Windowing is via the Language Environment date/time callable services described with examples in the Language Environment for MVS & VM Programming Reference SC26-3312-02. You can call these from all the LE-enaled compilers. Here are some of the routines: CEEDATE - convert Lilian date to character format CEEDATM - convert seconds to character timestamp CEEDAYS - convert date to Lilian format CEEDYWK - calculate day of week from Lilian date CEEGMT - get current Greenwich Mean Time CEEGMTO - get offset from Greenwich Mean Time to local time CEEISEC - convert integers to seconds CEELOCT - get current local time CEEQCEN - query century window CEESCEN - set century window CEESECI - convert seconds to integers CEESECS - convert timestamp to number of seconds Alice Crema IBM COBOL Family Support ----- YEAR2000 CFORUM appended at 16:58:21 on 97/07/08 GMT (by JFRANCIS at GDLVM7) <10139> Subject: VSAM Catalog and Year 2000 . Ref: Append at 11:29:20 on 97/07/08 GMT (by GAD at KGNVMC) > It is *clearly* stated in announcement letter 295-464 published on > 95/10/31 that VSAM catalogs and CVOLs will not be year 2000 compliant, > and no attempt will be made to do so. It was announced in letter > 293-148 published on 93/03/16 that DFSMS 1.1 was stabilizing the VSAM > catalog and CVOL support and this is a result of that stabilization. This only applies to DFSMS/MVS and VSAM catalogs on MVS. The Year 2000-ready releases of VM and VSE include Year 2000 support for VSAM catalogs. If you currently share VSAM catalogs between MVS and VM or VSE you will no longer be able to do so after December 31, 1999. John Franciscovich VM Development ----- YEAR2000 CFORUM appended at 12:51:37 on 97/07/09 GMT (by 86476355 at EHONE) <10140> Subject: OS/390 Yr2000 Scanner Hi Does anybody know about a tool or product that is capable of the following. Scanning all the IBM (or OEM) supplied software to verify that the software is YR2000 capable. (currently I do it manually. Check PSP buckets and then verify that the PTF's are on.) Thanks Ralph H Rudd PSS IBM South Africa Pty Ltd ----- YEAR2000 CFORUM appended at 05:31:01 on 97/07/10 GMT (by E085209 at EHONE) <10141> Subject: VSAM Catalog and Year 2000 . Ref: Append at 08:01:54 on 97/07/08 GMT (by 83200470 at EHONE) Hello, by applying the fix for APAR OW25632(DFSMSdfp) or OW25988(DFP), the IEC331I 004-033 is issued during VSAM CATALOG OPEN and this is a warning message. . On 2000/01/01, the message is changed to IEC331I 004-034 which means OPEN fail for VSAM CATALOG. Best regards, Shigeki Kimura, IBM Japan. ----- YEAR2000 CFORUM appended at 12:46:04 on 97/07/10 GMT (by ATEDVG05 at ELINK) <10142> ..... YEAR2000 CFORUM modified at 06:29:35 on 97/07/11 GMT (by ATEDVG05 at ELINK) <10144> Subject: OS/390 Yr2000 Scanner Ref: Append at 12:51:37 on 97/07/09 GMT (by 86476355 at EHONE) Hi Ralph. Have you had a look at Platinums 'SystemVision YEAR 2000'? I've just installed the product, but can't tell you any results before the end of August - holidays and schooling. I'm not quite sure if this is what you are looking for - it only searches through customized sources. This append was created on the External IBMLink system by :-) Kim Ericson . . . EDVg-debis Systemhaus . Vienna, Austria Kim_Ericson@edvg.co.at ----- YEAR2000 CFORUM appended at 17:00:15 on 97/07/10 GMT (by Y2KTSC3 at STLVM6) <10143> Subject: compliant versions of IBM products not in Y2K guide Ref: Append at 13:03:25 on 97/07/07 GMT (by Y2KTSC9 at STLVM6) >5668 958 COBOL/2 1.4.0 N > - Replaced by : 5688 194 Y AD/Cycle CODE/370 V1R1 I hate to contradict a colleague, but there was an error in the above referenced append. 5668-958 is not COBOL/2, it is VS COBOL II, and it is replaced by COBOL for MVS & VM (5688-197) and COBOL for OS/390 & VM (5648-A25). CODE/370 (5688-194) is the Debug Tool, and does not replace VS COBOL II. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 13:43:53 on 97/07/11 GMT (by 61800836 at VIEVMA) <10147> Subject: VSE/ESA guests (Y2K ready) under VM/ESA (not Y2K ready) One of our customers asks whether he has to migrate his VM/ESA system to be Y2K ready, even if he uses the VM/ESA system only to run several VSE/ESA production guests, which of course are Y2K ready. Is there a definite answer or will it be "It depends ...." ? Best regards, Helmut Brauchler - ESSC 1, Vienna - Austria ----- YEAR2000 CFORUM appended at 15:23:19 on 97/07/11 GMT (by JFRANCIS at GDLVM7) <10148> Subject: VSE/ESA guests (Y2K ready) under VM/ESA (not Y2K ready) Ref: Append at 13:43:53 on 97/07/11 GMT (by 61800836 at VIEVMA) VM/ESA's Year 2000 support (V2R2) is not required to run a guest system that is Year 2000 ready. John Franciscovich VM Development ----- YEAR2000 CFORUM appended at 17:34:34 on 97/07/11 GMT (by TFCHANG at BLDVMA) <10149> Subject: ESAMIGR SAMPLIST P. 8.28 of GC28-1251-06 mentions about the ESAMIGR package as an IBM tools for VM/ESA. We used it when we migrated from VM/HPO to VM/ESA. Our installation will be VM/ESA 220 this week, we found the ESAMIGR package form MKTTOOLB shadow, we ran the new ESAMIGR against our REXX, PLX source code using the ESAMIGR SAMPLIST came with the package. It works for MIGRATION purpose. It might be misleading if we do not further "Customerize" the ESAMIGR SAMPLIST to reflect what applications need to be changed in order to be Y2K compliant. Is there anyone "customerize" the ESAMIGR SAMPLIST for the purpose of Y2K compliant under VM/ESA220? If it is available then all the applications to be converted to Y2K compliant under VM/ESA220 could be benefited a great deal by this migration tool. T.F. Chang ----- YEAR2000 CFORUM appended at 11:18:20 on 97/07/15 GMT (by GBCDVZ02 at ELINK) <10150> Subject: PL/1 Compile time Will the PL/1 COMPILETIME variable still be presented in the same format in the year 2000? And will there be a variable containing the compile date and time in y2k format ? Regards, Paul Beesley This append was created on the External IBMLink system by Frizzell Paul Beesley Technical Coordinator Phone: 01202 502334 Email: GBFRIPBE@IBMMAIL ----- YEAR2000 CFORUM appended at 17:23:22 on 97/07/15 GMT (by HUYKHAC at SJFEVMX) <10151> Subject: PL/1 Compile time Ref: Append at 11:18:20 on 97/07/15 GMT (by GBCDVZ02 at ELINK) For compatibility, COMPILETIME will still return a 2-digit year. A new builtin function, COMPILEDATE, introduced via apars PN92224 (PL/I for MVS & VM) and PQ01168 (PL/I V2R3) will return a 4-digit year. Huy K. Le ----- YEAR2000 CFORUM appended at 12:34:12 on 97/07/17 GMT (by 61800836 at VIEVMA) <10152> Subject: VSE/ESA guests (Y2K ready) under VM/ESA (not Y2K ready) Ref: Append at 15:23:19 on 97/07/11 GMT (by JFRANCIS at GDLVM7) John, thank you for the clarification. Now the customer wants to go one step further. He uses SQL/DS V3.5 (Y2K compliant) with guest sharing support. That means, the SQL server is running under VM/ESA, but all the applications accessing or updating the database run under VSE/ESA in CICS or batch partitions. No CMS applications access the database. Obviously the maintenance for the server must be done under CMS. Is it still true in this environment, that VM/ESA's Year 2000 support (V2R2) is not required ? Helmut Brauchler - ESSC 1, Vienna - Austria ----- YEAR2000 CFORUM appended at 22:05:52 on 97/07/18 GMT (by LKGOINS at CHGVMIC1) <10153> Subject: Renovating Code that was Generated using INSTALL/1 In a few weeks, we will be starting a renovation for a client who has a lot of code that was generated by an Arthur Andersen product called INSTALL/1. The solution is windowing. Has anyone done any renovations using INSTALL/1-generated code? If so, anything we should watch out for? Please respond either to this forum or directly to the project manager, Laura Hunsinger at (312)974-6907 or tieline 844-6907. At this point, we have no specific questions; we just want to be forewarned! Thanks, Lynnelle Goins ----- YEAR2000 CFORUM appended at 08:32:33 on 97/07/21 GMT (by 83484690 at EHONE) <10154> Subject: CICS V2.1.2 Hello, My customer has the following query: If the application program does not need to compare dates and is not concerned about yr 1999 vs 2000, can CICS V2.1.2 be run after Year 2000 without abending ? Customer is fully aware that CICS V2.1.2 has dropped support and that it does not support year 2000, but will like to know if CICS V2.1.2 will abend because of the 00 year. Thanks in advance for your help.. Thia Ying ----- YEAR2000 CFORUM appended at 21:54:59 on 97/07/21 GMT (by DKREUTER at CANVM2) <10155> Subject: VM SQL and COBOL minimum levels What are the minimum levels of VM SQL (or VM/DB2) and COBOL II for VM that support the YEAR 2000? Cross posted to YR2000VM CFORUM. David Kreuter ----- YEAR2000 CFORUM appended at 02:36:04 on 97/07/22 GMT (by Y2KTSC3 at STLVM6) <10156> Subject: VM SQL and COBOL minimum levels Ref: Append at 21:54:59 on 97/07/21 GMT (by DKREUTER at CANVM2) >What are the minimum levels of VM SQL (or VM/DB2) and VS COBOL II >for VM that support the YEAR 2000? OS/VS COBOL and VS COBOL II programs and the Year 2000 ------------------------------------------------------- There are no known problems with older IBM COBOL products related to the Year 2000. There are only 2 issues to be concerned with for COBOL applications and the Year 2000: 1) Date Related Logic 2) Service support from IBM You can get service support for OS/VS COBOL and VS COBOL II programs indefinitely by using the Language Environment run-time library with just a run-time migration. This is described in the next section. As a result, an application with NO DATE RELATED LOGIC could be run in a supported environment beyond the turn of the century by a run time migration only, with no source changes or recompiles necessary. Repeat, no source code changes or recompiles and your OS/VS COBOL and VS COBOL II programs can be running with full IBM service support and no Year 2000 problems if they are running under Language Environment and have no date-related logic problems! 1) Date Related Logic ------------------------ Of course, an application that DOES have date related logic must be examined to see if it has a Year 2000 problem. If it does, then programs will have to be changed, which means at the very least a compile, link and test. At this point you can combine source upgrade (compiler migration) with Year 2000 conversion. IBM does not provide any way for OS/VS COBOL programs to obtain a 4-digit year date, so you must compile with at least VS COBOL II in order to use IBM provided services for obtaining a 4-digit year date. If you want to use COBOL language to get 4-digit year dates, then the only COBOL compilers you can use are the newest ones: COBOL for MVS & VM, COBOL for OS/390 & VM, and COBOL for VSE. VS COBOL II programs can get access to the LE date/time routines via dynamic CALL statements if they are running under LE. 2) Service support for programs compiled with OS/VS COBOL or VS COBOL II --------------------------------------------------------------------- IBM will continue to provide service support for the execution of programs compiled with the OS/VS COBOL and VS COBOL II compilers as long as these programs are using the Language Environment for MVS & VM (5688-198) versions of the COBOL library routines. (This also holds true for programs compiled with the DOS/VS COBOL and VS COBOL II compilers running on VSE, except that the strategic run-time library for VSE is Language Environment for VSE (5686-094).) Every COBOL program requires library routines in order to execute. They may be statically linked to the load modules or dynamically accessed at execution time. If the library routines that are being used are supported by IBM service, then you can call IBM when there is a problem and get the problem fixed. For example, the library routines for OS/VS COBOL programs exist in the OS/VS COBOL run-time library, the VS COBOL II run-time library, and in the Language Environment run-time library. If your OS/VS COBOL programs are running using the OS/VS COBOL library, then they are not supported by IBM service. If your OS/VS COBOL programs are running using the Language Environment run-time library, then your programs are supported by IBM service, and will be supported well into the 21st century. If you are starting with load modules consisting of programs compiled with the NORES option and link-edited with the OS/VS COBOL library or the VS COBOL II library, then you will need to use REPLACE linkage editor control statements to replace the old library routines with the Language Environment versions. If you start with object programs (non-linked) then you just need to link edit with Language Environment If the programs are compiled with RES, then you can just make the Language Environment library routines available at execution time in place of the OS/VS COBOL or VS COBOL II library routines by using LNKLST, or STEPLIB on MVS, and GLOBAL statements on VM. A recompile is NOT required to complete your migration. ------------------------------------------------------- The ideal state is that programs should be compiled with a supported compiler (recommended is COBOL for MVS & VM) running with a supported run-time library (Language Environment for MVS & VM). However this ideal state can be reached gradually in a fully supported manner: 1) Run-time migration followed OPTIONALLY at some future date by 2) Compiler migration What if I need to make a change to an OS/VS COBOL program? ----------------------------------------------------------- The OS/VS COBOL compiler is not supported, although the programs that were generated by it are supported under Language Environment. Once you have completed the run-time migration, if a change needs to be made to a COBOL program (for maintenance or enhancement) you only need to run the source though a source conversion tool such as CCCA (5785-ABJ) or the Conversion feature of VisualAge for COBOL and then compile using the COBOL for MVS & VM compiler. This way you can gradually convert your source with a minimum cost to your company. For complete information on both run-time migration and source conversion, see the COBOL Migration Guide, GC26-4764, and the LE Migration Guide, SC28-1944. You can view both on the Web from the bookshelf at: www.software.ibm.com/year2000 Useful presentations on COBOL migration are frequently given at Technical conferences such as GUIDE, SHARE, and the IBM Technical Interchange. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 15:30:23 on 97/07/22 GMT (by Y2KTSC2 at STLVM6) <10157> Subject: VM SQL and COBOL minimum levels Ref: Append at 02:36:04 on 97/07/22 GMT (by Y2KTSC3 at STLVM6) The earliest release of DB2 that is Year 2000 Ready is, DB2 for VSE and VM 4.1.0, 5648-158. There is no Year 2000 Ready version of COBOL II. The earliest COBOL that is Year 2000 Ready is, COBOL for MVS & VM 1.1.0, 5688-197 Year 2000 Technical Support Center (TSC2) ----- YEAR2000 CFORUM appended at 07:11:02 on 97/07/23 GMT (by JOHNORR at ISSCAUS) <10158> Subject: OS/2 Y2K Readiness Can you please tell me the current Y2K-ready status of OS/2, in particular Warp 3 and Warp 4, in light of: 1. The latest Appendix A of the Y2K Planning Guide (printed and online) shows both Warp 4 and Warp 3 Connect (with or without WIN-OS2) as being Y2K ready by year end 1997, with the footnote: "Base API calls are Year2000 ready. Other components/products available as part of the OS/2 package continue to be investigated and will be fixed, as appropriate." 2. I have seen other documentation that flags Warp 3 Connect as *NOT* Y2K ready, with no such flag for Warp 4. Are there really Y2K differences between Warp 3 and 4, or is the Planning Guide correct? Also, is it possible to find out: - When is OS/2 (Warp 3 and/or 4) likely to be declared fully Y2K ready? (Plus info on any required service to achieve this). - Which packaged components/products are already OK and which aren't? (Reason for asking this is that I don't really care if Solitaire or the Shredder haven't been checked, but there may be some more basic system functions, e.g. file or password management, that I should care about). Thanks.... John Orr Sydney, Australia ----- YEAR2000 CFORUM appended at 08:44:54 on 97/07/23 GMT (by Y2KTSCAP at SYDVMXA2) <10159> Subject: OS/2 Y2K Readiness Ref: Append at 07:11:02 on 97/07/23 GMT (by JOHNORR at ISSCAUS) John, Both OS/2 Warp versions 3 and 4 are Year 2000 Ready with the previously mentioned footnote. This includes Warp 3 Connect, which *IS* Year 2000 Ready. The documentation you were referring to could be old information. OS/2 Warp 3 was not mentioned in the previous edition of IBM's Planning Guide (Sixth Edition) as its Y2K status was still unknown. It was then introduced into the latest edition of the Guide (April 1997) as by then it had been more fully tested. We believe the fix pack for OS/2 Warp versions 3 and 4 will be available in the 4th quarter of this year. I would suggest you keep an eye on this forum as more information such as dates and how to obtain the service will be posted as soon as they come to hand. Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@vnet.ibm.com VNET: Y2KTSCAP at SYDVMXA2 ----- YEAR2000 CFORUM appended at 07:35:00 on 97/07/25 GMT (by 85676475 at EHONE) <10160> Subject: Bypass YR2000 by setting date back I was challenged from the strange idea to bypass YR2000. The procedure are as follow - Change all data files relevent to date back to the past ( for example 1940 so date kept in file will be changed from 97 to 40 becuase it is only 2-digits, from 96 to 39 and so on... ) - Shutdown and set Hardware date to be in the past also ( 1940 ) - Now everything is shiped back as if it start at 1940 This sound strange but possible if it work. The question is 1. Is there any problem if I change date back? ( such as file creation date which is 1997 but will be restored in 1940 ) 2. I know system keep many time records if I set date back, what will happen? ( I guess this's not very easy to say ) 3. Is this procedure possible to do? Thank you in advance, Wisit ----- YEAR2000 CFORUM appended at 11:22:31 on 97/07/25 GMT (by GAD at KGNVMC) <10161> Subject: Bypass YR2000 by setting date back Ref: Append at 07:35:00 on 97/07/25 GMT (by 85676475 at EHONE) Ahhh, this "solution" raises it's ugly head again... It's a solution that causes more problems than it solves, though. In fact it's not really a solution at all, but rather a fancy way to end up corrupting your data. Keep in mind that for this to work properly you must find **ALL** dates in any data, including that archived to tape, and reset them to the new base. Oh, and what do you do if someone was born in 1916? How do you subtract 27 from that. And what do you do about anything you receive from outside the site? Guess what, people like to read the correct date on reports...don't expect them to add 27 to the year. So, can you find and change all the programs that put out dates to do this? I doubt it, or you would not be asking about this scheme. Also, any dates that are inputed must also be adjusted by the program. Again a monumental programming task. Lastly (though there is more I could say) what are the odds that the operation staff will correctly enter the year whenever they set to date? I'm afraid I expect them to make a mistake sooner or later, which will end up corrupting things to no end. I've heard this idea proposed before, but it just does not hold water. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 16:52:33 on 97/07/25 GMT (by IL68778 at ELINK) <10162> ..... YEAR2000 CFORUM modified at 13:38:46 on 97/07/27 GMT (by IL68778 at ELINK) <10164> Subject: Bypass YR2000 by setting date back Ref: Append at 11:22:31 on 97/07/25 GMT (by GAD at KGNVMC) Here is a quote on this subject from Information Week, pasted from: http://techweb.cmp.com/iw/638/38uwwu.htm > Microsoft chairman Bill Gates said at his CEO Summit in May > that it's "pretty simple to go and find the places that > compare dates", that "there's a way of fooling the system by > just taking all the dates you put in and subtracting 30 years". Now, Greg, who are you to challenge Bill's wisdom? :=))) Gilbert Saint-flour ----- YEAR2000 CFORUM appended at 03:31:33 on 97/07/28 GMT (by ALANDP at SYDVMXA2) <10165> Date: Mon, 28 Jul 1997 From: FREELAND@anz.com Subject: 4701/4702 controller and year 2000 issues I am commencing work on the Year 2000 problem for our 4701/4702 controllers. We use them in all our ANZ Retail Branches and Proof Data Centres within Australia. I have been advised of IBM's FTP site that contains patches for the above controllers but I was wondering whether there are general information sources relating to 4700 & Year 2000 issues. Example: Frequently-Asked-Questions (FAQs), discussion forums, news groups, List-Servers, etc. There seems to be a lack of 4700-related sites on the Internet. (Basically I would like to know as much as possible). Your help would be greatly appreciated. Michael Freeland ----- YEAR2000 CFORUM appended at 14:42:34 on 97/07/28 GMT (by ACLARK at EHONE7) <10166> Subject: Bypass YR2000 by setting date back Ref: Append at 07:35:00 on 97/07/25 GMT (by 85676475 at EHONE) Besides the other problems that you'll cause... the setting of the hardware date to 1940 may generate some interesting problems too. 1) Do you have any s/w that needs a CPUID? Will they work with a bogus date? (eg. all Sterling products) 2) Does anything use the S/390 TOD clock for timestamping files (eg. DB2) The TOD clock wraps around next ~Sept. 17 2042 at 23:53:47.370496. So if you set the h/w clock to 1940 your TOD clock will roll over in two years and may cause you other grief sooner than the rest of us (who may not be around in 2042) and even before the year 2000 problems start. 3) If you send any of your data to a PC, they don't take too kindly to being told it's earlier that 1980... since they weren't invented before that. ---------------------------------------------------------------------- Adrian Clark - Sears Canada Inc. IBMMAIL(CASRSAJC) / aclark@null.net ----- YEAR2000 CFORUM appended at 17:53:38 on 97/07/28 GMT (by CAMEYERS at CHGVMIC1) <10167> Subject: Year 2000 Support Are the following products year 2k ready? VSMR 5799-wwl 1.3.3 APE 5668-896 1.1.3 Application Prototype Environment (this was replaced by V2 5668-808, does this support YR2k?) Common Lib 5688-082 2.3.0 Info Center/1 1.1.5 5668-897 (This was replaced by AS V4: 5648-092 Info Ctr Feat.Is this YR2kready) GPARS: 1.2.1 ? Most are very old, and I would say don't support YR2k. I plan to suggest they test the code. Has any of the replacement software listed been tested. ----- YEAR2000 CFORUM appended at 22:25:54 on 97/07/28 GMT (by PIZZAZZ at STLVM20) <10168> Subject: We IPL'ed with Y2K dates on our OLD hardware. This is off a Y2K list discussions, and I thought it was worth cross-posting. Karen R. Barney ----------------------------- Post follows ------------------------------ Received: from dean.zebra.co.uk by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Sun, 27 Jul 97 20:10:15 EDT Received: (from majordom@localhost) by dean.zebra.co.uk (8.6.12/8.6.10) id AAA30926 for listmanager-outgoing; Mon, 28 Jul 1997 00:13:35 +0100 Received: from ohm.fast.co.za (root@ohm.fast.co.za [196.28.25.5]) by dean.zebra.co.uk (8.6.12/8.6.10) with ESMTP id AAA30921 for ; Mon, 28 Jul 1997 00:13:31 +0100 Received: from pm-1-13.bry.fast.co.za (pm-1-13.bry.fast.co.za [196.28.25.77]) by ohm.fast.co.za (8.7.5/8.6.9) with SMTP id BAA18208; Mon, 28 Jul 1997 01:12:43 +0200 From: slug@fast.co.za (Chris Anderson) To: y2ksasig@cinderella.co.za, y2k@leba.net, listmanager@zebra.co.uk Newsgroups: comp.software.year-2000 Subject: Re: We IPL'ed with Y2K dates on our OLD hardware. Date: Sun, 27 Jul 1997 22:11:57 GMT Message-ID: <33e0c675.6127158@news2.fast.co.za> References: <33dad737.1871569@news1.ibm.net> X-Mailer: Forte Agent .99g/16.339 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-listmanager@zebra.co.uk Precedence: bulk redsky@ibm.net (Thane Hubbell) wrote: >Arnold asked me this in E-mail and I thought others might find it >interesting. Comments? Cory? > > >> A while ago you mentioned in an e-mail to me that you were going to IPL >> your mainframe with a year 2000 date. I don't remember ever hearing what >> happened. I am curious if you managed to do the test and what you found >> out. >> > >Yes we did it. We ran a bunch of software too! > >Here's the scoop. The 4300 series machines (and any 370 series for >that matter) keep an internal clock ticking off seconds that start on >01/01/1900 and go through 2041. 31 bit. If the system is allowed >to, it will roll over properly in Y2K. Our intention is not to be >operating for the roll over and to just IPL After 2000. > >In both our installations we run NON compliant operating systems that >we purchased. One is DOS/SP 2.1 and the other is from a company >called Software Pursuits called MVT/VSE - a DOS variant. At the MVT >Site we run VSAM, VTAM/BTAM and CICS 1.5, at the DOS/SP site we run >VTAM, VSAM and CICS 1.6. Old stuff and certainly not compliant. > >Now the long and short of it . We wrote an asm program to >interrogate the hardware timer and report it's actual value. We ran >it normally. The value checked out with what the 370 hardware timer >documentation said it would. So the question was, when we set the >clock on IPL and enabled the TOD set, would it report the value for >2000 or the value for 1900? If 1900 could we tolerate that? Since >1900 was not a leap year would the Julian date be reported correctly >after and on 02/29/00? > >And the answer is: > >Yes, it IPL'ed. All systems ran. VTAM, VSAM, CICS, and batch jobs >including POWER, also ICCF ran. > >The TOD clock reported 1900 not 2000. We IPLed for several dates. >01/01/00 and 02/29/00 and 03/01/00. All dates reported correct >julian dates and gregorian conversions. We did no day of week >checking, none of our systems depend on it or use it. > >My boss was in CA last week at our other site and performed the same >tests. > >We expect some problems with dates in ICCF in their sort of members >usually most recent to oldest - but after 19xx items have been >"updated" things should be OK. I don't know if they will take last >update or not as far as reporting goes, but my boss says we can live >with it anyway. > >So... I think this is the real scoop - at least as far as IBM is >concerned. > >IF you don't care about the operating system reporting the century >and all your operating system software is NON compliant, everything >will work. We'll have to use windowing on current date stuff to make >sure that we get the century and all the application software has to >be fixed, but we don't have to change operating systems. > >I'm not convinced we did enough of a test, but getting my boss to >even do this much was a MIRACLE! We'll see now if we ever get to fix >the code! > >Thanks for the interest! > > I was really pleased to hear that someone had finally had the courage to take this route. This is what I call the "Classic" Cinderella Class 4 problem. You are stuck with an old machine and for whatever reason,economic, black-box operation, whatever, you have to run with the old system. The Manufacturers all hate this suggestion. It means they can't sell you new expensive gear. Expect no assistance from them. This is an approach I have tried to punt but have had no takers. People just look at me strangely. Let alone let me demonstrate on their machine. B>) It is a high-risk approach. But it is feasible. Provided you know precisely what you are doing, and can live without certain things. Like Support. You really need access to system source code. It is truly a Hackers Delight solution (I use "Hacker" in the original non-perjorative sense) I have managed to find an approach that works ok with VM/SP 5 PLC 237. VSE 2.1 is a little more problematical, but it can be done. The old "public domain" versions are also a little more difficult, but could be done. A lot depends on disk type support (FBA/3330/3350/3380). The difficulty usually is to find a test machine. A PC/390 emulating 3380 would do it but you would generally need 9track 1600/6250 or 3480 cartridge support. Or a means of converting disk image tapes. Expensive for an individual. There are all sorts of ifs and buts, but it can be done. Beware, it is not as simple as it looks on casual inspection. It took Congressional Hearings to force IBM to take a really hard look at their code, hence the 1997 versions. I fought them tooth and nail to fix this back in 1986 but they wouldn't. They do not change their system internals lightly. The ICCF and VM FLIST directory sort sequence is trival and cosmetic and can be lived with and eventually sorts itself out. There are some interesting wrinkles in VTOC file expiry protection, but if you know about them they can be worked around. There are some Real Lulu bugs hidden in the old code! With VSAM, CICS and VTAM particularly. But there are ways and means. Thankfully neither VM nor VSE use system catalogs. This is the main bugbear in getting the earlier VS1 and MVS systems compliant. Apart from the YYDDD abomination. If anyone is really interested in this topic, I for one would be prepared to be actively involved. I have been working on this since 1986 and it is one of my hobbyhorses. BTW the TOD clock is actually being set to 2000 by the 00 IPL but the displays are wrong and show 1900, (that is why the leap year IPL works). APARs sometime during 1987 changed the IPL seed but little else. You can see this better under VM (which displays 2000 under certain conditions e.g. within REXX) Incidentally I have a theory that if the COMREG date were modified to YYYYMMDD (it is CHAR 8 - drop the slashes) then CURRENT-DATE for COBOL and SYSTEM-DATE for PL/1 would be vastly improved. Most applications just do an MVC from COMREG. Although an even better approach is to use an Assembler subroutine which reads the clock direct and does the correct interpretation. I have personally used this approach since the 80's. Works for me. I suppose the new "CCYYMMDD" could also be implemented (Aaargh. Shriek. No..no..noo) So if you guys are interested, drop me a line and I will publish a detailed scenario of how to get round the "deep" problems on "old" pre-XA and pre-ESA IBM hardware and software. And maybe we can get a working group together and hack this thing until it all works, and produce some "patches". ------------------------------------------------------------------------ Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za http://www.cinderella.co.za Striving for Year 2000 Compliance ----- YEAR2000 CFORUM appended at 01:17:09 on 97/07/30 GMT (by IL35816 at ELINK) <10169> Subject: Bypass YR2000 by setting date back Ref: Append at 14:42:34 on 97/07/28 GMT (by ACLARK at EHONE7) You know, this "setting the clock back 28 years" thing always seemed to me like the dumbest thing I had ever heard of but d---ed if there isn't a cover story in the July 28 Computerworld about an insurance company that claims to be doing this successfully. Charles Mills Firesign Computer Company, San Francisco charlesm@firesign.com ----- YEAR2000 CFORUM appended at 13:52:41 on 97/07/31 GMT (by BEUMII00 at ELINK) <10170> Subject: Access to Y2K Dasd - How far does one have to go ? IN preparing our Y2K migration plan, we often think about how to separate the Y2K test environment from our daily production environment ? How far does one have to go, to separate the access to the Y2K environment ? Is it alright to have different LPARS with shared DASD ? Or does one have to get separate DASD with separate Control Units, attached to separate CHPIDS ? Who has already some experience with this kind of problems ? Don't hesitate to answer | You can reach me by E-mail at Francois.VennekensėUM.BE This append was created on the External IBMLink system by Francois Vennekens, Systems Engineer UNION MINIERE A. Greinerstraat 14 - 2660 Hoboken (Belgium) Ph +32-3-8217887 Fax +32-3-8217816 - E-Mail Francois.VennekensėUM.BE ----- YEAR2000 CFORUM appended at 14:12:16 on 97/07/31 GMT (by GAD at KGNVMC) <10171> Subject: Access to Y2K Dasd - How far does one have to go ? Ref: Append at 13:52:41 on 97/07/31 GMT (by BEUMII00 at ELINK) If you are using a simulation product, such as Tick-Toc, to do testing at an application level then you can consider sharing DASD. Do keep in mind the potential for test database contamination with future dates, though. It can be done, but I would be cautious. For testing using a TOD set to 2000 or system level testing, isolated *UNSHARED* DASD is critical. Just IPLing MVS with a future date could cause information in the VTOC to become altered on shared DASD and cause you grief. You should be prepared to initialize all the packs using DSF that are used for year 2000 testing before placing them back into production pools. Anything less leaves you open to system level data contamination and grief. I have heard of customers that were so concerned about the possibility of data contamination during year 2000 testing that they leased time at their disaster recovery site to do it, thus making absolutely sure that contamination could not occur. I consider this toa *very* wise and safe move. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 07:41:47 on 97/08/01 GMT (by BEUMII00 at ELINK) <10172> Subject: Access to Y2K Dasd - How far does one have to go ? Ref: Append at 14:12:16 on 97/07/31 GMT (by GAD at KGNVMC) Thanks Greg for the Info So if we plan to test on a separate LPAR, using DASD isolated from the rest of our Production System it will not cause any damage. We also plan to make regular full volume copies from our production system to that test environment. Each time we do this we have to initialize all target volumes with DSF. Does it matter which DSF (the one from the Non Y2K compliant system or the one of the Y2K compliant system) we use ? As far as we talk about the same device types on both sides. This append was created on the External IBMLink system by Francois Vennekens, Systems Engineer UNION MINIERE A. Greinerstraat 14 - 2660 Hoboken (Belgium) Ph +32-3-8217887 Fax +32-3-8217816 - E-Mail Francois.VennekensėUM.BE ----- YEAR2000 CFORUM appended at 10:48:47 on 97/08/01 GMT (by GAD at KGNVMC) <10173> Subject: Access to Y2K Dasd - How far does one have to go ? Ref: Append at 07:41:47 on 97/08/01 GMT (by BEUMII00 at ELINK) Any version of DSF can be used to reinitialize the volumes. The intent is to destroy any datasets that may have gotten year 2000 dates into them in some way. This includes in the data, PDS directories, and the VTOC. The writing of a new VTOC using DSF is the easiest way to ensure this. Greg Dyck MVS BCP Kernel and CURE Support ----- YEAR2000 CFORUM appended at 13:27:42 on 97/08/01 GMT (by BEUMII00 at ELINK) <10174> Subject: Access to Y2K Dasd - How far does one have to go ? Ref: Append at 10:48:47 on 97/08/01 GMT (by GAD at KGNVMC) Thanks Greg, but there was another question that popped up. Is there a need for separate DASD Control Units, or is a VARY OFFLINE/ONLINE of the affected volumes sufficient to switch them over from environment (old) to environment (new) ? This append was created on the External IBMLink system by Francois Vennekens, Systems Engineer UNION MINIERE A. Greinerstraat 14 - 2660 Hoboken (Belgium) Ph +32-3-8217887 Fax +32-3-8217816 - E-Mail Francois.VennekensėUM.BE ----- YEAR2000 CFORUM appended at 18:40:21 on 97/08/01 GMT (by CROBERTS at BLDVMA) <10175> Subject: sliding window I do not think I fully understand the sliding window methodology on the Y2K functionality within DFSORT, or program century date routine. EXAMPLE: 1997 - 43 = 1954 CONVERTING EVERYTHING >= '54' TO CENTURY '19', AND EVERYTHING < '54' TO CENTURY '20'. RESULTS: JANUARY 1, 1954 THROUGH DECEMBER 31, 1999 JANUARY 1, 2000 THROUGH DECEMBER 31, 2053 EXAMPLE: 2000 - 43 = 1957 '57' EXAMPLE: 2042 - 43 = 1999 '99' EXAMPLE: 2043 - 43 = 2000 '00' <-----(PROBLEM)?? In 2042, data that is 1998 (44 years old) will become 2098. Expiration dates are in the future. You would need to check for something that is too far in the future, if that can be determined. How do you work with rate ranges which extend into the future or are intended to be infinite? Can anyone help me with this? Thanks. carol roberts Dept:f82 SN:216192 Div:10 Ext:5 - 8010 ----- YEAR2000 CFORUM appended at 19:31:16 on 97/08/01 GMT (by YAEGER at SJFEVMX) <10176> Subject: sliding window Ref: Append at 18:40:21 on 97/08/01 GMT (by CROBERTS at BLDVMA) I'm not sure I fully understand what you're asking, but perhaps I can help anyway. The century window concept is based on a window of 100 years. Two-digit year data which fits into a 100-year span can use a century window; two-digit year data which exceeds a 100-year span cannot, and will probably require conversion to four-digit years. DFSORT offers both a fixed and sliding century window. The fixed century window doesn't change. If you specify: Y2PAST=1950 you get a Century Window of 1950-2049 in 1997, 1998, and so on. The sliding century window specifies a century window that advances one year each year. If you specify: Y2PAST=47 you get a century window of 1950-2049 in 1997, 1951-2050 in 1998, and so on. You can set the century window to start at any year you like with either of these options and set different century windows for different DFSORT applications. But with either of these methods for using the century window, if your dates cannot be encompassed by a 100-year span at any point, the century window concept will not work for those dates. Frank L. Yaeger - DFSORT Team (Specialties: ICETOOL, OUTFIL, Y2K :-) => DFSORT/MVS is on the WWW at http://www.storage.ibm.com/dfsort/