Re: Anyone exploiting ZEDC?

[Andrew Rowley]

On 19/04/2024 9:35 pm, Scott Chapman wrote:

Agreed, it's been many years since I ran similar test with our software and 
don't remember the exact details, but my recollection is that I saw no 
noticeable change in CPU consumption. Which I remember being particularly 
interested in because I'd heard of issues reading that compressed data.
I did some experiments with SMF data with and without zEDC. What I saw 
in my test:
- zEDC I/O was much faster, reducing elapsed time by more than 10x in 
some cases

- CPU time for compression seemed to be less than 0.2s per GB
- CICS software compression greatly reduced the CPU time for copying the 
zEDC compressed data e.g. if you have weekly/monthly SMF housekeeping


Also some interesting results processing zEDC compressed data with Java. 
zEDC actually reduced the amount of time on the general purpose CPs - it 
seems like more of the work ended up on the zIIPs. Reporting on 39GB of 
zEDC compressed CICS data used only 2s CP / 38.6s zIIP time, compared to 
5.6s CP time reading the data with IFASMFDP. Reading the 6.6 GB dataset 
in Java used 1.49s CP time without zEDC, 1.25s CP time with zEDC (plus 
zIIP time).


You can read the details here:
https://www.blackhillsoftware.com/news/2024/04/29/using-zedc-compression-for-smf-data/

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Ed Jaffe]

On 4/16/2024 9:16 AM, Jousma, David wrote:

Is anyone exploiting ZEDC data compression accelerator in your environments?


We zEDC compress and encrypt our zFS file systems and SVC dumps.

We zEDC compress our HSM backups on both DASD and TAPE and other large 
data sets such as the *huge* PDSEs that hold our product ADATA.


zEDC has saved us *significant* amounts of DASD space and actually sped 
up some processes that read these giant files.


I know everyone says "DASD is cheap" and I've heard the same about tape, 
but we never seem to have enough. IJS...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Russell Witt]

The new release (over a year old, so not so new) of CA 1 Flexible Storage
has an option to exploit z/EDC when writing to tape or to exploit z/EDC and
ACS256 encryption when writing to tape. In both cases, we have an option to
do those both in a zIIP engine if available. On the z16 systems, it screams.
A simple ADRDSSU job can run 30% faster (clock time) with barely an uptick
in CPU usage. Running ADRDSSU with the ZCOMPRESS option goes a little fast
clock-time; but you see a HUGE increase in CPU time. 

But the z/EDC compression chip is wonderful. And running it in the zIIP is
even better.

Russell Witt
Broadcom 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Tuesday, April 16, 2024 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Anyone exploiting ZEDC?

Is anyone exploiting ZEDC data compression accelerator in your environments?
We recently licensed the enablement and are working through the issues in
our DEV environment.

We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets,
but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have
issues.   We've turned back off for now.

There is no central location in any IBM doc(including recent REDBOOKS) that
discusses where we can and cannot leverage ZEDC.   As it stands now, we had
to back out, and looking at taking a new approach in our ACS routines
checking for DSORG=PS, and then if not temp-dataset, or tape assign a DC
with the right options.

What I am wondering is if anyone is further along that can share how they
rolled out?   I really don't want to have to make the applications teams
have to "opt-in" by coding a DC in their JCL or other dataset allocations.

Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Steve Estle]

David, 

We are using it - biggest benefit so far has been with our backups in 
converting DFSMSDSS (ADRDSSU) backups using "ZPREF" option.  It reduced runtime 
on backups significantly (50%+) with also some reduction in CPU cycles.  We 
also are using it in other scenarios.  You do need to test though - think 
biggest areas of concern are with vendors that don't use standard access 
methods - few of note SAS, NOMAD - sure many others.   Feel free to contact me 
at sest...@gmail.com but am a big proponent of using.  I think I have white 
paper somewhere but need to track down.  One of the reasons we went this route 
is we are starting to exploit pervasive encryption which for most part requires 
extended format datasets (also required for ZEDC).  Best practice is to 
compress before you encrypt.  One other area we exploited was DFHSM and 
activated that so it now compresses migrated and backed up datasets - hard to 
measure improvement, but am sure is much more efficient than prior settings.  I 
know that large VSAM files see benefits as well - but just ensure you test 
before going to far in that direction - one other point - ZFS have the ability 
to compress as well which can be advantageous - especially when vendors send 
large ZFS packages - such as SAS does.  Areas we haven't exploited yet but are 
intriguing are JES spool space compression as well as SMF data compression.  

One other key suggestion to look at is to run a ZBNA (free software from IBM) 
study as it helps you identify good candidate datasets from your batch job 
cycles.  As others have noted it doesn't make sense to compress things that are 
relatively small - but do try and apply the 80/20 rule here.  Anytime you can 
do less I/O in batch jobs is always a good thing of course and win-win 
situation!

All the best,

Steve Estle
Peraton ZOS Systems Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Scott Chapman]

Agreed, it's been many years since I ran similar test with our software and 
don't remember the exact details, but my recollection is that I saw no 
noticeable change in CPU consumption. Which I remember being particularly 
interested in because I'd heard of issues reading that compressed data. 

IIRC, I was only looking at at CPU because I/O time can be significantly 
variable depending on where we reading the data from. And doing less I/O is 
obviously always better, and can significantly impact runtime in some cases. So 
I/O time wasn't really a question in my mind. 

Scott Chapman

On Thu, 18 Apr 2024 14:42:47 +1000, Andrew Rowley 
 wrote:

>On 18/04/2024 12:04 am, Michael Oujesky wrote:
>> Just a thought, but anyone processing internally compressed CICS or
>> DB2 data on a non-z/OS platform (Windows/Unix) might see substantial
>> CPU usage from RLE decompression.
>
>If the compression is lightweight, decompression should be too. I can't
>speak for any other product, but I did an experiment with the EasySMF
>Java API.
>
>Running a CICS report on my laptop I got:
>
>Processing CICS compressed data: 1.2 GB/s (size after decompression)
>
>Processing uncompressed data: 800 MB/s
>
>So processing the compressed data was actually about 50% faster.
>
>--
>Andrew Rowley
>Black Hill Software
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Radoslaw Skorupka]

W dniu 16.04.2024 o 18:28, rpinion865 pisze:

At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  [...]


No cards for z15. It has zEDC module in processor.
z14 and older had zEDC cards, defined in HCD as a function.

HW: Cards were paid feature, zEDC in z15 is not extra paid.
SW: Note: in both cases you have to enable z/OS paid component (cheap IMHO).

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Radoslaw Skorupka]

W dniu 16.04.2024 o 18:16, Jousma, David pisze:

Is anyone exploiting ZEDC data compression accelerator in your environments?   
We recently licensed the enablement and are working through the issues in our 
DEV environment.

We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, but 
are quickly finding that DFSORT, SAS, ISPF recovery datasets all have issues.   
We’ve turned back off for now.

There is no central location in any IBM doc(including recent REDBOOKS) that 
discusses where we can and cannot leverage ZEDC.   As it stands now, we had to 
back out, and looking at taking a new approach in our ACS routines checking for 
DSORG=PS, and then if not temp-dataset, or tape assign a DC with the right 
options.

What I am wondering is if anyone is further along that can share how they 
rolled out?   I really don’t want to have to make the applications teams have 
to “opt-in” by coding a DC in their JCL or other dataset allocations.


I've been using zEDC for years, since z13, AFAIR. Then z14, then z15 
until now.
No issues with DFSORT (we've been using a lot of it, including huge jobs 
- ~320GB of real memory instead of SORTWKx).

No issues with ISPF.
No SAS => no feedback.
The only sad news is... for DASD salesmen - no space upgrades. :-)

BTW: One of recent changes is PDSE compression. I love it when I remain 
SMPPTS :-)


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Prashant Joshi]

I did zBNA study for few environments and every time I see increase (or very 
small decrease) in CPU seconds usage. I see big difference in IO delta and 
considerable saving in DASD storage but not much difference in CPU time? Or 
zBNA includes only batch jobs and no other beneficiary started tasks like HSM, 
CICS, DB2 etc

Thank you,
Prashant

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Glenn Wilcock
Sent: Thursday, April 18, 2024 2:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Anyone exploiting ZEDC?

DFSMShsm is an excellent use case for zEDC and is our number one best practice 
for HSM.  When enabled, DSS zEDC compresses all blocks of data passed to HSM 
during Migration and Backup.  Because HSM is processing fewer data blocks, both 
cpu and elapsed time are reduced.  When going to ML1, the amount of storage is 
also significantly reduced.

Glenn Wilcock, DFSMS Chief Product Owner

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Andrew Rowley]

On 18/04/2024 12:04 am, Michael Oujesky wrote:
Just a thought, but anyone processing internally compressed CICS or 
DB2 data on a non-z/OS platform (Windows/Unix) might see substantial 
CPU usage from RLE decompression.


If the compression is lightweight, decompression should be too. I can't 
speak for any other product, but I did an experiment with the EasySMF 
Java API.


Running a CICS report on my laptop I got:

Processing CICS compressed data: 1.2 GB/s (size after decompression)

Processing uncompressed data: 800 MB/s

So processing the compressed data was actually about 50% faster.

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Unless the file is already compressed.  For those they just get 
passed to ML2 or BACKUP as-is.


Michael

At 04:04 PM 4/17/2024, Glenn Wilcock wrote:

DFSMShsm is an excellent use case for zEDC and is our number one 
best practice for HSM.  When enabled, DSS zEDC compresses all blocks 
of data passed to HSM during Migration and Backup.  Because HSM is 
processing fewer data blocks, both cpu and elapsed time are 
reduced.  When going to ML1, the amount of storage is also 
significantly reduced.


Glenn Wilcock, DFSMS Chief Product Owner

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Glenn Wilcock]

DFSMShsm is an excellent use case for zEDC and is our number one best practice 
for HSM.  When enabled, DSS zEDC compresses all blocks of data passed to HSM 
during Migration and Backup.  Because HSM is processing fewer data blocks, both 
cpu and elapsed time are reduced.  When going to ML1, the amount of storage is 
also significantly reduced.

Glenn Wilcock, DFSMS Chief Product Owner

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

SORTWKxx are typically temporary and not SMS 
compression eligible (requires catalog entry to 
hold the SMS compression attributes).


Michael

At 02:31 PM 4/16/2024, Jousma, David wrote:


Michael,

Yes, thanks.  It is just the sortwk datsets that are the issue.

Dave Jousma
Vice President | Director, Technology Engineering




From: IBM Mainframe Discussion List 
 on behalf of Michael 
Oujesky 

Date: Tuesday, April 16, 2024 at 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
Food for thought. zEDC is block oriented rather 
than record oriented (i. e. reads/writes full 
track blocks on DASD and BLKSIZE become logical 
(i. e. the size of the buffer used to exchange 
data with the application)), so any processing that expects



Food for thought.  zEDC is block oriented rather than record oriented

(i.e. reads/writes full track blocks on DASD and BLKSIZE become

logical (i.e. the size of the buffer used to exchange data with the

application)), so any processing that expects to make use of BLKSIZE

to perform physical I/O (random, update, etc) will fail.



Thus DFSORT will have issues for SORTWK datasets, but not

SORTIN/SORTOUT datasets.



Michael



This e-mail transmission contains information 
that is confidential and may be privileged.   It 
is intended only for the addressee(s) named 
above. If you receive this e-mail in error, 
please do not read, copy or disseminate it in 
any manner. If you are not the intended 
recipient, any disclosure, copying, distribution 
or use of the contents of this information is 
prohibited. Please reply to the message 
immediately by informing the sender that the 
message was misdirected. After replying, please 
erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Just a thought, but anyone processing internally compressed CICS or 
DB2 data on a non-z/OS platform (Windows/Unix) might see substantial 
CPU usage from RLE decompression.


Michael
At 07:02 AM 4/17/2024, Scott Chapman wrote:

My recommendation has always been to leave Db2/CICS's RLE 
compression of SMF data enabled even with zEDC compression of the data.


1) Less data will be sent to the zEDC compression engine, which will 
then process faster. I believe at one point I had an IBM chart that 
showed this.
2) The data might (likely) compress better because intervening 
repeated values are removed before it goes through the zEDC 
compression. (As Andrew shows below.) It might be dependent on the 
data, but it makes some sense when you realize that LZ77 relies on 
compressing in 32K blocks and by removing the duplicate zeros you 
potentially get more interesting repeated data into that 32K block.
3) When the data is read back from the zEDC-compressed store to be 
sent someplace for processing it will be smaller if the RLE 
compression was enabled. Depending on what you're doing with the 
data, that might be significant.
4) The RLE compression is extremely lightweight in terms of CPU. I 
do not expect it to be noticeable: it's going to disappear in the 
normal variation in CPU time seen for running the same work on any 
shared system. The only CICS/Db2s that I would expect could have a 
measurable increase in CPU would be those that are completely idle 
and doing nothing but writing interval SMF records to say they 
haven't processed any data.


Scott Chapman

On Wed, 17 Apr 2024 16:36:34 +1000, Andrew Rowley 
 wrote:


>On 17/04/2024 12:09 pm, Michael Oujesky wrote:
>> Yes and zEDC poorly compresses internally RLE compressed records.
>
>I was surprised how well zEDC compressed the already compressed records.
>Using my data:
>
>zEDC alone : 52000 tracks
>
>CICS compression + zEDC : 22000 tracks
>
>zEDC seems to be biased towards speed rather than compression ratio, so
>maybe the RLE compression helps by packing more repeated bytes into
>whatever compression window zEDC uses?
>
>> Plus CSRCESRV uses GP engine cycles
>
>That's true - CPU is probably more expensive than storage, so this could
>be just an interesting side-track. On the other hand, I think zEDC has
>to decompress and recompress the data for SMF dump etc. so CICS
>compression might save some overhead for SMF housekeeping type
>operations, reducing the amount of data going through zEDC?
>
>--
>Andrew Rowley
>Black Hill Software
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Just a thought, but 30's compress quite well also.

Michael

At 07:18 AM 4/17/2024, rpinion865 wrote:


Also, you will need this for SMF compression.

ISRBROBA  PINIONR.BAS.PARMLIB(SMFPRM00) - 01.12Line 00 Col 00
Command ===>  Scroll ===>
 Top of Data 
INTVAL(30)  /* SMF GLOBAL RECORDING INTERVAL*/
ACTIVE  /* ACTIVE SMF RECORDING */
RECORDING(LOGSTREAM)
LSNAME(IFASMF.,TYPE(110),COMPRESS)
LSNAME(IFASMF.,TYPE(100:102),COMPRESS)
LSNAME(IFASMF.,TYPE(70,89),COMPRESS)
LSNAME(IFASMF.,TYPE(0:99,103:109,111:2047),
   COMPRESS)




Sent with Proton Mail secure email.

On Wednesday, April 17th, 2024 at 8:08 AM, 
Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:


> Thank-you very much for this! I suspect this 
is the route we will have to take. To answer 
your other question, yes, ZEDC is a chargeable 
feature (although very inexpensive) and is turned on in IFAPRD00.

>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
> From: IBM Mainframe Discussion List 
IBM-MAIN@LISTSERV.UA.EDU on behalf of 
rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu

>
> Date: Tuesday, April 16, 2024 at 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: Anyone exploiting ZEDC?
> FWIW, here is a snippet of the SMS ACS DC 
code that we were using for zEDC. /* DEFINE 
extra data sets to receive zEDC compression / 
// 
FILTLIST COMP_DSN INCLUDE(CCM. CCM. FDR. *,

>
>
> FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC.
>
>
>
> / DEFINE extra data sets to receive zEDC compression /
>
>
>
> //
>
>
>
>
>
>
>
> FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.,
>
> RMS.PROD.MSA.BKUP.,
>
> LOGR.IFASMF.,
>
> DB2%.ARCHLOG%.)
>
>
>
> - - - - - - - - - - - - - - - - - - 46 Line(s) not Displ
>
>
>
> /* RULES FOR DISK zEDC HW data compression /
>
>
>
> /*/
>
>
>
> WHEN ( = _DSN) SET ='COMP'
>
> WHEN ( = 'GDS' &&  > 270MB)
>
>
> SET ='COMP'
>
> WHEN ( = 'ADRDSSU' &&  > 55MB)
>
>
> SET ='COMP'
>
>
>
>
>
>
>
>
>
> This e-mail transmission contains information 
that is confidential and may be privileged. It 
is intended only for the addressee(s) named 
above. If you receive this e-mail in error, 
please do not read, copy or disseminate it in 
any manner. If you are not the intended 
recipient, any disclosure, copying, 
distribution or use of the contents of this 
information is prohibited. Please reply to the 
message immediately by informing the sender 
that the message was misdirected. After 
replying, please erase it from your computer 
system. Your assistance in correcting this error is appreciated.

>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Timothy Sipples]

rpinion865
 wrote:
>Is it not true that even though you get the zEDC engines on the z15 and z16,
>you still have to pay for the exploitation by enabling Featurename('ZEDC') in
>parmlib's IFAPRDxx?

David Jousma wrote:

>To answer your other question, yes, ZEDC is a chargeable feature

>(although very inexpensive) and is turned on in IFAPRD00.

OK, I’ll try to clarify

On z15/LinuxONE III models and higher the zEDC hardware is on-chip, standard, 
no additional charge, no feature code needed. “It’s just there.”

In z/OS there’s an optional, chargeable software feature called “z/OS zEDC.” 
This licensed, chargeable feature (like other optional z/OS elements) is 
enabled in an IFAPRDxx parmlib member. However, if you don’t enable this 
chargeable element it’s still possible to exploit zEDC on z/OS to some degree. 
As one example, Java applications using java.util.zip’s zlib library (available 
in the IBM Semeru Runtimes) can exploit zEDC even without enabling the z/OS 
zEDC feature. Here’s how the z/OS 3.1 documentation explains it:

“...With IBM Integrated Accelerator for zEDC compression on the z15 [and 
higher], you use IFAPRDxx only for enabling asynchronous processing (by using 
the FPZ4 authorized services). Entitlement of the zEDC priced feature of z/OS 
is not required for using zlib-based functions.”

Anticipating the next question, I haven’t found a good, current list of zEDC 
exploiters and whether they require the z/OS zEDC feature or not. It’d be a 
fairly long list, and the list keeps growing. But if the product’s or 
component’s documentation lists the z/OS zEDC feature as a prerequisite (or a 
recommendation) then that’s an indicator it uses (or can use) the FPZ4 
authorized services.

IBM offers some tools that can help determine whether the z/OS zEDC feature 
would be of benefit, and how much. This whitepaper illustrates such an analysis:

https://www.ibm.com/support/pages/system/files/inline-files/zEDC_White_Paper.pdf

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[rpinion865]

Also, you will need this for SMF compression.

ISRBROBA  PINIONR.BAS.PARMLIB(SMFPRM00) - 01.12Line 00 Col 00
Command ===>  Scroll ===>
 Top of Data 
INTVAL(30)  /* SMF GLOBAL RECORDING INTERVAL*/  
ACTIVE  /* ACTIVE SMF RECORDING */  
RECORDING(LOGSTREAM)
LSNAME(IFASMF.,TYPE(110),COMPRESS)
LSNAME(IFASMF.,TYPE(100:102),COMPRESS) 
LSNAME(IFASMF.,TYPE(70,89),COMPRESS)  
LSNAME(IFASMF.,TYPE(0:99,103:109,111:2047), 
   COMPRESS) 




Sent with Proton Mail secure email.

On Wednesday, April 17th, 2024 at 8:08 AM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thank-you very much for this! I suspect this is the route we will have to 
> take. To answer your other question, yes, ZEDC is a chargeable feature 
> (although very inexpensive) and is turned on in IFAPRD00.
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu
> 
> Date: Tuesday, April 16, 2024 at 3:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
> 
> Subject: Re: Anyone exploiting ZEDC?
> FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. 
> /* DEFINE extra data sets to receive zEDC compression / 
> // 
> FILTLIST COMP_DSN INCLUDE(CCM. CCM. FDR. *,
> 
> 
> FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC.
> 
> 
> 
> / DEFINE extra data sets to receive zEDC compression /
> 
> 
> 
> //
> 
> 
> 
> 
> 
> 
> 
> FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.,
> 
> RMS.PROD.MSA.BKUP.,
> 
> LOGR.IFASMF.,
> 
> DB2%.ARCHLOG%.)
> 
> 
> 
> - - - - - - - - - - - - - - - - - - 46 Line(s) not Displ
> 
> 
> 
> /* RULES FOR DISK zEDC HW data compression /
> 
> 
> 
> /*/
> 
> 
> 
> WHEN ( = _DSN) SET ='COMP'
> 
> WHEN ( = 'GDS' &&  > 270MB)
> 
> 
> SET ='COMP'
> 
> WHEN ( = 'ADRDSSU' &&  > 55MB)
> 
> 
> SET ='COMP'
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thank-you very much for this!   I suspect this is the route we will have to 
take.   To answer your other question, yes, ZEDC is a chargeable feature 
(although very inexpensive) and is turned on in IFAPRD00.

Dave Jousma
Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC. /* 
DEFINE extra data sets to receive zEDC compression */ 
/**/ 
FILTLIST COMP_DSN INCLUDE(CCM. CCM. FDR. **,


FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC.



/* DEFINE extra data sets to receive zEDC compression */



/**/







FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.**,

  RMS.PROD.MSA.BKUP.**,

  LOGR.IFASMF.**,

  DB2%.ARCHLOG%.**)



-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   46 Line(s) not Displ



/* RULES FOR DISK zEDC HW data compression*/



/**/



   WHEN ( = _DSN) SET ='COMP'

   WHEN ( = 'GDS' &&  > 270MB)

 SET ='COMP'

   WHEN ( = 'ADRDSSU' &&  > 55MB)

 SET ='COMP'









This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Scott Chapman]

My recommendation has always been to leave Db2/CICS's RLE compression of SMF 
data enabled even with zEDC compression of the data.

1) Less data will be sent to the zEDC compression engine, which will then 
process faster. I believe at one point I had an IBM chart that showed this. 
2) The data might (likely) compress better because intervening repeated values 
are removed before it goes through the zEDC compression. (As Andrew shows 
below.) It might be dependent on the data, but it makes some sense when you 
realize that LZ77 relies on compressing in 32K blocks and by removing the 
duplicate zeros you potentially get more interesting repeated data into that 
32K block.  
3) When the data is read back from the zEDC-compressed store to be sent 
someplace for processing it will be smaller if the RLE compression was enabled. 
Depending on what you're doing with the data, that might be significant. 
4) The RLE compression is extremely lightweight in terms of CPU. I do not 
expect it to be noticeable: it's going to disappear in the normal variation in 
CPU time seen for running the same work on any shared system. The only 
CICS/Db2s that I would expect could have a measurable increase in CPU would be 
those that are completely idle and doing nothing but writing interval SMF 
records to say they haven't processed any data. 

Scott Chapman

On Wed, 17 Apr 2024 16:36:34 +1000, Andrew Rowley 
 wrote:

>On 17/04/2024 12:09 pm, Michael Oujesky wrote:
>> Yes and zEDC poorly compresses internally RLE compressed records.
>
>I was surprised how well zEDC compressed the already compressed records.
>Using my data:
>
>zEDC alone : 52000 tracks
>
>CICS compression + zEDC : 22000 tracks
>
>zEDC seems to be biased towards speed rather than compression ratio, so
>maybe the RLE compression helps by packing more repeated bytes into
>whatever compression window zEDC uses?
>
>> Plus CSRCESRV uses GP engine cycles
>
>That's true - CPU is probably more expensive than storage, so this could
>be just an interesting side-track. On the other hand, I think zEDC has
>to decompress and recompress the data for SMF dump etc. so CICS
>compression might save some overhead for SMF housekeeping type
>operations, reducing the amount of data going through zEDC?
>
>--
>Andrew Rowley
>Black Hill Software
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[rpinion865]

Is it not true that even though you get the zEDC engines on the z15 and z16, 
you still have to pay for the exploitation by enabling Featurename('ZEDC') in 
parmlib's IFAPRDxx?




Sent with Proton Mail secure email.

On Wednesday, April 17th, 2024 at 4:44 AM, Timothy Sipples  
wrote:

> rpinion865 wrote:
> 
> > At a prior life, we got the zEDC cards on a z15, and turned that on
> > for PS datasets.
> 
> 
> Just to clarify, every IBM z15, LinuxONE III, and higher model machine has 
> on-chip zEDC (compression). It’s formally called the “Integrated Accelerator 
> for zEDC,” and you can expand the zEDC part if you want to be more verbose. 
> On-chip zEDC is included at no additional charge in these more recent 
> machines. No zEDC cards required, no machine feature code required. Moreover, 
> it’s not possible to carry forward the zEDC cards to the newer machine models 
> even if you wanted to.
> 
> I realize it’s not the major point of this thread, but here’s a quick comment 
> about VSAM performance. I think it’s important to “sanity check” performance 
> assumptions periodically because past assumptions often no longer reflect 
> reality and time and technology progress. When I participate in such 
> assessments (and write reports) I typically include an “expiration date.” I 
> include a statement such as, “We recommend reassessing these performance 
> metrics no later than April 30, 2028.” That sort of statement might be based 
> on some educated guesswork, but I try to set a reasonable boundary in the 
> circumstances. There’ve been lots of VSAM-related performance improvements 
> over the years and decades, and they continue. zHyperWrite and the IBM Z 
> Digital Integration Hub (zDIH) are only two examples.
> 
> In terms of zEDC applicability to VSAM, just in case anybody needs the 
> official documentation here it is (z/OS 3.1 link):
> 
> https://www.ibm.com/docs/en/zos/3.1.0?topic=sets-characteristics-compressed-format-data
> 
> The “Requirements for Compression” subsection is also relevant.
> 
> There’s a lot of meaning packed into those two pages, more than usual I’d 
> say. For example, these words are quite important: “A compressed format data 
> set cannot be opened for update.” Those few words are doing some heavy 
> lifting. I’d add that a non-compressed format data set (that can be opened 
> for update) CAN contain data compressed with zEDC. As one example, a Java 
> program can compress data with zEDC then store the compressed data in a data 
> set (via JZOS for example).
> 
> —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM Z/LinuxONE, Asia-Pacific
> sipp...@sg.ibm.com
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Timothy Sipples]

rpinion865 wrote:
> At a prior life, we got the zEDC cards on a z15, and turned that on
>for PS datasets.

Just to clarify, every IBM z15, LinuxONE III, and higher model machine has 
on-chip zEDC (compression). It’s formally called the “Integrated Accelerator 
for zEDC,” and you can expand the zEDC part if you want to be more verbose. 
On-chip zEDC is included at no additional charge in these more recent machines. 
No zEDC cards required, no machine feature code required. Moreover, it’s not 
possible to carry forward the zEDC cards to the newer machine models even if 
you wanted to.

I realize it’s not the major point of this thread, but here’s a quick comment 
about VSAM performance. I think it’s important to “sanity check” performance 
assumptions periodically because past assumptions often no longer reflect 
reality and time and technology progress. When I participate in such 
assessments (and write reports) I typically include an “expiration date.” I 
include a statement such as, “We recommend reassessing these performance 
metrics no later than April 30, 2028.” That sort of statement might be based on 
some educated guesswork, but I try to set a reasonable boundary in the 
circumstances. There’ve been lots of VSAM-related performance improvements over 
the years and decades, and they continue. zHyperWrite and the IBM Z Digital 
Integration Hub (zDIH) are only two examples.

In terms of zEDC applicability to VSAM, just in case anybody needs the official 
documentation here it is (z/OS 3.1 link):

https://www.ibm.com/docs/en/zos/3.1.0?topic=sets-characteristics-compressed-format-data

The “Requirements for Compression” subsection is also relevant.

There’s a lot of meaning packed into those two pages, more than usual I’d say. 
For example, these words are quite important: “A compressed format data set 
cannot be opened for update.” Those few words are doing some heavy lifting. I’d 
add that a non-compressed format data set (that can be opened for update) CAN 
contain data compressed with zEDC. As one example, a Java program can compress 
data with zEDC then store the compressed data in a data set (via JZOS for 
example).

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Andrew Rowley]

On 17/04/2024 12:09 pm, Michael Oujesky wrote:

Yes and zEDC poorly compresses internally RLE compressed records.


I was surprised how well zEDC compressed the already compressed records. 
Using my data:


zEDC alone : 52000 tracks

CICS compression + zEDC : 22000 tracks

zEDC seems to be biased towards speed rather than compression ratio, so 
maybe the RLE compression helps by packing more repeated bytes into 
whatever compression window zEDC uses?



Plus CSRCESRV uses GP engine cycles


That's true - CPU is probably more expensive than storage, so this could 
be just an interesting side-track. On the other hand, I think zEDC has 
to decompress and recompress the data for SMF dump etc. so CICS 
compression might save some overhead for SMF housekeeping type 
operations, reducing the amount of data going through zEDC?


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[kekronbekron]

Turning off s/w compression in CICS & Db2 doesn't always work as advertised 
(meaning, it's not always better to turn off s/w compr and let h/w handle it).
Uncompressed = more I/O for SMF processor tooling to handle.
With either way of compressing, bytes stored will be around the same but the 
above was an added waste of CPU.



On Wednesday, April 17th, 2024 at 04:49, Andrew Rowley 
 wrote:

> On 17/04/2024 7:52 am, Michael Oujesky wrote:
> 
> > My current recommendation is to remove internal compression from CICS
> > CMF (110/112) and DB2 (100-102) records, Zedc compress the SMF
> > logstreams, then compress the logstream offloads via SMS zEDC
> > compression.
> 
> 
> Have you compared compressed size of zEDC with/without the CICS
> compression? I have limited samples, but it looks like zEDC might
> compress data better if it has been already been compressed by CICS. Of
> course, there is the CPU time to consider.
> 
> I think I/O can also be much faster for zEDC compressed data.
> 
> --
> Andrew Rowley
> Black Hill Software
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Yes and zEDC poorly compresses internally RLE compressed records.

Plus CSRCESRV uses GP engine cycles, whereas zEDC offloads the 
processing and reduces CICS and DB2 address space CPU time, By the 
time LOGGER writes the data to  the logstream, it is already 
compressed and is smaller than the compressed internally compressed. 
Ditto for the IFASMFDL logstream unload processing when the output 
files are SMS compressed with zEDC,


Michael

At 06:19 PM 4/16/2024, Andrew Rowley wrote:

Content-Transfer-Encoding: 8bit

On 17/04/2024 7:52 am, Michael Oujesky wrote:


My  current recommendation is to remove internal compression from 
CICS CMF (110/112) and DB2 (100-102) records, Zedc compress the SMF 
logstreams, then compress the logstream offloads via SMS zEDC compression.


Have you compared compressed size of zEDC with/without the CICS 
compression? I have limited samples, but it looks like zEDC might 
compress data better if it has been already been compressed by CICS. 
Of course, there is the CPU time to consider.


I think I/O can also be much faster for zEDC compressed data.

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Andrew Rowley]

On 17/04/2024 7:52 am, Michael Oujesky wrote:


My  current recommendation is to remove internal compression from CICS 
CMF (110/112) and DB2 (100-102) records, Zedc compress the SMF 
logstreams, then compress the logstream offloads via SMS zEDC 
compression.


Have you compared compressed size of zEDC with/without the CICS 
compression? I have limited samples, but it looks like zEDC might 
compress data better if it has been already been compressed by CICS. Of 
course, there is the CPU time to consider.


I think I/O can also be much faster for zEDC compressed data.

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Mark Jacobs]

And SMF data in logstreams too.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


On Tuesday, April 16th, 2024 at 6:32 PM, Mark Jacobs 
<0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Our storage team would know more about what they've done with zEDC, but I'm 
> using it for compression of zFS file systems and JES2 Sysout written to spool.
> 
> Mark Jacobs
> 
> Sent from ProtonMail, Swiss-based encrypted email.
> 
> GPG Public Key - 
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
> 
> 
> 
> 
> On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote:
> 
> > Is anyone exploiting ZEDC data compression accelerator in your 
> > environments? We recently licensed the enablement and are working through 
> > the issues in our DEV environment.
> > 
> > We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> > but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> > issues. We’ve turned back off for now.
> > 
> > There is no central location in any IBM doc(including recent REDBOOKS) that 
> > discusses where we can and cannot leverage ZEDC. As it stands now, we had 
> > to back out, and looking at taking a new approach in our ACS routines 
> > checking for DSORG=PS, and then if not temp-dataset, or tape assign a DC 
> > with the right options.
> > 
> > What I am wondering is if anyone is further along that can share how they 
> > rolled out? I really don’t want to have to make the applications teams have 
> > to “opt-in” by coding a DC in their JCL or other dataset allocations.
> > 
> > Dave Jousma
> > Vice President | Director, Technology Engineering
> > 
> > This e-mail transmission contains information that is confidential and may 
> > be privileged. It is intended only for the addressee(s) named above. If you 
> > receive this e-mail in error, please do not read, copy or disseminate it in 
> > any manner. If you are not the intended recipient, any disclosure, copying, 
> > distribution or use of the contents of this information is prohibited. 
> > Please reply to the message immediately by informing the sender that the 
> > message was misdirected. After replying, please erase it from your computer 
> > system. Your assistance in correcting this error is appreciated.
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Auto: Re: Anyone exploiting ZEDC?

[Frederic Mancini]

Je suis absent le 17 avril 2024.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Mark Jacobs]

Our storage team would know more about what they've done with zEDC, but I'm 
using it for compression of zFS file systems and JES2 Sysout written to spool. 

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.
> 
> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.
> 
> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.
> 
> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Have you considered using zEDC on your SMF logstreams?

My  current recommendation is to remove internal compression from 
CICS CMF (110/112) and DB2 (100-102) records, Zedc compress the SMF 
logstreams, then compress the logstream offloads via SMS zEDC 
compression.  Note that DFHSM archives compressed data as-is, so that 
ought to reduce storage needs in ML2.


Michael

At 11:16 AM 4/16/2024, Jousma, David wrote:
Is anyone exploiting ZEDC data compression accelerator in your 
environments?   We recently licensed the enablement and are working 
through the issues in our DEV environment.


We initially enabled Extended Format/COMPACT ZP, for all DSORG PS 
datasets, but are quickly finding that DFSORT, SAS, ISPF recovery 
datasets all have issues.   We've turned back off for now.


There is no central location in any IBM doc(including recent 
REDBOOKS) that discusses where we can and cannot leverage ZEDC.   As 
it stands now, we had to back out, and looking at taking a new 
approach in our ACS routines checking for DSORG=PS, and then if not 
temp-dataset, or tape assign a DC with the right options.


What I am wondering is if anyone is further along that can share how 
they rolled out?   I really don't want to have to make the 
applications teams have to "opt-in" by coding a DC in their JCL or 
other dataset allocations.


Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential 
and may be privileged.   It is intended only for the addressee(s) 
named above. If you receive this e-mail in error, please do not 
read, copy or disseminate it in any manner. If you are not the 
intended recipient, any disclosure, copying, distribution or use of 
the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer 
system. Your assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Actually to z/OS IAM datasets look like physical 
sequential.  They look to the application like VSAM.


At 02:02 PM 4/16/2024, Jousma, David wrote:

Thanks for that.  We do have IAM here, we’ll 
open a ticket with BMC asking about support.   I 
was just doubting since it presents to the OS as a VSAM dataset.


We were hoping to make ZEDC “inclusive” as in 
everyone gets it to reap the space reduction, 
and job performance improvements and that the OS 
would decide for us if a particular dataset that 
has the DATACLAS assigned to it would just ignore, but that wont be the case.


I have the ability to code ZEDC_preferred or 
ZEDC-Required.   Required will actually fail the 
allocation, which I don’t want to either, but I 
also don’t want to use non-accelerated compression either.


So, now as you pointed out, we’ll have to 
approach ZEDC as “exclusive” and only opt-in 
file types that are supported like GDG’s for 
sure.   We may roll the dice on all PS, 
exempting temp datasets and ISPF work datasets, 
and more as we stumble upon other incompatibilities.


With knowing the technical details, I think IBM 
missed the boat here.   ZEDC ought to be a 
drop-in replacement for compression, period.  I 
can specify COMPACTION YES for VSAM files but ZEDC wont touch them.   Why?


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List 
 on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>

Date: Tuesday, April 16, 2024 at 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
At my previous life, we were using BMC's IAM 
VSAM interface. I think IAM could use zEDC. But 
I was told by then IDP support, that IAM's 
internal compression was Moe (as in Moe Howard) 
better than even zEDC. Regarding coding for PS datasets



At my previous life, we were using BMC's IAM 
VSAM interface.  I think IAM could use zEDC. But 
I was told by then IDP support, that IAM's 
internal compression was Moe (as in Moe Howard) better than even zEDC.




Regarding coding for PS datasets opened in/out, 
I think DAF will show how a PS dataset is being 
opened.  We chose to use zEDC compression for 
new,catlg,delete GDGs because we were very 
confident that no one was going to process that combination as in/out.


And does not the IBM zBNA tool highlight good 
candidates?  We did not want to clutter up our 
SMS ACS DC routines with too many actions to put 
certain PS datasets into zEDC compression.  But 
in the end, we did put certain large PS, not 
opened in/out, datasets in the ACS DC routine.










This e-mail transmission contains information 
that is confidential and may be privileged.   It 
is intended only for the addressee(s) named 
above. If you receive this e-mail in error, 
please do not read, copy or disseminate it in 
any manner. If you are not the intended 
recipient, any disclosure, copying, distribution 
or use of the contents of this information is 
prohibited. Please reply to the message 
immediately by informing the sender that the 
message was misdirected. After replying, please 
erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Not surprising.  IAM replaces VSAM, including 
physical I/O to the file(s), along with better buffering and lookaside.


VSAM can have internally compressed records (like 
RMF III data stores do), but the application is 
responsible to processing the by the application data into a usable form.


In the past, I worked with an application that 
included their own access method that employed 
internally compressed records that included 
uncompressed records upwards of 3MB in size 
(similar in size to some of the reassembled long 
RMF records).  This access method used KSDS VSAM 
and allowed sequential or keyed access to concatenated  VSAM files.


Michael


At 02:26 PM 4/16/2024, rpinion865 wrote:

orm usable by the application
Curious, do you use IAM for Hogan 
applications?  My previous life did, and the 
applications group was very satisfied with the 
IAM performance vs. native VSAM.  However, we 
had to impress on them, that periodic reorgs 
were more necessary for IAM, than under 
VSAM.  And, we found out that ADRDSSU 
dump/restore of VSAM was what was being used to 
perform VSAM reorgs, as opposed to IDCAMS REPRO, DELETE,

DEFINE, REPRO.  Guess what, ADRDSSU sees an IAM dataset as extended format PS!




Sent with Proton Mail secure email.

On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, 
David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:


> Thanks for that. We do have IAM here, we’ll 
open a ticket with BMC asking about support. I 
was just doubting since it presents to the OS as a VSAM dataset.

>
> We were hoping to make ZEDC “inclusive” as in 
everyone gets it to reap the space reduction, 
and job performance improvements and that the 
OS would decide for us if a particular dataset 
that has the DATACLAS assigned to it would just 
ignore, but that wont be the case.

>
> I have the ability to code ZEDC_preferred or 
ZEDC-Required. Required will actually fail the 
allocation, which I don’t want to either, but I 
also don’t want to use non-accelerated compression either.

>
> So, now as you pointed out, we’ll have to 
approach ZEDC as “exclusive” and only opt-in 
file types that are supported like GDG’s for 
sure. We may roll the dice on all PS, exempting 
temp datasets and ISPF work datasets, and more 
as we stumble upon other incompatibilities.

>
> With knowing the technical details, I think 
IBM missed the boat here. ZEDC ought to be a 
drop-in replacement for compression, period. I 
can specify COMPACTION YES for VSAM files but ZEDC wont touch them. Why?

>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> From: IBM Mainframe Discussion List 
IBM-MAIN@LISTSERV.UA.EDU on behalf of 
rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu

>
> Date: Tuesday, April 16, 2024 at 2:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: Anyone exploiting ZEDC?
> At my previous life, we were using BMC's IAM 
VSAM interface. I think IAM could use zEDC. But 
I was told by then IDP support, that IAM's 
internal compression was Moe (as in Moe Howard) 
better than even zEDC. Regarding coding for PS datasets

>
>
> At my previous life, we were using BMC's IAM 
VSAM interface. I think IAM could use zEDC. But 
I was told by then IDP support, that IAM's 
internal compression was Moe (as in Moe Howard) better than even zEDC.

>
>
>
> Regarding coding for PS datasets opened 
in/out, I think DAF will show how a PS dataset 
is being opened. We chose to use zEDC 
compression for new,catlg,delete GDGs because 
we were very confident that no one was going to 
process that combination as in/out.

>
> And does not the IBM zBNA tool highlight good 
candidates? We did not want to clutter up our 
SMS ACS DC routines with too many actions to 
put certain PS datasets into zEDC compression. 
But in the end, we did put certain large PS, 
not opened in/out, datasets in the ACS DC routine.

>
>
>
>
>
>
>
>
>
> This e-mail transmission contains information 
that is confidential and may be privileged. It 
is intended only for the addressee(s) named 
above. If you receive this e-mail in error, 
please do not read, copy or disseminate it in 
any manner. If you are not the intended 
recipient, any disclosure, copying, 
distribution or use of the contents of this 
information is prohibited. Please reply to the 
message immediately by informing the sender 
that the message was misdirected. After 
replying, please erase it from your computer 
system. Your assistance in correcting this error is appreciated.

>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--

Re: Anyone exploiting ZEDC?

[rpinion865]

FWIW, here is a snippet of the SMS ACS DC code that we were using for zEDC.

/* DEFINE extra data sets to receive zEDC compression */  

/**/  

   

FILTLIST COMP_DSN INCLUDE(CCM.CCM.FDR.**, 
  RMS.PROD.MSA.BKUP.**,   
  LOGR.IFASMF.**, 
  DB2%.ARCHLOG%.**)   

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -   46 Line(s) not Displ

/* RULES FOR DISK zEDC HW data compression*/  

/**/  

   WHEN ( = _DSN) SET ='COMP'   
   WHEN ( = 'GDS' &&  > 270MB)
 SET ='COMP' 
   WHEN ( = 'ADRDSSU' &&  > 55MB)
 SET ='COMP' 




Sent with Proton Mail secure email.

On Tuesday, April 16th, 2024 at 3:30 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> No Hogan here. We use IAM in a bunch of applications because it is 
> significantly faster than VSAM (or was).
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu
> 
> Date: Tuesday, April 16, 2024 at 3:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
> 
> Subject: Re: Anyone exploiting ZEDC?
> Curious, do you use IAM for Hogan applications? My previous life did, and the 
> applications group was very satisfied with the IAM performance vs. native 
> VSAM. However, we had to impress on them, that periodic reorgs were more 
> necessary for IAM,
> 
> 
> Curious, do you use IAM for Hogan applications? My previous life did, and the 
> applications group was very satisfied with the IAM performance vs. native 
> VSAM. However, we had to impress on them, that periodic reorgs were more 
> necessary for IAM, than under VSAM. And, we found out that ADRDSSU 
> dump/restore of VSAM was what was being used to perform VSAM reorgs, as 
> opposed to IDCAMS REPRO, DELETE,
> 
> DEFINE, REPRO. Guess what, ADRDSSU sees an IAM dataset as extended format PS!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> 
> 
> On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David 
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote:
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Jousma, David]

Michael,

Yes, thanks.  It is just the sortwk datsets that are the issue.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Michael Oujesky 
Date: Tuesday, April 16, 2024 at 3:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
Food for thought. zEDC is block oriented rather than record oriented (i. e. 
reads/writes full track blocks on DASD and BLKSIZE become logical (i. e. the 
size of the buffer used to exchange data with the application)), so any 
processing that expects


Food for thought.  zEDC is block oriented rather than record oriented

(i.e. reads/writes full track blocks on DASD and BLKSIZE become

logical (i.e. the size of the buffer used to exchange data with the

application)), so any processing that expects to make use of BLKSIZE

to perform physical I/O (random, update, etc) will fail.



Thus DFSORT will have issues for SORTWK datasets, but not

SORTIN/SORTOUT datasets.



Michael



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Jousma, David]

No Hogan here.   We use IAM in a bunch of applications because it is 
significantly faster than VSAM (or was).

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 3:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
Curious, do you use IAM for Hogan applications? My previous life did, and the 
applications group was very satisfied with the IAM performance vs. native VSAM. 
However, we had to impress on them, that periodic reorgs were more necessary 
for IAM,


Curious, do you use IAM for Hogan applications?  My previous life did, and the 
applications group was very satisfied with the IAM performance vs. native VSAM. 
 However, we had to impress on them, that periodic reorgs were more necessary 
for IAM, than under VSAM.  And, we found out that ADRDSSU dump/restore of VSAM 
was what was being used to perform VSAM reorgs, as opposed to IDCAMS REPRO, 
DELETE,

DEFINE, REPRO.  Guess what, ADRDSSU sees an IAM dataset as extended format PS!









Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[rpinion865]

Curious, do you use IAM for Hogan applications?  My previous life did, and the 
applications group was very satisfied with the IAM performance vs. native VSAM. 
 However, we had to impress on them, that periodic reorgs were more necessary 
for IAM, than under VSAM.  And, we found out that ADRDSSU dump/restore of VSAM 
was what was being used to perform VSAM reorgs, as opposed to IDCAMS REPRO, 
DELETE,
DEFINE, REPRO.  Guess what, ADRDSSU sees an IAM dataset as extended format PS!




Sent with Proton Mail secure email.

On Tuesday, April 16th, 2024 at 3:02 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks for that. We do have IAM here, we’ll open a ticket with BMC asking 
> about support. I was just doubting since it presents to the OS as a VSAM 
> dataset.
> 
> We were hoping to make ZEDC “inclusive” as in everyone gets it to reap the 
> space reduction, and job performance improvements and that the OS would 
> decide for us if a particular dataset that has the DATACLAS assigned to it 
> would just ignore, but that wont be the case.
> 
> I have the ability to code ZEDC_preferred or ZEDC-Required. Required will 
> actually fail the allocation, which I don’t want to either, but I also don’t 
> want to use non-accelerated compression either.
> 
> So, now as you pointed out, we’ll have to approach ZEDC as “exclusive” and 
> only opt-in file types that are supported like GDG’s for sure. We may roll 
> the dice on all PS, exempting temp datasets and ISPF work datasets, and more 
> as we stumble upon other incompatibilities.
> 
> With knowing the technical details, I think IBM missed the boat here. ZEDC 
> ought to be a drop-in replacement for compression, period. I can specify 
> COMPACTION YES for VSAM files but ZEDC wont touch them. Why?
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of 
> rpinion865 042a019916dd-dmarc-requ...@listserv.ua.edu
> 
> Date: Tuesday, April 16, 2024 at 2:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
> 
> Subject: Re: Anyone exploiting ZEDC?
> At my previous life, we were using BMC's IAM VSAM interface. I think IAM 
> could use zEDC. But I was told by then IDP support, that IAM's internal 
> compression was Moe (as in Moe Howard) better than even zEDC. Regarding 
> coding for PS datasets
> 
> 
> At my previous life, we were using BMC's IAM VSAM interface. I think IAM 
> could use zEDC. But I was told by then IDP support, that IAM's internal 
> compression was Moe (as in Moe Howard) better than even zEDC.
> 
> 
> 
> Regarding coding for PS datasets opened in/out, I think DAF will show how a 
> PS dataset is being opened. We chose to use zEDC compression for 
> new,catlg,delete GDGs because we were very confident that no one was going to 
> process that combination as in/out.
> 
> And does not the IBM zBNA tool highlight good candidates? We did not want to 
> clutter up our SMS ACS DC routines with too many actions to put certain PS 
> datasets into zEDC compression. But in the end, we did put certain large PS, 
> not opened in/out, datasets in the ACS DC routine.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Michael Oujesky]

Food for thought.  zEDC is block oriented rather than record oriented 
(i.e. reads/writes full track blocks on DASD and BLKSIZE become 
logical (i.e. the size of the buffer used to exchange data with the 
application)), so any processing that expects to make use of BLKSIZE 
to perform physical I/O (random, update, etc) will fail.


Thus DFSORT will have issues for SORTWK datasets, but not 
SORTIN/SORTOUT datasets.


Michael

At 01:19 PM 4/16/2024, Sri Hari Kolusu wrote:
>> We initially enabled Extended Format/COMPACT ZP, for all DSORG 
PS datasets, but are quickly finding that DFSORT, SAS, ISPF 
recovery datasets all have issues.


Dave,

Can you elaborate more on the issue that you have with DFSORT as 
ZEDC is supported by DFSORT.  You can send an offline mail to avoid 
the clutter here.


Thanks,
Kolusus
DFSORT Development
IBM Corporation

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thanks for that.  We do have IAM here, we’ll open a ticket with BMC asking 
about support.   I was just doubting since it presents to the OS as a VSAM 
dataset.

We were hoping to make ZEDC “inclusive” as in everyone gets it to reap the 
space reduction, and job performance improvements and that the OS would decide 
for us if a particular dataset that has the DATACLAS assigned to it would just 
ignore, but that wont be the case.

I have the ability to code ZEDC_preferred or ZEDC-Required.   Required will 
actually fail the allocation, which I don’t want to either, but I also don’t 
want to use non-accelerated compression either.

So, now as you pointed out, we’ll have to approach ZEDC as “exclusive” and only 
opt-in file types that are supported like GDG’s for sure.   We may roll the 
dice on all PS, exempting temp datasets and ISPF work datasets, and more as we 
stumble upon other incompatibilities.

With knowing the technical details, I think IBM missed the boat here.   ZEDC 
ought to be a drop-in replacement for compression, period.  I can specify 
COMPACTION YES for VSAM files but ZEDC wont touch them.   Why?

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
At my previous life, we were using BMC's IAM VSAM interface. I think IAM could 
use zEDC. But I was told by then IDP support, that IAM's internal compression 
was Moe (as in Moe Howard) better than even zEDC. Regarding coding for PS 
datasets


At my previous life, we were using BMC's IAM VSAM interface.  I think IAM could 
use zEDC. But I was told by then IDP support, that IAM's internal compression 
was Moe (as in Moe Howard) better than even zEDC.



Regarding coding for PS datasets opened in/out, I think DAF will show how a PS 
dataset is being opened.  We chose to use zEDC compression for new,catlg,delete 
GDGs because we were very confident that no one was going to process that 
combination as in/out.

And does not the IBM zBNA tool highlight good candidates?  We did not want to 
clutter up our SMS ACS DC routines with too many actions to put certain PS 
datasets into zEDC compression.  But in the end, we did put certain large PS, 
not opened in/out, datasets in the ACS DC routine.









This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[rpinion865]

At my previous life, we were using BMC's IAM VSAM interface.  I think IAM could 
use zEDC. But I was told by then IDP support, that IAM's internal compression 
was Moe (as in Moe Howard) better than even zEDC. 

Regarding coding for PS datasets opened in/out, I think DAF will show how a PS 
dataset is being opened.  We chose to use zEDC compression for new,catlg,delete 
GDGs because we were very confident that no one was going to process that 
combination as in/out.
And does not the IBM zBNA tool highlight good candidates?  We did not want to 
clutter up our SMS ACS DC routines with too many actions to put certain PS 
datasets into zEDC compression.  But in the end, we did put certain large PS, 
not opened in/out, datasets in the ACS DC routine. 




Sent with Proton Mail secure email.

On Tuesday, April 16th, 2024 at 1:58 PM, Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> I could be wrong about VSAM compression here then. Maybe that is all CP 
> compressed and I misunderstood by what mechanism that is done. We could not 
> survive here without VSAM compression. Many of our VSAM files are > 4G space 
> even compressed.
> 
> 
> I do know we ARE using zEDC based on various internal communications I have 
> seen. I just do not know the exact details.
> 
> Peter
> 
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> Jousma, David
> 
> Sent: Tuesday, April 16, 2024 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Anyone exploiting ZEDC?
> 
> 
> Peter,
> 
> 
> 
> Interesting. IBM says VSAM does NOT exploit ZEDC. VSAM can be compressed, but 
> it must all be done on CP, which would be expensive. Within a VSAM LINEAR 
> dataset used as ZFS, ZFS will engage ZEDC.
> 
> 
> 
> Dave Jousma
> 
> Vice President | Director, Technology Engineering
> 
> 
> 
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
> Farley, Peter 
> <031df298a9da-dmarc-requ...@listserv.ua.EDUmailto:031df298a9da-dmarc-requ...@listserv.ua.edu>
> 
> 
> Date: Tuesday, April 16, 2024 at 1:10 PM
> 
> To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>
> 
> 
> Subject: Re: Anyone exploiting ZEDC?
> 
> 
> 
> I do not know what criteria the sysprogs here set things up. But we are 
> successfully using zEDC here especially for our huge VSAM and GDG production 
> files.
> 
> 
> 
> I wish I could tell you more, but the sysprogs here are outsourced and 
> getting answers from them requires official paperwork and bureaucracy that I 
> have no business reason to cover.
> 
> 
> 
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of 
> Jousma, David
> 
> 
> 
> 
> Sent: Tuesday, April 16, 2024 12:39 PM
> 
> 
> 
> To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU
> 
> 
> 
> 
> Subject: Re: Anyone exploiting ZEDC?
> 
> 
> 
> Thank-you for this feedback. I’m starting to feel like this is a half-baked 
> solution looking for a problem. I know of no way to systematically code for 
> open for update….
> 
> 
> 
> Dave Jousma
> 
> Vice President | Director, Technology Engineering
> 
> 
> 
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
> rpinion865 
> <042a019916dd-dmarc-requ...@listserv.ua.EDUmailto:042a019916dd-dmarc-requ...@listserv.ua.edu>
> 
> 
> 
> 
> Date: Tuesday, April 16, 2024 at 12:29 PM
> 
> 
> 
> To: ibm-m...@listserv.ua.EDUmailto:IBM-MAIN@LISTSERV.UA.EDU 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>
> 
> 
> 
> 
> Subject: Re: Anyone exploiting ZEDC?
> 
> 
> 
> At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
> datasets. But like you, we quickly learned that PS datasets opened for in/out 
> processing (update in place) did not work. As a compromise, we narrowed down 
> to new PS
> 
> 
> 
> At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
> datasets. But like you, we quickly learned that PS datasets opened for in/out 
> processing (update in place) did not work. As a compromise, we narrowed down 
> to new PS GDG datasets. Also we looked at new PS GDG datasets over a certain 
> size. We picked an arbitrary number of tracks/cylinders to apply the zEDC 
> compression to. Once we did that, our production job abends disappeared and 
> we started seeing a reduction in space usage on the storage groups where 
> these datasets were being allocated on.
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> 
> 
> 
> On Tuesday, April 16th, 2024 

Re: Anyone exploiting ZEDC?

[Sri Hari Kolusu]

>> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
>> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
>> issues.

Dave,

Can you elaborate more on the issue that you have with DFSORT as ZEDC is 
supported by DFSORT.  You can send an offline mail to avoid the clutter here.

Thanks,
Kolusu
DFSORT Development
IBM Corporation

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Farley, Peter]

I could be wrong about VSAM compression here then.  Maybe that is all CP 
compressed and I misunderstood by what mechanism that is done.  We could not 
survive here without VSAM compression.  Many of our VSAM files are > 4G space 
even compressed.

I do know we ARE using zEDC based on various internal communications I have 
seen.  I just do not know the exact details.

Peter

From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Tuesday, April 16, 2024 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone exploiting ZEDC?


Peter,



Interesting.   IBM says VSAM does NOT exploit ZEDC.   VSAM can be compressed, 
but it must all be done on CP, which would be expensive.Within a VSAM 
LINEAR dataset used as ZFS, ZFS will engage ZEDC.



Dave Jousma

Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
Farley, Peter 
<031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>>

Date: Tuesday, April 16, 2024 at 1:10 PM

To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>

Subject: Re: Anyone exploiting ZEDC?



I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files.



I wish I could tell you more, but the sysprogs here are outsourced and getting 
answers from them requires official paperwork and bureaucracy that I have no 
business reason to cover.



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Jousma, David



Sent: Tuesday, April 16, 2024 12:39 PM



To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>



Subject: Re: Anyone exploiting ZEDC?



Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….



Dave Jousma

Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of 
rpinion865 
<042a019916dd-dmarc-requ...@listserv.ua.edu<mailto:042a019916dd-dmarc-requ...@listserv.ua.edu>>



Date: Tuesday, April 16, 2024 at 12:29 PM



To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>



Subject: Re: Anyone exploiting ZEDC?



At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS



At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.



Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu<mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu>>
 wrote:

> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.

>

> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.

>

> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.

>

> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.

>

> Dave Jousma

> Vice President | Director, Technology Engineering



--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communicati

Re: Anyone exploiting ZEDC?

[Jousma, David]

Peter,

Interesting.   IBM says VSAM does NOT exploit ZEDC.   VSAM can be compressed, 
but it must all be done on CP, which would be expensive.Within a VSAM 
LINEAR dataset used as ZFS, ZFS will engage ZEDC.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter <031df298a9da-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 1:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files. I wish I could tell you more, but the sysprogs here are outsourced and 
getting answers


I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files.



I wish I could tell you more, but the sysprogs here are outsourced and getting 
answers from them requires official paperwork and bureaucracy that I have no 
business reason to cover.



From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David

Sent: Tuesday, April 16, 2024 12:39 PM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: Re: Anyone exploiting ZEDC?





Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….







Dave Jousma



Vice President | Director, Technology Engineering







From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>



Date: Tuesday, April 16, 2024 at 12:29 PM



To: IBM-MAIN@LISTSERV.UA.EDU 



Subject: Re: Anyone exploiting ZEDC?



At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS







At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.







Sent with Proton Mail secure email.







On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:







> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.



>



> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.



>



> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.



>



> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.



>



> Dave Jousma



> Vice President | Director, Technology Engineering



--







This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.





--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information i

Re: Anyone exploiting ZEDC?

[Farley, Peter]

I do not know what criteria the sysprogs here set things up. But we are 
successfully using zEDC here especially for our huge VSAM and GDG production 
files.

I wish I could tell you more, but the sysprogs here are outsourced and getting 
answers from them requires official paperwork and bureaucracy that I have no 
business reason to cover.

From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Tuesday, April 16, 2024 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone exploiting ZEDC?


Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….



Dave Jousma

Vice President | Director, Technology Engineering



From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>

Date: Tuesday, April 16, 2024 at 12:29 PM

To: IBM-MAIN@LISTSERV.UA.EDU 

Subject: Re: Anyone exploiting ZEDC?

At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS



At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.



Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.

>

> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.

>

> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.

>

> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.

>

> Dave Jousma

> Vice President | Director, Technology Engineering

--



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[Jousma, David]

Thank-you for this feedback.   I’m starting to feel like this is a half-baked 
solution looking for a problem.  I know of no way to systematically code for 
open for update….

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Tuesday, April 16, 2024 at 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Anyone exploiting ZEDC?
At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets. But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work. As a compromise, we narrowed down to 
new PS


At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.









Sent with Proton Mail secure email.



On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:



> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.

>

> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.

>

> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.

>

> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.

>

> Dave Jousma

> Vice President | Director, Technology Engineering

>

>

>

>

>

> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.

>

> --

> For IBM-MAIN subscribe / signoff / archive access instructions,

> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Anyone exploiting ZEDC?

[rpinion865]

At a prior life, we got the zEDC cards on a z15, and turned that on for PS 
datasets.  But like you, we quickly learned that PS datasets opened for in/out 
processing (update in place) did not work.  As a compromise, we narrowed down 
to new PS GDG datasets.  Also we looked at new PS GDG datasets over a certain 
size.  We picked an arbitrary number of tracks/cylinders to apply the zEDC 
compression to.  Once we did that, our production job abends disappeared and we 
started seeing a reduction in space usage on the storage groups where these 
datasets were being allocated on.




Sent with Proton Mail secure email.

On Tuesday, April 16th, 2024 at 12:16 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Is anyone exploiting ZEDC data compression accelerator in your environments? 
> We recently licensed the enablement and are working through the issues in our 
> DEV environment.
> 
> We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, 
> but are quickly finding that DFSORT, SAS, ISPF recovery datasets all have 
> issues. We’ve turned back off for now.
> 
> There is no central location in any IBM doc(including recent REDBOOKS) that 
> discusses where we can and cannot leverage ZEDC. As it stands now, we had to 
> back out, and looking at taking a new approach in our ACS routines checking 
> for DSORG=PS, and then if not temp-dataset, or tape assign a DC with the 
> right options.
> 
> What I am wondering is if anyone is further along that can share how they 
> rolled out? I really don’t want to have to make the applications teams have 
> to “opt-in” by coding a DC in their JCL or other dataset allocations.
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged. It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Anyone exploiting ZEDC?

[Jousma, David]

Is anyone exploiting ZEDC data compression accelerator in your environments?   
We recently licensed the enablement and are working through the issues in our 
DEV environment.

We initially enabled Extended Format/COMPACT ZP, for all DSORG PS datasets, but 
are quickly finding that DFSORT, SAS, ISPF recovery datasets all have issues.   
We’ve turned back off for now.

There is no central location in any IBM doc(including recent REDBOOKS) that 
discusses where we can and cannot leverage ZEDC.   As it stands now, we had to 
back out, and looking at taking a new approach in our ACS routines checking for 
DSORG=PS, and then if not temp-dataset, or tape assign a DC with the right 
options.

What I am wondering is if anyone is further along that can share how they 
rolled out?   I really don’t want to have to make the applications teams have 
to “opt-in” by coding a DC in their JCL or other dataset allocations.

Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN