----- YEAR2000 CFORUM appended at 00:00:18 on 97/03/02 GMT (by Y2KTSC3 at STLVM6) Subject: VS COBOL II ACCEPT Ref: Append at 15:23:30 on 97/02/28 GMT (by TOSTA at RIOSYS1) >> Under the obsolete compilers, OS/VS COBOL and VS COBOL II, all >> these methods return 2-digit year dates with no century indicator. > As far as I know, VS COBOL uses SVC 11 (TIME) to get time and > date. There is no SVC 11 format which returns century indicator The COBOL Standard states that all COBOL language other than Intrinsic Functions will return 2-digit year dates. It does not matter how COBOL gets the dates or what system it is running on. Therefore, if you write a COBOL program and compile it with either OS/VS COBOL or VS COBOL II then there is no language available to you to get a 4-digit year date. ACCEPT xyz FROM DATE will return a correct 2-digit year date in all IBM COBOL compilers, but it will never return a 4-digit year date without breaking all existing programs and without becoming non-ANSI compliant. The only COBOL language available to get 4-digit year dates is the date/time Intrinsic Functions in COBOL for MVS & VM. To get 4-digit year dates from pre-COBOL for MVS & VM programs: - Call a simple assembler or C routine to use SVC 11 (non-CICS only) - Under CICS, use EXEC CICS FORMATTIME or assembler with STCK instruction - Run VS COBOL II programs under LE and use dynamic CALLs to access the LE date/time services. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 02:26:26 on 97/03/03 GMT (by SYYEH at TAIVM1) Subject: PC printer 5577-HC2 Y2k status In facing Y2k challeng,many customers used PC printer(5577-HC2,5577-KC2) .they requested us to provide whether the printer are Y2k ready ? As I know,this question had been discussed before in Year2000 CFORUM,but still no answer. what is status now ? ----- YEAR2000 CFORUM appended at 12:13:07 on 97/03/03 GMT (by IYORK at KGNVMC) Subject: PC printer 5577-HC2 Y2k status Ref: Append at 02:26:26 on 97/03/03 GMT (by SYYEH at TAIVM1) The 5577 is developed by another company called APTi which is a joint venture between IBM and Tokyo Electric Company which means it may take a little longer to get the status. The research is already in progress due to an earlier request, so as soon as I find out, I'll post it. Iris ----- YEAR2000 CFORUM appended at 19:25:15 on 97/03/03 GMT (by TTLAM at SFOVMIC1) Subject: IBM Internal clock runs only until December 31 2041 Could you help me to clarify a statement that was made by one of the customer's software vendor. In their response, this is what they said 'The current limitation in Licensor's products on date and fields applying only until December 31, 2041 is based on IBM's internal clock, which runs only until such date. ............' Thanks Thomas Lam ----- YEAR2000 CFORUM appended at 00:42:40 on 97/03/04 GMT (by AS103033 at ELINK) Subject: IBM Internal clock runs only until December 31 2041 Ref: Append at 19:25:15 on 97/03/03 GMT (by TTLAM at SFOVMIC1) >'The current limitation in Licensor's products on date and fields >applying only until December 31, 2041 is based on IBM's internal clock, >which runs only until such date. ............' Close, but not quite... IBM S/370 S/390 systems use a hardware register called the Time Of Day (TOD) clock. The way the TOD clock is used by the operating systems, it will wrap back to zero in September 2042. So, the above date is the last year-end before the TOD clock wraps. Maybe the products in question do some sort of calculation in units of years? Andy Wood This append was created on the External IBMLink system by Westpac Banking Corp ----- YEAR2000 CFORUM appended at 01:34:39 on 97/03/04 GMT (by ALANDP at SYDVMXA2) Subject: COBOL and Y2K on the VSE Platform ========================================== The COBOL/VSE for VSE/ESA compiler is available today and provides full 4-digit year support including intrinsic functions. Language Environment for VSE/ESA (LE/VSE) provides additional date-manipulation with the LE/VSE Callable Services. The Year2000-ready versions are of VSE and COBOL are: VSE/ESA 2.2 VSE/ESA 1.4.2 (+PTFs) IBM COBOL for VSE/ESA 1.1 These components have full operating system enablement of the 4-digit years and can cope with all aspects of the Year 2000 Challenge. When tackling the Year 2000, IBM feels, as a rule, that it is best to move to the latest technology. For clients using VS COBOL II, the suggested migration route is to move the old COBOL run-time libraries to Language Environment and then re-compile with the COBOL for VSE/ESA compiler. IBM Language Environment for VSE/ESA also provides a valuable short-term solution with the sliding-window feature. If you are unable to change all of your applications or data at the same time, this feature allows 2-digit dates to be interpreted in a 100-year window. A 2-digit date is passed to LE and a 4-digit datre is returned. It must be stressed that this is a temporary solution and the window technology must be replaced with 4-digit support when the time allows. Note that VS COBOL II may use the date/time services of LE/VSE dynamically but does not itself support 4-digit years. From COBOL for VSE programs the date/time services can be called statically or dynamically. ----- YEAR2000 CFORUM appended at 02:31:24 on 97/03/04 GMT (by GAD at KGNVMC) - Subject: IBM Internal clock runs only until December 31 2041 Ref: Append at 19:25:15 on 97/03/03 GMT (by TTLAM at SFOVMIC1) The current 8 byte TOD clock value stored in response to a STCK instruction *will* wrap in 2042. If an application is storing the date in TOD clock format they certainly have a problem. There is consideration already being done today on how to deal with this. There is no solution that can be given at this time, though, beyond *not* storing dates in TOD clock format and instead using binary, decimal, or character format. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 04:12:34 on 97/03/04 GMT (by ALANDP at SYDVMXA2) Subject: Testing the Year2000 Enabled VSE/ESA ============================================= To test your Year2000 enabled operating system, you should provide for a separate isolated test system. This can be: . A separate logical partition(LPAR). VSE/ESA can run with the TOD-clock set in the future in a Processor Resource/Systems Manager(PR/SM) LPAR. If you have a non-IBM system that has a feature similar to PR/SM you should check that it has the same functionality. . A virtual machine running under VM/ESA. If you are running VM/ESA V2 you can set the TOD-clock in the future for a guest operating system. To allow for the virtual TOD-clock setting add the TODENABLE parameter in the OPTIONS card in the directory entry for the guest virtual machine. . A sparate processor. This can be any type of processor that is Year2000 enabled, such as an IBM PC Server s/390 or an RS/6000 and S/390 Server-on-Board. The most important thing to remember is to totally isolate your DASD. This is to ensure that you don't affect production data with your year 2000 testing. ----- YEAR2000 CFORUM appended at 10:13:22 on 97/03/04 GMT (by WATKISS at NHBVM9) Subject: Year 2000 compliance for CDIM Hi, Does anyone know details as to whether this product is Year 2000 compliant and tested. Or if there are plans to make it so in the near future. * CDIM - Change Delivery and Implementation Manager It is not mentioned in the Year 2000 Guide (5th). Thanks for your help with this Stewart Watkiss WATKISS at NHBVM9 Network Services (EMEA) SNA Network Implementation & Support ----- YEAR2000 CFORUM appended at 10:44:20 on 97/03/04 GMT (by 36602370 at EHONE) Subject: VS COBOL II ACCEPT Ref: Append at 00:00:18 on 97/03/02 GMT (by Y2KTSC3 at STLVM6) Before everyone reinvents the wheel for VS COBOL II, APAR PN76666 adds a new routine to Cobol II. IGZEDT4, this is an assembler function that utilises SVC 11 and gives a 4 digit year. You cannot utilise this function without inserting source code and recompiling your COB-II programs. This function does NOT replace any existing Cobol functionality (such as accept). This is the ONLY way you will get a 4 digit year out of cobol, regardless of what runtime library support you have. Paul Smith ----- YEAR2000 CFORUM appended at 12:16:54 on 97/03/04 GMT (by 62418658 at EHONE) Subject: Testing the Year2000 Enabled VSE/ESA Ref: Append at 04:12:34 on 97/03/04 GMT (by ALANDP at SYDVMXA2) Setting the TOD clock of a virtual machine individually is possible since long, and you don't need VM/ESA Version 2. VM/ESA Version 2.2 adds the full Y2000 compliance to CP, CMS, GCS..., but for a VSE/ESA virtual machine, nothing has changed and a VM/ESA Version 1 will do as well for testing the guest systems. This is only a technical remark. Other considerations apply as well, such as having a supported VM/ESA system... (VM/ESA 1.2.2 at least). Guy De Ceulaer - VM Support - Belgium ----- YEAR2000 CFORUM appended at 21:49:47 on 97/03/04 GMT (by Y2KTSC3 at STLVM6) Subject: OS/VS COBOL applications with multiple enclaves restriction Ref: Append at 07:18:33 on 97/02/27 GMT (by ALANDP at SYDVMXA2) >> 3.2.2 Determining Which Programs Require Upgrade >> OS/VS COBOL Programs in More than One Enclave: Under >> Language Environment, OS/VS COBOL programs cannot be in >> more than one enclave. >> Multiple enclaves can be created in several ways: >> When an OS/VS COBOL program CALLs an assembler program, >> which in turn issues an SVC LINK to another OS/VS COBOL program. >The client has asked "Can IBM eliminate this restriction?". The answer is NO, this question was answered on the LE CFORUM. >Is there any word on this? See the LE CFORUM Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 21:54:32 on 97/03/04 GMT (by Y2KTSC3 at STLVM6) Subject: VS COBOL II ACCEPT Ref: Append at 10:44:20 on 97/03/04 GMT (by 36602370 at EHONE) >This is the ONLY way you will get a 4 digit year out of COBOL, >regardless of what runtime library support you have. This is INCORRECT, please disregard. You can get 4-digit year dates from VS COBOL II programs using LE services if they are running under LE. In addition, the LE services are available under CICS and under VSE, where IGZEDT4 is not available. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 01:42:00 on 97/03/05 GMT (by ALANDP at SYDVMXA2) Subject: LE/VSE date routines ============================= There is a discrepancy between the base date for COBOL and the base date for LE/VSE. COBOL for VSE/ESA 1st January 1601 (Gregorian date - ISO Standard) LE/VSE 15th October 1582 (Lilian date) In MVS & VM this difference can be eliminated by using the INTDATE compiler option of COBOL. If you set the installation default to be INTDATE(LILIAN) then your COBOL Intrinsic Functions will use the LE/370 start date. This facility will be available in VSE/ESA as part of a general PTF in 2Q97 giving improved date-functionality in VSE. Note: Using the 'INTDATE(LILIAN)' approach will give the callable services and intrinsic functions a common base point - except 'CEECBLDY' which will still use the ISO standard as its base. Use 'CEEDAYS' instead. ----- YEAR2000 CFORUM appended at 09:06:26 on 97/03/05 GMT (by DROSOS at JEDVM1) Subject: OS/VS COBOL & COBOL II Pre-reqs Ref: The y2k and 2 digit dates: planning & Impl guide (6th edition) mentions pre-reqs for migrating directly from cobol vs to cobol MVS. The question is where can I find what these pre-reqs are??????? Thanks. Drosos Demetriades. drosos@vnet.ibm.com or drosos at jedvm1 ----- YEAR2000 CFORUM appended at 10:44:59 on 97/03/05 GMT (by 9WARLTK at CROVM4) Subject: COBOL and Y2K on the VSE Platform Ref: Append at 01:34:39 on 97/03/04 GMT (by ALANDP at SYDVMXA2) >> A 2-digit date is passed to LE and a 4-digit datre is returned. Hello Alan, I think this should say: You pass a valid date containing a 2-digit year to Language Environment and Language Environment returns an integer date based on the 100-year window. You then convert the integer date back to a Gregorian date to obtain the 4-digit year. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 16:59:09 on 97/03/05 GMT (by JSTEWART at RHQVM22) Subject: ADF and YEAR 2000 Ref: Append at 13:34:09 on 97/02/20 GMT (by BEGENB09 at ELINK) Hello Alex, Years ago I used to be part of the ADF support group and I don't believe you will have any problems with ADF 1.3 and year 2000. ADF 1.3 does not calculate dates or have any internal date handling routines so there won't be any problems with the century change. Your system date will display as 01/01/00 (MM/DD/YY) since ADF 1.3 does not have 8 character date fields. The ADF audit language does not have any date calulation routines, like those of SQL, so there won't be any century problems in that area, either. One area of concern that I can think of would involve any customer-written exits that are called by ADF. ADF 1.3 only supports a 6 character date. If exits are modified for 8 character dates there will be truncation if those exits attempt to return a Year 2000 date back to an ADF 1.3 date-type field. Jim Stewart ----- YEAR2000 CFORUM appended at 17:49:25 on 97/03/05 GMT (by GBCAIH08 at ELINK) Subject: Converting Julian date to DD/MM/YY Does anyone have a method of converting the Julian date, i.e. 97064 to the format 05/03/97 or even 05/03/1997. I have seen the LE manuals. There are functions provided for converting Lilian format, but not for Julian format. Regards, This append was created on the External IBMLink system by Eric Brunner - GBCAIH08 Senior Systems Programmer Thames Water Utilities Ltd. ----- YEAR2000 CFORUM appended at 18:00:00 on 97/03/05 GMT (by Y2KTSC1 at STLVM6) Subject: Converting Julian date to DD/MM/YY Ref: Append at 17:49:25 on 97/03/05 GMT (by GBCAIH08 at ELINK) Try the following algorithm: Input: YYYYNNN (where NNN is 1-366) Output: MM, DD, DOW (where DOW is day-of-week with 0=Sunday, 1=Monday, etc.) IF MOD(YYYY,4) = 0 THEN LY = 1 ELSE LY = 0 IF MOD(YYYY,100) = 0 THEN LY = 0 IF MOD(YYYY,400) = 0 THEN LY = 1 (LY is 1 if it is a leap year) WORK = NNN IF WORK > (LY + 59) THEN WORK = WORK + 2 - LY MM = INT(((WORK + 91) * 100) / 3055) DD = (WORK + 91) - INT((MM * 3055) / 100) MM = MM - 2; T = INT(YYYY / 100) - 6 - INT(YYYY / 400) DOW = MOD((NNN + INT((YYYY * 5) / 4) - LY - T),7) Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 19:27:38 on 97/03/05 GMT (by SORBERT at PKMFGVM3) Subject: Converting Julian date to DD/MM/YY Ref: Append at 18:00:00 on 97/03/05 GMT (by Y2KTSC1 at STLVM6) I tried the conversion exec. What is the MOD function ??? It didn't work on my VM/ESA system. Tom ----- YEAR2000 CFORUM appended at 19:41:36 on 97/03/05 GMT (by Y2KTSC1 at STLVM6) Subject: Converting Julian date to DD/MM/YY Ref: Append at 19:27:38 on 97/03/05 GMT (by SORBERT at PKMFGVM3) MOD is the modulo function. Most languages have that as either an operator or a built-in function. It is the remainder of the division. Year 2000 Technical Support Center Web Master ----- YEAR2000 CFORUM appended at 19:50:13 on 97/03/05 GMT (by SUTHISIL at BKKVMCC1) Subject: Converting Julian date to DD/MM/YY Ref: Append at 19:41:36 on 97/03/05 GMT (by Y2KTSC1 at STLVM6) The MOD function under REXX VM is the double slash "//" Suthisilp Jamnarnwej ----- YEAR2000 CFORUM appended at 08:23:32 on 97/03/06 GMT (by 62418658 at EHONE) Subject: Converting Julian date to DD/MM/YY Ref: Append at 17:49:25 on 97/03/05 GMT (by GBCAIH08 at ELINK) See DATECNV in DATEY2K PACKAGE on VMTOOLS Guy De Ceulaer - VM Support - Belgium ----- YEAR2000 CFORUM appended at 10:08:06 on 97/03/07 GMT (by ZAC3ST11 at ELINK) Subject: Vtam connectivity We would like to provide VTAM connectivity between our Y2K CMOS box that is completely isolated ( No shared dasd/CU's etc...) and our development systems. We would like to use 37x5 or CTC type connectivity or can something be done using the OSA adaptor and a LAN? What would be the implication for 2 VTAM's when 1 Vtam is running on a machine running with a Jan 2000 date. We are trying to enable development users geographically distant from our centre to logon on to the Y2K box via our normal development system network. Thks in advance This append was created on the External IBMLink system by Nigel Hislop. Standard Bank of South Africa. Hislop_N@ceo.sbic.co.za ZASBSRHS on IBMMAIL ----- YEAR2000 CFORUM appended at 23:16:57 on 97/03/07 GMT (by IYORK at KGNVMC) Subject: RE: YEAR2000 COMPLIANT PRODUCTS Ref: Append at 20:33:15 on 97/02/28 GMT (by LESENDEL at LASVM1) 5785-EEG Expedite/CICS was withdrawn. It is not year 2000 ready. The follow on is Expedite/CICS 4.2. It is not year 2000 ready. However, watch this space and I will post an update later this month. Iris ----- YEAR2000 CFORUM appended at 01:50:01 on 97/03/08 GMT (by Y2KTSC3 at STLVM6) Subject: OS/VS COBOL & VS COBOL II Pre-reqs Ref: Append at 09:06:26 on 97/03/05 GMT (by DROSOS at JEDVM1) >The y2k and 2 digit dates: planning & Impl guide (6th edition) mentions >pre-reqs for migrating directly from OS/VS COBOL to COBOL for MVS & VM. >The question is where can I find what these pre-reqs are??????? See the COBOL Migration Guide, GC26-4764. It is on the Web at www.software.ibm.com/year2000 (in the bookshelf) Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 02:01:54 on 97/03/08 GMT (by Y2KTSC3 at STLVM6) Subject: Converting Julian date to DD/MM/YY Ref: Append at 17:49:25 on 97/03/05 GMT (by GBCAIH08 at ELINK) >Does anyone have a method of converting the Julian date, >i.e. 97064 to the format 05/03/97 or even 05/03/1997. >I have seen the LE manuals. There are functions provided for >converting Lilian format, but not for Julian format. With both LE and COBOL you would convert to integer and then to Gregorian, IE: CALL 'CEEDAYS' USING YYDDD PICSTR1 LILIAN FC. CALL 'CEEDATE' USING LILIAN PICSTR2 MMDDYYYY FC. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 21:44:31 on 97/03/09 GMT (by IL35816 at ELINK) Subject: Vtam connectivity Ref: Append at 10:08:06 on 97/03/07 GMT (by ZAC3ST11 at ELINK) All of the above are possible. One significant question is 390 O/S because of different support of LAN devices. You might try the question in the VTAM CFORUM assuming you have access (TalkLink is idiosyncratic I know). Why not ask how to do your first choice because as I said, all of your methods are possible. My *guess* is that VTAM will not mind a 3-year date discrepancy between domains. Charles Mills Firesign Computer Company, San Francisco charlesm@firesign.com ----- YEAR2000 CFORUM appended at 06:56:19 on 97/03/10 GMT (by ZAC3ST11 at ELINK) Subject: Vtam connectivity Ref: Append at 21:44:31 on 97/03/09 GMT (by IL35816 at ELINK) Thanks Charles. My concern, of course, is your last comment. Will VTAM mind the 3 year discrepancy ? I'll post this to the VTAM forum, if I can get to it. Thks Nigel This append was created on the External IBMLink system by Nigel Hislop. Standard Bank of South Africa. Hislop_N@ceo.sbic.co.za ZASBSRHS on IBMMAIL ----- YEAR2000 CFORUM appended at 10:11:35 on 97/03/10 GMT (by 9WARLTK at CROVM4) ..... YEAR2000 CFORUM modified at 16:56:06 on 97/03/10 GMT (by 9WARLTK at CROVM4) Subject: Converting Julian date to DD/MM/YY Ref: Append at 17:49:25 on 97/03/05 GMT (by GBCAIH08 at ELINK) >Does anyone have a method of converting the Julian date, >i.e. 97064 to the format 05/03/97 or even 05/03/1997. >I have seen the LE manuals. There are functions provided for >converting Lilian format, but not for Julian format. Eric, If you put a century at the front of your 97064, you can use the COBOL Intrinsic Functions: INTEGER-OF-DAY to convert from YYYYDDD to integer date form and then DATE-OF-INTEGER to convert from integer date form to YYYYMMDD such as COMPUTE GREGORIAN = FUNCTION DATE-OF-INTEGER (FUNCTION INTEGER-OF-DAY (JULIAN)) See pages 443 and 438 of SC26-4769-01 COBOL Language Reference. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 10:19:41 on 97/03/10 GMT (by BEGENB09 at ELINK) Subject: ADF and YEAR 2000 Ref: Append at 16:59:09 on 97/03/05 GMT (by JSTEWART at RHQVM22) Hello Jim, Thanks for your answer. We already started the tests, not on a Year2000 machine but using Viasoft's VALIDATE product. This tool can simulate a date for all applications which get the system date using a SVC11. For the test we isolated some ADF transactions in a dedicated MPP region. We seem to have a problem when we specify in audit language a piece of coding like : MAD9ARGF = $DATE IF MAD9ARGF > '870000' MAD9ARGX = '19' ELSE MAD9ARGX = '20' ENDIF The $DATE is a system field which should return the system date in a 6 char field. If we display the target field after this move, we get a strange value like ' ô0329' (we tried to simulate feb-29,2000 as the system date). Do you have any idea or comment on this behaviour, or should we contact IBM, knowing that we are not using the most recent version of ADF ? Thanks in advance Alex Breesch This append was created on the External IBMLink system by Alex Breesch Generale Bank Belgium Development Support tel. +32.2/565.43.44 fax. +32.2/565.24.20 ----- YEAR2000 CFORUM appended at 10:38:24 on 97/03/10 GMT (by 9WARLTK at CROVM4) ..... YEAR2000 CFORUM modified at 17:02:29 on 97/03/10 GMT (by 9WARLTK at CROVM4) Subject: OS/VS COBOL & VS COBOL II Pre-reqs Ref: Append at 09:06:26 on 97/03/05 GMT (by DROSOS at JEDVM1) >The y2k and 2 digit dates: planning & Impl guide (6th edition) mentions >pre-reqs for migrating directly from OS/VS COBOL to COBOL for MVS & VM. >The question is where can I find what these pre-reqs are??????? Drosos, The y2k and 2 digit dates: planning & Impl guide (6th edition) page 8-11 Migrating from OS/VS COBOL 1. OS/VS COBOL to COBOL for MVS & VM says: See the Language Environment for MVS & VM Licensed Program Specification for prerequisite information.. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 12:54:23 on 97/03/10 GMT (by GBCBHG00 at ELINK) Subject: Vtam connectivity Ref: Append at 06:56:19 on 97/03/10 GMT (by ZAC3ST11 at ELINK) Nigel, Just for completeness can you post the response here please. This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 13:47:30 on 97/03/10 GMT (by GAD at KGNVMC) - Subject: Vtam connectivity Ref: Append at 06:56:19 on 97/03/10 GMT (by ZAC3ST11 at ELINK) VTAM does *not* care if the dates are close. I have seen this done during internal testing of MVS for year2000 readyness, with the test system date being 5 years after the proper year. No problem. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 15:33:47 on 97/03/10 GMT (by CODDP at NHBVM1) LANGUAGE MIGRATION INFOMATION FOR FORTRAN THERE IS A LARGE AMOUNT OF INFORMATION ABOUT LANGUAGE MIGRATION FOR LEVELS OF COBOL - USE OF CCCA ETC. MY CUSTOMER WOULD BE INTERESTED IN A SUMMARY OR KEY POINTS TO BE AWARE OF WHEN MIGRATING THROUGH LEVELS OF FORTRAN, PRIOR TO BEGINNING MILLENIUM FUNCTIONAL CORRECTIONS. THE INSTALLED VERSION IS LEVEL 1.4.2, A LONG WAY FROM THE CURRENT VERSIONS. ----- YEAR2000 CFORUM appended at 15:48:59 on 97/03/10 GMT (by CREMA at STLVM1) Subject: LANGUAGE MIGRATION INFOMATION FOR FORTRAN Ref: Append at 15:33:47 on 97/03/10 GMT (by CODDP at NHBVM1) >LANGUAGE MIGRATION INFOMATION FOR FORTRAN >THERE IS A LARGE AMOUNT OF INFORMATION ABOUT LANGUAGE MIGRATION FOR >LEVELS OF COBOL - USE OF CCCA ETC. MY CUSTOMER WOULD BE INTERESTED >IN A SUMMARY OR KEY POINTS TO BE AWARE OF WHEN MIGRATING THROUGH >LEVELS OF FORTRAN, PRIOR TO BEGINNING MILLENIUM FUNCTIONAL CORRECTIONS. >THE INSTALLED VERSION IS LEVEL 1.4.2, A LONG WAY FROM THE CURRENT >VERSIONS. For Fortran migration, see IBM Language Environment for MVS & VM Fortran Run-Time Migration Guide SC26-8499 Alice Crema IBM COBOL Family Support ----- YEAR2000 CFORUM appended at 18:07:54 on 97/03/10 GMT (by DRSCHAA at CHGVMIC1) Subject: 28 Year Interval for Y2K testing Aging Y2K converted data by 28 years is supposed to provide a calendar in which the days match exactly those of the original year, causing month end, year end, etc., to fall on the same day and date. This, of course, can prove to be valuable in testing Y2K changes. I have heard a report that the 28-year rule will NOT work when it crosses 2000. My under- standing is the opposite. It normally doesn't work crossing a century because except every 400 years the century doesn't have a leap year, and consequently breaks the 28-year sequence. Since the year 2000 will have a leap year, the 28-year rule WILL work. Is this a correct view of this rule? If not, what is? ----- YEAR2000 CFORUM appended at 18:51:25 on 97/03/10 GMT (by BARD018 at ELINK) Subject: IBM Internal clock runs only until December 31 2041 Ref: Append at 19:25:15 on 97/03/03 GMT (by TTLAM at SFOVMIC1) The exact time is 2042/09/17 23:53:47.370495, if you care. Chen-yu Hu C. R. Bard, Inc. Murray Hill, NJ, USA chen-yu.hu@ccmail.crbard.com (908) 277-8512 ----- YEAR2000 CFORUM appended at 18:53:42 on 97/03/10 GMT (by BARD018 at ELINK) Subject: 28 Year Interval for Y2K testing Ref: Append at 18:07:54 on 97/03/10 GMT (by DRSCHAA at CHGVMIC1) I guess you are correct except to compute Easter. But you have to *modify* programs to substract 28 years after reading input, and add 28 years before writing output. If you need to modify programs to buy 28 (or 56) years, why not adopt a permanent solution? Chen-yu Hu C. R. Bard, Inc. Murray Hill, NJ, USA chen-yu.hu@ccmail.crbard.com (908) 277-8512 ----- YEAR2000 CFORUM appended at 19:17:40 on 97/03/10 GMT (by IYORK at KGNVMC) Subject: ADF and YEAR 2000 Ref: Append at 13:34:09 on 97/02/20 GMT (by BEGENB09 at ELINK) Alex, Could you please tell me which ADF 1.3 you are referring to? Is it IMSADF II V1 (product number 5668-937) or the earlier ADF (without the II). Thanks. Iris ----- YEAR2000 CFORUM appended at 22:23:09 on 97/03/10 GMT (by Y2KTSC3 at STLVM6) Subject: MVS/ESA 4.3 Ref: Append at 17:03:30 on 97/02/20 GMT (by GBCADH00 at ELINK) >> Most shops should not do any "Time Machine" (changed system clock) >> until 1999. >Would you please give some background to that statement. The only >true test is a changed system clock - even with simulators there is >little guarantee that EVERY occurence will be picked up. To find that >applications changes (or subsystem software) is flawed as late as >1999 gives very little time for remedial action. My reasoning for that statement is that between now and 1999 most shops should only be concerned with changing their applications to use 4-digit dates and with migrating to Year 2000 Ready software (system, 3rd party, everything). Until many applications and all of the system software is Year 2000 Ready there is little reason to do Time Machine testing. You know you will find faults with non-Ready system software, and you can't fix those! Setting up a Time Machine and keeping it isolated is expensive, so I feel that customers will be better off delaying that step until near the end of the Year 2000 conversion. Date simulators will be good enough for Year 2000 Unit Testing of applications, and working on the applications is most of the Year 2000 conversion effort. The Time Machine test is to validate that all of the pieces together work correctly, as you state. I think that using a Time Machine for Unit Testing of application code is overkill. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 00:07:14 on 97/03/11 GMT (by YAEGER at SJFEVMX) ..... YEAR2000 CFORUM modified at 21:14:08 on 97/03/28 GMT (by YAEGER at SJFEVMX) Subject: DFSORT/MVS and DFSORT/VSE Year 2000 Teleconference | If you haven't signed up yet, you still can. The IBM Teleconferencing Series Presents ... DFSORT/MVS and DFSORT/VSE - The Year 2000 and Beyond Date: April 1, 1997 Subject: Join us to learn about the Year 2000 Features of IBM's powerful and flexible System/390 sorting, reporting, and analysis products, DFSORT/MVS and DFSORT/VSE. We'll explain these features in detail and show examples of how to sort, merge, transform, and report on all kinds of two-digit year dates using a fixed or sliding century window. Featured Speaker: Frank Yaeger, DFSORT Senior Programmer To register: Call American Teleconferencing Services at 1-800-289-0583 and request one of the following sessions: * 10:30am Eastern Time (session #287284) * 2:30pm Eastern Time (session #287287) There is no charge for this customer teleconference. Frank L. Yaeger - DFSORT Team (Specialties: ICETOOL, OUTFIL, Y2K :-) => DFSORT/MVS is on the WWW at http://www.storage.ibm.com/software/sort/srtmhome.htm => DFSORT/VSE is on the WWW at http://www.storage.ibm.com/software/sort/srtvhome.htm ----- YEAR2000 CFORUM appended at 08:18:17 on 97/03/11 GMT (by ZAC3ST11 at ELINK) Subject: Vtam connectivity Ref: Append at 13:47:30 on 97/03/10 GMT (by GAD at KGNVMC) Peter, this is the only posting to the VTAM forum so far. -------------------------------------------------------------- VTAM passes the time and date to NCP on activation, but it does not exchange time and date to other SSCPs or resources in the network, from what I can remember. It should work fine, however, as with any other change, I would strongly suggest trying this in your test network before moving it to production. Chuck Gardiner cag@raleigh.ibm.com --------------------------------------------------------------- - This append was created on the External IBMLink system by Nigel Hislop. Standard Bank of South Africa. Hislop_N@ceo.sbic.co.za ZASBSRHS on IBMMAIL ----- YEAR2000 CFORUM appended at 09:01:42 on 97/03/11 GMT (by BEGENB09 at ELINK) Subject: ADF and YEAR 2000 Ref: Append at 19:17:40 on 97/03/10 GMT (by IYORK at KGNVMC) Iris, The version we have is indeed IMSADF II V1 (product number 5668-937). Thanks in advance for all comments. Regards, Alex Breesch This append was created on the External IBMLink system by Alex Breesch Generale Bank Belgium Development Support tel. +32.2/565.43.44 fax. +32.2/565.24.20 ----- YEAR2000 CFORUM appended at 12:28:09 on 97/03/11 GMT (by IYORK at KGNVMC) Subject: ADF and YEAR 2000 Ref: Append at 09:01:42 on 97/03/11 GMT (by BEGENB09 at ELINK) Alex, I just spoke to someone yesterday who works on the product and he said ADF II V1 has dates. I'll try to get more info and post later. Iris ----- YEAR2000 CFORUM appended at 14:18:45 on 97/03/11 GMT (by GBCBHG00 at ELINK) Subject: Y2K Time machine tests A considerable ammount has been said on many subject including testing, but I would like to throw a concern for those of you tesing on a time machine be it HW or SW based. Your testing may well work, but might I emphasise that you are not testing *YOUR* system. Once you have modified and tested your code on a test system you *MUST* eventually integrate and system test on *YOUR LIVE SYSTEM*. I say this with no hesitation and justify my statement as follows: When testing on a time machine (HW or SW), you are only unit testing your applications. Your production environment comprises hardware, software and a network which (I hope) will also be tested. These tests are unit tests of each component. Only when you run your year 2000 compliant application on your year 2000 compliant hardware with your year 2000 compliant software over your year2000 compliant network are you actually system testing your entire environment. It is unacceptable to say you have completed your year2000 project if you have tested your software/application/hardware/network individualy on time machine(s). They must all eventully be tested together, in your production environmen This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 14:28:24 on 97/03/11 GMT (by Y2KTSC5 at STLVM6) Subject: IBM System Software Release Levels needed to handle Y2K Ref: Append at 01:39:25 on 97/02/21 GMT (by MPRINCIP at RHQVM09) The best place for you to start looking for information on the products you listed is in: 'The Year 2000 & 2-Digit Dates: A Guide for Planning and Implementation' IBM Document number GC28-1251-xx. The manual is free in several formats from our internet site at URL: http://www.software.ibm.com/year2000/index.html AND http://www.software.ibm.com/year2000 We will also send you an information document on COBOL and the Year 2000. If you have more Year 2000 related questions, please feel free to contact us at 1-800-IBM-4YOU or E-Mail us at Y2KTSC at VNET.IBM.COM Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 15:03:53 on 97/03/12 GMT (by 86617495 at EHONE) Subject: IBM System Software Release Levels needed to handle Y2K Ref: Append at 14:28:24 on 97/03/11 GMT (by Y2KTSC5 at STLVM6) You mention an 'information document on cobol and the year 2000'. Is this something that is generally available? If so can you point me at a place where I can read it please. (I am engaged in year 2000 cobol work here in UK.) Thanks. Ian Junor (crovm4(junori)) ----- YEAR2000 CFORUM appended at 07:07:38 on 97/03/14 GMT (by ANGUSK at SYDVMXA2) Subject: IBM System Software Release Levels needed to handle Y2K Ref: Append at 15:03:53 on 97/03/12 GMT (by 86617495 at EHONE) >You mention an 'information document on cobol and the year 2000'. >Is this something that is generally available? If so can you point >me at a place where I can read it please. (I am engaged in year 2000 >cobol work here in UK.) There is lots of useful information in the bookshelf at IBM's Year 2000 Technical Support Center, located on the Web at www.software.ibm.com/year2000 This includes: The COBOL Migration Guide, GC26-4764. (under IBM Language Migration Manuals) Meeting the COBOL Year 2000 Challenge (under Process Specific Papers) and several COBOL specific papers (under COBOL Specific Papers), and of course the Year 2000 Guide (under Customer Guidance Paper) Year 2000 Technical Support Center - Asia Pacific ----- YEAR2000 CFORUM appended at 17:16:14 on 97/03/14 GMT (by 70607825 at EHONE) Subject: LPAR and year 2000 hello, My customer wish to build an LPAR partition to test its applications for Year 2000. But he has a Parallel Sysplex and so a 9037 sysplex timer . Can somebody tell me how to proceed to IPL at 02 01 2000 ? Many thanks in advance Andre ----- YEAR2000 CFORUM appended at 17:45:16 on 97/03/14 GMT (by GAD at KGNVMC) - Subject: LPAR and year 2000 Ref: Append at 17:16:14 on 97/03/14 GMT (by 70607825 at EHONE) The CLOCKxx member must specify ETRMODE NO, TIMEZONE d.hh.mm.ss, and OPERATOR PROMPT. When the first message IEA888A is issued respond with DATE=2000.032,GMT to force the TOD to be set with the new date. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 22:52:07 on 97/03/14 GMT (by WAWA001 at EHONE7) ..... YEAR2000 CFORUM modified at 21:10:09 on 97/03/19 GMT (by WAWA001 at ELINK) ----- YEAR2000 CFORUM appended at 15:52:23 on 97/03/17 GMT (by U37CONT at RHQVM19) Subject: Lunacon '97 A couple of buttons I picked up at the local NYC SF convention: Old code never dies. It just waits for the year 2000. Quietly. Caution: Objects in calendar are closer than they appear Treesong (Philip M. Cohen), IBM Litigation, TL 351-4742 - 10:52:18 EDT ----- YEAR2000 CFORUM appended at 17:37:40 on 97/03/17 GMT (by 9WARLTK at CROVM4) Subject: PL/l DATE and DATETIME functions Could you let me know if both of these functions are YEAR2000 ready in PL/l for MVS & VM V1 R1, product number 5688-235. In particular will the DATE function return '01' for the year in 2001? TIA, Keith Warltier, Year2000 & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 18:29:54 on 97/03/17 GMT (by HUYKHAC at SJFEVMX) Subject: PL/l DATE and DATETIME functions Ref: Append at 17:37:40 on 97/03/17 GMT (by 9WARLTK at CROVM4) PL/I for MVS & VM is year 2000 ready.The year portion of the return value from DATE and DATETIME builtin functions will be 01 and 2001, respectively, for year 2001. Huy K. Le ----- YEAR2000 CFORUM appended at 20:30:08 on 97/03/17 GMT (by LATORRES at LASVM1) From: LA Technical Support Center/Argentina/IBM To: Keith Warltier Date: 03-17-97 17:15:23 Subject: PL/I DATE and DATETIME functions Hi Keith, PL/I for MVS & VM V1 R1, product number 5688-235, is year2000 Ready, as The Year 2000 and 2-Digits dates: Guide for Planning and Implementation (GC28-1251-05) states. About the DATETIME and DATE functions, the books explain the following: DATETIME returns a character string, length 17, in the format of yyyymmddhhmmssttt. The syntax for DATETIME is: >>__DATETIME__ ______ ___________ |_(__)_| The returned character string represents: yyyy Current year mm Current month dd Current day hh Current hour mm Current minute ss Current second ttt Current millisecond The time zone and accuracy are system dependent. DATE returns a character string, length 6, in the format of yymmdd. The syntax for DATE is: >>__DATE__ ______ _____________ |_(__)_| The returned character string represents: yy Last two digits of the current year mm Current month dd Current day The time zone and accuracy are system dependent. For further information, feel free to contact us. LA Technical Support Center. ----- YEAR2000 CFORUM appended at 00:00:10 on 97/03/19 GMT (by Y2KTSC3 at STLVM6) Subject: LPAR and year 2000 Ref: Append at 17:16:14 on 97/03/14 GMT (by 70607825 at EHONE) >My customer wish to build an LPAR partition to test its applications >for Year 2000. >But he has a Parallel Sysplex and so a 9037 sysplex timer . >Can somebody tell me how to proceed to IPL at 02 01 2000 ? Before you do make sure that the LPAR is not connected to production DASD. Even read only accesses can corrupt your catalogs. In addition, year 2000 testing of applications can be done more easily using date simulators, you might want to consider that. "Time Machines" are a lot of work and hassle. You may just end up running into known problems with old system software or vendor code with expriation dates. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 13:33:29 on 97/03/19 GMT (by IYORK at KGNVMC) Subject: PC printer 5577-HC2 Y2k status Ref: Append at 12:13:07 on 97/03/03 GMT (by IYORK at KGNVMC) The 5577s are year 2000 ready. In reality they don't use dates. Iris ----- YEAR2000 CFORUM appended at 15:52:50 on 97/03/19 GMT (by FLYOLTON at KGNVMC) SUBJECT: YEAR 2000 PDS CREATION AND MODIFICATION DATES These dates are kept in internal julian dates like 05297 for day 52 in year 1997. 1. Is there any DSECT available (that may be used by the TSO editor) that indicates the new format of USER-DATA that has been written out by the TSO EDITOR when the member is modified? n 2. Does this layout or DSECT have YEAR 2000 changes???????? Frank Yolton ----- YEAR2000 CFORUM appended at 16:43:29 on 97/03/19 GMT (by 86629111 at EHONE) Subject: CICS and Year 2000 compliance My customer is currently on CICS 3.3 and would like to move to CICS 4.1. However, they have major core systems that are based on a package that is still in OS/VS Cobol and will be until the end of 1997. They have been told that OS/VS COBOL will not work with CICS 4.1. They plan to have all applications made Year 2000 compliant by October 1998 and then to move to CICS 4.1 but this means that they will not have tested Year 2000 compliance in a Year 2000 compliant environment. Can you please advise whether doing their Year 2000 testing under CICS 3.3 will be a major risk. (i.e. are there likely to be Year 2000 problems in CICS 3.3 or changes within CICS versions that will alter date processing?) Thanks Valerie Gordon (IBM Year 2000 consultant) NHBVM1(GORDONV) ----- YEAR2000 CFORUM appended at 18:09:39 on 97/03/19 GMT (by BARD018 at ELINK) Subject: YEAR 2000 PDS CREATION AND MODIFICATION DATES Ref: Append at 15:52:50 on 97/03/19 GMT (by FLYOLTON at KGNVMC) With the assumptions that PDS creation and modification dates ==> PDS member creation and .... TSO editor ==> ISPF editor The ISPF statistics format is documented in SC34-4450 "ISPF Messages and Codes". I don't know if there is a DSECT shipped. In the documentation, there is no year 2000 support. I think ISPF will use byte 5 and byte 9 as the century bytes: 0 means 19xx, 1 means 20xx. Chen-yu Hu C. R. Bard, Inc. Murray Hill, NJ, USA chen-yu.hu@ccmail.crbard.com (908) 277-8512 ----- YEAR2000 CFORUM appended at 19:57:55 on 97/03/19 GMT (by IL68778 at ELINK) Subject: YEAR 2000 PDS CREATION AND MODIFICATION DATES Ref: Append at 18:09:39 on 97/03/19 GMT (by BARD018 at ELINK) This is the DSECT I use to process an SPF Directory Entry (SDE). I'm not sure where I got it or built it from. I *may* have lifted it 20 years ago from the source code of the SPF FDP. SDE DSECT SDENAME DS CL8 MEMBER NAME SDETTR DS XL3 TTR SDELUSER DS B LENGTH OF USER FIELD SDEVERS DS FL1 +00 VERSION NUMBER SDEMOD DS FL1 +01 MOD LEVEL DS XL2 +02 UNUSED (MUST BE ALL X'00') SDECDATE DS P'0077027' +04 CREATION DATE SDEMDATE DS P'0077032' +08 LAST MODIFICATION (DATE) SDEMTIME DS FL1'12,33' +12 LAST MODIFICATION (TIME) SDECLINE DS AL2 +14 NUMBER OF LINES (CURRENT) SDEILINE DS AL2 +16 NUMBER OF LINES (INIT) SDEMLINE DS AL2 +18 NUMBER OF LINES (MODIFIED) SDEID DS CL7 +20 TSO USER-ID SDEID2 DS CL3 +27 UNUSED (MUST BE ALL X'40') SDELNGTH EQU *-SDE +30 SDE LENGTH IS 12+4+(15*2) Gilbert Saint-flour Automated Migration Services IBMMAIL(USS24LG4) IBMLINK(IL68778) ----- YEAR2000 CFORUM appended at 22:33:30 on 97/03/19 GMT (by MA00957 at EHONE7) Subject: Version Reconciliation for YR2K Apps. Ref: Append at 01:24:22 on 97/01/22 GMT (by BCOKPOK at NYCVMIC1) Bertram, Unfortunately, we (Princeton Softech) don't normally monitor this forum but I was pleased that the Technical Support Centre (Center) passed on the information. I also appreciate Larry Kahm's kind words on our product, Version Merger. One of the sometimes overlooked issues in the Year2000 process is how to reconcile multiple versions of the source code, copy books, etc. This can occur for a number of reasons such as: > You need to incorporate local customizations into the new version of a vendor's product. > You need to incorporate fixes/enhancements made to the production code after the Year2000 project began into the final Year2000 version. Unfortunately, since many companies are still concentrating on the inventory phase at this point, they haven't looked far enough ahead to understand the reconciliation requirements. Version Merger is the pre-eminent reconciliation product available with hundreds of clients worldwide. We support a variety of languages, source formats, and change control/library management products. Extensive options are available to customize how the versions are compared and automate the reconciliation process. By merging three versions (base, customized code, new version) together simultaneously, Version Merger is uniquely able to show exactly what parts of the code are the same and what is different and why. Furthermore, as Larry mentioned, the primary and line commands available within the editor provide substantial productivity gains as well as help to insure the accuracy of the reconciled version. If you, or anyone else (within IBM or its clients) would like more information on Version Merger or our Relational Tools suite which helps build relational subsets of data and age data into the future for complete testing of Year2000 applications, please contact us at: www.PrincetonSoftech.com info@PrincetonSoftech.com 800/457-7060 or 609/497-0205 (voice) 609/497-0302 (fax) 1060 State Road, Princeton, NJ 08540 Regards, Rich Specht | 609/497-0205 | RichSpecht@PrincetonSoftech.com ----- YEAR2000 CFORUM appended at 02:49:51 on 97/03/20 GMT (by SOEGENGF at SYDVM1) Subject: Y2K testing A customer is setting up an environment for Y2K testing. They will isolate all dasd... except 2 volumes dedicated to the control dataset used by the StorageTek silo manager. The reason is because they will be sharing the silo between the year 2000 LPAR and the production LPAR. STK has suggested that they zap the vtoc on the 2 volumes to bring it back to a current date. There will be no space management done on this 2 volumes. Can anybody comment any potential problems please ? Thanks, Frank Soegeng ----- YEAR2000 CFORUM appended at 16:58:10 on 97/03/20 GMT (by AROJAS at MEXVM2) SUBJECT: OS/VS COBOL UNDER OS/390 I READ THAT THE OS/VS COBOL COMPILER IS NOT SUPPORTED, BUT COMPILED CODE WILL BE. MY QUESTION IS: UNDER OS/390 WILL BE POSSIBLE TO COMPILE PROGRAMS USING OS/VS COBOL VER. 2.4 ? MY CLIENT IS DOING THE CONVERSION TO Y2K BUT THE LEGACY APPS ARE MAINLY IN OS/VS COBOL. THEY ARE DOING AS WELL, THE MIGRATION FROM VMS 4.1 TO OS/390 VER 2.0 IBM MEXICO ARTURO ROJAS ----- YEAR2000 CFORUM appended at 21:19:04 on 97/03/20 GMT (by IYORK at KGNVMC) Subject: ADF and YEAR 2000 Ref: Append at 12:28:09 on 97/03/11 GMT (by IYORK at KGNVMC) Here's more on ADF II. IMSADF II V1 date fields are fields defined as TYPE=DATE. Only 2-character years are allowed in these fields. Date fields are verified by IMSADF for a valid month and day. A check for leap year is also done. The date 02/29/00 may not pass the validation test since the year 2000 is a leap year and 1900 is not. Other than that, what the date field is used for is up to the ADF programmer. A field does not need to be defined as TYPE=DATE to be used as a date field in an ADF application program. ADF will simply not verify it and treats it as any other field. The ADF Tool Pak can assist a programmer in finding fields not defined as TYPE=DATE but has the potential of being used as a date field. Hope that helps. Iris ----- YEAR2000 CFORUM appended at 14:10:40 on 97/03/21 GMT (by BEGENB09 at ELINK) Subject: ADF and YEAR 2000 Ref: Append at 21:19:04 on 97/03/20 GMT (by IYORK at KGNVMC) Hello Iris, Thanks for your answer. What is worrying is, are not the TYPE=DATE fields, but rather the SYSTEM field $DATE. As stated in a previous append, when doing on-line test with date 29/02/2000, we received a strange value of ' ô0329'. When we did the same simulation for a batch generation job of ADF, we got in the listing heading a date of 29/03/ ô. Additional test with other dates, also gave unpredictable results (f.i. 19/03/ ô for 2000.050, 31/03/ ô for 2000.062 and 10/04/ ô for 2000.072). So we think that the problem is not only a leap year problem. If you could get some more information, it would be helpful. Thanks in advance, Alex Breesch This append was created on the External IBMLink system by Alex Breesch Generale Bank Belgium Development Support tel. +32.2/565.43.44 fax. +32.2/565.24.20 ----- YEAR2000 CFORUM appended at 15:28:44 on 97/03/21 GMT (by CREMA at STLVM1) Subject: CICS and Year 2000 compliance Ref: Append at 16:43:29 on 97/03/19 GMT (by 86629111 at EHONE) >Subject: CICS and Year 2000 compliance >My customer is currently on CICS 3.3 and would like to move to CICS 4.1. >However, they have major core systems that are based on a package that >is still in OS/VS Cobol and will be until the end of 1997. They have >been told that OS/VS COBOL will not work with CICS 4.1. >They plan to have all applications made Year 2000 compliant by >October 1998 and then to move to CICS 4.1 but this means that they >will not have tested Year 2000 compliance in a Year 2000 compliant >environment. >Can you please advise whether doing their Year 2000 testing under >CICS 3.3 will be a major risk. (i.e. are there likely to be >Year 2000 problems in CICS 3.3 or changes within CICS versions that >will alter date processing?) >Thanks >Valerie Gordon >(IBM Year 2000 consultant) >NHBVM1(GORDONV) OS/VS COBOL does run with CICS 4.1. OS/VS COBOL is not listed in the CICS 4.1 supported product list because it is a withdrawn product and is not tested by the CICS team. Alice Crema IBM COBOL Family Market/Sales Support ----- YEAR2000 CFORUM appended at 14:08:18 on 97/03/24 GMT (by GBCBDN04 at ELINK) Subject: IMS and DB2 in LPAR with Year 2000 dates for testing This question and its answer were originally asked on the GENTECH forum and is posted here for information and also any further comments. Thanks Greg and Dougie. Thanks in advance for any further thoughts. ... ... ... ... ... ... ... ... ... ... ... ... ... ... Appended at 11:48:12 on 97/03/21 by GBCBDN04 at ELINK. Subject: IMS and DB2 in LPAR with Year 2000 dates for testing Scenario: we wish to test IMS and DB2 with year 2000 dates in an LPAR set to a logical date of 2000 while the underlying clock is set to the real date for production systems on a different LPAR. Will this work or will IMS (or DB2) be reading the base clock date? The TOD clock on the machine will be set to local time (GMT or British Summer Time). The LPAR is not offset from the TOD clock. When MVS is IPL'd, we will set it up so that it prompts us to confirm the date/time. At this point, we will set the date to 1999 (for example). What I want to know is if ALL parts of IMS /DB2 will use the MVS clock (1999 or 2000) or whether some processing in IMS/DB2 will ask the machine for the date/time and bypass the MVS clock. This append was created on the External IBMLink system by John Tanner - ITnet Ltd. (+44) (0)121-459-1155. GBKXFPCF at IBMMAIL. ... ... ... ... ... ... ... ... ... ... ... ... ... ... Subject: IMS and DB2 in LPAR with Year 2000 dates for testing Ref: Append at 11:48:12 on 97/03/21 GMT (by GBCBDN04 at ELINK) This is really a question to ask on the YEAR2000 forum, and has already been answered there. From an operating system point of view, each zone has it's own unique hardware TOD value. That value and *only* that value is used for STCK requests and the like. TOD values set on one zone can not be seen by programs executing in another zone. There is no problem doing what you want to do (but *do* make sure you cause the TOD clock to be changed by using the GMT specification when setting the value at IPL time). Greg Dyck MVS BCP Kernel and CURE support ... ... ... ... ... ... ... ... ... ... ... ... ... ... Appended at 17:29:52 on 97/03/21 by 36601943 at EHONE. Subject: IMS and DB2 in LPAR with Year 2000 dates for testing Ref: Append at 11:48:12 on 97/03/21 GMT (by GBCBDN04 at ELINK) John, Please post this question on the YEAR2000 CFORUM. The book "GC28-1251-05 Year 2000: A Guide to Planning and Implementation" has a chapter on this topic. There is a new edition available on our web site at: http://www.software.ibm.com/year2000 There was a keynote presentation at the IMS and DB2 Technical Conference given by John Leake this week. You may be able to obtain a print of his slides. Dougie Lawson, IBM Basingstoke, UK. (aka 8LAWSOD at NHBVM2) ... ... ... ... ... ... ... ... ... ... ... ... ... ... END OF EXTRACT. This append was created on the External IBMLink system by John Tanner - ITnet Ltd. (+44) (0)121-459-1155. GBKXFPCF at IBMMAIL. ----- YEAR2000 CFORUM appended at 17:58:38 on 97/03/24 GMT (by JSTEWART at RHQVM22) Subject: ADF and YEAR 2000 Ref: Append at 14:10:40 on 97/03/21 GMT (by BEGENB09 at ELINK) Hi Alex, I'm sorry I missed your earlier messages, I don't normally follow this forum and a colleague mentioned to me that ADF was being discussed here. ADF 2.2 is supported but version 1.3 is not covered. Did ADF 1.3 ship with source code? I could track the ADF program that gets the date and time from MVS and if you had the source perhaps you might tweak the code? I'll subscribe to this forum so my replies will be prompt. Kind regards, Jim Stewart >> Windows! The magic of turning a Pentium into a Gameboy! << ----- YEAR2000 CFORUM appended at 20:09:25 on 97/03/24 GMT (by Y2KTSC3 at STLVM6) Subject: OS/VS COBOL UNDER OS/390 Ref: Append at 16:58:10 on 97/03/20 GMT (by AROJAS at MEXVM2) >I READ THAT THE OS/VS COBOL COMPILER IS NOT SUPPORTED, BUT COMPILED >CODE WILL BE. Correct, if compiled code is run using Language Envuironment versions of the run-time library routines. In some cases (NORES) this mean that link-editing with LE using REPLACE cards will be necessary to replace the old versions. >MY QUESTION IS: UNDER OS/390 WILL BE POSSIBLE TO COMPILE PROGRAMS USING >OS/VS COBOL VER. 2.4 ? Possible, Yes, supported, NO. Once you are running under LE there is no need to use the old compiler, just run through a translator and compile with COBOL for MVS & VM! Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 02:21:01 on 97/03/25 GMT (by SYYEH at TAIVM1) Subject: PC/DOS 7 & Lan requester are y2k ready ? From The Year 2000 and 2-digit Dates: A guide for Planning and Implementation (sixth edition), There mentioned PC DOS 7 is y2k ready if support is available through the service stream(in Page A-58), What is "service stream" mean ? also we can't find any inf about DOS Lan requester,what version/release are Y2k ready ? Can somebody help us to answer this questions ? Thanks.. ----- YEAR2000 CFORUM appended at 14:54:48 on 97/03/25 GMT (by GBCBHG00 at ELINK) Subject: OS/VS COBOL UNDER OS/390 Ref: Append at 20:09:25 on 97/03/24 GMT (by Y2KTSC3 at STLVM6) "just run through a translater" is a pretty blanket statement. Would you care to clarify this. I have not reviewed OS/VS Cobol to Cobol for MVS and VM migration in detail but on the surface it appears that there are many functions which can not be "translated" or migrated. Examples that spring to mind include Cobol report writer and CICS MACRO level code. I know this is more directed at Cobol and should therefore be on another CFORUM, however as the statement was made here I would appreciate calrification in this CFORUM This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 15:25:21 on 97/03/25 GMT (by JCRANDL at ATLVMIC1) Subject: IMS Workload Router Version 2 (5697-B87) My customer is asking about the Y2K readiness of IMS WLR Version 2. Can anyone address this? I don't see it or it's predecessor in the planning guide. Thanks. Jim Randle, Memphis ISAM ----- YEAR2000 CFORUM appended at 17:04:40 on 97/03/25 GMT (by Y2KTSC3 at STLVM6) Subject: OS/VS COBOL UNDER OS/390 Ref: Append at 14:54:48 on 97/03/25 GMT (by GBCBHG00 at ELINK) >>Once you are running under LE there is >>no need to use the old compiler, just run through a translator and >>compile with COBOL for MVS & VM! >"just run through a translater" is a pretty blanket statement. Would you >care to clarify this. I have not reviewed OS/VS COBOL to COBOL for MVS >& VM migration in detail but on the surface it appears that there are >many functions which can not be "translated" or migrated. Examples that >spring to mind include COBOL report writer and CICS MACRO level code. If you read carefully, you will see that I prefixed the translator statement with "once you are running under LE". This means that you have already eliminated CICS Macro-level code, since Macro-level code is only supported on non-LE supported levels of CICS. (LE requires CICS V3.3 or later) Report Writer statements require no translation, they are all fully supported by the Report Writer Precompiler. If a customer has Report Writer statements, then they must buy that program offering as well. You can run Report Writer programs through CCCA with no problems. (CCCA can either flag Report Writer statements or ignore them) In 99.9% of cases, if a customer is running under LE using OS/VS COBOL compiled programs, they can make a change to a program by running it through a translator, making their code changes, and then compile with COBOL for MVS & VM as simple as that. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 23:23:10 on 97/03/26 GMT (by VNDRI236 at SJFEVMX) Subject: ADF and YEAR 2000 Ref: Append at 14:10:40 on 97/03/21 GMT (by BEGENB09 at ELINK) Hi Alex, I fix defects in ADF. My group has not tested ADF II V1.3 for year 2000 readiness because it will be dropped from support in November, 1997. Obviously you found a bug that we were not aware of. If you are interested in persuing this problem further, please open a PMR. I can investigate further to give you an explanation of why the year 2000 dates are not as they should be. To investigate further, I would ask you to force abends in ADF and have the dumps forwarded to me. Since the problem does not happen with current dates, a code change for this is unlikely. Are you aware of the IBM IMS/ESA ADF Tool Pak for MVS? It has a utility for assisting ADF programmers with the year 2000 problem. It is designed for use on all supported versions of IMS/ESA and IMSADF II Versions 1 and 2. For more information, please refer to announcement letter number 296-357. Kind regards, Alicia Bautista ----- YEAR2000 CFORUM appended at 16:54:50 on 97/03/27 GMT (by JGREIG at GNKVM) Subject: VisualAge 2000 Where can I get details of these tools ? Johan Greig IBM Greenock ----- YEAR2000 CFORUM appended at 20:31:21 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) ..... YEAR2000 CFORUM modified at 20:42:19 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) Subject: Date Validation >>Does anyone have a Y2000 date Conversion (Sorry, I meant to say date Converion) Does anyone have a Y2000 date Validation routine written in COBOL that you would be willing to share. Francis Lobresco ----- YEAR2000 CFORUM appended at 20:39:46 on 97/03/27 GMT (by Y2KTSC3 at STLVM6) Subject: Date Conversion Ref: Append at 20:31:21 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) >Does anyone have a Y2000 date conversion >routine written in COBOL that you would >be willing to share. What do you mean? A routine that converts a date into something else? A routine that converts a 2-digit date into a 4-digit date? Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 20:44:15 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) Subject: Date Conversion Ref: Append at 20:39:46 on 97/03/27 GMT (by Y2KTSC3 at STLVM6) Sorry, I meant to say a date Validation routine. I have amended my original append. Francis Lobresco ----- YEAR2000 CFORUM appended at 21:06:29 on 97/03/27 GMT (by Y2KTSC3 at STLVM6) Subject: Date Conversion Ref: Append at 20:44:15 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) >Sorry, I meant to say a date Validation routine. I am also sorry, I don't know what you are asking for. What do you want this "date validation routine" to do? Validate that a date is numeric, like COBOL class test? Validate that a date is in a certain range? Please give more specific details... Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 21:37:43 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) Subject: Date Conversion Ref: Append at 21:06:29 on 97/03/27 GMT (by Y2KTSC3 at STLVM6) I receive a file with records that have up to 8 dates to check. I want to call a program to do the checking. I want it to do the following: 1) Check that the numeric parts of the date are numeric 2) Check that the month is '1' thru '12' 3) Check that the day is valid for the month (This also includes a leap year test if the month is '2') 4) Return error information I have written a program. Because we have so many dates to check, we will probably re-write this in assembler to improve efficiency. We are using COBOL to work out the details because we are more familiar with it. What I am most unsure of is my logic for testing for a leap year. Hope this better explains what I am asking. Thanks, Francis Lobresco ----- YEAR2000 CFORUM appended at 22:06:38 on 97/03/27 GMT (by CREMA at STLVM1) Subject: VisualAge 2000 Ref: Append at 16:54:50 on 97/03/27 GMT (by JGREIG at GNKVM) >Where can I get details of these tools ? > >Johan Greig >IBM Greenock VisualAge 2000 is a cross-platform, cross-language application development offering combining IBM and non-IBM tools, education, and support to enable customers to implement their own solutions to the Year 2000 issue. The Year 2000 process is a staged solution: assessment and strategy, detail planning, implementation (impact analysis, find and fix), testing, and clean management. VisualAge 2000 initial offering includes: - Inventory and Assessment tools . ISOGON SoftAudit/2000 and SoftAudit/ONE Note: ISOGON tools will be announced in April 1997 . Edge Portfolio Analyzer Note: Edge Portfolio Analyzer remarketing agreement to be announced in April 1997 - Implementation: a) Impact Analysis; b) Find and Fix . VisualAge for COBOL, Professional - Testing . VisualAge for COBOL, Test . Debug Tool (host compiler feature) Alice Crema IBM COBOL Family Market/Sales Support ----- YEAR2000 CFORUM appended at 02:48:43 on 97/04/01 GMT (by AS106968 at ELINK) Subject: Date Conversion Ref: Append at 21:37:43 on 97/03/27 GMT (by V$N8KG5 at CLTVM1) Leap Year Test : I believe the following logic applies to leap year determination. If year divisible by 4 then Leap=Yes, but if also divisible by 100 then Leap=No, but if also divisible by 400 then Leap=Yes. Thats a bit scratchy. In PL/I you could code : SELECT(MOD(YEAR,100)); WHEN (0) SELECT(MOD(YEAR,400)); WHEN (0) LEAP_YEAR='1'B; OTHERWISE LEAP_YEAR='0'B; END; OTHERWISE SELECT(MOD(YEAR,0)); WHEN (0) LEAP_YEAR='1'B; OTHERWISE LEAP_YEAR='0'B; END; END; No doubt this forum will receive either corrections or better ways !! This append was created on the External IBMLink system by Richard Barrow, J B Were & Son, Systems Programmer, Ph : +61 3 9679 1284 Fax : +61 3 9679 1067 E-mail : rbarrow@jbwere.com.au