----- YEAR2000 CFORUM appended at 09:22:29 on 96/11/01 GMT (by 78897412 at EHONE) Subject: COBOL and Y2K Ref: Append at 15:20:33 on 96/10/31 GMT (by IYORK at KGNVMC) Iris, I feel a bit(understatement) foolish. Next time before appending I will be a bit more carefull before making clear I did not read the books careful enough! Thanks for bothering, NL97412@EAMSVM1 ----- YEAR2000 CFORUM appended at 10:36:24 on 96/11/01 GMT (by 86617495 at EHONE) Subject: LE/370 date routines Ref: Append at 17:03:43 on 96/10/31 GMT (by TMROSS at STLVM20) Hi Tom, Thanks for the book reference. One snag - CG26-4764-03 is the Compiler and Run-time Migration Guide. I found the Cobol for MVS & VM Programming Guide under SC26-4767-02. You're making me work for this information but then again information that is worked for should be retained longer. Ian Junor - IBM UK (Y2K Redevelopment) ----- YEAR2000 CFORUM appended at 12:45:56 on 96/11/01 GMT (by CLACKEY at RALVM17) Subject: Does my customer need to upgrade 3725 to 3745? Ref: Append at 15:43:31 on 96/10/16 GMT (by STEVE at UKFSC) Steve, If a customer chooses to refrain from investing in new hardware because the current hardware does not handle the century rollover, what options does the customer have? I am extremely interested in the customer's view of this very awkward dilema. Are there viable business options? Even the casual home PC user will have to deal with this dilema since the PC's BIOS can't handle it either. Carl Lackey ----- YEAR2000 CFORUM appended at 16:00:05 on 96/11/01 GMT (by TMROSS at STLVM20) Subject: LE/370 date routines Ref: Append at 10:36:24 on 96/11/01 GMT (by 86617495 at EHONE) >Thanks for the book reference. One snag - CG26-4764-03 is the >Compiler and Run-time Migration Guide. I found the Cobol for MVS & VM >Programming Guide under SC26-4767-02. Oops! I recommend the Migration Guide so often the number is stuck my brain. Sorry! (By the way, the Migration Guide is a great manual for helping you migrate to the Year 2000 ready COBOL products. We have even received Reader Comment Forms with no problems, just compliments! Unheard of for an IBM manual...) Tom Ross IBM COBOL Family Development ----- YEAR2000 CFORUM appended at 23:48:25 on 96/11/03 GMT (by KERSHAW at KGNVMC) Subject: LE/370 date routines Ref: Append at 15:26:36 on 96/10/29 GMT (by GBCAYX01 at ELINK2) LE provides two solutions to handle the YEAR 2000 problem. 1) Convert your dates to a Lillian date (and Integer Number based on October 15, 1582) 2) The Sliding Century Window solution - allowing users a temporary solution by reassinging dates Both are being used a viable solutions in the field. Kershaw S. Mehta Language Environment ----- YEAR2000 CFORUM appended at 20:55:53 on 96/11/04 GMT (by MLDUCKWO at STLVM20) < What's the difference between YEAR2000 CFORUM on IBMVM and < YEAR2000 CFORUM on IBMMVS and YEAR2000 CFORUM on GLOBNET? < < For example, the append at 12:06:55 on 96/10/24 GMT (by 86653614 at < EHONE) on the YEAR2000 CFORUM on IBMMVS is not on the other fora. < < How do I subscribe to receive all traffic without duplicates? There are two separate fora structured as follows: YEAR2000 CFORUM in the MVS environment on GLOBNET and shadowed on IBMMVS YEAR2000 CFORUM in the VM environment on GLOBNET and shadowed on IBMVM A post on the MVS forum does not appear on the VM forum and vice versa However, occasionally somebody posts the same question on both fora. We are looking into making both fora shadows of each other so that there will only be one forum you need to subscribe to. We'll post an updat on the fora as the situation changes. For now, you must subscribe to both in order to ensure you see all activity. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 20:56:00 on 96/11/04 GMT (by MLDUCKWO at STLVM20) < What's the difference between YEAR2000 CFORUM on IBMVM and < YEAR2000 CFORUM on IBMMVS and YEAR2000 CFORUM on GLOBNET? < < For example, the append at 12:06:55 on 96/10/24 GMT (by 86653614 at < EHONE) on the YEAR2000 CFORUM on IBMMVS is not on the other fora. < < How do I subscribe to receive all traffic without duplicates? There are two separate fora structured as follows: YEAR2000 CFORUM in the MVS environment on GLOBNET and shadowed on IBMMVS YEAR2000 CFORUM in the VM environment on GLOBNET and shadowed on IBMVM A post on the MVS forum does not appear on the VM forum and vice versa However, occasionally somebody posts the same question on both fora. We are looking into making both fora shadows of each other so that there will only be one forum you need to subscribe to. We'll post an updat on the fora as the situation changes. For now, you must subscribe to both in order to ensure you see all activity. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 11:58:19 on 96/11/05 GMT (by 9WARLTK at CROVM4) ..... YEAR2000 CFORUM modified at 11:14:27 on 96/11/07 GMT (by 9WARLTK at CROVM4) Subject: Y2K and the new COBOL standard The new COBOL standard contains support for a sliding window when converting a YY field into a YYYY field WITHOUT using integer dates. There are two versions of the draft available via ftp. One is the complete text in WordPerfect 6.0 for DOS. The other is ASCII text, but does not include syntax diagrams and figures. Each version consists of 33 files which are zipped using PKZIP. Use FTP to access ftp.microfocus.com via anonymous logon. From there, descend to one of the following directories: /pub/cobol/Standards/cblstdzp - WordPerfect 6.0 version /pub/cobol/Standards/cblstdas - ASCII text files If you have problems, contact the chairman of COBOL Technical Committee X3J4, Don Schricker (daschric@shore.net). You can download various proposals for updating the draft standard using: http://204.146.47.71/ad/cobol/cobol.htm Download COBOL 97 standards documents (doc files) Given the November 26, 1996 deadline for public review, comments should be emailed. Comments within IBM worldwide should be sent by November 21, 1996, to Ann Wallace, STLVM20(WALLACE). External comments should include name, company name, address, telephone number, and email address if applicable and be sent to ddonovan@itic.nw.dc.us Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 07:06:54 on 96/11/06 GMT (by STEVE at UKFSC) Subject: Does my customer need to upgrade 3725 to 3745? Ref: Append at 12:45:56 on 96/11/01 GMT (by CLACKEY at RALVM17) I don't think that the necessity to invest in new hardware is the most emotive issue here. My question is simply this: how will a 3725 with pure EP in it *know* that the year has changed to 2000? In other words, how will it know when to stop working? My suspicion, based entirely on speculation is that it won't know. If it is the loading of the EP which might cause problems then that is easily handled, at least for VM customers. You load it from a machine which always thinks its the same day. Groundhog day, perhaps... Steve Swift ----- YEAR2000 CFORUM appended at 07:09:04 on 96/11/06 GMT (by STEVE at UKFSC) Subject: GC28-1251 Where do we get copies of GC28-1251 after this: > Date: 05 November 1996, 17:59:19 GMT > From: TOOLSRUN 6.9 (level 1) TOOLS4GB at EHONE1 > To: Distribution > > MKTTOOLS: Information: GC281251 PACKAGE erased by TEMP97 at RHQVM12. > Erase per Ardsley England. Or was it purely some local administrivia going on at EHONE1? Steve Swift ----- YEAR2000 CFORUM appended at 15:49:25 on 96/11/06 GMT (by GBCBHG00 at ELINK) Subject: Cobol and Y2k Folks, I have tried to seek CLEAR clarification of the following questions, but as yet have not recieved what I consider to be a concise answer. If an application written in OS/VS Cobol or Cobol II (iether online - say CICS - or batch) does not use any system date functions, will it continue to run after midnight 31/12/1999? If so what will cause it to fail - Do the OS/VS Cobol or Cobol II runtime modules use date related functions under the covers which could cause *them* (ie the run time modules) to fail ? Are the "Cobol for MVS and VM" run time modules downwardly compatable or must the OS/VS Cobol and Cobol II programs be re-compiled and/or relinked The obvious answers are: OS/VS Cobol and Cobol II and many other versions of software do not fully support year 2000 and as such their function can not be guarenteed (or in some cases is unsupported). I beleive there was a presentation at the GSE Large systems meeting on the 25th of September which may have provided some answers, but I was unable to attend the meeting and have not been able to obtain any details. It was supposed to detail Title: Cobol and the Year 2000 Presenter: Ivan Shepherd, IBM OBJECTIVES: The talk will comprehensively cover the issues surrounding Cobol and the Year 2000. In particular, about load modules produced by earlier non Year 2000 compliant versions of the Cobol compiler. This append was created on the External IBMLink system by Peter Gammage Tel 0141-204 2737 SEMA Group Outsourcing Fax 0141-204 2523 1 Atlantic Quay Broomielaw, Glasgow G2-8JE Email: Peter.Gammage@mail.sema.co.uk ----- YEAR2000 CFORUM appended at 16:15:36 on 96/11/06 GMT (by Y2KTSC at STLVM6) Subject: Cobol and Y2k Ref: Append at 15:49:25 on 96/11/06 GMT (by GBCBHG00 at ELINK) Re: Questions about the COBOL compilers and runtimes An application currently running successfully, that has no date functions should continue to run successfully into the next century. We know of nothing in the OS/VS COBOL or COBOL II runtime modules that would cause a failure. No COBOL products are "downward" compatible. That is, no load module created with the COBOL for MVS & VM compiler and linked with LE should run using the OS/VS COBOL runtime. OS/VS COBOL and COBOL modules should run using the LE runtime as long as you've followed all the guidelines in the COBOL Migration and LE Migration manuals. There are many situations where this "upward" compatibility doesn't work and the migration guides do a very good job of telling you what they are. As a general suggestion, it's a good idea to stay current with technology. COBOL for MVS & VM and LE for MVS & VM provide a number of solutions for coding Year 2000 compatible applications. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 17:02:24 on 96/11/06 GMT (by MLDUCKWO at STLVM20) Subject: GC28-1251 Ref: Append at 07:09:04 on 96/11/06 GMT (by STEVE at UKFSC) >Where do we get copies of GC28-1251 after this: > >> Date: 05 November 1996, 17:59:19 GMT >> From: TOOLSRUN 6.9 (level 1) TOOLS4GB at EHONE1 >> To: Distribution >> >> MKTTOOLS: Information: GC281251 PACKAGE erased by TEMP97 at RHQVM12. >> Erase per Ardsley England. > >Or was it purely some local administrivia going on at EHONE1? The manual can be downloaded from the Year 2000 website at URL: http://www.software.ibm.com/year2000/index.html M. L. Duckworth ----- YEAR2000 CFORUM appended at 12:36:39 on 96/11/07 GMT (by 62410352 at EHONE) Subject: VM or LPAR Ref: Append at 15:35:05 on 96/10/24 GMT (by 62418658 at EHONE) TODENABLE ? To be precise: Before TODENABLE became an OPTION in the CP directory, ANY virtual machine could set it's own clock. Kris Buelens, VM Support IBM Belgium, BUELENSC at IECVM ----- YEAR2000 CFORUM appended at 12:49:05 on 96/11/07 GMT (by TMAC at RHQVM22) Subject: T2000 Phase I Assessment We are preparing for a Phase I Assessment and the customer has asked to have their Facilities included. What has been mentioned so far are Security Systems, PBX's, Elevators. Is there anyone out there with knowledge or experience in dealing with these kind of things in a Year2000 engagement? I am looking for as complete a list of things, such as PBX's, so that I can build surveys. Tom McNamara ----- YEAR2000 CFORUM appended at 13:26:55 on 96/11/07 GMT (by 86653614 at EHONE) Subject: Questions about the COBOL compilers and runtimes Ref: Append at 16:15:36 on 96/11/06 GMT (by Y2KTSC at STLVM6) Just to add that it was me, in fact, who gave the presentation at the GSE Large Systems meeting on September 25th. The contact name for the minutes of the meeting is a Mike Cafferata on 01477 533094. Richard Mascall, IBM in the United Kingdom ----- YEAR2000 CFORUM appended at 13:59:06 on 96/11/07 GMT (by 86653614 at EHONE) Subject: Cobol and Y2k Ref: Append at 15:49:25 on 96/11/06 GMT (by GBCBHG00 at ELINK) Just to add that it was me, in fact, who gave the presentation at the GSE Large Systems meeting on September 25th. The contact name for the minutes of the meeting is a Mike Cafferata on 01477 533094. Some appends to this forum appear on another forum. That happened here and the Year2000 technical chaps responded as below (I'm adding it here since it does not seem to have appeared on this forum). Among other points at the GSE meeting, I made the same comments as those below, namely that (a) as far as COBOL applications are concerned there is nothing inherently about the year 2000 that will cause the runtime to fail and (b) it's especially worthwhile being current with COBOL and LE because of the extra date-related facilities that they provide. >----- YEAR2000 CFORUM appended at 16:15:36 >on 96/11/06 GMT (by Y2KTSC at STLVM6) >Subject: Cobol and Y2k >Ref: Append at 15:49:25 on 96/11/06 GMT (by GBCBHG00 at ELINK) > >Re: Questions about the COBOL compilers and runtimes > >An application currently running successfully, >that has no date functions >should continue to run successfully into the next century. We know of >nothing in the OS/VS COBOL or COBOL II runtime >modules that would cause >a failure. > >No COBOL products are "downward" compatible. >That is, no load module >created with the COBOL for MVS & VM compiler >and linked with LE should >run using the OS/VS COBOL runtime. >OS/VS COBOL and COBOL modules should run using the LE runtime as long >as you've followed all the guidelines in the COBOL Migration and LE >Migration manuals. There are many situations where this "upward" >compatibility doesn't work and the migration guides do a very good >job of telling you what they are. > >As a general suggestion, it's a good idea to stay current with >technology. COBOL for MVS & VM and LE for MVS & VM provide a number >of solutions for coding Year 2000 compatible applications. >Year 2000 Technical Support Center > Richard Mascall, IBM in the United Kingdom ----- YEAR2000 CFORUM appended at 16:09:57 on 96/11/07 GMT (by GBCADH00 at ELINK) Subject: PS/PC and 1997 PS/PC restricts the sending date to the date range of 1980 to 1996 (According to IBM Mail Exchange). They say this can be overcome by changing lines in the PSPCPMP.DEF file to say 0063 instead of 5060 on the ;DATE FORMAT PARMS line (which also contains hex 14 characters). More details (and a program to do the edits) via the IBM Global Network helpdesk. This append was created on the External IBMLink system by Nick Hands-Clarke (GBFPLNHC at IBMMAIL.COM) FPLO (+44-1306 740123 ext 3121) ----- YEAR2000 CFORUM appended at 17:12:06 on 96/11/07 GMT (by SJCONTR at DALVMIC1) Subject: AS400 RPG Estimating Guidelines We are looking for Year 2000 compliance estimating guidelines for AS/400 based application portfolios to provide these clients with realistic financial expectations. Can anyone share what they have seen or have experienced? Thank you. Steve Contreras sjcontr at dalvmic1 303-773-5174 / TL 656-5174 ----- YEAR2000 CFORUM appended at 14:01:19 on 96/11/08 GMT (by 9WARLTK at CROVM4) Subject: Year 2000 Compliance, VS COBOL II and IBM COBOL Ref: Append 10:20:24 on 96/10/24 GMT (by GBCBHU09 at ELINK) Mark, The IBM definition of compliance in the Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation, GC28-1251-04, Appendix D. Glossary says: Year2000 ready. The capability for a product, when used in accordance with its associated documentation, to correctly process, provide, and/or receive date data within and between the twentieth and twenty-first centuries, provided that all hardware, software, and firmware used with the product properly exchange accurate date data with the product. In other words, processes dates correctly. In VS COBOL II, to obtain the current date in the form YYYYMMDD you can CALL 'IGZEDT4' USING BY REFERENCE date-identifier. In VS COBOL II, running under Language Environment, you can CALL dynamically: CEECBLDY--Convert Date to COBOL Integer Format 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 Date or Time CEEQCEN--Query the Century Window CEESCEN--Set the Century Window CEESECI--Convert Seconds to Integers CEESECS--Convert Timestamp to Seconds CEE3CTY--Set Default Country In other words, there are various ways to make VS COBOL II programs Year 2000 compliant. However: IGZEDT4 is not supported under CICS. The overhead of the dynamic CALLs may cause a problem. The VS COBOL II compiler is not Year 2000 compliant because it has no COBOL language support for 4-digit years. The VS COBOL II compiler is frozen. Effective November 28, 1997, service for the VSE feature of the VS COBOL II compiler will be discontinued. The current support for the VS COBOL II compiler for MVS and VM is not very long term. OS/VS COBOL was supported for 9 years after the 1985 availability of VS COBOL II. VS COBOL II has so far been supported for 5 years after the 1991 availability of IBM COBOL for MVS and VM (previously known as COBOL/370). The current support for Language Environment run-time support for VS COBOL II is long term. IBM COBOL for MVS & VM, IBM COBOL for VSE/ESA, IBM VisualAge COBOL for OS/2, IBM COBOL Set for AIX, and ILE COBOL for AS/400 are all Year 2000 compliant. They contain 4-digit year COBOL language support for CURRENT-DATE, DATE-OF-INTEGER DAY-OF-INTEGER, INTEGER-OF-DATE, INTEGER-OF-DAY and WHEN-COMPILED. These are the COBOL compilers recommended by IBM. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 15:20:47 on 96/11/08 GMT (by 9WARLTK at CROVM4) Subject: EMEA Year2000 Teleconferences Year 2000 and MVS 26th November, 1996 10.00am CET / 11.00 GMT Year 2000 and VM/VSE 3rd December, 1996 10.00am CET / 11.00 GMT These are part of a new series of interactive Pan European Teleconferences in English, German, French and Italian. From your desk you can listen to the experts, ask questions, talk to those who know the answers. The information and booking facility on the internet at http://www.europe.ibm.com/direct under Teleconferencing shows how you may register for a conference by telephone, fax, email or posted mail. IBM will then call you at a designated time to bring you into the meeting. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 15:48:12 on 96/11/08 GMT (by 9WARLTK at CROVM4) Subject: EMEA Year2000 Teleconferences Year 2000 and MVS 26th November, 1996 10.00am CET / 11.00 GMT Year 2000 and VM/VSE 3rd December, 1996 10.00am CET / 11.00 GMT These are part of a new series of interactive Pan European Teleconferences in English, German, French and Italian. From your desk you can listen to the experts, ask questions, talk to those who know the answers. The information and booking facility on the internet at http://www.europe.ibm.com/direct under Teleconferencing shows how you may register for a conference by telephone, fax, email or posted mail. IBM will then call you at a designated time to bring you into the meeting. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 13:50:42 on 96/11/11 GMT (by BARSKY at LASVM1) Subject: Users Guide or Reference Manual I'm looking for books to read and to know the methodology on Phase I, II III, for the Transformation 2000 process. If anybody can help telling me where can I find the explanation of EACH of the tasks of the activities and for each phase, I will be very thank. Name : Guillermo P. Barsky VM Id : BARSKY at ARG E-Mail : gparsky@vnet.ibm.com Phone : 54 1 319-6837 Fax : 54 1 319-6654 Country: Argentina ----- YEAR2000 CFORUM appended at 14:27:14 on 96/11/11 GMT (by 86629111 at EHONE) Subject: COMUDAS Are these Date Routines of use with COBOL CICS? - the documentation states PL1 CICS. ----- YEAR2000 CFORUM appended at 10:28:47 on 96/11/13 GMT (by 9WARLTK at CROVM4) ..... YEAR2000 CFORUM modified at 10:41:34 on 96/11/13 GMT (by 9WARLTK at CROVM4) Subject: APAR PN76666 misquoted on the Internet From the Internet: To: Multiple recipients of the year2000 list From: "Y2K Maillist (Via: Amy)" Subject: IGZEDT4: YYYYMMDD in OS/VS COBOL and COBOL II Date: Wed, 30 Oct 1996 08:44:01 -0500 (EST) From: Fred Schuff Message sent: 10/30/96 08:44am I looked at the APAR for COBOL II (PN76666) and PTF(UN83685) to provide a date with a 4-digit year from the system - to provide an equivalent for ACCEPT xxx FROM DATE. The APAR says the IBM supplied program, IGZEDT4 written in assembler language, works with COBOL II but NOT with OS/VS COBOL. This is not true - it works with both. From APAR PN76666 Usage notes: 1. IGZEDT4 is not supported under CICS. 2. IGZEDT4 can only be called from VS COBOL II programs, either statically or dynamically. There is no support to call IGZEDT4 from any other program (including OS/VS COBOL). Please note the wording "There is no support under OS/VS COBOL" This does NOT say "works with COBOL II but NOT with OS/VS COBOL." The "can only be called" means "can only be called in a supported environment" Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 23:27:34 on 96/11/15 GMT (by TMROSS at STLVM20) Subject: Using the century window feature of DFSORT with COBOL Here is a write up on how to use the COBOL SORT statement to sort records that have 2-digit years using a sliding or fixed century window...enjoy! Tom Ross IBM COBOL Family Development ------------------------------------------------------------------ DFSORT AND THE CENTURY WINDOW _____________________________ o Apply fix for APAR PN71337 (PTF UN90139) to DFSORT R13 o To use the century window function in a COBOL SORT you need to tell DFSORT when your century window starts and which fields are to be sorted using the century window Use the following 2 control statements in JCL: - OPTION Y2PAST - OPTION Y2PAST=nn -- Where nn=number of years back to start of window - OPTION Y2PAST=nnnn -- Where nnnn=fixed window start date - SORT FIELDS=(n,n,Y2C,A,...) -- Where Y2C, Y2Z, Y2P, and Y2D identify 2-digit year fields in character, zoned decimal, packed decimal, and decimal form o For more information, see DFSORT documentation - http://www.storage.ibm.com/storage/software/sort/srtmhome/htm DFSORT AND THE CENTURY WINDOW _____________________________ o The OPTION statement can be coded in the IGZSRTCD DD statement +----------------------------------------------------------+ | //IGZSRTCD DD * | | OPTION Y2PAST=20 | +----------------------------------------------------------+ o The SORT control statement must be coded in a DFSPARM DD statement o To SORT records that start with mm/dd/yy as yyyymmdd: +----------------------------------------------------------+ | //DFSPARM DD * | | SORT FIELDS=(7,2,Y2C,A, * sort C'yy' using CW | | 1,2,BI,A, * sort C'mm' ascending | | 4,2,BI,A) * sort C'dd' ascending | +----------------------------------------------------------+ o Other notes on SORT: - Use a local name if your installation changed the default name DFSPARM - A SORT statement can not be specified in IGZSRTCD - This will override the SORT FIELDS produced by the compiler, so you must make sure that you identify all fields that are to be sorted. - These are the ASCENDING/DESCENDING KEYS in the SORT statements in your COBOL program ----- YEAR2000 CFORUM appended at 17:26:28 on 96/11/18 GMT (by GBCBHU09 at ELINK) Subject: COBOL and Y2K Ref: Append at 12:01:53 on 96/10/31 GMT (by GBCBHU09 at ELINK) I have recently been in contact with Richard Mascall, HLL Product Specialist (IBM). I was hoping he'd solved the technical difficulties of posting on this forum by now, In guess he's still struggling. Richard is Product Specialist (HLLs). Email:richard_mascall@uk.ibm.com) I hope he'll forgive me for transcribing one of his notes to me. Both OS/VS COBOL and COBOL II are "compliant" compilers, in that, neither the compiler nor the run time code will fail due to the transition to Year 2000. Apart from the APARs mentioned in previous appends, both these languages will supply a 2-digit year to requesting applications. This is the principle reason why they're not listed in the 2000 manual. So, we can continue to compile and run. Whether anyone should continue to use an unsupported compiler is another question. This append was created on the External IBMLink system by Melvyn Maltz Marks and Spencer plc Tel:0171 268 5246 Fax:0171 268 5246 Email: melvyn.maltz@marks-and-spencer.com ----- YEAR2000 CFORUM appended at 17:56:36 on 96/11/18 GMT (by Y2KTSC at STLVM6) Subject: COBOL and Y2K Ref: Append at 17:26:28 on 96/11/18 GMT (by GBCBHU09 at ELINK) As of last week, all APPENDS appear on both IBMVM and IBMMVS fora. Thus an APPEND to one will automatically appear on the other. Neither OS/VS COBOL or VS COBOL II are YEAR 2000 compliant. While you may still use them after the year 2000, they will never support four digit years. The APAR to COBOL II is NOT intended for long term use and we strongly recommend upgrading to currently supported YEAR 2000 compilers. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 20:45:44 on 96/11/18 GMT (by IL68778 at ELINK) Subject: COBOL and Y2K Ref: Append at 17:56:36 on 96/11/18 GMT (by Y2KTSC at STLVM6) > Appended at 17:56:36 on 96/11/18 GMT (by Y2KTSC at STLVM6) > > Neither OS/VS COBOL or VS COBOL II are YEAR 2000 compliant. While > you may still use them after the year 2000, they will never support > four digit years. The APAR to COBOL II is NOT intended for long > term use and we strongly recommend upgrading to currently supported > YEAR 2000 compilers. Perhaps you should define what you mean by "year 2000 compliant". Not everyone uses the same definition and that's causing endless arguments. Is there any such thing as an ISO or ANSI definition of "year-2000 compliant"? How about "year-2000 compatible" ? Gilbert Saint-flour Automated Migration Services IBMMAIL(USS24LG4) IBMLINK(IL68778) ----- YEAR2000 CFORUM appended at 21:13:03 on 96/11/18 GMT (by Y2KTSC at STLVM6) Subject: COBOL and Y2K Ref: Append at 20:45:44 on 96/11/18 GMT (by IL68778 at ELINK) Allow me to rephrase using a proper IBM Definition: YEAR 2000 READY "The Product, when used in accordance with its associated documentation, is capable of correctly processing, providing and/or receiving date data within and between the twentieth and twenty-first centuries, provided that all products (for example, hardware, software and firmware) used with the Product properly exchange accurate date data with it." Again, we recommend moving to the latest "YEAR 2000 READY" COBOL complier. In this case 'IBM COBOL for MVS & VM V1 R2'. I hope this clarifies any confusion we may have caused. Best Regards... Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 21:31:49 on 96/11/18 GMT (by YAEGER at SJFEVMX) Subject: Using the century window feature of DFSORT with COBOL Ref: Append at 23:27:34 on 96/11/15 GMT (by TMROSS at STLVM20) I have some minor corrections/additions for Tom's writeup. From DFSORT's perspective, the OPTION statement can go in either the DFSPARM data set or the IGZSRTCD data set. Is there some reason why the OPTION statement must go in IGZSRTCD from COBOL's perspective? If anyone has a full-blown example of using DFSORT's Year2000 features for a COBOL program, I'd really like to have it for use in my SORT2000 paper and on the DFSORT home page so everyone can benefit from it. You can send it to fyaeger@vnet.ibm.com or YAEGER at SJFEVMX or USIB257Z at IBMMAIL. Alternatively, if someone has a COBOL program that they'd like to use DFSORT's Year2000 features for, I'd be happy to work on that with you. Just contact me offline. I don't know COBOL, but I do know DFSORT. 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 ------------------------------------------------------------------ Subject: Using the century window feature of DFSORT with COBOL Here is a write up on how to use the COBOL SORT statement to sort records that have 2-digit years using a sliding or fixed century window...enjoy! Tom Ross IBM COBOL Family Development ------------------------------------------------------------------ DFSORT AND THE CENTURY WINDOW _____________________________ o Apply fix for APAR PN71337 (PTF UN90139) to DFSORT R13 o To use the century window function in a COBOL SORT you need to tell DFSORT when your century window starts and >> which fields are to be sorted using the century window. Use the following 2 control statements in JCL: - OPTION Y2PAST >> - OPTION Y2PAST=s >> -- Sliding century window where s is the number of >> years back to start of window (nn=0 to 100) >> - OPTION Y2PAST=f >> -- Fixed century window where f is the start of the >> window >> - SORT FIELDS=(p,m,Y2C,A,...) -- Where Y2C, Y2Z, Y2P, and Y2D identify 2-digit year fields in character, zoned decimal, packed decimal, and decimal form >>o For more information, see the DFSORT home page at URL: >> - http://www.storage.ibm.com/software/sort/srtmhome.htm >> The SORT2000 paper contains complete details of DFSORT's >> Year 2000 features. You can browse it on the DFSORT home page, >> ask your IBM rep to obtain it for you from MKTTOOLS or download >> Postscript and text versions via anonymous FTP from: >> >> lscftp.pok.ibm.com/pub/mvs/docs/ DFSORT AND THE CENTURY WINDOW _____________________________ o The OPTION statement can be coded in the IGZSRTCD DD >> data set +----------------------------------------------------------+ | //IGZSRTCD DD * | | OPTION Y2PAST=20 | +----------------------------------------------------------+ o The SORT control statement must be coded in a DFSPARM DD > data set o To SORT records that start with mm/dd/yy as yyyymmdd: +----------------------------------------------------------+ | //DFSPARM DD * | | SORT FIELDS=(7,2,Y2C,A, * sort C'yy' using CW | | 1,2,BI,A, * sort C'mm' ascending | | 4,2,BI,A) * sort C'dd' ascending | +----------------------------------------------------------+ o Other notes on SORT: - Use a local name if your installation changed the > default name DFSPARM (ICEMAC PARMDDN=ddname) - A SORT statement can not be specified in IGZSRTCD - This will override the SORT FIELDS produced by the compiler, so you must make sure that you identify all fields that are to be sorted. - These are the ASCENDING/DESCENDING KEYS in the SORT statements in your COBOL program ----- YEAR2000 CFORUM appended at 13:30:52 on 96/11/19 GMT (by Y2KTSC at STLVM6) Subject: Using the century window feature of DFSORT with COBOL Ref: Append at 21:31:49 on 96/11/18 GMT (by YAEGER at SJFEVMX) The author of this document (relating to DFSORT and COBOL) is presenting this week at the GUIDE conference. We will be sure to follow-up with "off-line" contact to resolve any discrepancies in the original. Thank you for your interest and support. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 05:01:56 on 96/11/20 GMT (by DJKRESN at CHGVMIC1) Subject: General question on compilers and YR2000 Documentation indicates COBOL(PLI) for MVS(VSE) as YR2000 compliant language compilers. Customers are telling me that they already account for 4 digit year in their applications (written in OS/VS COBOL or DOS/VS COBOL for example) and therefore why do they have to upgrade their compliers to the 'compliant' versions? Do they really need to do this? I know with LE Runtimes you can execute a OS or DOS/VS COBOL program. Do they really need to recompile all their programs in the new compilers? What will happen to DOS/VS/COBOL on 1/1/2000 for an example? Some compilers (RPGII for example) are not even on the YR2000 list in any form/version. Is something like that going to run as long as the program takes the date into account? Thanks very much for a clarification. This is becoming a pervasive question across all all operating systems as I am out making calls on accounts. Debbie Kresnicka DJKRESN @ CHGVMIC1 dkresnicka@vnet.ibm.com ----- YEAR2000 CFORUM appended at 10:35:46 on 96/11/20 GMT (by 62418658 at EHONE) Subject: General question on compilers and YR2000 Ref: Append at 05:01:56 on 96/11/20 GMT (by DJKRESN at CHGVMIC1) Concerning the RPG compiler, we had the question from several customers whether RPG (5746-RG1) would still be supported on VM/ESA and would be Y2000 compliant. By chance I discovered that it will indeed become Y2000 compliant via a PTF both for VSE and VM (CMS/DOS). I found the info in G225-4508-13 "Special Issue - VSE and Year 2000", pages 32-33. RPG is indeed missing on the list for VM/ESA. Guy De Ceulaer - VM Support - Belgium ----- YEAR2000 CFORUM appended at 11:52:41 on 96/11/20 GMT (by GAD at KGNVMC) - Subject: General question on compilers and YR2000 Ref: Append at 05:01:56 on 96/11/20 GMT (by DJKRESN at CHGVMIC1) There are several different issues here. 1) If the compiler and runtime library is no longer supported by IBM and the customer continues to use it, they do so at their own risk. Year 2000 or not. End of discussion. 2) If the code generated by the compiler is capable of properly passing along the century indicator then that compiler is (in my words) Year 2000 enabled. The fact that the code returns a date of the form 19xx *DOES NOT* mean it is Year 2000 enabled. It may *always* put '19' in front of the year that it returns and that will not do in Year 2000. It is recognition of, and honoring of the century indicator that is returned from the operating system with the date that is critical. 3) A compiler is Year 2000 compliant when all the above criteria is met and all of the dates in output from the compiler (ie listings too) contain a 4 digit year. You are correct in the fact that a Year 2000 compliant compiler is not necessarily needed to produce Year 2000 compliant programs. But don't assume that because you get a 4-digit year today that it will be the correct 4-digit year in Year 2000 for a non-qualified compiler. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 12:03:40 on 96/11/20 GMT (by GBCBHG00 at ELINK) Subject: General question on compilers and YR2000 Ref: Append at 05:01:56 on 96/11/20 GMT (by DJKRESN at CHGVMIC1) Debbie, Have a look at append 35. I asked exactly the same question. The result was that OS/VS Cobol and Cobol II will still function after 31/12/1999. One question asked however was that as OS/VS Cobol is unsupported would you still want to run it? At this point in time my answer is that the business must decide. To be supported requires considerable change (OS/VS Cobol to Cobol for MVS and VM) with negligable (?) benefit for an application who's date processing is not dependant on compiler/system returned dates. 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:34:55 on 96/11/20 GMT (by Y2KTSC at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 05:01:56 on 96/11/20 GMT (by DJKRESN at CHGVMIC1) Lets divide this question into two categories: compilers and programs. Compilers: A year 2000 ready compiler has a 4-digit year date stamp for things like the compiler listing and may provide built-in support for a 4-digit year to the program. Programs: A year 2000 ready program can correctly handle the year portion of a date. The method of handling the year may be strictly with in the program logic or may use some of the support provided by the compiler. So a customer can have any of the following scenarios: year 2000 ready compiler and year 2000 ready programs year 2000 ready compiler and not year 2000 ready programs not year 2000 ready compiler and year 2000 ready programs not year 2000 ready compiler and not year 2000 ready programs It is up to the individual to decide whether to upgrade a compiler. The big question is "Do you want to have an out of service compiler?" OS/VS COBOL is already not supported and VS COBOL II may not be supported by year 2000. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 13:36:21 on 96/11/20 GMT (by GBCADH00 at ELINK) Subject: MVS Y2K Testing There is little on this topic in the Guide for Planning & Implementation document from IBM (GC28-1251). Is anyone aware of documents giving more detail on the do's and dont's? Is anyone in IBM preparing to issue such a docment? I am thinking here of MVS and sub-system testing rather than application testing - the latter being rather company and application specific. This append was created on the External IBMLink system by Nick Hands-Clarke (GBFPLNHC at IBMMAIL.COM) FPLO (+44-1306 740123 ext 3121) ----- YEAR2000 CFORUM appended at 13:38:04 on 96/11/20 GMT (by Y2KTSC at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 11:52:41 on 96/11/20 GMT (by GAD at KGNVMC) Item 2 is a good point. Check your dates to see if they are hard coded as 19xx. A 4-digit year does not necessary mean year 2000 ready. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 13:40:35 on 96/11/20 GMT (by GBCADH00 at ELINK) Subject: An application coding bug and Y2K Beware of supplying date ranges to applications with 31/12/99 as the final date. One of our vendor supplied applications failed as it went into an infinite loop. Their coding went along the lines of a) Process a date b) Add 1 to date, normalise as necessary c) If date > high-range goto (e) d) goto (a) e) continue This append was created on the External IBMLink system by Nick Hands-Clarke (GBFPLNHC at IBMMAIL.COM) FPLO (+44-1306 740123 ext 3121) ----- YEAR2000 CFORUM appended at 13:46:57 on 96/11/20 GMT (by Y2KTSC at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 12:03:40 on 96/11/20 GMT (by GBCBHG00 at ELINK) I must take exception with "negligible benefit". There are many enhancements from OS/VS COBOL to COBOL for MVS and VM including the following: - Evaluate statement (a form of case statement) - In-line Perform statement - Enhanced If-Then-Else structure - Enhanced Call parameter passing - Pointer data items - Intrinsic functions - Object-oriented coding structure And others things I can think of right off. All of these enhancements all one to write more structured, easier to maintain code. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 16:37:02 on 96/11/20 GMT (by THOMEN at SJFEVMX) Subject: General question on compilers and YR2000 Ref: Append at 12:03:40 on 96/11/20 GMT (by GBCBHG00 at ELINK) > At this point in time my answer is that the business must decide. To be > supported requires considerable change (OS/VS Cobol to Cobol for MVS and > VM) with negligable (?) benefit for an application who's date processing > is not dependant on compiler/system returned dates. Realize that there is no inherent obligation to ensure that unsupported software continues to operate properly. Over time subtle changes may be made in components outside the compiler, and those changes may not be compatible with the compiler, its runtime library, or the generated code. If a business considers this "negligible benefit" then that is of course their choice. Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 16:42:09 on 96/11/20 GMT (by Y2KTSC2 at STLVM6) Isolating everything associated with a Year 2000 system is the only >way to prevent any confusion with a current-date system. This is no >different from isolating any test-only system from production-only >systems. Some products/data may not need to be isolated. Running >shared DASD may not be a problem providing you can guarantee that no >files created on the Year 2000 system are ever accessed by a >current-date system. However, this is probably more work than >isolating your DASD and copying the files you need. CAUTION!!! Sharing DASD that contains catalogs, when those catalogs are also shared may result in data being placed in catalog entries for data sets that are ACCESSED by a system running dates after year 2000. Such data may be INCOMPATIBLE with the shared systems that are running prior to year 2000 and may not yet have software that is fully Yr2000 ready. It is NOT an exposure only for files that are CREATED, it is an exposure for files that are ACCESSED. This is an example of side-effects resulting from not knowing all of the actions taken and dependencies on date processing within MVS software. | Customers should NOT assume that they understand the effect of sharing | DASD between YR2000-ready and non-YR2000-ready systems solely on the | basis of their view of externals. The internals may be what kill | you if you don't follow the documentation. You will ESPECIALLY have problems if you use VSAM catalogs during this testing, as there is NO support in VSAM catalog for dates after 1/1/2000, and there never WILL be - they will be disabled after 12/31/1999 (as will CVOLs). Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 14:12:02 on 96/11/25 GMT (by 9WARLTK at CROVM4) Subject: General question on compilers and YR2000 Ref: Append at 14:27:04 on 96/11/21 GMT (by Y2KTSC1 at STLVM6) and: Append at 21:31:08 on 96/11/22 GMT (by Y2KTSC2 at STLVM6) The append at 14:27:04 on 96/11/21 GMT (by Y2KTSC1 at STLVM6) says: Yes, executable code (load module) compiled by the OS/VS Cobol compiler or the Cobol II compiler will still function unchanged after 31/12/1999. Year 2000 Technical Support Center The append at 21:31:08 on 96/11/22 GMT (by Y2KTSC2 at STLVM6) says: Today, IBM makes no guarantees that ANY program compiled, linked and running using OS/VS COBOL will execute. IBM also makes no guarantee that the OS/VS COBOL compiler will work. Using the OS/VS COBOL compiler is at your own risk! Year 2000 Technical Support Center Could you please remove the incorrect append? If the second append is the correct one, could you please update it to say: Today, IBM makes no guarantee that ANY program compiled, linked and running using OS/VS COBOL run-time will execute..... This will then synchronize with: Subject: OS/VS COBOL with OS/390 - os390 COBOL CFORUM appended at 14:58:41 on 96/11/13 GMT (by TMROSS at STLVM20) Ref: Append at 13:51:53 on 96/11/13 GMT (by JEPOL at SPOVMSIB) > Will OS/390 v2 support OS/VS COBOL ? Will applications written with >OS/VS COBOL run on OS/390 v2 ? IBM fully supports programs compiled with OS/VS COBOL that are linked and running with the Language Environment for MVS & VM run-time library running under OS/390, any release. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 17:04:25 on 96/11/25 GMT (by Y2KTSC2 at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 14:12:02 on 96/11/25 GMT (by 9WARLTK at CROVM4) Will OS/390 v2 support OS/VS COBOL ? Will applications written with <>OS/VS COBOL run on OS/390 v2 ? < DFSORT/MVS is on the WWW at http://www.storage.ibm.com/software/sort/srtmhome.htm ----- YEAR2000 CFORUM appended at 20:59:54 on 96/11/25 GMT (by IL68779 at ELINK) Subject: General question on compilers and YR2000 Ref: Append at 17:04:25 on 96/11/25 GMT (by Y2KTSC2 at STLVM6) >The currently supported compiler is COBOL for MVS & VM. The currently >supported link and execute product is LE for MVS & VM. It is >recommended that all COBOL be migrated/upgraded to these products. > >Year 2000 Technical Support Center Why does IBM insist on saying that "COBOL for MVS & VM" is the the currently supported compiler when "VS COBOL II" is fully supported? Should the correct statement be : "The currently recommended compiler is 'COBOL for MVS & VM' ?" Kal Biro (201) 994-5056 kbiro@e-mail.com IBMMAIL(USS248T4) ----- YEAR2000 CFORUM appended at 21:16:34 on 96/11/25 GMT (by BOBKING at GDLVM7) Subject: DFSORT and special dates Ref: Append at 19:06:18 on 96/11/25 GMT (by YAEGER at SJFEVMX) Thanks very much for your response. I'll get with the customer after the holiday and see what we can do with your suggestions and maybe user exits. Bob King IBM/ISSC Endicott BobKing at GDLVM7 bobking@vnet.ibm.com ----- YEAR2000 CFORUM appended at 22:35:02 on 96/11/25 GMT (by Y2KTSC2 at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 20:59:54 on 96/11/25 GMT (by IL68779 at ELINK) <>The currently supported compiler is COBOL for MVS & VM. The currently <>supported link and execute product is LE for MVS & VM. It is <>recommended that all COBOL be migrated/upgraded to these products. <> <>Year 2000 Technical Support Center < As the Y2000 centre says, dont assume that things will be fine if >you think you understand the externals. In fairness to the Yr2000 center, I really think that comment was mine, and I'm not part of the Yr2000 center... Of course I'm happy someone else agrees with me! Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 17:28:32 on 96/11/26 GMT (by Y2KTSC2 at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 14:27:04 on 96/11/21 GMT (by Y2KTSC1 at STLVM6) Per request by Keith Waltier the new statement is: Executable code (load module) compiled by the OS/VS Cobol compiler or the Cobol II compiler will still function unchanged after 31/12/1999 and will be supported if using Language Environment for MVS & VM as the linkedit and run-time library. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 17:35:05 on 96/11/26 GMT (by Y2KTSC2 at STLVM6) Subject: General question on compilers and YR2000 Ref: Append at 14:12:02 on 96/11/25 GMT (by 9WARLTK at CROVM4) The paragraph which states: While it is nice to be informed of other peoples views, correct or >not, of concerns in regard to the impending Year 2000 'problem', >I would suggest addressing all questions/explaintions/offers of advice, >to the people who will ultimately help. i.e. The Year 2000 group and >the Centre of Competance. While it is nice to be informed that such groups exist, I would suggest it's stretching it just a little to imply nobody else can help! Andy Wood. This append was created on the External IBMLink system by Westpac Banking Corp ----- YEAR2000 CFORUM appended at 18:36:07 on 96/11/27 GMT (by 75840348 at EHONE) Subject:LE/370 questions ... Hi guys, I've got some questions for you ... * What do I have to do for: (please specify if RECOMPILE or RELINK is needed) - VS COBOL II programs calling PL/I via static calls ...... - VS COBOL II programs calling PL/I via dynamic calls ...... - PL/I programs calling VS COBOL II via static calls ...... - PL/I programs calling VS COBOL II via dynamic calls ...... - C/370 programs calling VS COBOL II via static calls ...... - C/370 programs calling VS COBOL II via dynamic calls ...... - C/370 programs calling COBOL for MVS via static calls ...... - C/370 programs calling COBOL for MVS via dynamic calls ...... * Do I have to recompile or relink C/370 modules with C/C++ compiler ? * Do I have to recompile OS PL/I V1.1 thru V2.3 programs ? * Do I have to relink OS PL/I V1.3 thru V1.5 programs ? * Do I have to relink/recompile programs that use OS PL/I shared library ? * Can anybody help me to better understand if I have to relink COBOL programs to ensure they are all RES or all NORES ? * Is LE required as runtime environment for COBOL for MVS ? * Do I have to migrate or convert something to arrive to COBOL for MVS from VS COBOL II ? Is only recompile or relink needed ? * Is LE required as runtime environment for PL/I for MVS ? * Is LE required during PL/I for MVS compilation ? * Do I have to migrate PL/I V2 to PL/I for MVS ? I know these are a lot of questions. I found something about them on Migration and Conversion books of each product but I'd like to know something more from someone who did such conversions... I think it could be a nice (and useful|) thing to record all of these (and any others, why not?) questions in a document, don't you think ? I hope you can help me .................. Thanks in advance | ANDREA. P.S. Please, answer even to only one of these questions ||| ----- YEAR2000 CFORUM appended at 19:29:31 on 96/11/27 GMT (by Y2KTSC2 at STLVM6) Subject: LE/370 questions ... Ref: Append at 18:36:07 on 96/11/27 GMT (by 75840348 at EHONE) ... But, from a Year >2000 perspective, PL/I for MVS & VM is the only Year 2000 Ready PL/I >compiler. A prior append said: >Compilers: A year 2000 ready compiler has a 4-digit year date stamp >for things like the compiler listing and may provide built-in support >for a 4-digit year to the program. In what way is PL/I 2.3 not Year 2000 Ready? Andy Wood This append was created on the External IBMLink system by Westpac Banking Corp ----- YEAR2000 CFORUM appended at 09:37:11 on 96/11/28 GMT (by 9WARLTK at CROVM4) ..... YEAR2000 CFORUM modified at 12:34:42 on 96/12/04 GMT (by 9WARLTK at CROVM4) Subject: Why fix dead code? How much effort do you want to spend making dead code Year 2000 compliant? Probably not much. Could you use an IBM service to find the dead programs in your inventory and find the dead code in your live programs before any other YEAR 2000 compliance activity. Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK 9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM ----- YEAR2000 CFORUM appended at 13:09:45 on 96/11/28 GMT (by GBCBHG00 at ELINK) Subject: MVS Y2K Testing Firstly, when appending could you ensure that whatever method you are using retains the Subject line. CONFER requires this, without out it the append tree is lost, and it not possible to append on the same subject, we must start a new thread. Secondly, my comments were sent by email to 'mhvrcfs@vnet.ibm.com', to which I received an electronic reply saying it had been received. I then contacted 'keith_warltier@uk.ibm.com' who suggested that Iris York 'IYORK@VNET.IBM.COM' was the person to deal with this. I sent her the details. If you can give me an EMAIL address I will send a copy to you Basically the request was for the following information to be added 1) How dates should be set (this has been partially stated - GMT crucial) 2) How to check date has been set correctly 3) Implications of using this type of environment; ie MVS under LPAR as opposed to MVS in BASIC mode 4) Risks involved; ie Any connected hardware (ie dasd) may be infected with dates as a result all data must be isolated from any production systems and should be considered as disposable 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:21:57 on 96/11/28 GMT (by GBCBHG00 at ELINK) Subject: Yeare 2000 and Cobol - continued from append 80 - no subject > Today, IBM makes no guarantees that ANY program compiled, linked and > running using OS/VS COBOL will execute. IBM also makes no guarantee > that the OS/VS COBOL compiler will work. Using the OS/VS COBOL > compiler is at your own risk! I have a major problem with this statement. In a question I asked in this CFORUM regarding OS/VS Cobol and Cobol II generated programs as to if they will continue to run the Year 2000 support center advised: > Yes, executable code (load module) compiled by the OS/VS Cobol compiler > or the Cobol II compiler will still function unchanged after 31/12/1999 Is this correct or not !!!!! I/we need a definitive answer. Will a program which contains no date logic which has been compiled by the OS/VS Cobol or Cobol II compilers continue to function unchanged (ie no code change, no recompilation, no re-link) after 31/12/1999? 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:27:04 on 96/11/28 GMT (by GBCBHG00 at ELINK) Subject: MVS Y2K Testing Ref: Append at 12:57:20 on 96/11/25 GMT (by THOMEN at SJFEVMX) Mark, This is the kind of information which *MUST* be incorporated into the Y2K Guide for 2 digit dates GC28-1251-04. We need to know the implications. I am aware that the Y2K test system must be totally isolated to guarentee integrity - of both your production and Y2K test systems. And I must state TOTALLY isolated, until quantified by IBM otherwise. By totally isolated I mean - no shared hardware at all. 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:38:17 on 96/11/28 GMT (by GBCBHG00 at ELINK) Subject: General question on compilers and YR2000 Ref: Append at 17:04:25 on 96/11/25 GMT (by Y2KTSC2 at STLVM6) Firstly forgive me for my pendantiveness - but > The currently supported compiler is COBOL for MVS & VM. The currently > supported link and execute product is LE for MVS & VM. It is > recommended that all COBOL be migrated/upgraded to these products. Is it recommended or necessary. I asked these questions and I am being confused by symantics. I have systems written in Cobol compiled with OS/VS Cobol and Cobol II which I need to know if the must be modified to run after 31/12/1999. They contain no date logic. Please advise me of the modifications required to *ENSURE* that they continue to function after 31/12/1999 1) Do I need to re-compile (using Cobol for MVS and VM of course) 2) Do I need to re-link (using Cobol for MVS run times or LE/370) 3) Are Cobol for MVS and VM or LE/370 runtimes downwardly compatable with OS/VS Cobol or Cobol II run-times I understand that in a perfrect world we would install Cobol for MVS and VM and LE/370, modify all of our programs to use these and we would be there. But realistically this is not possible. IBM Please tell us unambiguously the minimum changes required for programs written for and compiled in OS/VS Cobol and Cobol II such that they will continue to run beyond 31/12/1999. 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:07:19 on 96/11/28 GMT (by THOMEN at SJFEVMX) Subject: Yeare 2000 and Cobol - continued from append 80 - no subject Ref: Append at 13:21:57 on 96/11/28 GMT (by GBCBHG00 at ELINK) Your question is conclusively answered in the append: Subject: General question on compilers and YR2000 Ref: Append at 14:12:02 on 96/11/25 GMT (by 9WARLTK at CROVM4) Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 14:17:48 on 96/11/28 GMT (by THOMEN at SJFEVMX) Subject: General question on compilers and YR2000 Ref: Append at 13:38:17 on 96/11/28 GMT (by GBCBHG00 at ELINK) >> The currently supported compiler is COBOL for MVS & VM. The currently >> supported link and execute product is LE for MVS & VM. It is >> recommended that all COBOL be migrated/upgraded to these products. > >Is it recommended or necessary. I asked these questions and I am being >confused by symantics. I think you might be trying too hard. When I reread the referenced append, it seems to be very clear. If you have an object module compiled under OS/VS COBOL and relink it with the LE runtime, it will be supported. Not the compiler, the relinked object code. Period. If you continue to compile using OS/VS COBOL, you will most likely have problems. If you do not relink using the LE runtime, you will most likely have problems (regardless, you will be unsupported). Based on those comments, the above statement is absolutely correct: IBM RECOMMENDS that you upgrade to the current compiler and runtime to AVOID the potential of having problems from running an unsupported COMPILER or RUNTIME. It does NOT say it is necessary. Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 20:14:56 on 96/11/28 GMT (by IL68778 at ELINK) Subject: General question on compilers and YR2000 Ref: Append at 14:17:48 on 96/11/28 GMT (by THOMEN at SJFEVMX) > Appended at 14:17:48 on 96/11/28 GMT (by THOMEN at SJFEVMX) > Subject: General question on compilers and YR2000 > Ref: Append at 13:38:17 on 96/11/28 GMT (by GBCBHG00 at ELINK) > > I think you might be trying too hard. When I reread the referenced > append, it seems to be very clear. If you have an object module > compiled under OS/VS COBOL and relink it with the LE runtime, it will > be supported. Not the compiler, the relinked object code. Period. Do you mean that he has to relink *all* OS/VS COBOL programs, even the ones compiled with RES? Would that buy him anything? How about VS COBOL II programs compiled with RES? Do they have to be relinked also? Gilbert Saint-flour Automated Migration Services IBMMAIL(USS24LG4) IBMLINK(IL68778) ----- YEAR2000 CFORUM appended at 00:34:34 on 96/11/29 GMT (by AS103033 at ELINK) Subject: General question on compilers and YR2000 Ref: Append at 14:17:48 on 96/11/28 GMT (by THOMEN at SJFEVMX) >I think you might be trying too hard. When I reread the referenced >append, it seems to be very clear. If you have an object module >compiled under OS/VS COBOL and relink it with the LE runtime, it will >be supported. Not the compiler, the relinked object code. Period. It may be clear to some, but I have some trouble with this concept. Not all problems can be resolved by tweaking the runtime code. Sometimes the compiler has to be changed and the program compiled again. Andy Wood This append was created on the External IBMLink system by Westpac Banking Corp ----- YEAR2000 CFORUM appended at 07:37:27 on 96/11/29 GMT (by THOMEN at SJFEVMX) Subject: General question on compilers and YR2000 Ref: Append at 20:14:56 on 96/11/28 GMT (by IL68778 at ELINK) >Do you mean that he has to relink *all* OS/VS COBOL programs, >even the ones compiled with RES? Would that buy him anything? >How about VS COBOL II programs compiled with RES? >Do they have to be relinked also? From the append 19:29:31 on 96/11/27: "All load modules compiled with VS COBOL II, PL/I and C/370 - which are currently running with those product's runtime libraries, will need to be re-linked with the LE linkedit library in order to run with the LE runtime library. In the LE Migration Guide, there are special considerations listed for each of the languages. No recompiles are necessary. This should take care of the first 5 questions. You should relink all COBOL programs regardless of the setting of RES/NORES. NORES programs include all needed subroutines, so will not use any runtime library at execution time. If you might have a mixture of RES/NORES modules executing in the same run unit, there are many "gotchas" to look out for. There are documented aids for this (MIXRES support), but generally it's a better plan to stick to RES." I'm not from the compiler group, but from looking at the appends that are getting posted to answer these questions, it seems that: - unless you're running the COBOL for MVS & VM compiler you are at risk - unless you're using the named LE runtime library, you're at risk - at a minimum you need to relink VS COBOL programs using the proper LE level - if your programs have no date-dependent code in them, and you've relinked with the proper level of LE runtime library, your code should work properly after 1/1/2000. - if you didn't relink, or your code has date-dependent logic in it, there is no guarantee it will work after 1/1/2000. Having been a customer and having done these types of things in the past, I can understand the concern about the work involved. However, from experience I also know the results of betting that it's OK not to follow the recommen- dations. I only wish when I'd have been faced with the upgrades I dealt with that I'd had 3+ years to work on it. Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 11:11:40 on 96/11/29 GMT (by GBCAGM48 at ELINK) Subject: MVS Y2K Testing Ref: Append at 13:27:04 on 96/11/28 GMT (by GBCBHG00 at ELINK) Does complete isolation also mean that the use of EMIF and device candidate lists to provide access from an LPAR to a subset of dasd under a 3990-6 controller is also excluded? i.e. if we have two LPARs on a 9021, each with access to a 3990, but with device candidate lists defined to separate out ranges of devices between the two LPARs, with NO sharing of those disks AT ALL, do we have a problem? Is the fact that the 3990 is still physically shared going to cause problems? This append was created on the External IBMLink system by Paul Sheils Tel: 0131-442-7873 Technical Consultant Fax: 0131-442-7441 System Software email:paul_sheils@bankofscotland.co.uk Bank of Scotland or:100642.2004@compuserve.com ----- YEAR2000 CFORUM appended at 11:26:22 on 96/11/29 GMT (by THOMEN at SJFEVMX) Subject: MVS Y2K Testing Ref: Append at 11:11:40 on 96/11/29 GMT (by GBCAGM48 at ELINK) I'm not that familiar with all the "LPARspeak" but if I understand you correctly, the LPARs are barred from looking at the DASD that is not defined as belonging to them. In this case it would seem to be exactly the same as the devices being physically separated, so I would expect you would be safe. None of the software on LPAR "A" could certainly try to reference dasd on LPAR "B"... Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 15:24:42 on 96/11/29 GMT (by GBCAGM48 at ELINK) Subject: MVS Y2K Testing Ref: Append at 11:26:22 on 96/11/29 GMT (by THOMEN at SJFEVMX) That's correct, the software (MVS) will not see the dasd that's not in the partition's candidate list. But the controller is still physically connected to the processor. Is the controller itself affected by having a partition which is running with a date some time in the future connecting to it, at the same time as other partitions running the current date? This append was created on the External IBMLink system by Paul Sheils Tel: 0131-442-7873 Technical Consultant Fax: 0131-442-7441 System Software email:paul_sheils@bankofscotland.co.uk Bank of Scotland or:100642.2004@compuserve.com