On Tue, 21 Feb 2012 10:16:25 -0600, McKown, John wrote:
Do you ever want to retire some step(s) from a job? But you don't really
want to remove the step(s) just in case? I don't remember this being
mentioned before, so I thought I would. It will work for any step, other than
the first one in
On Tue, 21 Feb 2012 10:16:25 -0600, McKown, John
john.mck...@healthmarkets.com wrote:
Do you ever want to retire some step(s) from a job? But you don't really
want to remove the step(s) just in case? I don't remember this being
mentioned before, so I thought I would. It will work for any step,
that will be skipped.
If you really want guaranteed zero effects from the unwanted step
without complete deletion of step JCL, changing the statements to
comments is the only sure way.
--
Joel C. Ewing,Bentonville, AR jcew...@acm.org
How about the even simpler
// IF FALSE THEN
...
// ENDIF
Very usefully TRUE FALSE can be passed thru as symbols.
--
Julian Levens
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
For IBM-MAIN subscribe
On Tue, 21 Feb 2012 10:16:25 -0600, McKown, John wrote:
Wrap the step(s) you want to bypass with:
// IF (stepname.RUN=TRUE AND stepname.RUN=FALSE) THEN
steps to be bypassed
// ENDIF
I sometimes do this, which also requires a prior step:
// DD DATA,DLM=$$
steps to be skipped
On Tue, 21 Feb 2012 20:01:19 +0100, julian.lev...@gmail.com
julian.lev...@gmail.com wrote:
How about the even simpler
// IF FALSE THEN
...
// ENDIF
Very usefully TRUE FALSE can be passed thru as symbols.
Nope. RTFM.
-- gil
provided. But other's replies
are also useful too!
Sorry if this was obvious. Maybe my brain has retired already.
You are NOT allowed to say sorry. :-D
I admire your courage to post tricks like this. Please continue to post more
tricks, even if you only manage to get 'JCL haters' crazy! ;-D
Doe
On Wed, 2012-02-22 at 01:11 -0600, Elardus Engelbrecht wrote:
snip
You are NOT allowed to say sorry. :-D
As Gibbs on NCIS would say.
I admire your courage to post tricks like this. Please continue to post more
tricks, even if you only manage to get 'JCL haters' crazy! ;-D
For my real
On Sun, 19 Feb 2012 18:11:13 -0600, Joel C. Ewing wrote:
Under Windows, a directory is closer functionally to the MVS/DOS concept
of a VTOC, as each volume has its own directory and you have to somehow
know which volume to consult -- although admittedly in a windows system
the number of volumes
On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote:
snip
What is cool is that SMS storage group. Usually users do not see the
volumes, they see dasd space. In case of shortage you can simply add
some volumes to the group. You can even buy new box and simply add it to
the group. And that's really
On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
kees.verno...@klm.com wrote:
R.S. r.skoru...@bremultibank.com.pl wrote in message
news:4f41f979.3010...@bremultibank.com.pl...
deleted
What is cool is that SMS storage group. Usually users do not see the
volumes, they see dasd space. In
Mike Schwab mike.a.sch...@gmail.com wrote in message
news:cajtoo5_brjh+-ojaqd9jq17cojfbbjuzddhi35yuk33zj_n...@mail.gmail.com
...
On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
kees.verno...@klm.com wrote:
R.S. r.skoru...@bremultibank.com.pl wrote in message
On 2/20/2012 at 08:34 AM, John McKown joa...@swbell.net wrote:
If the filesystem runs out of space,
and you used the proper type of filesystem (there are many), you simply
expand the size of the logical volume into unused space in the group.
You then resize the filesystem. If you used ext4
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab
Sent: Monday, February 20, 2012 8:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: O/T but curious (Re: Archaic allocation in JCL
(Was: Physical record size query) )
On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
kees.verno...@klm.com wrote
Gilmore
Sent: Fri 2/17/2012 6:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
Frank Swabrick wrote:
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
@bama.ua.edu
Subject: Re: O/T but curious (Re: Archaic allocation in JCL
(Was: Physical record size query) )
On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
kees.verno...@klm.com wrote:
R.S. r.skoru...@bremultibank.com.pl wrote in message
news:4f41f979.3010...@bremultibank.com.pl
in JCL
(Was: Physical record size query) )
Hey John,
That quite a new and surprising approach!
My point was to (indeed) empty several volumes, reformat/relabel them
(to predefined volumes in the new SG) and therewith add them to a new
SG, where I need the extra space.
With your way
In 4f418fa1.4040...@acm.org, on 02/19/2012
at 06:11 PM, Joel C. Ewing jcew...@acm.org said:
Under Windows, a directory is closer functionally to the MVS/DOS
concept of a VTOC, as each volume has its own directory
ITYM each volume has its own root directory; a typical DOS or 'doze
volume has
In 1329705063.29591.54.ca...@mckown5.johnmckown.net, on 02/19/2012
at 08:31 PM, John McKown joa...@swbell.net said:
Just to play the Devil's advocate for a bit, it depends on how you
define dataset name. I agree, in Linux (and as a stretch, Windows),
if you specify the entire file path,
W dniu 2012-02-19 08:30, Edward Jaffe pisze:
On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.
In that case, widespread adoption of 1TB volumes on z/OS should
significantly
On 2/19/2012 4:40 AM, R.S. wrote:
W dniu 2012-02-19 08:30, Edward Jaffe pisze:
On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.
In that case, widespread adoption of 1TB volumes
In
cajtoo59ducxpmrtvozjwjxbr26rbq1hdbdarsnfundxbhfw...@mail.gmail.com,
on 02/18/2012
at 07:06 PM, Mike Schwab mike.a.sch...@gmail.com said:
Neither Windows or Linux have a Catalog concept to find a dataset on
What do you think a directory is?
--
Shmuel (Seymour J.) Metz, SysProg and
Perhaps,
But have you ever heard of a 1 petabyte (or more) volume?
Ed
On Feb 18, 2012, at 5:36 PM, Scott Ford wrote:
Ed,
Or maybe they use the famous four letter word, plan and have a
harddrive big enough to handle the file
Sent from my iPad
Scott Ford
Senior Systems Engineer
On 02/19/2012 11:40 AM, Shmuel Metz (Seymour J.) wrote:
In
cajtoo59ducxpmrtvozjwjxbr26rbq1hdbdarsnfundxbhfw...@mail.gmail.com,
on 02/18/2012
at 07:06 PM, Mike Schwabmike.a.sch...@gmail.com said:
Neither Windows or Linux have a Catalog concept to find a dataset on
What do you think a
Amen John!!
From: IBM Mainframe Discussion List on behalf of John Gilmore
Sent: Fri 2/17/2012 6:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Archaic allocation in JCL (Was: Physical record size query)
Frank Swabrick wrote:
begin snippet
| No, I'm not expecting
Lol, nope , that would be a big file
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Feb 19, 2012, at 4:56 PM, Ed Gould edgould1...@comcast.net wrote:
Perhaps,
But have you ever heard of a 1 petabyte (or more) volume?
Ed
On Feb 18, 2012, at 5:36 PM,
Just to play the Devil's advocate for a bit, it depends on how you
define dataset name. I agree, in Linux (and as a stretch, Windows), if
you specify the entire file path, starting from the root, you don't need
a catalog.
But if you think of a file within a given subdirectory as a dataset
W dniu 2012-02-19 17:23, Edward Jaffe pisze:
On 2/19/2012 4:40 AM, R.S. wrote:
W dniu 2012-02-19 08:30, Edward Jaffe pisze:
On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.
In
R.S. r.skoru...@bremultibank.com.pl wrote in message
news:4f41f979.3010...@bremultibank.com.pl...
W dniu 2012-02-19 17:23, Edward Jaffe pisze:
On 2/19/2012 4:40 AM, R.S. wrote:
W dniu 2012-02-19 08:30, Edward Jaffe pisze:
On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
Remember that if z/OS
We are all pretty much knowledgeable about how the MF works in the
multi-volume area, right?
The secondary question I am asking is how does the PC create/handle
multivolume files?
I can guess but that is pretty much all it is. Can anyone explain it
for the PC ?
Ed
Sure: it doesn't. Unless you're using some other sort of volume manager.
Of course, with a 1TB drive selling for less than $100, multivolume
files aren't usually a requirement...
On Sat, Feb 18, 2012 at 2:43 PM, Ed Gould edgould1...@comcast.net wrote:
We are all pretty much knowledgeable about
Ed,
Or maybe they use the famous four letter word, plan and have a harddrive big
enough to handle the file
Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com
On Feb 18, 2012, at 5:43 PM, Ed Gould edgould1...@comcast.net wrote:
We are all pretty much knowledgeable
On Sat, 18 Feb 2012 16:43:27 -0600, Ed Gould wrote:
The secondary question I am asking is how does the PC create/handle
multivolume files?
Virtual volumes as big as needed: RAID; ZFS; ...?
Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for
Under Linux / AIX, You can define a logical volume that spans multiple
physical volumes. And different mount points can point to different
physical drives. But reading from the root / it all looks like one
logical drive.
Windows has different drive letters for each drive or hard drive
partition
At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic
allocation in JCL (Was: Physical record size qu:
The gotcha used to be that if you grossly over-requested space,
got space dispersed over umpteen volumes, only used a little of the
space, that RLSE would then only release
At 14:07 -0500 on 02/17/2012, Shmuel Metz (Seymour J.) wrote about
Re: Archaic allocation in JCL (Was: Physical record size qu:
In
CAPD5F5rThXaYbF32YgQMXK0bWTtXELh3X+XMOaUnKwPv=tt...@mail.gmail.com,
on 02/17/2012
at 12:50 PM, John Gilmore johnwgilmore0...@gmail.com said:
is not really
On 18 Feb 2012 17:53:19 -0800, in bit.listserv.ibm-main you wrote:
At 16:11 -0600 on 02/13/2012, Joel C. Ewing wrote about Re: Archaic
allocation in JCL (Was: Physical record size qu:
The gotcha used to be that if you grossly over-requested space,
got space dispersed over umpteen volumes, only
W dniu 2012-02-19 03:34, Clark Morris pisze:
[...]
For VSAM I would still allocate in either tracks or cylinders so that
I get the CA size I want. Of course if allocation is in millions of
anything, that caveat doesn't matter (or have they changed VSAM so a
CA can be larger than a cylinder?).
On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.
In that case, widespread adoption of 1TB volumes on z/OS should significantly
decrease the number of multivolume data sets in
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
-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
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
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
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
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
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:
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
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
.), 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
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
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?
...@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
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
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
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
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
: 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
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
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
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.
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
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
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
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
-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
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
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
-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
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
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
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
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
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
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
-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
: 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
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
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
-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
-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
: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
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
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
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
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
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.
-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
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
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
-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
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
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
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
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
-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
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
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
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
-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
. 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
101 - 200 of 2968 matches
Mail list logo
