----- YEAR2000 CFORUM appended at 14:00:22 on 97/01/02 GMT (by BRUCERAY at ICCVMAS7)
Subject: Business implications with Year 2000
 
I am curious as to where these types of discussions might be going on?
That is, with the Year 2000, what affect will it have on existing
everyday business functions?
For instance, we all know that the Year2000 is a huge systems nightmare.
But, for the banking industry for instance, what is the impact of all
this on a global branch office and their daily operations?  Would it
affect the way they do things, their daily routine, the DDA function,
etc?
 
Bruce
 
----- YEAR2000 CFORUM appended at 15:15:45 on 97/01/02 GMT (by STEVE at UKFSC)
Subject: VM Programming interfaces
 
Is there a document which draws together all of the possible changes
that an application programmer would need to consider when checking
their code for year2000 compliancy when using interfaces in CP and
CMS (whether intended as programming interfaces or not?)?
 
The obvious things are diagnose codes which return date information, CP
commands executed via DIAG 08.
Then there are the CMS macro interfaces, such as the bit in the FST
indicating year2000+.
Probable things would include CMS commands which are being trapped by
PIPEs
 
I can find most of this information spread throughout other documents,
but I've been asked for a specific VM application programmers reference
document.
 
Steve Swift
 
----- YEAR2000 CFORUM appended at 17:09:03 on 97/01/02 GMT (by 9WARLTK at CROVM4)
Subject: Year 2000 Guide, Version 6, December 1996, Now Available
 
The Year 2000 and 2-Digit Dates Guide, GC28-1251-05 can be browsed
or downloaded from the internet using:
    http://www.software.ibm.com/year2000/index.html
 
or obtained by IBMers from MKTTOOLS using:
    GET GC281251 TERS3820
 
Regards,   Keith Warltier,  Y2K & Redevelopment Practice,  IBM UK
9WARLTK@CROVM4  or GBIBMTJ2@IBMMAIL  or  KEITH_WARLTIER@UK.IBM.COM
 
----- YEAR2000 CFORUM appended at 01:37:53 on 97/01/03 GMT (by AS106968 at ELINK)
Subject: PL/1 programs running beyond Year 2000
Ref:     Append at 23:58:25 on 96/12/19 GMT (by Y2KTSC2 at STLVM6)
 
Does this problem also exist in the DOS/PLI 1.6 library ? (VSE)
 
Regards, Richard
 
This append was created on the External IBMLink system by
Richard Barrow,  J B Were & Son,  Systems Programmer,
Ph :  +61 3 9679 1284     Fax :  +61 3 9679 1067
 
----- YEAR2000 CFORUM appended at 06:22:38 on 97/01/03 GMT (by ANGUSK at SYDVMXA2)
Subject: PL/1 programs running beyond Year 2000
Ref:     Append at 01:37:53 on 97/01/03 GMT (by AS106968 at ELINK)
 
DOS PL/I, 5736-PL1 (5736PL161), is due to have service withdrawn on
June 30 1997.
 
This follows a 'per fee' extension of service from the original EOS
date of June 30 1996. The extension was provided to assist users
in making their conversion to PL/I for VSE product, 5668-069.
 
DOS PL/I is not Year 2000 ready, nor compliant. It will not be
upgraded with that support.
 
PL/I for VSE is Year 2000 ready.
 
A test showed that a DOS PL/I program compiled and run on a machine
IPLed with date 30 March 2000 returned in response to -
 
  DATEY2K:PROC OPTIONS(MAIN);
    DCL DATE      BUILTIN;
    PUT SKIP LIST('Date: '||DATE);
  END DATEY2K;
 
a value of -
 
  Date: 000330
 
This shows the date is returned correctly, but there is no century
indicator.
 
Regards
 
Year 2000 Technical Support Center (Asia Pacific)
 
----- YEAR2000 CFORUM appended at 16:28:46 on 97/01/06 GMT (by JFRANCIS at GDLVM7)
..... YEAR2000 CFORUM modified at 18:17:59 on 97/01/21 GMT (by JFRANCIS at GDLVM7)
Subject: VM Programming interfaces
Ref:     Append at 15:15:45 on 97/01/02 GMT (by STEVE at UKFSC)
 
| Corrected URL
 
Steve,
 
Documentation on the changes to VM programming interfaces and commands
| can be found at http://www.vm.ibm.com/year2000/y2kvmupd.html
 
The same information can be found in documents in YR2000VM PACKAGE on
MKTTOOLS.
 
Although these documents are somewhat out of date, they still provide a
good overview of the changes we've made in VM.
We are in the process of updating this documentation to include more
current VM Year 2000 information.
 
John Franciscovich
VM/ESA Development
 
----- YEAR2000 CFORUM appended at 00:35:39 on 97/01/09 GMT (by YAEGER at SJFEVMX)
Subject:  DFSORT/VSE Year 2000 features are available now
 
DFSORT/VSE V3R2 PTF UN99635 is available now!  It delivers DFSORT/VSE
Year 2000 features you can use to sort, merge and transform a wide
variety of dates with two-digit years according to a specified sliding
or fixed century window.
 
I've written a paper called SORTY2DV which contains complete details
of DFSORT/VSE's new Year 2000 features, and examples of the DFSORT/VSE
control statements needed to order and transform 39 different
character, zoned decimal and packed decimal date fields.
 
You can read an online version of the SORTY2DV paper on the
DFSORT/VSE home page at URL:
 
  http://www.storage.ibm.com/software/sort/srtvhome.htm
 
or download sorty2dv.zip which contains postscipt and text versions
of the paper, via anonymous FTP from:
 
  lscftp.pok.ibm.com/pub/vse/docs/
 
or ask your IBM representative to obtain the SORTY2DV package for
you from MKTTOOLS.
 
Frank L. Yaeger - DFSORT Team
 
----- YEAR2000 CFORUM appended at 02:09:27 on 97/01/10 GMT (by XXHKHAN at ISSCAUS)
Subject: 2-digit year part of key of IMS database (VSAM)
 
Is there any facility available to have 2-digit year as part of key
in IMS databases (VSAM). e.g. Year2000 ready DFSORT allows us to enter
the value of Y2PAST to have 2-digit year (sliding window).
 
Himyaz, ISSC Australia
 
----- YEAR2000 CFORUM appended at 11:48:54 on 97/01/10 GMT (by 36601943 at EHONE)
Subject: 2-digit year part of key of IMS database (VSAM)
Ref:     Append at 02:09:27 on 97/01/10 GMT (by XXHKHAN at ISSCAUS)
 
IMS does not have this support.
 
Dougie Lawson, IBM Basingstoke, UK.        (aka 8LAWSOD at NHBVM2)
 
----- YEAR2000 CFORUM appended at 15:48:23 on 97/01/10 GMT (by 86679714 at EHONE)
Subject: 2-digit year part of key of IMS database (VSAM)
Ref:     Append at 11:48:54 on 97/01/10 GMT (by 36601943 at EHONE)
 
Since IMS uses KSDSs for keyed access, the question is also one for
VSAM - IMS relies on VSAM to provide the records in key-sequential order.
 
Even if the support were available (that is year 01 occurs after year 99)
there would still be questions about data validity for the application
programs - will they have the same windowing capability?
 
Pete Sadler
 
----- YEAR2000 CFORUM appended at 02:06:51 on 97/01/13 GMT (by BCOKPOK at NYCVMIC1)
Subject: COBOL II ACCEPT
 
The Securities Industries YR2K Association asks:
     When COBOL II issues an ACCEPT to a YR2K Compliant Operating System
and COBOL II is not YR2K compliant, will COBOL II get a 2- or 4-
digit year in response?
 
While we are at COBOL II, the same audience asks:
 Outside of the date issue, is there any reason why a COBOL II
Application will not work in year 2000? I said no. But please verify that
for me. Thanks.
 
Bertram Okpokwasili
Cranford, NJ
NYCVMIC1(bcokpok)
 
----- YEAR2000 CFORUM appended at 05:53:10 on 97/01/13 GMT (by E15406 at TOKVMIC2)
Subject: Year 2000 support for several products
 
One of our customer is asking the following questions.
Are the specific releases of the following products Year2000-ready ?
If not, which versin or release supports it? Or, are there follow-on
products to support it?
 
TSO Data Utility              (5734-UT1) V1R1M4
TSO Dynamic STEPLIB           (5798-DZW) V1R1M0
TSO File transfer             (5799-BWJ) V1R1M1
XI(X.25 SNA Interconnection)V2(5685-035) V2R4M1
RTG                           (5668-815) V1R1M1
MSCM                          (5665-342) V1R1M0
IODBM                         (5788-JKD) V1R1M0
PL/I Checkout Compiler        (5734-PL2) V1R0M0
TSO ASM Prompter              (5734-CP2) V1R2M0
TSO COBOL Prompter            (5734-CP1) V1R1M4
FORTRAN LCP                   (5668-804) V1R1M0
ACRITH                        (5665-337) V1R3M0
DXT V2                        (5768-788) V2R5M0
 
What problem is expected if next product is useed after year 2000?
COBOL Interactive Debug       (5734-CB4) V1R1M0
 
----- YEAR2000 CFORUM appended at 21:15:43 on 97/01/13 GMT (by Y2KTSC1 at STLVM6)
Subject: Year 2000 support for several products
Ref:     Append at 05:53:10 on 97/01/13 GMT (by E15406 at TOKVMIC2)
 
Information is not available for all of these products.  Here is what
is known at this time:
 
TSO Data Utility              (5734-UT1) V1R1M4 - yes
TSO Dynamic STEPLIB           (5798-DZW) V1R1M0 - service withdrawn
TSO File transfer             (5799-BWJ) V1R1M1 - unknown
XI(X.25 SNA Interconnection)V2(5685-035) V2R4M1 - ok
RTG                           (5668-815) V1R1M1 - service withdrawn
MSCM                          (5665-342) V1R1M0 - service withdrawn
IODBM                         (5788-JKD) V1R1M0 - unknown
PL/I Checkout Compiler        (5734-PL2) V1R0M0 - being discontinued
TSO ASM Prompter              (5734-CP2) V1R2M0 - unknown
TSO COBOL Prompter            (5734-CP1) V1R1M4 - unknown
FORTRAN LCP                   (5668-804) V1R1M0 - unknown
ACRITH                        (5665-337) V1R3M0 - service withdrawn
DXT V2                        (5768-788) V2R5M0 - unknown
 
You can get more information about products by reading the Customer
Guidance Paper which can be downloaded from our web site at URL
 
  http://www.software.ibm.com/year2000
 
Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 02:59:03 on 97/01/14 GMT (by Y2KTSC3 at STLVM6)
Subject: COBOL II ACCEPT
Ref:     Append at 02:06:51 on 97/01/13 GMT (by BCOKPOK at NYCVMIC1)
 
>When VS COBOL II issues an ACCEPT to a Y2K Ready Operating System
>and VS COBOL II is not Y2K Ready, will VS COBOL II get a 2- or 4-
>digit year in response?
 
Neither, VS COBOL II gets the system date in packed decimal format
with a Century indicator.  The ANSI COBOL Standard requires that the
ACCEPT verb only return 2-digit year dates in external decimal format.
 
>Outside of the date issue, is there any reason why a VS COBOL II
>Application will not work in year 2000?
 
OS/VS COBOL and VS COBOL II programs and the Year 2000 problem
--------------------------------------------------------------
 
There are no known problems with COBOL programs running after the
Year 2000.  There are only 2 problems to be concerned with for COBOL
applications and the Year 2000:
 
  1) Date Related Logic
  2) Service support from IBM
 
You can get service support for OS/VS COBOL and VS COBOL II programs
indefinitely by using the Language Environment run-time library with
just a run-time migration.  This is described in the next section.
 
As a result, an application with NO DATE RELATED LOGIC could be run
in a supported environment beyond the turn of the century by a run time
migration only, with no source changes or recompiles necessary.
 
Repeat,  no source code changes or recompiles and your OS/VS COBOL and
VS COBOL II programs can be running with full IBM service support and
no Year 2000 problems if they are running under Language Environment
and have no date-related logic problems!
 
Of course, an application that DOES have date related logic must be
examined to see if it has a Year 2000 problem.  If it does, then the
programs will have to be changed, which means at the very least a
compile, link and test.  At this point you can combine source
upgrade (compiler migration) with Year 2000 conversion.  IBM does
not provide any way for OS/VS COBOL programs to obtain a 4-digit
year date, so you must compile with at least VS COBOL II in order
to use IBM provided services for obtaining a 4-digit year date.
 
Service support for programs compiled with OS/VS COBOL or VS COBOL II.
---------------------------------------------------------------------
 
IBM will continue to provide service support for the execution of
programs compiled with the OS/VS COBOL and VS COBOL II compilers as
long as these programs are using the Language Environment for MVS & VM
(5699-198) versions of the COBOL library routines. (This also holds
true for programs compiled with the DOS/VS COBOL and VS COBOL II
compilers running on VSE, except that the strategic run-time library
for VSE is Language Environment for VSE (5686-067).)
 
Every COBOL program requires library routines in order to execute.
They may be statically linked to the load modules or dynamically
accessed at execution time.  If the library routines that are
being used are supported by IBM service, then you can call IBM
when there is a problem and get the problem fixed.  For example,
the library routines for OS/VS COBOL programs exist in the OS/VS COBOL
run-time library, the VS COBOL II run-time library, and in the Language
Environment run-time library.  If your OS/VS COBOL programs are running
using the OS/VS COBOL library, then they are not supported by IBM
service.  If your OS/VS COBOL programs are running using the Language
Environment run-time library, then your programs are supported by
IBM service, and will be supported well into the 21st century.
 
If you are starting with load modules consisting of programs compiled
with the NORES option and link-edited with the OS/VS COBOL library
or the VS COBOL II library, then you will need to use REPLACE linkage
editor control statements to replace the old library routines with
the Language Environment versions.  If you start with object programs
(non-linked) then you just need to link edit with Language Environment
If the programs are compiled with RES, then you can just make the
Language Environment library routines available at execution time
in place of the OS/VS COBOL or VS COBOL II library routines by using
LNKLST, or STEPLIB on MVS, and GLOBAL statements on VM.
 
A recompile is NOT required to complete your migration.
-------------------------------------------------------
 
The ideal state is that programs should be compiled with a supported
compiler (recommended is COBOL for MVS and VM) running with a supported
run-time library (Language Environment for MVS & VM). However this
ideal state can be reached gradually in a fully supported manner:
 
1) Run-time migration followed OPTIONALLY at some future date by
2) Compiler migration
 
Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 17:49:39 on 97/01/14 GMT (by IYORK at KGNVMC)
Subject: Year 2000 support for several products
Ref:     Append at 21:15:43 on 97/01/13 GMT (by Y2KTSC1 at STLVM6)
 
DXT is not compliant.  Data Refresher is the replacement and it is.
TSO ASM Promper and COBOL prompter do not support a year 2000 ready
  COBOL so in effect it's not.   I believe I was told once that it
  only runs with OS/VS COBOL.
 
Iris
 
----- YEAR2000 CFORUM appended at 02:22:52 on 97/01/15 GMT (by ADELOACH at ATLVMIC1)
Subject: VisualAge Generator, CSP, and the Year 2000
 
Folks,
 
For those of you with VisualAge Generator or CSP and concerns
about the Year 2000 there is now a package, ADVGYR2K, on MKTTOOLS
to assist with addressing Year 2000 issues.
 
The ADVGYR2K PACKAGE contains:
 
  ADVGYR2K LIST3820 - a white paper, "VisualAge Generator, CSP, and
                      the Year 2000".
 
  ESFSCAN  CMDBIN   - an OS/2 REXX program that can be used to scan
                      ESF to look for date-related items.
 
For the moment this package is only available from MKTTOOLS so you
will have to bug your IBM rep for a copy.  I believe there is work
underway to put the paper (which includes a hardcopy listing of
the REXX program) on VisualAge Generator web site.
 
Allan DeLoach
IBM Certified I/T Specialist - AD/M, Area 7
VNET:     ADELOACH at ATLVMIC1
Internet: adeloach@atlvmic1.vnet.ibm.com
 
----- YEAR2000 CFORUM appended at 22:33:26 on 97/01/15 GMT (by RFWEILA at DALVMIC1)
Subject:  Looking for Sample Letters for Client to Use with 3rd Party
 
I know some sample letters exist for client to use to "survey" their
3rd Party Software vendors for questions like "...is your software
Year 2000 compliant ?  ...if not, when will it become compliant ?"
 
This is NOT what I am looking for.
 
What I am looking for is a sample letter, client can use to send to
3rd Party software vendors...informing them that they have hired a
consultant to help them determine if all their software (in house
developed and external) are Year 2000 Compliant, and needs that
vendors authorization to allow a 3rd party consultant to look at
and analyze the code for compliance.
 
If you have any samples or suggestions, please contact me via profs
at DALVMIC1(RFWEILA) or 8/642-6582.  Thanks.  Bob Weiland
 
----- YEAR2000 CFORUM appended at 14:17:28 on 97/01/16 GMT (by MCNEILL at YKTVMV)
..... YEAR2000 CFORUM modified at 19:26:18 on 97/01/16 GMT (by MCNEILL at YKTVMV)
Subject: Looking for Sample Letters for Client to Use with 3rd Party
Ref:     Append at 22:33:26 on 97/01/15 GMT (by RFWEILA at DALVMIC1)
 
| Deleted, unqualified opinion.
 
----- YEAR2000 CFORUM appended at 13:22:51 on 97/01/17 GMT (by GBCBHG00 at ELINK)
Subject: GC28-1251-05 Guide to 2 digit dates
 
Please could someone urgently review section 2.5.3.1 of this manual which
relates to setting the time to a future date. It conflicts with what I
been told by IBM MVS Support
 
The statement which requires review is:
 
  "On OS/390 or MVS : you can set the clock in an MVS image to a
  future date.  To set the clock, reply to the TOD clock prompt
  message IEA888A ¶GMT DATE=...,CLOCK=...Ù LOCAL DATE=...,CLOCK=...
  REPLY U, OR GMT/LOCAL TIME in the test LPAR image."
 
Basically this is correct, but it is missing one crucial peice of
information. When replying to the message you must include GMT. If GMT
is ommited then under certain circumstance (ie certain MVS instructions)
will return a DATE AND TIME different to the one set above.
 
This information was relayed to me by an IBMer as I had done the above
without the GMT and it did not set the date(s) properly.
 
Appended at 14:28:14 on 96/07/04 by GAD at KGNVMC.
Ref:     Append at 13:14:27 on 96/07/04 GMT (by GBCBHG00 at ELINK)
Subject: LPAR and TOD
 
There are **no** architected instructions that can access the physical
TOD clock value in an LPAR zone.  If the TOD value is truly modified by
entering "CLOCK=hh.mm.ss,DATE=yyyy.ddd,GMT" in response to the validation
prompt during IPL of MVS (and the GMT specification is critical to this)
then STCK and TRACE will start at the time you have set and increment
as expected.  If the GMT option is not specified then you only altered
the local TOD offset, not the TOD value.
 
Greg Dyck
MVS BCP Kernel and CURE support
 
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:54:52 on 97/01/17 GMT (by JACKF at KGNVMC)
Subject: LPAR and TOD
Ref:     Append at 13:22:51 on 97/01/17 GMT (by GBCBHG00 at ELINK)
 
Peter,
 
Thank you for pointing this out. I sent a note to MHVRCFS indicating that
GMT must be specified. I requested that the response go to both you and
me.
 
Jack Friedman; OS/390 Level 3 Service
 
----- YEAR2000 CFORUM appended at 17:42:27 on 97/01/17 GMT (by D83210 at LASVM1)
 From:     CN=Sergio Olivera/OU=Argentina/OU=Contr/O=IBM@IBMAR (SERGIOO @ LASNOTES)
 To:       Peter Gammage, SEMA Group Outsourcing.
 Date:     01-17-97 12:33:14 PM
 Subject:  GC28-1251-05 Guide to 2 digit dates
 
  Peter :
 
  I had review section 2.5.3.1 of GC28-1251-05 "Guide to 2 digit dates"
  and what are you said about the sintax of the command to set the clock
  in an MVS environmment is correct. But I think that the guide is just
  telling us what we must do in order to set the clock, not wich is the
  sintax of the command. The text "To set the clock, reply to the TOD
  clock prompt message IEA888A ›GMT DATE=...,CLOCK=...! LOCAL DATE=...,
  CLOCK=... REPLY U, OR GMT/LOCAL TIME in the test LPAR image." is
  referencing textually what the prompt said, not how to reply this
  prompt.
 
  If you look at the GC28-1442-01 MVS/ESA SP V5 System Commands, you can
  see how is the sintax of the command to set the clock.
 
  Following is a paragrah extracted of that manual were this point is
  discussed.
 
 +---------------------------------------------------------------------------------------+
 
 "1.1.6  Setting the Time and Date
 
    If the time-of-day (TOD) clock on the target processor is not set or if
    your installation specifies the OPERATOR PROMPT parameter in the CLOCKxx
    member of SYS1.PARMLIB that the system uses for initialization, the system
    prompts you during initialization to set the correct time and date with
    message IEA886A and/or message IEA888A.  Message IEA886A asks you to
    specify values for the time and date.  Message IEA888A displays the time
    and date and lets you accept or change these values.  In response to
    either message, set an accurate time and date according to your
    installation's requirements.
 
    For example, suppose the system issues:
 
          IEA888A GMT   DATE=1991.301,CLOCK=22.31.53
      *00 IEA888A LOCAL DATE=1991.301,CLOCK=17.31.53  REPLY U, OR GMT/LOCAL TIME
 
    The values in this message indicate that the local time is 5:31:53 P.M. on
    October 28, 1991 and that Greenwich mean time (GMT) is five hours later
    than local time in your time zone.  If the local time at your installation
    is really 8:00:00 A.M. on October 29, 1991, reply as follows:
 
      R 00,DATE=1991.302,CLOCK=13.00.00,GMT
 
    The system responds with:
 
          IEA888A GMT   DATE=1991.302,CLOCK=13.00.00
      *00 IEA888A LOCAL DATE=1991.301,CLOCK=08.00.00  REPLY U, OR GMT/LOCAL TIME
 
    Note that the system sets the local time but not the local date from the
    time and date you specify.  To set the local date, reply as follows:
 
      R 00,DATE=1991.302
 
    If the new GMT and local time values are still not accurate enough, you
    can reply with new GMT time values now (and as many times as you need) to
    bring the system's values closer to what your installation requires.  When
    you are satisfied with the system's values, reply as follows:
 
      R 00,U
 
    See "REPLY Command" in topic 4.27."
 
 +---------------------------------------------------------------------------------------+
 +---------------------------------------------------------------------------------------+
 
 "4.27.5  Setting the Time-of-Day Clock
 
    Once the system has been initialized, it can issue one of two messages,
    depending on whether or not the time-of-day clock is set.
 
    If the time-of-day (TOD) clock is not set, the system asks you to set it:
 
      * 00 IEA886A TOD CLOCK(S) MUST BE SET
 
    Use the following form of the REPLY command to set the time of day clock.
 
        R 00,'›DATE=yyyy.ddd!›,CLOCK=hh.mm.ss!›,GMT!'
 
    Where yyyy is the year (1924-2042) and the day ddd is the day (001-366),hh
    is the hour (00-23),mm is the minute (00-59), and ss is the second
    (00-59).
 
    Notes:
 
    1.  If you specify yy for the year (00-99), the system records the date as
        19yy.
    2.  The apostrophes in the above reply are optional.
 
    If you included GMT in your reply, the time and date are Greenwich mean
    time.  If you omitted GMT, the system assumes the values are the local
    time and date, converts them to Greenwich mean time values, and sets the
    clock(s) with the Greenwich mean time.
 
    When you have entered a valid reply to message IEA886A, the system issues
    message IEA903A, requesting a response.  There are 2 possible responses,
    depending on the environment MVS is running in.  The first requests you to
    reply U to message IEA903A and, at the exact time that matches the TOD
    clock setting, press the TOD clock security switch.  The second version
    does not request you to press the TOD clock security switch.  You reply U
    to message IEA903A and, at the exact time that matches the TOD clock
    setting, press the ENTER key for the reply text.  Once you have
    successfully set the TOD clock, or if the TOD clock is already set but you
    are allowed to alter it, the system displays the time and date and gives
    you the option of accepting or changing them:
 
      * id  IEA888A GMT DATE=yyyy.ddd,CLOCK=hh.mm.ss
            IEA888A LOCAL DATE=yyyy.ddd,CLOCK=hh.mm.ss REPLY U, OR GMT/LOCAL TIME
 
    If the values are acceptable, reply 'U'.  If you want to change the value
    of the TOD clock, enter a new date, time, or both as follows:
 
      R id,'›DATE=yyyy.ddd!›,CLOCK=hh.mm.ss!›,GMT!'
 
    Note:  The system automatically issues message IEA888A at IPL time if the
    OPERATOR PROMPT parameter is included in the active CLOCKxx member of
    SYS1.PARMLIB.  (See MVS/ESA SP V5 Initialization and Tuning Guide for
    details.)
 
    If you specified a different TOD clock setting, message IEA903A is issued
    as described above.  If you omitted GMT, the local date and/or time are
    assumed.  Once you have set the new time and/or date, the system re-issues
    message IEA888A with new values.  Reply to the message as previously
    described.
 
    Note:  The TOD clock should be set to a value based on zero being
    equivalent to 00 hours, 00 minutes, 00 seconds on January 1, 1900 GMT.
    During an IPL, the TOD clock might contain a value that, relative to this
    base, is not correct.  This can happen, for example, when C.E. servicing
    left the clock in the error state.  In such a case, to ensure that the
    local time and date are correct, specify GMT before setting the local time
    and date."
 
 +---------------------------------------------------------------------------------------+
 
  Regards.
 
  LA Technical Support Center / HOST, Argentina.
 
----- YEAR2000 CFORUM appended at 18:17:07 on 97/01/17 GMT (by GAD at KGNVMC) -
Subject: GC28-1251-05 Guide to 2 digit dates
Ref:     Append at 17:42:27 on 97/01/17 GMT (by D83210 at LASVM1)
I personally agree with Peter that the use of the GMT keyword should
be explicitly indicated.  My experience has been that most people do
*not* read the manual like you have just done.  I have seen too many
cases of the TOD clock *not* being properly set because of there
being a misunderstanding of the use of GMT at IPL time.  I believe
Peter has been bitten by this once already, which was the source of
my original append which Peter supplied.
 
Greg Dyck
MVS BCP Kernel and CURE support
 
----- YEAR2000 CFORUM appended at 21:29:10 on 97/01/17 GMT (by D83210 at LASVM1)
 From:     Sergio Olivera/Argentina/Contr/IBM@IBMAR (SERGIOO @ LASNOTES)
 To:       Greg Dick, MVS BCP Kernel and CURE support.
 Date:     01-17-97 17:58:23 PM
 Subject:  GC28-1251-05 Guide to 2 digit dates
 
  Greg :
 
  I agree with you and Peter over the importance of the GMT keyword, but,
  like any other keyword, its use must be explicity indicated in the same
  text who explain the syntax of the command which involved it.
  If you read carefully the "Guide to 2 digit dates" you will see that it
  doesn't indicate wich is the appropiate command to use in this
  situation. So, who want to change the tod of his installation must know
  the command syntax or must refer to the manual which explains it.
 
  Regards.
 
  LA Technical Support Center.
 
----- YEAR2000 CFORUM appended at 13:10:22 on 97/01/18 GMT (by IYORK at KGNVMC)
Subject: MVS PSP bucket
 
I know there have been some discrepencies between the planning guide
product lists that show a PTF available and the actual entries
in the PSP bucket.
 
I just wanted to let everyone know that I am working on it and hope
to have it resolved soon.
 
Sorry for any confusion or inconvenience.
 
Iris
 
----- YEAR2000 CFORUM appended at 12:35:05 on 97/01/20 GMT (by GBCBHG00 at ELINK)
Subject: GC28-1251-05 Guide to 2 digit dates
Ref:     Append at 18:17:07 on 97/01/17 GMT (by GAD at KGNVMC)
 
I have been bitten, not for Y2K testing but in general I had 2
applications returning different time values - one local and one GMT.
 
That was over 8 years ago and untill Greg pointed out I need the GMT
on the reply I was none the wiser. My main concern is that anyone who
reads this publication may fall in the same trap.
 
If this happens they *MAY* not be aware of the clock differences. The
TOD clock may still be set to todfays date while the local clock has been
set to a future date for testing. This can not be allowed to happen as
it is date processing we are testing. Clarity is required as a necessity.
 
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 12:45:30 on 97/01/20 GMT (by IYORK at KGNVMC)
Subject: GC28-1251-05 Guide to 2 digit dates
Ref:     Append at 12:35:05 on 97/01/20 GMT (by GBCBHG00 at ELINK)
 
We intend to add reference to specifying the GMT in the planning
guide.  Thanks for letting us know.
 
Iris
 
----- YEAR2000 CFORUM appended at 12:59:51 on 97/01/20 GMT (by MPONTES at SPOVMSIB)
Subject: year 2000 x mvs/esa 4.3
 
Hello,
I've a customer that would like information about mvs/esa 4.3 and
year 2000 support.
On ehone I found doc OZSQ683897 that mention announcement letter
295-464. I couldn't find this announcement letter. Please, does
anyone have a copy of it that could be sent to mpontes at spovmsib?
Thanks in advance, best regards.       Miriam
 
----- YEAR2000 CFORUM appended at 13:14:06 on 97/01/20 GMT (by IYORK at KGNVMC)
Subject: year 2000 x mvs/esa 4.3
Ref:     Append at 12:59:51 on 97/01/20 GMT (by MPONTES at SPOVMSIB)
 
MVS 4.3 is not the year 2000 supported release.  It starts with
MVS 5.1 and up (see planning guide).
 
The TIME macro, however, does return 4 digits in 4.3 but that is not
all you will need.  Changes were made for SMF records, SYSLOG, JCT
fields and messages and those were done only for 5.1 and up.
 
Iris
 
----- YEAR2000 CFORUM appended at 13:15:51 on 97/01/20 GMT (by GAD at KGNVMC) -
Subject: year 2000 x mvs/esa 4.3
Ref:     Append at 12:59:51 on 97/01/20 GMT (by MPONTES at SPOVMSIB)
MVS/ESA 4.3 is *not* year 2000 compliant as shipped, and there are no
plans to release PTFs to correct the non-compliance.
 
The announce letter you reference is on Hone; you should not have had
any problem finding it there.  I sent it to you as you requested, anyway.
 
Greg Dyck
MVS BCP Kernel and CURE support
 
----- YEAR2000 CFORUM appended at 13:24:42 on 97/01/20 GMT (by 86679714 at EHONE)
Subject: year 2000 x mvs/esa 4.3
Ref:     Append at 13:15:51 on 97/01/20 GMT (by GAD at KGNVMC)
 
The Announcement Letter number is US, other geographies often have a
different structure to their numbering (for example in EMEA).
 
Pete Sadler
 
----- YEAR2000 CFORUM appended at 16:41:33 on 97/01/20 GMT (by BCOKPOK at NYCVMIC1)
Subject: Assembler / Language Environment / YR2K
 
My customer asks: which Assembler Versions are YR2K compliant? Can they
run old Assembler (not- High Level) on the Language Environment without
serious problems. Please explain fully, or refer us to some literature
that would help answer these Assembler related questions.
 
Thanks.
 
Bertram
 
----- YEAR2000 CFORUM appended at 19:40:18 on 97/01/20 GMT (by PIZZAZZ at STLVM20)
Subject: Assembler / Language Environment / YR2K
Ref:     Append at 16:41:33 on 97/01/20 GMT (by BCOKPOK at NYCVMIC1)
 
> My customer asks: which Assembler Versions are YR2K compliant?
 
Only High Level Assembler is Y2K compliant. It provides four-digit year
values in all displayed dates, and supports a new system variable symbol
&SYSDATC that returns the date of the assembly in YYYYMMDD format. (Note
also that only HLASM V1R2 is current; all other assembler products have
been withdrawn from marketing and service.)
 
> Can they run old Assembler (not High Level) on the Language Environment
> without serious problems.
 
(1) If you are asking whether the assemblers themselves can assemble code
without LE, there is no problem because the assemblers do not depend on
the presence or absence of LE.
 
(2) If you are asking whether the code assembled by old assemblers will
continue to execute correctly under LE, again there is no problem. The
code will continue to work even if reassembled with High Level Assembler,
because the same object code is produced. (This also means that you do
not need to re-assemble old code with the new assembler unless it must
be modified.)
 
> Please explain fully, or refer us to some literature that would help
> answer these Assembler related questions.
 
See the High Level Assembler Presentation Guide (SG24-3910-01), the HLASM
Language Reference (SC26-4940-01) and Programmer's Guide (SC26-4941-01).
If you need detailed information contact John Ehrman (EHRMAN at STLVM27
or ehrman@vnet.ibm.com).
 
Karen R. Barney
 
----- YEAR2000 CFORUM appended at 21:39:59 on 97/01/20 GMT (by YAEGER at SJFEVMX)
Subject:  DFSORT SORT2000 Update:  COBOL, additional formats
 
I've updated my SORT2000 paper on DFSORT's Year 2000 Features
with information on the following:
 
  o sorting with COBOL using the century window and two-digit
    year formats
  o sorting, merging and transforming formats X'yymmdd', X'mmddyy',
    X'ddmmyy' and X'yyddmm' (bringing the number of formats covered
    to 49)
 
For those of you who are not familiar with the SORT2000 paper, it
contains complete details of DFSORT's new Year 2000 features, available
via R13 PTF UN90139 since May, 1996.  SORT2000 has examples of the
DFSORT control statements needed to order and transform 49 different
character, zoned decimal and packed decimal date fields, as well as
an overview of the performance enhancements provided with PTF UN90139.
 
The updated paper can be viewed on the DFSORT home page at URL:
 
     http://www.storage.ibm.com/software/sort/srtmhome.htm
 
or downloaded via anonymous FTP from:
 
      ftp://lscftp.pok.ibm.com/pub/mvs/docs/
 
or obtained for you from MKTTOOLS by your IBM representative.
 
Frank L. Yaeger - DFSORT Team (Specialties: ICETOOL, OUTFIL, Y2K :-)
 
----- YEAR2000 CFORUM appended at 01:24:22 on 97/01/22 GMT (by BCOKPOK at NYCVMIC1)
Subject: Version Reconciliation for YR2K Apps.
 
One of the problems my customers constantly complain about, especially
with shrink wrapped packages is Version Reconciliation. Does IBM have
Version Reconciliation in its YR2K methodology. If not,who do I contact
to take a look at Princeton Softech's tool (listed on the YR2K and 2-
Digit Dates Guide) for Version Reconciliation, to see if it's a tool
that IBM can use in the YR2K efforts, or recommend to customers?
 
If IBM has a tool in this area, what is it, and how can customers get it?
Thanks much
Bertram
 
----- YEAR2000 CFORUM appended at 05:08:18 on 97/01/22 GMT (by SAITOT at TOKVMSDC)
Subject: Year 2000 Work Bench
 
Could anyone give me any information of Y2K WB through on-line or
off-line ?
 
Takashi Saitoh, IBM Japan
 
----- YEAR2000 CFORUM appended at 05:17:27 on 97/01/22 GMT (by SAITOT at TOKVMSDC)
Subject: Year 2000 non-compliant COBOL
 
I would like to know or confirm something for VS COBOL II, year 2000
non-compliant COBOL compiler and run-time library.
What I want to confirm/know is that:
 
1.VS COBOL II V1.4 (non-LE environment)
 
  1) OS/390 R2 supports VS COBOL II V1.4 run-time environment, right ?
  2) IMS V6 keeps upward compatibility from IMS V4 and V5, right ?
     Dose it mean that IMS V6 supports VS COBOL II V1.4 as is base ?
  3) DB2 V4.1 supports interface of VS COBOL II V1.4 as is base, right ?
  4) CICS V4.1 has no major restriction to VS COBOL II V1.4, right ?
 
2.VS COBOL II Load Module Compatibility
 
  1) Generally speaking, load modules generated by any release of
     VS COBOL II (such as V1.1, V1.2, V1.3.0, V1.3.1, V1.3.2)
     are able to run under VS COBOL II V1.4 run-time environment, right?
 
Please advice me.
Takashi Saitoh, IBM Japan
 
----- YEAR2000 CFORUM appended at 15:23:17 on 97/01/22 GMT (by Y2KTSC4 at STLVM6)
Subject: Version Reconciliation for YR2K Apps.
Ref:     Append at 01:24:22 on 97/01/22 GMT (by BCOKPOK at NYCVMIC1)
 
You can obtain more information on Princeton Softech's tool by taking
a look at their WEB page at http://www.princetonsoftech.com.
 
In addition, it looks like you can call them at (609) 497-0205.  We are
sure they would be delighted to assist.
 
IBM - Year 2000 Technical Support Centre
 
----- YEAR2000 CFORUM appended at 15:52:26 on 97/01/22 GMT (by Y2KTSC4 at STLVM6)
Subject: Year 2000 Work Bench
Ref:     Append at 05:08:18 on 97/01/22 GMT (by SAITOT at TOKVMSDC)
 
There are a number of Work Benches in the industry.  Perhaps you can
be more specific on platform (e.g.: AS/400 , OS/2, Windows, etc...)
and environment (e.g.: COBOL, PL/1, etc...).
 
We would be delighted to assist you if we can.
 
IBM Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 17:52:59 on 97/01/22 GMT (by MA00613 at ELINK)
Subject: Version Reconciliation for YR2K Apps.
Ref:     Append at 15:23:17 on 97/01/22 GMT (by Y2KTSC4 at STLVM6)
 
I have used the version merger tool from Princeton Softech, and
have always been amused at how easy they made reconciling differences.
(Like, why didn't IBM come up with that???? VBG).
 
Identify old, identify new, run an analysis on them - review differences.
The key thing is:  if you wish to actually merge versions, there
are primary commands that really help you along.
 
Larry Kahm                                      Heliotropic Systems, Inc.
e-mail: kahml@ibm.net
"to boldly break software that no one had thought to before..."
 
----- YEAR2000 CFORUM appended at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
Subject: Lines of Code Count
Is there any known tool which count Number of Member and Records in a
MVS Partitioned Data Set. The purpose of this is to count Number of
Programs and Number of Lines of Code.
Any tool even unofficial would be welcome.
ACarlos Castro   IBM Brazil
 
----- YEAR2000 CFORUM appended at 22:41:05 on 97/01/22 GMT (by THOMEN at SJFEVMX)
Subject: Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
 
Answered offline.
 
  Mark Thomen
  DFSMS Development (Catalog/IDCAMS/VSAM)
  SJFEVMX/THOMEN or USIB54WA at IBMMAIL
 
----- YEAR2000 CFORUM appended at 22:47:48 on 97/01/22 GMT (by MA00613 at ELINK)
Subject: Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
 
If you have a PDS with statistics turned "on", you could use ISPF
Option 3.1 and print the index listing (selection x).
 
This report indicates the number of members in the data set, and
the records in each member.  At the end of the report is a summary total.
 
Hope that helps...
 
Larry Kahm                                      Heliotropic Systems, Inc.
e-mail: kahml@ibm.net
"to boldly break software that no one had thought to before..."
 
----- YEAR2000 CFORUM appended at 00:13:27 on 97/01/23 GMT (by Y2KTSC3 at STLVM6)
Subject: Year 2000 non-compliant COBOL
Ref:     Append at 05:17:27 on 97/01/22 GMT (by SAITOT at TOKVMSDC)
 
>1.VS COBOL II V1.4 (non-LE environment)
>
>  1) OS/390 R2 supports VS COBOL II V1.4 run-time environment, right ?
>  2) IMS V6 keeps upward compatibility from IMS V4 and V5, right ?
>     Dose it mean that IMS V6 supports VS COBOL II V1.4 as is base ?
>  3) DB2 V4.1 supports interface of VS COBOL II V1.4 as is base, right ?
>  4) CICS V4.1 has no major restriction to VS COBOL II V1.4, right ?
 
Yes to all.
 
>2.VS COBOL II Load Module Compatibility
>
>  1) Generally speaking, load modules generated by any release of
>     VS COBOL II (such as V1.1, V1.2, V1.3.0, V1.3.1, V1.3.2)
>     are able to run under VS COBOL II V1.4 run-time environment, right?
 
Yes
 
VS COBOL II has a limited life-time, however, so IBM recommends that
you run your programs under Language Environment for OS/390 and VM.
 
Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 00:45:44 on 97/01/23 GMT (by TMAGEE at LEXVM2)
 
Subject:  Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
 
The XREF tool is just what you need.  It is an internal IBM tool
that is available on MVS, VM, and OS/2.
 
T.D. Magee
Lexington
TMAGEE at LEXVM2
tie 545-4849
 
----- YEAR2000 CFORUM appended at 07:29:24 on 97/01/23 GMT (by GBOAOA00 at ELINK)
Subject: Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
 
Given that XREF is internal you could always write something in REXX
and call ISPF Library Management services. It is not really that
difficult to do.
 
This append was created on the External IBMLink system by
Jacqueline R. Cooper (Email: GBVF5MM1 @ IBMMAIL)
MM1 Limited
Tel +44 1243 863472
Fax +44 1243 863477
 
----- YEAR2000 CFORUM appended at 13:07:41 on 97/01/23 GMT (by CHAMC29H at ELINK)
Subject: Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
Another way to get the numer of members and lines is this:
//PDSTOPS  EXEC PGM=IEBPTPCH,REGION=256K
//SYSPRINT DD   SYSOUT=T
//SYSUT1   DD   DSN=name.of.pds,DISP=SHR (PDS for which to count lines)
//SYSUT2   DD   DCB=(RECFM=xx,LRECL=yy),SPACE=(CYL,(n,n),RLSE),
//         DISP=(MOD,CATLG),DSN=name.of.sqntlds
//SYSIN    DD   *
 PUNCH TYPORG=PO,MAXFLDS=12
 RECORD FIELD=(nn)
/*
Browsing the SYSUT2 Dataset do "find 'MEMBER NAME' all"; this gives the
number of members. The Difference between last line number and number of
member is the number of lines.
Kind regards,
Peter.
 
This append was created on the External IBMLink system by
Peter Rossel
Bedag Informatik, CH-3012 Bern (Switzerland)
Tel 0041 31-633,25,49
Fax 0041 31-633,23,69
 
----- YEAR2000 CFORUM appended at 15:10:11 on 97/01/23 GMT (by KLENSK at GDLVM7)
Subject: Lines of Code Count
Ref:     Append at 13:07:41 on 97/01/23 GMT (by CHAMC29H at ELINK)
 
Typically, the number of lines in a file is much higher than the number
of lines of code ("lines of code" is the subject of the original
append).  You really do need a tool like XREF to get a count that is
useful.
 
Tom Klensk
 
----- YEAR2000 CFORUM appended at 16:01:42 on 97/01/23 GMT (by 62473446 at EHONE)
Subject: Cobol VS Compiler in OS/390 environment
 
Even if Cobol VS compiler is no more  supported, it still works
   under MVS v5
Our year 2000 offering does not foresee a Cobol conversion ( from
Cobol VS to Cobol/MVS ) so with all restrictions already discussed
regarding ILE, will it be possible to compile old Cobol VS under
OS/390
thanks
Yvan_Simonis @ be.ibm.com
 
----- YEAR2000 CFORUM appended at 16:45:53 on 97/01/23 GMT (by LATORRES at LASVM1)
 From:     Silvina Latorre/Argentina/IBM@IBMAR (LATORRES @ LASNOTES)
 To:       Carlos Castro IBM Brazil
 Date:     01-23-97 12:00:23 PM
 Subject:  Line of Code Count
 
  Carlos:
 
  The RA tool counts the Number of Lines of Code in MVS Partitioned Data
  Set with the IRD0025 Job.
  This Job is generated in option 3 (Preprocess Copy member) and in this
  option, there are two others options.
  In option 1 (Create New Member List) you can create the member list
  that you want count.
  You will have to fill the blank spaces with parameters.
 
  Dataset Name . . . . . . . . . : _______ ---> Dataset Name of your
                                                interest
  Name of Member List  . . . . . : _____   ---> Member List to be
                                                created and processed.
                                                All copybooks will be
                                                stored in this dataset.
  Shadow Library PDS name  . . . : _______ ---> Name you wish to assign
                                                to the shadow dataset
 
  Option 2 (Process Existing Member List) generates the job (IRD0025)
  wich counts the number of lines of code of each member in MVS
  partitioned Data Set.
  You will have to fill the blank spaces with parameters.
 
  Name of the Memberlist . . . . : IVP      (Blank for Sel-list)
 
  Another option is to contact Saul Conrado, (MEXVM2 PA15063), who sent
  us a job developed in REXX wich do what you want.
 
  If you want, contact us for further information.
  Regards.
 
  LA Technical Support Center.
 
----- YEAR2000 CFORUM appended at 17:56:06 on 97/01/23 GMT (by BARD018 at ELINK)
Subject: Lines of Code Count
Ref:     Append at 21:33:59 on 97/01/22 GMT (by ACARLOS at RIOSYS1)
 
The PDS command from CBT tape (it is *free*) can count the number of
members and records (VERIFY subcommand).  However, it cannot tell how
many program statements.  To count the number of statements, the tool
needs to know the syntax of the specific program language.
 
Chen-yu Hu
C. R. Bard, Inc. Murray Hill, NJ, USA
chen-yu.hu@ccmail.crbard.com (908) 277-8512
 
----- YEAR2000 CFORUM appended at 22:14:49 on 97/01/23 GMT (by NEWSPOST at WATSON)
Subject: Append to AIX-L distribution list
X-rnews-From: "Pablo Fernandez" <pablof@vnet.ibm.com>
 
This append came up today, and it's Y2K related. I think it might be
usefull to
share it with all the FORUM subscribers.
 
From distribution list: AIX-L@pucc.princeton.edu
 
*** Question:
 
Subject:        AIX 3.2.5 Year2000 handling
 
Anybody any idea whether AIX 3.2.5 will be able to handle the date in the
Year 2000?
 
Regards, Davidng
 
--
GEC (S) Pte Ltd
GEC Building No 3 Tai Seng Drive
Singapore 535216
davidng@gec.com.sg
 
*** Answer:
 
Davidng,
 
AIX 3.2.5 is year 2000 compliant, although depending on the products you
have installed you may need
to apply some PTFs.
 
For more information concerning the level of compliance of IBM's products
(RS/6000 and AIX) you will find
information at http://www.s390.ibm.com/stories/year2000/aix.html , this is
the year 2000-ready IBM products listing within AIX.
 
The official IBM webpage for Y2000, is http://www.ibm.com/IBM/year2000
 
You can find more deep information at http://www.software.ibm.com/year2000
which is the IBM's year2000 technical support centers web page. There
you'll find a lot of information concerning the Y2000 challenge, and also a
softcopy of the book
"The Year 2000 and 2-Digit Dates: A Guide to Planning and Implementation",
a complete guide of Y2000 issues, also
whithin this book there's a complete listing of every hardware/software
product of IBM and its level of Y2000 compliancy.
 
If you need further assistance, please feel free to contact us.
 
Year2000 Technical Support Center Latin America
Pablo Fernandez - IBM Argentina
Y2KTSCLA@VNET.IBM.COM
 
Nntp-Posting-Host: pablof.argentina.ibm.com
 
----- YEAR2000 CFORUM appended at 15:07:10 on 97/01/24 GMT (by IYORK at KGNVMC)
Subject: Updates to Appendix A Since the Sixth Edition
 
We will now be posting any updates to Appendix A since the 6th edition.
These updates will be incorporated into the guide on the regular
publishing schedule.  The updates will also appear on the TSC's web
site and the century forum.
 
5695-041 ImagePlus for MVS/Folder Application Facility V2 R2 - no PTF
  required as originally indicated
5695-042 ImagePlus for MVS/Object Distribution Manager V2 R2 - no PTF
  required as originally indicated
5645-005 System Automation for OS/390 V1 R2 - PTF will be available 1997
  (no exact date known yet).
 
I hope this will help you to keep up to date.
 
Iris
 
----- YEAR2000 CFORUM appended at 22:30:28 on 97/01/24 GMT (by Y2KTSC3 at STLVM6)
Subject: Business implications with Year 2000
Ref:     Append at 14:00:22 on 97/01/02 GMT (by BRUCERAY at ICCVMAS7)
 
(No one seems to have tackled this one yet, so I will for completeness)
 
>I am curious as to where these types of discussions might be going on?
>That is, with the Year 2000, what affect will it have on existing
>everyday business functions?
 
It depends completely on the individual business, their systems, and
their applications.  If they have applications that are not affected
by the Year 2000, then there will be no effect.  If their applications
will fail due Year 2000 problems, and they do not fix them in time,
then everyday business functions would have serious problems.
 
>For instance, we all know that the Year2000 is a huge systems nightmare.
>But, for the banking industry for instance, what is the impact of all
>this on a global branch office and their daily operations?
 
Again, it depends completely on the individual bank, its systems,
and its applications.
 
>Would it affect the way they do things, their daily routine, the
>DDA function, etc?
 
Not if they do not have Year 2000 problems or if they fix the
Year 2000 problems before they happen.  That is why assessment of
the problem is so important and why companies must start fixing
the problems soon.
 
Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 22:38:02 on 97/01/24 GMT (by Y2KTSC3 at STLVM6)
Subject: OS/VS COBOL Compiler in OS/390 environment
Ref:     Append at 16:01:42 on 97/01/23 GMT (by 62473446 at EHONE)
 
>Even if OS/VS COBOL compiler is no more  supported, it still works
>   under MVS v5.
 
IBM cannot confirm this, we have never tested it.  IBM stopped testing
OS/VS COBOL in 1984, 13 years ago.  It may work in some cases, but we
cannot say "it still works".
 
>Our year 2000 offering does not foresee a COBOL conversion ( from
>OS/VS COBOL to COBOL/MVS )
 
A conversion to a new compiler is not necessary, only a migration
(No recompiles) to a new run-time library, such as Language Environment
for OS/390 and VM, which is included free with OS/390!
 
>...so with all restrictions already discussed regarding LE
 
I am not sure what this refers to, what restrictions?
 
>...will it be possible to compile old OS/VS COBOL under OS/390
 
It is not likely that there is something in OS/390 that will cause
the old compiler to stop working.  Customers may try this, but IBM
will not, so customers will have to tell us!  We do know of bugs that
exist in the old COBOL run-time library, but they will never be fixed.
A new release of DFSMS could easily expose these.
 
Year 2000 Technical Support Center
 
----- YEAR2000 CFORUM appended at 17:32:14 on 97/01/27 GMT (by GBCADH00 at ELINK)
Subject: OS/VS COBOL Compiler in OS/390 environment
Ref:     Append at 22:38:02 on 97/01/24 GMT (by Y2KTSC3 at STLVM6)
But a fix was produced for DFSMS because of an incompatible change
which prevented old Cobol load modules from working.
 
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:51:35 on 97/01/27 GMT (by SHERRY at SJFEVMX)
Subject: OS/VS COBOL Compiler in OS/390 environment
Ref:     Append at 17:32:14 on 97/01/27 GMT (by GBCADH00 at ELINK)
 
Yes, a fix was provided when a change to DFSMS/MVS R3 was incompatible
with OS/VS COBOL object modules.  Changes of this kind are reviewed on
an individual basis and resulted in a decision to change DFSMS/MVS
based on the business impact of the incompatibility.  This change was
to permit the object modules to continue to run, which has been stated
as a point of compatibility.  This should not be construed to indicate
that additional changes will be made, either for DFSMS/MVS or for OS/390.
Requiring use of the LE runtime library does not change the fact that
the object modules created with OS/VS Cobol can continue to function.
 
Sherry Goncharsky
DFSMS Investment, Strategy, and Plans
SHERRY @ SANJOSE or sherryg@vnet.ibm.com
 
----- YEAR2000 CFORUM appended at 10:29:11 on 97/01/28 GMT (by SAITOT at TOKVMSDC)
Subject: Year 2000 Work Bench
Ref:     Append at 15:52:26 on 97/01/22 GMT (by Y2KTSC4 at STLVM6)
 
I would like to know the Year 2000 Work Bench which is available for
COBOL, ASM, and PL/I (in host environment, maybe).
 
Takashi Saitoh, IBM Japan
 
----- YEAR2000 CFORUM appended at 15:20:26 on 97/01/28 GMT (by IYORK at KGNVMC)
Subject: 6886 Update level
 
A few weeks ago someone asked me about the 6886 and whether or not
the BIOS update level was correct in the guide (see A-88 figure A-24).
I've since misplaced the note from the original requestor so
I'm posting it here in case he/she monitors this forum.  If not,
I'm sure I'll get a reminder request.
 
The guide is correct in stating that you need BIOS level N2JT38A.
While level N2JT32A will work sometimes, it does not work in all cases
so you really need the 38A level.
 
Iris
 
----- YEAR2000 CFORUM appended at 16:25:42 on 97/01/29 GMT (by GBCBDN01 at ELINK)
Subject: TOD integrity
I apologise if this question has been asked elsewhere before, but....
 
I am just starting to get involved in Year2000 projects at my
installation and have the following question re 3090 processors.
 
If I am running a 3090 LPAR with the TOD clock set to a Year2000
type date, is the integrity of the PHYSICAL H/W 3090 CLOCK
guaranteed?....I have a concern with Year2000 testing tools or home
grown code that could run in an LPAR and then destroy the outside
world, ie other LPARs running with CURRENT TOD setting.
 
Am I suffering from severe paranoia?  It is years since i got
involved in any dangerous assembler programming and can't remember
what a 'skilled' person could do!
 
This append was created on the External IBMLink system by
Steve Norris
Technical Consultant
ITnet - Birmingham (0121 459 1155)
GBKXFZXF at IBMMAIL
 
----- YEAR2000 CFORUM appended at 16:37:34 on 97/01/29 GMT (by GAD at KGNVMC) -
Subject: TOD integrity
Ref:     Append at 16:25:42 on 97/01/29 GMT (by GBCBDN01 at ELINK)
The TOD value at a CPU level within a LPAR zone is 100% totally isolated
from all other zones on that processor.
 
Greg Dyck
MVS BCP Kernel and CURE Support
 
----- YEAR2000 CFORUM appended at 01:44:31 on 97/01/30 GMT (by AS106492 at ELINK)
Subject: Application Inventory tools
Ref:     Append at 11:36:17 on 96/08/13 GMT (by GBCBHG00 at ELINK)
 
This append was created on the External IBMLink system by
Qantek