Re: Detecting when a READ/GET crosses a concatenation boundary
Gilbert Saint-Flour wrote: Mike Wood said : check the value of DCBTIOT which is increased each time QSAM/BSAM start to read the next concatenated DD Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Is that due to EAV, or rather XTIOT? Dynamic allocation options that can be exploited based on new option in R12 Are you saying that in z/OS R12, DCBTIOT may no longer be updated when GET/READ switches to the next DD in a concatenation ? In the past 35 years, to detect this type of situation in my programs, I used the fact that DCBTIOT is updated. If it no longer happens, it would be a surprise ! Hmmm, well, I still use code which searches the TIOT the old-fashioned way, and if a DD is not found then it is assumed to not be allocated. If XTIOT catches on in a big way, this could be a problem too. Still, if we remember that XTIOT is a feature of dynamic allocation, then (a) JCL DD statement allocations will use the TIOT and not the XTIOT, and (b) if your program does the dynamic allocation then you control if the XTIOT is used or not. Also, it is safe to say DCBTIOT will still be maintained as expected when the allocation uses the TIOT. But, you can see that since the virtual storage address of an XTIOT entry can be more than a GB away from the start of the TIOT, the 2-byte DCBTIOT TIOT offset field cannot be maintained as we are used to when the relevant file uses the XTIOT. I guess I better stick to writing batch programs... :) Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
Mike Wood wrote: Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Once the DCB is open, issue GETDSAB LOC=ANY,DCBPTR= ... and use the DSABTIOT change to detect the concatenation change after each GET. Mike Wood RMM Development Mike, Is that due to EAV, or rather XTIOT? Just wondering... Thanks, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
Greg, ah yes, I should have said ' XTIOT, uncaptured UCBs, and DSAB above the line ...' Dynamic allocation options that can be exploited based on new option in R12 Mike Wood RMM Development On Tue, 20 Jul 2010 23:28:31 +1000, Greg Price greg.pr...@optushome.com.au wrote: Mike, Is that due to EAV, or rather XTIOT? Just wondering... Thanks, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
Mike Wood said : check the value of DCBTIOT which is increased each time QSAM/BSAM start to read the next concatenated DD Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Is that due to EAV, or rather XTIOT? Dynamic allocation options that can be exploited based on new option in R12 Are you saying that in z/OS R12, DCBTIOT may no longer be updated when GET/READ switches to the next DD in a concatenation ? In the past 35 years, to detect this type of situation in my programs, I used the fact that DCBTIOT is updated. If it no longer happens, it would be a surprise ! -- Gilbert Saint-Flour GSF Software http://gsf-soft.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
On Mon, 19 Jul 2010 00:14:10 -0400, Robert A. Rosenberg wrote: One potential GOTCHA - The EOV exit will be driven not only when you reach the end of a file and switch to the next file in the concatenation but ALSO during a volume switch of a multi-volume sequential dataset. Thus you need to check for this to avoid false positives if all you care about is switching to a new dataset as opposed to also being signaled about a new volume of the current dataset. The OP stated his objective: Purpose: Be able to the extract the dsn actively being processed. so superfluous entries to the exit would seem to be harmless. Another concern might be associating the proper DSN with records in buffers belonging to unCHECKed READs. Multiple buffering/chained scheduling would seem to blur the picture. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
I wish to detect when a BSAM read or QSAM GET crosses a concatenation boundary. I am guessing I need to code an OPEN and EOV DCB exit to get control. You don't need an exit, just check the value of DCBTIOT which is increased each time QSAM/BSAM start to read the next concatenated DD. Here's an example: OPEN DCBxx MVC SAVETIOT,DCBTIOT . . . GET DCBxx CLC SAVETIOT,DCBTIOT BE SAME_DD MVC SAVETIOT,DCBTIOT . . . SAME_DD EQU * . . . SAVETIOT DS H -- Gilbert Saint-Flour GSF Software http://gsf-soft.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
On Mon, 19 Jul 2010 12:00:02 +0200, Gilbert Saint-Flour wrote: I wish to detect when a BSAM read or QSAM GET crosses a concatenation boundary. I am guessing I need to code an OPEN and EOV DCB exit to get control. You don't need an exit, just check the value of DCBTIOT which is increased each time QSAM/BSAM start to read the next concatenated DD. Here's an example: OPEN DCBxx MVC SAVETIOT,DCBTIOT . . . GET DCBxx CLC SAVETIOT,DCBTIOT BE SAME_DD MVC SAVETIOT,DCBTIOT . . . SAME_DD EQU * . . . SAVETIOT DS H Of course there's SMOP to convert a (16-bit!?) DCBTIOT to a DSN. I suppose it's in the book. But when is DCBTIOT incremented?: o At the time of CHECK? (I would hope.) o At the time of READ? (Ugh.) o At the instant the DECB is POSTed? (Worst imaginable.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Once the DCB is open, issue GETDSAB LOC=ANY,DCBPTR= ... and use the DSABTIOT change to detect the concatenation change after each GET. Mike Wood RMM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
Thanks to all that responded to my inquiry. I will try some of the methods suggested. Sincerely; Ken Kripke kkri...@mindspring.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kenneth J. Kripke Sent: Sunday, July 18, 2010 5:09 PM To: IBM-MAIN@bama.ua.edu Subject: Detecting when a READ/GET crosses a concatenation boundary Hello; I wish to detect when a BSAM read or QSAM GET crosses a concatenation boundary. I am guessing I need to code an OPEN and EOV DCB exit to get control. The input data sets can reside on DASD or TAPE, but, the environment does not mix unlike devices...all one way or the other. Purpose: Be able to the extract the dsn actively being processed. Environment has specifc dsn naming conventions that tie back to a cycle number and the generating jobstream. Any assistance/tips would be greatly appreciated. SNIP DFSMS Using Data Sets gives some tips in this area. Look at the area covering Concatenating Data Sets Sequentially. The OPEN exit is driven for each data set in the concat as the Access Method switches to it. So from this, you should be able to get the DSN. And the Label exits get driven as well. Take a look at Using Non-VSAM User-Written Exit Routines with the specifics of Open/Close/EOV Standard User Label Exit. So you are on the right track. Beware of mixed mode (24/31 bit addressing), it can get you really lost when trying to diagnose a problem. Also, look out for LBI -- you have said something about tapes. They can be in LARGE BLOCK (32K) and certain things may be different for the exits (I can't remember exactly how that works -- I get to diagnose problems with our code from time to time). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Detecting when a READ/GET crosses a concatenation boundary
At 6:35 PM -0400 on 07/18/10, Thompson, Steve wrote about Re: Detecting when a READ/GET crosses a concatenation bound: Take a look at Using Non-VSAM User-Written Exit Routines with the specifics of Open/Close/EOV Standard User Label Exit. One potential GOTCHA - The EOV exit will be driven not only when you reach the end of a file and switch to the next file in the concatenation but ALSO during a volume switch of a multi-volume sequential dataset. Thus you need to check for this to avoid false positives if all you care about is switching to a new dataset as opposed to also being signaled about a new volume of the current dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
