[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Friday, January 13, 2017 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Smart enough (was Re: SDB and Program Object Library)
On Thu, 12 Jan 2017 16:41:58 -0500, Farley, Peter wrote:
> My unfortunate experience has b
ginal Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Friday, January 13, 2017 8:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Smart enough (was Re: SDB and Program Object Library)
>
> On Fri, Jan 13, 201
On Fri, Jan 13, 2017 at 9:42 AM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> Thanks Tom. Totally agree. "Give a man a fish and you feed him for a
> day; teach a man to fish and you feed him for a lifetime. (Maimonides)"
>
I prefer the variant: "Give a man a fish and you feed
y, January 13, 2017 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Smart enough (was Re: SDB and Program Object Library)
On Thu, 12 Jan 2017 16:41:58 -0500, Farley, Peter wrote:
> My unfortunate experience has been that ordinary users
>are not considered smart enough to see or understan
Tom Marchant wrote:
>This is one of my pet peeves, so I'll extend your rant a bit.
>Ever since I started in this business, people have warned me that certain
>people aren't smart enough to understand, and that giving them too much
>information will cause problems. As an application programmer,
On Fri, Jan 13, 2017 at 8:15 AM, Tom Marchant <
000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> On Thu, 12 Jan 2017 16:41:58 -0500, Farley, Peter wrote:
>
> > My unfortunate experience has been that ordinary users
> >are not considered smart enough to see or understand what
> >storage
On Thu, 12 Jan 2017 16:41:58 -0500, Farley, Peter wrote:
> My unfortunate experience has been that ordinary users
>are not considered smart enough to see or understand what
>storage admins do.
This is one of my pet peeves, so I'll extend your rant a bit.
Ever since I started in this
I think that SDB can't decide on a BLKSIZE when LRECL=0. In any case, for
a Program Object PDSE, the BLKSIZE is nearly irrelevant. PDSEs always use
a physical record length of 4K. For non-PO PDSEs, the nominal BLKSIZE is
faked up for you as needed.
Use SDB (0) when you have an LRECL, and 32K-8
On Wed, 11 Jan 2017 18:24:57 -0700, Lizette Koehler wrote:
>I just used Option 3.2 and allocated a PDSE with LRECL 80 and Blksize 0 with
>Version 2 (z/OS V2.1)
>
>No issues - it took it fine and the Blksize is 32760.
>
Did you populate it by copying a load module to a program object?
FWIW, I
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, January 12, 2017 1:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SDB and Program Object Library
>
> On 2017-01-12 06
o:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, January 12, 2017 4:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDB and Program Object Library
On 2017-01-12 14:23, Allan Staller wrote:
> Allocation
>
> Do these ACS routines operate
> o at data set creation?
On 2017-01-12 14:23, Allan Staller wrote:
> Allocation
>
> Do these ACS routines operate
> o at data set creation?
> o at OPEN?
> o Both?
>
"Allocation" is dismayingly ambiguous. But I assume you mean
allocation as in DISP=NEW ratner than allocation as in DISP=OLD.
Data Set Utility tells me:
enough to see or understand what storage admins do.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, January 12, 2017 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDB and Program Object Library
Actually, I might suggest using TEST under the ISMF function in ISPF.
But for verbose, you would need to get your friendly Storage Admin to add WRITE
Statements to the SMS routines.
Lizette
--
For IBM-MAIN subscribe / signoff
Allocation
On 2017-01-12 06:51, Allan Staller wrote:
> Bad ACS routuines?
>
Do these ACS routines operate
o at data set creation?
o at OPEN?
o Both?
Is there a way for an affected user to determine what effect these ACS routines
have? Something like a "verbose" option?
NO
>
> Is there
On 2017-01-12 06:51, Allan Staller wrote:
> Bad ACS routuines?
>
Do these ACS routines operate
o at data set creation?
o at OPEN?
o Both?
Is there a way for an affected user to determine what effect these ACS
routines have? Something like a "verbose" option?
>
> Is there any rationale to
IMHO it is plain stupid, but "it works as documented". Dot. End of
discussion. Any documented stupidity is authorised to remain unchanged.
I wish I would have SDB for DSORG=PO,RECFM=U with the value of 32760.
All exceptions could be solved with providing explicit BLKSIZE value.
BTW: I can't
Bad ACS routuines?
In order to copy a load module library to a progam object library I used ISPF
Data Set Utility to allocate the new library with DSNTYPE=LIBRARY. Believing
that "SDB knows best," I left BLKSIZE blank. ISPF warned me. I told it,
"Trust me." I went to Move/Copy Utility and
e Koehler
> Sent: Wednesday, January 11, 2017 6:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SDB and Program Object Library
>
> I just used Option 3.2 and allocated a PDSE with LRECL 80 and Blksize 0 with
> Version 2 (z/OS V2.1)
>
> No issues - it took it fine and t
Gilmartin
> Sent: Wednesday, January 11, 2017 5:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SDB and Program Object Library
>
> In order to copy a load module library to a progam object library I used ISPF
> Data Set Utility to allocate the new library with DSNTYPE=LIBRARY.
In order to copy a load module library to a progam object library
I used ISPF Data Set Utility to allocate the new library with
DSNTYPE=LIBRARY. Believing that "SDB knows best," I left BLKSIZE
blank. ISPF warned me. I told it, "Trust me." I went to Move/Copy
Utility and tried the copy. It
21 matches
Mail list logo