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