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 . . . : STANDARD Allocated 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 0000025237, 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
