Re: Track capacity?
Charles Mills wrote: I care because I am trying to debug a problem at a customer site. There are about a thousand considerations that I have left out of my note - life is more complex than the average listserve question. If I had posted the entire universe of issues, it would have been a very long note. I am looking for clues so as to debug how an unexpected SB37-04 might have come about. I don't have direct to the customer machine. The customer personnel are incredibly busy. Quick thoughts: 1. RLSE Check RLSE, or SMS RLSE (management class parameter). It can be the reason in case when the dataset is closed and then reopen again. 2. Change DD, create permanent dataset. make the allocation twice, see the parameters after the job, compare it to DD specification. -- Radoslaw Skorupka Lodz, Poland -- 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: Track capacity?
Thanks Radoslaw, RLSE is a good thought that had not occurred to me. The answer, as it happens, turns out to be that the SMS classes are apparently setting RECFM=U. My product always honors the wishes of the programmer who set up the JCL and therefore writes a dataset (that ideally should be RECFM=FBA) as RECFM=U, BLKSIZE=27951, and so a mere 598 records eat up an entire 299-track allocation. Thanks everyone for your thoughts and suggestions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Monday, June 19, 2006 12:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Quick thoughts: 1. RLSE Check RLSE, or SMS RLSE (management class parameter). It can be the reason in case when the dataset is closed and then reopen again. 2. Change DD, create permanent dataset. make the allocation twice, see the parameters after the job, compare it to DD specification. -- 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: Track capacity?
Thanks for your reply at least that verifies my original thought that 47476 was the 'track capacity' as published by IBM and that my memory may be still partially functioning James F. Smith \ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: 17 June 2006 21:40 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? James F Smith wrote: That doesn't look right, but please consider my bad memory. But wasn't the track capacity for a 3380 - 47476??? you are talking about the largest formated record w/o key. if you look at the calculation, a keyless record required adding 12 bytes and rounded up to multiple of 32bytes and then adding 480 to calculate how much of raw track capacity a formated record took. so single formated record 47476 and adding 12 = 47488 by chance is multiple of 32 and 47488+480 = 47968 47968 is the raw, unformated track capacity. each formated record has overhead, as per the calculation. re: http://www.garlic.com/~lynn/2006m.html#5 track capacity i've done qd conversion of the old gcard ios3270 to html. http://www.garlic.com/~lynn/gcard.html it has record size calculations ... but it predated 3390 ... so only has up thru 3380 http://www.garlic.com/~lynn/gcard.html#26.3 from above Track Record Size Device CapacityWithout keyWith key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12)704+#(K+12)+#(D+12) Device CapacityWithout keyWith key Notes: D is data length, K is key length # means round up to multiple of 32 -- 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: Track capacity?
James F Smith wrote: That doesn't look right, but please consider my bad memory. But wasn't the track capacity for a 3380 - 47476??? you are talking about the largest formated record w/o key. if you look at the calculation, a keyless record required adding 12 bytes and rounded up to multiple of 32bytes and then adding 480 to calculate how much of raw track capacity a formated record took. so single formated record 47476 and adding 12 = 47488 by chance is multiple of 32 and 47488+480 = 47968 47968 is the raw, unformated track capacity. each formated record has overhead, as per the calculation. re: http://www.garlic.com/~lynn/2006m.html#5 track capacity i've done qd conversion of the old gcard ios3270 to html. http://www.garlic.com/~lynn/gcard.html it has record size calculations ... but it predated 3390 ... so only has up thru 3380 http://www.garlic.com/~lynn/gcard.html#26.3 from above Track Record Size Device CapacityWithout keyWith key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12)704+#(K+12)+#(D+12) Device CapacityWithout keyWith key Notes: D is data length, K is key length # means round up to multiple of 32 -- 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: Track capacity?
No, I asked about 3390. The Wheelers responded that they had only older data up to the 3380. That was the only reference to 3380s. (Others provided 3390 data.) I'm boggled by this thing. - I'm 99% sure only ~600 records were written. - I'm 95% sure the extent was 104 tracks primary plus potentially 15 x 13 tracks secondary. - The data is 121 bytes long - The records should have been blocked to SDB. How the heck did I run out of space? To review, it's software with a lot of options and a lot of ability to pick up defaults from many places, and I am dealing with multiple layers of customer personnel - I have no ability to just run a test on the machine in question. The problem is occurring only when my software is loaded by another vendor product that I don't have here. Interesting. I'm looking at the numbers above. The full extent would be 299 tracks. IF the records somehow got written LRECL= roughly 1/2 track unblocked then it would run out of space at about 600 records. IF the vendor product pre-set the file's attributes to LRECL= roughly 1/2 track then it would account for this problem. That may be the angle I pursue. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of James F Smith Sent: Saturday, June 17, 2006 2:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? That doesn't look right, but please consider my bad memory. But wasn't the track capacity for a 3380 - 47476??? James F. Smith Bayshore Consulting Services [EMAIL PROTECTED] tel +86 10 6439 1733 fax +86 10 8046 2133 Skype jamesfs1 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: 17 June 2006 02:49 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Charles Mills wrote: all disks since dinosaurs roamed the Earth. Heck, it's got the 2311 and 2305. (That should be enough start up another one of those darned mainframe nostalgia threads.) i've done qd conversion of the old gcard ios3270 to html. http://www.garlic.com/~lynn/gcard.html it has record size calculations ... but it predated 3390 ... so only has up thru 3380 http://www.garlic.com/~lynn/gcard.html#26.3 -- 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: Track capacity?
In a message dated 6/17/2006 4:39:03 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: That doesn't look right, but please consider my bad memory. But wasn't the track capacity for a 3380 - 47476??? You start with the total number of bytes on the track, called track length' in the device geometry charts (e.g., 3990 or 2105 control unit reference book). A 3380 has a track length of 47968 (in Lynn Wheeler's formula below), and a 3390 has a track length of 58786. Then subtract all the following: how many bytes are used for the first gap between index point and the beginning of the home address, how many bytes it takes to store the full home address on the track, how many bytes are used for the next gap after the home address and before the R0 count field, how many bytes it takes to store a count field on the track, and how many bytes are used for the next gap after the count field. If you want to, you can use all these bytes for an R0 with a really big data field and/or even with a 255-byte key. This is very seriously contraindicated and not recommended. It is much better to let standard access methods build the rest of the track, in which case you must also subtract all the following: how many bytes it takes to store an 8-byte data field (standard R0 has no key and an 8-byte data field), how many bytes are used for a gap between the end of R0's data field and the beginning of the first real user record's count field, how many bytes it takes to store a count field on the track, and how many bytes are used for the gap after a count field. This yields a somewhat smaller number, called variously the size of the largest user record on the track, largest R1, or something like that. It is seriously recommended that you let standard access methods build this record and call it record number 1, or R1. But if you want to, you can write your own channel program to write this user record and use EXCP or STARTIO to write the record with anything you want in the record ID' part of the count field. Normally, the record ID will contain the CCHHR of the record, but, since my name is Bill Fairchild, I could put the five characters BILLF in the count field of every record I write on the track. Again strongly not recommended. The TRKCACL system service uses all the various device geometry variables to calculate the effective size of a record with a given key length and a given data length as it would require when stored on a track. This number must be subtracted from the total remaining user-usable bytes on the track, called track balance. If the remainder is non-negative, the record will fit on the track. Charts that tell how many records of a given size will fit on a track use this process and assume that all records have the same key length and data length. To make matters worse, you can't simply use your data length in computing how many bytes are needed to store that data field on the track, as data is no longer stored byte-for-byte on tracks. In the early days of S/360 DASD it was, but ever since the 3330 (I think, but I could be wrong) data has been written by the control unit not in bytes but in cells. If the cell length is 32, e.g., a one-byte data field will require 32 bytes on the track to hold one whole cell, of which only one byte is used by the user. Lynn Wheeler's formulae reflect the necessity for such cells. For a 3390, the largest possible user record (R1 data field) with no key is 56664 bytes ( I think). From an earlier post by Lynn Wheeler: Track Record Size Device CapacityWithout keyWith key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12) 704+#(K+12)+#(D+12) Bill Fairchild -- 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
Track capacity?
Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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: Track capacity?
The CBT tape has a block size calculation program called BLKDISK on file 296 which might fit the bill. Or you could order the IBM 3390 Direct Access Storage: Reference Summary GX26-4577. Regards, John Kalinich Computer Sciences Corp Charles Mills [EMAIL PROTECTED] To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Track capacity? 06/16/2006 12:13 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills -- 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: Track capacity?
56664 bytes per 3390 track. see ISMF option 8.5, assuming that your base config is defined as 3390. There used to be a 3390 Migration redbook that had a handy track/block utilization table. Unfortunately I can't find it online. Suggest using Blksize=0 to ensure half track blocking. -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 1:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Track capacity? Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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: Track capacity?
Quickref has it (item 3390DASD). I would expect it is available on the IBM web site but I don't have very much luck when I use their search feature. A blocksize of 605 will result in 45 blocks per track which results in slightly less than 50% utilization. Your primary is 104 tracks and your secondary is 13 tracks. 121 byte blocks result in 75 blocks per track -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 10:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Track capacity? Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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: Track capacity?
First hit on Google http://sdisw.com/vm/dasd_capacity.html I've used this page in the past. Just eyeballing it, it appears to be accurate. (It's even got numbers for a 2314) At 01:13 PM 6/16/2006, Charles Mills said: Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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: Track capacity?
Good grief! IBM is going to charge me $1.81 to mail this to me rather than letting me see it on line??? Hey, IBM I'll offer you $2.00 if I can see it on line! $3.00? $5.00? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John P Kalinich Sent: Friday, June 16, 2006 10:29 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? The CBT tape has a block size calculation program called BLKDISK on file 296 which might fit the bill. Or you could order the IBM 3390 Direct Access Storage: Reference Summary GX26-4577. -- 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: Track capacity?
all disks since dinosaurs roamed the Earth. Heck, it's got the 2311 and 2305. (That should be enough start up another one of those darned mainframe nostalgia threads.) Thanks! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Harrison Sent: Friday, June 16, 2006 10:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? First hit on Google http://sdisw.com/vm/dasd_capacity.html I've used this page in the past. Just eyeballing it, it appears to be accurate. (It's even got numbers for a 2314) -- 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: Track capacity?
THANK YOU. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, June 16, 2006 10:32 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Quickref has it (item 3390DASD). I would expect it is available on the IBM web site but I don't have very much luck when I use their search feature. A blocksize of 605 will result in 45 blocks per track which results in slightly less than 50% utilization. Your primary is 104 tracks and your secondary is 13 tracks. 121 byte blocks result in 75 blocks per track -- 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: Track capacity?
It's a long, long time since I've used it but take a look at the TRKCALC macro. It's well documented within SYS1.MACLIB(TRKCALC). From: Charles Mills [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Track capacity? Date: Fri, 16 Jun 2006 10:13:17 -0700 Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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 _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: Track capacity?
On Fri, 16 Jun 2006 10:13:17 -0700, Charles Mills wrote: Where can I find 3390 track capacity tables or formulas? The online copy of Using IBM 3390 in an MVS Environment: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/AM3U1001/CONTENTS Specifically, Appendix B has the tables: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/AM3U1001/B.1.2 Bill Godfrey -- 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: Track capacity?
Charles Mills wrote: all disks since dinosaurs roamed the Earth. Heck, it's got the 2311 and 2305. (That should be enough start up another one of those darned mainframe nostalgia threads.) i've done qd conversion of the old gcard ios3270 to html. http://www.garlic.com/~lynn/gcard.html it has record size calculations ... but it predated 3390 ... so only has up thru 3380 http://www.garlic.com/~lynn/gcard.html#26.3 from above Track Record Size Device CapacityWithout keyWith key 3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) 3380 47968 480+#(D+12)704+#(K+12)+#(D+12) Device CapacityWithout keyWith key Notes: D is data length, K is key length # means round up to multiple of 32 3390 track capacity is listed as 56,664 -- 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: Track capacity?
I'll ask Why to you care? and suggest try it and see :) Dave Gibney [EMAIL PROTECTED] System Programmer(509) 335-7359 Information Technology Washington State University Pullman, WA 99164-1222 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 10:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? THANK YOU. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, June 16, 2006 10:32 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Quickref has it (item 3390DASD). I would expect it is available on the IBM web site but I don't have very much luck when I use their search feature. A blocksize of 605 will result in 45 blocks per track which results in slightly less than 50% utilization. Your primary is 104 tracks and your secondary is 13 tracks. 121 byte blocks result in 75 blocks per track -- 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: Track capacity?
I care because I am trying to debug a problem at a customer site. There are about a thousand considerations that I have left out of my note - life is more complex than the average listserve question. If I had posted the entire universe of issues, it would have been a very long note. I am looking for clues so as to debug how an unexpected SB37-04 might have come about. I don't have direct to the customer machine. The customer personnel are incredibly busy. Is that sufficient justification for asking this question? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Friday, June 16, 2006 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? I'll ask Why to you care? and suggest try it and see :) -- 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: Track capacity?
Yup, more than enough. I forget that I'm at my site with enough authority to test stuff like this. And I have SMS set up so that I really don't care. Dave Gibney [EMAIL PROTECTED] System Programmer(509) 335-7359 Information Technology Washington State University Pullman, WA 99164-1222 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 12:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? I care because I am trying to debug a problem at a customer site. There are about a thousand considerations that I have left out of my note - life is more complex than the average listserve question. If I had posted the entire universe of issues, it would have been a very long note. I am looking for clues so as to debug how an unexpected SB37-04 might have come about. I don't have direct to the customer machine. The customer personnel are incredibly busy. Is that sufficient justification for asking this question? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Friday, June 16, 2006 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? I'll ask Why to you care? and suggest try it and see :) -- 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: Track capacity?
Charles, my response has nothing to do with track capacity, but since you mentioned an unexpected SB37-04 and previously talked about a blocksize mismatch between JCL and actual allocation ... Is the user's program, by any chance, a COBOL program? Does the JCL hardcode a blocksize value (or BLKSIZE=0), yet you still end up with an unblocked dataset? If the answer to both questions is Yes, please check the program source: In the FD of the output file in question, did the programmer explicitly code the phrase BLOCK CONTAINS 0 RECORDS? If that phrase is omitted, you get a compiler default of block contains _1(one)_ record. I found that forgetting to put this clause on FD definitions for sequential output files is a frequent cause of problems. HTH. Regards, Ulrich Krueger Mainframe Systems Services National Semiconductor Corp. Santa Clara, CA 95051 Tel: (408) 721-8071 Email: [EMAIL PROTECTED] IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/16/2006 12:39:05 PM: I care because I am trying to debug a problem at a customer site. There are about a thousand considerations that I have left out of my note - life is more complex than the average listserve question. If I had posted the entire universe of issues, it would have been a very long note. I am looking for clues so as to debug how an unexpected SB37-04 might have come about. I don't have direct to the customer machine. The customer personnel are incredibly busy. Is that sufficient justification for asking this question? Charles -- 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: Track capacity?
To answer the question about the number fo records...75 per track from 94 to 124 bytes. 9300 bytes per track at that rate. If I remember the process for space by blocks, the answer to the first question is seven cylinders and one cylinder.(4640/45 blocks/track/15 tracks per cylinder primary and 580/45/15 secondary). Charles Mills wrote: I care because I am trying to debug a problem at a customer site. There are about a thousand considerations that I have left out of my note - life is more complex than the average listserve question. If I had posted the entire universe of issues, it would have been a very long note. I am looking for clues so as to debug how an unexpected SB37-04 might have come about. I don't have direct to the customer machine. The customer personnel are incredibly busy. Is that sufficient justification for asking this question? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Friday, June 16, 2006 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? I'll ask Why to you care? and suggest try it and see :) -- 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: Track capacity?
A follow-up question if I may. I am trying to figure out the meaning of the sentence (in JCL Reference, under SPACE=(blklgth ...) The value specified for block size uses block length in this computation, with the exception of the value zero. I can't quite assign a meaning to that sentence. If ... - the JCL specifies SPACE=(605,(4640,580)) (with no AVGREC) - the (output) DCB is defaulted to BLKSIZE=0 and the open exit does not set BLKSIZE - the dataset is new - SMS is active on the system (but I don't think this dataset is SMS-managed) .. is there any reasonable circumstance under which MVS will NOT allocate roughly 104 tracks primary? Is the zero BLKSIZE fouling me up somehow? FWIW, the evidence is that it is running out of space after about 600 121-byte records, which SHOULD be being blocked x 26 to 3146 (but other possible errors might be resulting in unblocked records - as I said in another post, I'm working on a bug here under circumstances which limit the amount of information I have to go on). Thanks everyone for your patience. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 10:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Track capacity? Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? -- 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: Track capacity?
Thanks. The program (the subroutine in question, anyway) is in assembler. The DCB is coded without BLKSIZE= (i.e., defaults to BLKSIZE=0). The program picks up LRECL and RECFM values from a combination of DD/DSCB attributes, passed parameters used in an open exit, and values pulled from another DCB, but never touches BLKSIZE (although it could be coming from a DD or DSCB). The JCL does not specify any DCB attributes in this particular case. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Krueger Sent: Friday, June 16, 2006 1:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Charles, my response has nothing to do with track capacity, but since you mentioned an unexpected SB37-04 and previously talked about a blocksize mismatch between JCL and actual allocation ... Is the user's program, by any chance, a COBOL program? Does the JCL hardcode a blocksize value (or BLKSIZE=0), yet you still end up with an unblocked dataset? -- 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: Track capacity?
The blocksize does not have any effect until the data set is opened. The current value (perhaps specified in the JCL) will be stored in the DSCB as part of allocation but it can be overridden in the DCB or the open exit. JCL allocation occurs before your program executes. Therefore, it uses the block length value in the SPACE parameter rather than the blocksize value (which is not yet final). After the B37, the data set should be available for review. Look at the DSCB and see what really is going on (block size, lrecl, recfm, extents, etc). -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? A follow-up question if I may. I am trying to figure out the meaning of the sentence (in JCL Reference, under SPACE=(blklgth ...) The value specified for block size uses block length in this computation, with the exception of the value zero. I can't quite assign a meaning to that sentence. If ... - the JCL specifies SPACE=(605,(4640,580)) (with no AVGREC) - the (output) DCB is defaulted to BLKSIZE=0 and the open exit does not set BLKSIZE - the dataset is new - SMS is active on the system (but I don't think this dataset is SMS-managed) .. is there any reasonable circumstance under which MVS will NOT allocate roughly 104 tracks primary? Is the zero BLKSIZE fouling me up somehow? FWIW, the evidence is that it is running out of space after about 600 121-byte records, which SHOULD be being blocked x 26 to 3146 (but other possible errors might be resulting in unblocked records - as I said in another post, I'm working on a bug here under circumstances which limit the amount of information I have to go on). Thanks everyone for your patience. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 10:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Track capacity? Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? -- 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: Track capacity?
What about DATACLAS? -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 1:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Thanks. The program (the subroutine in question, anyway) is in assembler. The DCB is coded without BLKSIZE= (i.e., defaults to BLKSIZE=0). The program picks up LRECL and RECFM values from a combination of DD/DSCB attributes, passed parameters used in an open exit, and values pulled from another DCB, but never touches BLKSIZE (although it could be coming from a DD or DSCB). The JCL does not specify any DCB attributes in this particular case. -- 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: Track capacity?
In a message dated 6/16/2006 3:55:03 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: After the B37, the data set should be available for review. Look at the DSCB and see what really is going on (block size, lrecl, recfm, extents, etc). He said he does not have direct access to the computer, and the customer's personnel are incredibly busy, meaning they are too busy to run jobs for him, I assume. He could run a IMASPZAP of the first track and see how many blocks are on the track, if he could run a job, which he can't. Or he could study the B37 dump (if there was a dump) and maybe find in the I/O control blocks enough clues to infer the number of blocks per track, but in order to peruse a dump he would need direct access to the computer, which he doesn't have. The best bet is to use canned software to compute the # of blocks per track or a chart. Lynn Wheeler posted the track capacity formulae for 3375 and 3380, which are trivial compared to the 3390. I tried to use the documented formula once, but found it too convoluted to use. Use a program or a chart for 3390. Bill Fairchild -- 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: Track capacity?
DATACLAS is not coded and I confess to being less knowledgeable about SMS than I probably should be. Ah, here we go: XXSYSUT7 DD UNIT=SYSDA,SPACE=(605,(4640,580)) IGD101I SMS ALLOCATED TO DDNAME (SYSUT7 ) DSN (SYS06167.T102753.RA000.ECDX015A.R0227249) STORCLAS (SCTEMP) MGMTCLAS () DATACLAS (DCTEMP) VOL SER NOS= TEMP01 IEC030I B37-04,IFG0554A,jobname,stepname,SYSUT7,5572,TEMP01,SYS06167.T102753.RA000.j obname.R0227249 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, June 16, 2006 1:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? What about DATACLAS? -- 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: Track capacity?
So, SMS is active. Is AVGREC coded in the JCL? Dave Gibney [EMAIL PROTECTED] System Programmer(509) 335-7359 Information Technology Washington State University Pullman, WA 99164-1222 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 2:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? DATACLAS is not coded and I confess to being less knowledgeable about SMS than I probably should be. Ah, here we go: XXSYSUT7 DD UNIT=SYSDA,SPACE=(605,(4640,580)) IGD101I SMS ALLOCATED TO DDNAME (SYSUT7 ) DSN (SYS06167.T102753.RA000.ECDX015A.R0227249) STORCLAS (SCTEMP) MGMTCLAS () DATACLAS (DCTEMP) VOL SER NOS= TEMP01 IEC030I B37- 04,IFG0554A,jobname,stepname,SYSUT7,5572,TEMP01,SYS06167.T102753.RA000.j obname.R0227249 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, June 16, 2006 1:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? What about DATACLAS? -- 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: Track capacity?
Charles, Here is the answer to your original question. There is a PDF available at the following url...http://www.dtssoftware.com/Ref%20Guide9.01.pdf Steve Arnett. Charles Mills wrote: Where can I find 3390 track capacity tables or formulas? I haven't done this in so long I think the last time I did this it was for a 2314. Specifically, I am trying to figure out: - If the DD statement says SPACE=(605,(4640,580)) how many tracks will have been allocated (primary and each secondary)? - If the program actually wrote 121-byte blocks (yes, I know) how many of those would fit on a track? Thanks, Charles Mills +1-707-291-0908 -- 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: Track capacity?
No, entire DD statement is below. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Friday, June 16, 2006 2:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? So, SMS is active. Is AVGREC coded in the JCL? Dave Gibney [EMAIL PROTECTED] System Programmer(509) 335-7359 Information Technology Washington State University Pullman, WA 99164-1222 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 2:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? DATACLAS is not coded and I confess to being less knowledgeable about SMS than I probably should be. Ah, here we go: XXSYSUT7 DD UNIT=SYSDA,SPACE=(605,(4640,580)) -- 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: Track capacity?
On Fri, 16 Jun 2006 13:42:10 -0700, Charles Mills [EMAIL PROTECTED] wrote: .. is there any reasonable circumstance under which MVS will NOT allocate roughly 104 tracks primary? Is the zero BLKSIZE fouling me up somehow? Yes i guess : if you can't allocate it in less than five extents on the first volume . ( of course if you use space constraint relief what i say is not true ) Bruno -- 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: Track capacity?
I'm sorry - I should have said is there any reasonable circumstance under which the allocation will succeed but the allocation will NOT be roughly 104 tracks primary? My allocation is succeeding - the program is failing on an SB37-04. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Sugliani Sent: Friday, June 16, 2006 2:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? On Fri, 16 Jun 2006 13:42:10 -0700, Charles Mills [EMAIL PROTECTED] wrote: .. is there any reasonable circumstance under which MVS will NOT allocate roughly 104 tracks primary? Is the zero BLKSIZE fouling me up somehow? Yes i guess : if you can't allocate it in less than five extents on the first volume . ( of course if you use space constraint relief what i say is not true ) Bruno -- 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: Track capacity?
If DATACLAS is not coded then it is being added by the ACS routine. Whether it specifies a blocksize is something you will have find out from the customer. -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 2:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? DATACLAS is not coded and I confess to being less knowledgeable about SMS than I probably should be. Ah, here we go: XXSYSUT7 DD UNIT=SYSDA,SPACE=(605,(4640,580)) IGD101I SMS ALLOCATED TO DDNAME (SYSUT7 ) DSN (SYS06167.T102753.RA000.ECDX015A.R0227249) STORCLAS (SCTEMP) MGMTCLAS () DATACLAS (DCTEMP) VOL SER NOS= TEMP01 IEC030I B37-04,IFG0554A,jobname,stepname,SYSUT7,5572,TEMP01,SYS06167.T102753.RA0 00.j obname.R0227249 -- 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: Track capacity?
Sooner or later someone is going to realize that problems like this are not amenable to ouija board analysis. If they want a solution, they will have to figure out a way for someone to lay hands on the system. -Original Message- From: (IBM Mainframe Discussion List) [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 2:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? In a message dated 6/16/2006 3:55:03 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: After the B37, the data set should be available for review. Look at the DSCB and see what really is going on (block size, lrecl, recfm, extents, etc). He said he does not have direct access to the computer, and the customer's personnel are incredibly busy, meaning they are too busy to run jobs for him, I assume. He could run a IMASPZAP of the first track and see how many blocks are on the track, if he could run a job, which he can't. Or he could study the B37 dump (if there was a dump) and maybe find in the I/O control blocks enough clues to infer the number of blocks per track, but in order to peruse a dump he would need direct access to the computer, which he doesn't have. -- 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: Track capacity?
As I read the sentence in question, it says that the specified block size is a factor in the calculation *except for* block size zero, which by convention requests System Determined Blocksize. With SDB, the factor in the calculation is a number that depends on device geometry rather than what's coded, i.e. zero. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Charles Mills [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/16/2006 01:42 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Track capacity? A follow-up question if I may. I am trying to figure out the meaning of the sentence (in JCL Reference, under SPACE=(blklgth ...) The value specified for block size uses block length in this computation, with the exception of the value zero. I can't quite assign a meaning to that sentence. If ... 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
Re: Track capacity?
Maybe I'm missing something here, but what does track capacity have to do with this? This is a problem that can clearly happen well within the allocation specifications by running out of extents, not having enough volumes available, or even filling up the VTOC. Any chance you have the text of the IEC030I message that goes with this? Adam -- 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: Track capacity?
Yeah, you're missing the first few posts of the thread g. Pretty much all of that has been covered. - I have partial evidence, but the evidence I have is that only about 600 records were written. That would fill well within the specified allocation, assuming it happened as specified. - IEC030I B37-04,IFG0554A,jobname,stepname,SYSUT7,5572,TEMP01,SYS06167.T102753.RA000.j obname.R0227249 Not the most informative message, IMHO. - The original question was about track capacity because I was trying to figure out how many records would fit in the specified allocation. I moved on to did the allocation happen the way I think it did? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Adam Sent: Friday, June 16, 2006 4:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Maybe I'm missing something here, but what does track capacity have to do with this? This is a problem that can clearly happen well within the allocation specifications by running out of extents, not having enough volumes available, or even filling up the VTOC. Any chance you have the text of the IEC030I message that goes with this? -- 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: Track capacity?
DATACLAS would potentially supply a BLKSIZE for the DCB, but would ***NOT*** override the blklgth of 605 coded in SPACE=, is that correct? No matter what DATACLAS said, I'd still get the 104 tracks primary implied by the SPACE= parameter (barring an allocation failure), is that correct? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Friday, June 16, 2006 3:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? If DATACLAS is not coded then it is being added by the ACS routine. Whether it specifies a blocksize is something you will have find out from the customer. -Original Message- From: Charles Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 2:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? DATACLAS is not coded and I confess to being less knowledgeable about SMS than I probably should be. Ah, here we go: XXSYSUT7 DD UNIT=SYSDA,SPACE=(605,(4640,580)) -- 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: Track capacity?
Is there an LRECL=nnn? That parameter in SPACE is considered a block without AVGREC. It is only related to LRECL or BLKSIZE by programmer coincidence. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Friday, June 16, 2006 4:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Track capacity? Yeah, you're missing the first few posts of the thread g. Pretty much all of that has been covered. - I have partial evidence, but the evidence I have is that only about 600 records were written. That would fill well within the specified allocation, assuming it happened as specified. - IEC030I B37-04,IFG0554A,jobname,stepname,SYSUT7,5572,TEMP01,SYS06167.T 102753.RA000.j obname.R0227249 Not the most informative message, IMHO. - The original question was about track capacity because I was trying to figure out how many records would fit in the specified allocation. I moved on to did the allocation happen the way I think it did? Charles -- 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
