RE: Don't use Rcldlo.A Ptf is On

If you can't wait for the PTF ( we ran RCLDLO 1/1/2000 ) here is the patch
for the adventurous:

To patch the system to get around this PROBLEM:
o  STRSST
o  Option 1 to Start a Service Tool
o  Option 4 to Display/Alter Dump
o  Option 1 to Display/Alter Storage
o  Option 1 for MI Object
o  Option 14 for Index
o  Option 1 for Find by Object Name
o  Type SWILL for the name SUBTYPE: CD and QDOC library name
   (library in context field), leave library subtype as 01

  Object:
    Type . . . . . . . . . :   (0E) - Index
    Name . . . . . . . . . .   SWILL
    Subtype  . . . . . . . .   CD   00-FF

  Context:
    Name . . . . . . . . . .   QDOC
    Subtype  . . . . . . . .   01   00-FF
Type choices, press Enter.

-  Press Enter on the Display Object Found Information screen
      where it repeats object name.
-  For RISC releases, Take Option 1 for Display Unformatted Data
-  On Control line, if RISC, enter P18 (for IMPI, enter P1A) and
    F10 to push stack this takes you to the Associated Space of
    SWILL object.
-  X/220 from there is a date/timestamp(to get there,
         enter 220 in the control field and then page down once)
     or you can
         add 220 to the address at the top and press enter.
       Ex: addr 01A3D700 0200 + X'220 = 01A3D700 0420

Before Image:
                     Display Storage

Control ....                 nnnnn, Pnnnn, Lcccc, .cccc, >
Address ....   01A3D700 0200

0200 C3C80200 00000080  00000000 00000000 * CH.............. *
0210 00000000 00000000  00000000 00000000 * ................ *
0220 00000000 00000000  00000000 00000000 * ................ *
0230 00000000 00000000  00000000 00000000 * ................ *
0240 00000000 00000000  00000000 00000000 * ................ *


After Picture:
                     Display Storage

Control .....             nnnnn, Pnnnn, Lcccc, .cccc, >
Address ..... 01A3D700 0420

0420 00000000 00000000  00000000 00000000 * ................ *
0430 00000000 00000000  00000000 00000000 * ................ *
0440 00000000 00000000  00000000 00000000 * ................ *
0450 00000000 00000000  00000000 00000000 * ................ *
0460 00000000 00000000  00000000 00000000 * ................ *
0470 00000000 00000000  00000000 00000000 * ................ *
0480 00000000 00000000  00000000 00000000 * ................ *
0210 00000000 00000000  00000000 00000000 * ................ *
0220 00000000 00000000  00000000 00000000 * ................ *
0230 00000000 00000000  00000000 00000000 * ................ *
0240 00000000 00000000  00000000 00000000 * ................ *

  NOTE: In most cases this will actually be offset 420
-The first 4 bytes at that offset is the date/timestamp that we
 can change to get around this probem.  It is probably all 0's
 (meaning the first column is 00000000)  You can change the
 first character to an 8

                      Display Storage

Control . . . . . . .             nnnnn, Pnnnn, Lcccc, .cccc, >
Address . . . . . . .   01A3D700 0420

0420 80000000 00000000  00000000 00000000 * ................ *
     -
0430 00000000 00000000  00000000 00000000 * ................ *
0440 00000000 00000000  00000000 00000000 * ................ *
0450 00000000 00000000  00000000 00000000 * ................ *
0460 00000000 00000000  00000000 00000000 * ................ *
0470 00000000 00000000  00000000 00000000 * ................ *
0480 00000000 00000000  00000000 00000000 * ................ *
0490 00000000 00000000  00000000 00000000 * ................ *
- Press F11 twice to alter storage and go back to display mode
- Back out to a command line and they should now be able to
  create the DLO object
.
If the problem is occuring on a QDOC library that is in a user
ASP, (library QDOC0002, QDOC0003, etc.) the date/timestamp that
needs to be udpated is at a different location.  The directions
above take you to the date/timestamp for QDOC.  The
date/timpestamps for the other QDOC's follow at offsets of x/10,
so the date/timestamp for QDOC0002 is at x/0230, for QDOC0003 is
at x/0240, and so on.

Alex Moore ~ Ellis Hosiery Mills, Inc.
alexm@ellishosiery.com
    _    _             __  __
   / \  | | _____  __ |  \/  | ___   ___  _ __ ___
  / _ \ | |/ _ \ \/ / | |\/| |/ _ \ / _ \| '__/ _ \
 / ___ \| |  __/>  <  | |  | | (_) | (_) | | |  __/
/_/   \_\_|\___/_/\_\ |_|  |_|\___/ \___/|_|  \___|

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of bvining@vnet.ibm.com
Sent: Monday, January 03, 2000 1:59 PM
To: MIDRANGE-L@midrange.com
Subject: Don't use Rcldlo.A Ptf is On


To expand on this a bit, there is a Y2K APAR that is being worked on
for RCLDLO.  The APAR is SA86751, and basically MCH1210 may occur when
operating with DLOs after performing a RCLDLO.  Perhaps it's just me,
but I consider MCH errors to be different than "machine checks".

The easiest way to avoid this is to not use RCLDLO until PTFs are
available.  As the attached note indicates, PTFs for V3R2, V3R7 and
the various V4 releases are targeted for later this week.

Bruce

>
>Ibm call us today to say don't use Rcldlo.
>A ptf will be deliver this week.
>
>This cause a machine check.
>A Y2K problem.
>
>Stephane Leon
>


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---