You might issued SEND CP RACFVM CP VMDUMP 0-END FORMAT CMS DSS TO
dump_id
 
Then send it to IBM

        -----Original Message-----
        From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson
        Sent: Monday, June 16, 2008 10:14 AM
        To: [email protected]
        Subject: Re: Busy RACFVM
        
        

        Alan Altmark <[EMAIL PROTECTED]> wrote:- 
        
        > Where is the I/O going?  SMF log?  Database?  In general, RACF
does 
        > nothing by himself.  #CP TRACE EXT RUN on the suspect RACFVM
server will 
        > tell you if its run amok or if something is driving the
horses.
        
        > The external interrupts can come from CP on the *RPI interface
on from 
        > guests like LDAPSRV, FTPSERVE, and REXECD (issuing RACROUTEs).
        
        > QUERY IUCV RACFVM will give you the path ids.  If you've got
QIUCV, I 
        > think it will tell you where the external interrupt buffer is
in the 
        > RACFVM server.  My version does this:
        
        > QIUCV EXEC 1.2 (C) IBM Corporation, 1989, 2008 
        
        > User RACFVM has 4 out of a possible 300 connections. 
        >   - External interrupt buffer is located at 00E84D08 
        >   - Control interrupt buffer not defined 
        >   - 1208 messages received, 1209 sent, 0 failed 
        
        > But you can also go to each user listed in QUERY IUCV and do a
TRACE IUCV 
        > on those users. 
        
        OK - that was a few good pointers to check. 
        
        I did the EXT trace and could see the regular items occurring  -
all with the same address and with Code 4000 (not sure what this is but,
I am guessing, IUCV). 
        
        I dit the Query IUCV RACFVM and could see there was only the
*RPI interface and RMSMASTR connected. I killed RMSMASTR and the IO
continued unchanged so I have to assume this is the *RPI interface
initiating the IO. 
        
        I did a TRACE IUCV on RACFVM (only for a short time) and could
see a stream of IUCVRECV & REPLY events. I tried displaying some of the
storage referenced but I did not know quite what I was looking for and I
could see no eyecatchers that meant anything to me. 
        
        Next I tried turning on LOGOPTIONS ALWAYS for all the classes
that were currently in DEFAULT (using an exec so I could quickly
reverse). I left this on for about 2 minutes - during which time I took
some IND USER displays about 4 seconds apart and noted the time. After
turning everything back to default I took a copy of the SMF file and ran
RACFADU against it.  I could see a fair amount of activity from various
servers (including incoming FTP on FTPSERVE) but nothing abnormal and
the activity during the periods I had noted were completely unrelated
(even allowing for the IO to the SMF file and the RACF database). 
        
        To answer the question from Kris - no, don't have a RACF LIST
running behind the scenes and we do have a user id checker but it only
logs on missing servers and does not run that frequently. 
        
        We don't have any second level system on this VM image. 
        
        Not really sure where to go from here. 
        
        Colin Allinson
        
        Amadeus Data Processing GmbH
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.
--------------------------------------------------------

Reply via email to