----- 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 <year2000@hookup.net>
From: "Y2K Maillist (Via: Amy)" <y2k@tor.hookup.net>
Subject: IGZEDT4: YYYYMMDD in OS/VS COBOL and COBOL II
Date: Wed, 30 Oct 1996 08:44:01 -0500 (EST)
From: Fred Schuff <fschuff@system-support.com>
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)
<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.
In the manual, The Year 2000 & 2-Digit Dates: A Guide for Planning
and Implementation (GC28-1251-04), page A-12, the product DOS/VS RPG II
Version 1.3 (5746-RG1) is listed as being Year 2000 ready by Year End
1996.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 22:51:19 on 96/11/20 GMT (by Y2KTSC at STLVM6)
Subject: MVS Y2K Testing
Ref: Append at 13:36:21 on 96/11/20 GMT (by GBCADH00 at ELINK)
More documentation on this issue is high on our wish list as well.
Mean while here is a tidbit of information I found about LPAR's:
Any LPAR-able machine can be used for year 2000 testing. Each LPAR has
a logical TOD clock which is initially set to the physical TOD clock
value at LPAR activation.
To override this value, the operator must be prompted to set the
logical TOD clock at IPL time. The operator is prompted due to
the OPERATOR PROMPT parm in the SYS1.PARMLIB(CLOCKxx) member.
Ensure that the operator understands the appropriate response
to the resulting IEA888A message (GMT parm) during the IPL. For
example, 'R nn,DATE=2001.001,TIME=12.34.00,GMT'.
The most important thing to remember is to totally isolate your
DASD. This is to ensure that you don't affect production data
with your year 2000 testing.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 10:28:08 on 96/11/21 GMT (by 62418658 at EHONE)
Subject: RPG in Planning & Implementation Guide
Ref: Append at 16:42:09 on 96/11/20 GMT (by Y2KTSC2 at STLVM6)
Yes, it is mentioned on page A-13, but this is for the VSE platform and
does not imply that it will also be upgraded to the VM (CMS/DOS)
platform. The "Special Issue - VSE and Year 2000" does mention CMS/DOS
too, but I'm actually in discussion with Helmut Hanselmann (RPGII
Change Team) as whether this will be CMS/DOS on VM/ESA 2.2.0...
Guy De Ceulaer - VM Support - Belgium
----- YEAR2000 CFORUM appended at 13:54:56 on 96/11/21 GMT (by Y2KTSC1 at STLVM6)
Subject: RPG in Planning & Implementation Guide
Ref: Append at 10:28:08 on 96/11/21 GMT (by 62418658 at EHONE)
Please keep us on this forum informed of the outcome of your discussion.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 14:18:29 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Subject: General question on compilers and YR2000
Ref: Append at 13:34:55 on 96/11/20 GMT (by Y2KTSC at STLVM6)
Dear "Year 2000 Technical Support Centre",
Your scenarios are correct quite correct. My concern however related to
a year2000 ready program. It may require use of non-year2000 ready
compiler supplied run time modules.
It is these modules for which I have the concern. If the application does
not use any date-time functionallity, or its date-time functionallity is
provided by the application code (date obtained from user input for
example) will the RUN TIME modules still function after 31/12/1999?
In this case the run-time modules would cause the application to fail. If
this is unclear plaese call me as I would like confirmation that code
compiled by the OS/VS Cobol compiler or the Cobol II compiler which has
NO DATE HANDLING will still function unchanged 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 14:24:20 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Subject: General question on compilers and YR2000
Ref: Append at 13:46:57 on 96/11/20 GMT (by Y2KTSC at STLVM6)
I say negligable benefit because at this point the benefit I am after is
to have my code continue to run. I understand that these products provide
new function and therefore (arguably) benefits. However I am not after
new function.
If you were to upgrade you would not want to take advantage of this new
function as well as modify code for Y2K and modify Code for EMU. You
just want it to work for Y2k. So I restate negligable benefit.
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:27:04 on 96/11/21 GMT (by Y2KTSC1 at STLVM6)
Subject: General question on compilers and YR2000
Ref: Append at 14:18:29 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
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
----- YEAR2000 CFORUM appended at 14:42:15 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Subject: General question on compilers and YR2000
Ref: Append at 16:37:02 on 96/11/20 GMT (by THOMEN at SJFEVMX)
Mark,
I understand the state of play with regards to unsupported products, and
I whole hartedly agree that I do not want to run one. However at this
point in time a business which has say 100,000 programs written in OS/VS
Cobol which has no date dependant code would not want to migrate.
Similarly the business which has 100,000 modules which do contain date
dependant code wants to fix the date dependant code WITHOUT additional
impact by other changes.
I favour installing the new compiler, changing the code for the compiler,
testing and implementing - before any application Y2K changes are made.
My logic is simple - the new compiler may provide functions which help or
negate application date processing logic.
However I must state that in many cases that this IS NOT AN OPTION. There
is no time or resource to support both sets of changes. Needless to say
capital to cover the cost of the new compiler.
I do not personally agree that this is an acceptable situation, but to
modify 100,000 programs to cater for Y2K, and to modify those same
programs for compiler changes (whether before, during or after the Y2K
application changes) significantly increases the risk of project failure:
1) You have increased the scope of your changes
2) The changes may be intertwined - a chunk of applications date code may
have to be modified for dat and compiler changes. This complicates the
problem resolution process
3) You have increased the effort required to change the code - effort for
application Y2K code changes and effort for compiler changes
4) You have increased the cost of the project in terms of products -
a new licence will be required for the new compiler and this *WILL*
cost more than the old licence.
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:46:46 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Subject: MVS Y2K Testing
Ref: Append at 22:51:19 on 96/11/20 GMT (by Y2KTSC at STLVM6)
I hope that the Y2K Guide for 2 didgits dates will be updated with this
as at present it does not include the GMT on the reply (and this is
crucial) - I have submitted an RCF to have this changed but have not as
yet had a response.
I would clarify isolate. It is unacceptable to have the DASD software
isolated (say varied offline). They must be hardware isolated as MVS (I
do not know about VM) will access all devices during the IPL prior to
any varies being processed.
What else must be isolated ? Network - etc.
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:01:17 on 96/11/21 GMT (by ALICEF at SPOVMSIB)
Hello There, Does anyone know about COPICS BASE PRODUCT 1.4 and
other COPICS modules like SOR MRP, etc? Customer environment is
VSE/ESA. Are there any changes planned for this product regarding
YEAR2000? Please advise.
----- YEAR2000 CFORUM appended at 16:27:27 on 96/11/21 GMT (by IYORK at KGNVMC)
Subject: COPICS
Ref: Append at 16:01:17 on 96/11/21 GMT (by ALICEF at SPOVMSIB)
What's the product number for that COPICS?
Iris
----- YEAR2000 CFORUM appended at 16:46:09 on 96/11/21 GMT (by ALICEF at SPOVMSIB)
Hi, COPICS BASE PRODUCT 1.1.4 568801901. TKS.
----- YEAR2000 CFORUM appended at 17:37:24 on 96/11/21 GMT (by GBCADH00 at ELINK)
Subject: General question on compilers and YR2000
Ref: Append at 14:24:20 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
I agree - for an old legacy application which is being compiled
just to use a supported compiler, new statements are irrelevant.
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:40:20 on 96/11/21 GMT (by GBCADH00 at ELINK)
Subject: MVS Y2K Testing
Ref: Append at 14:46:46 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Can NJE facilities be used to move code updates from a 1996 system
to a 2000 system (and back again). Doing it all via uncatalogued
tape will get OPS going wild.
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:41:56 on 96/11/21 GMT (by GBCADH00 at ELINK)
Subject: General question on compilers and YR2000
Ref: Append at 14:42:15 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
We are a PL/I site and have rejected migration to the latest compiler
because of the object module incompatabilities with new and very old code.
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 21:17:31 on 96/11/21 GMT (by Y2KTSC4 at STLVM6)
Subject: General question on compilers and YR2000
Ref: Append at 17:41:56 on 96/11/21 GMT (by GBCADH00 at ELINK)
While many organizations will struggle with how to approach the task
of upgrading their applications to meet the challenges offered with
the YEAR 2000, it remains true that customers should consider making
their PLATFORM and INFRASTRUCTURE (hardware, software, firmware)
YEAR 2000 READY. This would include their compilers.
At that point, appropriate DATE services will be available to allow
the customer to move forward with solving the YEAR 2000 date issues
within their applications and business systems.
In any case, only those fully SUPPORTED and YEAR 2000 READY compilers
should be recommended by IBM. RISK and RESOURCE problems need to be
managed and acted on by the customer based upon this factual and
accurate information.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 08:39:45 on 96/11/22 GMT (by 62410352 at EHONE)
Subject: MVS Y2K Testing
Ref: Append at 22:51:19 on 96/11/20 GMT (by Y2KTSC at STLVM6)
Also with VM you can have an MVS (or VSE or VM) guest at a different
date than the host system. The guest needs OPTION TODENABLE in its
directory definition, to allow it to define its own, private, date/time.
The requirements to make the guest prompt the operator for a date are
the same as when running under LPAR.
Kris Buelens, IBM Belgium, BUELENSC at IECVM
----- YEAR2000 CFORUM appended at 09:10:07 on 96/11/22 GMT (by 62418658 at EHONE)
Subject: MVS Y2K Testing
Ref: Append at 14:46:46 on 96/11/21 GMT (by GBCBHG00 at ELINK2)
Re: Isolation.
Consider VM as the hypervisor for your test system(s). Not only can you
change the date as Kris explained, but you can define virtual machines
(virtual environments) having access to only those devices you want.
You can add devices to the guest in flight, which can then decide to
vary on at will. VM provides a lot more flexibility and control than
PR/SM (LPAR) for that matter.
Review my append of 96/10/16 10:42:05 for a more complete & detailed list
of advantages.
Guy De Ceulaer - VM Support - Belgium
----- YEAR2000 CFORUM appended at 12:10:07 on 96/11/22 GMT (by GBCBHG00 at ELINK)
Subject: General question on compilers and YR2000
Ref: Append at 21:17:31 on 96/11/21 GMT (by Y2KTSC4 at STLVM6)
I agree that the onus should be on the customer to handle the risk
and resource problems, however the problem is that the vendor (in this
case IBM, but my experience says all vendors) forces additional resource
requirements and risk by the implied statement of year 2000 support.
For example Cobol for MVS and VM is the year 2000 ready compiler, however
Cobol II is (I am fairly sure) still supported and I have seen no
announcement detailing its withdrawal. As a result it *IS* still a
supported compiler. It may not be Y2K compliant - however it is still
supported. Advising the customer that they *MUST* upgrade means that the
vendor is forcing addtional risk and resource on the customer.
What is needed (and we have it in these appends but I do not see an
official announcement/statment) is a clear statment that load modules
produced by OS/VS Cobol or Cobol II which contain no date processing
will continue to run after 31/12/1999. With this statement the customer
can make a value decission on when to upgrade to the new compiler rather
than be forced to by 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 15:35:49 on 96/11/22 GMT (by 86633147 at EHONE)
Subject: Year 2000 'problems'
All,
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.
'Idle gossip' and 'he said, she said' will waste valuable time (and
the clock is still ticking), so please do not bandy ideas across a
global network, when the people that can help are ready and waiting.
eg. Askkthe quetions and get given the answers.
----- YEAR2000 CFORUM appended at 16:41:43 on 96/11/22 GMT (by IYORK at KGNVMC)
Subject: 3745 fix
Ref: Append at 04:11:07 on 96/10/28 GMT (by WELHAMS at HKGVM8)
3745 status:
machine type code level
170DFR2 MCF34 C38006A
17A DRV6 MCL12 D40002.012
X1A FRV6 MCL13 D39894.013 (X=any number)
X10 FFR2 MCF97 C37967C
Those code levels are available now.
Iris
----- YEAR2000 CFORUM appended at 17:39:39 on 96/11/22 GMT (by DTERECK at TORVM3)
Hi everyone...
This is my first attempt at appending to the forum, so I apologize for
any "rough spots", in advance...
At the IBM website, www.software.ibm.com/year2000/faq1.html, under
Programming Languages, the 2nd question says:
Why must I migrate from the OS/VS COBOL run-time library to the
Language Environment (LE) for MVS & VM run-time library?
One of the reasons in the response to this says:
To solve the Year 2000 problem in Cobol applications - in order to use
IBM-supplied date/time services that are Year 2000 ready.
I have a problem with this. This statement implies (maybe more than
implies) that an OS/VS Cobol program will be able to call the new
Year2000-ready date routine supplied by LE. It is my understanding
that this SHOULD NOT BE DONE, as it is a completely unsupported
capability - that is, IBM has stated that there is no guarantee of any
kind that an OS/VS Cobol program making a call to an LE routine, will
work.
If that's true, then I don't believe we want the web page to say what it
is saying, without a bunch of disclaimers or clarifications.
Do you agree? Any comments?
And I don't know who is responsible for the information on the web
page, but I assume that the Year 2000 Technical Support Centre would
either be the ones, or they'd at least know who is.
Thnx...Dan Tereck
ISM Manitoba, Year 2000 Project
----- YEAR2000 CFORUM appended at 19:30:00 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
<Subject: MVS Y2K Testing ers
<Ref: Append at 14:46:46 on 96/11/21 GMT (by GBCBHG00 at ELINK2) be
<Can NJE facilities be used to move code updates from a 1996 system
<to a 2000 system (and back again). Doing it all via uncatalogued a a
<tape will get OPS going wild.
<
<This append was created on the External IBMLink system by
<Nick Hands-Clarke (GBFPLNHC at IBMMAIL.COM)
<IFPLO (+44-1306 740123 ext 3121)
Assumming by "code updates" you are talking about load modules, object
code, source code, data files, etc. you can use NJE to transmit the data.
This is no different than transmitting data between two 1996 systems.
If you're talking about anything else, we'll need to know more detail
before we can give you an answer. i.e. Why do you think you need to
use uncataloged tapes?
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 19:38:02 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
<Question on, COPICS BASE PRODUCT 1.1.4 568801901, being Year 2000 Ready
Service on COPICS BASE PRODUCT 1.1.4 568801901 was withdrawn on
12/30/1994. There are no plans to determine it's ability to handle
the change of century.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 20:05:23 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
<Subject: MVS Y2K Testing
<Ref: Append at 22:51:19 on 96/11/20 GMT (by Y2KTSC at STLVM6)
<
<I hope that the Y2K Guide for 2 didgits dates will be updated with this
<as at present it does not include the GMT on the reply (and this is
<crucial) - I have submitted an RCF to have this changed but have not as
<yet had a response.
<
<I would clarify isolate. It is unacceptable to have the DASD software
<isolated (say varied offline). They must be hardware isolated as MVS (I
<do not know about VM) will access all devices during the IPL prior to
<any varies being processed.
<
<What else must be isolated ? Network - etc.
First, to whom did you send the request to change the manual? We are
concerned that you did not receive a reply.
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.
If you have any specific suggestions/solutions, we would be happy to
review them.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 20:24:31 on 96/11/22 GMT (by IYORK at KGNVMC)
Subject: COPICS
Ref: Append at 19:38:02 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
COPICS was transferred to CGI. I have someone trying to find out
what their plans are. Whatever/whenever I find out, I'll post.
Iris
----- YEAR2000 CFORUM appended at 21:31:08 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
<I have a problem with this. This statement implies (maybe more than
<implies) that an OS/VS Cobol program will be able to call the new
<Year2000-ready date routine supplied by LE. It is my understanding
<that this SHOULD NOT BE DONE, as it is a completely unsupported
<capability - that is, IBM has stated that there is no guarantee of any
<kind that an OS/VS Cobol program making a call to an LE routine, will
<work.
<
<If that's true, then I don't believe we want the web page to say what it
<is saying, without a bunch of disclaimers or clarifications.
<
<Do you agree? Any comments?
<
<And I don't know who is responsible for the information on the web
<page, but I assume that the Year 2000 Technical Support Centre would
<either be the ones, or they'd at least know who is.
The statement does not imply that OS/VS COBOL can call LE services.
What it says is that a program compiled with the OS/VS COBOL compiler,
linked with LE and run with LE, will continue to execute.
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!
We are responsible for the Webpage and I will pass your comments
along.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 12:57:20 on 96/11/25 GMT (by THOMEN at SJFEVMX)
..... YEAR2000 CFORUM modified at 13:15:55 on 96/11/25 GMT (by THOMEN at SJFEVMX)
Subject: MVS Y2K Testing
Ref: Append at 20:05:23 on 96/11/22 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)
<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
<
<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.
There are no inconsistencies in the above appends, but here is a
recap:
The OS/VS COBOL product consists of a compiler and run-time library.
It is no longer supported by IBM. Object code produced by the
OS/VS COBOL product is fully supported when linked and executed using
the Language Environment for MVS & VM (LE for MVS & VM).
This means that a module compiled with OS/VS COBOL will continue to
run under LE for MVS & VM; however, continuing to compile COBOL source
using the OS/VS COBOL compiler is NOT RECOMMENDED.
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
----- YEAR2000 CFORUM appended at 17:48:31 on 96/11/25 GMT (by BOBKING at GDLVM7)
Subject: DFSORT and special dates
My customer is planning to use the Year 2000 features of DFSORT but has
some questions about how it might handle special dates. These are date
data that aren't really dates but are used as indicators. Examples are
low values, high values, and spaces in year or entire date field, and
99999, 99/99/99, 00000, and 00/00/00 in date fields.
1) When using Y2C, will low values and spaces still collate before all
numeric values and will high values still collate after all numeric
values and, effectively, not be windowed?
2) Are there any (easy) ways to achieve the effect of windowing
- a yyddd date field with 99999 as 9999999 instead of 1999999,
- a yyddd date field with 00000 as 0000000 instead of 2000000,
- a yy/mm/dd date field with 99/99/99 as 9999/99/99
instead of 1999/99/99, and
- a yy/mm/dd date field with 00/00/00 as 0000/00/00
instead of 2000/00/00?
The above is the logic the customer will be using in his windowing code
and he needs to make sure he can make the sorts behave the same.
Also, some the customer's database unloads have dates that are in keys in
9s complement form (that is, 961125 appears as 038874). Are there any
(easy) ways to window these date fields with DFSORT?
Thanks for any help or pointers.
Bob King IBM/ISSC Endicott BobKing at GDLVM7 bobking@vnet.ibm.com
----- YEAR2000 CFORUM appended at 19:06:18 on 96/11/25 GMT (by YAEGER at SJFEVMX)
Subject: DFSORT and special dates
Ref: Append at 17:48:31 on 96/11/25 GMT (by BOBKING at GDLVM7)
I'm afraid DFSORT doesn't have any magic bullets for these cases, but
I can offer some thoughts.
Y2C treats the two-digits as hex xyxy where x is ignored and y is a
year digit (0-9). So spaces (hex 4040) and 00 (hex F0F0) will be
treated as yy=00. The 00 will be treated as 1900 or 2000 according to
the century window. Likewise, 99 will be treated as 1999 or 2099
according to the century window.
If your low value is blanks or 00 and your high value is 99, there's
no way DFSORT can tell the difference between a low value and 00 or
a high value and 99 just by looking at the two-digit year. This is one
of the problems with using two-digit years.
If you're willing to transform the yyddd date fields (step 1) and then
collate them (step 2), there's some things you can do, but they might
be a little "messy" because you have to transform fields of the
form 00000 and 99999 without using the Y2C format and other dates
using the Y2C format.
For example, you could use one OUTFIL statement to INCLUDE only the
records with C'99999', C'00000' and C' ' and convert them with
OUTREC to C'9999999', C'0000000' and C'0000000', and use another
OUTFIL statement (in the same step) with SAVE to include the rest of
the records and convert them with OUTREC using Y2C to C'yyyyddd'.
Then you could collate the concatenated data sets.
What I said applies to yy/mm/dd dates as well.
Of course, this could end up involving multiple steps each time so it
might be better to do this once to create permanent 4-digit year dates
and avoid windowing.
This also could be problematical with multiple dates in the same record
some of which have 99999 or 00000 and some of which don't.
As for the 9s complement fields, DFSORT's lookup and change can be used
to interpret 03 as 1996, etc, but again this involves transorming and
then collating. Also, the window has to be set up statically via the
lookup and change conditions - you can't use the fixed or sliding
window option directly.
If any of this sounds like something you might use, I can help you figure
out the control statements you need offline.
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
----- 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
<
<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' ?"
It is true that VS COBOL II, V1R4M0, is a currently supported compiler.
However, it has been stated in numerous places that support for this
compiler will soon be discontinued, probably BEFORE the end of the
century. Also, VS COBOL II, V1R4M0 is not a Year 2000 Ready product.
Some enhancements have been made to help companies in their efforts
to process the change of century, but overall, companies should not
plan on migrating to, or staying on, VS COBOL II.
COBOL for MVS & VM is the only Year 2000 Ready COBOL compiler product.
It is the tactical and strategic COBOL compiler companies should be
using.
As this is a forum dealing with Year 2000 issues, we recommend and
promote only Year 2000 Ready products.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 07:29:44 on 96/11/26 GMT (by THOMEN at SJFEVMX)
Subject: General question on compilers and YR2000
Ref: Append at 20:59:54 on 96/11/25 GMT (by IL68779 at ELINK)
There is a difference between "supported for service" and "supported for
enhancements." If a product is announced as "functionally stabilized"
that essentially means that no new product requirements will be accepted
against it and it will not be further enhanced - such as VSAM Catalogs.
That doesn't mean that problems won't be fixed if they're reported.
Mark Thomen
DFSMS Development (Catalog/IDCAMS/VSAM)
SJFEVMX/THOMEN or USIB54WA at IBMMAIL
----- YEAR2000 CFORUM appended at 09:29:41 on 96/11/26 GMT (by 9WARLTK at CROVM4)
Subject: General question on compilers and YR2000
Ref: Append at 17:04:25 on 96/11/25 GMT (by Y2KTSC2 at STLVM6)
Thank you for the recap with which I agree. Would you please add to
your append at 14:27:04 on 96/11/21 GMT (by Y2KTSC1 at STLVM6):
"and will be supported if using Language Environment"
In your append at 21:31:08 on 96/11/22 GMT (by Y2KTSC2 at STLVM6) would
you please change:
"Today, IBM makes no guarantee that ANY program compiled, linked and
running using OS/VS COBOL will execute."
to:
"Today, IBM makes no guarantee that ANY program compiled, linked and
running using OS/VS COBOL run-time will execute."
Regards, Keith Warltier, Y2K & Redevelopment Practice, IBM UK
9WARLTK@CROVM4 or GBIBMTJ2@IBMMAIL or KEITH_WARLTIER@UK.IBM.COM
----- YEAR2000 CFORUM appended at 09:46:50 on 96/11/26 GMT (by 62418658 at EHONE)
Subject: Save useful discussions
The activity on this forum grows every day. Wouldn't it be wise to
save the useful appends (like the excellent one on DFSORT by Frank)
in a HOWTO file before they get pruned. As the Y2000 Support Center
people would have to do this, they would have full control over the
'final statements' about discussions.
Guy De Ceulaer - VM Support - Belgium
----- YEAR2000 CFORUM appended at 10:23:00 on 96/11/26 GMT (by 36602370 at EHONE)
Subject: Y2K Testing
Ref: Append at 20:05:23 on 96/11/22 GMT (by Y2KTSC2 at STLVM6)
There are other reasons why you should isolate data other than the
the VSAM/catalog issues. Security Databases, Datasets, Backup and
archive tools, OEM software with expiry dates in it, TMS systems
........ and so on.
If you run HSM, or DSS that processes based on dates. Datasets can
(and have been) archived, deleted, expired because of the huge jump in
'todays date'.
RACF (or any other security package), even if you have y2000 complient
software your userids may become revoked thourgh 'inactivity' or
invalid through other reasons (ie containing future dates as your
last logon).
TMS systems, (RMM or CA-1 for example) normally process and manage tapes
based on creation dates and retention periods.
Clone your system and run in isolation in an LPAR.
As the Y2000 centre says, dont assume that things will be fine if
you think you understand the externals.
----- YEAR2000 CFORUM appended at 12:24:55 on 96/11/26 GMT (by THOMEN at SJFEVMX)
Subject: Y2K Testing
Ref: Append at 10:23:00 on 96/11/26 GMT (by 36602370 at EHONE)
>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:
<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!
is being changed to read:
Today, IBM makes no guarantees that ANY program compiled, linked and
running using OS/VS COBOL run-time will execute. IBM also makes no
guarantees that the OS/VS COBOL compiler will work. Using the
OS/VS COBOL compiler is at your own risk!
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 04:49:02 on 96/11/27 GMT (by AS103033 at ELINK)
Subject: Year 2000 'problems'
Ref: Append at 15:35:49 on 96/11/22 GMT (by 86633147 at EHONE)
> 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)
<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 ......
<
<* 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 ?
You've obviously spent a lot of time putting these questions together,
and from the title of the append, it looks like you're concerned about
running these products under LE for MVS & VM.
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.
LE is the required runtime product for COBOL for MVS & VM.
Programs compiled with VS COBOL II Release 3.0 and above should
compile cleanly with COBOL for MVS & VM. However, the migration
guide points out many things that can impact processing. Examples
are the settings for AMODE and RMODE, RES/NORES, mixture of
VS COBOL II with COBOL for MVS & VM, etc.
LE is the required runtime product for PL/I for MVS & VM.
LE is not required during compilation of PL/I for MVS & VM, but is
required for Linkedit, which is normally combined with the compile.
Depending on the decisions you make for your company, you may decide
not to migrate from PL/I V2 to PL/I for MVS & VM. But, from a Year
2000 perspective, PL/I for MVS & VM is the only Year 2000 Ready PL/I
compiler.
Now, to recap, the products and earliest release which is Year 2000
Ready are listed below:
COBOL for MVS & VM V1R2
PL/I for MVS & VM V1R1
C/C++ for MVS/ESA V3R2
LE for MVS & VM V1R4
If you are migrating from an earlier release of a language compiler
to one of the above products, or are planning to use LE as the runtime
environment, reading the migration guides are absolutely recommended.
Year 2000 Technical Support Center
----- YEAR2000 CFORUM appended at 00:34:15 on 96/11/28 GMT (by AS103033 at ELINK)
Subject: LE/370 questions ...
Ref: Append at 19:29:31 on 96/11/27 GMT (by Y2KTSC2 at STLVM6)
> ... 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