Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

In <1329705063.29591.54.ca...@mckown5.johnmckown.net>, on 02/19/2012 at 08:31 PM, John McKown said: >Just to play the Devil's advocate for a bit, it depends on how you >define "dataset name". I agree, in Linux (and as a stretch, Windows), >if you specify the entire file path, starting from the

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

In <4f418fa1.4040...@acm.org>, on 02/19/2012 at 06:11 PM, "Joel C. Ewing" said: >Under Windows, a directory is closer functionally to the MVS/DOS >concept of a VTOC, as each volume has its own directory ITYM each volume has its own root directory; a typical DOS or 'doze volume has many direc

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

nsurance 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- > >

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

day, February 20, 2012 8:24 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: O/T but curious (Re: Archaic allocation in JCL > > (Was: Physical record size query) ) > > > > On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM > > wrote: > > > "R.S.&

Re: Archaic allocation in JCL (Was: Physical record size query)

Gilmore > Sent: Fri 2/17/2012 6:21 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > > > > Frank Swabrick wrote: > > > | No, I'm not expecting a real answer to that question. > | Just trying to point ou

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

rame Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab > Sent: Monday, February 20, 2012 8:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: O/T but curious (Re: Archaic allocation in JCL > (Was: Physical record size query) ) > > On Mon, Feb 20, 2012 at 1:58 AM

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

>>> On 2/20/2012 at 08:34 AM, John McKown wrote: > If the filesystem runs out of space, > and you used the proper type of filesystem (there are many), you simply > expand the size of the logical volume into unused space in the group. > You then resize the filesystem. If you used ext4 or btrfs, I

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

"Mike Schwab" wrote in message news:... > On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM > wrote: > > "R.S." wrote in message > > news:<4f41f979.3010...@bremultibank.com.pl>... > <> > >> What is cool is that SMS storage group. Usually users do not see the > >> volumes, they see dasd space

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM wrote: > "R.S." wrote in message > news:<4f41f979.3010...@bremultibank.com.pl>... <> >> What is cool is that SMS storage group. Usually users do not see the >> volumes, they see dasd space. In case of shortage you can simply add >> some volume

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote: > What is cool is that SMS storage group. Usually users do not see the > volumes, they see dasd space. In case of shortage you can simply add > some volumes to the group. You can even buy new box and simply add it to > the group. And that's really

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On Sun, 19 Feb 2012 18:11:13 -0600, Joel C. Ewing wrote: >> >Under Windows, a directory is closer functionally to the MVS/DOS concept >of a VTOC, as each volume has its own directory and you have to somehow >know which volume to consult -- although admittedly in a windows system >the number of volu

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On Sun, 19 Feb 2012 20:31:03 -0600, John McKown wrote: > >Linux addresses this issue via a utility called "mlocate". It runs >periodically, usually once a day during a low activity time, via >crontab. And, as you immediate can tell, it is not real time. Files get >created and deleted without an imm

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

"R.S." wrote in message news:<4f41f979.3010...@bremultibank.com.pl>... > W dniu 2012-02-19 17:23, Edward Jaffe pisze: > > On 2/19/2012 4:40 AM, R.S. wrote: > >> W dniu 2012-02-19 08:30, Edward Jaffe pisze: > >>> On 2/18/2012 4:45 PM, Paul Gilmartin wrote: > Remember that if z/OS didn't impose

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

W dniu 2012-02-19 17:23, Edward Jaffe pisze: On 2/19/2012 4:40 AM, R.S. wrote: W dniu 2012-02-19 08:30, Edward Jaffe pisze: On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Just to play the Devil's advocate for a bit, it depends on how you define "dataset name". I agree, in Linux (and as a stretch, Windows), if you specify the entire file path, starting from the root, you don't need a catalog. But if you think of a file within a given subdirectory as a dataset equiv

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Lol, nope , that would be a big file Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 19, 2012, at 4:56 PM, Ed Gould wrote: > Perhaps, > > But have you ever heard of a 1 petabyte (or more) volume? > > Ed > > On Feb 18, 2012, at 5:36 PM, Scott Ford wrote: >

Re: Archaic allocation in JCL (Was: Physical record size query)

Amen John!! From: IBM Mainframe Discussion List on behalf of John Gilmore Sent: Fri 2/17/2012 6:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Archaic allocation in JCL (Was: Physical record size query) Frank Swabrick wrote: | No, I'm not expecting a

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On 02/19/2012 11:40 AM, Shmuel Metz (Seymour J.) wrote: In , on 02/18/2012 at 07:06 PM, Mike Schwab said: Neither Windows or Linux have a Catalog concept to find a dataset on What do you think a directory is? Under Windows, a directory is closer functionally to the MVS/DOS concept of a

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Perhaps, But have you ever heard of a 1 petabyte (or more) volume? Ed On Feb 18, 2012, at 5:36 PM, Scott Ford wrote: Ed, Or maybe they use the famous four letter word, plan and have a harddrive big enough to handle the file Sent from my iPad Scott Ford Senior Systems Engineer www.identity

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

In , on 02/18/2012 at 07:06 PM, Mike Schwab said: >Neither Windows or Linux have a Catalog concept to find a dataset on What do you think a directory is? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't care.

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On 2/19/2012 4:40 AM, R.S. wrote: W dniu 2012-02-19 08:30, Edward Jaffe pisze: On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In that case, widespread adoption of 1TB volumes

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

W dniu 2012-02-19 08:30, Edward Jaffe pisze: On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In that case, widespread adoption of 1TB volumes on z/OS should significantly decrea

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On 2/18/2012 4:45 PM, Paul Gilmartin wrote: Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for multivolume data sets. In that case, widespread adoption of 1TB volumes on z/OS should significantly decrease the number of multivolume data sets in use

Re: Archaic allocation in JCL (Was: Physical record size query)

W dniu 2012-02-19 03:34, Clark Morris pisze: [...] For VSAM I would still allocate in either tracks or cylinders so that I get the CA size I want. Of course if allocation is in millions of anything, that caveat doesn't matter (or have they changed VSAM so a CA can be larger than a cylinder?).

Re: Archaic allocation in JCL (Was: Physical record size query)

On 18 Feb 2012 17:53:19 -0800, in bit.listserv.ibm-main you wrote: >At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic >allocation in JCL (Was: Physical record size qu: > >>The "gotcha" used to be that if you grossly over-requested space, >>got space dispersed over umpteen volum

Re: Archaic allocation in JCL (Was: Physical record size query)

At 14:07 -0500 on 02/17/2012, Shmuel Metz (Seymour J.) wrote about Re: Archaic allocation in JCL (Was: Physical record size qu: In , on 02/17/2012 at 12:50 PM, John Gilmore said: is not really wrongheaded. It is an unfortunate oversimplification for real DASD. Not if you were only disc

Re: Archaic allocation in JCL (Was: Physical record size query)

At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic allocation in JCL (Was: Physical record size qu: The "gotcha" used to be that if you grossly over-requested space, got space dispersed over umpteen volumes, only used a little of the space, that "RLSE" would then only release

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Under Linux / AIX, You can define a logical volume that spans multiple physical volumes. And different mount points can point to different physical drives. But reading from the root / it all looks like one logical drive. Windows has different drive letters for each drive or hard drive partition

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

On Sat, 18 Feb 2012 16:43:27 -0600, Ed Gould wrote: > >The secondary question I am asking is how does the PC create/handle >multivolume files? > Virtual volumes as big as needed: RAID; ZFS; ...? Remember that if z/OS didn't impose a factitious limit on volume size, there'd be little need for mul

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Ed, Or maybe they use the famous four letter word, plan and have a harddrive big enough to handle the file Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 18, 2012, at 5:43 PM, Ed Gould wrote: > We are all pretty much knowledgeable about how the MF works in

Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

Sure: it doesn't. Unless you're using some other sort of volume manager. Of course, with a 1TB drive selling for less than $100, multivolume files aren't usually a requirement... On Sat, Feb 18, 2012 at 2:43 PM, Ed Gould wrote: > We are all pretty much knowledgeable about how the MF works in the

O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

We are all pretty much knowledgeable about how the MF works in the multi-volume area, right? The secondary question I am asking is how does the PC create/handle multivolume files? I can guess but that is pretty much all it is. Can anyone explain it for the PC ? Ed

Re: Archaic allocation in JCL (Was: Physical record size query)

an do it's own analysis. After all, is that not what computers are for? Frank From: John Gilmore To: IBM-MAIN@bama.ua.edu Sent: Friday, February 17, 2012 5:21 PM Subject: Re: Archaic allocation in JCL (Was: Physical record size query) Frank Swab

Re: Archaic allocation in JCL (Was: Physical record size query)

In , on 02/17/2012 at 12:50 PM, John Gilmore said: >is not really wrongheaded. It is an unfortunate oversimplification >for real DASD. Not if you were only discussing conversion of the SPACE parameter. I agree that carrying over BLKSIZE from generation to generation is ghastly, albeit far to

Re: Archaic allocation in JCL (Was: Physical record size query)

In <0987218410888335.wa.paulgboulderaim@bama.ua.edu>, on 02/17/2012 at 11:02 AM, Paul Gilmartin said: >It would seem to me that when the time came to convert from 3330 to >3350 (e.g.), the simple path would have been to replace "TRK" with >"13030" That would have left a lot of slack. Pos

Re: Archaic allocation in JCL (Was: Physical record size query)

re for? > > Frank > > > > >> >> From: John Gilmore >>To: IBM-MAIN@bama.ua.edu >>Sent: Friday, February 17, 2012 5:21 PM >>Subject: Re: Archaic allocation in JCL (Was: Physical record size query) >> >>Frank S

Re: Archaic allocation in JCL (Was: Physical record size query)

_ > From: John Gilmore >To: IBM-MAIN@bama.ua.edu >Sent: Friday, February 17, 2012 5:21 PM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >Frank Swabrick wrote: > > >| No, I'm not expecting a real answer to that question. >| Just tr

Re: Archaic allocation in JCL (Was: Physical record size query)

Frank Swabrick wrote: | No, I'm not expecting a real answer to that question. | Just trying to point out why it's hard, to say the least, | to know how to size files of this type. The question itself has not been very well formulated. No one, I hope and suppose, sizes files directly in cylinde

Re: Archaic allocation in JCL (Was: Physical record size query)

If that is not sarcasm than you've hopelessly lost me. Frank > > From: Paul Gilmartin >To: IBM-MAIN@bama.ua.edu >Sent: Friday, February 17, 2012 3:57 PM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >On

Re: Archaic allocation in JCL (Was: Physical record size query)

On Fri, 17 Feb 2012 13:46:12 -0800, Frank Swarbrick wrote: >How many transactions am I going to post today?  How many on Monday.  What >about Tuesday after a three day weekend?  What about Tuesday on a 3 day >weekend 4 years from now? >Each "transactions" is 100 bytes.  We save the transactions

Re: Archaic allocation in JCL (Was: Physical record size query)

Variable length records? > > From: Scott Ford >To: IBM-MAIN@bama.ua.edu >Sent: Friday, February 17, 2012 8:59 AM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >Gil, > >Worked with a math phd for a b

Re: Archaic allocation in JCL (Was: Physical record size query)

__ > From: Edward Jaffe >To: IBM-MAIN@bama.ua.edu >Sent: Friday, February 17, 2012 7:57 AM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >On 2/17/2012 6:32 AM, Steve Comstock wrote: >> On 2/17/2012 12:57 AM, Edward Jaffe wrote: >>>

Re: Archaic allocation in JCL (Was: Physical record size query)

What i usually do, is once I get the file created, is to set the allocation to 10% more than the file size and secondary extents to 10% of the file size. First time around, CYL,(100,100),RLSE or some SWAG. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all?

Re: Archaic allocation in JCL (Was: Physical record size query)

Paul Gilmartin's: It would seem to me that when the time came to convert from 3330 to 3350 (e.g.), the simple path would have been to replace "TRK" with "13030" (CYL slightly more complicated) and leave the other numbers unchanged. JCL so modified would work on either model during the transition

Re: Archaic allocation in JCL (Was: Physical record size query)

On Fri, 17 Feb 2012 10:39:03 -0600, Mark Zelden wrote: > >Although it is a crude and inaccurate conversion, one could use M instead of >CYL basically >1:1 and would be sure to get enough space since 1M is about 1.42 CYLs. If I >did that at >least I could picture it in my head the same way I h

Re: Archaic allocation in JCL (Was: Physical record size query)

On Thu, 16 Feb 2012 23:57:44 -0800, Edward Jaffe wrote: >On 2/13/2012 9:38 AM, Joel C. Ewing wrote: >> Requiring application programmers to think in terms of tracks and cylinders >> and to understand interaction between physical block size and track capacity >> is indeed archaic, as are artifici

Re: Archaic allocation in JCL (Was: Physical record size query)

"Paul Gilmartin" wrote in message news:<2410839884184451.wa.paulgboulderaim@bama.ua.edu>... > On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote: > > > >Me too, never even thought of megabytes until the pc slam dunk artists came along, everyone I knew calculated their file size in tracks or

Re: Archaic allocation in JCL (Was: Physical record size query)

Gil, Worked with a math phd for a bunch of yrs and he preached records for allocations, not cyls or tracks. I guess everyone has an opinion... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 17, 2012, at 10:41 AM, Paul Gilmartin wrote: > On Fri, 17 Feb 2012

Re: Archaic allocation in JCL (Was: Physical record size query)

On Fri, 17 Feb 2012 09:59:13 -0500, Scott Ford wrote: > >Me too, never even thought of megabytes until the pc slam dunk artists came >along, everyone I knew calculated their file size in tracks or cyls. As >someone tod me new world orderlol > I would have expected that during technology tran

Re: Archaic allocation in JCL (Was: Physical record size query)

Guys, Me too, never even thought of megabytes until the pc slam dunk artists came along, everyone I knew calculated their file size in tracks or cyls. As someone tod me new world orderlol Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 17, 2012, at 9:32 A

Re: Archaic allocation in JCL (Was: Physical record size query)

On 2/17/2012 6:32 AM, Steve Comstock wrote: On 2/17/2012 12:57 AM, Edward Jaffe wrote: TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that these days? SPACE=(1,(5,1),RLSE),AVGREC=M Allocate in MEGs I would have thought allocations in records or thousands of records,

Re: Archaic allocation in JCL (Was: Physical record size query)

On 2/17/2012 12:57 AM, Edward Jaffe wrote: On 2/13/2012 9:38 AM, Joel C. Ewing wrote: Requiring application programmers to think in terms of tracks and cylinders and to understand interaction between physical block size and track capacity is indeed archaic, as are artificial restrictions on numb

Re: Archaic allocation in JCL (Was: Physical record size query)

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe > Sent: Friday, February 17, 2012 1:58 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Archaic allocation in JCL (Was: Physical record > size query) >

Re: Archaic allocation in JCL (Was: Physical record size query)

Edward Jaffe has now made the crucial point. Circumventions of any great need to know much about TRK and CYL issues are available (and in one form or another have long been available). That said, the geometry of real DASD was never an intellectually challenging topic; and I grow ever more weary o

Re: Archaic allocation in JCL (Was: Physical record size query)

On 2/13/2012 9:38 AM, Joel C. Ewing wrote: Requiring application programmers to think in terms of tracks and cylinders and to understand interaction between physical block size and track capacity is indeed archaic, as are artificial restrictions on number of extents or volumes. TRKs and CYLs

Re: Archaic allocation in JCL (Was: Physical record size query)

m: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > Thomas Berg > Sent: Monday, February 13, 2012 3:28 AM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] Archaic allocation in JCL (Was: Physical record size > query) > > I can't understand why we

Re: Archaic allocation in JCL (Was: Physical record size query)

Pretty much the latter, with release at YI for most. EXTENDED as the default. I have a DATACLAS=BIG vs. BIGEXT to use for the few cases that can't be extended. Haven't seen an x37 in ages (except for some truly large SMF/PDB files) where the required space needs a bit of hand holding. It does

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

ussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of > Thomas Berg > Sent: Monday, February 13, 2012 5:11 AM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] SV: Archaic allocation in JCL (Was: Physical record size > query) > > > -Ursprungligt meddelande- >

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

On 2/14/2012 9:42 AM, Thomas Berg wrote: AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. -> There have been changes in the JCL "language" the latest Years: LIKE, DCB subparms outside of the DCB parm, etc.

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

On Tue, 14 Feb 2012 11:28:58 +0100, Vernooij, CP - SPLXM wrote: >"Paul Gilmartin" wrote in message >> >> And now I may add to my list another example or two of IBM's having >> a good idea but implementing it in the wrong layer. This should have >> been done not in MQ and/or DB2, but in allocatio

Re: Archaic allocation in JCL (Was: Physical record size query)

On Tue, 14 Feb 2012 07:26:38 -0500, Lizette Koehler wrote: > >I think it was amazing that IBM was able to eliminate the need for >DCB=(x) and just let us use the subparms. > My conjecture is that the UNIX file systems provided the impetus for this. The designers wanted to allow RECFM, LRECL,

SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Lizette Koehler > Skickat: den 14 februari 2012 13:27 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > >

Re: Archaic allocation in JCL (Was: Physical record size query)

> > > > But, this is precisely what SMS and DATACLAS are for. It does > > accomplish, for the most part, SPACE=ANY. > > Not fully using SMS is so 80s' > > If so, do You really see everyone that creates and submits JCLs to create/change > DATACLAS/STORCLAS instead of editing the SPACE= parms ? >

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

"Paul Gilmartin" wrote in message news:<2205241542597622.wa.paulgboulderaim@bama.ua.edu>... > On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: > > > >The only application I know that manages extent size - that means using > >some algorithm for extent increase - is MQ Series aka Wbesphere MQ > >

SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Gibney, Dave > Skickat: den 13 februari 2012 22:31 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > >

Re: Archaic allocation in JCL (Was: Physical record size query)

On 02/13/2012 04:26 PM, Paul Gilmartin wrote: On Mon, 13 Feb 2012 16:11:53 -0600, Joel C. Ewing wrote: (I'd prefer, for legibility, SPACE=(1,54.000.000.000) with European thousands separators.) Not sure about your reference to half-word chunks. Although there are 16Mi limits on max numerica

Re: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 16:11:53 -0600, Joel C. Ewing wrote: > >> (I'd prefer, for legibility, SPACE=(1,54.000.000.000) with European >> thousands separators.) > >Not sure about your reference to half-word chunks. Although there are >16Mi limits on max numerical value for primary-qty parameter, >"SPAC

Re: Archaic allocation in JCL (Was: Physical record size query)

On 02/13/2012 02:43 PM, Paul Gilmartin wrote: On Mon, 13 Feb 2012 11:38:44 -0600, Joel C. Ewing wrote: It should be possible to just specify data set limits in terms of data bytes expected or records/average-record-length expected without regard for tracks, cylinders, extents, or volumes. ...

Re: Archaic allocation in JCL (Was: Physical record size query)

bject: SV: Archaic allocation in JCL (Was: Physical record size query) > > > -Ursprungligt meddelande- > > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > > Lizette Koehler > > Skickat: den 13 februari 2012 12:43 > > Till: IBM-MAIN@bama.

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

Sent from my iPad On Feb 13, 2012, at 14:53, "Paul Gilmartin" wrote: > On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: >> >> The only application I know that manages extent size - that means using >> some algorithm for extent increase - is MQ Series aka Wbesphere MQ >> (since version 6 AFAIR).

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: > >The only application I know that manages extent size - that means using >some algorithm for extent increase - is MQ Series aka Wbesphere MQ >(since version 6 AFAIR). >It would be nice to have such facility in DATACLASS. > Nice indeed. And someone

Re: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 11:38:44 -0600, Joel C. Ewing wrote: >> >It should be possible to just specify data set limits in terms of >data bytes expected or records/average-record-length expected without >regard for tracks, cylinders, extents, or volumes. ... > And the user interface should be simplifi

Re: Archaic allocation in JCL (Was: Physical record size query)

In , on 02/13/2012 at 09:19 AM, Chris Craddock said: >I think it is fair to say that JCL and space management are areas >where z/OS truly is archaic. The "other" world manages to get by just >fine without having to figure out how much resource to give. It's not that they have fewer space issu

Re: Archaic allocation in JCL (Was: Physical record size query)

ire, both now and 10 years down the line".  Never been by idea of a good use of my time. Frank > > From: Chris Craddock >To: IBM-MAIN@bama.ua.edu >Sent: Monday, February 13, 2012 8:19 AM >Subject: Re: Archaic allocation in JCL (Was: Physical

SV: Archaic allocation in JCL (Was: Physical record size query)

För > Frank Swarbrick > Skickat: den 13 februari 2012 19:27 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > > Are you sure you are a mainframer? > > > > > > > From: Thomas

Re: Archaic allocation in JCL (Was: Physical record size query)

oij, CP - SPLXM >> > Skickat: den 13 februari 2012 14:22 >> > Till: IBM-MAIN@bama.ua.edu >> > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) >> > >> > "Thomas Berg" wrote in message >> > news:> > se>... &g

Re: Archaic allocation in JCL (Was: Physical record size query)

> From: Lizette Koehler >To: IBM-MAIN@bama.ua.edu >Sent: Monday, February 13, 2012 4:42 AM >Subject: Re: Archaic allocation in JCL (Was: Physical record size query) > >> >> I can't understand why we STILL need to specify SPACE= (etc) for an >al

Re: Archaic allocation in JCL (Was: Physical record size query)

Are you sure you are a mainframer? > > From: Thomas Berg >To: IBM-MAIN@bama.ua.edu >Sent: Monday, February 13, 2012 4:27 AM >Subject: Archaic allocation in JCL (Was: Physical record size query) > >I can't understand why we STILL n

Re: Archaic allocation in JCL (Was: Physical record size query)

On 02/13/2012 09:19 AM, Chris Craddock wrote: On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartinwrote: On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: Or, as the programmers at our shop would do: SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTAN

SV: SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul > Gilmartin > Skickat: den 13 februari 2012 16:30 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: SV: Archaic allocation in JCL (Was: Physical record size query) > > O

Re: Archaic allocation in JCL (Was: Physical record size query)

AIN@bama.ua.edu] On Behalf Of Paul Gilmartin > Sent: Monday, February 13, 2012 8:56 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Archaic allocation in JCL (Was: Physical record > size query) > > On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: > > >Or, as the pro

Re: Archaic allocation in JCL (Was: Physical record size query)

This only works on an empty dasd storage group. In a well filled one, there are only few allocations per volume of this calculated size possible, reducing very much the real amount of usable space per volume. If you lower the size, there are more allocatins possible and somewhere there is the op

Re: Archaic allocation in JCL (Was: Physical record size query)

You can always take the capacity of your largest volume, divide it by the maximum number of extents, and make that your allocation size. Then it can spread across 59 volumes for the maximum possible data set size. On Mon, Feb 13, 2012 at 9:19 AM, Chris Craddock wrote: > On Mon, Feb 13, 2012 at 8:

Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query)

"Thomas Berg" wrote in message news:... > > -Ursprungligt meddelande- > > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. > > Skickat: den 13 februari 2012 15:49 > > Till: IBM-MAIN@bama.ua.edu > > Ämne: Re: SV: SV:

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 16:13:48 +0100, Thomas Berg wrote: >> > >> Can you use UNIX files (zFS) for your purposes and avoid the archaism? > >Not practically. But that would be a circumvention, not a solution as I see >it. > When something doesn't work as desired, and it's impractical to fix it (R.S.

Re: Archaic allocation in JCL (Was: Physical record size query)

W dniu 2012-02-13 15:56, Paul Gilmartin pisze: On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: Or, as the programmers at our shop would do: SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. In many other systems, such as Win

Re: SV: SV: SV: Archaic allocation in JCL (Was: Physical record size query)

On 02/13/12 10:20, Thomas Berg wrote: I refuse! :) (In my life space abends occurs regularly, often caused by circumstances beyond my control.) BTW, You latter suggestions is not bad - but You didn't go far enough! There should unlimited number of *everything*! Don't make artificial limits

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

W dniu 2012-02-13 16:14, Paul Gilmartin pisze: On Mon, 13 Feb 2012 14:48:57 +0100, R.S. wrote: Your idea is worth discussion, but not your requirement is off target. It is not JCL problem, it is z/OS problem. To fill the requirement the sapce should be allocated ad hoc, cluster after cluster (*

SV: SV: SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. > Skickat: den 13 februari 2012 15:49 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: SV: SV: Archaic allocation in JCL (Was: Physical record size > query) > > W dniu

Re: Archaic allocation in JCL (Was: Physical record size query)

On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin wrote: > On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: > > >Or, as the programmers at our shop would do: > > > > >SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. > > > >In many

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 14:48:57 +0100, R.S. wrote: > >Your idea is worth discussion, but not your requirement is off target. >It is not JCL problem, it is z/OS problem. To fill the requirement the >sapce should be allocated ad hoc, cluster after cluster (*). That >requires total VTOC revolution. > Wh

SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul > Gilmartin > Skickat: den 13 februari 2012 15:48 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > > On M

Re: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: >Or, as the programmers at our shop would do: > >SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. > >In many other systems, such as Winblows, everybody gets their own personal >"s

Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query)

W dniu 2012-02-13 15:21, Thomas Berg pisze: (This is an answer also to Vernooij.) Please consider what You do manually when the space is to small (e g B37 etc.), or You just is unsure: You try a bigger allocation, maybe also extend (or reduce) the secondary amount. And repeat. Often many times

Re: Archaic allocation in JCL (Was: Physical record size query)

On Mon, 13 Feb 2012 12:27:53 +0100, Thomas Berg wrote: >I can't understand why we STILL need to specify SPACE= (etc) for an allocation >of a dataset. >You normally don't do that in other OS (platforms), You always (both >principally and in practice) want to allocate as much as is needed during

SV: SV: Archaic allocation in JCL (Was: Physical record size query)

i 2012 14:49 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: SV: Archaic allocation in JCL (Was: Physical record size query) > > W dniu 2012-02-13 14:28, Thomas Berg pisze: > [...] > > With SPACE=ANY, the needed space is allocated and extended during the > execution. > > So You

Re: SV: Archaic allocation in JCL (Was: Physical record size query)

W dniu 2012-02-13 14:28, Thomas Berg pisze: [...] With SPACE=ANY, the needed space is allocated and extended during the execution. So You don't do any "preallocation" of a specified amount of space. Thomas, Your idea is worth discussion, but not your requirement is off target. It is not JCL pro

Re: Archaic allocation in JCL (Was: Physical record size query)

a.ua.edu] För > > > > Lizette Koehler > > > > Skickat: den 13 februari 2012 12:43 > > > > Till: IBM-MAIN@bama.ua.edu > > > > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > > > > > > > > > > > >

Re: Archaic allocation in JCL (Was: Physical record size query)

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg > Sent: Monday, February 13, 2012 7:26 AM > To: IBM-MAIN@bama.ua.edu > Subject: SV: Archaic allocation in JCL (Was: Physical record > size query) >

SV: Archaic allocation in JCL (Was: Physical record size query)

> -Ursprungligt meddelande- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För > Vernooij, CP - SPLXM > Skickat: den 13 februari 2012 14:22 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) > >

  1   2   >