Shmuel Metz (Seymour J.) wrote:
In <598332.62220...@web54606.mail.re2.yahoo.com>, on 10/25/2010
at 09:09 PM, Ed Gould said:
I know IBM got the vsam catalog right with minimal issues
Both the original VSAM catalog and the4 ICF catalog had major issues.
And a long and painful ev
In , on 10/25/2010
at 07:11 AM, "Robert A. Rosenberg" said:
>You have a "Chicken and Egg" situation with IPL Time support for
>PDSEs. How much of an environment must exist before PDSEs support is
> possible?
They managed the equivalent in TSS/360.
--
Shmuel (Seymour J.) Metz, SysPr
In <598332.62220...@web54606.mail.re2.yahoo.com>, on 10/25/2010
at 09:09 PM, Ed Gould said:
>I know IBM got the vsam catalog right with minimal issues
Both the original VSAM catalog and the4 ICF catalog had major issues.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position
On Tue, 26 Oct 2010 12:50:56 -0300 Clark Morris
wrote:
:>On 26 Oct 2010 04:34:49 -0700, in bit.listserv.ibm-main you wrote:
:>>>I will forgive him his SYS1.NUCLEUS jibe, since the rest of his post
:>>>makes it clear that he knows very well where the real problem lies.
:>>Maybe I don't know. Th
On 26 Oct 2010 04:34:49 -0700, in bit.listserv.ibm-main you wrote:
>>I will forgive him his SYS1.NUCLEUS jibe, since the rest of his post
>>makes it clear that he knows very well where the real problem lies.
>
>Maybe I don't know. The only problem that I know of, and the reason that I
>created d
>I will forgive him his SYS1.NUCLEUS jibe, since the rest of his post
>makes it clear that he knows very well where the real problem lies.
Maybe I don't know. The only problem that I know of, and the reason that I
created deferred LPA wait,was the question of how an application, starting
after
5/10, Rick Fochtman wrote:
From: Rick Fochtman
Subject: Re: PDSE versus PDS
To: IBM-MAIN@bama.ua.edu
Date: Monday, October 25, 2010, 4:29 PM
>
>
> --
>
>> The decision not to support IPL-time use of PDSEs w
On Mon, 2010-10-25 at 11:48 -0300, Clark Morris wrote:
> On 25 Oct 2010 04:49:29 -0700, in bit.listserv.ibm-main you wrote:
>
> >>The decision not to support IPL-time use of PDSEs was an unconscionable
> >one. ,
> >
> >OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone
> >al
Rick Fochtman wrote:
>I have to think that the complexity of the code changes required would also
>mitigate against this changes as well.
That's "militate against". (Yeah, common error, pet peeve.)
...phsiii
--
For IBM-MAIN sub
That's because you're one of the practical ones. I was raised as a
Mathematician, not an Engineer! It needs to be done because it is
"elegant" to do so. Costs money? What does that have do to with
it
On Mon, 2010-10-25 at 23:08 +1000, Shane wrote:
> Ya gotta love this guy.
> People hypothesi
--
The decision not to support IPL-time use of PDSEs was an unconscionable one. It would indeed be easy to caricature it as sabotage.
Perhaps likewise the decision not to support network-mounted files
at IPL-time.
On 25 Oct 2010 04:49:29 -0700, in bit.listserv.ibm-main you wrote:
>>The decision not to support IPL-time use of PDSEs was an unconscionable
>one. ,
>
>OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone
>also needs to be in a PDSE?
>
>It is SYS1.NUCLEUS and LPA modules that
On 25 Oct 2010 04:41:28 -0700, in bit.listserv.ibm-main you wrote:
>At 02:28 + on 10/25/2010, john gilmore wrote about Re: PDSE versus PDS:
>
>>The decision not to support IPL-time use of PDSEs was an
>>unconscionable one. It would indeed be easy to caricature it as
>&
My last post should of course have had this subject. "PDSE versus PDSE" is too
tendentious.
John Gilmore Ashland, MA 01721-1817 USA
--
For IBM-MAIN subscribe / signoff / archive access
Ya gotta love this guy.
People hypothesizing (pontificating ?) all over the place, and the
voice of reason brings all crashing back to earth.
Shane ...
(and yes, I've dissed PDSEs at least as much as everyone else)
On Mon, 25 Oct 2010 07:48:39 -0400
Peter Relson wrote:
> OK, I'll bite. What code
>The decision not to support IPL-time use of PDSEs was an unconscionable
one. ,
OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone
also needs to be in a PDSE?
It is SYS1.NUCLEUS and LPA modules that cannot be in PDSEs. LNKLST modules
can be.. And for most cases dynamic LPA
At 02:28 + on 10/25/2010, john gilmore wrote about Re: PDSE versus PDS:
The decision not to support IPL-time use of PDSEs was an
unconscionable one. It would indeed be easy to caricature it as
sabotage.
You have a "Chicken and Egg" situation with IPL Time support for
PDSEs
On 10/25/2010 1:38 AM, Paul Gilmartin wrote:
I understand that when a PDS member name is removed by BLDL
aliases are not removed. Whether this is "radically
deficient" depends in large part on what happens when the
remaining aliases are referenced or when the PDS is
compressed. I don't know.
On Mon, 25 Oct 2010 02:28:32 +, john gilmore wrote:
>
>The decision not to support IPL-time use of PDSEs was an unconscionable one.
>It would indeed be easy to caricature it as sabotage.
>
Perhaps likewise the decision not to support network-mounted files
at IPL-time. But Mr. Blair is w
William Blair wrote
| . . . back and forth, back and forth, as long as no Program Object-only
constructs are included . . .
This is nearly correct; but 1) the PDSE-only constructs are usually the point;
and 2) the maximal size of a PDS-resident load module is 16 megabytes and that
of a PDSE
Charles Mills asked:
| A PDSE can hold program objects that are effortlessly
| converted to conventional load modules when you copy
| them to a PDS. How's that?
IEBCOPY invokes the Program Binder to do the conversion. For example:
> IEB1135I IEBCOPY FMID HDZ1A10 SERVICE LEVEL NONE
On Fri, 2010-10-22 at 07:44 -0400, Veilleux, Jon L wrote:
> Which is a terrible idea when it comes to security. Combining DATA and
> PROGRAMs in one directory can open you up to a lot of integrity issues.
>
If the data is read-only and the directory read/execute other than to
the owner, why woul
On 22 October 2010 16:08, Paul Gilmartin wrote:
> On Fri, 22 Oct 2010 12:58:05 -0700, Charles Mills wrote:
>>
>>A PDSE can hold program objects that are effortlessly converted to
>>conventional load modules when you copy them to a PDS. How's that?
>>
>>From: IBM Mainframe Discussion List [mailto:i
On Fri, 22 Oct 2010 12:58:05 -0700, Charles Mills wrote:
>
>A PDSE can hold program objects that are effortlessly converted to
>conventional load modules when you copy them to a PDS. How's that?
>
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
>Of Tom Marchant
>Sent: F
ed to
conventional load modules when you copy them to a PDS. How's that?
Charles
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Friday, October 22, 2010 4:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE versus PDS
On Thu, 21 Oct 2010 14:5
Joel C. Ewing pisze:
[...]
Re HFS/ZFS file-level security:
But isn't default security in UNIX normally inherited from the directory
level?
No. It usually takes a place in Windows or Novell, and in fact does not
mean that inheritance must be used.
In Unix world file attributes are "inherited
Veilleux, Jon L pisze:
Yes, security is at the file level, but there are way too many tasks and users
that 'need' UID0 and can, therefore, bypass file-level security.
But this is unrelated to the previous sentence about keeping programs
and other files in common directory.
--
Radoslaw Skoru
On 10/22/2010 07:32 AM, Tom Marchant wrote:
On Fri, 22 Oct 2010 08:13:36 -0400, Veilleux, Jon L wrote:
Because, usually data files are R/W and PROGRAM files should be R/O to
prevent inadvertent (or not) updates should someone be able to bypass the
UNIX security bits on the files.
As Radoslaw
22, 2010 8:33 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE versus PDS
On Fri, 22 Oct 2010 08:13:36 -0400, Veilleux, Jon L wrote:
>Because, usually data files are R/W and PROGRAM files should be R/O to
prevent inadvertent (or not) updates should someone be able to bypass the UNIX
security bits
..@bama.ua.edu] On Behalf
Of Tom Marchant
>Sent: Friday, October 22, 2010 7:57 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: PDSE versus PDS
>
>On Fri, 22 Oct 2010 07:44:56 -0400, Veilleux, Jon L wrote:
>
>>Combining DATA and PROGRAMs in one di
idea to combine different
functions within a single directory.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Tom Marchant
Sent: Friday, October 22, 2010 7:57 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE versus PDS
On Fri, 22 Oct 2010 07
Veilleux, Jon L pisze:
Which is a terrible idea when it comes to security. Combining DATA and PROGRAMs
in one directory can open you up to a lot of integrity issues.
Not quite, because you can set security at file level. Caution: in fact
we don't talk here about operational data, rather quiva
On Fri, 22 Oct 2010 07:44:56 -0400, Veilleux, Jon L wrote:
>Combining DATA and PROGRAMs in one directory can open you
>up to a lot of integrity issues.
Can it? Why?
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archi
, 2010 8:03 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE versus PDS
On Thu, 21 Oct 2010 22:22:10 +0200, R.S. wrote:
>
>Load modules can live in PDS as well as in PDSE.
>Every program that can live in PDS can also live in PDSE.
>Minor caution: PDSE cannot contain both DATA and PRO
On Thu, 21 Oct 2010 14:59:18 -0700, Charles Mills wrote:
>Conventional load modules can live in PDSEs.
Not quite. You can copy a load module from a PDS to a PDSE and
IEBCOPY converts it into a program object.
--
Tom Marchant
-
On Thu, 21 Oct 2010 14:59:18 -0700, Charles Mills wrote:
>Conventional load modules can live in PDSEs.
>
I'm not so sure. I understand that IEBCOPY (sometimes?)
invokes Binder to manipulate PDSE contents (Because Program
management owns the only supported interfaces to PDSE
load libraries? Even
On Thu, 21 Oct 2010 22:18:16 +0200, R.S. wrote:
>
>> Should it be ZFS rather than zFS?
>What do you mean? Official nomenclature?
>I believe that you will easily find 'all-uppercase' wording in official
>IBM documents. Oh, maybe you simply miss our favorite USS quarrel ?
> It's quite obvious it stan
On 21 Oct 2010 15:51:41 -0700, in bit.listserv.ibm-main you wrote:
>On Thu, 21 Oct 2010 14:57:43 -0500
>Paul Gilmartin wrote:
>
>> Should it be ZFS rather than zFS?
>
>You are one sick puppy ;-)
>Let's see - change the IPL sequence, run z/OS under USS, get rid of
>JCL ...
>Ahhh . . . now I see wh
On Thu, 21 Oct 2010 22:22:10 +0200, R.S. wrote:
>
>Load modules can live in PDS as well as in PDSE.
>Every program that can live in PDS can also live in PDSE.
>Minor caution: PDSE cannot contain both DATA and PROGRAM members
>concurrently. PDS does not distinguish such objects - member is a
>member
On Thu, 21 Oct 2010 14:57:43 -0500
Paul Gilmartin wrote:
> Should it be ZFS rather than zFS?
You are one sick puppy ;-)
Let's see - change the IPL sequence, run z/OS under USS, get rid of
JCL ...
Ahhh . . . now I see where you're heading.
Talk about the parasite eating the dog.
Shane ...
---
>FWIW I don't use them for source code because I worry about loss of data.
>Perhaps it's a foolish worry, and I have never had a PDSE problem, but I have
>seen too many dire posts here not to be concerned.
Most of the posts are about load modules (programme objects) and sharing.
A single user da
Conventional load modules can live in PDSEs.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Chase, John
Sent: Thursday, October 21, 2010 8:25 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PDSE versus PDS
"Program objects"
: Re: PDSE versus PDS
>>consider as a method PDS old compared to PDSE.
>Well, if your installation likes performance problems, go right ahead.
Barbara, you have to learn to stop beating around the bush and tell us what
you really feel!
(8-{]}
BTW, I used to be a big fan of PDSE.
Now, exc
W dniu 2010-10-21 17:24, Chase, John pisze:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of zMan
On Thu, Oct 21, 2010 at 1:29 AM, Ted MacNEIL
wrote:
Barbara, you have to learn to stop beating around the bush and tell
us what you really feel!
(8-{]}
BTW, I used to
On Thu, 21 Oct 2010 15:04:44 -0300, Clark Morris wrote:
>
>Can load modules be housed in zFS? program objects? DLLs? Would it be
>better to functionally stabilize PDSE and have the zFS the strategic
>direction forward? Would there be a performance improvement. Given
>that PDSE is NOT available a
W dniu 2010-10-21 21:57, Paul Gilmartin pisze:
On Thu, 21 Oct 2010 15:04:44 -0300, Clark Morris wrote:
Can load modules be housed in zFS? program objects? DLLs? Would it be
better to functionally stabilize PDSE and have the zFS the strategic
direction forward? Would there be a performance imp
On 21 Oct 2010 06:58:53 -0700, in bit.listserv.ibm-main you wrote:
>On Thu, Oct 21, 2010 at 1:29 AM, Ted MacNEIL wrote:
>> Barbara, you have to learn to stop beating around the bush and tell us what
>> you really feel!
>> (8-{]}
>>
>> BTW, I used to be a big fan of PDSE.
>> Now, except for sourc
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of zMan
>
> On Thu, Oct 21, 2010 at 1:29 AM, Ted MacNEIL
wrote:
> > Barbara, you have to learn to stop beating around the bush and tell
us what you really feel!
> > (8-{]}
> >
> > BTW, I used to be a big fan of PDSE.
> >
On Thu, Oct 21, 2010 at 1:29 AM, Ted MacNEIL wrote:
> Barbara, you have to learn to stop beating around the bush and tell us what
> you really feel!
> (8-{]}
>
> BTW, I used to be a big fan of PDSE.
> Now, except for source code, I won't use them unless I have to.
>
> Rather than constantly compr
>>consider as a method PDS old compared to PDSE.
>Well, if your installation likes performance problems, go right ahead.
Barbara, you have to learn to stop beating around the bush and tell us what you
really feel!
(8-{]}
BTW, I used to be a big fan of PDSE.
Now, except for source code, I won't
>In the installation they want all files are PDS PDSE rather than because they
>consider as a method PDS old compared to PDSE.
Well, if your installation likes performance problems, go right ahead.
*Especially* if any of your PDSs contain recfm=V(x) records.
IBM development has told me (through
: Wednesday, October 20, 2010 8:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: PDSE versus PDS
Hi colleagues,
In the installation they want all files are PDS PDSE rather than because they
consider as a method PDS old compared to PDSE.
I would like the experience of others on their premises and in which cases are
Hi colleagues,
In the installation they want all files are PDS PDSE rather than because they
consider as a method PDS old compared to PDSE.
I would like the experience of others on their premises and in which cases are
recommended one or the other.
Is there any document about it ?
Thank you v
53 matches
Mail list logo
