Re: Storage paradigm [was: RE: Data volumes]

2013-06-15 Thread Anne Lynn Wheeler
and virtual memory ... includes reference that OS/VS2 release 2 (MVS) was on glide path to OS/VS2 release 3 (FS) re: http://www.garlic.com/~lynn/2013h.html#44 Why does IBM keep saying things like this http://www.garlic.com/~lynn/2013h.html#45 Storage paradigm [was: RE: Data volumes] http

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Ted MacNEIL
Perhaps you are keeping bad company. While humans are not perfect, there are methods to improve code reliability. In 30+ years, I've worked for 6 companies. Gee, they all must be bad company! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread R.S.
W dniu 2013-06-11 08:58, Ted MacNEIL pisze: Perhaps you are keeping bad company. While humans are not perfect, there are methods to improve code reliability. In 30+ years, I've worked for 6 companies. Gee, they all must be bad company! Are we still talking about possible bug in the

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Vernooij, CP - SPLXM
, control who can use different Dataclasses etc. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Monday, June 10, 2013 19:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage paradigm [was: RE: Data volumes

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Thomas Berg
, Peter x23353 Sent: Monday, June 10, 2013 5:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Storage paradigm [was: RE: Data volumes] Rant Like a few others on this list, I have often gritted my teeth at the necessity to estimate disk storage quantities that vary widely over time in a fixed manner

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Elardus Engelbrecht
Gerhard Postpischil wrote: What planet are you from? Sol 3 Interesting that you refer to that filthy big blue polluted ironball with warring citizens. The last time I checked, we're on Tatooine in a galaxy far far away or so I think... ;-) Ted MacNEIL wrote: Programmers seem able to test

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Joel C. Ewing
On 06/10/2013 01:57 PM, Ted MacNEIL wrote: As to run-away programs, they should be thoroughly checked on a test system before going into production; a run-away in production should be so rare as to be immaterial. What planet are you from? Programmers seem able to test everything except that

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Gerhard Postpischil
On 6/11/2013 5:41 AM, Elardus Engelbrecht wrote: Interesting that you refer to that filthy big blue polluted ironball with warring citizens. The last time I checked, we're on Tatooine in a galaxy far far away or so I think... ;-) Nice display of dry wit G Gerhard Postpischil Bradford, Vermont

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Shmuel Metz (Seymour J.)
In CAAJSdjhdFqcpkSUKJ9Uu+DSJh1VwwJdFT2VSHwC3P9=79nc...@mail.gmail.com, on 06/10/2013 at 11:45 AM, John McKown john.archie.mck...@gmail.com said: LUW works similar to z/OS UNIX file systems. I.e. there is a file system which is formatted using some utility (mkfs in the Linux/UNIX world, format

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Shmuel Metz (Seymour J.)
In 51b60a0b.7030...@valley.net, on 06/10/2013 at 01:16 PM, Gerhard Postpischil gerh...@valley.net said: Technically the easiest to implement would be adding a new device type, thus keeping (E)CKD completely distinct from FBA. The new type could be supported by VSAM/AMS only (and JCL, SVC 99,

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Shmuel Metz (Seymour J.)
In 985915eee6984740ae93f8495c624c6c23194bd...@jscpcwexmaa1.bsg.ad.adp.com, on 06/10/2013 at 02:46 PM, Farley, Peter x23353 peter.far...@broadridge.com said: There *are* non-theoretical solutions to runaway file output. The *ix system model of using disk quotas per user makes it entirely

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Shmuel Metz (Seymour J.)
In 985915eee6984740ae93f8495c624c6c23194bd...@jscpcwexmaa1.bsg.ad.adp.com, on 06/10/2013 at 11:38 AM, Farley, Peter x23353 peter.far...@broadridge.com said: Why is it that IBM (and organizations that use their mainframe systems) so vigorously resist a conversion off of the ECKD standard?

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Gerhard Postpischil
On 6/11/2013 2:58 AM, Ted MacNEIL wrote: In 30+ years, I've worked for 6 companies. Gee, they all must be bad company! I'll take your word for it. In 40+ years I worked for 8 companies, two of which were ISVs, two service bureaus, and the rest were contract software providers (mostly, but

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread John McKown
LVM requires an LV (Logical Volume) to be in a single VG (Volume Group). A VG is composed of one or more PVs (Physical Volumes). A PV is basically a specially formatted disk partition (which can be the entire disk or subdivision). A single file system must reside on a single LV. Which is in a VG.

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread John McKown
Yes, most people basically want to say: I don't want to have to concern myself with how much space and time it takes to do my work. I just want it to work. Oh, and I need it ASAP. And it must not require too much thought. That is, I need to be able to use it on a Monday morning, before I have had

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Thomas Berg
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, June 11, 2013 3:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage paradigm [was: RE: Data volumes

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Anne Lynn Wheeler
shmuel+...@patriot.net (Shmuel Metz , Seymour J.) writes: That's not the Multics model. The Multic model is that segment numbers are dynamically assigned as needed, and that in general two processes will use different numbers for the same segment. IBM had something similar in TSS, but

Re: Storage paradigm [was: RE: Data volumes]

2013-06-11 Thread Anne Lynn Wheeler
) for moderate filesystem workload. some past posts http://www.garlic.com/~lynn/submain.html#mmap re: http://www.garlic.com/~lynn/2013h.html#44 Why does IBM keep saying things like this http://www.garlic.com/~lynn/2013h.html#45 Storage paradigm [was: RE: Data volumes] note that there was two parts

Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Farley, Peter x23353
Rant Like a few others on this list, I have often gritted my teeth at the necessity to estimate disk storage quantities that vary widely over time in a fixed manner (i.e., SPACE in JCL) when the true need is just to match output volume to input volume each day. Why is it that IBM (and

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread John McKown
In general, I agree. But I will say that I need something to limit run-away usage of disk space. Why? Because we have had programmers who didn't want to be bother either. So they put out a report to SPOOL. And then their program went into a loop; writing the same message over and over. This

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Dale R. Smith
On Mon, 10 Jun 2013 11:38:08 -0400, Farley, Peter x23353 peter.far...@broadridge.com wrote: Rant Like a few others on this list, I have often gritted my teeth at the necessity to estimate disk storage quantities that vary widely over time in a fixed manner (i.e., SPACE in JCL) when the true

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Blaicher, Christopher Y.
@LISTSERV.UA.EDU Subject: Storage paradigm [was: RE: Data volumes] Rant Like a few others on this list, I have often gritted my teeth at the necessity to estimate disk storage quantities that vary widely over time in a fixed manner (i.e., SPACE in JCL) when the true need is just to match output

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread John McKown
- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, June 10, 2013 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Storage paradigm [was: RE: Data volumes] Rant Like a few others on this list, I have often gritted my teeth

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Roberts, John J
For Windows Capabilities, I suggest reading about Dynamic Disks and Dynamic Volumes on MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363785(v=vs.85).aspx John -- For IBM-MAIN subscribe / signoff / archive

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Gerhard Postpischil
On 6/10/2013 12:15 PM, Blaicher, Christopher Y. wrote: I am not a LUW person, other than I use a windows machine for simple things, so I am curious how external storage is allocated and controlled in that environment. I think we have all heard the complaints about the short-comings of MVS in

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Gerhard Postpischil
On 6/10/2013 11:38 AM, Farley, Peter x23353 wrote: Rant Like a few others on this list, I have often gritted my teeth at the necessity to estimate disk storage quantities that vary widely over time in a fixed manner (i.e., SPACE in JCL) when the true need is just to match output volume to input

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Mike Schwab
Download GnuPartEd, Burn it to CD-ROM, Boot from it, resize as needed. On Mon, Jun 10, 2013 at 11:56 AM, Roberts, John J jrobe...@dhs.state.ia.us wrote: For Windows Capabilities, I suggest reading about Dynamic Disks and Dynamic Volumes on MSDN:

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Farley, Peter x23353
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Monday, June 10, 2013 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage paradigm [was: RE: Data volumes] On 6/10/2013 11:38 AM, Farley, Peter x23353 wrote: Rant Like a few others

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread John McKown
Too true. And, around here, our QA people appear to be glitz checkers instead of function and reliability checkers. They have more people than any other group and do less testing on the mainframe. They seem to check mainly for ease of use. That is, can a totally numb skull still use this? On Mon,

Re: [SPAM] Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Gerhard Postpischil
On 6/10/2013 2:46 PM, Farley, Peter x23353 wrote: To your point about tailoring and dynamically submitting JCL, it really is an issue. In a typical large z/OS shop today, dynamically tailoring and submitting JCL is only permitted for test environments and users. Production JCL is frozen and

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Gerhard Postpischil
On 6/10/2013 2:57 PM, Ted MacNEIL wrote: What planet are you from? Sol 3 Programmers seem able to test everything except that one condition that will break in Production Perhaps you are keeping bad company. While humans are not perfect, there are methods to improve code reliability.