We also use Faver and it is a handy tool to have especially for reorgs and point in time backups. Most of our backups go to a TMM disk pool so we bypass tape initially but eventually, some of the backups end up on tape during migration. I have occasionally wondered if using HSM functionality would be a viable alternative to Faver, esp. if you can use FRBACKUP. I supposed the reorgs wouldn't work because the files would be restored to the same condition they were when they were backed up. I haven't thought it all the way through but was wondering if you had given it any thought given the fact that you are going to a VTS so tape really never gets involved. I'm sure there are some +s and -s, just wondered if it might be worth taking a look at.
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: Wednesday, September 14, 2011 9:27 AM To: [email protected] Subject: Re: SMS compressed VSAM datasets They are virtual 3490s in a 3494 VTS from IBM. To anticipate some likely questions. They are SMS managed. The DATACLAS assigned to all virtual 3490s has COMPACTION=YES specified in it. The messages indicate that they are compressed. Eg: IEC705I TAPE ON 0601,205917,SL,COMP,PPRI100D,PS060.JS010,PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00,MEDIA2 <before conversion> IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 305 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2883V00,VOLS=264066,264094,266057, TOTALBLOCKS=270716 </before> <after conversion> IEC205I FVROUT0,PPRI100D,PS060,FILESEQ=1, COMPLETE VOLUME LIST, 301 DSN=PRIPG.GRP.GCRLCHKS.PREBKUP.G2885V00, VOLS=205917,272723,217801,270266,207012,211973,274660,216448, VOLS=227706,213369,206060,TOTALBLOCKS=3326908 </after> The conversion job does a Faver backup, followed by an IDCAMS EXPORT. The stats: IEC205I FVROUT0,EXP00152,FAVER,FILESEQ=1, COMPLETE VOLUME LIST, 835 DSN=GVBPN.PRIPV.PR.GCRLCHKS,VOLS=265418,292061,265898, TOTALBLOCKS=270620 IEC205I OUTFILE,EXP00152,EXPORT,FILESEQ=1, COMPLETE VOLUME LIST, 655 DSN=EXPPN.PRIPV.PR.GCRLCHKS, VOLS=230343,230359,266156,252995,230627,267258,233365,267150, VOLS=267698,229245,277722,TOTALBLOCKS=2058408 -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Pommier, Rex R. > Sent: Wednesday, September 14, 2011 8:54 AM > To: [email protected] > Subject: Re: SMS compressed VSAM datasets > > From 3 output tapes to 12? What kind of tape drives are you using? > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of McKown, John > Sent: Wednesday, September 14, 2011 8:18 AM > To: [email protected] > Subject: Re: SMS compressed VSAM datasets > > Given that the most obvious difference is that what used to > take 3 output tapes is now going to 12 output tapes, the > "slow down" is due to the number of bytes being written to > tape. The bytes read from disk seem be about the same because > the number of cylinders taken by the VSAM dataset is the > same. The "problem" is that Faver is expanding the compressed > bytes in the SMS case but not in the Data Accelerator case. > We are talking to CA about why Faver expands the compressed > bytes when the dataset is SMS compressed instead of just > "sucking it up" using something like a "read track" CCW which > I think would bypass the SMS decompression. > > BTW - Faver is working exactly as it is documented to work in > the Faver manual. We just don't like it. <shrug> > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > [email protected] * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain > confidential or proprietary information. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten > and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West > National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of Staller, Allan > > Sent: Wednesday, September 14, 2011 7:50 AM > > To: [email protected] > > Subject: Re: SMS compressed VSAM datasets > > > > 1) I would increase bufnum before bufsize.... > > 2) Compress the output... > > > > HTH, > > > > <snip> > > This is a weird question, but I've been directed to ask it. We are > > converting some VSAM datasets which currently use BMC's Data > > Accelerator > > compression to use SMS compression instead. This is a financial > > decision. We use CA-Faver to do our VSAM backups. Faver > states in its > > manual that it will unload the VSAM data to its archive in > > uncompressed > > form. I guess this is because Faver "knows" it is SMS > compressed. When > > the data was compressed via Data Accelerator, Faver was > > unaware that it > > was compressed, and so did not interface with Data Accelerator to > > uncompress the data. This meant that the data on the tape was > > in a very > > compressed form. Which is not true with SMS compression. > The result of > > this difference is that our backups are taking much longer. > > Which was a > > surprise to all and is causing concern. So my question out > > there is "any > > ideas on what I can do to make run faster"? So far, the only > > suggestion > > from CA is to increase the BUFSIZE on the dump. But I don't > think this > > is going to reduce the run time significantly. > > </snip> > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: GET > IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > The information contained in this e-mail may contain > confidential and/or privileged information and is intended > for the sole use of the intended recipient. If you are not > the intended recipient, you are hereby notified that any > unauthorized use, disclosure, distribution or copying of this > communication is strictly prohibited and that you will be > held responsible for any such unauthorized activity, > including liability for any resulting damages. As > appropriate, such incident(s) may also be reported to law > enforcement. If you received this e-mail in error, please > reply to sender and destroy or delete the message and any > attachments. Thank you. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail (and any attachments) may contain information that is confidential and/or protected by law. Any review, use, distribution or disclosure to anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
