High CPU / channel ovhd w/3592 and DFDSS

[Michael R. Mayne]

Our environment is a single z9-BC mainframe (2096-R07(I01)), z/OS V1R9 @
RSU0906, a 3592-C06 tape controller w/2 FX4 channels, and 3592-E05 (TS1120)
tape drives.

We're performing initial testing towards migrating to current tape hardware
from (please don't ask, too embarrassed to tell). Using DFHSM (with DFDSS
as the data mover) to back up a single 18GB sequential file (non compressed)
to dual TS1120 tape drives is consuming over 50% of the total CPU. Looking
at the FICON performance numbers while this is happening, I see huge (25% to
40%) utilization numbers for the 2 FX4 CHPIDS driving the tape controller,
while the 2 FX4 CHPIDS connected to the DASD array are running only about 5%
utilization apiece. 50% of our CPU seems (to me, anyway) to be a high price
to pay to back up a single sequential file. I'm looking for (any or all of
these): similar experiences, is this normal or whacked out, any tuning or
performance tips that might help, how to determine exactly where the
overhead is coming from, and (last but not least) how to approach IBM to
address this issue. All constructive comments, questions and suggestions
appreciated.

Thanks.
-Mike

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Pommier, Rex R.]

Mike,

This is definitely not normal. It might not be a bad idea to tell us
what you are migrating from.

We have almost the same environment as you. We have a z9-BC (G01), z/OS
1.7, 3592-C06 with 1 FX4 channel, 3592-E05 tape drives. I upgraded from
3590s to the TS1120s and our utilization on the channel to the tape
drives as well as CPU utilization did not do anything even remotely
close to what you're experiencing. We are doing full volume dumps to 2
tape drives simultaneously for our nightly backups.

A couple ideas. Are your old tape drives so old that you have software
compression turned on in DFHSM? Are you doing any kind of
software-based encryption writing to these tapes?

Rex

[Longnecker, Dennis]

Anyone have, or know where I can get, a version of XMITMGR for Windows 7 64 bit PC? I find the program very useful when looking at files on the CBT tape and not being able to use it creates extra work for looking for stuff.

The version I have (version 3) says the version of the operating system is incompatible with the software.

Or, is there another way to look at the XMI files on the PC?

Thanks,
Dennis

[Michael R. Mayne]

OK, I'll 'fess - the old tape subsystem is a 3490-A20 controller with 2
3490-B40 drive units. The old tape subsystem has hardware compression, as
does the new. I'll check for software compression (never thought of it,
actually), but I doubt that it's turned on. If it was, I'd expect CPU (on
this box, which is a Uni) to be closer to 100% than 50%. Compression would
also not explain why the CHPID utilization for the tapes is so high (and I
think the CHPID utilization is directly related to the CPU overhead). Could
I have them defined inefficiently somehow in my IOCDS? Am I doing bad
things to tape performance with DFSMS DATACLAS or STORCLAS settings? I
guess I won't know exactly what's wrong until it's fixed...

Thanks.
-Mike

[Lizette Koehler]

Check on the PROPERTIES tab for the program and see if you have the
COMPATIBILITY tab. If so, you can probably tell it to use the 32 bit mode.
At least it works that way in VISTA.

Lizette

> Anyone have, or know where I can get, a version of XMITMGR for Windows 7
64 bit
> PC? I find the program very useful when looking at files on the CBT tape
and not
> being able to use it creates extra work for looking for stuff.
>
> The version I have (version 3) says the version of the operating system is
incompatible
> with the software.
>
> Or, is there another way to look at the XMI files on the PC?
>
>

----------------------------------------------------------------------

[Scott Chapman]

Small blocksize maybe? Just a guess.

[O'Brien, David W. [C] , NIH/CIT]

Michael,

Check your HSM Activity log for msg. ADR035I, then check the Optimize value.

OPTIMIZE(4) will provide you with the least amount of physical I/O.

Change the DUMPIO(n) in HSM parmlib if necessary.

HTH,
Dave O'Brien
NIH Contractor
________________________________________
From: Michael R. Mayne [michae...@HHSYS.ORG]
Sent: Wednesday, November 18, 2009 7:08 PM
To: IBM-...@bama.ua.edu
Subject: Re: High CPU / channel ovhd w/3592 and DFDSS

[Michael R. Mayne]

This has always been a question - the DFHSM blocksize for BACKUP is
(apparently) fixed at 16K, and I know of no way to override it. Any DFHSM
experts out there?

[O'Brien, David W. [C] , NIH/CIT]

The answer used to be 'No' but that may have changed.

Thank You,

Dave O'Brien
NIH Contractor
________________________________________
From: Michael R. Mayne [michae...@HHSYS.ORG]

Sent: Thursday, November 19, 2009 9:30 AM

To: IBM-...@bama.ua.edu
Subject: Re: High CPU / channel ovhd w/3592 and DFDSS

This has always been a question - the DFHSM blocksize for BACKUP is

[Wendell Lovewell]

Hi Dennis.

I think the 64-bit problem with XMITMGR is a problem with the installation
.exe and not with XMITMGR itself. I think I remember having to copy it from
a 32-bit Windows PC to my 64-bit PC. There might be a DLL to copy with
it--I'm sorry I don't remember. If there was one, you might need REGSVR32
to register the dll after you copy it to your pc.

You might also need to go to the Properties tab and change the compatibility
mode as Lizette suggested--I have had to do that for several programs under
64-bit Vista.

hth
Wendell

[Hal Merritt]

Can't speak to the CPU, but the tape channel utilization may be an indication of the much higher performance tape units. Historically, many tape unit models can consume most of a channel path.

The low DASD channel utilization may point to compression for that resource.

Perhaps the DASD really is compressed and the tape not. That would be a simple explanation that fits your observations.

HTH and good luck

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Michael R. Mayne
Sent: Wednesday, November 18, 2009 2:55 PM
To: IBM-...@bama.ua.edu

Thanks.
-Mike

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

[John Laubenheimer]

Two thoughts here.

1) Your new tape drives accept data at a faster rate than your old tape
drives. Therfore, you might expect that DFHSM is reading the DASD at a
faster rate; hence, DFHSM gets dispatched more frequently. This would
increase the apparent CPU utilization of DFHSM. However, since your backup
completes in a shorter amount of time, the average CPU utilization of DFHSM
should remain the same (or similar).

2) Check you HSM parameters. Use SETSYS TAPEHARDWARECOMPACT to
notify DFHSM that your tape drives have this feature. And, check your
SETSYS COMPACT parameter:
SETSYS COMPACT(DASDMIGRATE NOTAPEMIGRATE DASDBACKUP
NOTAPEBACKUP)
/* USE COMPACTION FOR: */
/* MIGRATION TO DASD */
/* BACKUP TO DASD */
/* DO NOT USE COMPACTION FOR: */
/* MIGRATION TO TAPE */
/* BACKUP TO TAPE */
You really don't need DFHSM to compact your data; the tape hardware does
this for you. (Of course, if you do compact your tape backup in software,
you're doing much more of this operation per second, since you are processing
more data.)

Of course, this may/may not be your problem; and, as always, YMMV.

[Kirk Wolf]

It would be very nice, IMO, if there were an open source, portable
program to pack and unpack XMITs. Java would be nice, so that a
single binary build would serve all comers.

Anyone interested in donating/writing something or collaborating?
Pointers to existing open code or docs on the format would be helpful.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List

> [mailto:IBM-...@bama.ua.edu] On Behalf Of Kirk Wolf
> Sent: Thursday, November 19, 2009 11:45 AM
> To: IBM-...@bama.ua.edu

> Subject: Re: XMITMGR for 64 Bit Windows?
>
> It would be very nice, IMO, if there were an open source, portable
> program to pack and unpack XMITs. Java would be nice, so that a
> single binary build would serve all comers.
>
> Anyone interested in donating/writing something or collaborating?
> Pointers to existing open code or docs on the format would be helpful.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com

Looks like there is some HLASM source for this on http://cbttape.org/cbtdowns.htm in file 571. From that, one could make a document of what an XMIT file looks like. From that, code could be written.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

[Roy Hewitt]

McKown, John wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of Kirk Wolf
>> Sent: Thursday, November 19, 2009 11:45 AM
>> To: IBM-...@bama.ua.edu
>> Subject: Re: XMITMGR for 64 Bit Windows?
>>
>> It would be very nice, IMO, if there were an open source, portable
>> program to pack and unpack XMITs. Java would be nice, so that a
>> single binary build would serve all comers.
>>
>> Anyone interested in donating/writing something or collaborating?
>> Pointers to existing open code or docs on the format would be helpful.
>>
>> Kirk Wolf
>> Dovetailed Technologies
>> http://dovetail.com
>
> Looks like there is some HLASM source for this on http://cbttape.org/cbtdowns.htm in file 571. From that, one could make a document of what an XMIT file looks like. From that, code could be written.
>
> --
> John McKown

John

I know you always like a challange, but wouldnt it be a lot easier just to use the record layouts as
described in the TSO/E Customisation manual ;-)

Cheers

Roy

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Roy Hewitt
> Sent: Thursday, November 19, 2009 3:34 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: XMITMGR for 64 Bit Windows?
<snip>
>
> John
>
> I know you always like a challange, but wouldnt it be a lot
> easier just to use the record layouts as
> described in the TSO/E Customisation manual ;-)
>
> Cheers
>
> Roy
>

Ah! Spoil sport! <grin> I've never looked in that manual. The difficult part would be that a PO dataset is IEBCOPY unloaded. Is that documented there too?

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

----------------------------------------------------------------------

[Roy Hewitt]

McKown, John wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of Roy Hewitt
>> Sent: Thursday, November 19, 2009 3:34 PM
>> To: IBM-...@bama.ua.edu
>> Subject: Re: XMITMGR for 64 Bit Windows?
> <snip>
>> John
>>
>> I know you always like a challange, but wouldnt it be a lot
>> easier just to use the record layouts as
>> described in the TSO/E Customisation manual ;-)
>>
>> Cheers
>>
>> Roy
>>
>
> Ah! Spoil sport! <grin> I've never looked in that manual. The difficult part would be that a PO dataset is IEBCOPY unloaded. Is that documented there too?
>

Yes, I realised I should have mentioned the unloaded IEBCOPY format in the ohnosecond before I hit
send! But yes it is documented in the Utilities manual. It's an involved process as the unloaded
format is device dependant, (presumably based on the temporary dataset that was used to unload it)
and for PDSE it uses a virtual device format with something like 256 tracks/cyl.. (which is why PDSE
don't work with XmitManager..) There are some bits of rexx around that do the XMIT decoding and I've
used them to help extract from a corrupt xmit file and then manually unpacked the unloaded
IEBCOPY... messy!

Cheers

Roy

[Brian Westerman]

As long as you copy it to the "Program Files (X86)" directory, it works
fine. You don't need to run it any special way.

When you first click on a .XMI file, you will have to navigate to that
directory (make sure you check always to use that program for that type
file) and from then on it will be fine. You can also just use any filetype
editor to set the connection between .xmi and .xmit to that program, but in
any case, it will function fine.

Your only problem might be that you have to install it on a XP or lower
machine first to get the files to copy.

I'm not sure if the source is still available to re-write it or not. It
might be cool to give it a shot.

Brian

[Knutson, Sam]

http://www.planetmvs.com/unxmit/index.html

http://www.planetmvs.com

Dave Alcock's excellent site includes a useful page of various
information about XMIT compiled in one place.

Thanks, Sam

====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

[Robert AH Prins]

"Kirk Wolf" <ki...@DOVETAIL.COM> wrote in message
news:b2b367b60911190944s1a2...@mail.gmail.com...

> On Thu, Nov 19, 2009 at 8:41 AM, Wendell Lovewell
> <wlov...@mackinney.com> wrote:
>> Hi Dennis.
>>
>> I think the 64-bit problem with XMITMGR is a problem with the
>> installation
>> .exe and not with XMITMGR itself. I think I remember having to copy
>> it from
>> a 32-bit Windows PC to my 64-bit PC. There might be a DLL to copy
>> with
>> it--I'm sorry I don't remember. If there was one, you might need
>> REGSVR32
>> to register the dll after you copy it to your pc.
>>
>> You might also need to go to the Properties tab and change the
>> compatibility
>> mode as Lizette suggested--I have had to do that for several programs
>> under
>> 64-bit Vista.
>

> It would be very nice, IMO, if there were an open source, portable
> program to pack and unpack XMITs. Java would be nice, so that a
> single binary build would serve all comers.
>
> Anyone interested in donating/writing something or collaborating?
> Pointers to existing open code or docs on the format would be helpful.

CBTTAPE.ORG contains two files:

http://www.cbttape.org/ftp/cbt/CBT776.zip (Updated RECV390 for the PC,
zip file from Edgar Hofmann)
and
http://www.cbttape.org/ftp/cbt/CBT800.zip (RECEIVE/UNXMIT tool written
in REXX for the PC - beta)

I'm still using the older RECV390 written by Jim Morrison
(http://www.cbttape.org/~jmorrison/), be it with a patched translate
table, as the version in his source is pretty minimal (EBCDIC-ASCII text
only). JM's code is public domain acording to the CBPTAPE page. Program
is written in C. :(

Robert
--
Robert AH Prins
robert (a) prino (d) org

[Longnecker, Dennis]

Thanks All. I installed it on a Windows XP machine, and then copied the directory c:\program files\xmitmgr to my Windows 7 PC and it works like a champ. Just the installer was having a problem.

Dennis

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of Wendell Lovewell
Sent: Thursday, November 19, 2009 6:42 AM
To: IBM-...@bama.ua.edu
Subject: Re: XMITMGR for 64 Bit Windows?

[Brian Westerman]

I was wondering if it would cause any issues for anyone if I were to set up
a new install file of XMITMGR so that other people down the line who might
not have an old system will still be able to install it.

Is there any copyright laws that would be broken to do that since it's
already free?

Brian

[Robert AH Prins]

"Brian Westerman" <Brian_W...@SYZYGYINC.COM> wrote in message
news:LISTSERV%20091125210...@BAMA.UA.EDU...

>I was wondering if it would cause any issues for anyone if I were to
>set up
> a new install file of XMITMGR so that other people down the line who
> might
> not have an old system will still be able to install it.
>
> Is there any copyright laws that would be broken to do that since it's
> already free?

Since when is it free?

If you're a member of LinkedIn, you might want to contact Neil
Johnston-Ward who wrote it. He might be willing to open-source it,
although porting Borland Delphi to other OS'es might not be trivial...

Robert
--
Robert AH Prins

robert dot ah dot prins on gmail