subject:"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 of this and other pleas
to spare applications programmers--and often now sysprogs too--any
need to know what they are doing and how to do it.

I miss any sense of proportion.  We were never dealing here with an
arbitrary and cruel requirement that intellectually challenged Arsenal
footballers master Pali and Prakrit in order to consult their rule
books.   (Indeed, and to the point,  the three Arsenal footballers I
have known well were not intellectually challenged.)

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread McKown, John

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

 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? Most of our allocations are in MEGs. Doesn't 
 everyone do that 
 these days?

 SPACE=(1,(5,1),RLSE),AVGREC=MAllocate in MEGs

 -- 
 Edward E Jaffe

No. Our programmers allocate in CYLs. Why? I understand what a cylinder is. 
This megabyte stuff just doesn't make sense to me. Seems weird, but they will 
say that they don't know how many records are going to be in a file, or how big 
the record may be when it is variable in length. But they __do__ have an 
estimate of how many cylinders it needs to have allocated. HUH? Any more, with 
SMS, we have the normal DATACLAS have a DVC value of 59 (maximum). The person 
who was the storage administrator simply told the programmers to use a 
standard allocation value and let the system take care of extending the 
dataset on a volume, and onto more volumes. This works about 95% of the time 
here. The other 5% of the time, the programmer needs to use a really large 
value for their DEFINE of a VSAM KSDS. But we know what those datasets are and 
how big they need to be. We are a fairly static shop on the z side any more. 
The high level application designers are all Windows trained and d!
 on't even consider how to use z/OS to accomplish company goals. Their response 
to almost anything is z/OS can't do that. What they really mean is I don't 
know how to get z/OS to do that, and I don't intend to learn either. I know 
Windows and so Windows is the answer.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Steve Comstock


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 number of extents or
volumes.


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,
or millions of records, e.g.:

  SPACE=(440,(100,5),RLSE),AVGREG=M

allocate space for 100 million records of 440 bytes long.


Folks responsible for an application usually have some rough idea
of the number of records (right?) and they know the size of the
records. Records relate to something concrete (customers,
inventory, employees, etc.) whereas megabytes is more abstract.


But, hey, I live in the ivory tower.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Edward Jaffe


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,
or millions of records, e.g.:

  SPACE=(440,(100,5),RLSE),AVGREG=M

allocate space for 100 million records of 440 bytes long.


Like the folks in John McKown's shop, I have trouble dealing with space in terms 
of average record size and number of records. It seems overburdensome to have to 
worry about space at that level or detail. OTOH, I have no trouble at all 
knowing how many megabytes I'll need! :-)


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Scott Ford

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 AM, Steve Comstock st...@trainersfriend.com wrote:

 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 number of extents or
 volumes.
 
 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,
 or millions of records, e.g.:
 
  SPACE=(440,(100,5),RLSE),AVGREG=M
 
 allocate space for 100 million records of 440 bytes long.
 
 
 Folks responsible for an application usually have some rough idea
 of the number of records (right?) and they know the size of the
 records. Records relate to something concrete (customers,
 inventory, employees, etc.) whereas megabytes is more abstract.
 
 
 But, hey, I live in the ivory tower.
 
 -- 
 
 Kind regards,
 
 -Steve Comstock
 The Trainer's Friend, Inc.
 
 303-355-2752
 http://www.trainersfriend.com
 
 * To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment
 
 * Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Paul Gilmartin

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 transitions with a
mixture of DASD geometries in a shop, bytes or records would
have been the invariant metric of data set size, therefore the
most convenient.  Perhaps it was just bigotry, evident in the
characterization in the paragraph above: We're dinos; we don't
do megabytes!

But then there's volume capacity which, in megabytes, is not
invariant, even for a single volume of a single given model.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Scott Ford

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 paulgboul...@aim.com wrote:

 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 transitions with a
 mixture of DASD geometries in a shop, bytes or records would
 have been the invariant metric of data set size, therefore the
 most convenient.  Perhaps it was just bigotry, evident in the
 characterization in the paragraph above: We're dinos; we don't
 do megabytes!
 
 But then there's volume capacity which, in megabytes, is not
 invariant, even for a single volume of a single given model.
 
 -- gil
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Vernooij, CP - SPLXM

Paul Gilmartin paulgboul...@aim.com 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 cyls. As someone tod me new world orderlol
  
 I would have expected that during technology transitions with a
 mixture of DASD geometries in a shop, bytes or records would
 have been the invariant metric of data set size, therefore the
 most convenient.  Perhaps it was just bigotry, evident in the
 characterization in the paragraph above: We're dinos; we don't
 do megabytes!
 
 But then there's volume capacity which, in megabytes, is not
 invariant, even for a single volume of a single given model.
 
 -- gil

No, it is just the 'change' that prevented adoption. In spite of all the
pro's, it has one con: it is different from what we are used to. And
that is usually a big trhreshold.

I have seen this several times in the past: once we had a simple
homewritten change management system. Then we changed to Netman and
everybody complained about all its shortcommings and difficulties. Then
we changed to Paragrine and everybody complained about it and said how
much better Netman was.

We are/were used to trks and cyls and everything different is worse
until proven otherwise.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Mark Zelden

On Thu, 16 Feb 2012 23:57:44 -0800, Edward Jaffe edja...@phoenixsoftware.com 
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 number of extents or
 volumes.

TRKs and CYLs? Most of our allocations are in MEGs. Doesn't everyone do that
these days?

SPACE=(1,(5,1),RLSE),AVGREC=MAllocate in MEGs


Not that I've seen.  A good portion of production JCL just uses a dataclas for 
various allocation 
amounts / defaults like MB100E  (100MB, extended format).But most 
production and 
almost all end user JCL (including sysprogs like myself) still use CYL.
Maybe because I
just copy other JCL to start with, and I guess I can just picture the amount 
it 
represents in my head.

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 have been doing with with 
CYL for
my entire MF career.   On a slightly larger scale, so what if I allocated in M 
and ended up with
710 CYL instead of 500 CYL.  (typical for me to use (500,500) for large-ish 
allocations).

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Paul Gilmartin

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 have been doing with with 
CYL for
my entire MF career.   On a slightly larger scale, so what if I allocated in M 
and ended up with
710 CYL instead of 500 CYL.  (typical for me to use (500,500) for large-ish 
allocations).
 
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, and be suitable for any future DASD.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Paul Gilmartin's:

begin snippet
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, and be suitable for any future DASD.
/end snippet

is not really wrongheaded.  It is an unfortunate oversimplification
for real DASD.  For them BLKSIZE= values could not be ignored.  If
they were in moving, for example, from 3350s to 3390s, it was
possible, indeed easy, to waste 30+ percent of the new devices'
capacity.

As I have already had occasion to note today, accurate DASD-capacity
calculations parametric in block are not difficult.  They require no
mastery of---choose the dubious metaphor you find more
congenial---either brain surgery or rocket science.  Dubious
approximations, on the other hand, always gave/give trouble.

On 2/17/12, Paul Gilmartin paulgboul...@aim.com wrote:
 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 have been doing with
 with CYL for
my entire MF career.   On a slightly larger scale, so what if I allocated
 in M and ended up with
710 CYL instead of 500 CYL.  (typical for me to use (500,500) for
 large-ish allocations).

 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, and be suitable for any future DASD.

 -- gil

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Mike Schwab

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?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

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 for a year.  We are 
a brand new bank that has not yet processed any transactions.  How many 
megabytes should I define my transaction file?

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.

Frank





 From: Edward Jaffe edja...@phoenixsoftware.com
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:

 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,
 or millions of records, e.g.:

   SPACE=(440,(100,5),RLSE),AVGREG=M

 allocate space for 100 million records of 440 bytes long.

Like the folks in John McKown's shop, I have trouble dealing with space in 
terms 
of average record size and number of records. It seems overburdensome to have 
to 
worry about space at that level or detail. OTOH, I have no trouble at all 
knowing how many megabytes I'll need! :-)

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Variable length records?

 From: Scott Ford scott_j_f...@yahoo.com
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 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 paulgboul...@aim.com wrote:

 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 transitions with a
 mixture of DASD geometries in a shop, bytes or records would
 have been the invariant metric of data set size, therefore the
 most convenient.  Perhaps it was just bigotry, evident in the
 characterization in the paragraph above: We're dinos; we don't
 do megabytes!

 But then there's volume capacity which, in megabytes, is not
 invariant, even for a single volume of a single given model.

 -- gil

 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Paul Gilmartin

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 for a year.  We 
are a brand new bank that has not yet processed any transactions.  How many 
megabytes should I define my transaction file?

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.

Well, that's because you're posing the question in them PFCSK megabytes.
If you'd just think in cylinders like a good mainframer is supposed to, it would
be simple.

--- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 paulgboul...@aim.com
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 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 for a year.  We 
are a brand new bank that has not yet processed any transactions.  How many 
megabytes should I define my transaction file?

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.

Well, that's because you're posing the question in them PFCSK megabytes.
If you'd just think in cylinders like a good mainframer is supposed to, it 
would
be simple.

--- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Frank Swabrick wrote:

begin snippet
| 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.
/end snippet

The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

But who has the responsibility?  This seems something that a system programmer, 
with some good analysis tools, should do.  Or the system itself should be such 
that it can do it's own analysis.  After all, is that not what computers are 
for?

Frank





 From: John Gilmore johnwgilmore0...@gmail.com
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:

begin snippet
| 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.
/end snippet

The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Frank,

Your point is well taken.  Often no one has the responsibility.

Still, while the system cannot analyze itself, it can include
data-collection machinery that greatly facilitates such analyses; and
this machinery is/should be the responsibility of those who design and
 maintain a system

--jg

On 2/17/12, Frank Swarbrick frank.swarbr...@yahoo.com wrote:
 But who has the responsibility?  This seems something that a system
 programmer, with some good analysis tools, should do.  Or the system itself
 should be such that it can do it's own analysis.  After all, is that not
 what computers are for?

 Frank





 From: John Gilmore johnwgilmore0...@gmail.com
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:

begin snippet
| 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.
/end snippet

The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Shmuel Metz (Seymour J.)

In 0987218410888335.wa.paulgboulderaim@bama.ua.edu, on
02/17/2012
   at 11:02 AM, Paul Gilmartin paulgboul...@aim.com 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. Possibly that would have been a
good thing.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Shmuel Metz (Seymour J.)

In
CAPD5F5rThXaYbF32YgQMXK0bWTtXELh3X+XMOaUnKwPv=tt...@mail.gmail.com,
on 02/17/2012
   at 12:50 PM, John Gilmore johnwgilmore0...@gmail.com 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 too common.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-17 Thread Ed Gould

The analyst has to have the numbers for it is he(she) that is  
designing the system.

He is supposed to be the giver of the grail.
The real issue is which analyst. There are several different types  
business, system and a few others.

The delineation is supposed to be the job description.
The real problem is who's pervue does it come under if it is no one.

Ed

On Feb 17, 2012, at 7:03 PM, Frank Swarbrick wrote:

But who has the responsibility?  This seems something that a system  
programmer, with some good analysis tools, should do.  Or the  
system itself should be such that it can do it's own analysis.   
After all, is that not what computers are for?


Frank






From: John Gilmore johnwgilmore0...@gmail.com
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:

begin snippet
| 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.
/end snippet

The question itself has not been very well formulated.

No one, I hope and suppose, sizes files directly in cylinders, tracks
or megabytes.  These are derived quantities.  One begins with record
types, their individual sizes, and their expected volumes/counts.

Initially one has only estimates, often poor ones, of
transaction/processing volumes, but these estimates can be improved
incrementally by collecting statistics of the volumes actually
experienced during processing and then analyzing these data..

That this is not much done does not been that it cannot or should not
be done.

Adequate capacity planning and even many design decisions are
impossible without the systematic collection and analysis of such
information.

John Gilmore, Ashland, MA 01721 - USA

- 
-

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-16 Thread Edward Jaffe


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? Most of our allocations are in MEGs. Doesn't everyone do that 
these days?


SPACE=(1,(5,1),RLSE),AVGREC=MAllocate in MEGs

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-15 Thread Gibney, Dave

  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 take 
generous pools and a somewhat aggressive DFHSM migration policy with low 
thresholds. 
 
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 ?
 Or do You envision DATACLAS/STORCLAS's with very generous SPACE
 allocations (for every allocation) ?
 
 
 
 Regards,
 Thomas Berg
 _
 Thomas Berg   Specialist   A M   SWEDBANK
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions, send
 email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-15 Thread Ron Hawkins

Thomas,

I don't believe this is true. There are files systems that require
pre-allocation of space. 

In fact the use of a raw LUN is predefined space by definition. If you spent
some setting up arrays for large Open Systems servers where they want 120
different LUN sizes you see the similarity.

The PC disk NTFS model is not a valid comparison with a z/OS file system. Go
and look at a couple of 100TBs of squatty box storage like you have in z/OS.
Pre-allocated space in LUN units is rife through Open Systems - as is a
significant amount of wasted free space :-(

Oh, and automatic extension of a file from one LUN to another for 59 LUNS is
a foreign concept in Open Systems File systems. They're still wishing for
one. They have to go through a Dynamic LUN Expansion process to manage that
one - always fun at 3 in the morning.

Ron

 -Original Message-
 From: 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 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
 execution
 
 If for backward compatibility it can't be done automatically, why not
 introduce a new keyword like e g SPACE=ANY ?
 
 
 
 Regards,
 Thomas Berg
 _
 Thomas Berg   Specialist   A M   SWEDBANK
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions, send email
to
 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Thomas Berg

 -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)
 
  -Original Message-
  From: IBM Mainframe Discussion 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: 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.ua.edu
   Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
  
   
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 execution
   
If for backward compatibility it can't be done automatically, why
 not
   introduce a new
keyword like e g SPACE=ANY ?
   
   
  
   Thomas,
  
   IIRC - if you force a DATACLAS on a dataset in SMS, you can specify
 the
   Space requirements there.  Then the JCL does not require Space.  Have
 you
   looked at that?  However, then that makes your storage admin
 responsible
   for
   ensuring the space is enough.  And if needed alter the dataclass if
 there
   are space issues.  And it would require all such datasets be SMS
 managed.
  
  
   Lizette
 
  Hi Lizette,
 
  In practice it's not a viable alternative. Besides the need (if doing it
 that way)
  to communicate frequently with the space gang, it's to many variants
 of
  datasetnames and to many different needs for space depending on time,
  date and subgrouping within applications.
 
 
 
   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 ?
Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations 
(for every allocation) ?  


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Vernooij, CP - SPLXM

Paul Gilmartin paulgboul...@aim.com 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
 (since version 6 AFAIR).
 It would be nice to have such facility in DATACLASS.
  
 Nice indeed.  And someone else suggested DB2 as another good
 performer.
 
 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 allocation where all
applications
 could take advantage of it.  All this could have been done without
 changing the specification of the VTOC and DSCB nor making
incompatible
 changes to them.
 
 Conway's Law.
 
 -- gil

There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If
the DB2 lab needs something or has a good idea and the z/OS lab is not
willing to implement it, the DB2 lab implements it itself (assuming they
at least talk to each other).

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Lizette Koehler

 
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 ?
 Or do You envision DATACLAS/STORCLAS's with very generous SPACE
allocations (for
 every allocation) ?
 
 
 
 Regards,
 Thomas Berg

So the question becomes where to define space?  The system cannot think
like a human.  It usually needs a place to start.  So IBM provided some
solutions.

The LIKE parm in JCL
The SMS DataClas functions
The JCL SPACE parm

I think it was amazing that IBM was able to eliminate the need for
DCB=(x) and just let us use the subparms.  

For SPACE you are looking at old code that needs to be altered in CONVERTER,
JES, ALLOCATION, IOS and probably more.  It is old code and not likely to
change in our lifetimes.  I am also sure that if the developers in the 60's
and 70's had any clue where computing was going, they might have thought
harder on their designs.  Remember when this was evolving we had
restrictions that needed to be spelled out to the operating system.
Therefore, this process (Space Allocation) needed to be definitely set.
Remember, this came to us from MFT, MVT, SVS, and then MVS.  And developers
had to know what they were using and conserve the space usage.  Everything
was expensive back then.

Instead maybe you need to look at a homegrown process that generates your
JCL using META Data.  Then if you have space problems, you can adapt your
META Data or use products like SRS (DTS Software) or BMC Mainview SRM to
monitor and dynamically grow or shrink a file as needed.  Wait - we are back
to your issue.  Having to monitor and change something for space issues.
That is where products like SRS and SRM are helpful.  They monitor your
system and if a space issue is about to happen, dynamically change the data
allocations on the fly.  Remember the old STOPX37?  But, you also have
issues because now you need to monitor the monitors and adjust them as space
issues arise.  Seems to me to be an infinite loop.  Not one with a solution
with today's tools.

The issue of space is one of limitation of DASD space.  If you have infinite
storage, then over allocate everything in a Dataclass and not worry.  If you
have a constricted dasd environment, then keeping tight allocations will
lead to space issues.  So what do you want to manage - JCL or SMS code?

Most shops review their allocations periodically and adjust their process.
Either through SMS Dataclas or JCL.  I know most shop would love to have a
human thinking universe, however the computer is still fairly rudimentary.
No Star Trek environment yet.  ;-D

If you truly want to see this type of issue resolved, then perhaps a SHARE
requirement or Change request to IBM would be more effective?

Just my $0.02 worth.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Thomas Berg

 -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)
 
  
 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 ?
  Or do You envision DATACLAS/STORCLAS's with very generous SPACE
 allocations (for
  every allocation) ?
 
 
 
  Regards,
  Thomas Berg
 
 So the question becomes where to define space?  The system cannot think
 like a human.  It usually needs a place to start.  So IBM provided some
 solutions.

Please!  Requirement of space do not need any thinking.  It answers itself 
during the execution.  

 The LIKE parm in JCL

If You have and remember the appropriate dataset.  And this is not much better 
than using SPACE=.

 The SMS DataClas functions

Se my post above.

 The JCL SPACE parm 

Which caused my choice of subject: Archaic...

 I think it was amazing that IBM was able to eliminate the need for
 DCB=(x) and just let us use the subparms.
 
 For SPACE you are looking at old code that needs to be altered in
 CONVERTER,
 JES, ALLOCATION, IOS and probably more.  It is old code and not likely to
 change in our lifetimes.  

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.  This could obviously be done.
- There can't be that many places that does the allocation of the space on 
disk. 
Note that there is no change of cataloging as such, just the process of 
adding/extending the 
extents as the dataset is expanding.  There is no need to change the old code 
more than 
allowing a branch to the new code to handle the case of the new variant of 
the SPACE parm.  

snip

 Wait - we are back
 to your issue.  Having to monitor and change something for space issues.
 That is where products like SRS and SRM are helpful.  They monitor your
 system and if a space issue is about to happen, dynamically change the
 data allocations on the fly.  Remember the old STOPX37?  But, you also have
 issues because now you need to monitor the monitors and adjust them as
 space issues arise.  

Here we are back to how we look at the space allocation process.  You seems to 
see it 
as a complicated process - or at least an intellectually demanding logic.
For me it's something I can do in my sleep.  (It's just a loop of changing the 
SPACE parms 
until it works = no B37 etc.)
How could this be other that a VSMOP ?

snip

 If you truly want to see this type of issue resolved, then perhaps a SHARE
 requirement or Change request to IBM would be more effective?

Well, with more effective You seem to assume that I'm trying to get something 
realized.  But this 
was/begun as an opinion from me to the ongoing discussions in this list 
regarding enhancements 
of MVS. 

For a realization of something like this and as working in a Swedish company 
(which AFAIK 
is not a SHARE member) I have to rely on other participants on this list that 
are SHARE members. 
(A request by me to IBM needs accompanying money...) 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Paul Gilmartin

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, and BLKSIZE
with PATH=, but prohibit other subparameters.  There was no
mechanism to make one parameter mutex with a subparameter
of a different parameter, and it was easier to allow the bare
attributes than to devise the needed mutex.

Or does the chronology and other evidence refute this?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Paul Gilmartin

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 allocation where all
applications
 could take advantage of it.  All this could have been done without
 changing the specification of the VTOC and DSCB nor making
incompatible
 changes to them.

 Conway's Law.

There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If
the DB2 lab needs something or has a good idea and the z/OS lab is not
willing to implement it, the DB2 lab implements it itself (assuming they
at least talk to each other).
 
That's a close paraphrase of my surmise of Conway's Law.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Gerhard Postpischil


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.  This could obviously be done.
-  There can't be that many places that does the allocation of the space on 
disk.
Note that there is no change of cataloging as such, just the process of 
adding/extending the
extents as the dataset is expanding.  There is no need to change the old code 
more than
allowing a branch to the new code to handle the case of the new variant of 
the SPACE parm.


You may think of your request as being reasonable, but a new 
SPACE parameter could be added in less time than this thread has 
been going. There is no one place where old code can be branched 
away from, rather space/extent processing is endemic in all DASD 
related code. More critically, most I/O related control blocks 
have physical limits, and would require major redesign to handle 
even static expansion, not to mention dynamic. By comparison, 
supporting FBA devices in zOS would have been trivial, but IBM 
could not justify that, either.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-14 Thread Ron Hawkins

Thomas,

I've done this with DFSMS for a large, multi-country application where the
developers simply coded UNIT=SMALL, MEDIUM, LARGE and HUGE in the JCL.

The ACS routines took this UNIT value, along with some other logic and
assigned a standard space allocation using the appropriate DATACLAS.

The size for each DATACLAS was different for the DEV, UNIT and PROD
environments, which allowed them to use the same JCL for these different
environments.

We did protect successful allocation with UNITCNT=5 and some ACC.

Ron


 -Original Message-
 From: IBM Mainframe Discussion 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-
  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.ua.edu
  Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
 
  
   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 execution
  
   If for backward compatibility it can't be done automatically, why
   not
  introduce a new
   keyword like e g SPACE=ANY ?
  
  
 
  Thomas,
 
  IIRC - if you force a DATACLAS on a dataset in SMS, you can specify
  the Space requirements there.  Then the JCL does not require Space.
  Have you looked at that?  However, then that makes your storage admin
  responsible for ensuring the space is enough.  And if needed alter the
  dataclass if there are space issues.  And it would require all such
  datasets be SMS managed.
 
 
  Lizette
 
 Hi Lizette,
 
 In practice it's not a viable alternative. Besides the need (if doing it
that
 way) to communicate frequently with the space gang, it's to many
variants of
 datasetnames and to many different needs for space depending on time, date
and
 subgrouping within applications.
 
 
 
 Regards,
 Thomas Berg
 _
 Thomas Berg   Specialist   A M   SWEDBANK
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions, send email
to
 lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

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 
execution 

If for backward compatibility it can't be done automatically, why not introduce 
a new keyword like e g SPACE=ANY ? 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Lizette Koehler

 
 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 execution
 
 If for backward compatibility it can't be done automatically, why not
introduce a new
 keyword like e g SPACE=ANY ?
 
 

Thomas,

IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the
Space requirements there.  Then the JCL does not require Space.  Have you
looked at that?  However, then that makes your storage admin responsible for
ensuring the space is enough.  And if needed alter the dataclass if there
are space issues.  And it would require all such datasets be SMS managed.


Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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.ua.edu
 Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
 
 
  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 execution
 
  If for backward compatibility it can't be done automatically, why not
 introduce a new
  keyword like e g SPACE=ANY ?
 
 
 
 Thomas,
 
 IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the
 Space requirements there.  Then the JCL does not require Space.  Have you
 looked at that?  However, then that makes your storage admin responsible
 for
 ensuring the space is enough.  And if needed alter the dataclass if there
 are space issues.  And it would require all such datasets be SMS managed.
 
 
 Lizette

Hi Lizette,

In practice it's not a viable alternative. Besides the need (if doing it that 
way) to communicate frequently with the space gang, it's to many variants of 
datasetnames and to many different needs for space depending on time, date and 
subgrouping within applications. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread McKown, John

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.

SPACE=WHAT,ME_WORRY?

SPACE=I-CANT-BE-BOTHERED-TO-SIZE-THIS-PROPERLY-AND-MY-PROGRAMS-NEVER-LOOP-EXCESSIVELY

In many other systems, such as Winblows, everybody gets their own personal
space. And if it is used up, it doesn't impact others. z/OS shares DASD
space. So one bad apple can cause a major problem. Hopefully not in production.
But what about for temp space? I've had production jobs go down due to no
space on the work packs due to a nitwit coding up a job with 30 SORTWKnn DD
statements, with SPACE=(CYL,(2000,100)). Because they kept getting SORT
CAPACITY EXCEEDED and just wanted the elided job to run. This was in
internal COBOL sort, so dynamic SORTWORK was not possible. IIRC, the problem
was their program outputting about 30 million records (a bug).

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone .
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets® is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA
Life and Health Insurance Company.SM

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

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 execution

If for backward compatibility it can't be done automatically,
why not introduce a new keyword like e g SPACE=ANY ?

Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Thomas Berg thomas.b...@swedbank.se wrote in message 
news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se...
  -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.ua.edu
  Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
  
  
   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 execution
  
   If for backward compatibility it can't be done automatically, why not
  introduce a new
   keyword like e g SPACE=ANY ?
  
  
  
  Thomas,
  
  IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the
  Space requirements there.  Then the JCL does not require Space.  Have you
  looked at that?  However, then that makes your storage admin responsible
  for
  ensuring the space is enough.  And if needed alter the dataclass if there
  are space issues.  And it would require all such datasets be SMS managed.
  
  
  Lizette
 
 Hi Lizette,
 
 In practice it's not a viable alternative. Besides the need (if doing it that 
 way) to communicate frequently with the space gang, it's to many variants 
 of datasetnames and to many different needs for space depending on time, date 
 and subgrouping within applications. 
 
 
  
 Regards, 
 Thomas Berg 

Now I don't understand: if you have so many different space needs, how do you 
assume 'SPACE=ANY' to solve this?

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

My variant is faster to write!  ;)

(BTW, with my idea only needed space is allocated, there is no unused 
preallocated space.)


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 


 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
 McKown, John
 Skickat: den 13 februari 2012 14:21
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
 
 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.
 
 Or
 
 SPACE=WHAT,ME_WORRY?
 
 Or
 
 SPACE=I-CANT-BE-BOTHERED-TO-SIZE-THIS-PROPERLY-AND-MY-PROGRAMS-NEVER-LOOP-
 EXCESSIVELY
 
 In many other systems, such as Winblows, everybody gets their own personal
 space. And if it is used up, it doesn't impact others. z/OS shares
 DASD space. So one bad apple can cause a major problem. Hopefully not in
 production. But what about for temp space? I've had production jobs go
 down due to no space on the work packs due to a nitwit coding up a job
 with 30 SORTWKnn DD statements, with SPACE=(CYL,(2000,100)). Because they
 kept getting SORT CAPACITY EXCEEDED and just wanted the elided job to
 run. This was in internal COBOL sort, so dynamic SORTWORK was not
 possible. IIRC, the problem was their program outputting about 30 million
 records (a bug).
 
 --
 John McKown
 Systems Engineer IV
 IT
 
 Administrative Services Group
 
 HealthMarkets®
 
 9151 Boulevard 26 . N. Richland Hills . TX 76010
 (817) 255-3225 phone .
 john.mck...@healthmarkets.com . www.HealthMarkets.com
 
 Confidentiality Notice: This e-mail message may contain confidential or
 proprietary information. If you are not the intended recipient, please
 contact the sender by reply e-mail and destroy all copies of the original
 message. HealthMarkets® is the brand name for products underwritten and
 issued by the insurance subsidiaries of HealthMarkets, Inc. -The
 Chesapeake Life Insurance Company®, Mid-West National Life Insurance
 Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
 
 
 
  -Original Message-
  From: IBM Mainframe Discussion List
  [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
  Sent: Monday, February 13, 2012 5:28 AM
  To: IBM-MAIN@bama.ua.edu
  Subject: Archaic allocation in JCL (Was: Physical record size query)
 
  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 execution
 
  If for backward compatibility it can't be done automatically,
  why not introduce a new keyword like e g SPACE=ANY ?
 
 
 
  Regards,
  Thomas Berg
  _
  Thomas Berg   Specialist   A M   SWEDBANK
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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)
 
 Thomas Berg thomas.b...@swedbank.se wrote in message
 news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.
 se...
   -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.ua.edu
   Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
  
   
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 execution
   
If for backward compatibility it can't be done automatically, why
 not
   introduce a new
keyword like e g SPACE=ANY ?
   
   
  
   Thomas,
  
   IIRC - if you force a DATACLAS on a dataset in SMS, you can specify
 the
   Space requirements there.  Then the JCL does not require Space.  Have
 you
   looked at that?  However, then that makes your storage admin
 responsible
   for
   ensuring the space is enough.  And if needed alter the dataclass if
 there
   are space issues.  And it would require all such datasets be SMS
 managed.
  
  
   Lizette
 
  Hi Lizette,
 
  In practice it's not a viable alternative. Besides the need (if doing it
 that way) to communicate frequently with the space gang, it's to many
 variants of datasetnames and to many different needs for space depending
 on time, date and subgrouping within applications.
 
 
 
  Regards,
  Thomas Berg
 
 Now I don't understand: if you have so many different space needs, how do
 you assume 'SPACE=ANY' to solve this?

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. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread McKown, John

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

 My variant is faster to write!  ;)

 (BTW, with my idea only needed space is allocated, there is 
 no unused preallocated space.)

 Regards, 
 Thomas Berg 
 _ 
 Thomas Berg   Specialist   A M   SWEDBANK 

What, IMO, would be nicer to implement your idea would be a SPACE parameter 
which is more a LIMIT type parameter. If we could do away with extent limits 
and volume count limits, then DASD allocation could be done more on a on 
demand, cylinder at a time, philosophy. Kind of like how UNIX allocates DASD 
space, but with with some sort of quota to stop a looping program from using 
up all the space.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Thomas Berg thomas.b...@swedbank.se wrote in message 
news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se...
  -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)
  
  Thomas Berg thomas.b...@swedbank.se wrote in message
  news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.
  se...
-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.ua.edu
Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
   

 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 execution

 If for backward compatibility it can't be done automatically, why
  not
introduce a new
 keyword like e g SPACE=ANY ?


   
Thomas,
   
IIRC - if you force a DATACLAS on a dataset in SMS, you can specify
  the
Space requirements there.  Then the JCL does not require Space.  Have
  you
looked at that?  However, then that makes your storage admin
  responsible
for
ensuring the space is enough.  And if needed alter the dataclass if
  there
are space issues.  And it would require all such datasets be SMS
  managed.
   
   
Lizette
  
   Hi Lizette,
  
   In practice it's not a viable alternative. Besides the need (if doing it
  that way) to communicate frequently with the space gang, it's to many
  variants of datasetnames and to many different needs for space depending
  on time, date and subgrouping within applications.
  
  
  
   Regards,
   Thomas Berg
  
  Now I don't understand: if you have so many different space needs, how do
  you assume 'SPACE=ANY' to solve this?
 
 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. 
 
 
  
 Regards, 
 Thomas Berg 

Consider how that is to be administrated during the execution of a job: if you 
do it like PCs, your dasd is formatted in small fixed chunks of space and each 
time you need more, you take another chunk. Suppose a chunk is 1 track: when a 
dataset is being filled, it will create hundreds/thousands/millions of chunks. 
This requires a completely new administration in DCB/DEB's and in VTOC DSCBs. 
Or do you introduce a new file- and diskformat: FAT/NTFS/ZFS(oh no, this 
exists),ZOSFS? On the same disks or on newly formatted disks? It brings a 
truckload of consequences to implement.

A simple variant would be: assign a default Dataclas, with a large amount of 
space, enough for 90% of your needs and release overallocated space at Close. 
This can all now already be done simply with Dataclass and Managementclass.

Kees.


Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

BTW: Idea of space extents is maybe archaic, but I wouldn't consider it
worse. It's different and reruires different approach and tools.

(*) Cluster - in this case the smallest addressable amount of disk
storage. For 3390-3 it would be 1 trk, for NTFS disk in my PC it would
be 4kB, for old FAT format of 2GB partition it was 32kB, for EAS on EAV
device it is 21 CYL.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

(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. 
Would it be a problem if this (more or less) is automated ?  Hm ?

Technically I suppose it's solved by an initial virtual allocation filling a 
buffer in memory.
Then a disk allocation is done at a threshold with e g 5 cyl.
If that is not enough, add 4 times the amount, 20 cyl.
Repeat this until finish.  
Release unused space (from the last add). 

This is just an example, it can be done much more sophisticated by the OS. 

And the limit of allocation should be set by userid or datasetname properly.  
Or maybe by a (e g) LIMIT= keyword.

(I'm using the JCL case as an illustrative example, it should of course be 
general system interface.)


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S.
 Skickat: den 13 februari 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 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 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.
 
 BTW: Idea of space extents is maybe archaic, but I wouldn't consider it
 worse. It's different and reruires different approach and tools.
 
 
 (*) Cluster - in this case the smallest addressable amount of disk
 storage. For 3390-3 it would be 1 trk, for NTFS disk in my PC it would
 be 4kB, for old FAT format of 2GB partition it was 32kB, for EAS on EAV
 device it is 21 CYL.
 --
 Radoslaw Skorupka
 Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 
execution
 
Can you use UNIX files (zFS) for your purposes and avoid the archaism?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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.
Would it be a problem if this (more or less) is automated ? Hm ?

Technically I suppose it's solved by an initial virtual allocation filling a
buffer in memory.
Then a disk allocation is done at a threshold with e g 5 cyl.
If that is not enough, add 4 times the amount, 20 cyl.
Repeat this until finish.
Release unused space (from the last add).

This is just an example, it can be done much more sophisticated by the OS.

And the limit of allocation should be set by userid or datasetname properly.
Or maybe by a (e g) LIMIT= keyword.

(I'm using the JCL case as an illustrative example, it should of course be
general system interface.)

Actually space abends in my environment are very very rare. Time and
experience were needed to go there, but the experience + SMS facilities
+ DFSMShsm causes x37 abends almost non-existent.

As I said, z/OS storage requires different approach. On Windows system
programmer opens the file and writes to it. On z/OS he has to answer the
question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be
vry imprecise, but it is required.

Could it be better? I think so. What about unlimited number of extents?
Or at least, let's say, 3000 per volume? What about multi-volume
PDS(E)s? What about FBA disks?

WAKE UP!
;-)

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 
space. And if it is used up, it doesn't impact others. z/OS shares DASD 
space.  ...
 
The z/OS cultural norm for HFS and zFS is to give each user a
dedicated filesystem for HOME.  This is similar to the behavior
of personal instances of those other systems.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 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
 execution
 
 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. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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.
 
What I'd like to see as a less revolutioary implementation of
SPACE=ANY is:

o Primary allocation: one cluster.

o Succeeding allocations are successive Fibonacci numbers
  (arbitrary design choice) of clusters.

Since extents are not now constrained to be equal in size, this
would be a relatively local change in allocation.  Since (in some
cases) a data set may have up to 123 extents, this would
support a maximum data set size of up to 1.6 ^ 122 clusters,
hardly a practical limit.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Chris Craddock

On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 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 space. And if it is used up, it doesn't impact others. z/OS
 shares DASD space.  ...
 
 The z/OS cultural norm for HFS and zFS is to give each user a
 dedicated filesystem for HOME.  This is similar to the behavior
 of personal instances of those other systems.



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. There's no reason
z/OS couldn't do the same other than slavish adherence to legacy. IMHO it
is about time the system itself took care answering its own incessant how
big?, how many?, how often? questions. It's 2012 ferpetesakes. I'm all
in favor of making sure that existing applications continue to work. I am
far less impressed with continuing to impose 1960s thinking on new ones.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 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.
  Would it be a problem if this (more or less) is automated ?  Hm ?
 
  Technically I suppose it's solved by an initial virtual allocation
 filling a buffer in memory.
  Then a disk allocation is done at a threshold with e g 5 cyl.
  If that is not enough, add 4 times the amount, 20 cyl.
  Repeat this until finish.
  Release unused space (from the last add).
 
  This is just an example, it can be done much more sophisticated by the
 OS.
 
  And the limit of allocation should be set by userid or datasetname
 properly.  Or maybe by a (e g) LIMIT= keyword.
 
  (I'm using the JCL case as an illustrative example, it should of course
 be general system interface.)
 
 
 Actually space abends in my environment are very very rare. Time and
 experience were needed to go there, but the experience + SMS facilities
 + DFSMShsm causes x37 abends almost non-existent.
 
 As I said, z/OS storage requires different approach. On Windows system
 programmer opens the file and writes to it. On z/OS he has to answer the
 question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be
 vry imprecise, but it is required.
 
 Could it be better? I think so. What about unlimited number of extents?
 Or at least, let's say, 3000 per volume? What about multi-volume
 PDS(E)s? What about FBA disks?
 WAKE UP!
 ;-)

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. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 



 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 (*). That
requires total VTOC revolution.

What I'd like to see as a less revolutioary implementation of
SPACE=ANY is:

o Primary allocation: one cluster.

o Succeeding allocations are successive Fibonacci numbers
(arbitrary design choice) of clusters.

Since extents are not now constrained to be equal in size, this
would be a relatively local change in allocation. Since (in some
cases) a data set may have up to 123 extents, this would
support a maximum data set size of up to 1.6 ^ 122 clusters,
hardly a practical limit.

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.
However using DVC and 123 ext/vol and space constraint relief + reduce
allocation is not bad also.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Mark Jacobs


On 02/13/12 10:20, Thomas Berg wrote:
snip


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.


  
Regards,

Thomas Berg
_
Thomas Berg   Specialist   A M   SWEDBANK


   
TANSTAAFL. Whether we like it or not economics is a fact of life, 
everything can't be unlimited. There are always costs involved both for 
widgets and for the management of said widgets.


--
Mark Jacobs
Time Customer Service
Tampa, FL


Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning.

- Albert Einstein

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 Winblows, everybody gets their own personal space. And
if it is used up, it doesn't impact others. z/OS shares DASD space. ...

The z/OS cultural norm for HFS and zFS is to give each user a
dedicated filesystem for HOME. This is similar to the behavior
of personal instances of those other systems.

I don't use this cultural norm for HFS, I have never met such norm in
Unix world and I don't understand such norm.
However having common HFS for *group* of users and - if needed -
dedicated HFSes for justified exceptions - sounds much better.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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. appears to understand the design constraints), and you discard
it and get a new one with more satisfactory design, I don't see why you
see that as a circumvention as opposed to a solution.

Suppose z/OS were to provide an entirely new DSORG that met your
requirement of SPACE=ANY.  Would you see that also as a
circumvention?

Tne customers' perennial but impossible demand: Make it work, but
don't change anything!  E.g.: allow volumes larger than 54 GB,
but don't change the 3390 geometry!

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

Thomas Berg thomas.b...@swedbank.se wrote in message 
news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se...
  -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 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.
   Would it be a problem if this (more or less) is automated ?  Hm ?
  
   Technically I suppose it's solved by an initial virtual allocation
  filling a buffer in memory.
   Then a disk allocation is done at a threshold with e g 5 cyl.
   If that is not enough, add 4 times the amount, 20 cyl.
   Repeat this until finish.
   Release unused space (from the last add).
  
   This is just an example, it can be done much more sophisticated by the
  OS.
  
   And the limit of allocation should be set by userid or datasetname
  properly.  Or maybe by a (e g) LIMIT= keyword.
  
   (I'm using the JCL case as an illustrative example, it should of course
  be general system interface.)
  
  
  Actually space abends in my environment are very very rare. Time and
  experience were needed to go there, but the experience + SMS facilities
  + DFSMShsm causes x37 abends almost non-existent.
  
  As I said, z/OS storage requires different approach. On Windows system
  programmer opens the file and writes to it. On z/OS he has to answer the
  question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be
  vry imprecise, but it is required.
  
  Could it be better? I think so. What about unlimited number of extents?
  Or at least, let's say, 3000 per volume? What about multi-volume
  PDS(E)s? What about FBA disks?
  WAKE UP!
  ;-)
 
 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. 
 
 
  
 Regards, 
 Thomas Berg 

This is a huge conversion.

There was a good point in your previous suggestion and in Gill's: take a 
primary allocation and add ever larger secondaries. With multivolume datasets, 
you can have a lot of extents and consequently a lot of space, all without 
having to change the current limits in the Dasd architecture. 

It only requires a new Space Constraint Releave algorithme.

This is what DB2 does nowadays. Our DB2 administrators converted to this 
(-1,-1) allocation a year ago and happily saw problems with mis/underallocated 
space amounts disappear completely and we gained back a lot of unnecessarily 
overallocated space from the former way of database space allocation. The knife 
cuts on both sides this way.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Mike Schwab

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 crashlu...@gmail.com wrote:
On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin paulgboul...@aim.comwrote:

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 space. And if it is used up, it doesn't impact others. z/OS
shares DASD space. ...

The z/OS cultural norm for HFS and zFS is to give each user a
dedicated filesystem for HOME. This is similar to the behavior
of personal instances of those other systems.

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. There's no reason
z/OS couldn't do the same other than slavish adherence to legacy. IMHO it
is about time the system itself took care answering its own incessant how
big?, how many?, how often? questions. It's 2012 ferpetesakes. I'm all
in favor of making sure that existing applications continue to work. I am
far less impressed with continuing to impose 1960s thinking on new ones.
--
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 optimum extent size that gives you the maximum space for
a dataset and it is depending on the amount of filling of the storage group,
the concurrent allocations in the storage group, the moment and amount of dasd
cleanup, the outside temperature and the mood of programmers.

YMMV is very appropriate here.

Kees.

Mike Schwab mike.a.sch...@gmail.com wrote in message
news:CAJTOO59sE28iM+pw5Zp53XoWGyDGVhSpTdBkQf=mcxu64w0...@mail.gmail.com...
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 crashlu...@gmail.com wrote:
On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin paulgboul...@aim.comwrote:

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 space. And if it is used up, it doesn't impact others. z/OS
shares DASD space. ...

The z/OS cultural norm for HFS and zFS is to give each user a
dedicated filesystem for HOME. This is similar to the behavior
of personal instances of those other systems.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread McKown, John

Yes, I do this too. $HOME is managed by automount. So I don't even need to 
preallocate the filesystem. In addition, I have a /tmp2 subdirectory. It is 
like $HOME in that it is managed by automount. In /etc/profile, I make $TMP, 
$TEMP, $TMPDIR, et al., all have a value of /tmp2/$LOGNAME and mark them 
READONLY. Most UNIX utilities use one of these environment variables for 
allocating temporary files. And so every user ends up with a unique temporary 
file space as well a as unique HOME. This doesn't stop people from using /tmp 
and I don't try. But I do tell them how to get temporary space that is not 
going to be exhaused by someone else.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:IBM-MAIN@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 programmers at our shop would do:
 
 SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-B
 ECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT.
 
 In many other systems, such as Winblows, everybody gets 
 their own personal space. And if it is used up, it 
 doesn't impact others. z/OS shares DASD space.  ...
  
 The z/OS cultural norm for HFS and zFS is to give each user a
 dedicated filesystem for HOME.  This is similar to the behavior
 of personal instances of those other systems.
 
 -- gil
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
 
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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)
 
 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. appears to understand the design constraints), and you discard
 it and get a new one with more satisfactory design, I don't see why you
 see that as a circumvention as opposed to a solution.
 
 Suppose z/OS were to provide an entirely new DSORG that met your
 requirement of SPACE=ANY.  Would you see that also as a
 circumvention?
 
 Tne customers' perennial but impossible demand: Make it work, but
 don't change anything!  E.g.: allow volumes larger than 54 GB,
 but don't change the 3390 geometry!

To the last question, if it required the applications to be rewritten: Yes. 

My intention was not to solve my immediate need, but to propose a more general 
solution that can be used by wider group. 

Regarding zFS: this would require a change in many places: procedures, JCLs and 
routines for administration of space (for the UNIX side). 
Of course, if You see UNIX as the future and MVS (or maybe just its file 
system) as something to leave behind, You are right. 
But my view is that MVS could and should be improved. 


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 





 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Joel C. Ewing

On 02/13/2012 09:19 AM, Chris Craddock wrote:

On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartinpaulgboul...@aim.comwrote:

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 space. And if it is used up, it doesn't impact others. z/OS
shares DASD space. ...

The z/OS cultural norm for HFS and zFS is to give each user a
dedicated filesystem for HOME. This is similar to the behavior
of personal instances of those other systems.

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. Prior to emulated DASD and large DASD
cache sizes, space/allocation sensitivity to tracks and cylinders was
frequently necessary for performance reasons, but that is no longer the
case. 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 given some
simple mechanism for specifying such limits, z/OS should also provide
support for monitoring whether application growth is causing data sets
to be at risk of exceeding their limit. Restricting sequential data set
allocation to record allocation of SMS Extended Sequential data sets
with space constraint relief and SD block size comes close, but is an
incomplete solution and only works for sequential files.

The MVS allocation strategy, which generally requires dynamic secondary
extensions to data sets when the size exceeds what can reliably be
obtained on a single volume, has always been flawed. Even when the exact
size of a large data set was known in advance, there was never a
guarantee that space for required secondary extensions would be
available on the selected volumes. In effect there was no easy way to
convey to z/OS via primary/secondary specifications what the true limit
of the data set should be because the actual maximum number of secondary
allocations was always an unknown, with no guarantee at the beginning of
step execution that even one dynamic secondary could be allocated on any
of the chosen volumes.

Perhaps an awareness of total data bytes involved in a data set is non
essential for data sets below some (installation-dependent) total-byte
threshold; but at some point for larger data sets those developing the
batch application should have an awareness of approximate data set size
and records involved so that concurrent space requirements for a job
step may be at least approximated up front; and so application
programmers don't choose an approach that might be appropriate for a toy
application of 1000 records but totally inappropriate for a production
application with a million records. If a required batch application is
going to consume a significant percentage of the total DASD farm, there
also needs to be some means for awareness of that, as it will impact job
scheduling and capacity planning.

The z/OS fixation on requiring data set SPACE specification for
allocation rather than using some totally dynamic approach is no doubt
an outgrowth of the desire for MVS to reliably support unattended batch
and, as others have mentioned, to prevent one looping batch job from
causing termination and denial-of-service of other unrelated jobs by
exhausting available DASD space. Properly designed JCL SPACE parameters
(which admittedly takes some effort) can also ABEND a batch job step up
front if sufficient DASD space does not exist for successful completion
-- much more desirable than allowing a batch job step to run for hours
and consume valuable resources, and then blow up because space for
further secondary allocation is unavailable. Operating systems that
don't require space estimates for large file allocation are implicitly
saying that reliable running of unattended batch processes is of
lesser importance.

--
Joel C. Ewing,Bentonville, AR jcew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive

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

Are you sure you are a mainframer?

 From: Thomas Berg thomas.b...@swedbank.se
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 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 
execution 

If for backward compatibility it can't be done automatically, why not 
introduce a new keyword like e g SPACE=ANY ? 

Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

We do this.  And while it somewhat simplifies things, it doesn't eliminate the 
requirement of determining how much storage is required.  It just moves it, and 
gives a set of sizes, rather than infinite granularity.

We have the following SMS data classes:

DATACLAS AVGREC   PRIMARY SECONDARY VOLUMES 

JUMBO    M        3000    1500       9
LARGE    M        1000 500   9
MEDIUM   M     100  50       9
SMALL    M      10   5       9
TINY K        1024 512       9
MINI K      20  20       9
NULL -       0   0   1

(On further reflection TINY and MINI should be reversed, but it was too late 
by the time we noticed.)

Is this the best?  No idea.  But it's what we did.
Of course we probably have a huge number of files that specify LARGE when they 
could be MEDIUM or less...


Frank






 From: Lizette Koehler stars...@mindspring.com
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
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 execution
 
 If for backward compatibility it can't be done automatically, why not
introduce a new
 keyword like e g SPACE=ANY ?
 
 

Thomas,

IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the
Space requirements there.  Then the JCL does not require Space.  Have you
looked at that?  However, then that makes your storage admin responsible for
ensuring the space is enough.  And if needed alter the dataclass if there
are space issues.  And it would require all such datasets be SMS managed.


Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

If you specify a default data class in this manner does this negate the 
requirement for both SPACE and DATACLAS?
Sounds good to me!
Frank





 From: Vernooij, CP - SPLXM kees.verno...@klm.com
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, February 13, 2012 6:43 AM
Subject: Re: Archaic allocation in JCL   (Was: Physical record size query)
 
Thomas Berg thomas.b...@swedbank.se wrote in message 
news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se...
  -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)
  
  Thomas Berg thomas.b...@swedbank.se wrote in message
  news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.
  se...
-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.ua.edu
Ämne: Re: Archaic allocation in JCL (Was: Physical record size query)
   

 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 execution

 If for backward compatibility it can't be done automatically, why
  not
introduce a new
 keyword like e g SPACE=ANY ?


   
Thomas,
   
IIRC - if you force a DATACLAS on a dataset in SMS, you can specify
  the
Space requirements there.  Then the JCL does not require Space.  Have
  you
looked at that?  However, then that makes your storage admin
  responsible
for
ensuring the space is enough.  And if needed alter the dataclass if
  there
are space issues.  And it would require all such datasets be SMS
  managed.
   
   
Lizette
  
   Hi Lizette,
  
   In practice it's not a viable alternative. Besides the need (if doing it
  that way) to communicate frequently with the space gang, it's to many
  variants of datasetnames and to many different needs for space depending
  on time, date and subgrouping within applications.
  
  
  
   Regards,
   Thomas Berg
  
  Now I don't understand: if you have so many different space needs, how do
  you assume 'SPACE=ANY' to solve this?
 
 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. 
 
 
  
 Regards, 
 Thomas Berg 

Consider how that is to be administrated during the execution of a job: if you 
do it like PCs, your dasd is formatted in small fixed chunks of space and each 
time you need more, you take another chunk. Suppose a chunk is 1 track: when a 
dataset is being filled, it will create hundreds/thousands/millions of chunks. 
This requires a completely new administration in DCB/DEB's and in VTOC DSCBs. 
Or do you introduce a new file- and diskformat: FAT/NTFS/ZFS(oh no, this 
exists),ZOSFS? On the same disks or on newly formatted disks? It brings a 
truckload of consequences to implement.

A simple variant would be: assign a default Dataclas, with a large amount of 
space, enough for 90% of your needs and release overallocated space at Close. 
This can all now already be done simply with Dataclass and Managementclass.

Kees.


Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential 
and privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may 
be disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

            

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists

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

I'm beginning to wondering... :)
But I started in februari 1979...


 
Regards, 
Thomas Berg 
_ 
Thomas Berg   Specialist   A M   SWEDBANK 

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] 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 Berg thomas.b...@swedbank.se
 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 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
 execution
 
 If for backward compatibility it can't be done automatically, why not
 introduce a new keyword like e g SPACE=ANY ?
 
 
 
 Regards,
 Thomas Berg
 _
 Thomas Berg   Specialist   A M   SWEDBANK
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
 
 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

I am having a hard time seeing this type of rationality put forth.  It's 
throwing me for a loop.  It's been a peeve of mine since I started on 
mainframes 15+ years ago.  I'm used to hearing it's your application; you 
figure out how much space it will require, both now and 10 years down the 
line.  Never been by idea of a good use of my time.

Frank




 From: Chris Craddock crashlu...@gmail.com
To: IBM-MAIN@bama.ua.edu 
Sent: Monday, February 13, 2012 8:19 AM
Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
 
On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 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 space. And if it is used up, it doesn't impact others. z/OS
 shares DASD space.  ...
 
 The z/OS cultural norm for HFS and zFS is to give each user a
 dedicated filesystem for HOME.  This is similar to the behavior
 of personal instances of those other systems.



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. There's no reason
z/OS couldn't do the same other than slavish adherence to legacy. IMHO it
is about time the system itself took care answering its own incessant how
big?, how many?, how often? questions. It's 2012 ferpetesakes. I'm all
in favor of making sure that existing applications continue to work. I am
far less impressed with continuing to impose 1960s thinking on new ones.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

2012-02-13 Thread Shmuel Metz (Seymour J.)

In
CAKXAhqVnjEpHL1xcVgdEi2uwAJ-fe-TngRwm41wH0ry7=qo...@mail.gmail.com,
on 02/13/2012
   at 09:19 AM, Chris Craddock crashlu...@gmail.com 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 issues, it's that they have
*different* space issues. As an example, there's no equivalent to a
multi-volume file, although the existence of logical volume managers
makes it less critical.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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 simplified.  I should be able to
code SPACE=(1,540) and let SDB infer an average
block size and allocation spare me the algebra of factoring the
total space into halfword chunks.  This might require a new
alternative TU: a  64-bit (for future growth) extent size in bytes.

(I'd prefer, for legibility, SPACE=(1,54.000.000.000) with European
thousands separators.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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