Re: z/OS BDAM question
On 11/07/2018 12:06 AM, Paul Gilmartin wrote: > On 2018-11-06, at 22:20:07, Joel C. Ewing wrote: > >> If you search on-line for Unicode characters, their code point values >> are usually given using the "U+" notation, where is in hex, so >> IBM is just following standard usage. >> > My curiosity was more about whether and where it's conventional > to separate digit groups with that U+2420 SYMBOL FOR SPACE glyph. > It seems needlessly recherché. > On 2018-11-02, at 05:39:38, R.S. wrote: >... > ... 16␠777␠215 tracks ... > -- gil > I now understand the current recommended practice in international contexts is to avoid use of comma or period as numeric thousands separators because of conflicting conventions in different countries, with a "thin blank" U+2009 being the preferred alternative. My guess is the author of the IBM manual intended to follow that practice, but was using an editor that allowed or encouraged an erroneous choice for the blank code point, resulting in one with a visible-blank glyph. With my normal email viewing font and reading glasses, I could barely see anything for the less dense "SP" glyph -- I interpreted it as merely dirt specks on my display screen until I later resorted to extreme zoom-in. I suspect whoever composed and proofread the original manual was similarly challenged and never realized a visible glyph had been used for the blank. Joel C. Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
On 2018-11-06, at 22:20:07, Joel C. Ewing wrote: > If you search on-line for Unicode characters, their code point values > are usually given using the "U+" notation, where is in hex, so > IBM is just following standard usage. > My curiosity was more about whether and where it's conventional to separate digit groups with that U+2420 SYMBOL FOR SPACE glyph. It seems needlessly recherché. >>> On 2018-11-02, at 05:39:38, R.S. wrote: ... ... 16␠777␠215 tracks ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
If you search on-line for Unicode characters, their code point values are usually given using the "U+" notation, where is in hex, so IBM is just following standard usage. Also this notation is only weird if one is not familiar with current Linux desktop systems -- this not that far from how an arbitrary Unicode character is directly entered into an application on Fedora Linux: CTRL+SHIFT+u followed by the Unicode hex code-point value followed by a space. and the above sequence could be logically abbreviated like CTRL+U2422␣ which enters the single Unicode character ␢(with no trailing space) I assume the Unicode notation convention came first, and Linux just chose to support Unicode input using a convention that closely approximates that Unicode notation. One would hope any IBM manual(s) using the "U+..." notation might explain it somewhere for the benefit of those not that familiar with Unicode notations. Joel C. Ewing On 11/02/2018 10:49 AM, Mick Graley wrote: > Nah - it's actually how they are on the IBM manual page - weird. > > > On Fri, 2 Nov 2018 at 15:38, Paul Gilmartin < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On 2018-11-02, at 05:39:38, R.S. wrote: >>> ... >>> Content-Transfer-Encoding: 8bit >>> Content-Type: text/plain; charset="utf-8"; format=flowed >>> >>> ... 16␠777␠215 tracks ... >>> >> I had to look it up: >> The following table lists some symbols, in decreasing order by >> practical usefulness. >> Their shapes vary by font; especially the last one varies a lot. >> ␣ U+2423 OPEN BOX >> ␢ U+2422 BLANK SYMBOL >> ␠ U+2420 SYMBOL FOR SPACE >> >> Eek! Do they always write numbers that way in Poland? >> >> -- gil >> -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Nah - it's actually how they are on the IBM manual page - weird. On Fri, 2 Nov 2018 at 15:38, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On 2018-11-02, at 05:39:38, R.S. wrote: > > ... > > Content-Transfer-Encoding: 8bit > > Content-Type: text/plain; charset="utf-8"; format=flowed > > > > ... 16␠777␠215 tracks ... > > > I had to look it up: > The following table lists some symbols, in decreasing order by > practical usefulness. > Their shapes vary by font; especially the last one varies a lot. > ␣ U+2423 OPEN BOX > ␢ U+2422 BLANK SYMBOL > ␠ U+2420 SYMBOL FOR SPACE > > Eek! Do they always write numbers that way in Poland? > > -- 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: z/OS BDAM question
On 2018-11-02, at 05:39:38, R.S. wrote: > ... > Content-Transfer-Encoding: 8bit > Content-Type: text/plain; charset="utf-8"; format=flowed > > ... 16␠777␠215 tracks ... > I had to look it up: The following table lists some symbols, in decreasing order by practical usefulness. Their shapes vary by font; especially the last one varies a lot. ␣ U+2423 OPEN BOX ␢ U+2422 BLANK SYMBOL ␠ U+2420 SYMBOL FOR SPACE Eek! Do they always write numbers that way in Poland? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Another poster (sorry I deleted the post so can't credit him) already stated that the addressable range depends on the method you use to access the data set. Yes relative track addressing is 2 bytes and limited to 64K tracks. But relative block addressing is 3 bytes and so limited to 16M blocks. So depending on your block size you can address more than the physical limit of the data set. However, as Curtis has just pointed out, Adabas itself doesn't use BDAM, it uses EXCP/EXCPVR. And yes Curtis you are correct - most of our Adabas data sets are DSORG=DA but some of them are indeed DSORG=PS. Because I inherited these systems I'm not quite sure why. Must be something to do with the way they were first allocated and formatted (maybe different releases of Adabas), but it doesn't make a difference, they both work fine. Cheers, Mick. On Fri, 2 Nov 2018 at 12:30, Giliad Wilf < 00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > Interesting. > I recall two statements, probably from two different sources: > > One states that BDAM does not support large format datasets. > > The other states that DA datasets accessed by relative track address are > limited to 65536 tracks. > > ...so, I must assume ADABAS has a way for accessing records of a dataset > that large... > > On Fri, 2 Nov 2018 11:32:23 +, Mick Graley > wrote: > > >Hi All, > > > >I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > >I inherited a number of Adabas databases and they use DSORG=DA. > >One of my larger databases has a data storage component that is 240,525 > >tracks (16,035 cylinders) in 9 extents across 8 volumes. > > > >Organization . . . : DA > >Record format . . . : F > >Record length . . . : 5064 > >Block size . . . . : 5064 > >1st extent cylinders: 363 > >Secondary cylinders : 1668 > >Allocated cylinders : 16,035 > >Allocated extents . : 9 > > > >The rules are documented here: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > > > >Cheers, > > > >Mick. > > > > > >On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > > > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > are > >> usually physically equivalent to DSORG PS, and often are so designated. > >> However, most DA files I've seen are indeed RECFM=F. > >> > >> sas > >> > >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: > >> > >> > Datacom may use some method of "direct access," but the datasets > >> > themselves are RECFM=F. > >> > >> -- > >> 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 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: z/OS BDAM question
On Nov 2, 2018, at 7:29 AM, Giliad Wilf <00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: > > ...so, I must assume ADABAS has a way for accessing records of a dataset that > large... Actually, current ADABAS versions don’t use an access method; they write their own channel programs and issue EXCP. I think there’s an option to use VSAM on EAVs. All our ADABAS container datasets are defined as PS in the VTOC, but that doesn’t really matter. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Interesting. I recall two statements, probably from two different sources: One states that BDAM does not support large format datasets. The other states that DA datasets accessed by relative track address are limited to 65536 tracks. ...so, I must assume ADABAS has a way for accessing records of a dataset that large... On Fri, 2 Nov 2018 11:32:23 +, Mick Graley wrote: >Hi All, > >I can confirm that there is no 64K tracks limit on DSORG=DA data sets. >I inherited a number of Adabas databases and they use DSORG=DA. >One of my larger databases has a data storage component that is 240,525 >tracks (16,035 cylinders) in 9 extents across 8 volumes. > >Organization . . . : DA >Record format . . . : F >Record length . . . : 5064 >Block size . . . . : 5064 >1st extent cylinders: 363 >Secondary cylinders : 1668 >Allocated cylinders : 16,035 >Allocated extents . : 9 > >The rules are documented here: >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > >Cheers, > >Mick. > > >On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are >> usually physically equivalent to DSORG PS, and often are so designated. >> However, most DA files I've seen are indeed RECFM=F. >> >> sas >> >> On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: >> >> > Datacom may use some method of "direct access," but the datasets >> > themselves are RECFM=F. >> >> -- >> 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
It is a little bit more complex. There is third flavour or DSORG=PO, it is DSNTYPE=HFS. ;-) HFS is also constrained to single volume when non-SMS-managed. In the past it was simply single volume. Last, but not least: a database structure (table, tablespace, index) may or may not be constrained by limito of single dataset. For example, it was possible to create more-than-4GB objects, while VSAM limit was 4GB. Now it is usually EA VSAM, but it is still possible to use multiple datasets per object. Backing to the dataset limitations - PDS is the only dataset type/subtype which is really constrained to 64kTRK, because it is both single-volume, and 64k limit susceptible. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 13:18, Mick Graley pisze: Hi Radoslaw, That's true, but I believe the OP was asking whether the entire data set was limited to 64K tracks and I believe only PDS and PDS/E are limited to one volume. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4002.htm None of my database data sets (DB2, IMS, Adabas) are limited to one volume. Cheers, Mick. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Hi Radoslaw, That's true, but I believe the OP was asking whether the entire data set was limited to 64K tracks and I believe only PDS and PDS/E are limited to one volume. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4002.htm None of my database data sets (DB2, IMS, Adabas) are limited to one volume. Cheers, Mick. On Fri, 2 Nov 2018 at 11:58, R.S. wrote: > Mick, > You are still missing the point: 64k TRK limit is PER VOLUME. It regards > PDS, (basic) PS, and DA. > In other words, BDAM datasets are 64k TRK constrained as some other > datasets are. > Of course some (PDS) datasets cannot be multivolume, while DA (and PS) > can be, but that's different story. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > > W dniu 2018-11-02 o 12:51, Mick Graley pisze: > > Hi Radoslaw, > > If you combine all the rules for direct data sets across 2 or 3 pages of > > the manual you get: > > 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents > > across all volumes. > > Which suggests to me a limit of 3,866,565 tracks. > > Cheers, > > Mick. > > > > > > On Fri, 2 Nov 2018 at 11:40, R.S. > wrote: > > > >> Documentations says the following: > >> > >> /Many types of data sets *are limited* to 65␠535 total tracks allocated > >> on any one volume, and if a greater number of tracks is required, this > >> attempt to create a data set will fail./ > >> > >> // > >> /Data sets that *are not limited* to 65␠535 total tracks allocated on > >> any one volume are: / > >> > >>* /A large format sequential; but cannot occupy more than 16␠777␠215 > >> tracks on a single volume. / > >>* /Extended-format sequential/ > >>* /UNIX files/ > >>* /PDSE/ > >>* /VSAM/ > >> > >> ...lack od BDAM files here > >> > >> I think, you missed very important point: 64k tracks *PER VOLUME*. The > >> limit is not per dataset. > >> > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > >> > >> > >> > >> > >> W dniu 2018-11-02 o 12:32, Mick Graley pisze: > >>> Hi All, > >>> > >>> I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > >>> I inherited a number of Adabas databases and they use DSORG=DA. > >>> One of my larger databases has a data storage component that is 240,525 > >>> tracks (16,035 cylinders) in 9 extents across 8 volumes. > >>> > >>> Organization . . . : DA > >>> Record format . . . : F > >>> Record length . . . : 5064 > >>> Block size . . . . : 5064 > >>> 1st extent cylinders: 363 > >>> Secondary cylinders : 1668 > >>> Allocated cylinders : 16,035 > >>> Allocated extents . : 9 > >>> > >>> The rules are documented here: > >>> > >> > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > >>> Cheers, > >>> > >>> Mick. > >>> > >>> > >>> On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > >>> > BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > >> are > usually physically equivalent to DSORG PS, and often are so > designated. > However, most DA files I've seen are indeed RECFM=F. > > sas > > >> > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with
Re: z/OS BDAM question
Mick, You are still missing the point: 64k TRK limit is PER VOLUME. It regards PDS, (basic) PS, and DA. In other words, BDAM datasets are 64k TRK constrained as some other datasets are. Of course some (PDS) datasets cannot be multivolume, while DA (and PS) can be, but that's different story. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:51, Mick Graley pisze: Hi Radoslaw, If you combine all the rules for direct data sets across 2 or 3 pages of the manual you get: 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents across all volumes. Which suggests to me a limit of 3,866,565 tracks. Cheers, Mick. On Fri, 2 Nov 2018 at 11:40, R.S. wrote: Documentations says the following: /Many types of data sets *are limited* to 65␠535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail./ // /Data sets that *are not limited* to 65␠535 total tracks allocated on any one volume are: / * /A large format sequential; but cannot occupy more than 16␠777␠215 tracks on a single volume. / * /Extended-format sequential/ * /UNIX files/ * /PDSE/ * /VSAM/ ...lack od BDAM files here I think, you missed very important point: 64k tracks *PER VOLUME*. The limit is not per dataset. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:32, Mick Graley pisze: Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are usually physically equivalent to DSORG PS, and often are so designated. However, most DA files I've seen are indeed RECFM=F. sas == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Hi Radoslaw, If you combine all the rules for direct data sets across 2 or 3 pages of the manual you get: 65,535 tracks per volume, 59 volumes, 16 extents per volume, 255 extents across all volumes. Which suggests to me a limit of 3,866,565 tracks. Cheers, Mick. On Fri, 2 Nov 2018 at 11:40, R.S. wrote: > Documentations says the following: > > /Many types of data sets *are limited* to 65␠535 total tracks allocated > on any one volume, and if a greater number of tracks is required, this > attempt to create a data set will fail./ > > // > /Data sets that *are not limited* to 65␠535 total tracks allocated on > any one volume are: / > > * /A large format sequential; but cannot occupy more than 16␠777␠215 > tracks on a single volume. / > * /Extended-format sequential/ > * /UNIX files/ > * /PDSE/ > * /VSAM/ > > ...lack od BDAM files here > > I think, you missed very important point: 64k tracks *PER VOLUME*. The > limit is not per dataset. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2018-11-02 o 12:32, Mick Graley pisze: > > Hi All, > > > > I can confirm that there is no 64K tracks limit on DSORG=DA data sets. > > I inherited a number of Adabas databases and they use DSORG=DA. > > One of my larger databases has a data storage component that is 240,525 > > tracks (16,035 cylinders) in 9 extents across 8 volumes. > > > > Organization . . . : DA > > Record format . . . : F > > Record length . . . : 5064 > > Block size . . . . : 5064 > > 1st extent cylinders: 363 > > Secondary cylinders : 1668 > > Allocated cylinders : 16,035 > > Allocated extents . : 9 > > > > The rules are documented here: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm > > > > Cheers, > > > > Mick. > > > > > > On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > > > >> BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files > are > >> usually physically equivalent to DSORG PS, and often are so designated. > >> However, most DA files I've seen are indeed RECFM=F. > >> > >> sas > >> > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > > > -- > 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: z/OS BDAM question
Documentations says the following: /Many types of data sets *are limited* to 65␠535 total tracks allocated on any one volume, and if a greater number of tracks is required, this attempt to create a data set will fail./ // /Data sets that *are not limited* to 65␠535 total tracks allocated on any one volume are: / * /A large format sequential; but cannot occupy more than 16␠777␠215 tracks on a single volume. / * /Extended-format sequential/ * /UNIX files/ * /PDSE/ * /VSAM/ ...lack od BDAM files here I think, you missed very important point: 64k tracks *PER VOLUME*. The limit is not per dataset. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-02 o 12:32, Mick Graley pisze: Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are usually physically equivalent to DSORG PS, and often are so designated. However, most DA files I've seen are indeed RECFM=F. sas == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Hi All, I can confirm that there is no 64K tracks limit on DSORG=DA data sets. I inherited a number of Adabas databases and they use DSORG=DA. One of my larger databases has a data storage component that is 240,525 tracks (16,035 cylinders) in 9 extents across 8 volumes. Organization . . . : DA Record format . . . : F Record length . . . : 5064 Block size . . . . : 5064 1st extent cylinders: 363 Secondary cylinders : 1668 Allocated cylinders : 16,035 Allocated extents . : 9 The rules are documented here: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/mdss.htm Cheers, Mick. On Sat, 27 Oct 2018 at 01:10, Steve Smith wrote: > BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are > usually physically equivalent to DSORG PS, and often are so designated. > However, most DA files I've seen are indeed RECFM=F. > > sas > > On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: > > > Datacom may use some method of "direct access," but the datasets > > themselves are RECFM=F. > > -- > 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: z/OS BDAM question
BDAM implies DSORG DA, but can use any RECFM. However, DSORG DA files are usually physically equivalent to DSORG PS, and often are so designated. However, most DA files I've seen are indeed RECFM=F. sas On Fri, Oct 26, 2018 at 11:40 AM Tom Sims wrote: > Datacom may use some method of "direct access," but the datasets > themselves are RECFM=F. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Datacom may use some method of "direct access," but the datasets themselves are RECFM=F. Disclaimer, not a Datacom expert, more of a Datacom victim, by way of other CA program products. Tom Sims On 10/26/2018 8:11 AM, Rob Schramm wrote: I think I have seen it work for DSNTYPE=LARGE instead of extended format. Aren't CA Datacom files bdam? I say that because.. last time i interacted with Datacom it was only able to use DSNTYPE=LARGE. Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
Well I'll BDAM Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services Humana Inc. 123 East Main Street Louisville, KY 40202 Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Friday, October 26, 2018 11:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] z/OS BDAM question On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote: >want to know if BDAM can be larger than 65535 tracks. Is this limitation per >extent or entire file size. It seems to depend on how you want to access it. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4087.htm -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote: >want to know if BDAM can be larger than 65535 tracks. Is this limitation per >extent or entire file size. It seems to depend on how you want to access it. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/d4087.htm -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
I think I have seen it work for DSNTYPE=LARGE instead of extended format. Aren't CA Datacom files bdam? I say that because.. last time i interacted with Datacom it was only able to use DSNTYPE=LARGE. Rob Schramm On Thu, Oct 25, 2018, 11:18 PM Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > My personal experience converting two old BDAM-based systems in the past > (one for an ISV product, one for a user application), is that converting to > use RRDS is relatively easy (SMOP), gives you much better control of error > conditions, and performs as well or better even in extreme conditions if > you make intelligent use of BLSR or SMB to use local caching of buffers. > Memory is (relatively) cheap, so make the most use of it that you can. > > And RRDS can be both extended (> 4Gb file size) and compressed saving much > disk space, but YMMV depending on the volume of I/O you need to sustain. > Compression isn't free, though it seems to be quite inexpensive (in CPU > time) these days, at least on relatively current hardware. > > And RRDS is supported in z/VSE as well, making the code more portable if > you need that option. > > HTH > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Frank M. Ramaekers > Sent: Wednesday, October 24, 2018 2:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS BDAM question > > EXTERNAL EMAIL > > I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT > want to know if BDAM can be larger than 65535 tracks. Is this limitation > per extent or entire file size. > > From the z/VSE LISTSERV: > I believe it is 65K tracks per extent with a maximum of 255 extents for > BDAM, but I can't find any doc to verify that right now. > > -- > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > -- > 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: z/OS BDAM question
My personal experience converting two old BDAM-based systems in the past (one for an ISV product, one for a user application), is that converting to use RRDS is relatively easy (SMOP), gives you much better control of error conditions, and performs as well or better even in extreme conditions if you make intelligent use of BLSR or SMB to use local caching of buffers. Memory is (relatively) cheap, so make the most use of it that you can. And RRDS can be both extended (> 4Gb file size) and compressed saving much disk space, but YMMV depending on the volume of I/O you need to sustain. Compression isn't free, though it seems to be quite inexpensive (in CPU time) these days, at least on relatively current hardware. And RRDS is supported in z/VSE as well, making the code more portable if you need that option. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank M. Ramaekers Sent: Wednesday, October 24, 2018 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS BDAM question EXTERNAL EMAIL I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want to know if BDAM can be larger than 65535 tracks. Is this limitation per extent or entire file size. >From the z/VSE LISTSERV: I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, but I can't find any doc to verify that right now. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
W dniu 2018-10-24 o 20:22, Frank M. Ramaekers pisze: I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want to know if BDAM can be larger than 65535 tracks. Is this limitation per extent or entire file size. >From the z/VSE LISTSERV: I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, but I can't find any doc to verify that right now. BDAM (DSORG=DA) dataset is limited to 64k TRKs. Whole dataset, not extent. There are other limitations regarding extents. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS BDAM question
You can't. BDAM does not support DSNTYPE=LARGE. Giliad On Wed, 24 Oct 2018 18:22:04 +, Frank M. Ramaekers wrote: >I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want >to know if BDAM can be larger than 65535 tracks. Is this limitation per >extent or entire file size. > >From the z/VSE LISTSERV: >I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, >but I can't find any doc to verify that right now. > >Frank M. Ramaekers Jr. | Systems Programmer | Information Technology | >American Income Life Insurance Company | 254-761-6649 (732-6649) > >-- >This message contains information which is privileged and confidential and is >solely for the use of the intended recipient. If you are not the intended >recipient, be aware that any review, disclosure, copying, distribution, or use >of the contents of this message is strictly prohibited. If you have received >this in error, please destroy it immediately and notify us at >privacy...@torchmarkcorp.com. > >-- >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: z/OS BDAM question
If you use the Relative Block Address the dataset can be much larger. Mikael Nyström Core Ledger SEB Phone: +46 70 739 48 55 Switchboard: +46 771 62 10 00 Postal Address: A-B9, SE-106 40 Stockholm, Sweden Office Address: Stjarntorget 4 E-mail: mikael.nyst...@seb.se www.seb.se ? Please consider the environment before printing this e-mail CONFIDENTIALITY NOTICE This e-mail is confidential and may contain legally privileged information. If you have received it by mistake, please inform us by reply e-mail and then delete it (including any attachments) from your system; you should not copy it or in any other way disclose its content to anyone. E-mail is susceptible to data corruption, interception, unauthorised amendment, tampering and virus. We do not accept liability for any such actions or the consequences thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank M. Ramaekers Sent: den 24 oktober 2018 20:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS BDAM question I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want to know if BDAM can be larger than 65535 tracks. Is this limitation per extent or entire file size. >From the z/VSE LISTSERV: I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, but I can't find any doc to verify that right now. Frank M. Ramaekers Jr. | Systems Programmer | Information Technology | American Income Life Insurance Company | 254-761-6649 (732-6649) -- This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@torchmarkcorp.com. -- 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: z/OS BDAM question
Hi Frank, The limitation is for the entire data set... Rule: Direct data sets whose records are to be identified by relative track address must be limited in size to no more than 65 536 tracks for the entire data set. The above and more details can be found here... http://publibz.boulder.ibm.com/epubs/pdf/dgt3d410.pdf I don't believe this limitation has changed in the past few years, but you might want to check the doc for whatever version of z/OS you're running. HTH, Mike From: IBM Mainframe Discussion List on behalf of Frank M. Ramaekers Sent: Wednesday, October 24, 2018 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS BDAM question I'm a z/VM and z/VSE shop, but we do have a z/OS system and someone in IT want to know if BDAM can be larger than 65535 tracks. Is this limitation per extent or entire file size. >From the z/VSE LISTSERV: I believe it is 65K tracks per extent with a maximum of 255 extents for BDAM, but I can't find any doc to verify that right now. Frank M. Ramaekers Jr. | Systems Programmer | Information Technology | American Income Life Insurance Company | 254-761-6649 (732-6649) -- This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@torchmarkcorp.com. -- 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
