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

[Shmuel Metz (Seymour J.)]

In <1329705063.29591.54.ca...@mckown5.johnmckown.net>, on 02/19/2012
   at 08:31 PM, John McKown  said:

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

The directory is a catalog, and the path may include links.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Shmuel Metz (Seymour J.)]

In <4f418fa1.4040...@acm.org>, on 02/19/2012
   at 06:11 PM, "Joel C. Ewing"  said:

>Under Windows, a directory is closer functionally to the MVS/DOS
>concept  of a VTOC, as each volume has its own directory

ITYM each volume has its own root directory; a typical DOS or 'doze
volume has many directories.

>and you have to somehow know which volume to consult

Much like MVS before IBM pulled the plug on user catalogs.

>But in either case they are obviously structurally different

Just like CVOL, VSAM catalog and ICF catalog were structurally
different from each other. Just like directories in FAT are
structurally different from directories in NTFS. Just like directories
in ext2 are structurally different from directories in reiserfs.

>finding an file entry in Windows or Linux requires a progressive 
>search through multiple directory levels rather than just a 
>single lookup of the full path name as with a data set name in an 
>MVS catalog.

There is no "single lookup of the full path name" except in a shop
with no user catalogs, which you'd be hard pressed to find.

>And in both Windows and Linux, in many cases the user thinks of a 
>file by its file name and not its full path,  and the onus in on 
>the user to remember under what directory the file was placed.

That's true for MVS as well.

>That issue does not arise in MVS

It certainly does.

>because dataset names are always referenced by the full name

No. In fact, there are cases where attempting to refer to a data set
by its full name will cause an error.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[McKown, John]

I used to do that on rare occasion. I then got told off by management. They 
associated the volser to the storage group and did their reporting based on it. 
So my mixing things up messed up their reports. I'm not allowed to do that any 
more. We have offline volumes with a specific starting character. I will get 
"dinged" if any dataset ever shows up on any volume with that character. All 
"offline" volumes __must__ remain unused at all times. If I need space, even if 
only for a few hours, I must request it. 


--
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 Vernooij, CP - SPLXM
> Sent: Monday, February 20, 2012 2:32 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: O/T but curious (Re: Archaic allocation 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 of handling, I can remove the volumes from the 
> old SG, add
> them to the new SG and with the flip of a finger, I have the 
> free space
> of those volumes added to the new SG. If space management is set up
> will, the datasets on the volumes will be moved back to their 
> proper SG
> in due time, but I do not have to wait for that before I can add the
> free space to the new SG.
> 
> Never looked at this that way.
> 
> Kees.
> 
> 
> "McKown, John"  wrote in message
> news: cnrh.dom>.
> ..
> > Nope. The DSNs on the volumes will stay on the volumes, and be fully
> accessable. If they need to be extended onto a new volume, still no
> problem. If they are every migrated & recalled, they will go to other
> volumes in the old storage group. Assuming nothing has been done to
> affect that. Unless, of course, the storage class is 
> "guaranteed space",
> in which case I think the recall will fail.
> > 
> > --
> > 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 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
> > >  wrote:
> > > > "R.S."  wrote in message
> > > > news:<4f41f979.3010...@bremultibank.com.pl>...
> > > <>
> > > >> What is cool is that SMS storage group. Usually users do 
> > > not see the
> > > >> volumes, they see dasd space. In case of shortage you can 
> > > simply add
> > > >> some volumes to the group. You can even buy new box and 
> > > simply add it
> > > > to
> > > >> the group. And that's really cool IMHO.
> > > >
> > > > And SMS's granularity is also co

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

[Vernooij, CP - SPLXM]

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 of handling, I can remove the volumes from the old SG, add
them to the new SG and with the flip of a finger, I have the free space
of those volumes added to the new SG. If space management is set up
will, the datasets on the volumes will be moved back to their proper SG
in due time, but I do not have to wait for that before I can add the
free space to the new SG.

Never looked at this that way.

Kees.


"McKown, John"  wrote in message
news:.
..
> Nope. The DSNs on the volumes will stay on the volumes, and be fully
accessable. If they need to be extended onto a new volume, still no
problem. If they are every migrated & recalled, they will go to other
volumes in the old storage group. Assuming nothing has been done to
affect that. Unless, of course, the storage class is "guaranteed space",
in which case I think the recall will fail.
> 
> --
> 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 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
> >  wrote:
> > > "R.S."  wrote in message
> > > news:<4f41f979.3010...@bremultibank.com.pl>...
> > <>
> > >> What is cool is that SMS storage group. Usually users do 
> > not see the
> > >> volumes, they see dasd space. In case of shortage you can 
> > simply add
> > >> some volumes to the group. You can even buy new box and 
> > simply add it
> > > to
> > >> the group. And that's really cool IMHO.
> > >
> > > And SMS's granularity is also cool. If you add your 1TB disk to a
> > > storage group, you cannot use this space in anther SG 
> > anymore. If you
> > > have 1TB of 3390-54's, you can give to and take from SMS 
> > storage groups
> > > any required amounts at any time.
> > >
> > You don't have to empty the volumes?
> > -- 
> > 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 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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[McKown, John]

Nope. The DSNs on the volumes will stay on the volumes, and be fully 
accessable. If they need to be extended onto a new volume, still no problem. If 
they are every migrated & recalled, they will go to other volumes in the old 
storage group. Assuming nothing has been done to affect that. Unless, of 
course, the storage class is "guaranteed space", in which case I think the 
recall will fail.

--
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 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
>  wrote:
> > "R.S."  wrote in message
> > news:<4f41f979.3010...@bremultibank.com.pl>...
> <>
> >> What is cool is that SMS storage group. Usually users do 
> not see the
> >> volumes, they see dasd space. In case of shortage you can 
> simply add
> >> some volumes to the group. You can even buy new box and 
> simply add it
> > to
> >> the group. And that's really cool IMHO.
> >
> > And SMS's granularity is also cool. If you add your 1TB disk to a
> > storage group, you cannot use this space in anther SG 
> anymore. If you
> > have 1TB of 3390-54's, you can give to and take from SMS 
> storage groups
> > any required amounts at any time.
> >
> You don't have to empty the volumes?
> -- 
> 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 IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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

[Mark Post]

>>> On 2/20/2012 at 08:34 AM, John McKown  wrote: 
> If the filesystem runs out of space,
> and you used the proper type of filesystem (there are many), you simply
> expand the size of the logical volume into unused space in the group.
> You then resize the filesystem. If you used ext4 or btrfs, I think you
> can do this while it is in use. If you used ext3, I think you need to
> unmount it (take it "offline") to resize it.

To shrink an ext3 file system it has to be offline.  To expand it, that 
limitation was removed some time ago.


Mark Post

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

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

[Vernooij, CP - SPLXM]

"Mike Schwab"  wrote in message
news:...
> On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
>  wrote:
> > "R.S."  wrote in message
> > news:<4f41f979.3010...@bremultibank.com.pl>...
> <>
> >> What is cool is that SMS storage group. Usually users do not see
the
> >> volumes, they see dasd space. 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 cool IMHO.
> >
> > And SMS's granularity is also cool. If you add your 1TB disk to a
> > storage group, you cannot use this space in anther SG anymore. If
you
> > have 1TB of 3390-54's, you can give to and take from SMS storage
groups
> > any required amounts at any time.
> >
> You don't have to empty the volumes?
> -- 
> Mike A Schwab, Springfield IL USA

Details, details. I *can* take 100GB from this SG which I can't from a
1TB single volume.

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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Mike Schwab]

On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM
 wrote:
> "R.S."  wrote in message
> news:<4f41f979.3010...@bremultibank.com.pl>...
<>
>> What is cool is that SMS storage group. Usually users do not see the
>> volumes, they see dasd space. In case of shortage you can simply add
>> some volumes to the group. You can even buy new box and simply add it
> to
>> the group. And that's really cool IMHO.
>
> And SMS's granularity is also cool. If you add your 1TB disk to a
> storage group, you cannot use this space in anther SG anymore. If you
> have 1TB of 3390-54's, you can give to and take from SMS storage groups
> any required amounts at any time.
>
You don't have to empty the volumes?
-- 
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[John McKown]

On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote:

> What is cool is that SMS storage group. Usually users do not see the 
> volumes, they see dasd space. In case of shortage you can simply add 
> some volumes to the group. You can even buy new box and simply add it to 
> the group. And that's really cool IMHO.

You'd like LVM2 on Linux. You assign your physical disk partitions to a
physical volume group (conceptually like an SMS volume group). You can
then divvy up the space in that group into various sized logical
volumes. This is then initialized with a filesystem with mkfs
(equivalent to ICKDSF, I guess). If the filesystem runs out of space,
and you used the proper type of filesystem (there are many), you simply
expand the size of the logical volume into unused space in the group.
You then resize the filesystem. If you used ext4 or btrfs, I think you
can do this while it is in use. If you used ext3, I think you need to
unmount it (take it "offline") to resize it. If you're out of space in
the volume group, buy another disk and initialize it into the physical
volume group, then expand. logical volume space does not need to be
physically contiguous.

> 
-- 
John McKown
Maranatha! <><

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

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

[Paul Gilmartin]

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 is typically very low.  In Linux, if all volumes
>are mounted, the directory plays a similar functional role to that of
>the MVS catalog(s) and VTOCs combined.  But in either case they are
>obviously structurally different: finding an file entry in Windows or
>Linux requires a progressive search through multiple directory levels
>rather than just a single lookup of the full path name as with a data
>set name in an MVS catalog.
> 
There's some hint here that the single-level catalog lookup should
have a performance advantage over a multi-level directory search.
In practice, I find the opposite.  Deleting several dozen catalogued
data sets takes orders of magnitude longer than deleting a similar
number of z/OS UNIX files.  Admittedly, our lab configuration
precludes a sysplex configuration that might otherwise greatly
optimize catalog operations, I am told.

In practice, the z/OS search is not single-level; perhaps four:
master catalog; user catalog; VTOC; PDS directory.

And not mentioned here as yet is that the catalog can index offline
volumes and automatically generate mount requests as needed.
But this distinction seems to be vanisning.  I have become accustomed
on Solaris to receiving, infrequently, a message on my terminal that
some file is temporarily unavailable; I must wait for it.  I take this
to mean that something analogous to HSM recall is in progress.

-- gil

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

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

[Paul Gilmartin]

On Sun, 19 Feb 2012 20:31:03 -0600, John McKown wrote:
>
>Linux addresses this issue via a utility called "mlocate". It runs
>periodically, usually once a day during a low activity time, via
>crontab. And, as you immediate can tell, it is not real time. Files get
>created and deleted without an immediate database update. Hum, might be
>interesting to see about using the inotify interface to implement a
>"real time" update to the mlocate database.
>
>I wonder if z/OS UNIX has something to monitor UNIX filesystem events.
>Something to think about.
> 
OS X does much of this for a couple purposes.

"Spotlight" maintains a timely index of not only names but also
content of files.

"Time Machine" performs hourly incremetal backups based on
notifications without scanning the entire filesystem for changes.
But after a restart, TM does scan the entire filesystem to
detect recent changes.

-- gil

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

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

[Vernooij, CP - SPLXM]

"R.S."  wrote in message
news:<4f41f979.3010...@bremultibank.com.pl>...
> W dniu 2012-02-19 17:23, Edward Jaffe pisze:
> > On 2/19/2012 4:40 AM, R.S. wrote:
> >> W dniu 2012-02-19 08:30, Edward Jaffe pisze:
> >>> On 2/18/2012 4:45 PM, Paul Gilmartin wrote:
>  Remember that if z/OS didn't impose a factitious limit on
>  volume size, there'd be little need for multivolume data sets.
> >>>
> >>> In that case, widespread adoption of 1TB volumes on z/OS should
> >>> significantly decrease the number of multivolume data sets in
use...
> >>>
> >>
> >> 1TB ??? Why so huge? It's... it's... it's almost as much as single
HDD
> >> in my PC! 
> >
> > What's especially cool is that mainframe volumes can by dynamically
> > configured to be any size between Mod1 and 1TB. If you ever run out
of
> > space on a volume, just turn the "magic screwdriver" on the remote
DASD
> > HMC (SSPC) to make the volume larger and keep on going. The new size
is
> > immediately seen by z/OS.
> 
> Well, the same feature was available 12+ years ago on "windows" dasd 
> arrays. What is "warm" (not cool ) is that mainframe volumes
CANNOT 
> BE always dynamically enlarged. It is available on some controllers 
> under some circumstances (set up).
> 
> 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 cool IMHO.
> 
> 

And SMS's granularity is also cool. If you add your 1TB disk to a
storage group, you cannot use this space in anther SG anymore. If you
have 1TB of 3390-54's, you can give to and take from SMS storage groups
any required amounts at any time. 

Kees.

> -- 
> Radoslaw Skorupka
> Lodz, Poland
> 
> 

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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[R.S.]

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 that case, widespread adoption of 1TB volumes on z/OS should
significantly decrease the number of multivolume data sets in use...



1TB ??? Why so huge? It's... it's... it's almost as much as single HDD
in my PC! 


What's especially cool is that mainframe volumes can by dynamically
configured to be any size between Mod1 and 1TB. If you ever run out of
space on a volume, just turn the "magic screwdriver" on the remote DASD
HMC (SSPC) to make the volume larger and keep on going. The new size is
immediately seen by z/OS.


Well, the same feature was available 12+ years ago on "windows" dasd 
arrays. What is "warm" (not cool ) is that mainframe volumes CANNOT 
BE always dynamically enlarged. It is available on some controllers 
under some circumstances (set up).


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



--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

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

[John McKown]

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
equivalent and the subdirectory path as a "volume" equivalent, then you
could use some sort of "catalog". Of course, such names are not
guaranteed to be unique. In fact, there are almost certainly duplicates
such as each user's .profile file.

Linux addresses this issue via a utility called "mlocate". It runs
periodically, usually once a day during a low activity time, via
crontab. And, as you immediate can tell, it is not real time. Files get
created and deleted without an immediate database update. Hum, might be
interesting to see about using the inotify interface to implement a
"real time" update to the mlocate database.

I wonder if z/OS UNIX has something to monitor UNIX filesystem events.
Something to think about.

On Sun, 2012-02-19 at 12:40 -0500, Shmuel Metz (Seymour J.) wrote:
> In
> ,
> on 02/18/2012
>at 07:06 PM, Mike Schwab  said:
> 
> >Neither Windows or Linux have a Catalog concept to find a dataset on
> 
> What do you think a directory is?
>  
-- 
John McKown
Maranatha! <><

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

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

[Scott Ford]

Lol, nope , that would be a big file

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 19, 2012, at 4:56 PM, Ed Gould  wrote:

> Perhaps,
> 
> But have you ever heard of a 1 petabyte (or more) volume?
> 
> Ed
> 
> On Feb 18, 2012, at 5:36 PM, Scott Ford wrote:
> 
>> Ed,
>> Or maybe they use the famous four letter word, plan and have a harddrive big 
>> enough to handle the file
>> 
>> Sent from my iPad
>> Scott Ford
>> Senior Systems Engineer
>> www.identityforge.com
>> 
>> 
>> 
>> On Feb 18, 2012, at 5:43 PM, Ed Gould  wrote:
>> 
>>> We are all pretty much knowledgeable about how the MF works in 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
>>> 
>>> --
>>> 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

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

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

[Joel C. Ewing]

On 02/19/2012 11:40 AM, Shmuel Metz (Seymour J.) wrote:

In
,
on 02/18/2012
at 07:06 PM, Mike Schwab  said:


Neither Windows or Linux have a Catalog concept to find a dataset on


What do you think a directory is?

Under Windows, a directory is closer functionally to the MVS/DOS concept 
of a 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 is typically very low.  In Linux, if all volumes 
are mounted, the directory plays a similar functional role to that of 
the MVS catalog(s) and VTOCs combined.  But in either case they are 
obviously structurally different: finding an file entry in Windows or 
Linux requires a progressive search through multiple directory levels 
rather than just a single lookup of the full path name as with a data 
set name in an MVS catalog.  And in both Windows and Linux, in many 
cases the user thinks of a file by its file name and not its full path, 
and the onus in on the user to remember under what directory the file 
was placed.  That issue does not arise in MVS because dataset names are 
always referenced by the full name -- roughly the equivalent to always 
requiring the full path name in Win/Linux -- and that makes direct 
lookup in a "catalog" possible.


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

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

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

[Ed Gould]

Perhaps,

But have you ever heard of a 1 petabyte (or more) volume?

Ed

On Feb 18, 2012, at 5:36 PM, Scott Ford wrote:


Ed,
Or maybe they use the famous four letter word, plan and have a  
harddrive big enough to handle the file


Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 18, 2012, at 5:43 PM, Ed Gould  wrote:

We are all pretty much knowledgeable about how the MF works in 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

- 
-

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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Shmuel Metz (Seymour J.)]

In
,
on 02/18/2012
   at 07:06 PM, Mike Schwab  said:

>Neither Windows or Linux have a Catalog concept to find a dataset on

What do you think a directory is?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. 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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Edward Jaffe]

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 on z/OS should
significantly decrease the number of multivolume data sets in use...



1TB ??? Why so huge? It's... it's... it's almost as much as single HDD in my 
PC! 


What's especially cool is that mainframe volumes can by dynamically configured 
to be any size between Mod1 and 1TB. If you ever run out of space on a volume, 
just turn the "magic screwdriver" on the remote DASD HMC (SSPC) to make the 
volume larger and keep on going. The new size is immediately seen by z/OS.


--
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[R.S.]

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 decrease the number of multivolume data sets in use...



1TB ??? Why so huge? It's... it's... it's almost as much as single HDD 
in my PC! 


BTW: few weeks ago I worked in a shop where they have 3390-3's only. I 
felt comfortably with so small volumes.


--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


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

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

[Edward Jaffe]

On 2/18/2012 4:45 PM, Paul Gilmartin wrote:

Remember that if z/OS didn't impose a factitious limit on
volume size, there'd be little need for multivolume data sets.


In that case, widespread adoption of 1TB volumes on z/OS should significantly 
decrease the number of multivolume data sets in use...


--
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Mike Schwab]

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 or usb / CD / DVD drive.

And you can have a link where a file name points to another file name.

Neither Windows or Linux have a Catalog concept to find a dataset on
any of 64,000 or so disk drives (I have 2400 at work).

On Sat, Feb 18, 2012 at 4:43 PM, Ed Gould  wrote:
> 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

-- 
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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[Paul Gilmartin]

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 multivolume data sets.

-- gil

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

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

[Scott Ford]

Ed,
Or maybe they use the famous four letter word, plan and have a harddrive big 
enough to handle the file

Sent from my iPad
Scott Ford
Senior Systems Engineer
www.identityforge.com



On Feb 18, 2012, at 5:43 PM, Ed Gould  wrote:

> We are all pretty much knowledgeable about how the MF works in 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
> 
> --
> 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: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )

[zMan]

Sure: it doesn't. Unless you're using some other sort of volume manager.

Of course, with a 1TB drive selling for less than $100, multivolume
files aren't usually a requirement...

On Sat, Feb 18, 2012 at 2:43 PM, Ed Gould  wrote:
> We are all pretty much knowledgeable about how the MF works in the
> 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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

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

[Ed Gould]

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

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