----- YEAR2000 CFORUM appended at 19:07:41 on 97/02/04 GMT (by Y2KTSC5 at STLVM6) Subject: AIX 3.2.5 Year2000 handling Ref: Append at 22:14:49 on 97/01/23 GMT (by NEWSPOST at WATSON) AIX 3.2.5 is Year 2000 ready. Support is available through the service stream. To help identify a Year2000 APAR/PTF, the keyword YR2000 is added to the APAR and/or PTF cover letter text to assist searching. ----- YEAR2000 CFORUM appended at 03:22:34 on 97/02/05 GMT (by Y2KTSC3 at STLVM6) Subject: OS/VS COBOL Compiler in OS/390 environment Ref: Append at 17:51:35 on 97/01/27 GMT (by SHERRY at SJFEVMX) >>But a fix was produced for DFSMS because of an incompatible change >>which prevented old COBOL load modules from working. >Yes, a fix was provided when a change to DFSMS/MVS R3 was incompatible >with OS/VS COBOL object modules. Changes of this kind are reviewed on >an individual basis and resulted in a decision to change DFSMS/MVS >based on the business impact of the incompatibility. This change was >to permit the object modules to continue to run, which has been stated >as a point of compatibility. This should not be construed to indicate >that additional changes will be made, either for DFSMS/MVS or for OS/390. >Requiring use of the LE runtime library does not change the fact that >the object modules created with OS/VS COBOL can continue to function. If OS/VS COBOL programs are running using the LE libraries, (Which means relinked with REPLACE if NORES, or the OS/VS COBOL library replaced with LE if RES) then the DFSMS problem will never occur again, regardless of any changes that DFSMS makes to VSAM. We have fixed the VSAM OPEN/CLOSE module ILBOVOC in LE so that it no longer uses an undocumented interface with DFSMS. We did not fix OS/VS COBOL or VS COBOL II. If you want your OS/VS COBOL modules to run for a long time, then you need to get them running with Language Environment to avoid these types of problems. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 02:11:27 on 97/02/06 GMT (by CON1 at SYDVM1) Subject: year 2000 and year 1972 One of my customers has proposed an interesting idea for gettting around the Y2K problem. His premise is: 1972 has the calendar as 2000, so he changes all his dates to 1972 instead of 2000 This might be less work than fixing all the 2000 problems. He is an MVS customer. Does anyone know if there is a showstopper reason why MVS and its subsystems might not work under this scenario. Any comments would be appreciated. Con Yianakos ----- YEAR2000 CFORUM appended at 02:15:27 on 97/02/06 GMT (by THOMEN at SJFEVMX) Subject: Application Inventory tools Ref: Append at 11:36:17 on 96/08/13 GMT (by GBCBHG00 at ELINK) I'm puzzled; what does this have to do with the YEAR2000 forum? Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 09:31:28 on 97/02/06 GMT (by 62418658 at EHONE) Subject: year 2000 and year 1972 Ref: Append at 02:11:27 on 97/02/06 GMT (by CON1 at SYDVM1) Does this mean that the customer will IPL its MVS system with the system date 1972 on Jan 1 2000 ? This will not solve any problem (except that a calendar will show a sunday on a sunday...). All the programs will be fooled. I guess the company produces invoices and these will show a past date of 1972... it may be that the client has no longer to pay it legaly | All employees become 28 years younger... they'll all be dead before they can retire | Etc. All dates using 2 digits will still have the ambiguity - e.g. is 35 2007 (2035) or is it 1907 (1935) ? So, to solve the problems, the customer would have to change all programs to account for the difference of 28 years... not speaking about system services that use file creation dates for backups etc. Guy De Ceulaer - VM Support - Belgium ----- YEAR2000 CFORUM appended at 13:58:03 on 97/02/06 GMT (by 61821013 at VIEVMA) Subject: PL1 Preprocessor-Function COMPILETIME According to the latest version of the latest Year 2000 Planning Guide the product: 5668-910 IBM OS PL/I OPTIMIZING COMPILER VER 2 REL 3 MOD 0 should be Year2000 ready. The PL1 Preprocessor-Function COMPILETIME returns only 2 digits for the year. |||??? Hermann Augesky Y2K-TEAM Vienna, IBM Austria/CER ----- YEAR2000 CFORUM appended at 14:17:07 on 97/02/06 GMT (by GAD at KGNVMC) - Subject: PL1 Preprocessor-Function COMPILETIME Ref: Append at 13:58:03 on 97/02/06 GMT (by 61821013 at VIEVMA) A new function named COMPILEDATE has been added via APAR to some versions of PL1. I don't see an APAR for this specific version, though. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 14:49:47 on 97/02/06 GMT (by 61821013 at VIEVMA) Subject: PL1 Preprocessor-Function COMPILETIME Ref: Append at 14:17:07 on 97/02/06 GMT (by GAD at KGNVMC) Function "COMPILEDATE" is not known with this Compiler-Version. If there is no PTF, who should raise an APAR ? The Planning Guide too, should be updated accordingly. Hermann Augesky Y2K-Team Vienna, IBM Austria/CER ----- YEAR2000 CFORUM appended at 15:20:16 on 97/02/06 GMT (by Y2KTSC3 at STLVM6) Subject: PL1 Preprocessor-Function COMPILETIME Ref: Append at 13:58:03 on 97/02/06 GMT (by 61821013 at VIEVMA) >The PL/I Preprocessor-Function COMPILETIME returns only 2 digits for >the year. !!!??? The definition of Year 2000 Ready does not include changing every function to return 4-digit year dates. For example, the ANSI COBOL Standard requires that ACCEPT xxx FROM DATE gives a 2-digit year date. As long as a language product will continue to run after 1999, and also provides SOME way to get 4-digit year dates, and is fully supported by IBM service, then it is Year 2000 ready. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 15:42:21 on 97/02/06 GMT (by Y2KTSC3 at STLVM6) Subject: year 2000 and year 1972 Ref: Append at 02:11:27 on 97/02/06 GMT (by CON1 at SYDVM1) >His premise is: >1972 has the calendar as 2000, so he changes all his dates to 1972 >instead of 2000 >Does anyone know if there is a showstopper reason why MVS and its >subsystems might not work under this scenario. YES! You will run into the same problems that any "Time Machine" will cause. You cannot tie a future machine and a present machine (or in your suggestion, a present machine and a past machine) to the same DASD and have it work. For example, if you have an update attempted in 1972 to a file that was last accessed in 1997, it will not work. This is exactly why a machine or LPAR IPL'ed to 2000 or later must not share system resources (DASD,tape,etc) with an LPAR IPL'ed to 1997. Interesting idea, but I have heard a million ideas so far, and there is no "Silver Bullet"! Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 15:46:17 on 97/02/06 GMT (by Y2KTSC3 at STLVM6) Subject: Year 2000 Work Bench Ref: Append at 10:29:11 on 97/01/28 GMT (by SAITOT at TOKVMSDC) >I would like to know the Year 2000 Work Bench which is available for >COBOL, ASM, and PL/I (in host environment, maybe). Are you asking about an IBM product? Work Bench is a trademarked name that IBM cannot use. We have a Redeveloper set of tools that comes with VisualAge for COBOL, is that what you are asking about? We are working on a lot of tools, but nothing to announce for PL/I and assembler yet. We will have announcements in 1997...stay tuned! Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 11:20:20 on 97/02/07 GMT (by 75407594 at EHONE) Subject: Dataset Expiry Dates I have searched through the on-line web version of the Implementation and Planning Guide for an answer to the following question posed by a customer. "We have various tape and dasd datasets with an expiry date of 99/365 which, when they were first set up, was thought to mean it would not expi With the approach of that magical date can someone tell us what is likely happen to all those datasets on that day or the day after. Will they all and we end up with masses of free disk space and tape storage ?" ----- YEAR2000 CFORUM appended at 11:36:10 on 97/02/07 GMT (by 75407594 at EHONE) Subject: Dataset Expiry Dates I have looked through the Year 2000 web site's on-line version of the Implementation and Planning Guide for guidelines on dataset expiry dates but to no avail. The following question has been asked by a customer :- "We have various tape and dasd datasets with an expiry date of 99/365 which, when they were first set up, was thought to mean it would not expi With the approach of that magical date can someone tell us what is likely happen to all those datasets on that day or the day after. Will they all and we end up with masses of free disk space and tape storage ?" ----- YEAR2000 CFORUM appended at 11:57:05 on 97/02/07 GMT (by GAD at KGNVMC) - ..... YEAR2000 CFORUM modified at 11:58:21 on 97/02/07 GMT (by GAD at KGNVMC) . Subject: Dataset Expiry Dates Ref: Append at 11:36:10 on 97/02/07 GMT (by 75407594 at EHONE) This has **long** been documented in the MVS/ESA JCL Reference; there is no reason for it to be in the planning guide as it is old function. (19)99.365 *is* treated as a special date, and will *not* be expired. It can only be set explicitly; if a RETPD value falls on 1999.365 it is given an extra day so it instead expires on 2000.001. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 12:43:01 on 97/02/07 GMT (by JOHNORR at ISSCAUS) Subject: Dataset Expiry Dates Ref: Append at 11:58:21 on 97/02/07 GMT (by GAD at KGNVMC) Thanks for the quick and precise answer - but I beg to differ that "thare is no reason for it to be in the planning guide as it is old function. (19)99.365 *is* treated as a special date, and will *not* be expired. It can only be set explicitly; if a RETPD value falls on 1999.365 it is given an extra day so it instead expires on 2000.001. Greg Dyck MVS BCP Kernel and CURE support ÿÿDataset Expiry Dates John Orr (johnorr@isscaus.vnet.ibm.com) ----- YEAR2000 CFORUM appended at 12:52:49 on 97/02/07 GMT (by JOHNORR at ISSCAUS) Subject: Dataset Expiry Dates Ref: Append at 11:58:07 on 97/02/07 GMT (by GAD at KGNVMC) Oops ... finger trouble.... Thanks for the quick and precise answer, but I beg to differ that "there is no reason for it to be in the planning guide as it is an old function". The "technical" answer is as you stated, but the "human factors" answer recognises that not every Y2000 planner is (or should be) familiar with detail from the MVS JCL manual. The idea of a planning guide is to bring together information from multiple sources to help people in what is already a complex information-gathering task. Doesn't hurt to repeat what is obvious to some.... :=) - John Orr ISSC Australia ----- YEAR2000 CFORUM appended at 17:32:18 on 97/02/07 GMT (by THOMEN at SJFEVMX) Subject: Dataset Expiry Dates Ref: Append at 12:52:49 on 97/02/07 GMT (by JOHNORR at ISSCAUS) If we repeated everything in our planning manuals that has been shipped (and documented) function for quite a while, no one would be able to lift it. Mark Thomen DFSMS Development (Catalog/IDCAMS/VSAM) SJFEVMX/THOMEN or USIB54WA at IBMMAIL ----- YEAR2000 CFORUM appended at 21:22:03 on 97/02/08 GMT (by SHIMADAR at STLVM6) Subject: PL1 Preprocessor-Function COMPILETIME Ref: Append at 15:20:16 on 97/02/06 GMT (by Y2KTSC3 at STLVM6) The following PL/I apars have been opened to support the new PL/I MACRO Preprocessor COMPILEDATE built-in for Year 2000: PQ01168 (OS PL/I V2R3) PN92224 (PL/I for MVS & VM V1R1M1) COMPILEDATE returns a char(17) string holding the current date and time as all numerics (just like the built-in DATETIME). It includes a 4-digit year for Year 2000, versus the 2-digit year provided by the COMPILETIME built-in. Bob Shimada PL/I Service ----- YEAR2000 CFORUM appended at 01:10:12 on 97/02/10 GMT (by HELENE at NYCVMIC1) Subject: 1972 - data encapsalation I just attended a conference where they talked about how to do data encapsolation - and have used 1972 to successful change programs to handle Year 2000. It's recommended only as a fast alternative to bide time until you have time to do data expansion. All data must have 28 years subtracted from it. The only changes that need to be made in the program is to change date literals that are used in comparisons. Users who enter data containing dates must also be trained to subtract 28 years from any date fields. Although this doesn't require the use of a LPAR or a simulated date clock, it will only work in a very limited environment where data isn't shared between many databases. Alternative strategies of program encapsolation were also discussed Helene Schiffman (Helene at NYCVMIC1) ----- YEAR2000 CFORUM appended at 09:23:14 on 97/02/11 GMT (by X04 at TELVM1) - Subject: Y2000 support for IBM product programs I want to know the year2000 status of several program products that are not mentioned in "The year 2000 and 2-Digit Dates : A Guide for Planning and Implementation" publication: - 5668-896 APE - 5668-808 APE V2 - 5688-015 Bookmaster - 5684-091 DisplayWriter/370 Shimeon Ginsburg ----- YEAR2000 CFORUM appended at 11:05:02 on 97/02/11 GMT (by 75407594 at EHONE) Subject: Y2000 support for IBM product programs Ref: Append at 09:23:14 on 97/02/11 GMT (by X04 at TELVM1) These product Year 2000 questions will be handled by the IBM EMEA Year 2000 Technical Support Centre at Y2KTSCE@IE.IBM.COM. We will respond directly to you. IBM EMEA Year 2000 Technical Support Centre. ----- YEAR2000 CFORUM appended at 13:49:44 on 97/02/11 GMT (by NLTRACY at PKMFGVM3) Subject: Answers on Product Readiness Please make the answers you find on the YR200 status of specific products available on this forum. The VM PSP buckets are missing information and there seems to be some confusion about quite a few products. Anything you can find will help the VM System Programmers plan for YR2000 roll outs. Neale Tracy ----- YEAR2000 CFORUM appended at 14:44:51 on 97/02/11 GMT (by SORBER at ENDVM5) Subject: Answers on Product Readiness Ref: Append at 13:49:44 on 97/02/11 GMT (by NLTRACY at PKMFGVM3) Yes, I agree with Neale. It benefits all of us to have questions answered on this forum. In fact, I would go further and encourage the owners/answerers of this forum to post questions they may have received offline to this forum with answers. We'll all benefit. Thanks, Tom Sorber ----- YEAR2000 CFORUM appended at 14:46:07 on 97/02/11 GMT (by IYORK at KGNVMC) Subject: Y2000 support for IBM product programs Ref: Append at 09:23:14 on 97/02/11 GMT (by X04 at TELVM1) These products are listed in the guide. Try looking again and please read the preface before the appendix. Iris ----- YEAR2000 CFORUM appended at 15:33:35 on 97/02/11 GMT (by RSIVARAM at TOROVM1) Subject: This is a test Rajesh Sivaraman (905) 316-2137 ----- YEAR2000 CFORUM appended at 17:28:26 on 97/02/11 GMT (by Y2KTSC6 at STLVM6) Subject: This is a test Ref: Append at 15:33:35 on 97/02/11 GMT (by RSIVARAM at TOROVM1) Please use the TESTER FORUM for practice. ----- YEAR2000 CFORUM appended at 23:20:41 on 97/02/13 GMT (by Y2KTSC3 at STLVM6) Subject: Support for old COBOL programs >Recently, on the YEAR2000 CFORUM, an append stated that IBM will >continue to provide service support for the execution of programs >compiled with the OS/VS COBOL and VS COBOL II compilers as long as >these programs are using the Language Environment (LE) for MVS >versions of the COBOL library routines. >Where is this statement of support officially documented? In the Licensed Program Specifications for LE, GC26-4774-06. It just says that the old programs will run with LE. This means that once they are running on LE, if a problem crops up that is a bug in LE, then IBM will fix it. >Also which version/release levels of the COBOL compilers are supported? I will answer this 2 ways. There are 2 COBOL compilers currently supported by IBM: VS COBOL II Release 4 and COBOL for MVS & VM Release 2 LE supports programs compiled by the following COBOL compilers: OS/VS COBOL Release 2 VS COBOL II Release 3 or later COBOL/370 Release 1 COBOL for MVS & VM Release 2 >Since LE also provides a run-time environment PL/I, C, and Fortran, >is this same statement of service support valid for them?" Yes. For PL/I, OS PL/I V1.3 (object modules) V1.5.1 (load modules) and OS PL/I Version 2 programs are supported. For C, programs compiled by C/370 V1 and V2 are supported by LE For Fortran, VS Fortran V1 and V2, FORTRAN IV H and FORTRAN IV G programs are supported, MVS non-CICS only. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 23:29:43 on 97/02/13 GMT (by Y2KTSC3 at STLVM6) Subject: CCCA and Report Writer >I have a question from an IBMer in Hong Kong whos client is migrating >from OS/VS COBOL to VS COBOL II. There are some Reportwriter functions >in the OS/VS COBOL programs and he wants to know if these need to be >'precompiled' in the migration using the program offering Report Writer >Precompiler (# 5798-DYR). Yes, they will need to be precompiled every time they are compiled after they are migrated to VS COBOL II. >The client is also planning to use CCCA and I am not sure that it will >handle Reportwriter functions (I am aware that the Report Writer was an >integral function of OS/VS COBOL but it is now a separate product). CCCA will tolerate the Report Writer language. You can convert Report Writer programs with CCCA and then use the Precompiler which handles any Report Writer statements (68/74/85) Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 13:54:19 on 97/02/18 GMT (by 86208250 at EHONE) Subject: MVS/ESA 4.3 Hi, I would like to ask a question, may be silly one,but I have to. One of my MVS customers would like to open an LPAR to perform their year2000 tests from the installed SW and applications point of view. But their MVS level is 4.3. As far as I know MVS/ESA 4.3 is not year200 compliant product. Could it be still possible to make their tests or should they definitely migrate to ESA V5 or OS390 ?. Thanks a lot for an urgent reply. ----- YEAR2000 CFORUM appended at 00:23:04 on 97/02/20 GMT (by Y2KTSC3 at STLVM6) Subject: MVS/ESA 4.3 Ref: Append at 13:54:19 on 97/02/18 GMT (by 86208250 at EHONE) >One of my MVS customers would like to open an LPAR to perform their >year2000 tests from the installed SW and applications point of view. >But their MVS level is 4.3. As far as I know MVS/ESA 4.3 is not >year200 compliant product. Could it be still possible to make >their tests or should they definitely migrate to ESA V5 or OS390 ?. As long as the Year 2000 tests are using a date simulator and not actually changing the system clock, then MVS 4.3 is fine. If they want to set up a "Time Machine", that should not be done until all of the system software is migrated to Year 2000 ready levels, and probably after the applications are fixed as well. Most shops should not do any "Time Machine" (changed system clock) until 1999. In your customer's case, they will just discover the problems that we already know about in old system software. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 01:39:25 on 97/02/21 GMT (by MPRINCIP at RHQVM09) Subject: IBM System Software Release Levels needed to handle Y2K We are working with a major corporation who has many old versions of COBOL, MVS, CICS, etc. We need a list of system software levels that will be a problem at the turn of the century that will force us to upgrade the applications for the new release. For example, the customer is at CICS version 1.7. We have heard that CICS version 4.1 is required to be Y2K compliant. Is there an overall list of system software levels that will be a problem along with the 'typical' types of application code changes that will be required to upgrage? Any and all help greatly appreciated! Mary Principe MPRINCIP at RHQVM09 ----- YEAR2000 CFORUM appended at 03:34:08 on 97/02/21 GMT (by LAURAG at SYDVMXA2) 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) Mary, I am a member of the Asia Pacific Year 2000 Technical Support Centre and I noticed your entry in the forum. The information you seek is in the Appendix of "The Year 2000 and 2-Digit Dates: A Guide for PlanningImplementation" (GC28-1251-05). A soft copy of this guide is available on the Internet. The address of the home page for all related Year 2000 is http://www.software.ibm.com/year2000/resource.html. I hope these sources of information are of use to you, Regards Y2KTSCAP ----- YEAR2000 CFORUM appended at 17:23:58 on 97/02/21 GMT (by LATORRES at LASVM1) From: Silvina Latorre/Argentina/IBM@IBMAR (LATORRES @ LASNOTES) To: Mary Principe Date: 02-21-97 13:00:23 Subject: IBM System Software Release Levels needed to handle Y2K Mary: The information that you need, you will find it on "The Year 2000 and 2-Digit Dates: A guide for Planning and Implementation" (GC28-1251-05) that you can freely download from: http://www.software.ibm.com/year2000/resource.html In the Appendix A. Year2000-Readiness Status of Selected IBM Program Products and Hardware, you will find a complete list of Y2K compliant applications. You can also find more information in: http://www.s390.ibm.com/stories/year2000 If you want, contact us for further information. Regards. LA Technical Support Center. ----- YEAR2000 CFORUM appended at 18:01:59 on 97/02/21 GMT (by LESENDEL at LASVM1) From: Jose Luis Calzato/Argentina/Contr/IBM @ IBMAR to: Sheldon Potolsky Date: 02-21-97 14:54:03 Subject: Definition of Year 2000 Compliant. Sheldon, I have a definition that is used by IBM that is in the "year 2000 and 2-Digit Dates: A Guide for Planning and Implementation" (GC28-1251-05), that you can find at: http://www.software.ibm.com/year2000/resource.html that states the following: IBM defines Year2000-Ready as follows: The capability of a Product, when used in accordance with its associated documentation, to correctly process, provide and/or receive date data within and between the 20th and 21st centuries, provided that all other products (for example, hardware, software, and firmware) used with the Product, properly exchange accurate date data with it. I hope this definition will help you. Jose Luis Calzato - TSC Latin America South. ----- YEAR2000 CFORUM appended at 16:26:49 on 97/02/25 GMT (by PALIN at CANVM2) Subject: Cobol/II upgrade required? I have a customer who is currently using Cobol/II and when you use the accept verb it returns a 2 year digit field. The customer will be upgrading their OS to OS/390, will this resolve the year 2 digit problem or does the customer have to upgrade Cobol after the they have moved to OS/390??? Bernie Lock IBM Canada Ltd. ----- YEAR2000 CFORUM appended at 18:10:03 on 97/02/25 GMT (by Y2KTSC3 at STLVM6) Subject: VS COBOL II upgrade required? Ref: Append at 16:26:49 on 97/02/25 GMT (by PALIN at CANVM2) >I have a customer who is currently using VS COBOL II and when you >use the ACCEPT verb it returns a 2 digit year field. >The customer will be upgrading their OS to OS/390, will this >resolve the year 2 digit problem or does the customer have to >upgrade COBOL after the they have moved to OS/390??? The ANSI COBOL Standard states that the ACCEPT xyz FROM DATE command must return a 2-digit year date. No vendor can change this, least of all IBM! How could you put a 4-digit year into a 2-digit year field? You would over write data or cause program checks. Changing the operating system will not change the behavior of the programs. The only COBOL compiler that supports 4-digit year dates is the COBOL for MVS & VM compiler. In addition, VS COBOL II will be withdrawn from marketing and support in the near future, so customers should be migrating off of it as they solve the Year 2000 problem. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 00:39:46 on 97/02/26 GMT (by GGIESE at TORVM3) Subject: Language Environment and OS/VS Cobol Ref: Append at 17:13:48 on 97/02/24 GMT (by Y2KTSC3 at STLVM6) Hello, I have a customer who will not be moving off OS/VS Cobol. I have noticed that IBM will give support if they are using LE (which they are not at this time). My question is "2-digit date cannot be used with OS/VS, but if they link with LE, can they use 4-digit dates ?" P.S. I do not know much about Cobol, so please excuse me if this is a dumb question. Gordon E. Giese, ISM T & T (IBM Canada) (204) 941-2063 ----- YEAR2000 CFORUM appended at 10:22:51 on 97/02/26 GMT (by 36602370 at EHONE) Subject: Language Environment and OS/VS Cobol Ref: Append at 00:39:46 on 97/02/26 GMT (by GGIESE at TORVM3) As far as I know the only you will get a 4 digit year from OS/VS COBOL is to write your own assembler function. The ACCEPT verb will only ever return 2 digits (this is an ANSI standard). Paul Smith ----- YEAR2000 CFORUM appended at 21:13:14 on 97/02/26 GMT (by Y2KTSC3 at STLVM6) Subject: Language Environment and OS/VS COBOL Ref: Append at 00:39:46 on 97/02/26 GMT (by GGIESE at TORVM3) >I have a customer who will not be moving off OS/VS COBOL. I have >noticed that IBM will give support if they are using LE (which they >are not at this time). My question is "2-digit date cannot be used >with OS/VS, but if they link with LE, can they use 4-digit dates ?" First I would like to point out that moving to LE is moving off of the OS/VS COBOL run-time library. Second, there is no IBM supported way to get 4-digit year dates from programs compiled by the OS/VS COBOL compiler. And finally, if the customer does migrate to LE, they can compile with a later compiler to get 4 digit year dates without recompiling all programs in the shop. I will send you my previous append on COBOL, run-time library support and Year 2000. Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 21:17:48 on 97/02/26 GMT (by TOSTA at RIOSYS1) Subject: COBOL II ACCEPT Ref: Append at 02:59:03 on 97/01/14 GMT (by Y2KTSC3 at STLVM6) About VS COBOL II and ACCEPT, I have a question : Is that right that when VS COBOL II issues an ACCEPT to an Operating System (suppose MVS, no matter if Year 2000 Ready or not), ACCEPT will get the system date in packed decimal format with a Century indicator ? Is the Century indicator right ? I know that ANSI standard for COBOL requires to return only 2-digit year dates. Thanks in advance. ----- YEAR2000 CFORUM appended at 22:44:24 on 97/02/26 GMT (by GAD at KGNVMC) - Subject: COBOL II ACCEPT Ref: Append at 21:17:48 on 97/02/26 GMT (by TOSTA at RIOSYS1) What you can do to do this is to write a small assembler program that gets the current date using the TIME service and returns a 4 digit year in the expected format. Then replace all ACCEPT's for the date with this routine. That is the easiest way to get a 4 digit year returned to you. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 01:09:52 on 97/02/27 GMT (by Y2KTSC3 at STLVM6) Subject: VS COBOL II ACCEPT Ref: Append at 21:17:48 on 97/02/26 GMT (by TOSTA at RIOSYS1) >About VS COBOL II and ACCEPT, I have a question : >Is that right that when VS COBOL II issues an ACCEPT to an >Operating System (suppose MVS, no matter if Year 2000 >Ready or not), ACCEPT will get the system date in packed decimal >format with a Century indicator? Yes, if it is an MVS system that has that capability >Is the Century indicator right ? Yes, (again if it is an MVS system that has that capability) Year 2000 Technical Support Center ----- YEAR2000 CFORUM appended at 07:18:33 on 97/02/27 GMT (by ALANDP at SYDVMXA2) A client has been using the following document "COBOL/370 and COBOL for MVS & VM Compiler and Run-Time Migration Guide". >> 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?". Is there any word on this? Regards Year 2000 Technical Support Center - Asia Pacific Internet: y2ktscap@vnet.ibm.com VNET: Y2KTSCAP at SYDVMXA2 ----- YEAR2000 CFORUM appended at 11:55:54 on 97/02/27 GMT (by GAD at KGNVMC) - Subject: Mixed OS/VS Cobol to Assembler to OS/VS Cobol calls Ref: Append at 07:18:33 on 97/02/27 GMT (by ALANDP at SYDVMXA2) This question should be directed to the LE370 FORUM, as it is not a year 2000 issue as much as it is a LE usage issue. The experts on LE hang on on the LE370 forum. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 10:34:14 on 97/02/28 GMT (by 86454400 at EHONE) Subject: YEAR 2000 Compliant Products A customer wants to know if the following products are year 2000 compliant. If they are, which are the minimum releases required? CICS/VSAM RECOVERY - 5695-010 MERVA/ESA - 5655-039 Expedite/CICS - 5785-EEG CRYPTO - 5740-XY5 Thanks for any input. Origenes Mahuma ----- YEAR2000 CFORUM appended at 15:23:30 on 97/02/28 GMT (by TOSTA at RIOSYS1) Subject: VS COBOL II ACCEPT Ref: Append at 01:09:52 on 97/02/27 GMT (by Y2KTSC3 at STLVM6) Subject: VS COBOL II ACCEPT Ref: Append at 01:09:52 on 97/02/27 GMT (by Y2KTSC3 at STLVM6) Once again, if this information is right, then we need to correct a entry I saw in COBOL CFORUM, dated 96/09/25, time 22:39:29 which states : "... There are only a few ways to get dates using Cobol. (I am only addressing Cobol source here, not assembler subroutines). Under the obsolete compilers, OS/VS Cobol and VS Cobol II, all these methods return 2-digit year dates with no century indicator. Tom Ross - IBM COBOL Family Developmnet - TMROSS @ STLVM20". 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 (Cobol could do this translation but I don't think it does). Thanks. ----- YEAR2000 CFORUM appended at 15:45:18 on 97/02/28 GMT (by GAD at KGNVMC) - Subject: VS COBOL II ACCEPT Ref: Append at 15:23:30 on 97/02/28 GMT (by TOSTA at RIOSYS1) The TIME macro (SVC 11) absolutely positively returns a century indicator on year 2000 enabled versions of MVS. Cobol just ignores it. Greg Dyck MVS BCP Kernel and CURE support ----- YEAR2000 CFORUM appended at 17:35:30 on 97/02/28 GMT (by HGS at KGNVMC) - Subject: YEAR 2000 Compliant Products Ref: Append at 10:34:14 on 97/02/28 GMT (by 86454400 at EHONE) Here is what I found in the "Year 2000 and Two Digit Dates" guide (gc28-1251-05) for the minumim supported release levels: 5695-010 V2R3 is year 2000 ready. 5655-039 V3 will be ready by year end 97. 5785-EEG not found. 5740-xy5 V1R1 is year 2000 ready now. Howard Saxtan, MVS support ----- YEAR2000 CFORUM appended at 20:33:15 on 97/02/28 GMT (by LESENDEL at LASVM1) SUBJECT: RE: YEAR2000 COMPLIANT PRODUCTS The information you need can be found at "The Year 2000 and 2-Digit Dates: A Guide for Planning and Implementation", that can be downloaded from: HTTP://WWW.SOFTWARE.IBM.COM/YEAR2000/RESOURCE.HTML This guide states the following: 5695-010 CICSVR V2.3 is Year 2000 Ready 5655-039 MERVA/ESA MVS/CICS V.3 will be by year-end 1997 5740-XY5 Programmed Cryptographic Facility(PCF) V1 R1 is Year 2000 Ready There is no information about 5785-EEG Expedite/CICS and we are looking for it from other sources. Please, let us know if you find something else that may help us. YEAR 2000 TECHNICAL SUPPORT CENTER LATIN AMERICA T/L: 8-840-7347 // Y2KTSCLA AT ARG