Re: JDBC and DB2/VM

[Roland P. Chung]

Hello Herny, one of my clients was able to access DB2/VSE from MS/Excel after installing the appropriate "Schema stored procedures for CLI/ODBC/JDBC/OLE DB Client Applications" fix. (BTW, it never made to be an APAR).     Have you instlled the "Schema stored procedures for CLI/ODBC/JDBC/OLE DB Client Applications" fix in your DB2/VM system? If not, I would suggest you call IBM DB2/VSE&VM services to order:     1) any missing APAR/PTFs for your DB2/VM V7.20 system.  2) request to have a "Schema stored procedures for CLI/ODBC/JDBC/OLE DB Client Applications" FIXTEST.  3) install the above and try again.     I know you will not get too much support from IBM because DB2/VM V7.20 is out of services. However, you still can get all existing APAR/PTF/FIXes, etc. for DB2/VSE 7.20.      Good luck. 
    ...Roland  Henry Wilusz <[EMAIL PROTECTED]> wrote:  HelloJust a short question to see if anyone has gotten JDBC drivers on awindows machine to successfully access DB2/VM. We know that the driverswork with DB2/universal. but fail miserably with DB2/VM. DB2/VM is atversion 7.2The attempt to access DB2/VM returns a authorization failure message tothe windows machine (incorrect message there) and a data capture dump onDB2/VM. The reason for exploring the JDBC angle is that ODBC connections tothis database sometimes hang with no error messages, and we cannot seemto reproduce the hang conditions. An interesting part of the DB2 dump is below. Note that the probablecause section does not tell what the unsupported value was that it istrying to deal
 with.SYMPTOM STRING: MS/ARI2909I PIDS/5697F4201 RIDS/ARITPAC PRCS/11PROBABLE CAUSE OF FAILURE:DDM VALUE NOT SUPPORTEDIf anyone has gotten cold fusion or JDBC to work to DB2/VM, and iswilling to share the secrets, I would like to hear from them thanks Henry Wilusz[EMAIL PROTECTED]Failure is not an option . . . . .. . . . . It comes standard with windowsWith best regards,...Roland ChungSenior Technical Specialist (S/390,VM/VSE,DB2/VSE&VM)MAXC Consultants Inc.Voice/Fax: 416-901-9442 (If busy, call: 416-469-2268)197 Hastings Ave., Toronto, Ontario, Canada. M4L 2L6** Life is short. Stop once in a while and smell the roses. **

Re: VM SPOOL question

[Brian Nielsen]

Yeah, I know what it means.  I was just not expecting the size reserved 

for the dump to *grow* when I did the SET DUMP DASD.

I have no intentions to allocate another SPOOL volume.  We run only Linux
 
guests and there's little demand for spool space.

The other thing of interest is that since the last IPL the SPOOL space 

reserved for the DUMP has approximately doubled (as evidenced by it being
 
split nearly equally between the 2 volumes before the SET DUMP DASD) and 

*none* of that doubling is attributable to SPXTAPE.

Brian Nielsen


On Fri, 13 Oct 2006 10:09:35 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrot
e:

>If you have another pack that you can use, I would suggest formatting it
, 
allocating it a SPOL pack, and designating it as a dump pack in your 
system config. That 91% that you see for Z52SP2 is mostly allocated for 

DUMP. You have, in effect, a 1-pack SPOOL system plus the DUMP files. 
Since contiguous pages are allocated for the dumps at ipl (unless DUMP is
 
set OFF), you will always see the disparity between the 2 packs and all o
f 
almost all of your normal spooling will be on the other, non-dump, pack. 
  
>
>Regards,
>Richard Schuh
>
>
>> -Original Message-
>> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]

>> Behalf Of Brian Nielsen
>> Sent: Friday, October 13, 2006 9:56 AM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: Re: VM SPOOL question
>> 
>> 
>> I decided to see what SET DUMP DASD would do on my system as far as 

>> reclaiming any DUMP space growth caused by SPXTAPE over time. 
>>  Here is =
>> 
>> what I got:
>> 
>> q dump
>> DASD dump space CP IPL
>> RDEV PAGES
>>  -
>> 661F 278346
>> 6748 253074
>> Ready; T=0.01/0.01 10:37:25
>> set dump dasd
>> DASD 661F dump unit CP IPL pages 546256
>> Ready; T=0.01/0.01 10:37:45
>> q alloc spool
>> EXTENT EXTENT  TOTAL  PAGES   HIGH%
>> VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
>> --  -- -- -- -- -- 
>> Z52SP1 6748  1   3338 600840   8516 585886   1%
>> Z52SP2 661F  1   3338 600840 546813 35  91%
>>   -- --
>> SUMMARY1174K 555329 46%
>> USABLE 1174K 555329 46%
>> Ready; T=0.01/0.01 10:39:04
>> 
>> 
>> As the Q DUMP shows, the dump used to be spread roughly 
>> evenly between my=
>>  
>> 2 SPOOL packs.  Now it's concentrated on one pack.  Rats.
>> 
>> It also *grew* in size from 531420 pages to 546256 pages.  
>> It's only 2.8%=
>>  
>> larger, but it was unexpected.
>> 
>> q cplevel
>> z/VM Version 5 Release 2.0, service level 0501 (64-bit)
>> Generated at 03/01/06 12:37:45 MDT
>> IPL at 03/26/06 09:48:10 MDT
>> 
>> Brian Nielsen
>> 
>> 
>> On Fri, 13 Oct 2006 09:29:16 -0700, Schuh, Richard 
>> <[EMAIL PROTECTED]> wrot=
>> e:
>> 
>> >And at least the larger of the 2 will grow over time, 
>> depending on the =
>> 
>> amount of space needed to include all pages devoted to CP. 
>> This has been =
>> 
>> thoroughly discussed in this forum in the fairly recent past. 
>> SPXTAPE was=
>>  
>> named as a big contributor to the growth. The only way to 
>> scale the dump =
>> 
>> file back is to SET DUMP DASD. It is not necessary to SET 
>> DUMP OFF first,=
>>  
>> the SET DUMP DASD causes the file to be reallocated.
>> > 
>> >Regards, 
>> >Richard Schuh 
>> 
>
=
===

Re: VM SPOOL question

[Schuh, Richard]

SPOOLCHN is great for diagnosing problems in spool and for determining which 
spool files have blocks allocated on a given pack. It does take a long time to 
run on a spool system that has 10 packs and over 10,000 spool files. It is not 
stand-alone. There is another package, I forget its name, on the IBM VM 
Download page that it needs.

Regards,
Richard Schuh


> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of Jim Bohnsack
> Sent: Friday, October 13, 2006 10:00 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM SPOOL question
> 
> 
> I'll second the SPOOLCHN suggestion.  I've never had VM:SPOOL so I 
> probably don't know what I'm missing, but SPOOLCHN is great.
> 
> Jim
> 
> Huegel, Thomas wrote:
> > This is a multi-part message in MIME format.
> >
> > --_=_NextPart_001_01C6EEE1.D03604F2
> > X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 
> F54095E7-2D01-4AE2-A988-8830DD6030C5
> > Content-Transfer-Encoding: 7bit
> > Content-Type: text/plain;
> > charset="iso-8859-1"
> >
> > Not an answer to your question, but you might want to go to 
> the download
> > page and get SPOOLCHN it may help
> >   
> 
> -- 
> Jim Bohnsack
> Cornell University
> (607) 255-1760
> [EMAIL PROTECTED]
> 

Re: VM SPOOL question

[Stracka, James (GTI)]

We dedicate a 3390-9 for DUMP as the dump space must be contiguous.  In
the system configuration file is:
   CP_Owned   Slot  10  VMDMP1 DUMP

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Friday, October 13, 2006 1:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM SPOOL question


If you have another pack that you can use, I would suggest formatting
it, allocating it a SPOL pack, and designating it as a dump pack in your
system config. That 91% that you see for Z52SP2 is mostly allocated for
DUMP. You have, in effect, a 1-pack SPOOL system plus the DUMP files.
Since contiguous pages are allocated for the dumps at ipl (unless DUMP
is set OFF), you will always see the disparity between the 2 packs and
all of almost all of your normal spooling will be on the other,
non-dump, pack.   

Regards,
Richard Schuh


> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of Brian Nielsen
> Sent: Friday, October 13, 2006 9:56 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM SPOOL question
> 
> 
> I decided to see what SET DUMP DASD would do on my system as far as
> reclaiming any DUMP space growth caused by SPXTAPE over time. 
>  Here is =
> 
> what I got:
> 
> q dump
> DASD dump space CP IPL
> RDEV PAGES
>  -
> 661F 278346
> 6748 253074
> Ready; T=0.01/0.01 10:37:25
> set dump dasd
> DASD 661F dump unit CP IPL pages 546256
> Ready; T=0.01/0.01 10:37:45
> q alloc spool
> EXTENT EXTENT  TOTAL  PAGES   HIGH%
> VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
> --  -- -- -- -- -- 
> Z52SP1 6748  1   3338 600840   8516 585886   1%
> Z52SP2 661F  1   3338 600840 546813 35  91%
>   -- --
> SUMMARY1174K 555329 46%
> USABLE 1174K 555329 46%
> Ready; T=0.01/0.01 10:39:04
> 
> 
> As the Q DUMP shows, the dump used to be spread roughly
> evenly between my=
>  
> 2 SPOOL packs.  Now it's concentrated on one pack.  Rats.
> 
> It also *grew* in size from 531420 pages to 546256 pages.
> It's only 2.8%=
>  
> larger, but it was unexpected.
> 
> q cplevel
> z/VM Version 5 Release 2.0, service level 0501 (64-bit) Generated at 
> 03/01/06 12:37:45 MDT IPL at 03/26/06 09:48:10 MDT
> 
> Brian Nielsen
> 
> 
> On Fri, 13 Oct 2006 09:29:16 -0700, Schuh, Richard
> <[EMAIL PROTECTED]> wrot=
> e:
> 
> >And at least the larger of the 2 will grow over time,
> depending on the =
> 
> amount of space needed to include all pages devoted to CP.
> This has been =
> 
> thoroughly discussed in this forum in the fairly recent past.
> SPXTAPE was=
>  
> named as a big contributor to the growth. The only way to
> scale the dump =
> 
> file back is to SET DUMP DASD. It is not necessary to SET
> DUMP OFF first,=
>  
> the SET DUMP DASD causes the file to be reallocated.
> > 
> >Regards,
> >Richard Schuh 
>


If you are not an intended recipient of this e-mail, please notify the sender, 
delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail. http://www.ml.com/email_terms/

Re: VM SPOOL question

[Schuh, Richard]

If you have another pack that you can use, I would suggest formatting it, 
allocating it a SPOL pack, and designating it as a dump pack in your system 
config. That 91% that you see for Z52SP2 is mostly allocated for DUMP. You 
have, in effect, a 1-pack SPOOL system plus the DUMP files. Since contiguous 
pages are allocated for the dumps at ipl (unless DUMP is set OFF), you will 
always see the disparity between the 2 packs and all of almost all of your 
normal spooling will be on the other, non-dump, pack.   

Regards,
Richard Schuh


> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of Brian Nielsen
> Sent: Friday, October 13, 2006 9:56 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: VM SPOOL question
> 
> 
> I decided to see what SET DUMP DASD would do on my system as far as 
> reclaiming any DUMP space growth caused by SPXTAPE over time. 
>  Here is =
> 
> what I got:
> 
> q dump
> DASD dump space CP IPL
> RDEV PAGES
>  -
> 661F 278346
> 6748 253074
> Ready; T=0.01/0.01 10:37:25
> set dump dasd
> DASD 661F dump unit CP IPL pages 546256
> Ready; T=0.01/0.01 10:37:45
> q alloc spool
> EXTENT EXTENT  TOTAL  PAGES   HIGH%
> VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
> --  -- -- -- -- -- 
> Z52SP1 6748  1   3338 600840   8516 585886   1%
> Z52SP2 661F  1   3338 600840 546813 35  91%
>   -- --
> SUMMARY1174K 555329 46%
> USABLE 1174K 555329 46%
> Ready; T=0.01/0.01 10:39:04
> 
> 
> As the Q DUMP shows, the dump used to be spread roughly 
> evenly between my=
>  
> 2 SPOOL packs.  Now it's concentrated on one pack.  Rats.
> 
> It also *grew* in size from 531420 pages to 546256 pages.  
> It's only 2.8%=
>  
> larger, but it was unexpected.
> 
> q cplevel
> z/VM Version 5 Release 2.0, service level 0501 (64-bit)
> Generated at 03/01/06 12:37:45 MDT
> IPL at 03/26/06 09:48:10 MDT
> 
> Brian Nielsen
> 
> 
> On Fri, 13 Oct 2006 09:29:16 -0700, Schuh, Richard 
> <[EMAIL PROTECTED]> wrot=
> e:
> 
> >And at least the larger of the 2 will grow over time, 
> depending on the =
> 
> amount of space needed to include all pages devoted to CP. 
> This has been =
> 
> thoroughly discussed in this forum in the fairly recent past. 
> SPXTAPE was=
>  
> named as a big contributor to the growth. The only way to 
> scale the dump =
> 
> file back is to SET DUMP DASD. It is not necessary to SET 
> DUMP OFF first,=
>  
> the SET DUMP DASD causes the file to be reallocated.
> > 
> >Regards, 
> >Richard Schuh 
> 

Re: VM SPOOL question

[Jim Bohnsack]

I'll second the SPOOLCHN suggestion.  I've never had VM:SPOOL so I 
probably don't know what I'm missing, but SPOOLCHN is great.


Jim

Huegel, Thomas wrote:

This is a multi-part message in MIME format.

--_=_NextPart_001_01C6EEE1.D03604F2
X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 
F54095E7-2D01-4AE2-A988-8830DD6030C5
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset="iso-8859-1"

Not an answer to your question, but you might want to go to the download
page and get SPOOLCHN it may help
  


--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: VM SPOOL question

[Brian Nielsen]

I decided to see what SET DUMP DASD would do on my system as far as 
reclaiming any DUMP space growth caused by SPXTAPE over time.  Here is 

what I got:

q dump
DASD dump space CP IPL
RDEV PAGES
 -
661F 278346
6748 253074
Ready; T=0.01/0.01 10:37:25
set dump dasd
DASD 661F dump unit CP IPL pages 546256
Ready; T=0.01/0.01 10:37:45
q alloc spool
EXTENT EXTENT  TOTAL  PAGES   HIGH%
VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
--  -- -- -- -- -- 
Z52SP1 6748  1   3338 600840   8516 585886   1%
Z52SP2 661F  1   3338 600840 546813 35  91%
  -- --
SUMMARY1174K 555329 46%
USABLE 1174K 555329 46%
Ready; T=0.01/0.01 10:39:04


As the Q DUMP shows, the dump used to be spread roughly evenly between my
 
2 SPOOL packs.  Now it's concentrated on one pack.  Rats.

It also *grew* in size from 531420 pages to 546256 pages.  It's only 2.8%
 
larger, but it was unexpected.

q cplevel
z/VM Version 5 Release 2.0, service level 0501 (64-bit)
Generated at 03/01/06 12:37:45 MDT
IPL at 03/26/06 09:48:10 MDT

Brian Nielsen


On Fri, 13 Oct 2006 09:29:16 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrot
e:

>And at least the larger of the 2 will grow over time, depending on the 

amount of space needed to include all pages devoted to CP. This has been 

thoroughly discussed in this forum in the fairly recent past. SPXTAPE was
 
named as a big contributor to the growth. The only way to scale the dump 

file back is to SET DUMP DASD. It is not necessary to SET DUMP OFF first,
 
the SET DUMP DASD causes the file to be reallocated.
> 
>Regards, 
>Richard Schuh

Re: VM SPOOL question

[William Boyer]

That did
it.  I did the SET DUMP DASD and I
am now down to 43% of the spooling space used.  

 

Thanks to
all who responded.

 

William L. Boyer
Senior Systems Programmer

 

ViPSÒ, an Emdeon Company

One West
Pennsylvania Avenue

Baltimore,
MD  21204

Office:  410.832.8300 ext. 8419

Fax: 410.832.8327

 

This message is confidential,
intended only for the named recipient(s) and may contain information that is
privileged or exempt from disclosure under applicable law.  If you are not the
intended recipient(s), you are notified that the dissemination, distribution,
or copying of this message is strictly prohibited.  If you receive this
message in error or are not the named recipient(s), please notify the sender at
either the fax address or telephone number above and delete this message.  Thank you.

 

-Original
Message-
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On
Behalf Of Schuh, Richard
Sent: Friday, October 13, 2006
12:29 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM SPOOL question

 

And at least the larger
of the 2 will grow over time, depending on the amount of space needed to
include all pages devoted to CP. This has been thoroughly
discussed in this forum in the fairly recent past. SPXTAPE was named as a
big contributor to the growth. The only way to scale the dump file back is to
SET DUMP DASD. It is not necessary to SET DUMP OFF first, the SET DUMP
DASD causes the file to be reallocated.

 

Regards, 
Richard Schuh 



-Original Message-
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On
Behalf Of Bates, Bob
Sent: Friday, October 13, 2006
9:13 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM SPOOL question

Yeah, I didn't think
about it long enough. What can I say, it's Friday.  

-Original
Message-
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On
Behalf Of Schuh, Richard
Sent: Friday, October 13, 2006
11:07 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM SPOOL question

They are holding space.
CP carves out contiguous blocks of space for them and reserves it for dumps.

 

Regards, 
Richard Schuh 





-Original
Message-
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On
Behalf Of Bates, Bob
Sent: Friday, October 13, 2006
9:02 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM SPOOL question

I don't think those files
are holding any space, they are open for a system dump should one occur. 

 

You say you've checked
RDR and PRT, have you looked to PUN? There are a number of ways things can end
up there and I always manage to overlook it when I'm checking. That's one of
the reasons I like VM:Spool... 

 

Bob Bates
Citigroup Technology Infrastructure
817-317-8033 

-Original
Message-
From: The IBM z/VM Operating
System [mailto:[EMAIL PROTECTED]On
Behalf Of William Boyer
Sent: Friday, October 13, 2006
10:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: VM SPOOL question

My VM SPOOL is at 74%
used.  Normally I run a REXX/PIPE
that does a Q RDR EXP and calculates the blocks used by each user and gives me
a list of the top 10.  Normally
this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a large amount:

 

*  Source  
Available   Num
files   In Use   % full  * 

*  --  
-   -   --   --  * 

*
Q ALLOC SPOOL:   
1174K   --- 894001 74%   * 

*
SPOOLHOG calculated:  ---    2719 218984     ---   *

 

NOTE:  I have two 3390-3’s dedicated to VM
SPOOL.

 

I modified the exec to do a
Q PRT EXP and that only shows about 5000 more blocks in use.  After some looking around I found these
two spool files in OPERATNS userid:

 

q rdr operatns all   

ORIGINID FILE CLASS
RECORDS  CPY HOLD DATE  TIME NAME  TYPE DIST 


SYSTEM   9465 D SYS  001 NONE
OPEN- SYS
SYSTEM

SYSTEM   9696 D SYS  001 NONE
OPEN- SYS 
CPDUMP   
CPDUMP 

 

They do not have records
but then again they are not closed. 
Could these two rdr spool files be what is hogging up my spool?  If not does anyone have a suggestion as
where to look next?  Thanks.

 

William L. Boyer
Senior Systems Programmer

 

ViPSÒ, an Emdeon Company

One West Pennsylvania Avenue

Baltimore, MD  21204

Office:  410.832.8300 ext.
8419

Fax:
410.832.8327

 

This message is confidential, intended only for the named recipient(s)
and may contain information that is privileged or exempt from disclosure under
applicable law.  If you are not the intended recipient(s),
you are notified that the dissemination, distribution, or copying of this
message is strictly prohibited.  If you receive this
message in error or are not the named recipient(s), please notify the sender at
either the fax address or telephone number above and delete this message.  Thank you.

 

Re: VM SPOOL question

[Schuh, Richard]

And at least 
the larger of the 2 will grow over time, depending on the amount of space needed 
to include all pages devoted to CP. This has been thoroughly 
discussed in this forum in the fairly recent past. SPXTAPE was named as a 
big contributor to the growth. The only way to scale the dump file back is to 
SET DUMP DASD. It is not necessary to SET DUMP OFF first, the SET DUMP DASD 
causes the file to be reallocated.
 
Regards, Richard 
Schuh 

  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of Bates, 
  BobSent: Friday, October 13, 2006 9:13 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
  question
  Yeah, I didn't think about it long enough. What can I say, it's Friday. 
   
  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of Schuh, 
  RichardSent: Friday, October 13, 2006 11:07 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
  question
  They are 
  holding space. CP carves out contiguous blocks of space for them and reserves 
  it for dumps.
   
  Regards, Richard Schuh 
  
-Original Message-From: The IBM z/VM Operating 
System [mailto:[EMAIL PROTECTED]On Behalf Of Bates, 
BobSent: Friday, October 13, 2006 9:02 AMTo: 
IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
question
I 
don't think those files are holding any space, they are open for a system 
dump should one occur. 
 
You say you've checked RDR and PRT, have you looked to PUN? There are 
a number of ways things can end up there and I always manage to overlook it 
when I'm checking. That's one of the reasons I like VM:Spool... 

 

Bob BatesCitigroup Technology 
Infrastructure817-317-8033 
-Original Message-From: The IBM z/VM Operating 
System [mailto:[EMAIL PROTECTED]On Behalf Of William 
BoyerSent: Friday, October 13, 2006 10:55 AMTo: 
IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
question

My 
VM SPOOL is at 74% used.  
Normally I run a REXX/PIPE that does a Q RDR EXP and calculates the 
blocks used by each user and gives me a list of the top 10.  Normally this comes close to what 
the Q SPOOL ALLOC shows.  
However, today the two are off by a large 
amount:
 
*  Source   
Available   Num 
files   In Use   % full  * 

*  --   
-   
-   
--   --  * 

* 
Q ALLOC SPOOL:    
1174K   
--- 
894001 
74%   * 

* 
SPOOLHOG calculated:  ---    
2719 
218984 
---   
*
 
NOTE:  I have two 3390-3’s dedicated to VM 
SPOOL.
 
I 
modified the exec to do a Q PRT EXP and that only shows about 5000 more 
blocks in use.  After some 
looking around I found these two spool files in OPERATNS 
userid:
 
q 
rdr operatns all   

ORIGINID 
FILE CLASS RECORDS  CPY HOLD 
DATE  TIME NAME  TYPE DIST  
SYSTEM   9465 D SYS  001 NONE 
OPEN- SYS 
SYSTEM
SYSTEM   9696 D SYS  001 NONE 
OPEN- SYS  
CPDUMP    
CPDUMP 

 
They 
do not have records but then again they are not closed.  Could these two rdr spool files be 
what is hogging up my spool?  If 
not does anyone have a suggestion as where to look next?  
Thanks.
 
William 
L. BoyerSenior 
Systems Programmer
 
ViPSÒ, 
an 
Emdeon Company
One 
West Pennsylvania Avenue
Baltimore, 
MD  
21204
Office:  410.832.8300 ext. 
8419
Fax: 
410.832.8327
 
This 
message is confidential, intended only for the named recipient(s) and may 
contain information that is privileged or exempt from disclosure under 
applicable law. 
 If you are not the intended 
recipient(s), you are notified that the dissemination, distribution, or 
copying of this message is strictly 
prohibited. 
 If you receive this message in error 
or are not the named recipient(s), please notify the sender at either the 
fax address or telephone number above and delete this 
message. 
 Thank you.
 

Re: VM SPOOL question

[Bates, Bob]

Yeah, 
I didn't think about it long enough. What can I say, it's Friday. 
 
-Original Message-From: The IBM z/VM Operating System 
[mailto:[EMAIL PROTECTED]On Behalf Of Schuh, 
RichardSent: Friday, October 13, 2006 11:07 AMTo: 
IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
question
They are 
holding space. CP carves out contiguous blocks of space for them and reserves it 
for dumps.
 
Regards, Richard Schuh 

  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of Bates, 
  BobSent: Friday, October 13, 2006 9:02 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
  question
  I 
  don't think those files are holding any space, they are open for a system dump 
  should one occur. 
   
  You 
  say you've checked RDR and PRT, have you looked to PUN? There are a number of 
  ways things can end up there and I always manage to overlook it when I'm 
  checking. That's one of the reasons I like VM:Spool... 
   
  
  Bob BatesCitigroup Technology 
  Infrastructure817-317-8033 
  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of William 
  BoyerSent: Friday, October 13, 2006 10:55 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
  question
  
  My VM 
  SPOOL is at 74% used.  Normally I 
  run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
  user and gives me a list of the top 10.  
  Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
  large amount:
   
  *  Source   
  Available   Num 
  files   In Use   % full  * 
  *  --   
  -   
  -   
  --   --  * 
  * 
  Q ALLOC SPOOL:    
  1174K   --- 894001 74%   * 
  
  * 
  SPOOLHOG calculated:  ---    
  2719 
  218984 
  ---   
  *
   
  NOTE:  I have two 3390-3’s dedicated to VM 
  SPOOL.
   
  I 
  modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
  in use.  After some looking around 
  I found these two spool files in OPERATNS 
  userid:
   
  q rdr 
  operatns all   
  
  ORIGINID 
  FILE CLASS RECORDS  CPY HOLD 
  DATE  TIME NAME  TYPE DIST  
  SYSTEM   9465 D SYS  001 NONE 
  OPEN- SYS 
  SYSTEM
  SYSTEM   9696 D SYS  001 NONE 
  OPEN- SYS  
  CPDUMP    
  CPDUMP 
  
   
  They 
  do not have records but then again they are not closed.  Could these two rdr spool files be 
  what is hogging up my spool?  If 
  not does anyone have a suggestion as where to look next?  
  Thanks.
   
  William 
  L. BoyerSenior 
  Systems Programmer
   
  ViPSÒ, 
  an 
  Emdeon Company
  One 
  West Pennsylvania Avenue
  Baltimore, 
  MD  
  21204
  Office:  410.832.8300 ext. 
  8419
  Fax: 
  410.832.8327
   
  This 
  message is confidential, intended only for the named recipient(s) and may 
  contain information that is privileged or exempt from disclosure under 
  applicable law. 
   If you are not the intended 
  recipient(s), you are notified that the dissemination, distribution, or 
  copying of this message is strictly 
  prohibited. 
   If you receive this message in error or 
  are not the named recipient(s), please notify the sender at either the fax 
  address or telephone number above and delete this 
  message. 
   Thank you.
   

Re: VM SPOOL question

[Huegel, Thomas]

Not an 
answer to your question, but you might want to go to the download page and get 
SPOOLCHN it may help.

  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of William 
  BoyerSent: Friday, October 13, 2006 10:55 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
  question
  
  My VM 
  SPOOL is at 74% used.  Normally I 
  run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
  user and gives me a list of the top 10.  
  Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
  large amount:
   
  *  Source   
  Available   Num 
  files   In Use   % full  * 
  *  --   
  -   
  -   
  --   --  * 
  * 
  Q ALLOC SPOOL:    
  1174K   --- 894001 74%   * 
  * 
  SPOOLHOG calculated:  ---    
  2719 
  218984 
  ---   
  *
   
  NOTE:  I have two 3390-3's dedicated to VM 
  SPOOL.
   
  I 
  modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
  in use.  After some looking around 
  I found these two spool files in OPERATNS userid:
   
  q rdr 
  operatns all   
  
  ORIGINID 
  FILE CLASS RECORDS  CPY HOLD 
  DATE  TIME NAME  TYPE DIST  
  SYSTEM   9465 D SYS  001 NONE 
  OPEN- SYS 
  SYSTEM
  SYSTEM   9696 D SYS  001 NONE 
  OPEN- SYS  
  CPDUMP    
  CPDUMP 
  
   
  They 
  do not have records but then again they are not closed.  Could these two rdr spool files be 
  what is hogging up my spool?  If 
  not does anyone have a suggestion as where to look next?  Thanks.
   
  William 
  L. BoyerSenior 
  Systems Programmer
   
  ViPSÒ, 
  an 
  Emdeon Company
  One 
  West Pennsylvania Avenue
  Baltimore, 
  MD  21204
  Office:  410.832.8300 ext. 
  8419
  Fax: 
  410.832.8327
   
  This 
  message is confidential, intended only for the named recipient(s) and may 
  contain information that is privileged or exempt from disclosure under 
  applicable law. 
   If you are not the intended 
  recipient(s), you are notified that the dissemination, distribution, or 
  copying of this message is strictly 
  prohibited. 
   If you receive this message in error or 
  are not the named recipient(s), please notify the sender at either the fax 
  address or telephone number above and delete this 
  message. 
   Thank you.
   



  
<< ella for Spam Control >> has removed 
  7494 VSE-List messages and set aside 5065 VM-List for 
  meYou can use it too - and it's FREE!  www.ellaforspam.com

Re: VM SPOOL question

[Jim Bohnsack]

Those two big files are CP pre-allocated dump files that are there as a 
"just in case".  You could set dump off but then if a problem did occur, 
you'd be out of luck.  A few years and/or releases ago, there was a 
problem with the CP dump space growing over time.  At that time,  I set 
a timer pop in my VMSCHED machine to set the dump off and 10 minutes 
later set it back on.  I don't know if the growing dump files are sill a 
problem, but doing that doesn't hurt, unless of course, an abend happens 
just as you turn off the dump space.


Jim

William Boyer wrote:

This is a multi-part message in MIME format.

--_=_NextPart_001_01C6EEDF.F0DC780E
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My VM SPOOL is at 74% used.  Normally I run a REXX/PIPE that does a Q =
RDR EXP and calculates the blocks used by each user and gives me a list =
of the top 10.  Normally this comes close to what the Q SPOOL ALLOC =
shows.  However, today the two are off by a large amount:
=20
*  Source   Available   Num files   In Use   % full  *=20
*  --   -   -   --   --  *=20
* Q ALLOC SPOOL:1174K   --- 894001 74%   *=20
* SPOOLHOG calculated:  ---2719 218984 ---   *
=20
NOTE:  I have two 3390-3's dedicated to VM SPOOL.
=20
I modified the exec to do a Q PRT EXP and that only shows about 5000 =
more blocks in use.  After some looking around I found these two spool =
files in OPERATNS userid:
=20
q rdr operatns all   =
   =20
ORIGINID FILE CLASS RECORDS  CPY HOLD DATE  TIME NAME  TYPE =
DIST =20
SYSTEM   9465 D SYS  001 NONE OPEN- SYS =
SYSTEM
SYSTEM   9696 D SYS  001 NONE OPEN- SYS  CPDUMPCPDUMP=
=20
=20
They do not have records but then again they are not closed.  Could =
these two rdr spool files be what is hogging up my spool?  If not does =
anyone have a suggestion as where to look next?  Thanks.
=20
William L. Boyer
Senior Systems Programmer
=20
ViPS*, an Emdeon Company
One West Pennsylvania Avenue
Baltimore, MD  21204
Office:  410.832.8300 ext. 8419
Fax: 410.832.8327
=20
This message is confidential, intended only for the named recipient(s) =
and may contain information that is privileged or exempt from disclosure =
under applicable law.  If you are not the intended recipient(s), you are =
notified that the dissemination, distribution, or copying of this =
message is strictly prohibited.  If you receive this message in error or =
are not the named recipient(s), please notify the sender at either the =
fax address or telephone number above and delete this message.  Thank =
you.
=20
  


--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: VM SPOOL question

[Schuh, Richard]

They are 
holding space. CP carves out contiguous blocks of space for them and reserves it 
for dumps.
 
Regards, Richard Schuh 

  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of Bates, 
  BobSent: Friday, October 13, 2006 9:02 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: Re: VM SPOOL 
  question
  I 
  don't think those files are holding any space, they are open for a system dump 
  should one occur. 
   
  You 
  say you've checked RDR and PRT, have you looked to PUN? There are a number of 
  ways things can end up there and I always manage to overlook it when I'm 
  checking. That's one of the reasons I like VM:Spool... 
   
  
  Bob BatesCitigroup Technology 
  Infrastructure817-317-8033 
  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of William 
  BoyerSent: Friday, October 13, 2006 10:55 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
  question
  
  My VM 
  SPOOL is at 74% used.  Normally I 
  run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
  user and gives me a list of the top 10.  
  Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
  large amount:
   
  *  Source   
  Available   Num 
  files   In Use   % full  * 
  *  --   
  -   
  -   
  --   --  * 
  * 
  Q ALLOC SPOOL:    
  1174K   --- 894001 74%   * 
  
  * 
  SPOOLHOG calculated:  ---    
  2719 
  218984 
  ---   
  *
   
  NOTE:  I have two 3390-3’s dedicated to VM 
  SPOOL.
   
  I 
  modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
  in use.  After some looking around 
  I found these two spool files in OPERATNS 
  userid:
   
  q rdr 
  operatns all   
  
  ORIGINID 
  FILE CLASS RECORDS  CPY HOLD 
  DATE  TIME NAME  TYPE DIST  
  SYSTEM   9465 D SYS  001 NONE 
  OPEN- SYS 
  SYSTEM
  SYSTEM   9696 D SYS  001 NONE 
  OPEN- SYS  
  CPDUMP    
  CPDUMP 
  
   
  They 
  do not have records but then again they are not closed.  Could these two rdr spool files be 
  what is hogging up my spool?  If 
  not does anyone have a suggestion as where to look next?  
  Thanks.
   
  William 
  L. BoyerSenior 
  Systems Programmer
   
  ViPSÒ, 
  an 
  Emdeon Company
  One 
  West Pennsylvania Avenue
  Baltimore, 
  MD  
  21204
  Office:  410.832.8300 ext. 
  8419
  Fax: 
  410.832.8327
   
  This 
  message is confidential, intended only for the named recipient(s) and may 
  contain information that is privileged or exempt from disclosure under 
  applicable law. 
   If you are not the intended 
  recipient(s), you are notified that the dissemination, distribution, or 
  copying of this message is strictly 
  prohibited. 
   If you receive this message in error or 
  are not the named recipient(s), please notify the sender at either the fax 
  address or telephone number above and delete this 
  message. 
   Thank you.
   

Re: VM SPOOL question

[Stracka, James (GTI)]

Title: Message



Do a 
QUERY DUMP to see how much is allocated to DUMP space.  Also, QUERY SDF to 
show the SDF files, then QUERY NSS  and QUERY TRF if you are running 
external traces.   This in addition to QUERY PUNCH 
EXP.

  
  -Original Message-From: The IBM z/VM 
  Operating System [mailto:[EMAIL PROTECTED] On Behalf Of William 
  BoyerSent: Friday, October 13, 2006 11:55 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
  question
  
  My VM 
  SPOOL is at 74% used.  Normally I 
  run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
  user and gives me a list of the top 10.  
  Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
  large amount:
   
  *  Source   
  Available   Num 
  files   In Use   % full  * 
  *  --   
  -   
  -   
  --   --  * 
  * 
  Q ALLOC SPOOL:    
  1174K   --- 894001 74%   * 
  
  * 
  SPOOLHOG calculated:  ---    
  2719 
  218984 
  ---   
  *
   
  NOTE:  I have two 3390-3’s dedicated to VM 
  SPOOL.
   
  I 
  modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
  in use.  After some looking around 
  I found these two spool files in OPERATNS 
  userid:
   
  q rdr 
  operatns all   
  
  ORIGINID 
  FILE CLASS RECORDS  CPY HOLD 
  DATE  TIME NAME  TYPE DIST  
  SYSTEM   9465 D SYS  001 NONE 
  OPEN- SYS 
  SYSTEM
  SYSTEM   9696 D SYS  001 NONE 
  OPEN- SYS  
  CPDUMP    
  CPDUMP 
  
   
  They 
  do not have records but then again they are not closed.  Could these two rdr spool files be 
  what is hogging up my spool?  If 
  not does anyone have a suggestion as where to look next?  
  Thanks.
   
  William 
  L. BoyerSenior 
  Systems Programmer
   
  ViPSÒ, 
  an 
  Emdeon Company
  One 
  West Pennsylvania Avenue
  Baltimore, 
  MD  
  21204
  Office:  410.832.8300 ext. 
  8419
  Fax: 
  410.832.8327
   
  This 
  message is confidential, intended only for the named recipient(s) and may 
  contain information that is privileged or exempt from disclosure under 
  applicable law. 
   If you are not the intended 
  recipient(s), you are notified that the dissemination, distribution, or 
  copying of this message is strictly 
  prohibited. 
   If you receive this message in error or 
  are not the named recipient(s), please notify the sender at either the fax 
  address or telephone number above and delete this 
  message. 
   Thank you.
   

Re: VM SPOOL question

[Brian Nielsen]

Those files are for the CP dump.  Perhaps in the past you didn't have DUM
P 
turned on.  Doing a Q DUMP will tell you how many SPOOL pages are reserve
d 
for the CP DUMP.  The SET DUMP command is used to turn DUMP on or off and
 
to where.

Brian Nielsen

On Fri, 13 Oct 2006 11:55:01 -0400, William Boyer <[EMAIL PROTECTED]> wrote
:

>My VM SPOOL is at 74% used.  Normally I run a REXX/PIPE that does a Q RD
R 
EXP and calculates the blocks used by each user and gives me a list of th
e 
top 10.  Normally this comes close to what the Q SPOOL ALLOC shows.  

However, today the two are off by a large amount:
> 
>*  Source   Available   Num files   In Use   % full  * 
>*  --   -   -   --   --  * 
>* Q ALLOC SPOOL:1174K   --- 894001 74%   * 
>* SPOOLHOG calculated:  ---2719 218984 ---   *
> 
>NOTE:  I have two 3390-3's dedicated to VM SPOOL.
> 
>I modified the exec to do a Q PRT EXP and that only shows about 5000 mor
e 
blocks in use.  After some looking around I found these two spool files i
n 
OPERATNS userid:
> 
>q rdr operatns 
all
 
  
>ORIGINID FILE CLASS RECORDS  CPY HOLD DATE  TIME NAME  TYPE  
   
DIST  
>SYSTEM   9465 D SYS  001 NONE OPEN- SYS 

SYSTEM
>SYSTEM   9696 D SYS  001 NONE OPEN- SYS  CPDUMP
CPDUMP 
> 
>They do not have records but then again they are not closed.  Could thes
e 
two rdr spool files be what is hogging up my spool?  If not does anyone 

have a suggestion as where to look next?  Thanks.
> 
>William L. Boyer
>Senior Systems Programmer
> 
>ViPS*, an Emdeon Company
>One West Pennsylvania Avenue
>Baltimore, MD  21204
>Office:  410.832.8300 ext. 8419
>Fax: 410.832.8327
> 
>This message is confidential, intended only for the named recipient(s) 

and may contain information that is privileged or exempt from disclosure 

under applicable law.  If you are not the intended recipient(s), you are 

notified that the dissemination, distribution, or copying of this message
 
is strictly prohibited.  If you receive this message in error or are not 

the named recipient(s), please notify the sender at either the fax addres
s 
or telephone number above and delete this message.  Thank you.
> 
>

Re: VM SPOOL question

[Schuh, Richard]

Those files 
are the files created for system dumps - 1 for a soft abend dump, the other for 
a full dump. They will always be carved out of the spool system at IPL unless 
you SET DUMP OFF (a bad idea). Many shops create a full pack disk dedicated to 
the dump function so that (a) there will always be space available to allocate 
the dump files, and (b) free up the space on the ordinary spool disks for 
regular spool activity. 
 
Regards, Richard 
Schuh 

  -Original Message-From: The IBM z/VM Operating 
  System [mailto:[EMAIL PROTECTED]On Behalf Of William 
  BoyerSent: Friday, October 13, 2006 8:55 AMTo: 
  IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
  question
  
  My VM 
  SPOOL is at 74% used.  Normally I 
  run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
  user and gives me a list of the top 10.  
  Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
  large amount:
   
  *  Source   
  Available   Num 
  files   In Use   % full  * 
  *  --   
  -   
  -   
  --   --  * 
  * 
  Q ALLOC SPOOL:    
  1174K   --- 894001 74%   * 
  
  * 
  SPOOLHOG calculated:  ---    
  2719 
  218984 
  ---   
  *
   
  NOTE:  I have two 3390-3’s dedicated to VM 
  SPOOL.
   
  I 
  modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
  in use.  After some looking around 
  I found these two spool files in OPERATNS 
  userid:
   
  q rdr 
  operatns all   
  
  ORIGINID 
  FILE CLASS RECORDS  CPY HOLD 
  DATE  TIME NAME  TYPE DIST  
  SYSTEM   9465 D SYS  001 NONE 
  OPEN- SYS 
  SYSTEM
  SYSTEM   9696 D SYS  001 NONE 
  OPEN- SYS  
  CPDUMP    
  CPDUMP 
  
   
  They 
  do not have records but then again they are not closed.  Could these two rdr spool files be 
  what is hogging up my spool?  If 
  not does anyone have a suggestion as where to look next?  
  Thanks.
   
  William 
  L. BoyerSenior 
  Systems Programmer
   
  ViPSÒ, 
  an 
  Emdeon Company
  One 
  West Pennsylvania Avenue
  Baltimore, 
  MD  
  21204
  Office:  410.832.8300 ext. 
  8419
  Fax: 
  410.832.8327
   
  This 
  message is confidential, intended only for the named recipient(s) and may 
  contain information that is privileged or exempt from disclosure under 
  applicable law. 
   If you are not the intended 
  recipient(s), you are notified that the dissemination, distribution, or 
  copying of this message is strictly 
  prohibited. 
   If you receive this message in error or 
  are not the named recipient(s), please notify the sender at either the fax 
  address or telephone number above and delete this 
  message. 
   Thank you.
   

Re: VM SPOOL question

[Bates, Bob]

I 
don't think those files are holding any space, they are open for a system dump 
should one occur. 
 
You 
say you've checked RDR and PRT, have you looked to PUN? There are a number of 
ways things can end up there and I always manage to overlook it when I'm 
checking. That's one of the reasons I like VM:Spool... 
 

Bob BatesCitigroup Technology Infrastructure817-317-8033 

-Original Message-From: The IBM z/VM Operating System 
[mailto:[EMAIL PROTECTED]On Behalf Of William 
BoyerSent: Friday, October 13, 2006 10:55 AMTo: 
IBMVM@LISTSERV.UARK.EDUSubject: VM SPOOL 
question

My VM 
SPOOL is at 74% used.  Normally I 
run a REXX/PIPE that does a Q RDR EXP and calculates the blocks used by each 
user and gives me a list of the top 10.  
Normally this comes close to what the Q SPOOL ALLOC shows.  However, today the two are off by a 
large amount:
 
*  Source   
Available   Num 
files   In Use   % full  * 
*  --   
-   
-   --   --  * 
* 
Q ALLOC SPOOL:    
1174K   
--- 
894001 
74%   * 

* 
SPOOLHOG calculated:  ---    
2719 
218984 
---   
*
 
NOTE:  I have two 3390-3’s dedicated to VM 
SPOOL.
 
I 
modified the exec to do a Q PRT EXP and that only shows about 5000 more blocks 
in use.  After some looking around I 
found these two spool files in OPERATNS 
userid:
 
q rdr 
operatns all   

ORIGINID 
FILE CLASS RECORDS  CPY HOLD 
DATE  TIME NAME  TYPE DIST  
SYSTEM   9465 D SYS  001 NONE OPEN- 
SYS 
SYSTEM
SYSTEM   9696 D SYS  001 NONE OPEN- 
SYS  
CPDUMP    
CPDUMP 

 
They do 
not have records but then again they are not closed.  Could these two rdr spool files be what 
is hogging up my spool?  If not does 
anyone have a suggestion as where to look next?  
Thanks.
 
William 
L. BoyerSenior 
Systems Programmer
 
ViPSÒ, 
an 
Emdeon Company
One 
West Pennsylvania Avenue
Baltimore, 
MD  
21204
Office:  410.832.8300 ext. 
8419
Fax: 
410.832.8327
 
This 
message is confidential, intended only for the named recipient(s) and may 
contain information that is privileged or exempt from disclosure under 
applicable law. 
 If you are not the intended recipient(s), 
you are notified that the dissemination, distribution, or copying of this 
message is strictly prohibited. 
 If you receive this message in error or 
are not the named recipient(s), please notify the sender at either the fax 
address or telephone number above and delete this 
message. 
 Thank you.
 

VM SPOOL question

[William Boyer]

My VM SPOOL is at 74% used. 
Normally I run a REXX/PIPE that does a Q RDR EXP and calculates the
blocks used by each user and gives me a list of the top 10.  Normally this comes close to what the Q
SPOOL ALLOC shows.  However, today
the two are off by a large amount:

 

* 
Source  
Available   Num files   In Use   % full  * 

* 
--  
-   -   --   --  * 

* Q ALLOC SPOOL:   
1174K   --- 894001 74%   * 

* SPOOLHOG calculated:  ---    2719 218984 ---   *

 

NOTE:  I
have two 3390-3’s dedicated to VM SPOOL.

 

I modified the exec to do a Q PRT EXP and that only shows about 5000
more blocks in use.  After some
looking around I found these two spool files in OPERATNS userid:

 

q rdr operatns all  


ORIGINID FILE CLASS RECORDS 
CPY HOLD DATE  TIME NAME  TYPE DIST  

SYSTEM   9465 D SYS
 001 NONE OPEN- SYS
SYSTEM

SYSTEM   9696 D SYS
 001 NONE OPEN- SYS  CPDUMP    CPDUMP 

 

They do not have records but then again they are not closed.  Could these two rdr spool files be what
is hogging up my spool?  If not
does anyone have a suggestion as where to look next?  Thanks.

 

William L. Boyer
Senior Systems Programmer

 

ViPSÒ, an Emdeon Company

One West
Pennsylvania Avenue

Baltimore,
MD  21204

Office:  410.832.8300 ext. 8419

Fax: 410.832.8327

 

This message is confidential,
intended only for the named recipient(s) and may contain information that is
privileged or exempt from disclosure under applicable law.  If you are not the
intended recipient(s), you are notified that the dissemination, distribution,
or copying of this message is strictly prohibited.  If you receive this
message in error or are not the named recipient(s), please notify the sender at
either the fax address or telephone number above and delete this message.  Thank you.

 

CAVMEN Meeting on Thursday, October 19, 2006

[Chicago Area VM (and Linux) Enthusiasts]

The fourth quarter meeting of the Chicago Area VM (and Linux) 
Enthusiasts will be held on Thursday, October 19, 2006.



--


Meeting Location:

This quarter's meeting will be held at the Hewitt Associates 'East 
Campus' located at 100 Half Day Road, in Lincolnshire, IL. We will 
meet in the Lower Level Conference Room in Building 98 - back to our 
regular meeting location.


If you have not attended a meeting at this location before, or you 
are not familiar with the area, 
Click here for 
additional information on directions, maps, lodging and dining.



--


Attendance:

Our host site has requested a count of expected attendees by the 
Monday before the meeting, so that they can plan appropriately for 
refreshments, etc. If you are planning to attend, PLEASE send an 
E-Mail by that date to [EMAIL PROTECTED] 
with a subject line of "Meeting Attendance".


This is meant to be a facilities planning aid and should not be 
interpreted as a registration requirement. If you suddenly become 
available at the last minute, please feel free to attend even if you 
have not responded.


Thank you in advance for your cooperation in this matter.


--


Agenda:

9:00 AM z/VM Performance Update

The speaker will cover new developments in the z/VM performance area. 
Topics will include the latest z/VM releases and performance-related 
service. We will also look at some performance development in the 
area of Linux guest support.


The speaker will be Dr. Brian Wade of the IBM Corporation.

10:30 AMCoffee Break

11:00 AMAutomating Application Startup under Linux

The creation of automatic startup scripts for applications on Linux 
is poorly-documented and fraught with some peril in the early SUSE 
and RedHat releases. In this presentation, we'll go over what happens 
during Linux startup, the SysV init script structure that is used by 
most Linux distributions, and how to create scripts that can be 
safely integrated into the Linux startup process to start your 
applications at boot time. We'll look at automating and transforming 
some vendor-supplied startup processes for Oracle and DB2, and 
providing a flexible framework for building easily configurable 
startup scripts for new applications.


The speaker will be Dr. David Boyes of Sine Nomine Associates.

12:30 PMLunch Break

1:30 PM Administration and Vendor Announcements

1:45 PM Update on z/VM Systems and Storage Management 
Products from IBM


The focus of this session will be Backup and Restore Manager for z/VM 
V1.2, announced and available in August 2006. The speaker will also 
review anything new in Tape Manager and Operations Manager since 
their V1.2 releases in February 2006. A live demo will be included.


The speaker will be Ms. Tracy Dean of the IBM Corporation.

2:30 PM z/VM and Linux on System z Performance Monitoring - 
An Update on How and With What Products


z/VM is critical to the growing use of Linux on System z. Managing 
this environment requires insight into resource consumption at the 
z/VM level and at the Linux guest level. IBM's product offerings 
provide an integrated way to monitor (and manage) these performance 
characteristics. This presentation will discuss the current offerings 
and the new IBM OMEGAMON XE on z/VM and Linux, which IBM preview 
announced in August 2006.


The speaker will be Mr. Mac Holloway of IBM/Tivoli.

3:30 PM Coffee Break

3:45 PM Integrating IBM Solutions for System and Performance 
Management of z/VM and Linux on System z.


Management, including automation, often spans products and 
activities. These exist within a larger automation infrastructure and 
product set. This session will introduce scenarios that involve the 
integration of IBM z/VM system and performance management products, 
including IBM Operations Manager for z/VM and the recently announced 
IBM OMEGAMON XE on z/VM and Linux.


The speakers will be Ms. Tracy Dean and Mr. Mac Holloway of IBM.

4:45 PM Free-for-All

Members will attempt to answer any reasonable VM or hardware related 
questions. If you are having a problem and want to find out if others 
are experiencing it, or you are installing new hardware or software 
and want to find out what types of problems others have experienced, 
here is the place to find out.


Members are encouraged to bring ideas for future presentations and 
speakers to this meeting.


--

Please check the WEB site for Map and Directions:
http://cavmen.home.comcast.net

In addition, you will also find extensive information available on 
dining and lodging in the Hewitt Associates area.


Additional information about the CAVMEN group, and other VM related 
items of interest are available on our web site.


There is no charge for admission to meetings.

Meeting attendance is open to anyone, and advance registration is not required.

I

Re: Real core

[Tom Duerbusch]

Well, yea...

We have all done that.
As well as fax some pages.
Back in VM/IS days, the dumpscan tool (I think that was it) had a set
of panels around it.  Made things a lot easier.  We would give IBM the
dial up sequence for them to shoot problems.  We also started the
process to send the tape, just in case, it wasn't an easy problem and
they needed their "better" tools.

I was more wondering, when/how people transmitted large dumps in the
"old" days (pre-high speed Internet connections).  So far, it looks like
most was involved with 56K lease lines.  I guess the McAutos (McDonnall
Douglas) and BCS (Boeing) of the world might afford lease lines to their
venders, but for the rest of us  I was never involved in a situation
(before 2000 or so) where I could transmit a dump "AND" the vender could
receive it and be able to do something with it.

Tom Duerbusch
THD Consulting

>>> [EMAIL PROTECTED] 10/12/2006 10:00 AM >>>
On Wed, 11 Oct 2006 10:28:07 -0500, Tom Duerbusch 
<[EMAIL PROTECTED]> wrote:

>So I guess the question I'm wondering...
>
>How many others have shipped dumps, online, back before high speed
>Internet connections?

Why send the entire dump when they're only going to look at a tiny 
fraction of it?  On multiple occasions I did it live over the phone
with 
the support center.  They said what they wanted to look at and I read
it 
out to them.  So that's "on line" in one sense. 

We shipped tapes too, but not for the problems that were easy to
diagnose.

Brian Nielsen

Re: OSA configurations

[Brian Nielsen]

In short, yes.  The port would be set up as a trunk port so that all the 

traffic can reach it.  After that, traffic for the IP addresses registere
d 
to the OSA card by TCP stacks on the mainframe will be delivered to their
 
appropriate TCP stack, thus achieving whatever security access you've set
 
up.

You may want to use VLAN's in the network to further increase confidence 

in the isolation and security.  You would need to work with your network 

folks to set up the VLAN numbers & IP ranges that would correspond to
 the 
various access levels you defined.

Brian Nielsen

On Fri, 13 Oct 2006 10:20:00 -, Dusha, Cecelia Ms. WHS/ITMD 
<[EMAIL PROTECTED]> wrote:

>This is probably a dumb question, but I don't know the answer...
>
>Is it possible for a single OSA port to be a part of 3 different network

>types (trusted, private and public)?  In other words, can it be set up t
o
>use IPL addresses in the range of the trusted, private and public?  If s
o,
>what would be required on the network side to handle this?  And what are
 
the
>security repercussions?
>
>Presently we are considering:
>   OSA1 port 1 primary for general trusted access
>   OSA1 port 2 primary for IFL trusted access
>   OSA2 port 1 backup for general engine trusted access
>   OSA2 port 2 backup for IFL trusted access
>   OSA3 port 1 primary for public access
>   OSA3 port 2 primary for private access
>   OSA4 port 1 backup for public access
>   OSA4 port 2 backup for private access
>
>This achieves the isolation for each network type and can be easily 
managed.
>But an OSA card is capable of utilizing over 2000 IP addresses...
>
>Please advice.
>
>Thank you.
>
>Cecelia Dusha

OSA configurations

[Dusha, Cecelia Ms. WHS/ITMD]

This is probably a dumb question, but I don't know the answer...

Is it possible for a single OSA port to be a part of 3 different network
types (trusted, private and public)?  In other words, can it be set up to
use IPL addresses in the range of the trusted, private and public?  If so,
what would be required on the network side to handle this?  And what are the
security repercussions?

Presently we are considering:
OSA1 port 1 primary for general trusted access
OSA1 port 2 primary for IFL trusted access
OSA2 port 1 backup for general engine trusted access
OSA2 port 2 backup for IFL trusted access
OSA3 port 1 primary for public access
OSA3 port 2 primary for private access
OSA4 port 1 backup for public access
OSA4 port 2 backup for private access

This achieves the isolation for each network type and can be easily managed.
But an OSA card is capable of utilizing over 2000 IP addresses...

Please advice.

Thank you.

Cecelia Dusha

Re: Business case for restoring the PWD Flex license

[Len Diegel]

  
David, while I was once the relationship manager between FSI and 
IBM (working for IBM), I can only guess based on that history, what might 
be going on in either company.   I'm sure you already realize 
this is a very complex situation between two companies coming to 
terms with a number of issues and a multitude 
of options.   Unfortunately for all of us, the PWD 
program wound up in the middle.  
 
First, I am certain that FSI would continue their support of the PWD 
program, if they felt comfortable in doing so.  They have worked with 
IBM and the PWD resellers to provide several hundred licenses in support of that 
program, which seems to have been a success.  Apparently, FSI now 
feels a degree of risk due to the expiration of certain IBM patents on 
11/1 along with some agreements that are dated..  (Note:  This 
was covered in some detail on the FLEX LISTSERV..)  
Conversely, IBM owns the patents, approves zArch licenses for PWD 
use,  and simply expects FSI to 
continue delivering them via PWD resellers (Cornerstone and 
T3) for distribution to the PWD members.  It seems a simple 
enough matter to resolve and we all hope that will happen some 
time soon at least by November.
 
I suspect that both IBM and FSI are working hard to 
resolve the issues before them. Unfortunately, we can't predict if/when 
they will reach an agreement.   For this reason Steve 
Friedman (T3) and I have been notifying partners of the pending end 
date.  Hopefully, IBM and FSI will reach an agreement that benefits us 
all.  Whatever the outcome, Cornerstone intends to continue 
support for our PWD customers.
 
Regards,
Len Diegel
VP IBM zSeries &  zFrame Solutions
Cornerstone Systems Inc. 

Re: real core

[Anne & Lynn Wheeler]

Tom Duerbush wrote:
>So I guess the question I'm wondering...
>
>How many others have shipped dumps, online, back before high speed
>Internet connections?

re:
http://www.garlic.com/~lynn/2006s.html#16 memory, 360 lcs, 3090 extended
store, etc
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was:
real core)

we had done hsdt (high speed data transport) project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

in the 80s ... with high-speed backbone connected to the internal
network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

in the late 80s, they used to ship chip designs to high-speed hardware
logic simulator/checker in the late 80s. this was claimed to
contributed to helping bring in rios/power chip a year early.

we were also interested in participating in nsfnet-1 backbone
(which could be considered the operational precurser to the modern
internet). we weren't allowed to bid ... but did get an technical
review, one of the conclusions was what we had running and operational
was at least five years ahead of all the nsfnet-1 bids (RFP
responses) to build something new. slightly related
http://www.garlic.com/~lynn/internet.htm#0

and
http://www.garlic.com/~lynn/2002k.html#12 nsfnet program announcement
http://www.garlic.com/~lynn/2000e.html#10 nsfnet award announcement

for other drift, in the early days of rex (rexx), i wanted to
demonstrate that rex wasn't just another batch command processor
(exec, exec2) but could be used to implement very complex
application. I chose the vm problem/dump analyzer ... which was a
fairly large application written in assembler. i wanted to demonstrate
that in 3 months working half-time, i could implement in rex something
that had ten times the function and ten times the performance of the
existing assembler implementation. the result was dumprx
http://www.garlic.com/~lynn/subtopic.html#dumprx

which could be used to analyze a dump interactively ... even over the
internal network w/pvm (terminal emulation) ... w/o having to actually
ship the dump. part of dumprx was library of automated analysis
scripts ... the results could be saved and restored; aka you could run
the automated analysis scripts ... that batched the most common
sequence of manual analysis processes.

the library of batched analysis routines effectively automated most of
the most common (manual) analysis procedures (examined storage for
a broad range of failure signatures).