Re: Space Allocation In Bytes
In 503d2b0b.6010...@neo.tamu.edu, on 08/28/2012 at 03:33 PM, Richard Peurifoy r-peuri...@neo.tamu.edu said: I think BSAM/QSAM will simulate an EOF without doing any I/O to the data set if you try to read it. I'd prefer an ABEND. Note that if you first write to it first then [B|Q]SAM will allocate an extent in EOV processing. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 503cfd09.1010...@bremultibank.com.pl, on 08/28/2012 at 07:16 PM, R.S. r.skoru...@bremultibank.com.pl said: BTW: it's NOT similar to /dev/null or DD DUMMY. Of course it is. Zero-space dataset is real object, consuming real resources (VTOC, maybe catalog) with no real (as intended) use. /dev/null and DUMMY are also real objects consuming real resources (space in /dev, TIOT emtry, JFCB, etc.) They all have real use. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 1384193780234110.wa.paulgboulderaim@listserv.ua.edu, on 08/28/2012 at 06:26 PM, Paul Gilmartin paulgboul...@aim.com said: I believe this is the behavior of QSAM. BSAM at least in the past behaved otherwise; cheerfully reading residual, likely invalid, data. For a zero-extent dataset there are no residual data to read. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Peter, I works fine if working in ISPF. But when the question of line command is requested, I am thinking along the lines of a simple interface that could be used batch or foreground. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hunkeler Peter (KIUP 4) Sent: Monday, August 27, 2012 10:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes I'm trying for an example. But what command can I use to list SPACE? Neither LISTDS nor LISTCAT seems to do it for me. (But do I just not know the correct options? Something under IDCAMS?) Am I a fool in believing ISPF's data set list I line command? It shows me allocated tracks and allocated extents. If this is non-zero, then the data set *is* using up space on dasd. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Radoslaw, Infrequent but not illogical. I've used it for datasets that are only opened and written to on a weekly or monthly basis. The secondary extents are allocated and used when anything is written. You will also find empty datasets with space released to zero tracks. This is one of the effects of having a HWM written to an empty dataset. If it is logical at space release, why wouldn't it be logical at allocation? It's net same result. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, August 27, 2012 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Space Allocation In Bytes W dniu 2012-08-25 17:49, Skip Robinson pisze: Zero space allocation is perfectly valid. Valid, but illogical. Data set with zero size is illogical. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526- 021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
I've never been in a shop which did, except when it was necessary. Such as when generating a new GDG entry, back !many! years ago. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Monday, August 27, 2012 9:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On :: Behalf Of R.S. :: Sent: Monday, August 27, 2012 3:34 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Space Allocation In Bytes :: :: W dniu 2012-08-25 17:49, Skip Robinson pisze: :: Zero space allocation is perfectly valid. :: :: Valid, but illogical. Data set with zero size is illogical. Doesn't anyone use model DSCBs anymore? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
We use it for datasets allocated to SYSUDUMP etc. It allocates 0 tracks until the moment a dump has to be written, if any. Kees. Ron Hawkins ronjhawk...@sbcglobal.net wrote in message news:002a01cd8505$42ce00e0$c86a02a0$@sbcglobal.net... Radoslaw, Infrequent but not illogical. I've used it for datasets that are only opened and written to on a weekly or monthly basis. The secondary extents are allocated and used when anything is written. You will also find empty datasets with space released to zero tracks. This is one of the effects of having a HWM written to an empty dataset. If it is logical at space release, why wouldn't it be logical at allocation? It's net same result. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, August 27, 2012 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Space Allocation In Bytes W dniu 2012-08-25 17:49, Skip Robinson pisze: Zero space allocation is perfectly valid. Valid, but illogical. Data set with zero size is illogical. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526- 021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
Re: Space Allocation In Bytes
In 503bf5eb.5010...@bremultibank.com.pl, on 08/28/2012 at 12:34 AM, R.S. r.skoru...@bremultibank.com.pl said: Valid, but illogical. Data set with zero size is illogical. No. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. It's perfectly logical, as are /dev/null and DUMMY. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 2147353307588112.wa.paulgboulderaim@listserv.ua.edu, on 08/27/2012 at 06:43 PM, Paul Gilmartin paulgboul...@aim.com said: But its length attribute is nonzero. In fact, IIRC, HLASM will never create a symbol with length attribute of zero; Don't confuse symbol with SET symbol. The assembler assigns the character string value represented in the operand field to the SETC symbol in the name field. The string length must be in the range 0 (null character string) through 1024 characters. I believe (without trying it again) that ANSWER EQU 42,0 results in an assembler error. Yes, but that's not ANSWER SETC '' -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Tue, 28 Aug 2012 00:45:25 -0700, Lizette Koehler wrote: Peter, I works fine if working in ISPF. But when the question of line command is requested, I am thinking along the lines of a simple interface that could be used batch or foreground. Thanks for your understanding. Simply, there are too many disjoint ways of retrieving not enough information about a data set. These include HLIST, LISTDS, LISTCAT, BPXWDYN(INFO), Rexx LISTDSI, ISPF DSLIST, ISPF DDLIST, ... probably many others. There should be a single simple interface to retrieve any of the information supplied by any of the above. It should be accessible with: o JCL EXEC PGM= o TSO CALL o Assembler CALL o Rexx address LINKMVS (the above interfaces are all very similar.) o Other Rexx interfaces. It should be able to direct its output to: o TSO terminal. o DDNAME if OUTDD() specified o Rexx compound variable if STEM() specified. o Reply buffer supplied by assembler CALL or Rexx LINKMVS. It should accept as argument: o Catalogued data set name - even with the extended syntax allowed by DISABLE(DSNCHECK) o Uncatalogued data set name if UNIT and VOL are specified - again even with nonstandard name syntax o DDNAME, which may refer to: - catalogued data set - uncatalogued data set - temporary DSN - VIO data set - UNIT and VOL with no DSN coded - UNIX path (have I missed any?) With DDNAME specified it should (be able to) return attributes which will be used in the DCB merge at OPEN, not necessarily those in the DSCB. DDNAME should be allowed to be any 8-character string that could have been allocated by SVC 99; not restricted to JCL syntax (the latter could be retrieved if desired by issuing a second call with DSN, UNIT, and VOL supplied by a previous call). The values returned should be sufficient to allow reallocation of the same entity to a different DDNAME with TSO ALLOCATE or BPXWDYN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 2627995591725082.wa.paulgboulderaim@listserv.ua.edu, on 08/27/2012 at 07:09 PM, Paul Gilmartin paulgboul...@aim.com said: ... so SPACE=(0,1) does allocate space. What's in your ACS? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Ed Gould :: Sent: Monday, August 27, 2012 10:31 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Space Allocation In Bytes :: :: LiZette: :: :: I think you can get a freeware product called IEHLIST w/cc ::LISTVTOC vol=3380=volser,format (or dump) IBM does make some freeware available on their website (such as DBSYNC from the RACF goodies page) but I doubt any of it comes with a 400 page formal SCxx manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
W dniu 2012-08-28 17:59, Roger W. Suhr pisze: No, it's not illogical. We use Format 1 DSCB entries as model DSCB for GDG's and other things. No data space use is needed for that, so we allocate TRK=0. No problem there! Well, it depends on the point of view. Datasets by definition are for keeping data, not to make GRS ENQ, not to be DSCB model (BTW: haven't heard anyone about SMS? DATACLASS or even LIKE?). Zero-space dataset is like PDS with zero directory. Possible to create, but not usable as intended. BTW: it's NOT similar to /dev/null or DD DUMMY. Zero-space dataset is real object, consuming real resources (VTOC, maybe catalog) with no real (as intended) use. Of course, as I already said, it's perfectly possible, legal and IBM supported to use such datasets for the purposes as above or maybe others as well. BTW2: Another parallel comes to my mind: IEFBR14. Usually we expect the program to do something. ;-) Usually we expect dataset to contain some data... -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Attempting to distinguish empty files from nul strings and the like Ron Skorupka writes: begin extract Zero-space dataset is real object, consuming real resources (VTOC, maybe catalog) with no real (as intended) use. end extract/ but nul strings also consume resources in just this way. The PL/I varying character string nada of declare nada character varying(0) ; is comprised of a halfword prefix having the value 0. Or again, its C analogue is comprised of a single eos-delimiter byte, x'00'. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
I made 'Radoslaw' into 'Ron', for which I apologize. --jg On 8/28/12, John Gilmore jwgli...@gmail.com wrote: Attempting to distinguish empty files from nul strings and the like Ron Skorupka writes: begin extract Zero-space dataset is real object, consuming real resources (VTOC, maybe catalog) with no real (as intended) use. end extract/ but nul strings also consume resources in just this way. The PL/I varying character string nada of declare nada character varying(0) ; is comprised of a halfword prefix having the value 0. Or again, its C analogue is comprised of a single eos-delimiter byte, x'00'. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
We still have some too. Linda Sent from my iPhone On Aug 27, 2012, at 8:17 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Aug 27, 2012 at 9:02 PM, retired mainframer retired-mainfra...@q.com wrote: Doesn't anyone use model DSCBs anymore? We still have some hanging around. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On 8/28/2012 3:19 PM, glen herrmannsfeldt wrote: Shmuel Metz , Seymour J. shmuel+...@patriot.net wrote: In 503bf5eb.5010...@bremultibank.com.pl, on 08/28/2012 at 12:34 AM, R.S. r.skoru...@bremultibank.com.pl said: Valid, but illogical. Data set with zero size is illogical. No. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. It's perfectly logical, as are /dev/null and DUMMY. But for CKD doesn't there have to be some place to write the EOF? I think BSAM/QSAM will simulate an EOF without doing any I/O to the data set if you try to read it. -- RIchard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
My 'interested colleague' Meral Temel supplied a crucial piece of the puzzle. She filled up a volume totally with ordinary data sets to where external indicators showed zero tracks of free space. She then allocated a zero-space data set on the volume with no error. There could not have been a spot for any fragment of the data set to be written outside the VTOC. I know that ISPF Browse will show 'no data' if it judges from the VTOC that utilization is zero, as in 3.2, regardless of what might be there physically. OTOH IEBGENER attempts read a file until EOF regardless of VTOC info. I ran GENER to print a zero-space data set:. The result is the same as if the only data on the first track were EOF. DATA SET UTILITY - GENERATE PROCESSING ENDED AT EOD . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Richard Peurifoy r-peuri...@neo.tamu.edu To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/28/2012 01:33 PM Subject:Re: Space Allocation In Bytes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On 8/28/2012 3:19 PM, glen herrmannsfeldt wrote: Shmuel Metz , Seymour J. shmuel+...@patriot.net wrote: In 503bf5eb.5010...@bremultibank.com.pl, on 08/28/2012 at 12:34 AM, R.S. r.skoru...@bremultibank.com.pl said: Valid, but illogical. Data set with zero size is illogical. No. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. It's perfectly logical, as are /dev/null and DUMMY. But for CKD doesn't there have to be some place to write the EOF? I think BSAM/QSAM will simulate an EOF without doing any I/O to the data set if you try to read it. -- RIchard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Tue, 28 Aug 2012 15:33:15 -0500, Richard Peurifoy wrote: But for CKD doesn't there have to be some place to write the EOF? I think BSAM/QSAM will simulate an EOF without doing any I/O to the data set if you try to read it. Yup. As I said here lately, I've depended on that behavior in the past. And I believe that if the primary extent is exactly filled, the OS will not allocate a secondary merely to write that EOF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Tue, 28 Aug 2012 14:45:42 -0700, Skip Robinson wrote: I know that ISPF Browse will show 'no data' if it judges from the VTOC that utilization is zero, as in 3.2, regardless of what might be there physically. OTOH IEBGENER attempts read a file until EOF regardless of VTOC info. I ran GENER to print a zero-space data set:. The result is the same as if the only data on the first track were EOF. I believe this is the behavior of QSAM. BSAM at least in the past behaved otherwise; cheerfully reading residual, likely invalid, data. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
:: Well, it depends on the point of view. :: Datasets by definition are for keeping data, not to make GRS ENQ, not Everything depends on the point of view! Roger -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Tuesday, August 28, 2012 5:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Tuesday, August 28, 2012 10:17 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Space Allocation In Bytes :: :: W dniu 2012-08-28 17:59, Roger W. Suhr pisze: :: No, it's not illogical. We use Format 1 DSCB entries as model DSCB :: for :: GDG's and other things. No data space use is needed for that, so we :: allocate TRK=0. No problem there! :: :: Well, it depends on the point of view. :: Datasets by definition are for keeping data, not to make GRS ENQ, not :: to be DSCB model (BTW: haven't heard anyone about SMS? DATACLASS or even :: LIKE?). Zero-space dataset is like PDS with zero directory. Possible to :: create, but not usable as intended. Do you extend this narrow definition of intention to include a PDS where all the data is kept in the directory and the members are all empty? This technique has probably been around as long as model DSCBs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
You can also OPEN a DCB to a data set allocated with zero space and with a system-created temporary data set name. Not necessarily all types of DCBs, but I have done this in order to have a complete EXCP control block structure created (DEB, etc.) that I later manipulated for use with EXCP. Yes, this was in an APF authorized program. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Saturday, August 25, 2012 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes Zero space allocation is perfectly valid. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/25/2012 08:27 AM Subject:Re: Space Allocation In Bytes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Wed, 8 Aug 2012 14:06:04 +0200, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) As in: DD LRECL=80,SPACE=(1,...),... Seveal contributors argued that there was no way a 1-byte block could be written if LRECL=80, and the construct should result in an error. The JCL RM says: blklgth -- (only if AVGREC is not coded) Specifies the average block length of the data, in bytes. The blklgth is a decimal number from 0 through 65535. Really!? In fact by experiment, in JCL: DD SPACE=(0,1),... and in TSO ALLOCATE AVBLOCK(0) ... are both accepted without complaint. I suppose allocation adds a count and an IBG; divides track size by that; takes the ceiling and requests the resulting number of tracks (almost certainly 1). I have little problem with that. I haven't investigated whether SPACE=(0,9) allocates fewer tracks than SPACE=(1,9). It's possible that integer arithmetic or 32-byte chunking gives the same result for both. Perhaps I'll start coding SPACE=(0,1) in JCL to allocate minimal data sets, just to startle readers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
I'm curious about the experiment that shows something on disk. ZAP command says 'DATA SET UNAVAILABLE OR NON-EXISTENT'. IEHLIST says 'THE ABOVE DATASET HAS NO EXTENTS'. What view of the disk shows something on a data track? . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/25/2012 09:50 AM Subject:Re: Space Allocation In Bytes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Sat, 25 Aug 2012 08:49:49 -0700, Skip Robinson wrote: Zero space allocation is perfectly valid. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. Ummm... no. By experiment, it allocates one track. There has to be room for the count field. And SPACE=(65535,1) allocates two tracks. This surprises me. Does 3390 support blocks spanning tracks? Also surprisingly, SPACE=(0,9) allocates 8,334 tracks; SPACE=(1,9) allocates 1,163 tracks. Did I do something wrong? Did someone divide by zero? The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. The data set's being 'real' has little to do with GRS enque. I can code: //GRS EXEC PGM=WOMBAT,COND=(0,LE) //SERIALDD DISP=OLD,DSN=NONE.SUCH The data set needn't exist; the step isn't executed; yet I believe an exclusive ENQ is issued for its name which could be used to serialize execution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Mon, 27 Aug 2012 13:36:58 -0700, Skip Robinson wrote: I'm curious about the experiment that shows something on disk. ZAP command says 'DATA SET UNAVAILABLE OR NON-EXISTENT'. IEHLIST says 'THE ABOVE DATASET HAS NO EXTENTS'. What view of the disk shows something on a data track? I'm trying for an example. But what command can I use to list SPACE? Neither LISTDS nor LISTCAT seems to do it for me. (But do I just not know the correct options? Something under IDCAMS?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Gil, What kind of space are you looking for? LISTC name ALL will provide space info on VSAM but not NON VSAM If you want space on NON VSAM then I think the PDS utility on the CBTTAPE.ORG would work. Or create a REXX and use the LM functions to list the space or LISTDSI. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 27, 2012 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes On Mon, 27 Aug 2012 13:36:58 -0700, Skip Robinson wrote: I'm curious about the experiment that shows something on disk. ZAP command says 'DATA SET UNAVAILABLE OR NON-EXISTENT'. IEHLIST says 'THE ABOVE DATASET HAS NO EXTENTS'. What view of the disk shows something on a data track? I'm trying for an example. But what command can I use to list SPACE? Neither LISTDS nor LISTCAT seems to do it for me. (But do I just not know the correct options? Something under IDCAMS?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
It was pointed out earlier that creating a 'dummy enqueue' for serialization can be accomplished without actually specifying a data set name at all. I haven't tried that but won't contest it--as long as serialization is required only in a single task. But there is one very 'logical' place for a similar strategy. Some ancient and venerable MVS utilities require, for certain functions, that a *volume* be allocated separately from the function itself. In batch, one can code something like this: //MYVOL DD DISP=OLD,VOL=SER=xx That does not work in TSO. The command 'alloc dd(myvol) old vol(xx)' gets the prompt 'IKJ56700A ENTER DATA SET NAME -'. I have used a zero-space data set (NEW) for this purpose. It works quite well. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/27/2012 03:35 PM Subject:Re: Space Allocation In Bytes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU W dniu 2012-08-25 17:49, Skip Robinson pisze: Zero space allocation is perfectly valid. Valid, but illogical. Data set with zero size is illogical. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. That's exploitation of side effect. Stilla valid (it works, so it is valid), but it's still illogical. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Mon, 27 Aug 2012 16:26:40 -0700, Lizette Koehler wrote: What kind of space are you looking for? LISTC name ALL will provide space info on VSAM but not NON VSAM It's NONVSAM. If you want space on NON VSAM then I think the PDS utility on the CBTTAPE.ORG would work. So I have to go out and get a nonstandard utility ... Or create a REXX and use the LM functions to list the space or LISTDSI. ... or go through IKJEFT01; ISPSTART; LM*; ... Of course, I can do this easily with foreground ISPF; DSLIST; Info. But I had set myself the goal of doing it all in a _simple_ (self-contained) batch job so I could post here a refutation to the doubter. Why does MVS make simple things so damned hard!? OK. Here's the hybrid solution; batch JCL: // //EMPTY JOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* //STEP EXEC PGM=IEFBR14 //SYSUT0DD DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(0,1), // DSN=SYSUID..TEMP.ALMOST.EMPTY //SYSUT2DD DISP=(,CATLG),UNIT=SYSALLDA,SPACE=(0,1), // DSN=SYSUID..TEMP.ALMOST.EMPTY // (de)allocation messages: IEF142I EMPTY STEP - STEP WAS EXECUTED - COND CODE IEF285I user.TEMP.ALMOST.EMPTY UNCATALOGED IEF285I VOL SER NOS= TSO022. IEF285I user.TEMP.ALMOST.EMPTY DELETED IEF285I VOL SER NOS= TSO022. IEF285I user.TEMP.ALMOST.EMPTY CATALOGED IEF285I VOL SER NOS= TSO005. and data set info: Data Set Information Data Set Name . . . . : user.TEMP.ALMOST.EMPTY General Data Current Allocation Management class . . : **None**Allocated tracks . : 1 Storage class . . . : **None**Allocated extents . : 1 Volume serial . . . : TSO005 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : NONE Current Utilization Record format . . . : ? Used tracks . . . . : 0 Record length . . . : 0 Used extents . . . : 0 Block size . . . . : 0 1st extent tracks . : 1 ... so SPACE=(0,1) does allocate space. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
I was careful to use the value-byte-count attribute k'whatever' The HLASM 'length' attribute, L'something, should have a different name and a different attribute indicator. What it yields in non-trivial cases is not at all what novices expect it to yield, Regrettably, it is 10+ lustra too late to do anything about this. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Paul Gilmartin :: Sent: Monday, August 27, 2012 5:09 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Space Allocation In Bytes :: :: On Mon, 27 Aug 2012 16:26:40 -0700, Lizette Koehler wrote: :: :: What kind of space are you looking for? :: :: LISTC name ALL will provide space info on VSAM but not NON VSAM :: :: It's NONVSAM. :: :: If you want space on NON VSAM then I think the PDS utility on the :: CBTTAPE.ORG would work. :: :: So I have to go out and get a nonstandard utility ... Or you could go to the DFP Utilities manual and use IEHLIST. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of R.S. :: Sent: Monday, August 27, 2012 3:34 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Space Allocation In Bytes :: :: W dniu 2012-08-25 17:49, Skip Robinson pisze: :: Zero space allocation is perfectly valid. :: :: Valid, but illogical. Data set with zero size is illogical. Doesn't anyone use model DSCBs anymore? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Mon, Aug 27, 2012 at 9:02 PM, retired mainframer retired-mainfra...@q.com wrote: Doesn't anyone use model DSCBs anymore? We still have some hanging around. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
LiZette: I think you can get a freeware product called IEHLIST w/cc LISTVTOC vol=3380=volser,format (or dump) ED On Aug 27, 2012, at 6:26 PM, Lizette Koehler wrote: Gil, What kind of space are you looking for? LISTC name ALL will provide space info on VSAM but not NON VSAM If you want space on NON VSAM then I think the PDS utility on the CBTTAPE.ORG would work. Or create a REXX and use the LM functions to list the space or LISTDSI. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, August 27, 2012 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Allocation In Bytes On Mon, 27 Aug 2012 13:36:58 -0700, Skip Robinson wrote: I'm curious about the experiment that shows something on disk. ZAP command says 'DATA SET UNAVAILABLE OR NON-EXISTENT'. IEHLIST says 'THE ABOVE DATASET HAS NO EXTENTS'. What view of the disk shows something on a data track? I'm trying for an example. But what command can I use to list SPACE? Neither LISTDS nor LISTCAT seems to do it for me. (But do I just not know the correct options? Something under IDCAMS?) Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Wed, 8 Aug 2012 14:06:04 +0200, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) As in: DD LRECL=80,SPACE=(1,...),... Seveal contributors argued that there was no way a 1-byte block could be written if LRECL=80, and the construct should result in an error. The JCL RM says: blklgth -- (only if AVGREC is not coded) Specifies the average block length of the data, in bytes. The blklgth is a decimal number from 0 through 65535. Really!? In fact by experiment, in JCL: DD SPACE=(0,1),... and in TSO ALLOCATE AVBLOCK(0) ... are both accepted without complaint. I suppose allocation adds a count and an IBG; divides track size by that; takes the ceiling and requests the resulting number of tracks (almost certainly 1). I have little problem with that. I haven't investigated whether SPACE=(0,9) allocates fewer tracks than SPACE=(1,9). It's possible that integer arithmetic or 32-byte chunking gives the same result for both. Perhaps I'll start coding SPACE=(0,1) in JCL to allocate minimal data sets, just to startle readers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Zero space allocation is perfectly valid. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/25/2012 08:27 AM Subject:Re: Space Allocation In Bytes Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Wed, 8 Aug 2012 14:06:04 +0200, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) As in: DD LRECL=80,SPACE=(1,...),... Seveal contributors argued that there was no way a 1-byte block could be written if LRECL=80, and the construct should result in an error. The JCL RM says: blklgth -- (only if AVGREC is not coded) Specifies the average block length of the data, in bytes. The blklgth is a decimal number from 0 through 65535. Really!? In fact by experiment, in JCL: DD SPACE=(0,1),... and in TSO ALLOCATE AVBLOCK(0) ... are both accepted without complaint. I suppose allocation adds a count and an IBG; divides track size by that; takes the ceiling and requests the resulting number of tracks (almost certainly 1). I have little problem with that. I haven't investigated whether SPACE=(0,9) allocates fewer tracks than SPACE=(1,9). It's possible that integer arithmetic or 32-byte chunking gives the same result for both. Perhaps I'll start coding SPACE=(0,1) in JCL to allocate minimal data sets, just to startle readers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Sat, 25 Aug 2012 08:49:49 -0700, Skip Robinson wrote: Zero space allocation is perfectly valid. As is SPACE (0,1) also. The result is just as requested. In either case, the data set exists in the VTOC but takes up no space on disk. Ummm... no. By experiment, it allocates one track. There has to be room for the count field. And SPACE=(65535,1) allocates two tracks. This surprises me. Does 3390 support blocks spanning tracks? Also surprisingly, SPACE=(0,9) allocates 8,334 tracks; SPACE=(1,9) allocates 1,163 tracks. Did I do something wrong? Did someone divide by zero? The data set is treated as 'real', including GRS enqueue. Hence it can be used like any other exclusively held data set to serialize execution. The data set's being 'real' has little to do with GRS enque. I can code: //GRS EXEC PGM=WOMBAT,COND=(0,LE) //SERIALDD DISP=OLD,DSN=NONE.SUCH The data set needn't exist; the step isn't executed; yet I believe an exclusive ENQ is issued for its name which could be used to serialize execution. From: Paul Gilmartin Date: 08/25/2012 08:27 AM The JCL RM says: blklgth -- (only if AVGREC is not coded) Specifies the average block length of the data, in bytes. The blklgth is a decimal number from 0 through 65535. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Space Allocation In Bytes
Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
Jake, Minimum allocation for a file on DASD is one track. Richard -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: 08 August 2012 01:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Space Allocation In Bytes Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
W dniu 2012-08-08 13:40, Jake anderson pisze: Hi, I am probably asking a very simple Question but I am unable to interpret Properly. I tried allocating a PS file with space Unit=Bytes, Primary as 1,RECFM=FB,LRECL=80, but when I view the Dataset Information shows the primary Extent is occupied with *55840 bytes* : General Data Current Allocation Management class . . : **None**Allocated bytes . . : 55,840 Storage class . . . : STANDARDAllocated extents . : 1 Volume serial . . . : MTWK06 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : FB Used bytes . . . . : 0 Record length . . . : 80 Used extents . . . : 0 Block size . . . . : 27920 1st extent bytes . : *55840* Secondary bytes . . : 0 Dates Data set name type : Creation date . . . : 2012/08/08 SMS Compressible. . : NO Referenced date . . : ***None*** Expiration date . . : ***None*** Could anyone please enlighten me how does the Primary Value gets generated as 55840 bytes ? Does it mean it is treating the Primary extent as 2 Blocks on a Track which would be 55,840 bytes ? 1. Assuming we are NOT talking about EAV, allocation is being done in whole tracks. So, you can specify bytes, kilobytes, records, but the smallest physical chunk of disk space is always track. In your case you requested very small amount of space, so you got single track minus some technical areas. BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) 2. Track is 56664 bytes BRUTTO. There are gaps, HA, R0, which causes your track is not 100% utilized. In any case it won't be 100% utilized. System determined blocksize (SDB) for FB 80 is 29720, two blocks on the track. So, for space 1 byte, 1 track or 1000 tracks, you will have two blocks per track, 2x29720. Caution: last block can be shorter, but just after dataset is created, there are not data inside. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Aug 8, 2012, at 06:06, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) I believe the block specification is an average. As such, it's not required to be a multiple of LRECL. If half the blocks are 80 bytes and half are 160, an average of 120 is possible. Granted, 1 can never occur, not even as an average. I suppose allocation simply calculates the tracks necessary to hold the requested number of 1-byte blocks plus gaps. It might be a courtesy for allocation to issue a warning, but how much validity checking should it be expected to perform? What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
W dniu 2012-08-08 16:00, Paul Gilmartin pisze: On Aug 8, 2012, at 06:06, R.S. wrote: BTW: your allocation request was illogical - you wanted to have 80-byte records and requested 1 byte. Such request has to be re-interpreted or canceled. ;-) I believe the block specification is an average. As such, it's not required to be a multiple of LRECL. If half the blocks are 80 bytes and half are 160, an average of 120 is possible. Granted, 1 can never occur, not even as an average. I suppose allocation simply calculates the tracks necessary to hold the requested number of 1-byte blocks plus gaps. It might be a courtesy for allocation to issue a warning, but how much validity checking should it be expected to perform? What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? In this case there is nothing to consider: 1 byte of disk space cannot hold any 80-byte record. It's not issue of AVG or even blocksize as multiplication of record size. Again: we talt about PRIMARY ALLOCATION OF ONE BYTE. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. On Wed, Aug 8, 2012 at 9:00 AM, Paul Gilmartin paulgboul...@aim.com wrote: deleted What about RECFM=VB? What's the smallest valid block? 9? 8? 4? (That would be a BDW with no records.) Does Using Data Sets allow this? I bet I could write one with BSAM; I wonder how QSAM would handle reading it? -- gil -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Aug 8, 2012, at 09:11, Mike Schwab wrote: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. ??? No. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d490/3.1.3.1.2 Title: z/OS V1R12 DFSMS Using Data Sets Document Number: SC26-7410-10 3.1.3.1.2 Record Descriptor Word (RDW) A variable-length logical record consists of a record descriptor word (RDW) followed by the data. The record descriptor word is a 4 byte field describing the record. The first 2 bytes contain the length (LL) of the logical record (including the 4 byte RDW). The length can be from 4 to 32 760. All bits of the third and fourth bytes must be 0, because other values are used for spanned records. A length of 4 implies zero bytes of data; no blank. It's easy to create such records with EXECIO, FTP, or vi. I do not find a stated minimum for the BDW. Absent firm information, I'll assume 4-byte blocks (nothing but BDW) are permissible. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. I had no such problem: Data Set Information More: + Data Set Name . . . . : user.SHORT.BLOCKS General Data Current Allocation Management class . . : **None**Allocated blocks . : 86 Storage class . . . : **None**Allocated extents . : 1 Volume serial . . . : TSO005 Device type . . . . : 3390 Data class . . . . . : **None** Organization . . . : PS Current Utilization Record format . . . : F Used blocks . . . . : 3 Record length . . . : 6 Used extents . . . : 1 Block size . . . . : 6 Command === F1=HelpF3=Exit F12=Cancel . . . . . . . . . . . . . . . . . . . . . . . . . . . File Edit Edit_Settings Menu Utilities Compilers Test Help ——— VIEW user.SHORT.BLOCKS Columns 1 6 ** * Top of Data ** =PROF BLOCKS (FIXED - 6)RECOVERY OFF WARNNUMBER OFF... 01 these 02 are 03 recrds ** Bottom of Data -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
W dniu 2012-08-08 17:11, Mike Schwab pisze: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. Do you mean LRECL=6? It does work. Even RECFM=FB,LRECL=1 does work. However I've never tried shorter records ;-))) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In 0fdb46cc-7d2e-4887-9f5c-fc29d9c2b...@aim.com, on 08/08/2012 at 09:45 AM, Paul Gilmartin paulgboul...@aim.com said: I do not find a stated minimum for the BDW. Absent firm information, I'll assume 4-byte blocks (nothing but BDW) are permissible. No, the minimum ios 8; see 3.2.3.1 Block Size (BLKSIZE) Minimum block size: If you specify a block size other than zero, there is no minimum requirement for block size except that format-V blocks have a minimum block size of 8. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In CAJTOO58735VUTbFZ-GL2hvGg5=p=zoaf0271gsclbqt0y4j...@mail.gmail.com, on 08/08/2012 at 10:11 AM, Mike Schwab mike.a.sch...@gmail.com said: A zero byte VB record is expanded to 1 blank x'40' so the minimum is a block of 9 bytes including block size and record size field. Are you sure didn't specify A or M? From z/OS DFSMS Using Data Sets, SC26-7410-09: 3.2.3.1 Block Size (BLKSIZE) Minimum block size: If you specify a block size other than zero, there is no minimum requirement for block size except that format-V blocks have a minimum block size of 8. Note also: 3.1.3.1.2 Record Descriptor Word (RDW) A variable-length logical record consists of a record descriptor word (RDW) followed by the data. The record descriptor word is a 4 byte field describing the record. The first 2 bytes contain the length (LL) of the logical record (including the 4 byte RDW). The length can be from 4 to 32 760. 3.1.6.3 Using Magnetic Tape ... When you create a tape data set with variable-length record format-V or format-D, the control program pads any data block shorter than 18 bytes. For format-V records, it pads to the right with binary zeros so that the data block length equals 18 bytes. For format-D (ASCII) records, the padding consists of ASCII circumflex characters, which are equivalent to X'5E's. I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. What happened when you tried? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
On Wed, Aug 8, 2012 at 1:43 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In CAJTOO58735VUTbFZ-GL2hvGg5=p=zoaf0271gsclbqt0y4j...@mail.gmail.com, on 08/08/2012 at 10:11 AM, Mike Schwab mike.a.sch...@gmail.com said: deleted I tried to allocate a FB 6 0 to hold a list of volsers for a table, LRL under 10 would not work. What happened when you tried? On TSO ISPF 3.2, it failed with record length too short so I kept adding 1 to the LRECL until 10 worked. This was about 9 years ago. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Allocation In Bytes
In CAJTOO5-_jCQt3_wepucjBcEqhu7sNFbv7TcE=4vabeyj5mv...@mail.gmail.com, on 08/08/2012 at 02:15 PM, Mike Schwab mike.a.sch...@gmail.com said: On TSO ISPF 3.2, it failed with record length too short so I kept adding 1 to the LRECL until 10 worked. This was about 9 years ago. Well, ISPF has its own rules, but I'd try to APAR it if it still does that. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
