Re: Hiperbatch revisited
Thanks for that Martin, makes interesting reading. I believe that IBM carried out some kind of investigation here at Express Gifts about 1992, but I don't have any documentation from that time. I was recently asked to investigate dataset contention on a VSAM KSDS approx. 2.6GB. PAV was first put forward, but couldn't be justified since we only see intermittent IOSQ. We couldn't have easily implemented HB with our 9672 with 2GB of central storage, but our zSeries comes with 8GB. Even after accounting for 1GB HSA and approx. 2GB used by MQ, we still have enough free to load most of our cluster into storage, at least overnight. I will try to convince our Ops Analysts to remove BLSR, at least temporarily. Do you know if HBAID is still available ? I have already downloaded Parallel Sysplex Batch Performance, will have another read. regards, Alex Alex Tough Systems Programmer Express Gifts -- 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
Re: Performance comparison: Hiperbatch, BLSR, SMB?
Peter Apologies if this has already been answered, but the way for a job to opt out of using Hiperbatch is to ask your RACF Security Admin to update the DLF DATA segment for a particular dataset and remove that job or jobs (using a wildcard) from the list of jobs that are allowed to access the DLF object. I struggle to understand how BLSR can give better performance than HB if all other system resources are equal (same WLM Service Class, similar level of CPU contention). My understanding of BLSR is that it will buffer parts (in Control Intervals) of your VSAM cluster into memory. If you have all or most of the cluster allocated to a DLF data object, why would BLSR be faster ? You say that you don't have access to SMF data, but do you have access to RMF or Omegamon/Epilog to indicate what is causing performance degradation ? regards, Alex Alex Tough Systems Programmer Express Gifts -- 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
Hiperbatch revisited
Having some fun this week with Hiperbatch. I want to run one of our largest VSAM clusters as a retained DLF object in RACF during batch run. Asked Ops to run EXPORT, IMPORT to load into memory and everything looked fine, so went to bed. Next morning, it turns out that the object has been purged after being updated by job using BLSR. Today I have proven to myself with a very simple Cobol programme that subsequent use of BLSR will purge a retained object, but I can't see from the MVS Hiperbatch Guide that this is working as expected : Retained DLF objects continue to exist after the last user closes the data set and must be deleted in one of the following ways: * When the data set is recreated. * When the data set is deleted or renamed. * When the data set is updated by an access method (such as BSAM) that does not support Hiperbatch. * When the object is explicitly deleted The data set hasn't been recreated, deleted, renamed or explicitly deleted (I've tested that), so that just leaves being updated by an unsupported access method. Using BLSR with VSAM, the access method is still VSAM, certainly that's what I see in relevant SMF type 64 records. Granted that it may well not be a good idea to access same cluster using both BLSR and Hiperbatch and we can easily change our JCL. Anybody seen this behaviour or have any thoughts ? many thanks, Alex Tough Systems Programmer, Express Gifts -- 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
