Re: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
--snip-- Not in our experience. We've tried all possible forms of I/O and LDS was certainly the best when it comes to VSAM. zFS is implemented as VSAM LDS files and I assume that they know what they are doing. from recollectin ESDS and RRDS performance wasn't great by comparison, so we dropped that exploration farily early on. -unsnip--- How about BDAM Relative Record? Or BSAM using NOTE/POINT and TTR addressing? BDAM is far an away the closest to EXCP in terms of performance. -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 02/05/2008 at 07:47 AM, Tom Quarendon [EMAIL PROTECTED] said: No, there is a TTTR. Is that something that they added for large data set support? Whatever. I don't think that that is ambigous as far as I can see, MCCR is not ambiguous, just wrong. It shows the head field as being twice as long as it actually is. Educate me on the difference between direct access and random access then. Sorry, I meant direct access with sequential. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
What Shmuel was pointing out that if you have the data set open normally, the DEB will have extent entries for each extent on each volume. Then the M will point to the m+1 th extent of the data set; if the DS has one extent per volume, then M=2 will address the 3rd volume, etc. If you've been doing the OPENJ with a single volser, then JFCBVLSQ should not be used, because you're making it appear to be a single, uncontinued data set? I'm trying to read a dataset that will potentially have many volumes each of which has up to 16 extents. I'm trying to open the dataset in a way that I get one volume at a time, with the DEB reflecting the extents of that volume. What you're talking about sounds like BDAM where you get a single logical view of a multivolume dataset? I'm wanting to do EXCP access and my understanding is that when you do this you get a simple DCB which is connected to one volume at a time and for which the DEB just reflects however many extents are on that volume. Certainly this is what I see, and this is how I'm performing my I/O. The question is why, when I declare my dataset DISP=OLD, do I get this behaviour, where when I open volume sequence number 2 I look at the DEB and the associated UCBs and they are indeed on the volume that I know to be the second one, whereas when I do the same with DISP=NEW the extents in the DEB are all on the first volume. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: I think that you misunderstand. I'm not trying to change the volser on which the dataset resides. I'm trying to open a particular volume sequence number in a multivolume set. You do that by specifying the JFCBVLSQ field specifying 1 if you want the first volume, 2 for the second etc. What Shmuel was pointing out that if you have the data set open normally, the DEB will have extent entries for each extent on each volume. Then the M will point to the m+1 th extent of the data set; if the DS has one extent per volume, then M=2 will address the 3rd volume, etc. If you've been doing the OPENJ with a single volser, then JFCBVLSQ should not be used, because you're making it appear to be a single, uncontinued data set? Gerhard Postpischil Bradford, VT -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 02/04/2008 at 07:46 AM, Tom Quarendon [EMAIL PROTECTED] said: I think that you misunderstand. No. I'm not trying to change the volser on which the dataset resides. Nor did I claim that you were. I'm trying to open a particular volume sequence number in a multivolume set. Don't confuse random access with direct access. The M field in a MCCR There is no MCCR, only an MBBCCHHR. Once I've got a DCB pointing at the correct volume You're confusing the DCB with the DEB. Take a dump and look at what is in each. construct a MCCHHRR corresponding to the TTTR The is no TTTR either. using the normal methods. No; if you were using the normal methods then you wouldn't be having the problem. I don't understand how the 'M' has a bearing on which volume I'm talking to. Specifying the extent number implicitly specifies the UCB address, which in turn specifies the volume. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
I've tried a number of things, but typically just VOLUME=SER=(volser1,volser2,volser3,volser3) I've also tried UNIT=(SYSDA,4) VOLUME=(,,,4) and I get the same problem. J R wrote: Are you specifying vol-count on your allocation? What does your allocation look like? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
I don't know how to open the data set in such a way, nor do I see why you need to do so. Suppose there are 16 volumes in the data set and each volume has 16 extents. Your DCB has a DDNAME=WHATEVER. Your DD statement for WHATEVER points to the data set name. You OPEN the DCB. Your DEB that will be constructed has 256 extent entries in it, with the first 16 pointing to the UCB for the first of the 16 volumes, the second set of 16 extent entries in the DEB all point to the UCB for the second of the 16 volumes, etc. You use EXCP to read this file. You construct your own MBBCCHHR in the IOB before doing the EXCP. You can put any value you want into the M byte. If you put a value between X'00' and X'0F' you will use one of the first 16 extent entries in the DEB and thus access volume 1. Etc. Whenever you want to go from volume(n) to volume(N+1) you will need a new M value, as also you will if you move from extent(x) to extent(x+1) within the same volume. The reason that you need to is that when using EXCP or BSAM, then OPEN only gives you access to one volume at a time. When you extend a dataset using EOV and the secondary allocation needs to be on a different volume, either because there is no space or because you've got 16 extents on the current volume, then the DCB is moved to the next volume and the DEB now has only one extent, which is the new extent on the new volume. Using BSAM or EXCP you don't get a DEB with extents in it from multiple volumes. So to read data from a previous extent you need to go back and with a seperate DCB open the previous volume. Also, you can have up to 255 volumes can't you? So in other words you can have more than 256 extents in total, so a 1 byte M isn't enough. For that reason alone you'd need multiple DCBs. Anyhow. The mechanism I'm using is to have one DCB per volume, as per the description in the section Using BSAM or EXCP for Random I/O to a Multivolume Data Set in DFSMSdfp Advanced Services. In that section it says If you open a BSAM or EXCP DCB for a multivolume data set, OPEN gives your program access to only one volume at a time and this is exactly what I see. The title Using EXCP for Random I/O to a Multivolume Data Set describes precisely what I'm trying to do, and indeed the method works just fine, except for this one case of not getting the right volume when I try and open volume 2 of a 3 or more volume set when the dataset is declared DISP=NEW. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: The question is why, when I declare my dataset DISP=OLD, do I get this behaviour, where when I open volume sequence number 2 I look at the DEB and the associated UCBs and they are indeed on the volume that I know to be the second one, whereas when I do the same with DISP=NEW the extents in the DEB are all on the first volume. As I see it you've been trying to fit a square peg into a round hole. Try something completely different: let your current output file be DD OUTFILE, with DISP=NEW. Add another DD, say EXCPFILE, with DISP=OLD,UNIT=SYSALLDA,DSN=index.whatever,VOL=SER=anyvol As long as you don't open it, you won't fail. Now do the RDJFCB for EXCPFILE, and update only the DSN, VOLSER, and flag bits. That should bypass the DISP=NEW/MOD difficulties. I would also set the do not rewrite DSCB, etc. bits, and close this file before you close OUTFILE. Gerhard Postpischil Bradford, VT -- 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: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
What you should see is a single DEB that shows ALL the extents, on ALL the volumes. you should be able to loop through all the extent descriptors in the DEB, calculating the extent numbers and CCHHR values in a fairly simple fashion. This will also help you detrmine the correct extent number. The MBBCCHHR values that you supply to IOS via your EXCP blocks need to be correct in both respects or the I/O will fail. You don't get that when you open for EXCP or BSAM. OPEN only allows you to access one volume at a time in those circumstances. Hence the need to manage a seperate DCB for each volume. When you declare DISP=NEW, there is no second volume. It won't be added until you actually try to write something in the 17th extent. I appreciate that. There is a second volume, and inded in my example third and forth, by the time that I've extended the dataset sufficiently using EOV. Why not just open it for QSAM access and avoid the entire problem? Unless you're trying to do something funky, there are very few good reasons to use EXCP. But the whole point is that I am trying to do something funky. Well, to a PC programmer it's hardly funky. All I want is a large random access scratch file with optimal performance. Doesn't sound too hard. By large I mean 4GB which restricts you. Got to be multi volume. VSAM LDS fits the bill and works fine, so long as you don't use DIV which can't cope with 4GB, but performance requirements and the acceptance of customers requires a physical sequential based solution. Meaning that you have to use EXCP and manage the seperate volumes yourself. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
I think that you misunderstand. No. Then I misunderstand you then. Don't confuse random access with direct access. I don't think I am. I'm not trying to use BDAM. However I am trying to access a direct access storage device with EXCP, non sequentially, i.e randomly. How do you think I'm confusing them? There is no MCCR, only an MBBCCHHR. My typo. You're confusing the DCB with the DEB. Take a dump and look at what is in each. Not really. Just my slightly slack language. I'm attempting to open a DCB pointing at one and only one volume, hence the use of the OPEN TYPE=J specifying the JFCBVLSQ field, as described in DFSMSdfp Advanced Services. The DEB associated with the DCB (there is only one) lists the extents of the dataset I've opened. This is how I'm determining which volume I'm getting when I've opened my DCB and how I determine that I'm getting the wrong one. The is no TTTR either. Well there is a TTTR -- I'm creating a TTTR representing where I logically want to access in the volume then convert that to an MBCCHHR to pass to the channel program to read the record off the disk. using the normal methods. No; if you were using the normal methods then you wouldn't be having the problem. By normal methods here I meant using the CVTPCNVT program to convert a TTTR to an MBBCCHHR with reference to a particular DEB. Not sure what you're refering to by normal methods. The problems aren't related to the conversion of TTTRs to MBCCHHRs, the problems are that the DCB is not connected to the right volume. I don't understand how the 'M' has a bearing on which volume I'm talking to. Specifying the extent number implicitly specifies the UCB address, which in turn specifies the volume. It certainly would if the extents in the DEB where spread across different volumes yes. However, the point is that when I've opened the DCB the DEB doesn't have the corretly list of extents in it. I open the DCB using OPEN TYPE=J specifying JFCBVLSQ=2 to open the second volume and what I get is a list of extents all of which have UCBs refering to the volume serial number of the first volume. This only happens when I specify DISP=NEW on my dataset. If I preallocate the dataset and declare it DISP=OLD in my JCL, then the process works. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
In a message dated 2/4/2008 11:54:44 A.M. Central Standard Time, [EMAIL PROTECTED] writes: The reason that you need to is that when using EXCP or BSAM, then OPEN only gives you access to one volume at a time. ... etc. ... etc. I have never done an EXTEND or altered the volume sequence number in the JFCB, which I now recollect is what you are doing, so my comments do not fit your situation. Sorry for the confusion. Bill Fairchild Rocket Software **Biggest Grammy Award surprises of all time on AOL Music. (http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp00300025 48) -- 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: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
-snip- The M field in a MCCR is the extent number. Once I've got a DCB pointing at the correct volume I construct a MCCHHRR corresponding to the TTTR that I want within that volume using the normal methods. I don't understand how the 'M' has a bearing on which volume I'm talking to. -unsnip Last I knew it was still MBBCCHHR, thanks to the peculiar addressing required for the old 2321 Data Cell Drive. -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom, The following commends are on the question of why you get different results with a DISP=NEW and a DISP=OLD data set. With DISP=NEW, except for the first volume, until you write to a volume there is, logically, no volume. You only create the operating system structures for a new volume when EOV is driven and that EOV forced a new volume. I have done what you are talking about for both DISP=OLD and DISP=NEW data sets. It is difficult and you have to basically open a DCB for each volume. With DISP=NEW, the first DCB you open will always be associated with the last volume written to. This is because when you issue an EOV and you go to a new volume, the DCB and other control blocks are disassociated with the old volume and are now associated with the new volume. To get to the previous volume, you have to open a new DCB pointing to the previous volume. With DISP=OLD life is much easier, unless you are going to extend the data set. In that case you can open a DCB for each existing volume. If you extend the last dataset by doing an EOV, the DCB that was pointing at the last will now be pointing at the new last volume. If you want to get at the old last volume you have to open a new DCB pointing at the old last volume. Have I confused you enough? Please contact me offline if you have more questions that you think I can help you with. Chris Blaicher BMC Software, Inc. 512-340-6154 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Quarendon Sent: Monday, February 04, 2008 10:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Trouble opening specific volumes with OPEN TYPE=J I've tried a number of things, but typically just VOLUME=SER=(volser1,volser2,volser3,volser3) I've also tried UNIT=(SYSDA,4) VOLUME=(,,,4) and I get the same problem. J R wrote: Are you specifying vol-count on your allocation? What does your allocation look like? __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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
Re: Trouble opening specific volumes with OPEN TYPE=J
The question is why, when I declare my dataset DISP=OLD, do I get this behaviour, where when I open volume sequence number 2 I look at the DEB and the associated UCBs and they are indeed on the volume that I know to be the second one, whereas when I do the same with DISP=NEW the extents in the DEB are all on the first volume. Are you specifying vol-count on your allocation? What does your allocation look like? Date: Mon, 4 Feb 2008 15:30:23 + From: [EMAIL PROTECTED] Subject: Re: Trouble opening specific volumes with OPEN TYPE=J To: IBM-MAIN@BAMA.UA.EDU I'm trying to read a dataset that will potentially have many volumes each of which has up to 16 extents. I'm trying to open the dataset in a way that I get one volume at a time, with the DEB reflecting the extents of that volume. What you're talking about sounds like BDAM where you get a single logical view of a multivolume dataset? I'm wanting to do EXCP access and my understanding is that when you do this you get a simple DCB which is connected to one volume at a time and for which the DEB just reflects however many extents are on that volume. Certainly this is what I see, and this is how I'm performing my I/O. The question is why, when I declare my dataset DISP=OLD, do I get this behaviour, where when I open volume sequence number 2 I look at the DEB and the associated UCBs and they are indeed on the volume that I know to be the second one, whereas when I do the same with DISP=NEW the extents in the DEB are all on the first volume. _ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join -- 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: Trouble opening specific volumes with OPEN TYPE=J
In a message dated 2/4/2008 9:32:48 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I'm trying to read a dataset that will potentially have many volumes each of which has up to 16 extents. I'm trying to open the dataset in a way that I get one volume at a time, with the DEB reflecting the extents of that volume. I don't know how to open the data set in such a way, nor do I see why you need to do so. Suppose there are 16 volumes in the data set and each volume has 16 extents. Your DCB has a DDNAME=WHATEVER. Your DD statement for WHATEVER points to the data set name. You OPEN the DCB. Your DEB that will be constructed has 256 extent entries in it, with the first 16 pointing to the UCB for the first of the 16 volumes, the second set of 16 extent entries in the DEB all point to the UCB for the second of the 16 volumes, etc. You use EXCP to read this file. You construct your own MBBCCHHR in the IOB before doing the EXCP. You can put any value you want into the M byte. If you put a value between X'00' and X'0F' you will use one of the first 16 extent entries in the DEB and thus access volume 1. Etc. Whenever you want to go from volume(n) to volume(N+1) you will need a new M value, as also you will if you move from extent(x) to extent(x+1) within the same volume. What you're talking about sounds like BDAM where you get a single logical view of a multivolume dataset? The access method is irrelevant. You will get the same kind of multi-extent DEB whether you use EXCP, XDAP, BDAM, BSAM , QSAM, BISAM, QISAM, or BPAM. I'm wanting to do EXCP access and my understanding is that when you do this you get a simple DCB which is connected to one volume at a time and for which the DEB just reflects however many extents are on that volume. Certainly this is what I see, and this is how I'm performing my I/O. I don't know where you see this, because this is not what you get. You get a simple DCB, whatever that means, that is connected to (points to) a single complex DEB (I just made up the descriptor complex) that points to ALL the extents in the file regardless of the volume involved. Create a multi-volume file, OPEN a simple DCB to it, ABEND, and study the construction of the DEB, not the DCB. Bill Fairchild Rocket Software **Biggest Grammy Award surprises of all time on AOL Music. (http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp00300025 48) -- 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: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
snip--- I'm trying to read a dataset that will potentially have many volumes each of which has up to 16 extents. I'm trying to open the dataset in a way that I get one volume at a time, with the DEB reflecting the extents of that volume. What you're talking about sounds like BDAM where you get a single logical view of a multivolume dataset? I'm wanting to do EXCP access and my understanding is that when you do this you get a simple DCB which is connected to one volume at a time and for which the DEB just reflects however many extents are on that volume. Certainly this is what I see, and this is how I'm performing my I/O. ---unsnip- What you should see is a single DEB that shows ALL the extents, on ALL the volumes. you should be able to loop through all the extent descriptors in the DEB, calculating the extent numbers and CCHHR values in a fairly simple fashion. This will also help you detrmine the correct extent number. The MBBCCHHR values that you supply to IOS via your EXCP blocks need to be correct in both respects or the I/O will fail. --snip-- The question is why, when I declare my dataset DISP=OLD, do I get this behaviour, where when I open volume sequence number 2 I look at the DEB and the associated UCBs and they are indeed on the volume that I know to be the second one, whereas when I do the same with DISP=NEW the extents in the DEB are all on the first volume. ---unsnip- When you declare DISP=NEW, there is no second volume. It won't be added until you actually try to write something in the 17th extent. Why not just open it for QSAM access and avoid the entire problem? Unless you're trying to do something funky, there are very few good reasons to use EXCP. -- 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: Trouble opening specific volumes with OPEN TYPE=J
As I see it you've been trying to fit a square peg into a round hole. Doesn't seem like square peg and round hole to me, actually it all seems to work quite neatly, just so long as the dataset is DISP=OLD. Try something completely different: let your current output file be DD OUTFILE, with DISP=NEW. Add another DD, say EXCPFILE, with DISP=OLD,UNIT=SYSALLDA,DSN=index.whatever,VOL=SER=anyvol As long as you don't open it, you won't fail. Now do the RDJFCB for EXCPFILE, and update only the DSN, VOLSER, and flag bits. That should bypass the DISP=NEW/MOD difficulties. I would also set the do not rewrite DSCB, etc. bits, and close this file before you close OUTFILE. That workaround has been suggested to me, but I've yet to try it out. I would need to dynamically allocate a new ddname using SVC99 with matching parameters (dataset name, dcb information, space allocation, but primarily anything that might affect volume allocation, such as unit, unitcount, volume count, volume serial numbers etc), then do all of my access through that DCB instead of the one that the user has set up. I was hoping for a proper resolution, ideally consisting of you've forgotten to set bit X in field Y. soon however I will have to start implementing the workaround to see if it helps. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 02/04/2008 at 04:37 PM, Tom Quarendon [EMAIL PROTECTED] said: I don't think I am. I'm not trying to use BDAM. Don't confuse random access with BDAM. Well there is a TTTR No, there is a TTR. MBCCHHR Another typo; that should be 64 bits, not 56. By normal methods here I meant using the CVTPCNVT program to convert a TTTR to an MBBCCHHR with reference to a particular DEB. That supports multi-volume data sets. However, the point is that when I've opened the DCB the DEB doesn't have the corretly list of extents in it. I open the DCB using OPEN TYPE=J specifying JFCBVLSQ=2 to open the second volume and what I get is a list of extents all of which have UCBs refering to the volume serial number of the first volume. All of which? Do you have multiple extents on the first volume, or are there duplicate extents in the DEB? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 02/04/2008 at 07:16 PM, Tom Quarendon [EMAIL PROTECTED] said: But the whole point is that I am trying to do something funky. Well, to a PC programmer it's hardly funky. All I want is a large random access scratch file with optimal performance. I'd expect better performance from ESDS or RSDS than from EXCP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: That workaround has been suggested to me, but I've yet to try it out. I would need to dynamically allocate a new ddname using SVC99 with matching parameters (dataset name, dcb information, space allocation, but primarily anything that might affect volume allocation, such as unit, unitcount, volume count, volume serial numbers etc), then do all of my access through that DCB instead of the one that the user has set up. I think you missed the point - no dynamic allocation, as that would just get you back where you started. All you need is another DD, with DISP=OLD, and no catalog access (i.e., explicit unit and volume) to modify the JFCB for. OPEN won't know or care that it's a multi-volume DS, and just build the DEB for the volume/unit you put into the JFCB. Gerhard Postpischil Bradford, VT -- 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: SPAM: Re: Trouble opening specific volumes with OPEN TYPE=J
I'd expect better performance from ESDS or RSDS than from EXCP. Not in our experience. We've tried all possible forms of I/O and LDS was certainly the best when it comes to VSAM. zFS is implemented as VSAM LDS files and I assume that they know what they are doing. from recollectin ESDS and RRDS performance wasn't great by comparison, so we dropped that exploration farily early on. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
Don't confuse random access with BDAM. We'll you'll have to tell me what I am confusing then because I don't understand what you mean. Educate me on the difference between direct access and random access then. No, there is a TTR. No, there is a TTTR. I'm using the offset +12 CVTPCNVT entry point which takes a TTTR and not a TTRn to create my MBBCCHHR. Another typo; that should be 64 bits, not 56. Whatever. I don't think that that is ambigous as far as I can see, not like TTR verses TTTR. That supports multi-volume data sets. Not sure what you mean. You can use the CVTPCNVT routine regardless, multivolume or not. And anyway the DEB will only ever have extents from one volume, because OPEN for EXCP only ever gives you access to one volume at a time, so in fact as far as CVTPCNVT is concerned it is a single volume dataset, not that that really makes a difference to CVTPCNVT I imagine. All of which? Do you have multiple extents on the first volume, or are there duplicate extents in the DEB? There are multiple extents on each of multiple volumes. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
I think you missed the point - no dynamic allocation, as that would just get you back where you started. All you need is another DD, with DISP=OLD, and no catalog access (i.e., explicit unit and volume) to modify the JFCB for. OPEN won't know or care that it's a multi-volume DS, and just build the DEB for the volume/unit you put into the JFCB. But to create the second DD would require an SVC99 call. This would have to be done transparantly -- we can't require the user to provide two DDnames for each dataset they want to access in this way. I'm not talking about dynamic allocation in the sense of actually allocating a dataset, but of dynamically allocating a DDname using SVC99. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 01/14/2008 at 11:34 AM, Gerhard Postpischil [EMAIL PROTECTED] said: I don't have access to my docs right now, otherwise I would have specified the bit, but JFCVSL sounds correct. It needs to be set on any OPEN when there is a changed data set name or serial. I seem to recall setting it for a changed member name also. I'm pretty sure that it's not required for a changed member. My recollection is that it's strictly for a changed volser. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
In [EMAIL PROTECTED], on 01/14/2008 at 01:09 PM, Tom Quarendon [EMAIL PROTECTED] said: I'm trying to write some code that performs random access I/O on a multi volume dataset using a technique similar to that described in chapter 7 of DFSMSdfp Advanced Services, and am having mixed results. Probably because you're using the wrong tool. The code all works just fine, so long as the dataset I'm dealing with exists already, or is allocated in a previous step of my job using, for example, an EXEC PGM=IEFBR14 step. If I try and allocate the dataset in the step that actually performs the I/O as a DISP=(NEW,CATLG) or DISP=(NEW,DELTE) dataset, then when I try and open specific volumes by changing the JFCBVLSQ field in the JFCB prior to performing an OPEN TYPE=J, then I don't get the right volume. What do you mean by that? The OPENJ does not[1] change the TIOT, so you're still pointing to the same UCB's as before. Since MVS no longer supports mountable DASD, that means that you can only succeed in changing a volser that you already have allocated. That means that you don't need an RDJFCB at all, just a correct calculation of the extent number. It seems to me like I always get the first volume. That's expected if you always set M to 0. [1] Well, it may do a DYNALLOC under the covers, but that's just for ENQ housekeeping. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Trouble opening specific volumes with OPEN TYPE=J
Probably because you're using the wrong tool. And the correct tool in your opinion is? What do you mean by that? The OPENJ does not[1] change the TIOT, so you're still pointing to the same UCB's as before. Since MVS no longer supports mountable DASD, that means that you can only succeed in changing a volser that you already have allocated. That means that you don't need an RDJFCB at all, just a correct calculation of the extent number. I think that you misunderstand. I'm not trying to change the volser on which the dataset resides. I'm trying to open a particular volume sequence number in a multivolume set. You do that by specifying the JFCBVLSQ field specifying 1 if you want the first volume, 2 for the second etc. It seems to me like I always get the first volume. That's expected if you always set M to 0. The M field in a MCCR is the extent number. Once I've got a DCB pointing at the correct volume I construct a MCCHHRR corresponding to the TTTR that I want within that volume using the normal methods. I don't understand how the 'M' has a bearing on which volume I'm talking to. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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: Trouble opening specific volumes with OPEN TYPE=J
I don't have access to my docs right now, otherwise I would have specified the bit, but JFCVSL sounds correct. It needs to be set on any OPEN when there is a changed data set name or serial. I seem to recall setting it for a changed member name also. I've tried setting the JFCBVSL flag before I open a volume with the JFCBVLSQ field set, but it doesn't seem to make any difference. Do you have a documentation reference for that? -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: I've tried setting the JFCBVSL flag before I open a volume with the JFCBVLSQ field set, but it doesn't seem to make any difference. Do you have a documentation reference for that? The only reference I found was in the source code for OPEN, many, many moons ago. I've never had a problem with it, however I expect that our environments are different. About all I can suggest at this point is that you try a simple test program, and dump it just before and after the OPENJ, to verify the contents. Additional control blocks (TIOT, SIOTs, etc.) may be helpful. The other thing you might try, if your environment permits it, is to run authorized, and build the DCB, DEB, IOB, etc. on the fly, and avoid O/C/E code completely. But I don't know whether your security or audit staff would be too thrilled by that. Gerhard Postpischil Bradford, VT -- 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
Trouble opening specific volumes with OPEN TYPE=J
I'm trying to write some code that performs random access I/O on a multi volume dataset using a technique similar to that described in chapter 7 of DFSMSdfp Advanced Services, and am having mixed results. The code all works just fine, so long as the dataset I'm dealing with exists already, or is allocated in a previous step of my job using, for example, an EXEC PGM=IEFBR14 step. If I try and allocate the dataset in the step that actually performs the I/O as a DISP=(NEW,CATLG) or DISP=(NEW,DELTE) dataset, then when I try and open specific volumes by changing the JFCBVLSQ field in the JFCB prior to performing an OPEN TYPE=J, then I don't get the right volume. It seems to me like I always get the first volume. I don't believe that there's anything fundamentally wrong with the code as it works fine if I allocate an empty multivolume dataset and reference it as DISP=OLD in the step that's going to do the work. I also get similar problems if I use DISP=MOD, only this time I get only either the first or the last volume -- try and open anything in the middle and I always get the last. This I wasn't so worried about since I get just use DISP=OLD instead and this works fine. So I guess my question is, is OPEN TYPE=J specifying the JFCBVLSQ field supposed to work on DISP=NEW datasets? Has anyone had success with this? Current this is a bit of a show stopper for us as ideally we need to be able to use a multivolume temporary dataset (so declared DISp=(NEW,DELETE,DELETE) with a DSN of something like WPSTEMP). Many thanks. -- 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: Trouble opening specific volumes with OPEN TYPE=J
I haven't and maybe that what my problem is. The documentation as far as I can see makes no mention of that, at least not in the example in chapter 7 of DFSMSdfp Advanced Services. Do you mean the JFCVSL bit in JFCBTSDM? You mean that the problem is that it doesn't realise that I've added a new volume and hence is opening the wrong one? I.E I need to set this flag once I've done an EOV to extentd the file? Or do I need to set this bit in order for it to take notice of the value I've put in the JFCBVLSQ field? I can't find any documentation of the JFCVSL field other than just the short description of the field in in the MVS Data Area manual. Thanks for your help on this. Gerhard Postpischil wrote: You make no mention of changing anything else in the JFCB. Did you set the volume serial changed bit? -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: So I guess my question is, is OPEN TYPE=J specifying the JFCBVLSQ field supposed to work on DISP=NEW datasets? Has anyone had success with this? You make no mention of changing anything else in the JFCB. Did you set the volume serial changed bit? Gerhard Postpischil Bradford, VT -- 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: Trouble opening specific volumes with OPEN TYPE=J
Tom Quarendon wrote: Do you mean the JFCVSL bit in JFCBTSDM? You mean that the problem is that it doesn't realise that I've added a new volume and hence is opening the wrong one? I don't have access to my docs right now, otherwise I would have specified the bit, but JFCVSL sounds correct. It needs to be set on any OPEN when there is a changed data set name or serial. I seem to recall setting it for a changed member name also. Gerhard Postpischil Bradford, VT -- 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: Trouble opening specific volumes with OPEN TYPE=J
---snip--- I'm trying to write some code that performs random access I/O on a multi volume dataset using a technique similar to that described in chapter 7 of DFSMSdfp Advanced Services, and am having mixed results. The code all works just fine, so long as the dataset I'm dealing with exists already, or is allocated in a previous step of my job using, for example, an EXEC PGM=IEFBR14 step. If I try and allocate the dataset in the step that actually performs the I/O as a DISP=(NEW,CATLG) or DISP=(NEW,DELTE) dataset, then when I try and open specific volumes by changing the JFCBVLSQ field in the JFCB prior to performing an OPEN TYPE=J, then I don't get the right volume. It seems to me like I always get the first volume. I don't believe that there's anything fundamentally wrong with the code as it works fine if I allocate an empty multivolume dataset and reference it as DISP=OLD in the step that's going to do the work. I also get similar problems if I use DISP=MOD, only this time I get only either the first or the last volume -- try and open anything in the middle and I always get the last. This I wasn't so worried about since I get just use DISP=OLD instead and this works fine. So I guess my question is, is OPEN TYPE=J specifying the JFCBVLSQ field supposed to work on DISP=NEW datasets? Has anyone had success with this? Current this is a bit of a show stopper for us as ideally we need to be able to use a multivolume temporary dataset (so declared DISp=(NEW,DELETE,DELETE) with a DSN of something like WPSTEMP). -unsnip--- Dumb question: While you're doing this random access, is there any data at the points you're trying to access? Most, though perhaps not all, random access dataset have data pre-loaded, or at least the areas being accesses are pre-formatted. We need more information about what you're trying to accomplish before we can even postulate a theory about your problem. Why multi-volume? Why temporary? How is it being used? -- 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: Trouble opening specific volumes with OPEN TYPE=J
Dumb question: While you're doing this random access, is there any data at the points you're trying to access? Most, though perhaps not all, random access dataset have data pre-loaded, or at least the areas being accesses are pre-formatted. We need more information about what you're trying to accomplish before we can even postulate a theory about your problem. Why multi-volume? Why temporary? How is it being used? It's multi-volume because it's very large. We need to have datasets that are more than 4GB. We use EXCP to access the datasets for performance reasons. The datasets we process can be temporary and they can be permanent. Temporary ones are used for work storage for intermediate results and then permanent datasets are updated. The dataset is not preloaded, it often starts empty and then grows with random reads/writes, and is often temporary so chucked away again. We track the size (high water mark) of the datasets and as data is written to it use either an update record or a format record channel command appropriately to write the data to the datasets (the data is not sparse -- the dataset is expanded sequentially). When necessary we issue an EOV macro to expand the dataset when we need to write beyond the end of the current extent. In the case of multivolume dataset this may result in the new extent being created in a different volume. We keep a seperate DCB for each volume in the multi volume dataset. When the EOV causes a shift to a new volume, the DCB now relates to that new volume so we update our list accordingly. So in the case of the temporary datasets they start out empty and then as the processing runs the temporary dataset gets filled up, potentially expanding to multiple volumes as necessary. So lets say we want to write data to a given byte offset (an RBA if you like). We translate the RBA into a volume sequence number and a TTTR and then check to see if we've currently got the relevant DCB open. If not then we open is using the RDJFCB/OPEN TYPE=J method specifying the volume sequence number in the JFCB. At this point I check whether the volume serial numbers of the UCBs associated with each extent match what I would expect given the information in the list of volume serial numbers in the JFCB, and this is where I detect that the wrong volume is sometimes opened. Having made sure that we've got the right DCB for the volume we then translate the TTTR into an MBBCCHHR in that dataset and write the relevant block using a write update record or format track channel program. The program only ever reads and writes a block (hardware record) at a time, so there's no concern about having to update partial records and that kind of thing. So that's the basic scenario. If you're familar with SAS, then think MXG processing. The SMF data is read in and many large datasets are created in the WORK library (which is temporary). The WORK library can be many GB in size. WORK libraries are temporary. What we're doing is equivalent to SAS data libraries. Identical in fact as we write a SAS clone. It all works swimmingly (and btw, a lot faster than any other I/O method we've tried -- C runtime library, BSAM, VSAM of all flavours -- of which only VSAM can cope with the volumes we need), apart from the OPEN TYPE=J not always seeming to open the correct volume in the case when the dataset is DISP=NEW, or indeed DISP=MOD. If it's DISP=OLD, it (appears) to work correctly. -- 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
