To call the IBM Support Center,
 
  Call 800-237-5511.  They will take some information like name and
      customer number, and assign you a problem number (eg 3X852).
      Record this number.  You then wait for a service representative
      to help you.
 
  You have three customer numbers (aka Access Code)
>>*** 4600627 - Has VM/SP 5, HPO 5, XA/SP 1, and a bunch more.
      4601013 - A bunch of stuff, like SQL.
    * 4607811 - Has VM/SP 4, HPO 4.2, and a bunch more stuff.
      5482071 - AIX
 
  The program product numbers for CMS are 5664-167C for SP/4
                                      and 5664-308  for SP/5.5.
 
>>Use the VMD 3090 for a CPU Serial, #70119.
 
  When there's a problem with a fix, they prefer knowing the PTF number,
  (UV33060), not the APAR number (29078).
  - The update filetype has the APAR number.
  - The SID code in the update itself has the APAR number.
  - The AUX file has both numbers.
 
==============================================================================================================================================================================================================================
Problem # |
Date/time |    Regarding
----------+--------------------------------------------------------------
6X731 (CL)|   There's a problem with APL in fullscreen mode, e.g. when
12/12/89  | running with the session manager, under XA/SP 2 & CMS 5.5.
 4:15 pm  | To reproduce, get inside APL (on VMD, just type in APL),
          | send yourself a message (via )HOST M * Hi, Rick.), then
Amy Bowen | exit APL (via )OFF HOLD).  If TERM BREAKIN GUESTCTL is in
BOWENAMY  | effect, the screen will lock until you hit PA1 a few times.
  at      | If TERM BREAKIN IMMED is in effect, the screen clears after
ENDVMFE0  | you say )OFF HOLD, your message appears at the top of the
01/09/90  | screen, and stays there 'till you hit clear.  Then the
10:00 am  | screen temporarily returns to your fullscreen, APL session,
Rich      | then exits.  We've got standard stuff in this area, so I
Cunningham| called it in.
   and    |
somebody  |   I got a call from APL Level 2 and basically they said
else, I   | that they couldn't recreate the problem.  They also
didn't    | mentioned GDDM APAR VM39425, but that doesn't sound like
catch his | my problem.
name      |
          |   Called and left a message.  Something about did APAR
Roy Bei   | VM39425 solve my problem?  I didn't even pursure that APAR.
02/01/90  | VM39425 is still open.  It has to do with GDDM and resetting
10:00 am  | the keyboard.
          |   I finally got hold of Roy, and he's still investigating
          | the GDDM apar, still trying to get it to fail on one of his
          | systems, and wants to talk to a CP screen-handling expert.
Roy Bei   | Rich Cunningham, by the way, sits next door to Roy.
02/27/90  |   Roy called back again, asking if I was using VTAM and
 9:11 am  | what release of CMS I was using.  I said no and CMS 5.5.
          |
06/13/90  |   I called just to see what the status was.  It's been 3
 9:15 am  | months since I've heard anything.
          |
 2:25 pm  |   Roy Bei called and said he's just kinda let it slide.
          | He was waiting for a response back from the CP console guys
          | and never got it.  He's going to resurrect it.
          |
06/15/90  |   Han Morgan, ARCANGEL at KGNVMC, called and asked for a
 2:40 am  | CP TRACE and a TRSOURCE trace of what's happening.  He gave
Han Morgan| me the commands to type in (I wish I wrote them down) and
ARCANGEL  | I got into APL, sent myself a message, and exited APL.  I
  at      | hung as expected.  I got into CP READ by hitting <reset>
KGNVMC    | and PA1 a coupla times, TRACE END ALL, CLOSE PRT, TRSOURCE
Dept 74NK | DISABLE ALL, Q TRF, I CMS, TRACERED 105, and sent him both
292-8504  | my spooled console and the TRSOURCE output.  All this was
          | done from RAJ on my 3278-5 at VMD address D65.
          |
10/01/90  |   I looked on Retain myself to see what the status was.
          | Han Morgan had this to say on 07/02, "I looked at the
          | trace and tried to recreate the problem with no success and
          | we suspect at this time that this is a APL problem....
          | Delaying..Han'.  I still haven't heard anything since 6/15.
          | I called the support center again and asked for a call
          | back to check on the status.
          |
10/02/90  |   Got a phone message from somebody saying they're looking
          | into it.
          |
10/08/90  |   Called again to get another call back.  What a pain I'm
10:10 am  | making of myself, huh?
          |
03/05/91  |   Still haven't heard anything.  Time to resurrect the
 9:45 am  | issue.  I did notice however, Han Morgan updated the PMR on
          | 2/21/91.  He had this to say, "We did a trace here and found
          | that the interrupt is passed to the guest but not then
          | responded to - in this case APL....Looking further."
          |
03/05/91  |   Roy Bei called.  He mentioned Han's update, but he'll call
10:35 am  | Han, get more information, and call me back.
          |   Got another call a bit later from Allison Irwin saying
          | that Han Morgon was out sick, expected back 3/11, and she'll
          | have him call me or update the PMR or call Roy Bei or do
          | something when he gets back.
          |
05/14/91  |   Called again to get another call back.  This thing will
 9:30 am  | never close unless I push it.  Roy called when I was on the
10:00 am  | phone and left a message.  I called him back and left another
10:30 am  | message.  Roy called me again and said he would get hold of
 1:00 pm  | Allison or Han and see what's up.  The last thing Roy told
Roy Bei   | those two was "If there's something wrong with APL, tell me
8-543-4632| or show me and I'll fix it."  They haven't done that, so
          | nothing has been done.
          |
05/17/91  |   Roy called back.  Evidently, Han Morgan is out with a
 6:50 am  | medical problem and won't be back for awhile.  Roy will get
Roy Bei   | hold of somebody else and call me back when he's learned
          | something.
          |
06/12/91  |   Han's finally back (yea!!).  He asked what kind of terminal
 9:15 am  | I had - I told him a direct, coax-connect, 3278, and asked me
Han Morgan| to do another TRSOURCE trace for him.  I did, generated a
ARCANGEL  | 75,000 line file, and sent it to him.  (I shoulda compressed
  at      | or tersed it first.  Rats.)  The TRSOURCE commands were
KGNVMC    |   TRSOURCE ID HAN TYPE IO DEV D65 IODATA 500
          |   TRSOURCE ENABLE ID HAN
          |   TRSAVE CP ON
          |    -- recreate the problem.  APL, )HOST M * *, )OFF HOLD,
          |       and hit PA1 a couple of times to get free.  I got msgs
          |       saying that trace data was lost (or something like
          |       that), so Han may call later and have me reduce the
          |       CP tracing with SET CPTRACE.
          |   TRSOURCE DISABLE ID HAN
          |   TRSAVE CP ON
          |   TRACERED spid1 spid2 CMS HAN TRACE, then SF it to Han.
07/16/91  |
 4:00 pm  |   Just found out that Wes has "fixed" APL by taking out an
          | unneeded "VMPUSH SCREEN" from the APLCOMMN EXEC.  Mark Jurich
          | found out that this was causing the hang, told Wes, and
          | started a thread in the APL2R3 FORUM on IBMAPL.  I talked to
          | Doug Aiton in STL who said he was investigating and sent this
          | note to Han Morgan.
=========================================================================
Date: 16 July 91, 15:07:55 PDT
From: Rick Jasper               8-457-2731           JASPER   at ALMVMD
      VM Systems Support
To:   ARCANGEL at KGNVMC
 
Re:  6X731,397 - The send-yourself-a-message-under-full-screen-APL-with-TERM-
     BREAKIN-GUESTCTL-in-XA-mode-and-the-screen-locks-up problem.
 
  I've just been made aware of a thread in the APL2R3 FORUM on the IBMAPL
IUO conferencing disk started by one of our users, Mark Jurich, on 91/07/11.
Mark describes the problem and Doug Aiton, who evidently supports APL in
some way at STL, said he was investigating.  Anyway, Mark found out that
the problem only manifests itself when you did a "VMPUSH SCREEN" before
getting into APL.  On our system, when you type in "APL", a bunch of execs get
invoked, one of which had buried in it a "VMPUSH SCREEN".  Our APL person has
taken it out (it wasn't needed any more anyway), and things now work fine
here. I can still get things to fail here 'cause I made a copy of the old,
unmodified exec with VMPUSH SCREEN still in it, but I wanted to make you
aware of all this.  As I recall, you had troubles recreating my situation on
your system.  Maybe you can get it to fail by bracketing your call to APL
with a VMPUSH SCREEN and a VMPOP SCREEN.  If nothing else, you might want
to talk to Doug Aiton.  His tie-line is 8-543-3590.  He has other information
regarding this situation that I haven't told you (cause I didn't follow it
when Doug told me, that's why).
          |
Roy Bei   |   Roy called.  Han sent my note above to him and asked Roy to
BEI at    | close the PMR since I have a workaround.  I told Roy, no.
  STLVM20 | There's still a problem somewhere, so it should be fixed.
 7/18/91  | Doug Aiton (who's in the same department as Roy, btw) has
 9:45 am  | a better handle on the problem (you don't have to use VMPUSH
          | to make it fail - any CP i/o will cause it to fail, and any
          | CMS i/o will break it free - or something like that).  Roy
          | said he would not close the PMR and try to transfer it over
          | to CP screen management (Han).
Tim French|
8-292-8439|   Tim called.  Evidently, Roy updated the PMR stating "the
 7/18/91  | customer wanted a solution."  Tim thought that meant now (or
10:30 am  | in the next few hours), so called me (Han was out).  I told
          | him the story and said it wasn't "now", but maybe within a
          | few weeks or so.  Tim said he would have Han update the PMR.
 7/22/91  |
 7/22/91  |   Han sent a note asking about my level of HCPGRF.  I told
Han Morgan| him  and he said it's current.  He's working on a TRSOURCE
          | trap for me to run.
          |
 8/15/91  |   Han sent me a TRSOURCE trace that he wanted me to run
Han Morgan| "with as little users as possible", but the TRSOURCE
          | statements didn't match the level of HCPGRF we have.
          | Here is Han sent me.
TRSO ID FSS1 SET FSSET TYPE I/O DEV XXXX IOD 500
TRSO ID FSS2 SET FSSET TYPE DATA LOC HCPGRF + 1484 58F0DA14 DL G8.130
TRSO ID FSS3 SET FSSET TYPE DL G8+8%.100
TRSO ID FSS4 SET FSSET TYPE DATA LOC HCPGRF + 14E4 58F0DA1C DL G8.130
TRSO ID FSS5 SET FSSET TYPE DL G8+8%.100
TRSO ID FSS6 SET FSSET TYPE DATA LOC HCPGRF + 1574 58F0DA20 DL G8.130
TRSO ID FSS7 SET FSSET TYPE DL G8+8%.100
TRSO EN FSSET
* RECREATE THE PROBLEM ON THE TERMINAL AND TURN OFF THE TRACES ASAP.
END THIS WITH -
 TRSO DISABLE FSSET.
          |
 8/19/91  |   I sent Han a note back saying his TRSOURCE trace doesn't
          | match our HCPGRF and that we have a local mod.
 8/20/91  |   Han sent a note back saying he will get back to me.
          |
 9/13/91  |   I got a phone call from a Betty Carr who said she was the
          | Level 2 Change Team manager asking about this problem.
          | She said she thought they were waiting on me to provide them
          | with a trace.  I sent a note back to her telling her about
          | the last 3 notes between Han and myself, showing that it was
          | I who was waiting on them.
 9/13/91  |
 2:15 pm  |   Boy, I don't know who that lady was, but I got a response
          | from Han today.  She must have rattled his cage a bit.
          | Anyway, Han sent me another trsource trace file with
          | different offsets, but they still don't match what I get
          | when I assemble HCPGRF without our local mods.  But Han did
          | send me enough english this time so that I was able to
          | figure out what he intended.  I changed the offsets and the
          | hex instructions to match our CP.  Han also had things
          | wrong in the rest of the TRSOURCE syntax that I had to
          | correct.  What a pain.  Evidently, Han isn't that careful.
          | I finally had to call Han and ask him over the phone to
          | correct the trace.  Han also asked for me to do a CPTRACE
          | at the same time and to send it all to THUNDER4 at KGNVMC.
          | Here's the note I sent to both Han and THUNDER4 (it turns
          | out that THUNDER4 *is* Han, so I didn't have to send two).
          |
Date: 13 September 91, 14:52:33 PDT
From: Rick Jasper               8-457-2731           JASPER   at ALMVMD
      VM Systems Support
To:   THUNDER4 at KGNVMC
cc:   ARCANGEL at KGNVMC
 
Ok, Han.  The trace has been done.  I logged onto RICK at ALMVMY (our test
VM system) and got into APL.  Then from another userid, I
 
SET CPTRACE ALL
TRSO ID FSS1 SET FSSET TYPE IO DEV 06A0 IOD 500
TRSO ID FSS2 SET FSSET TYPE DATA LOC HCPGRF + 1478 58F0D9F4 DL G8.130
TRSO ID FSS2 SET FSSET DL G8+8%.100
TRSO ID FSS4 SET FSSET TYPE DATA LOC HCPGRF + 14D8 58F0D9FC DL G8.130
TRSO ID FSS4 SET FSSET DL G8+8%.100
TRSO ID FSS6 SET FSSET TYPE DATA LOC HCPGRF + 1568 58F0DA00 DL G8.130
TRSO ID FSS6 SET FSSET DL G8+8%.100
TRSO EN SET FSSET
TRSAVE CP ON
 
Then from RICK, I sent myself a message via ")HOST M * *".  The screen beeped
  as it should (TERM BREAKIN GUESTCTL).
 
I then did the ")OFF", which should clear the screen, give me the queued
  message, and return to CMS.  What I got instead was the same screen I was
  looking at (APL) and the terminal went into input inhibited.
 
I then hit the reset key on my terminal and hit PA1.  The terminal went into
  input inhibited status again.
 
I hit reset and PA1 again.  Same thing.  Input inhibited.
 
I hit reset and PA1 a third time.  This time CP cleared the screen, gave me
  the queued message, and put me in CP READ.
 
From the other userid, I stopped the traces via TRSAVE CP OFF and
  TRSOURCE DISABLE SET FSSET.  The result was five TRF files.
 
OWNERID  FILE TYPE CL RECS DATE  TIME     FILENAME FILETYPE ORIGINID
RAJ      0111 TRF  A  0003 09/13 14:37:49 FSS4     DATA     SYSTEM
RAJ      0115 TRF  A  0002 09/13 14:37:49 FSS2     DATA     SYSTEM
RAJ      0119 TRF  A  0002 09/13 14:37:49 FSS1     IO       SYSTEM
RAJ      0123 TRF  A  0256 09/13 14:37:53 CPTRACE  CP       SYSTEM
RAJ      0127 TRF  A  0060 09/13 14:38:08 CPTRACE  CP       SYSTEM
 
I read each TRF file in with no selection criteria and am sending you the
five files to make sense out of.  CPTRACE FILE1 is TRF file #123.
CPTRACE FILE2 is TRF file #127.  Hope this is what you need.
 
Rick
          |
 9/16/91  |   Han sent a note asking me to merge the above 5 trace files.
          | I sent him a note back saying I didn't know how to use
          | TRACERED to do this, so either tell me what to type in or
          | logon to RAJ at ALMVMY and do it himself.  As far as I know,
          | you can't merge them with TRACERED.  TRACERED will only merge
          | one TRSOURCE file and one CPTRACE file together, not any
          | other combination.
          |
 9/25/91  |   Han opened VM49641 for this problem.
          |
10/23/91  |   Got a note from Janet Geddes from the CP Change Team/Devel-
 2:00 pm  | opment saying VM49641 is being closed as a DUP of VM47475.
          | Seems like I looked at VM47475 before.  Forgot why we didn't
          | try it.  Anyway, I replied to Janet that I will.  Maybe the
          | pre-req chain is too long.  I forget.
          |
10/30/91  |   It was long!  By the time I got done with this, I had two
11:30 pm  | dozen PTF's and almost 200 files.  Anyway, I got it all done
          | and tested it last night and it still failed.  In the shower
          | this morning I realized I had built from the wrong set of
          | disks and didn't pick up the new fixes.  Tried it again today
          | and it worked.  Great!  I sent a note to Janet that it
          | worked and apologized for my note last night saying it didn't
          | and told her to close the PMR and APAR.
          |
11/04/91  |   Turns out the above service broke XAUTOLOG only if you're
          | XAUTOLOGging from a class G user that's authorized from a
          | XAUTOLOG card in the directory.  UM18375 fixes it.
          |
11/14/91  |   Finally got it IPL'd on VMD this morning and Mark Harwood
          | noticed that responses to CP commands from XEDIT, don't
          | break through the screen like they used to.  Should they?
          | Wayne said it was kinda nice that the "1 FILE PURGED" msg
          | doesn't break through when discarding files from RDRLIST.
          | Hmmmm.  Is it worth calling it in?  Nah, unless somebody
          | else complains louder.  (See 3X344.)
          |
11/15/91  |   Had a hang on VMD this morning.  Looked like a deadlock.
          | Found VM48731/UM19543 and put it on.  This is the third PE
          | against VM47475!  Pretty flaky fix, if you ask me.
          | See my PMR 3X344 below.
          |
----------+--------------------------------------------------------------
1X692 (CL)|   Bob Carr's test MVS virtual machine on ALMVMY is getting
 6/10/91  | missing interrupts.  The message on the MVS console is
12:50 pm  |   IOS071I  E06,15,JES2, MISSING CHANNEL AND DEVICE END
Sue       | MVSVM1 is the userid, its virtual E06 is its own full-pack
          | MDISK.  Bob found a big APAR, VM39582, and a PE to it,
          | VM42154, that are new to 9101.  They may be suspect, but I
          | dunno yet.  Using TRSOURCE,
          |    TRSOURCE ID MVS TYPE IO DEVICE 506 IODATA 100
          |    TRSOURCE ENABLE ID MVS          |
          |    ... have MVS do its thing ...   \---> The real address.
          |    TRSOURCE DISABLE ID MVS
          |    Q TRF * ALL
          |    TRACERED spid CMS fn ft
          |    X fn ft
          | and
          |    TRACE I/O E06 CCW INST INT,
          | I saw CP doing an I/O as follows (notice the CE/DE here,
          |                                      the 0C in the last word)
TRACE TYPE IO, CPU 0000                  TIME 11:42:03.082617    |
      TRACEID = MVS, TRACESET = NULL, IODATA = 100               |
      USER = MVSVM1, I/O OLD PSW = 033C0000 8016FCAE             |
      DEVICE = 0506, SCSW = 00C04007 0224D6F8 0C000001 <---------/
   -> CCW(1) = 63400010 01571020, CCW ADDRESS = 0224D6D8
      DATA = 00C41000 00000000 00E20000 00F0000E  *.D.......S...0..*
   -> CCW(2) = 47400010 0224D720, CCW ADDRESS = 0224D6E0
      DATA = 06000001 00E30006 00E30006 05570000  *.....T...T......*
   -> CCW(3) = 06441000 02381848, CCW ADDRESS = 0224D6E8 ** IDA **
     -> IDAW(1) = 03025000
        DATA = 4780C2B0 D5028024 C3C34780 C2B0D502  *..B.N...CC..B.N.*
               8024C3C6 4780C2B0 D5028024 C3C94780  *..CF..B.N...CI..*
               C2B0D502 8024C3CC 4780C2B0 D5028024  *B.N...C...B.N...*
               C3CF4770 C2FA58F0 FA089300 F0004780  *C...B..0..l.0...*
               C2CC5EF0 C38A9180 F0014780 C2B447F0  *B.;0C.j.0...B..0*
               C2FA900F F004D72B F044F044 5080F058  *B...0.P.0.0.&.0.*
               9202F003                             *k.0.*
     -> IDAW(2) = 03025800
   -> CCW(4) = 03200001 7FFFFF02, CCW ADDRESS = 0224D6F0
          |
          | but when MVSVM1 got the interrupt, the channel status and
          | device status fields were all zeros.  This is wrong.
          |
00:  -> 0116E450' TSCH  B2358050 >> 01C28590    CC 0    SCH 0008    DEV 0E06
00:             CCWA 03CC10E0   DEV STS 00  SCH STS 00  CNT 0001
00:             KEY 0   FPI 80  CC 0   CTLS 4029
          |
          | (These two trace extracts were from different I/O's, so some
          | fields won't match, but they are examples of what's going on)
          |
 6/11/91  |   Robert wanted me to send him a combined TRSOURCE and CP
 3:00 pm  | trace of the situation, as well as a console listing from
Robert    | the MVS console with trace on there.  To setup,
Kabbes    |    TRSOURCE ID MVS TYPE IO DEV 506 IODATA 32
RKABBES   |    TRSAVE FOR ID MVS SIZE 2000 KEEP 5
  at      |    SET CPTRACE OFF
KGNVMC    |    SET CPTRACE FOR SPECIFIC RESET
8-292-8577|    SET CPTRACE FOR MVSVM1
          |    SPOOL CONS JASPER EOF START
          |    -- Get MVSVM1 set up.  Logon, IPLXA, PF11, then enter,
          |       R 00,CLPA,SYSP=J2 to the System Parameters prompt,
          |       R 00,VM to the Catalog prompt, then when you see the
          |       Starting JES2 - checkpoint in progress message, hit
          |       the clear key (!) to get into CP READ.
          |    TRSOURCE ENABLE ID MVS
          |    TRSAVE CP ON SIZE 2000 KEEP 5
          |    TRACE I/O E06 INT INST CCW RUN CMD Q TIME
          |    -- Let MVSVM1 go until you get a IOS071I message.
          |    TRSAVE CP OFF
          |    TRSOURCE DISABLE ID MVS
          |    -- Hit the clear key to get MVSVM1 into CP READ.
          |    TRACE END
          |    SPOOL CONS STOP CLOSE
          |
          |    TRACERED spid1 spid2 CMS MVS TRACE   (The IO & CP traces)
          |    -- null line for selection criteria --
          |    RECEIVE spid3 MVS CONSOLE            (The VM trace)
          |
          |   The instructions for bringing up MVS on VMY are,
          | - Logon to MVSVM1.
          | - Type IPLXA.
          | - Hit PF11.
          | - Hit <enter>.
          | - For the "system parameters" prompt, R 00,CLPA,SYSP=J2
          | - For the "catalog" prompt, R 00,VM
          |
06/26/91  |   Rob sent a note last Friday saying he needed more/better
Rob Kabbes| traces.  I redid the trace and sent them to him.  He'll be
          | on vacation for the next 2 1/2 weeks, so for future
          | reference, MVS TRACE7 (sent to Rob as MVSTERSE TRACE7) is
          | TRF file 175, which is a CPTRACE only, with SET CPTRACE
          | set to I/O IOS VINT VCSW CALLRET and RUNU, via
          |     SET CPTRACE OFF
          |     SET CPTRACE FOR SPECIFIC RESET
          |     SET CPTRACE FOR SYSTEM I/O IOS VINT VCSW CALLRET RUNU
          |     TRSAVE CP ON SIZE 6000 KEEP 5   <-- This turns it on
          |     ...  have MVS do its thing ...
          |     TRSAVE CP OFF
          | then TRACERED 175 CMS MVS TRACE7 with no selection criteria.
          | During all this, I had a virtual machine trace set on
          | MVSVM1, viz TRACE I/O INT INST NORUN CMD Q T.  That trace
          | is in the file MVS CONSOLE7.
          |
          |   After I did TRACE7, I turned on the full CP tracing via
          |     SET CPTRACE OFF
          |     SET CPTRACE ON ALLCODES
          |     TRSAVE CP ON SIZE 6000 KEEP 5
          | and reran the MVS loop.  This created TRF file 179.  The MVS
          | console trace is also included in MVS CONSOLE7.  Since 179 is
          | so big (1016 4K records), I initially TRACERED'd it with
          | selection criteria of RDEV 506 (as I recall) and called it
          | MVS TRACE8.
          |
          |   Both traces should have been useful, but for some reason,
          | TRACE7 didn't have any virtual I/O stuff in it, so it was
          | hard to correlate the console tracing with it.  However, we
          | found a good correlation in TRACE8 starting with a virtual
          | SSCH at 12:25:29 and ending with a TPI at 12:26:22, so I
          | re-TRACERED 179 with selection criteria TIME 06/27/91
          | 12:25:29 06/27/91 12:26:30, called it MVS TRACE82, tersed
          | it, and sent it off to Rob.  That's where it sits now.
          |
 7/15/91  |   Rob is back from vacation and called me to see where things
          | stood.  I told him just where they stood 3 weeks ago.
          | I refreshed his memory on where we were and he went to go
          | look at things again.  Meanwhile, I agreed to increase MVS's
          | DASD MIH time.
          |
 7/16/91  |   Rob called again and said everything looked fine to him.
          | He's waiting for me.
          |
Date: 16 July 91, 16:05:15 PDT
From: Rick Jasper               8-457-2731           JASPER   at ALMVMD
      VM Systems Support
To:   RKABBES  at KGNVMC
 
Rob,
 
  We set the MVS DASD MIH time to 5 minutes, 15 seconds, and MVS came up
fine.  We lowered it to 2:00 and got exactly 1 missing interrupt message on
the MVS console, but MVS still came up ok.  We changed it to 3:00 and got
zero missing interrupt messages and MVS came up ok.  We left it at 3:00.
 
  Looking at the time stamps in the MVS console, we saw that the 5:15 IPL
took 26 seconds longer than the 2:00 setting.  This leads me to believe that
CP is taking about 2 minutes, 15 seconds or so to finish one of MVS's CCW
chains (my guess is it's the one that writes 90 tracks of data in one i/o).
 
  The next thing I could do is have TRACE I/O INT INST NORUN CMD Q T active
on the MVS virtual machine and send you the results of that.  That should
give us CP's I/O "service times".  Presumably we'll see a Start Subchannel
that takes between 2-3 minutes to complete.  I'll do that tomorrow.
 
Rick
          |   Sigh!  Robert called.  The trace is no good.  He needs
 7/24/91  | another one, this time using all three traces, TRSOURCE,
 9:30 am  | CPTRACE, and the virtual machine trace.  I redid the trace,
Robert    | all looks good this time (i.e. the Virtual SSCH, TSCH, etc.
  Kabbes  | were all there) and sent him the stuff.  The CP traces
          | (CPTRACE & TRSOURCE) totaled over 2 million lines.  14 meg.
          | 275 3380 cylinders.  And that was for one I/O!  The files
          | (MVS9TERS CPTRACES & MVS9 CPTRACES) are on DUMPVMD's 191
          | disk.  MVS CONSOLE9 is on RICKLANE's 191 disk.
          |
 7/25/91  |   Robert didn't like this one either!  Good grief!  He wants
          | another trace done.  I did another one (MVS10), but didn't
          | send it to him 'cause after looking at the 2 million line
          | trace I sent him, it looks usable.  Here's my note to him.
          |
Date: 25 July 91, 15:51:07 PDT
From: Rick Jasper               8-457-2731           JASPER   at ALMVMD
      VM Systems Support
To:   RKABBES  at KGNVMC
 
Re:  1X692,397
 
Rob,
 
   I took another look at that 2 million line trace and there were two
I/O's that took 2 minutes 40 seconds to complete.  See the Virtual Start
Subchannel at 09:35:40.006632, and the next one at 09:38:21.300913.
I've attached some pertinent lines from the trace, showing all the
real SSCH's, real I/O interrupts, and real TSCH's, for the first set of
Virtual SSCH, Virtual I/O interrupt, and Virtual TSCH.
 
  Taking a look at what goes on in that 2:40 is interesting.  Between
the Virtual SSCH & Virtual I/O Interrupt, CP does 83 real SSCH's
(I expected 90, because I think CP is taking MVS's big, long CCW chain
to write 90 tracks of data, and breaking it up into 90 real SSCH's,
one track at a time).  The interesting thing is, CP doesn't do the first
real Start Subchannel for a 5 full seconds after the Virtual SSCH.
What is CP doing in that time?  I dunno.  The real interrupt comes back
in reasonable time, but then CP doesn't do the next real SSCH for another
5 seconds.  This time gap between each SSCH is happening after the
preceeding TSCH and the next SSCH, so it's not DASD hardware that's
causing the delay, it must be CP doing something.  The 5 second gap
eventually lessens to under a second by the time CP gets to the end,
but something is wrong at the beginning.
 
Can you take another look at it?
 
Rick
 
p.s.  I did produce another trace, but haven't looked at what I got yet.
 
 0C33 CPU 0000  VIRTUAL START SUBCHANNEL            TIME 09:35:40.006632
---  249 lines deleted showing 83 SSCH, I/O Interrupt, TSCH triplets. ---
 0C00 CPU 0001  VIRTUAL 370-XA I/O INTERRUPTION     TIME 09:38:20.404103
 0C35 CPU 0001  VIRTUAL TEST SUBCHANNEL             TIME 09:38:20.410917
          |
 8/22/91  |   Robert called back.  Said he opened up an APAR for this
12:45 pm  | problem, VM48628, with the following error description:
          |   An MVS/ESA guest channel program with multiple imbedded
          |   Locate x'47' CCWS is taking too long to complete. The
          |   Locate CCWS are segmented and a Define Extent is inserted
          |   before the Locate.  The problem occurs after the interrupt
          |   when all the subsequent CCWS (not just the CCWS leading
          |   up to the next Locate) are re-translated prior to driving
          |   the next segment, causing a severe performance degradation
          |   in the translation process.
          |
 9/13/91  |   Got a note from Janet Geddes saying she thinks she's found
 9:00 am  | the bug and asking me to do some testing for her.  She also
          | asked what level of HCPMDP (OCO) we have.  I sent a note
          | back saying sure and the level.
          |
 9/16/91  |   Janet sent me an updated HCPMDP.  I tested it and the fix
11:40 am  | brought the MVS IPL time down from 14:10 to 6:04 (mm:ss),
          | which was about what it was in the pre-9101 days.  I sent
          | Janet a note telling her this.
          |
10/10/91  |   Pat Cirone sent a note saying this fix is now available.
 9:00 am  | Who's Pat Cirone?  As far as I'm concerned, this can be
          | closed now.  RETAIN says it's PTF UM19834.
          |
10/31/91  |   Pat called again to ask if the PMR can be closed.  Yes,
 9:50 am  | close the bloody thing.  Leave me alone.
          |
----------+--------------------------------------------------------------
2X260 (CL)|   VMPUSH & VMPOP doesn't restore the trailing blanks in a
 8/15/91  | PF key definition.  SET PF1 JUNK   , VMPUSH PFK, VMPOP PFK,
 4:30 pm  | and the trailing blanks will be gone.  Turns out that CP
George    | doesn't return the trailing blanks in the QUERY PF command
  Knoll   | (you can verify this by TRACE DIAG 8 and VMPUSH PFK or Q PF).
KNOLL at  | This was brought up in 1985 in the old, archived VMPOPUSH
   KGNVMC | FORUM, and somebody said back then that the change team
          | accepted it as a future suggestion.  CP, BTW, does the same
          | thing under HPO 4.2.  Evidently, CP was never changed.
          | I'm resurrecting the issue again.  See what they say now.
          |
          |   HCPQRP is the module that would need to change.  It's such
          | a simple change, too.  One line.
          |
./ R 04301990          $ 4302880 890                  08/15/91 17:42:34
         L     R2,=A(QCNCMND+QCNNOCR) Set command response bits          4301990
          |
 8/16/91  |   George said he talked to Karen Gardner, the level 3 lady
George    | that owns HCPQRP.  She's going to investigate.  Meanwhile,
 2:15 pm  | I gave George the above 1-line update to HCPQRP to pass on.
          | It should help to convince Karen to change the module.
          |
 9/20/91  |   What the hey?  This PMR is no longer in RETAIN!  That's
 2:30 pm  | not suppose to happen!  They can't just delete my problem
2X606 (CL)| without notifying me or nothing.  I called and opened up
          | a new PMR.  How dare they!
          |
 9/24/91  |   George called.  They've opened up APAR VM49629.  Great!
 9:10 am  |
          |   Bill Wright called to just chat, I think.  They aren't
10/24/91  | going with my fix 'cause it affects TTY line processing.
 5:00 pm  | They're going to define another bit in the VMDBK of all
          | places to be used in QUERY PF processing only.  HCPQRP will
          | set the VMDQPF bit in VMDMISC1 and HCPQCN will check it.
          | If it's on, QCN won't delete trailing blanks.  Isn't that
          | a joke?  Seems all the other parm bits in R2 to QCN are
          | being used.  It may change by the time the fix comes out,
          | so we'll see.
          |
          |   VM49629 is still open as of 1/23/92.
          |
03/05/92  |   Bill Wright sent notes to arrange a conference call this
11:30 am  | morning with him, his manager, and her manager, Bill Hume,
Bill      | who said he "owned all of CP."  They wanted to talk me into
  Wright  | accepting a WAD closing for VM49629 with the assurance it
WRIGHTWH  | will get fixed in "the next release", which after being
at GDLVM6 | asked, said was ESA 2.0.  Basically, I said fine, the only
          | problem being we're about to go to ESA 1.1 and I'd like
          | this fixed there.  Bill Wright said after the phone call
          | that his 2.0 fix will work on 1.1 and he'll ship me an
          | unofficial 1.1 fix.  Great.
          |
----------+--------------------------------------------------------------
123X2 (CL)|   Got a PZE001 ABEND on VMD this morning.  Looked in RETAIN
 8/26/91  | and VM48630 (still open) looks likely.  NET was the active
11:30 am  | user and the last lines on NET's console were
Bill      |   CTCA 0C11 DROPPED FROM RSCSV3T 0C11
Stewart   |   CTCA 0C11 COUPLED BY RSCSV3T 0C11
          | VM48630 talks about HCPCTC simulating a virtual CTCA and
          | VM42870 changing the way it works.  Specifically, HCPCTC
          | now turns on VMDRSTAT,VMDSIMWT and calls HCPENDC0 which
          | turns it off.
          |
          |   What seems to have happened is David was logged onto
          | RSCSV3T and IPL'd GCS, which probably reset/dropped/uncoupled
          | its virtual CTCA with NET.  This was an asynchronous
          | operation as far as NET is concerned, so if NET was in
          | SIMWAIT before (which is likely - NET is doing CP commands
          | all the time), this asynchronous CTCA operation is turning
          | off VMDSIMWT unconditionally.  HCPCTC should not do this.
          |
          |   The trace table shows an I/O interrupt coming in from a
          | paging device.  The start subchannel for that is long gone.
Jennifer  |
Moriaty   |   Jenny guessed like I did that taking off VM42870 and its
 8/26/91  | P.E. APAR, VM46822 would be a good idea, but I said that I
          | could have guessed that and that I wanted to talk to
John      | someone who was more technically aware of the problem than
Harris    | we were.  Like the guy working on VM48630.
 9/03/91  |
 2:20 pm  |   John called to discuss this, but I was on the phone and
HARRISJF  | he wasn't there when I called back.  I sent a note.
  at      | John responded the next day with "Yes, take off VM42870 and
GDLVMA    | VM46822."  So, I did.
          |
 9/16/91  |   John (Dukes?) called, but didn't say what he wanted.
12:30 pm  | He called back.  He obviously wasn't aware that John Harris
          | and I had already communicated and John Harris had already
          | answered my question.  Evidently, John Harris didn't update
          | my PMR.
          |
----------+--------------------------------------------------------------
2X520 (CL)|   Marty found a problem with the GLOBALV LIST command.
 9/12/91  | The output of the GLOBALV LIST command is 1 space, followed
 5:30 pm  | by the variable name, an equal sign, then the contents of
Patrick   | the variable itself.  For example,
          |  RICK=the value itself
          | If the length of all that is longer than 130 characters,
          | the line is truncated.  An exec to demonstrate this is
          |    /* */
          |    permaccess = copies('a',144)
          |    "GLOBALV SELECT TOOLCNTL PUT PERMACCESS"
          |    "GLOBALV SELECT TOOLCNTL LIST PERMACCESS"
          |
          |   What's happening is that DMSGLO (the GLOBALV command) is
          | SVC-calling TYPLIN (DMSCWR) to type a line.  The length is
          | correct, but DMSGLO needs to turn on a bit to tell DMSCWR
          | that this is (or could be) a long line.  Some update to
          | DMSGLO like
          |   ./ I 23400000          $ 23401000 1000
          |            MVI   GLOTYPB0+1,X'10'  .
          | should do the trick.  This will unconditionally tell DMSCWR
          | that the line is long, whether it is or not.
          |
          |   This bug appears in CMS Release 4, 5.5, 5.6, and 8.
 9/13/91  |
10:00 am  |   Liz called and quickly grasped the situation.  She'll
Liz       | investigate a bit and get back to me (probably quickly).
  Holland |
HOLLANDE  |   She did - at 11:15.  She agrees there's a bug and she's
   at     | opening an APAR, VM49325.  She'll also check the other
ENDVMFE0  | CMS releases.
Dep. 99qg |
10/22/91  |   Just got a letter stating that VM49325 is being closed and
          | all they're doing is changing the manual and help file to
          | document a 130-byte restriction.  Amazing!  I give them the
          | fix, it's a one-liner, and they still choose to simply
          | document it rather than fix it.  I called in again to appeal
          | the resolution and also to complain since I was never
          | notified.  And now it's too late 'cause the original PMR has
          | closed over 30 days ago.  I gotta open another PMR, 2X972.
          | See PMR 2X972 below.
          |
----------+--------------------------------------------------------------
2X972 (CL)|   A reopening of 2X520 to appeal the closure of VM49325.
10/22/91  | This was to get the GLOBALV LIST command to type out the
 4:00 pm  | complete line if the variable name+value > 130 characters.
Patrick   | Those guys closed this APAR after I gave them the 1-line fix.
          | Isn't that amazing?
10/22/91  |
 5:00 pm  |   Debbie took the time to patiently explain to me the APAR
Debbie    | process between level 2 (her group) and the Change Team.
  Wells   | Level 2 handles the PMR and if need be, opens an APAR.
Dep. 99qs | Once an APAR gets opened, they like to close the PMR, but
Endicott  | will keep it open if the customer insists.  The Change Team
          | is the one responsible for answering the APAR.  Once the
          | Change Team decides on how to close it, they notify level 2,
          | who'll then contact the customer and close the PMR if it's
          | still open.  Level 2 does not decide how to close APARs, so
          | if I want to appeal an APAR (like I wanna do), I gotta send
          | a note to the CMS Change Team manager, Richard Lloyd,
          | LLOYDRIC at ENDVMFE0.  I sent him this nice note.
Date: 23 October 91, 12:06:05 PDT
From: Rick Jasper               8-457-2731           JASPER   at ALMVMD
      VM Systems Support
To:   LLOYDRIC at ENDVMFE0
 
Richard,
 
  I understand you're the CMS Change Team manager and the one to appeal
APAR closures to.  I identified and reported a trivial problem with the CMS
GLOBALV command truncating long lines sent to the console.  The following
exec demonstrates
/* */
junk = copies('a',200)                 /*  Make a long variable,  */
'GLOBALV SELECT TOOLCNTL PUT JUNK'     /*  save it via GLOBALV,   */
'GLOBALV SELECT TOOLCNTL LIST JUNK'    /*  and now type it out.   */
 
When I called the problem in, I supplied the following one-line fix to
DMSGLO that I've tested and have running on my system now.
./ I 23400000          $ 23401000 1000
         MVI   GLOTYPB0+1,X'10'  .
DMSGLO calls TYPLIN by creating a plist and SVC-ing to TYPLIN.  This fix
simply turns on a bit in the TYPLIN plist that tells TYPLIN this line is,
or could be, a long line (greater than 130 characters).
 
  This problem got assigned APAR number VM49325, which recently closed not by
distributing this fix, but by merely documenting this "restriction" to the
GLOBALV command.  This I find amazing!  Here's a one-line fix to a problem
and "they" decide to call it a restriction and document it, rather than fix
it.  The rationale to document rather than fix escapes me.  Here's an excerpt
from the APAR summary page,
        The CMS preferred interface macro to write to the terminal,
      LINEWRT, also has the 130 byte restriction.  If it was possible
      to change the GLOBALV interface to eliminate the restriction,
      then that would be the course of action.
This is puzzling for two reasons.  First, DMSGLO doesn't use LINEWRT.
Like I said, it creates the plist and calls TYPLIN directly.  So LINEWRT's
130-character restriction is irrelevent.  Secondly, the last sentence
implies that if it was possible to fix this, they would.  It is possible!
I gave them the fix.  I gave it to level 2 at least.  Perhaps the fix didn't
make it to the Change Team?
 
  Can you please have another look at this problem and either get it fixed or
explain to me the rationale to not fix it?  This isn't a high priority item
or anything, it's just a slap in the face of the current IBM buzzword, MDQ.
 
Rick Jasper
          |
10/28/91  |   Got a call from some nice lady (I didn't catch her name nor
 9:40 am  | which organization she worked for - I should have) explaining
          | what happened with VM49325.  She kinda meekly explained that
          | they didn't really look at the code.  They recently had
          | another APAR close by doing the same thing - documenting the
          | 130-byte length restriction on some command, and they thought
          | this was the same thing.  After my note above, they realised
          | their error and are now agreeing to fix it with my fix.  She
          | also said they never saw my fix originally.  Sounds like
          | all's well.
          |
10/30/91  |   Got a note back from Dick Lloyd saying they'll back out
 9:00 am  | VM49325 with VM50425.
          |
11/21/91  |   RETAIN says VM50425 & UM20323 are both closed.  Looking at
11:30 am  | their update to DMSGLO (DMSGLO A50425DS), it's interesting to
          | note they changed the update slightly, preferring to MVI to
          | an equated symbol rather than to a literal, i.e.
          |                MVI   GLOTYPB0+1,LONGLINE
          |       LONGLINE EQU   X'10'              LINE GREATER THAN 130
          | rather than    MVI   GLOTYPB0+1,X'01'
          |
          |   I got the fix via DLL.
          |
----------+--------------------------------------------------------------
3X259 (CL)|   Called to get the problem description from VM41583 read to
11/14/91  | me.  In RETAIN, VM41583 is IBM Confidential.  This is the
11:15 am  | 1-line update to HCPLOG that returns you to the logo after
          | entering a bad password.  This broke Roy's send-a-warning-
          | to-the-user-warning-him-that-too-many-bad-password-attempts-
          | will-lock-the-userid code, that I'm considering backing out.
          | First though, I want to understand why it was changed.
          |
          |   PID changed LGO 'cause it wasn't forcing off the userid
          | after the limit of invalid password attempts was reached.
          | Since our password limit is 0, LGO wants to force off the
          | user after the first bad attempt.  We have it set to zero
          | 'cause we wanna count the number of bad attempts and take
          | action (see PWVIO EXEC on the SYSPROG disk) ourselves after
          | a different threshold is reached.  In other words, the
          | take-drastic-measures action is done in an exec, not in CP.
          | What we need is two threshholds, which is what (I think)
          | VM/ESA has, the first to warn, the second to take more
          | drastic action.  I guess I'll just wait 'till VM/ESA to fix
          | this.
          |
----------+--------------------------------------------------------------
3X344 (CL)|   Called in two problems with VM47475, Mark Harwood's
11/21/91  | problem with responses to CP commands not showing immediately
 2:30 pm  | as it did before VM47475, and another I found.  If your CP
          | command from within XEDIT has more than a screen full of
          | data, typing in say CP Q N from XEDIT causes a bunch of
          | beeping, but then you never return from CMS's Diagnose 8.
          | I verified this by doing a DMPVMDBK RAJ after doing a
          | CP Q N command from XEDIT.  My PSW pointed to right after
          | the diagnose 8 instruction at DMSXCM + x730 (00E8DEC0).
          | Your terminal is reset (that is, you don't have input
          | inhibited), but your CP command is still on the XEDIT
          | command line.  Since you never returned from the Diag 8,
          | XEDIT hasn't refreshed the screen.  The only way out of
          | this is to hit PA1, which the first time does nothing but
          | turns on input inhibited, hit reset, then hit PA1 a second
          | time.  This clears the full-screen application (XEDIT) and
          | gives you the first screen of CP data, but when you clear
          | the screen, you only get the first line of the second page
          | of your CP command.  It's as if CP took one of your PA1's
          | and interpreted it as halt-CP-output.  Not right.
          |
Bob       |   Talked to Bob, did a TRSOURCE trace for him
 Maikels  |       TRSOURCE ID TEST TYPE IO IOD 500 DEV D65  (RAJ's tube)
MAIKELS   |       TRSOURCE ENABLE ALL
   at     |       --- do CP Q N from XEDIT, hit PA1, reset, PA1, PA2
KGNVMC    |       TRSOURCE DISABLE ALL
          |       TRACERED 1590
          |       RD = CP TRACE, then SF CP TRACE to Bob
          | Bob's going to digest it and get back to me.
          |
          |   I also found VM50757, which looks like an APAR opened up
          | against VM/ESA complaining about similar things.  Don't know
          | if they're related or not.
          |
11/22/91  |   Bob's finally convinced (he wasn't last night) that TERM
12:45 pm  | BREAKIN is broken according to the CP Command Reference.
Bob       | It says "GUESTctl specifies that high-priority warnings from
 Maikels  | CP and user-requested CP functions still break in ..." and
          | after VM47475, user-requested CP functions aren't breaking
          | in.  I let him use JASPER0 to see for himself how it works
11/25/91  | since their VM system doesn't have VM47475 on.
 8:45 am  |
Bob       |   Bob says he's opened up VM50911 for this problem.
 Maikels  |
          |   Marty found a problem that I believe is another symptom
11/27/91  | of VM47475.  I sent a note to Bob Maikels asking whether he
          | wanted this piggybacked on this PMR or whether I should
          | open another.
          |
12/02/91  |   Bob says to open another PMR.  I think that Bob thinks
 2:20 pm  | this isn't related to VM47475.  I think it is.  Oh, well.
Bob       | I'll open another PMR.  See 3X418 below.
 Maikels  |
          |   VM50911 is still open as of 1/23/92.
          |   VM50911 is still open as of 3/05/92.
          |
 3/17/92  |   Laura called to verify that we had VM48444 installed.
12:50 pm  | She's convinced this is the APAR in error, not VM47475 like
Laura     | I had guessed, and just wanted to make sure we had it
 Cramer   | installed before she updated the PMR.  Just for the record,
          | I installed both VM48444 and VM47475 on 10/30/91.
          |
 7/19/92  |  Received the following note from Kathy McFarland while I
          | was out with my hip operation.  Sent her a note explaining
          | I was not going to install any more service on XA 2.1,
          | that I was planning on going to ESA sometime soon.  If she
          | wanted to, she could close the PMR.
          |
Date: 14 July 92, 13:23:02 EDT
From: KATHYMC  at KGNVMC
To:   JASPER at ALMADEN
Re: PMR 3X344
 
Hi Rick,
  Kathy McFarland from the level 2 support group here. Since I couldn't
reach you by phone I thought I'd send a note requesting status on the above
mentioned PMR.
  The PMR referenced a problem of the command line not clearing in XEDIT
when a CP command response is more than 1 page. The line will not clear until
the CP response is viewed. Apar VM50911 was opened for this problem.
  The apar was ordered for you by a co-worker of mine on 7/7/92. Did you
receive the fix? If so, were you able to apply it and did it resolve the
problem? Is it alright if we close this PMR?
  Thanks and Regards, Kathy
          |
----------+--------------------------------------------------------------
3X418 (CL)|   Called in problem Marty found where the result of a CP
12/02/91  | command done via Diagnose 8 is getting the logon data in the
 5:15 pm  | command response buffer.  I believe this to be due to APAR
          | VM47475.  The following exec demonstrates the problem.
          | To run the exec, have a file in your reader, say spool file
          | number 1234.
          | -  Say DOIT 1234.  The exec collects the tag information on
          |    the specified file, then should run forever unless the tag
          |    information changes or you get a bad return code on the
          |    tag command.
          | -  Disconnect.
          | -  Reconnect.  The next tag command will not get the expected
          |    result, causing the loop to quit.  What you get back from
          |    the tag command is the log information when you
          |    reconnected, possibly suffixed by the tag information.
          |    I've seen it both ways, that tag info there and not there.
          |    I'm queued to level 2.
/* */
arg nnnn
if nnnn = '' then do;say 'You gotta supply a spool file number.';exit;end
'EXECIO 1 CP (VAR DATA STRING TAG QUERY FILE' nnnn
if rc^=0 then do;say 'Bad rc ('rc') on initial TAG QUERY command.';exit rc;end
 
do forever
  'EXECIO * CP (STEM OUT. STRING TAG QUERY FILE' nnnn
  If rc^=0 Then Do
    Say 'Bad rc ('rc') on TAG command.'
    Say 'Tag data was >'data'<'
    Do i=1 to out.0
      Say 'Tag info is >'out.i'<'
    End
    Exit rc
  End
  if out.1 ^= data then do
    Say 'Data mismatch.'
    Say 'Tag data was >'data'<'
    Do i=1 to out.0
      Say 'Tag info is >'out.i'<'
    End
    Exit 12345
  End
End
          |
12/03/91  |   Suresh called and I sent the above exec.
10:10 am  |
Suresh    |
Krishna-  |
  moorthy |
V$I00224  |
at KGNVMC |
          |
Date: 5 December 91, 15:29:29 EST
From: BIMAL H. SHAH             292-8536             BIMAL    at KGNVMC
To:   JASPER at ALMADEN
 
Re : PMR 3x418
 
Rick,
 
I was looking into the problem we discussed on Tuesday. Also, I discussed
that with couple of my colleague. Here is our findings.
 
In XA 2.1 HCPQCN handles o/p to term or buffer. The way it is coded that
when cp some o/p for virtual machine, it first looks for DIAG 8 buffer.
If it is defined that it puts the o/p data in the buffer and exit.
(Ref. GENERAL COMMENT 1 in prolog of HCPQCNWT).
I think this is the reason why your exec fails on XA 2.1 system.
 
For ESA 1.1 we have totally re-written QCN and also changed a logic
quite a bit and problem you see via this exec doesn't appear.
 
Please let me know your comments on this findings.
 
Thanks........ Bimal Shah (CP LVL 2)
 
          |   I called Bimal back and discussed this.  One of the first
          | things QCN does in the QCNWT entry point (after the label
          | NOTDROP) is check a bit in the VMDBK to see if there's a
          | Diagnose 8 buffer or not.  So it would seem all CP output
          | will go to that buffer regardless of whether it came from
          | the CP command being diag 8'd or not.  However, it looks
          | like they could turn on the QCNNORSP (x'10') bit in R2,
          | byte 2 and bypass that check.  This is what I told Bimal.
          |
          |   I then tried modifying CP myself to send those reconnect
          | messages with QCNNORSP on, but after looking at it a bit,
          | it seemed I was opening a whole can of worms.  There's
          | hardly any QCN calls with QCNNORSP on.  Seems like there
          | should be.  Consider the logon/reconnect/logoff/attach/
          | detach msgs that the operator userid gets.  Would any of
          | those go into a diag 8 buffer?  I wonder.  I should go run
          | my tag-looping exec under PROP and see.
          |
Date: 6 December 91, 19:41:39 EST
From: BIMAL H. SHAH             292-8536             BIMAL    at KGNVMC
To:   JASPER at ALMADEN
 
Rick,
 
I am sorry I couldn't got back to you earlier today. I looked in around
the area in QCN you pointed out yesterday in our last phone
conversation.
It looks like that QCNNORSP (Response is not a cmd response) bit should
be on while reconnecting and that way o/p data will go to display term.
 
Anyway I created an apar VM51031 to address this problem.
 
Please queue in when ever you need a status on it.
 
Thanks........ Bimal.
          |
 1/10/92  |   Got a call from somebody saying this APAR is closed.
11:10 am  |
          |
 1/21/92  |   COR tape VM5092 is in house, but it pre-reqs a bunch of
          | PTFs that I don't have installed and probably won't ever
          | install since VM/ESA is around the corner.
          |
----------+--------------------------------------------------------------
3X553 (CL)|   While poking around in HCPQCN, I noticed a TM instruction
12/16/91  | that was checking the wrong byte.  Just above the label
 9:45 am  | NOTDIAG, there's a TM SVR2MSG,QCNVMIO.  That should be
Mark      | testing the SVR2CR byte.  They're shooting me through to
          | level 2.
Tasha     |
Beretvas  |   The level 2 person is going to investigate.  She seemed
TASHA at  | convinced it's a problem.  (A while later)  Tasha's going to
  KGNVMC  | open an APAR, send me the number, then close the PMR.
          |
Tom       |   Tom says it'll be APAR # VM51116.
          |
          |   VM51116 is still open as of 1/23/92.
02/05/92  |
 2:00 pm  |   Tape arrived today with the fix on it.  I threw it away.
          |
----------+--------------------------------------------------------------
3X923 (CL)|   Called to get the problem description of VTAM APAR VM40404
01/30/92  | read over the phone.  It was one of those "Call the Support
 2:20 pm  | Center" problems so we couldn't read about it in RETAIN.
Ramish    | Ramish said it was to fix a problem with possibly displaying
          | the password during password prompting (my guess is the
          | redisplay after hitting the clear key wasn't setting the
          | input field).  Ramish said this APAR was reported against
          | VTAM 3.2.1 and we have VTAM 3.3.  He couldn't confirm
          | whether or not this was in the 3.3 base or not.  He queued
          | me to VTAM level 2.
 4:50 pm  |
Dale      |   Dale said VM40404 was included in the 3.3 base.
          |
----------+--------------------------------------------------------------
4X224 (CL)|   When I came in this morning, ALMVMA was sick.  If you did a
03/02/92  | QUERY FRAMES, the LOCKRS count on the bottom line showed that
 2:50 pm  | over 8,000 of it's 16,000 pages were "currently locked for
Dave      | I/O operations"  (the 3081 has 64 meg of real storage = 16K
          | pages).  I couldn't get onto RETAIN, so I called it in.
          | Dave found VM47232/UM18956 that talks about an XA-mode
          | virtual machine doing Diagnose 98's to lock pages, but not
          | doing the corresponding Diagnose 98/subcode 0 to unlock them.
          | Dave says it's on 9201 which just arrived last week, so I'll
          | take a look at it.  I wrote a quick and dirty exec to scan
          | the VMDBK's of all logged on users, and on VMA there was only
          | two Diagnose 98 users, PVM and TCPIP, both of which are in
          | 370-mode.  I don't think VM47232 is the right PTF.
          |
          | Finally was able to logon to RETAIN myself and found
          | VM51268/UM18999, which sounds like a perfect match.  It
          | talks about 3 places in HCPIUH that checks the condition code
          | after calling HCPPTFLK.  The problem is HCPPTFLK doesn't set
          | the condition code.  Since it was 3 branch instructions, I
          | came up with another quick and dirty exec to zap CP until I
          | could replace the nucleus.  Here are both execs in case I
          | find other uses for them.
          |
/* */
parse value diag(8,'QUERY NAMES') with users
do until users = ''
  parse var users line '15'x users
  parse var line u1 . ', ' u2 . ', ' u3 . ', ' u4 .
  Call DoUser u1
  Call DoUser u2
  Call DoUser u3
  Call DoUser u4
End
Exit
DoUser:
  arg who
  Parse Value diagrc(8,'LOCATE' who) with RC . . . VMBLOK@ '15'x         .
  VMBLOK_@ = Strip(VMBLOK@)
  If RC = 21 | RC = 40 | RC = 45 Then Return
  If RC = 1 | RC = 16 Then
  Do
    Say 'You don''t have the correct priviledges to run this EXEC.'
    Exit 0
  End
 
  addr = d2x(x2d(VMBLOK@) + x2d(46C))     /*  Get VMDX98CT.  */
  Parse Value diag(8,'D H'addr) with . +11 count +8 .
 
  If count='00000000' Then Return    /*  No diag 98 i/o going on??  */
  say who'''s count is' count'.'
Return
          |
          |
          |
/*  FIXCP EXEC: Fix HCPIUH per VM51268/UM21079.  Fixes creeping LOCKRS */
/*              counts in the QUERY FRAMES response, indicating those  */
/*              pages are unusable 'till the next IPL.                 */
 
Parse Value diag(8,'CP Q CPLEVEL') with CP_Level ',' .
If CP_Level ^= 'VM/XA SP Release 2.1' Then Do
  Say 'This only works on a VM/XA 2.1 system.'
  Exit 0
End
 
Parse Value diagrc(8,'LOCATE HCPIUH') with RC . . . HCPIUH_Address .     .
If RC ^=0 Then Do
  Say 'You don''t have the correct priviledges to run this EXEC.'
  Exit 0
End
 
addr = d2x(x2d(HCPIUH_Address) + x2d(7AC))
Parse Value diag(8,'D H'addr) with . +11 data +8 .
If data = '4770C81E' Then Do
  cmd = 'STORE H'addr '4700C81E'
  Say cmd
  cmd
End
 
addr = d2x(x2d(HCPIUH_Address) + x2d(900))
Parse Value diag(8,'D H'addr) with . +11 data +8 .
If data = '4770C912' Then Do
  cmd = 'STORE H'addr '4700C912'
  Say cmd
  cmd
End
 
addr = d2x(x2d(HCPIUH_Address) + x2d(928))
Parse Value diag(8,'D H'addr) with . +11 data +8 .
If data = '4770C93A' Then Do
  cmd = 'STORE H'addr '4700C93A'
  Say cmd
  cmd
End
          |
----------+--------------------------------------------------------------
8X665 (CL)|   This was Wayne's PMR having to do with CP output going into
01/06/92  | a diag 8 buffer, or some such thing.  I dunno.  Anyway, Wayne
George    | gave me a COR tape, VM5090, that had a jillion other PTF's,
  Knoll   | co-reqs and pre-reqs galore, and looking into it, there were
          | some PTF's that had open PE's against them.  And I couldn't
          | just pull out the 1-2 PTF's Wayne wanted.  Too convoluted.
          | So, I just told Wayne to forget it.  I told George he could
          | close the PMR (or that's what Wayne told me I did anyway).
          |
----------+--------------------------------------------------------------
4X751 (CL)|   We've been getting errors from EREP for months.  It's about
 4/30/92  | time I (or somebody) looked to see why.  When running the
11:11 am  | EREP with the EVENTSUM CPEREP input file, we got lotsa msgs
          |    IFC253I EXIT MOD IFCBDAS1 COULD NOT OBTAIN MDRDASD DATA
          | Called the Support Center.  They shipped me the latest and
          | greatest, installed it, and I still get the same thing.
 5/01/92  | Time to call it in again.  For the record, we've got
          | a version of EREP 3.5 that I stole from John Myers (MYERSJH
          | at YKTVMV) from the VCEA 192 disk.  Level 1 forwarded my
          | call to Level 2.  Level 1 did say you could add DEBUG=(17)
          | to the EREP parms (in the EVENTSUM CPEREP file) to see which
          | sense bytes are triggering the messages.  I'll try that.
          |
          |
----------+--------------------------------------------------------------
4X788 (CL)|   This is the PMR that Rick Haeckel called in for Roy.
5X025     | The original PMR, 4X788, got closed 'cause it was placed on
06/09/92  | the wrong queue (what's TNM?) and Roy said he didn't know
          | anything about that.  The second one is the one that's open,
          | but the Support Center can't get ahold of Roy and can't leave
          | a message 'cause his voicemail is full.
----------+--------------------------------------------------------------
6X293 (CL)|   After LPAR-ing our 3090-600S, SMART's processor utilization
10/29/92  | numbers show only 470% busy, with a wait time of 130%.  Even
 3:40 pm  | the VMPRF reports (PRF002 on XAREP's 201 disk) show only 75%
          | busy (was 93% busy when not LPAR).  These numbers don't jibe
          | with CP's Indicate command or with the SAD display.  Both
          | show all processors 100% busy.  I couldn't explain it, so I
          | decided to have the Support Center explain it to me.
          |   BTW, we've got RTM/SF 1.4.0, pp# 5798-DWD, and it's pretty
          | current.  I found 6 fixes in Retain that we don't have,
          | GC04376, GC04552, GC04618, GC04769, GC04803, and GC04859,
          | none of which address this problem.
          |   Turns out the Support Center wasn't much help.  I put an
          | append in the PRSM FORUM on IBMVM and got my answer the next
          | morning, which was also the answer the Support Center read to
          | me.  Basically, we gotta get the "SIE Under SIE" RPQ, 8P1367
          | and 8P1368 (aka "Region Relocate Facility").  Either that or
          | run ALMVSA V=R under VM.  I like the second option better.
          |
----------+--------------------------------------------------------------
8X656 (CL)|   EREP has been choking lately with this message
11/12/92  | IFC264I UNABLE TO IDENTIFY DASD DEVICE WITH OBR CODE = 2023
 9:12 am  |                                                IN RECORD;
          |
02/22/93  | I don't remember how this was resolved.  I think I got some
          | service which fixed it ok.  I forget.
          |
----------+--------------------------------------------------------------
2X326 (CL)|   Don Peter called my attention to a problem with the Batch
02/22/93  | machines.  Three of the slaves (BATCH2, 3, & 6) were offline.
 3:40 pm  | The BATCH console log showed all of them going offline on
          | 02/21/93 at 00:08:00 - 00:10:00.  Don't know why.  The only
          | msgs on the BATCH console were a job got started and 2-4
          | minutes later, BATCH forced off the batch slaves with this
          | msg:  DGRMAI019W Task BATCHn put offline - did not start job
          |
Tom       |   I've got BATCH 2.1.0 installed, program product # 5684-137.
  Gignac  |
GIGNACTO  |   Tom's says this msg is misleading.  The job could have
   at     | started and maybe just released the disk the DGRTASK is on,
ENDVMFE0  | which is BATCH's 29E disk, the Batch slave's 192, D-disk,
8-853-5396| the way we have things set up.  Don Peter says Chris
          | GUDEMAN (the user) was using BOUT and probably submitted
          | a flood of jobs at the same time using = in FULIST.
          | Don says his BOUT EXEC leaves the 192 & D-disk alone.
          |
          |   Tom's going to check with his Change Team and get back
          | to me in a couple of days.  Another option we have is to
          | turn tracing on in the DGRTASK EXEC on BATCH's 192 disk.
          | To do so, just set dbg=1.  Doing this though, will send
          | three extra console files to the user for each job.
          | Maybe I'll just turn it on for GUDEMAN if it's between
          | 12:00 and 1:00 in the morning.  It's REXX, so you can do
          | anything you want.
          |
          |   I finally decided the problem was probably due to the
          | batch slaves not getting the read link to their 192 disk
          | for some reason, so I told Tom Gignac to close this PMR.
          |
----------+--------------------------------------------------------------
3X981 (CL)|   Called to get the latest service & bucket for VM/ESA R2.0.
04/08/93  | They're sending out the 9304 tape and bucket.  They've got
12:45 pm  | an interesting new phone routing system for VM calls,
          | Press 1 to order a specific item (which I did)
          |       2 for I/O, DDR, or Install
          |       3 for console services, LDEVs, IUCV, logon/off, or DIRM
          |       4 for storage, spooling, scheduling, DVF, or IPCS
          |       5 for command, monitor, smart, rtm, vmprf, or vmmap
          |       6 for CMS, SES, RSCS, or GCS
          |       7 If you don't know which one to choose,
          |    or 8 to replay the choices.
          | The tape arrived the next day (how 'bout that?).
          |
----------+--------------------------------------------------------------
4X336 (CL)|   I couldn't build my HCPALM MACLIB (the one for locally-
04/19/93  | modified macro/copy files).  I also get the same error
 3:00 pm  | rebuilding any of CP's maclibs.  The command I'm using
          | (from the Service Guide, pg 7-8) is
          |       VMFBLD PPF ALMADEN CP HCPALM HCPALM (SERVICED
          | The error message I get is
          |       VMFBLD2222E Object HCPALM is not defined in build
          |                                         list HCPALM EXC01901
          | I'm queued to level 2.
          |   Meanwhile, I tried tracing the VMFBLD EXEC and it looks
          | like it wants is an :OBJNAME/:EOBJNAME pair for the
          | MACLIB name.  I added that to HCPALM EXC01901 (that ft is
          | a whole nuther problem I got straight via the VMSES FORUM)
          | but now I get
          |      VMFBLD2182I Identifying new build requirements
          |      VMFBLD2182I No new build requirements identified
          |      VMFBLD2180I There are 0 build requirements remaining
          | Sounds like I gotta put something in some build table or
          | another that'll tell SES to go ahead and build HCPALM.
          | I gotta ask them when they call back.
          |   While I'm at it, I might as well get all my SES questions
          | answered.
          | 1)  Will SES notify me to rebuild HCPALM when a macro/copy
          |     file change, like it will for HCPOM1?
          |     --- Yes, it should.                                ---
          | 2)  Should I create a VMSES PARTCAT for the localmod 2C4
          |     disk?
          | 3)  What ft-abbreviations should I use in the VMFSIM LOGMOD
          |     command as shown on pg 7-3 in the Service Guide?
          |     For example, I add a msg, so I modify HCPMES REPOS and
          |     HCPMXRBK.  Or I add a module to the CP loadlist,
          |     HCPMDLAT.
          | 4)  What are the possible states for an object in the
          |     Build Status Table (VM SRVBLDS)?  Perhaps the "No new
          |     build requirements identified/remaining" msgs above
          |     is because my HCPALM MACLIB isn't in a particular state.
          |     --- See theVMSES/E Introduction & Reference,       ---
Joe       |     --- page 735-736.  The "No new" msg was indeed     ---
 Gregor   |     --- because you didn't follow the Service Guide,   ---
8-853-5516|     --- page 7-5, where it said to update the "Select  ---
GREGORJL  |     --- Data File".  That's where VMFBLD goes to see   ---
  at      |     --- the last date a part was serviced, to compare  ---
ENDVMFE0  |     --- it with the date it was last built (kept in    ---
 4/20/93  |     --- the Build Status Table, VM SRVBLDS).           ---
10:00 am  |
          |  Joe was able to set me straight.  First of all, the VMFBLD
          | command should have been VMFBLD PPF ALMADEN CP HCPALM
          | without the second HCPALM.  That second HCPALM evidently
          | is if you just want to rebuild one member (object) of the
          | maclib.  Leaving it off says you want to rebuild the whole
          | thing.
          |  Secondly, the "SERVICED" option needed to be "ALL" since
          | I didn't have the 6VMVMB20 $SELECT file changed, per the
          | Service Guide, page 7-5.
          |
----------+--------------------------------------------------------------
4X524 (CL)|   The CMS version of ICKDSF Release 14 is giving me random
 4/23/93  | program checks.  The message is DMSITP141T Program interrupt
 4:25 pm  | X'15' occurred at 000367EE in routine ICKDSF.
          | Program interrupt code x'15' is new in XA, meaning an
          | operand exception occurred.  This is on a SSCH instruction.
          | Now there's only two operands for a SSCH instruction,
          | GPR1 "contains the subsystem identification word, which
          | designates the subchannel that is to be started," and
          | the base+displacement points to the ORB.  G1 is zero when
Leslie    | it fails (it's 00010007 when it works), so that must be
  Barton  | what's wrong.  I'm queued to level 2.
8-583-5433|
          |   This is against devices 4206 or 4207, which is a bad HDA
Dave      | scheduled to be replaced next week (maybe I should tell them
  Smith   | to hold off).  The DSF command was
8-583-5429|        INIT UNIT(4206) NVFY VOLID(EA4206)
Both in   |
Bldg. 89  |   Dave thinks he's got the fix.  PTF UN32524.  He's sending
 4/26/93  | me the updates now.  DSF is serviced with replacement text
 2:22 pm  | decks, so I had to run the ICKTXT EXEC to rebuild the txtlib,
          | then the ICKMOD EXEC to rebuild the ICKDSF MODULE.  Both
          | execs are on MAINT's D00 disk.  This fixed the problem.
          |
----------+--------------------------------------------------------------
5X540 (CL)|   Called in the following program check from EREP.
05/24/93  |       DMSITP141T Operation exception occurred at 0002208A
 3:14 pm  |                                         in routine IFCEREP1
          | happening when CELOG runs CPEREPXA with the HISTORY CPEREP
Roy       | data file which has only ACC=Y and TABSIZE=999K in it.
          |   The Support Center said that UV54018 was suppose to fix
          | this, but according to 5654260J MEMO on EREP's 202 disk
          | (the current disk), I should have this PTF already on.
          | Looking around though at different files, it appears I
          | don't.
          |     - ERPTFLIB TXTLIB has 16 members in it that start
          |       with UV, none of them are UV54018.
          |     - The I5654260 SRVLOG35 file only says VM PUT 0000,
          |       implying I've never put service on EREP.  That
          |       doesn't sound right 'cause I just called EREP in
          |       a few months ago and I installed service back then
          |       (didn't I?  My notes are unclear what I did.).
          |     - Roy said that there should be a ERPTFLIB TXTnnnnn
          |       file around that shows the last PTF applied to
          |       ERPTFLIB, ala SES PTF-numbered files.  I don't
          |       have one of those files.
          | Roy also said to read the information apar, II04846,
          | to see about installing EREP service.  I did and extracted
          | what it had in EREP MYQMARK.
          |
          | It looks like I may never have put on service.  Anyway,
          | Roy's sending me the latest EREP PTF, UV90723.
          |
 5/26/93  |   Tape arrived.  It only replaced ERPTFLIB TXTLIB and fixed
10:00 am  | everything.  I had to trim down the EREPVMA DATA file on
          | EREP's 191 disk 'cause it had duplicate records (due to
          | the DAILY EXEC failing before it cleared the ERDS, thus
          | the next time it ran, it would recombine the ERDS stuff into
          | the accum file) and extra weeks of data in it (due to the
          | DAILY EXEC failing before it called its "Purge_Old_Records"
          | routine).
          |
----------+--------------------------------------------------------------
6X124 (CL)|   I'm getting the same error message from EREP 3.5 as I was
06/16/93  | getting back last November 12, 1992 (see 8X656), namely
 9:15 am  | IFC264I UNABLE TO IDENTIFY DASD DEVICE WITH OBR CODE = 2023
          |                                                IN RECORD;
          | I don't remember what happened last November, but I just
          | put on supposedly the latest service to EREP last month.
          | The bad record in the CELOG console listing shows the devices
          | to be 876 & 877 (in columns 58-59), which are 3380-K' boxes.
          | I'm queued to EREP level 2 in Tucson.
Steve     |
  Kurtz   |   I sent Steve a copy of the EREP console showing the
SEKURTZ   | record causing the error and Steve says there's a byte in
  at      | the header portion of the record that shows the number of
TUCVM3    | sense bytes, which should be x'18' or x'20', but is x'00'.
06/16/93  | Steve says the problem is in the way CP is building the
 1:40 pm  | record.  It's a CP bug that he thinks is already fixed by
          | UM20644, which came out in PUT 9202 and we don't have on.
          | I told Steve to close the PMR and I'll either put it on or
          | (more likely) just ignore the error until we get to VM/ESA.
          |
          |   I got the fix and it was just one small update to HCPDUC.
          | We didn't have any local service to HCPDUC and we had the
          | only other update to it, so it was easy to install.  I put
          | it on the CPSYSXA D20 disk, but will wait until the next
          | build to install.
          |
----------+--------------------------------------------------------------
6X570 (CL)|   When trying to use ICKDSF Release 14 to build a new VM/ESA
07/01/93  | sysres pack for VMY, DSF barfed on a PARM allocation type
 2:17 pm  | with ICK33120I "PARM" IS AN INVALID ALLOCATION TYPE and
George    | condition code=12.  Also, when doing a CPVOLUME LIST on the
          | ES2RES volume, the already-allocated PARM disks (MAINT's
          | CF1 & CF2 disks) came up with ????.  It appears the version
          | of DSF I have doesn't understand PARM at all.  (I did apply
          | the DSF service that came with ESA, didn't I??)
          |
          |   Turns out that Jeff's version of DSF works fine.  Ruth
Leslie    | keeps DSF on the PRODUCT DSF14 disk.  She just added
  Barton  | service on 10/03/92 and her ICKCP01 TEXT deck is at a
8-583-5433| higher level than mine, so even though I just serviced
07/01/93  | DSF a coupla months ago (see 4X524), I'm downlevel.
LBARTON   |
  at      |   Leslie says she'll send me all 21 DSF Release 14 fixes.
SJSVM28   | Meanwhile, I'll just use Jeff's ICKDSF MODULE.
          |
07/02/93  |   The tape came in the next day.  I downloaded it, took a
          | look at their 5684042D EXEC (it erased 3 TXTnnnnn files
          | and renamed what was on the tape to TEXT - which wouldn't
          | work since there was already TEXT decks on MAINT's D00
          | disk by those names.  The rename should have been a copy
          | with replace).  Anyway, I copied/renamed their text decks,
          | ran ICKTXT & ICKMOD to get me a new ICKDSF MODULE.  It also
          | fails.  Back to the Support Center ...
          |
Leslie    |   Leslie says my DSF disk is all screwed up.  I've got some
  Barton  | DSF Release 13 modules mixed in with the Release 14 ones.
07/12/93  | This disk (MAINT's D00) was a brand new, clean install
          | from the product install & service tapes.  Those tapes must
          | have been screwed up.  She says I should order DSF Release
          | 15 anyway.  I guess that's what I'm gonna do.
          |
----------+--------------------------------------------------------------
6X826 (CL)|   While trying to apply our local generic node name mod to
07/12/93  | DMSDDL, I found a bug in DMSDDL.  They've got this fancy
 4:15 pm  | dancy PSPACE macro that's suppose to insure there's room
          | left in the module for future expansion, but it doesn't
          | work.  The RECEIVE & RECEND labels in DMSDDL have 0 bytes
Steve     | of addressability left from its base register (R10) and
  Webb    | the PSPACE macro isn't complaining 'cause they've got a
WEBBSTEV  | different register (R11) to use starting at the PROGERR
  at      | label.
ENDVMFE0  |
8-853-5323|   Level 1 says there's 5 updates to DMSDDL, so I asked for
          | them to be sent to me.  He's also going to ask the DMSDDL
          | module owner if this problem has been fixed.
          |
          |   Turns out that the DMSDDL owners were aware that the
          | PSPACE macro wasn't working, so in CMS Release 10, they
          | commented it out (!!).  How 'bout that?  They had an update
          | in the CMS 9 service stream that also ran into addressing
          | problems, but they just changed the PSPACE percent figure
          | from 5% to 3% to get around it.  The owners don't want to
          | fix it any more than this for CMS 9.
          |
          |   Steve suggested I open a PASR.  There was something in
          | the VMARENA FORUM on 93/04/21 on how to do this.  You can
          | get a blank form from VMREQS at GDLVM7.  Steve said I could
          | just send him a note and he'd paste it into a PASR.
          |
 7/27/93  |   Got a note from WEBBSTEV saying requirement #1450 has
          | been opened in their VM Systems Planning's Requirements
          | Database (RMP).  I should hear within 90 days.
          |
          |
          |
----------+--------------------------------------------------------------
6X906 (CL)|   Complained that NOTE doesn't erase an autosave file after
07/14/93  | you send the note if you happened to have that autosave on.
12:45 pm  | We've had the following local mod to the SENDFILE EXEC for
          | as long as I've been here.  I'm just trying to drop it as a
          | local mod.  The following 5 lines go after the -NOTEEXIT
          | label.
          |      &SUBCOMMAND XEDIT COMMAND EXTRACT /AUTOSAVE/
Mary      |      &X = &DATATYPE OF &AUTOSAVE.1
Hotten-   |      &IF &X ^= NUM &SKIP 2
    stein |         &SUBCOMMAND XEDIT COMMAND SET AUTOSAVE OFF
HOTTENMA  |         ERASE &AUTOSAVE.2 AUTOSAVE &AUTOSAVE.4
  at      | I sent Mary this update, but come to find out, SENDFILE was
ENDVMFE0  | rexify'd in CMS9.  I haven't seen where it fits, but they'll
          | figure it out.
          |   Mary wanted to put this in their internal problem report
          | process for inclusion in a future release of CMS (release
          | release 11?).  I said whichever way it is, an APAR for this
          | release or something for a future release would be fine.
          |
Mary      |   Mary called and said she opened a "Design Requirement"
Hotten-   | and gave me the item number so I can track it.  It's 1446.
    stein | She said technically, this isn't a PASR, but they're
07/20/93  | essentially the same thing.  I should hear within 90 days
10:45 AM  | what their response is.
          |
----------+--------------------------------------------------------------
6X960 (CL)|   I've got the generic mod partially in our CMS and found a
07/15/93  | bug in DMSDDL.  If the IDENTIFY command fails when doing a
 3:40 pm  | SENDFILE (at label ENDPARSE), DMSDDL tries calling BADIDEN,
          | which calls WRAP4, which gets to label UNIMSG1 and BALR's
Paul      | to ISSUEERR, which saves and changes R11 to =A(ISSUEMSG),
  Murray  | then, since SENDFILE wants the msgs stacked, branches to
8-853-5342| ISSUESTK to stack it.  Now, if that stack gets an error,
MURRAYPA  | which mine did for some reason, then you go to BADSTACK,
  at      | which then branches to WRAP4 based on R11 being =A(PROGERR)
ENDVMFE0  | which it was before ISSUEERR changed it.  An obvious bug.
          | As a matter of fact, even if BADSTACK restores R11, you're
          | gonna be in an endless loop (assuming the error you got
          | stacking the line is solid, which it would have been in
          | my case) continually stacking error msg lines.
          |
          |   Paul's gonna contact the DMSDDL owner.  Meanwhile, why
          | am I getting an error stacking a line?  I've got no mods
          | there ... Ahh, I see why.  Right after we do the IDENTIFY,
          | we "initialize ATTN plist" by moving in the ATTN command.
          | If IDENTIFY gets the error, then the ATTN plist (which is
          | how a line is stacked) isn't initialized yet and R1 when
          | we do the SVC202 is pointing to hex zeros.  The MVC
          | ATTNCMD,CATTN command needs to be moved up to at least
          | before the IDENTIFY command, maybe even sooner.  So that's
          | two bugs with DMSDDL.  I called Paul back and told him.
          |
Paul      |   Paul says he's opened APAR VM56565 for this problem.
  Murray  | Meanwhile, I said it was ok to close this PMR.
          |
08/24/93  |   Got a letter from PID saying this APAR is closed on 7/30.
          | Their problem description leads me to believe they didn't
          | fix the second (third?) part of this problem, the ATTN plist
          | being initialized before it's used.  Well, that situation
          | was more of a thought game anyway, I'm not going to pursue
          | it.
          |
----------+--------------------------------------------------------------
8X532 (CL)|   Called about various AMMR V1R2M0 problems (pp# 5684-140).
 9/08/93  | First, I'm missing some help files, DEVADD HELPAMMO and
 2:30 pm  | DEVDEL HELPAMMO.  Second, there appears to be something
          | amiss with the help.  If I select the ":AMMR" item on the
          | main AMMR menu, I get DMSHEL254E Help cannot find the
          | requested information.  If not misspelled, enter HELP for
          | menu assistance, or HELP HELP for the HELP command.
          |   I also saw in a 93/01/29 append in the AMMR FORUM that
          | "an SPE went out last year" that changed the syntax of the
          | AMMR POOL ADD command to AMMR POOL ADD poolname rdev (RDEV.
Glenda    | This isn't reflected in my help files, so I suspect I don't
  Ford    | have the SPE.  I'm just gonna ask the support center for
FORDGGF   | everything they've got for AMMR.  The append also said
  at      | there was "a DOC APAR out on Retain" that documented other
GDLVM7    | publication errors.  Might as well get that, too.
8-852-5144|   The help text doesn't show the Query STATUS command.
 9/09/93  | My level from the Query STATUS command is Version 1.2.00
 1:40 pm  | SL00.  The folks in the forum say level 7 is the latest.
          |   Glenda's gonna send me the latest PTF to get me to level 7.
          | Should be in in a coupla days.
          |   The "DOC APAR" number is VM50726.  Glenda says I've gotta
          | go to Retain myself to read all about it.
          |   While I had her on the horn, I asked her for a TEMPLATE
          | to convert our VMTAPE data base to AMMR.  She sent me
          | VMTAPE TEMPLATE.  Great.
          |
----------+--------------------------------------------------------------
9X014 (CL)|   Called to get a PTF for CMS 5.6, VM55996/UM24769, that I
 9/24/93  | need for ADSM.  That PTF is very recent and not on any PUT
 3:45 pm  | tape yet.  Our current release of CMS is 201, which equates
          | to PUT 9002!!  The Support Center is sending me PUT tape
Debbie    | tape 9304, the PUT Bucket, and a COR tape with UM24769.
  Wills   |   I also asked for the same fix for CMS Release 10, UM24762.
          | That's coming, too.
          |
 9/27/93  |   Three tapes came in.  The 2 PTF tapes for CMS 5.6 & R10,
          | and another tape that looks like it might be the PUT Bucket,
          | it only has 3 PTFs on it.
          |
----------+--------------------------------------------------------------
1X760 (CL)|   Called to investigate VM57462.  Leoda says it's a fix to
12/20/93  | HCPIUH that restores R1.  I'm hoping the same bug is in IUD
 1:00 pm  | that's our AUTOLINK problem.  I see both modules storing R1
          | around a call to HCPIUGAS to get a lock, then instead of
          | restoring R1 after the call, it again stores R1 in the same
          | place.  The ST R1 looks like it should be a L R1.
          |   That's exactly what VM57462 does.  And the exact bug is
          | in IUD, which is what's bugging AUTOLINK.  I'm gonna patch
          | our system myself.
          |   Turns out this same bug is in 2 other modules, 4 in all.
          | HCPIUC 4 times, IUD 3 times, and in IUH & IUW once each.
12/21/93  | I patched all 9 places in the 4 modules.  It is not in IUB
 4:15 am  | or IUE.  I called the Support Center back and told them.
          |
 1/07/94  |   AUTOLINK hung up again, so the above is not our problem.
          | The problem turned out to be the IUCV msgid getting above
          | 100,000,000 (nine digits).  Code in SVMIUCV and AUTOLINK
          | converts that 4-byte hex field to deciman digits on the
          | initial IUCV interrupt, then back again for the IUCV
          | RECEIVE, all in an 8-byte field, thus truncating digits.
          | Thus AUTOLINK was asking for the wrong msg on the IUCV
          | RECEIVE.  It's been fixed with the BIGNUM update.
          |
 4/28/94  |   Got a call from somebody (didn't catch his name) asking
 9:40 am  | about this PMR.  I told him I didn't care about getting
          | VM/XA serviced.  All I wanted to do is warn them about this
          | bug existing in other places - to check all places where
          | HCPIUGAS is called.  He said he would pass that message on.
          |
----------+--------------------------------------------------------------
2X795 (CL)|   Called in various problems with AMMR.
02/04/94  |   (a) First it seems the database file, MASTER VOLLIST,
 5:20 pm  | isn't getting closed after a MOUNT SCRATCH requests gets
          | satisfied.  The forum says it should be closed after each
Ed        | update.
Quigley   |   (b) I also can't get the MOUNT command to stack the volid
QUIGLEYE  | after a MOUNT SCRATCH ON 181 (POOL ... LIFO as the manual
   at     | says it should.
GDLVM7    |   (c) The last problem I have is if a tape is on a drive, I
8-294-5119| can't add it to a scratch pool.  The sequence of events is
          | POOL ADD DB---- JUNK01
          | POOL ADD DB---- FE0 (RDEV
          | MOUNT SCRATCH ON 181 (POOL DB----
          | Tape JUNK01 gets mounted and assigned to me.
          | I detach the drive and AMMR Q STATUS to get AMMR to pick
          |   up the fact FE0 is free again.
          | JUNK01 is loaded into FE0.
          | MOUNT SCRATCH ON 181 (POOL DB---- again.  The mount is not
          |   satisfied 'cause I forgot to add JUNK01 back into the pool.
          | POOL ADD BD---- JUNK01 fails.  I get EZI22007E Volume JUNK01
          |   not free for assignment to SCRATCH pools.
          | The only way I know to get out of this state is to force
          | AMMR.  I didn't (and should have) try to simply unload
          | JUNK01 and possibly load something else.  But just because
          | a tape is loaded into a drive shouldn't prevent me from
          | adding it to a pool.  Ideally, I should be able to add it
          | to the pool and AMMR should immediately use it for any
          | outstanding mount.
Glenda    |
  Ford    |   For problem (a), Glenda wants me to log onto AMMR and
FORDGGF   | type TEST ON NOP, issue and satisfy the mount, TEST OFF,
  at      | and send her the AUDIT LISTING.
GDLVM7    |
8-852-5144|   For problem (b), Glenda doesn't think the LIFO or FIFO
 2/08/94  | options work when asking for a scratch tape from a pool.
 1:40 pm  | I told her I expected it to if I specify WAIT.  She said
          | she didn't think so but asked me to reissue the mount
          | with .MDBG. as the last option on the mount command, which
          | will generate a lot of console output, and send her your
          | console listing.
          |
          |   For problem (c), I couldn't recreate this problem
          | yesterday.  As a matter of fact, AMMR worked very well
          | yesterday, so I told her to forget about problem (c).
          |
          |   I also asked her about two other problems:
          |
          |   (d) When doing a MOUNT ... (WAIT, you get the message
          | WAITING FOR MOUNT. TYPE '1' TO CANCEL.  When typing the 1,
          | I got the following 2 messages.
          | EZI08037I Message acknowledged. Awaiting processing
          | EZI15049S Invalid volid.  Use QUERY command and re-issue
          |                             CANCEL with the request number.
          | The MOUNT module is sending AMMR a MOUNT CANCEL SCRATCH.
          | I sent Glenda a spooled console of this happening.  Maybe
          | a .MDBG. debug run will help this, too.
          |
          |   (e) The last problem is, from a privileged id, getting
          | EZI02010E You are not permitted to change this data.
          | when doing an AMMR CHANGE DB0001 OWNER JASPER.  This
          | doesn't happen all the time and I don't know how I get
          | into the state when it does.  Glenda's first take on this
          | was I was trying to change owner for a scratch tape, which
          | isn't allowed.  That's probably the case, but then the
          | manual should suggest that.  I was likely getting very
          | confused due to (a), (f), and the fact that newly scratched
          | tapes are at the *end* of the Q FREE response.
          |
          |   (f) Probably related is the fact that sometimes tapes are
          | in the free list (AMMR QUERY FREE), but the scratch bit
          | is not set on.  Possibly due to a POOL DEL DB---- DB0002
          | not resetting the scratch bit.  I'll bet that's it.
          |
          |   Regarding problems (a), (b), and (d) ...
Date: 10 February 94, 13:34:27 PST
From: Rick Jasper               8-457-2731           JASPER   at ALMADEN
      VM Systems Support
To:   Glenda Ford               8-852-5144           FORDGGF  at GDLVM7
 
Glenda,
 
  Sorry this took so long, but I finally got around to doing as you asked.
I'm had tape DB0001 in the DB---- scratch pool in tape drive FEF.
I logged onto AMMR and typed TEST ON NOP, then from my JASPER id, spooled
my console, then typed in mount scratch on 181 (pool db---- wait lifo sl .MDBG.
I'm sending you MOUNT CONSOLE, which is JASPER's spooled console, as well
as the AUDIT LISTING from AMMR's 191 disk.
 
  To refresh your memory (and to document for mine), the MOUNT CONSOLE
should help answer the question why I wasn't getting the tape label stacked
even though I asked for it via the lifo option.  The AUDIT LISTING was to
verify the MASTER VOLLIST file was not getting closed (committed to disk)
after a scratch mount request got satisfied.  You had thought it wouldn't
work for scratch tapes, but I didn't see why not as long as I specified
the wait option.
 
  For grins, I also traced a MOUNT SCRATCH command that I canceled by
typing a 1 as the MOUNT command says to.  I'm sending the CANCEL CONSOLE
and AUDIT2 LISTING to help determine the cause of the error messages
EZI15049S Invalid volid.  Use QUERY command and re-issue CANCEL with the
 request number.
It looks like the MOUNT MODULE is sending AMMR a MOUNT CANCEL SCRATCH
command, which AMMR is complaining about.
 
Rick
          |
          |   Later that same day, regarding problem (f) ...
Date: 10 February 94, 14:53:30 PST
From: Rick Jasper               8-457-2731           JASPER   at ALMADEN
      VM Systems Support
To:   Glenda Ford               8-852-5144           FORDGGF  at GDLVM7
 
  After looking into it a bit further, I've found when/how tapes get
onto the free list with the scratch bit (x'10) turned off.  It's done
by the POOL DEL command.  The sequence with tape DB0001 & pool DB----
(presuming DB0001 was never classified) is
 
 1)  Scratch the tape (AMMR SCRATCH DB0001).  The scratch bit will correctly
     be on and DB0001 will show up in a AMMR Q FREE response.
 2)  Assign the tape to a scratch pool (AMMR POOL ADD DB---- DB0001).
     AMMR will turn off the scratch bit.  The tape does not show up in a
     AMMR Q FREE response.
 3)  Remove the tape from the scratch pool (AMMR POOL DEL DB---- DB0001).
     AMMR does not turn the scratch bit back on, but the tape does show
     up in a AMMR Q FREE response.
 
  This sequence causes an indiscrepancy for when I shut AMMR down (even if
I do it cleanly with an ENDRUN), when AMMR comes up again, DB0001 will not
be in the free list.  The scratch bit in MASTER VOLLIST is off.
 
  My opinion is AMMR shouldn't be turning off the scratch bit on the
POOL ADD DB---- DB0001 command.  Just because the tape is added to a pool
doesn't mean it's not still a scratch tape, does it?  Likewise, I wouldn't
remove a tape from a scratch pool when it gets assigned.  If you want to
insist on the current handling of scratch/pool/assignment status, then
the POOL DEL DB---- DB0001 command should turn the scratch bit back on.
 
Rick
          |
          | Synopsis:
          | (a) - MASTER VOLLIST not getting closed when a scratch
          |       mount gets satisfied.  Clearly a bug.
          |       Circumvented by MNTEXIT EXEC to cause a db update.
          | (b) - LIFO/FIFO option on MOUNT SCRATCH command does not
02/11/94  |       stack the volid.  Glenda says my MOUNT MODULE was
          |       out of date and has sent me a replacement, but it
          |       still didn't work.
          | (c) - Confusion on my part.
          | (d) - Cancelling a MOUNT SCRATCH by typing 1.  Clearly a bug,
02/11/94  |       but Glenda says "that you can't use the 1 to cancel
 6:40 am  |         in an SL, DEVMGT scratch pool system!  As I
her time  |         mentioned the other day, this setup has restrictions.
  (EST)   |         What's happening is in AMMR's normal processing it
          |         has always used the volid to identify mounts for
          |         each virtual machine.  With this setup the volid is
          |         SCRTCH and not a valid one because no tape is in the
          |         machine to be assigned.   I know this is not real
          |         clean but this function was added very late and I'd
          |         say corners were cut in the design.  Sorry you won't
          |         be able to cancel it with the one in this setup, it
          |         would be a re-design of the MOUNT modules hand
          |         shaking."
          | (e) - Can't change ownership of a scratch tape.  Glenda says
          |       WAD, which is ok, but the error message should be
          |       clarified.
          | (f) - Scratch bit isn't being turned back on when you
          |       POOL DEL a tape.  Clearly a bug.
          |       Circumvented by POOLEXIT EXEC that scratches the tape.
02/11/94  | (g) - Found another bug.  After-Mount exits sometimes get
 1:18 pm  |       passed the wrong second argument, the one that is the
          |       database record.  When I MOUNT SCRATCH (POOL DB----
          |       and DB0001 is used to satisfy my mount, my exit is
          |       passed DB0002's database record.  So far, it's only
          |       DB0001 that this screws up with.  Other tapes used to
          |       satisfy scratch tape requests get passed correctly.
          |       I've sent Glenda a note.
          |
02/21/94  |         Glenda sent me a new AMMR20 MODULE that was suppose
          |       fix both (a) and (f), but it didn't.  I sent her a
          |       note on the 23rd.
          |
----------+--------------------------------------------------------------
3X345 (CL)|   I got in deep doodoo this morning when I inadvertedly typed
02/28/94  | CPFORMAT FORMAT instead of CPFORMAT ALLOCATE, using DSF
10:30 am  | release 15.  I was further frustrated by stupid error msgs
          | from DSF, when I was trying to recover.  These msgs came
          | from formatting just cylinder 0.
          |   ICK33100I 1769 CYLINDER MINIDISK IS INVALID
Leslie    |   ICK30008I MIMIC(MINI) NOT SUPPORTED IN THIS ENVIRONMENT
  Barton  |   ICK31327I NO STORAGE AVAILABLE FOR MAXIMUM TRACK
8-583-5433|                                            CAPACITY RECORD
LBARTON   |   ICK33010I SPECIFIED RANGE(0,0); START CYLINDER HIGHER
  at      |                                            THAN END CYLINDER
SJFEVMX   |   ICK33060I ALLOCATION TYPE "...." IS NOT SUPPORTED ON 3880
          | Running a release 14 module worked ok.  Leslie is looking at
          | a trace.
Leslie    |   Leslie says I have a mixed level of DSF, 12 of my text
 3/03/94  | files have ICKDSF14 in them, the other 42 have ICKDSF15.
          | I don't know how they got mixed - I did a clean install of
          | DSF 15 & added a PUT tape.  Perhaps the PUT tape was for
          | DSF 14.  I'm gonna have to reinstall.
          |   Leslie closed this PMR, but asked me to contact her
          | after I reinstall.  W had talked about me modifying their
          | RENAME exec (that renames the TXTnnnn files to ft=TEXT)
          | to check for level inconsistencies, 'cause I got bit by
          | this one before (see PMR 6X570 on 7/1/93).
          |
 4/13/94  |  Tapes came in.  I re-installed on MAINT's D00 disk, regen'd,
          | and replaced ICKDSF IPL & ICKDSF MODULE on the Y-disk.  We'll
          | see if I have troubles next time.  The standalone tape is
          | EX0130.  The DSF module product tape is EX0131.  The service
          | tape that came with it is EX0132.  The  service tape I got
          | with PMR 3X345 is EX0133.  All were read in & used.
          |
----------+--------------------------------------------------------------
3X499 (CL)|   Found out I needed some ISPF & CMS PTFs to make ISPF work.
 3/04/94  | We have ISPF V3 R2, 5684-043.  We need VM45093 (PTF UM18125)
 5:00 pm  | and we should also see APAR VM55250  (PTF UM24209).
Stan      |   I asked for the latest PUT for just this product and Stan
          | said he could order a PUT for everything on my customer
          | number or specific PTF's for specific products.  He can't
          | order a PUT for just 1 product.  I told him, fine.  Send
          | everything.  It's on its way.
          |   First, one tape with VM/ESA Rel 2.0 stuff came.  Then a
          | few days later, 3 more tapes came with the rest of the
          | program products.  See the VM5503, VM5504, & VM5521 PUT9401
          | files on the VMK83 192 disk.
          |
----------+--------------------------------------------------------------
4X480 (CL)|   Another EREP problem (sigh).  Program check.
04/11/94  | DMSITP141T Operation exception occurred at 000220E2 in
10:45 am  | routine IFCEREP1.  I set DEBUG=(17) in the HISTORY CPEREP
          | parm file as described above in PMR 4X751 and saw that this
          | record in the "History Data Accumulation" file, EREPVMA DATA,
          | on EREP's A191 disk.  Columns 123-124 seem to be the device
          | address, 2A2B, which is a tube.  This next line is 138
          | bytes long.  The userid NMRLAB *does* logon to 2A2B.
ˆßm™©ß
ŒNMRLAB  a‡øøøSÿø)ÿÿÿ{ âȸÚL®00003000
ddd
øøøø
Gary      |   For the record, we have EREP V3.5.0 installed on the
  Pattee  | EREP 202 disk. program product #5654-260.
PATTEE    |
  at      |   I'm queued to level 2.  Meanwhile, I took the offensive
TUCVM3    | record out of XAEREPIO RECORD so at least we can continue.
8-321-4056|
 4/11/94  |   I sent Gary the above sense bytes.
 1:15 pm  |
          |   I had another set of sense bytes appear that crashed EREP
 4/13/94  | in the same way.  This time, they were from 29E1, a CTCA
10:00 am  | normally attached to PVM as 9E1, which is PVM's ALMPVM07,
          | one of those PCCA's.  This is that record (140 bytes long).
ˆÞm
¨ßß
ŒSYSTEM  = ‡çøøTÿø*ÿÿÿøëØ�ø9H¥sì27881100dd
Vøøçÿ
          | ... Later ...  But then I just got more and more errors.
          | Maybe just deleting these records from the EREP data isn't
          | going to fix what's wrong.  I've tried calling Gary back
          | (especially since he said he would call back by yesterday)
          | and get no answer.  I left a message.
          |
 4/14/94  |   Finally got hold of Gary.  Told him of the urgency since
 1:20 pm  | EREP hasn't run for a while here.  He'll call back soon.
 2:00 pm  |   Gary called back and asked for more info, like exactly
          | where we were when we program checked - which module, etc.
          | I stopped at where the program check occurred and saw that
          | IFCEREP1 + x'1E2' was doing a Load R15 from R12+x'808',
          | picking up 220E0 and BALR-ing to it.  That location was
          | zeros, so it program checked.  Sounds pretty straight-forward
          | to me to resolve.
          |
 5/04/94  |   Haven't heard from anybody for a while.  Frank says the
 8:50 am  | last entry in the PMR was on 4/27.  They are working on it,
Frank     | and are getting close, but haven't pinned it down yet.
          | They're working with VM asking about loadlib levels.
          | Anyway, Gary should call back soon.
          |
 5/09/94  |   We found out that EREP runs fine when running under CMS 9,
          | so since we'll be on VM/ESA 2.0 & CMS 9 in 6 1/2 weeks, I
          | told them to go ahead and close the PMR.  I'm not interested
          | in fixing CMS 5.6.
          |
----------+--------------------------------------------------------------
6X107 (CL)|   Called to get the latest service to VM/ESA Release 2.0.
06/10/94  | I did this back on 4/8/93 (see PMR 3X981), but I wanted to
 4:40 pm  | get the latest stuff.  Chris Bischoff needs some fixes for
          | for GCS to get the new VTAM 3.4 running.
          |   Kathleen said 9405 is the latest.  Tape's on its way.
          |
----------+--------------------------------------------------------------
6X514 (CL)|   After converting to VM/ESA R 2.0 this weekend, the 5088
06/27/94  | users are getting I/O errors logging on to VM (they're MVS-
 2:45 pm  | attached) when getting into full-screen applications like
          | INEWS or XEDIT or sometimes, FULIST.
Al        |   Bob Carr found a PVM APAR/PTF, VM58240 (PTF UV58309 for
Rimington | release 210 or UV58308 for release 211), but the text of
BIGAL     | that APAR doesn't sound like our problem.
   at     |   Al wants me to try CMS 5.6, see if there's an error
GDLVM7    | message on the PVM console, dump the RDEV & LDDBK for the
          | logical device (LOCATE LDEV L03xx), try a locally-attached
          | 5088, and check the screen size (whew!).  Al's gonna get
          | somebody from the I/O area to call me back tomorrow by
          | 10 am to see what I learned (Al's in the console group).
 4:00 pm  |   I found a 5088 that's directly attached to VM upstairs
          | in C2-425 in Peter Wimmer's office/lab (7-2169).  It fails
          | the same way and works in CMS 5.6, so it appears to be a
          | CMS 9 problem.  I called the Support Center back to get the
          | PMR queued to the CMS folks.  Meanwhile, I have a TRSOURCE
          | trace on RICK, 5088 CPTRACE and a console showing a display
          | of the RDEV in 5088 CONSOLE.  The terminal session was 43X80.
Sue       |
Chaber    |   I spent a few hours with Sue on the phone tracing &
8-852-5039| debugging this.  Finally went off into some PLAS routines
CHABERSE  | (DMSWVT, WIR, & WIO) called from DMSXSC, so I traced them
   at     | and sent her the (only) 300-line trace.
GDLVM7    |
          |   Sue wanted a trace on the LTR at EE25FC to see what's in
          | R15.  It's x'64'.
          |
          |
          |
----------+--------------------------------------------------------------
6X583 (CL)|   I'm getting the following messages from ICKDSF Rel 15.0
06/28/94  | when doing a INSPECT REALADDR(811) TRACKS(826,0) NVFY NOASGN.
 7:30 pm  | ICK32364I CAN NOT OBTAIN ACCESS TO DEVICE 0811
          |           RC= 407
          |           THE MINIDISK HAS AN EXISTING LINK TO IT, USERID =
          |                                        """""""" (8 hex 0's)
          | ICK11130I CAN NOT DETACH LINKED DEVICE  5FF
          |           RC= 40
          | ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12
          |           19:11:40    06/28/94
          | This is under ESA 2.0.  Doing tracing of the Diagnose E4's
          | shows a Diag E4, function x'03' getting rc=407(x'197') for
          | an EW link to that cylinder.  There are no minidisks nor
          | links allocated there (it used to be ACCOUNT's 191 disk).
          | This appears to be a CP bug.  The userid returned *is*
          | all x'00's, so DSF is just reporting what CP returned.
Jim       |
Sicignano |   See PMR 3E551,282 in RETAIN.  See also VM57836, closed
8-852-3725| without a fix (Cancelled).  It talks about the same
SICIGANO  | situation.  I sent Jim my DSFERROR CONSOLE.
   at     |   Jim wants to trace HCPVDS, maybe.
GDLVM7    | There are 3 ways to use DSF to inspect a track.
          | 1) INSPECT REALADDR(811) TRACKS(826,0) NVFY NOASGN
          |      - Doesn't work as above.  The reason (we just found out)
          |        is CP cannot get an exclusive link to the minidisk.
          |        The reason for that is the same as if we tried a
          |        LINK ACCOUNT BAD1 123 EW command, namely
          |        HCPLNM1158E Stable and exclusive links are not
          |           supported. A system that shares this volume
          |           is not at release VM/ESA1.1 or greater.
          |        I've got to re-XLINK FORMAT all our DASD!
          |        But there's still a bug in CP's DIAGNOSE E4 code
          |        (HCPVDS?) that if the link fails because of the msg
          |        above, it should not return rc=407, rc=198 would be
          |        better.  Also, the manuals don't explicitely say
          |        anywhere that you *have* to re-XLINK FORMAT all
          |        your DASD.  This was on my list of things to do,
          |        but I didn't realize it was a priority.
          |        I was told that even after I re-XLINK format this
          |        box though, this syntax won't work because this is a
          |        3380 behind a 3880 and that combination does not
          |        support concurrent maintenance (see 2) below).
          |        I'll check this out on Saturday after I re-XLINK.
          |        I wonder what error message I would get.
          | 2) INSPECT UNIT(BAD1) UID(ACCOUNT) TRACK(0,0) NVFY NOASGN
          |      - With older style DASD that doesn't support concurrent
          |        maintenance, eg 3880/3380, this won't work (I don't
          |        know what error msg you get).  The minidisk definition
          |        has to be in your directory definition and nobody
          |        (not even you) can have a link to it.  Since the
          |        minidisk is yours, you don't need the UID() keyword.
          |        This is how I've got to do it after I re-XLINK
          |        FORMAT the DASD, but I'll see what the error msg is
          |        if I try it with UID(ACCOUNT) first, before moving it.
          |        I was told that this syntax would work for new style
          |        DASD, ie 3990/3380 & 3990/3390, and you wouldn't have
          |        to first move the minidisk to your userid.
          |        The track btw, is the offset from the virtual mdisk.
          | 3) INSPECT UNIT(vaddr) TRACKS(826,0) NVFY NOASGN
          |      - Where vaddr is your linked-as virtual address.
          |        The way this all used to work is one would first link
          |        the minidisk (e.g. LINK ACCOUNT BAD1 100), then
          |        run DSF INSPECT.  It no longer works this way.
          |        Now (see 2) above) you can and do use this syntax
          |        if the minidisk is in your directory entry, but you
          |        don't have a link to the disk (if you do, the EW
          |        DSF does via Diag E4 will fail, telling you that
          |        you have a link to the disk).  And as described above,
          |        you have to move the minidisk definition to your
          |        directory if the box does not support concurrent
          |        maintenance.
          |
          |  So, on Saturday I'll come in and re-XLINK FORMAT all our
          |  DASD.  Then I'll check
          |    INSPECT REALADDR(811) TRACKS(826,0) NVFY NOASGN
          |  That should fail because the box does not support
          |  concurrent maintenance, but I want to see what error msg
          |  I get.
          |
          |  I'll then try
          |    INSPECT UNIT(BAD1) UID(ACCOUNT) TRACK(0,0) NVFY NOASGN
          |  This should also fail for the same reason.  Again, what's
          |  the error message?
          |
          |  I should also try inspecting a 3390 track with
          |    INSPECT REALADDR(160) TRACKS(2171,0) NVFY NOASGN
          |  just to check this out on a box that supposedly does
          |  support concurrent maintenance.  This should work.
          |  Also,
          |    INSPECT UNIT(193) UID(PQB3A) TRACK(99,0) NVFY NOASGN
          |  again, should work.
          |
          |   The PMR is staying open so Jim could look at the rc=407
          | (or 307 for function 2) in this case of the old-style CSE
          | record.  Diag E4 should return a different return code.
          |
          |
          |
          |
          |
----------+--------------------------------------------------------------
6X584 (CL)|   The PROFS userid got this program check & messages,
06/28/94  | DMSITP143T Addressing exception occurred at 80EA5038 in
 7:30 pm  |                       system routine EXEC; re-IPL CMS
          | HCPGIR450W CP entered; disabled wait PSW 000A0000 80E75D8
          |   EA5038 is IXXRVA (Rexx) +x'518'.  I did a lot of poking
          | around and saw no reason the instruction, an ICM at RVA+514,
          | BF1FB00C, should fail.  The regs (at 654.40) were  << No!! >>
          | Note later:  These weren't the registers.  654 is A(PGMSECT),
          |              note PGMSECT itself.  You needed to go to 6FC0+
          |              7C (like your notes in CMSAREAS MYQMARK say) to
          |              get to the registers.  I can't tell now what the
          |              registers were.
          |                                   The Program old PSW was
Sue       | 030C1000 80EA5038 (storage protect key of 0).
Chaber    |   See VM57829/UM25628 for a possible fix.  Level 2 will call
8-852-5039| me tomorrow.  Sue Chabers says this PTF doesn't apply to
CHABERSE  | CMS 9.  She wanted a trace, but it only happened once under
   at     | PROFS and never again, so I can't recreate it.  I sent her
GDLVM7    | the info I did have, console listing from my debug session.
          |   Sue found VM55953 which discussed a bug in the PID CUF
          | version of Browse that was fixed.  I told her we don't use
          | that version of Browse and didn't know if that bug was in
          | the IUO version or not.  I appended in the BROWSE FORUM
          | asking if VM55953 applied or not.  Meanwhile, I agreed
          | this PMR could be closed.  If this happens again, Sue wants
          | a DUMP 0-END DSS.
          |
----------+--------------------------------------------------------------
6X922 (CL)|   Called in Bob Carr's problem with using AGSS under APL.
07/15/94  | He was getting a storage overlay in free storage, so that
 2:15 pm  | DMSFRG would crap out with
          | DMSITP143T Addressing exception occurred at 80E115B6 in
          |            system routine DMSFROSV; re-IPL CMS.
          | This only occurs on a OS/2 2.11 CM2 (Communication Manager)
          | 1.11 (includes Host Graphics & APL Support) workstation.
          |   Even though the message says DMSFRO, E115B6 is DMSFRG +
          | x'4A6'.  After a lot of poking around, that part of FRG
          | is going through a chained list of free-storage pointers
          | and the first forward link pointer is destroyed.  Looking
          | at the registers (D 654 = A(PGMSECT) = 6FC0 + 7C = 703C,
          | which was R0-R15 at the time of the program check), R3
          | was the address of the last piece of storage looked at on
          | the chain, which was 1DA000.  I went through the process,
          |   APL
          |   )LOAD 19 AGSS
          |   START
          |   Select Plot & hit enter
          |   iota (shift-I) 12 for both X & Y Variable(s) & hit enter
          |   F3 to end looking at this graph
          |   F4 to put some text on the plot
          |   Type some text, then shift-K to get the ', then enter
          | Then hit PA1 (Alt-Insert) to get into CP Read and started
          | a TRACE STORE INTO 1DA000.8, then got back into that plot.
          |   Hit the left mouse button (or PF1) and you get the
          |   failure.
          | That trace showed that GDDM was mucking around with that
          | address.
          |  04336EDC  MVI   92F3A000 >> 001DA000    CC 3
          |  04336F14  STH   4030F000 >> 001DA001    CC 3
          |  04336F18  MVC   D201F002CAF0 >> 001DA003    04337E99    CC 3
          |  04336F1E  XC    D701F004F004 >> 001DA005    001DA005    CC 0
          |  04336F2C  STH   4080F006 >> 001DA007    CC 1
          |  043BDE96  MVC   D201C000BC7A >> 001DA000    043BF8BB    CC 0
          |  04230C3C  MVI   92E9E003 >> 001DA003    CC 2
          |  00E1266E  XC    D70320002000 >> 001DA000    001DA000    CC 0
          |  00E12674  ST    50102004 >> 001DA004    CC 0
          |  043BDE96  MVC   D201C000BC7A >> 001DA000    043BF8BB    CC 0
          |  04230C3C  MVI   92E9E003 >> 001DA003    CC 2
Calvin    |  00E1266E  XC    D70320002000 >> 001DA000    001DA000    CC 0
  Suiter  |  00E12674  ST    50102004 >> 001DA004    CC 0
8-444-7063|
But he was|  We're running GDDM 3.1.0, #5684-168, VM/ESA 2.0, CMS 9.
at        |
8-444-5114|
when I    |
talked to |
him.      |
          |  admmdft trcestr='fullio flow dsopen parmsf(32000)'
          |
          |
          |
          |
          |
          |
          |
          |
----------+--------------------------------------------------------------
-X--- (  )|   -
0-/--/94  | -
 -:-0 pm  | -
          | -