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
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 convent
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
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; ch
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.
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
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 i
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 o
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
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,
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.
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.
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
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
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 a
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
f 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
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.i
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 BD
scussion 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
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 ext
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 f
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
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.
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'
25 matches
Mail list logo
