On Tue, 29 Sep 2020, at 23:57, Paul Gilmartin wrote:
> Similarly, I once created a data set such as:
> DD DISP=(NEW,CATLG),DSN=hlq.X.FOO-BAR
> No problem. Later, I tried
> DD DISP=(NEW,CATLG),DSN=hlq.Y.FOO-BAR,
>DCB=hlq.X.FOO-BAR
> Again, the hyphen caused a syntax error. The re
> Subject: Re: [External] Re: blanks at the end of Unix file names - was
> LMINIT cannot handle concatenation with more than 16 data sets?
>
>
>
> I *think* it remembers the option on the main panel, assuming you actually
> exit ISPF rather than 622'ing.
>
>
>
>
ussion List On Behalf Of
Charles Mills
Sent: Wednesday, September 30, 2020 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: blanks at the end of Unix file names - was LMINIT
cannot handle concatenation with more than 16 data sets?
I *think* it remembers the option on the main pan
Behalf
Of Paul Gilmartin
Sent: Wednesday, September 30, 2020 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: blanks at the end of Unix file names - was LMINIT
cannot handle concatenation with more than 16 data sets?
On Wed, 30 Sep 2020 10:51:36 -0700, Charles Mills wrote:
>
On Wed, 30 Sep 2020 10:51:36 -0700, Charles Mills wrote:
>
>For dataset delete from 3.4?
>
>On the main panel
>
>Enter "/" to select option
>/ Confirm Data Set Delete
>/ Confirm Member Delete
>
>And on the delete panel
>
>Enter "/" to select option
> Set data s
U] On Behalf
Of Paul Gilmartin
Sent: Wednesday, September 30, 2020 8:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: blanks at the end of Unix file names - was LMINIT
cannot handle concatenation with more than 16 data sets?
On Wed, 30 Sep 2020 13:59:02 +, Pommier, Rex wrote:
- was LMINIT cannot handle
concatenation with more than 16 data sets?
On Wed, 30 Sep 2020 15:44:14 +, Seymour J Metz wrote:
>Applications should diagnose but not "correct" user errors, and should use
>comoon system services to do so, where they exist. OS developers should
On Wed, 30 Sep 2020 15:44:14 +, Seymour J Metz wrote:
>Applications should diagnose but not "correct" user errors, and should use
>comoon system services to do so, where they exist. OS developers should
>provide services for validation. Neither application developers nor OS
>developers sho
: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, September 30, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: blanks at the end of Unix file names - was LMINIT cannot handle
concatenation with more than 16 data
-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, September 30, 2020 6:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: blanks at the end of Unix file names - was LMINIT cannot handle
concatenation with more than 16 data sets?
On Wed, 30 Sep 2020 08:01:09 -0500, Walt Farrell wrote
On Wed, 30 Sep 2020 13:59:02 +, Pommier, Rex wrote:
>
>OK, thanks. I hadn't considered the "I'm going to because I can" angle,
>namely because I'm more of the "why would you even want to do that, even if
>you can, it'll cause problems." Kind of guy. But I know the adage, every time
>somebo
mething foolproof, the universe comes up with a bigger fool.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Tuesday, September 29, 2020 5:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: blanks at the end of Unix file names - was
On Wed, 30 Sep 2020 08:01:09 -0500, Walt Farrell wrote:
>On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote:
>
>>Applications should not "validate" filenames before attempting to open or
>>create a file. Present the name to the file system API and report any error
>>back to the user. Applic
On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote:
>Applications should not "validate" filenames before attempting to open or
>create a file. Present the name to the file system API and report any error
>back to the user. Application filename validation is what leads to these
>inconsiste
On Tue, 29 Sep 2020 19:58:06 -0500, Paul Gilmartin wrote:
>On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote:
>
>>Applications should not "validate" filenames before attempting to open or
>>create a file. Present the name to the file system API and report any error
>>back to the user. App
sistencies.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, September 29, 2020 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: blanks at the end of Unix file names - was LMINIT cannot handle
concaten
On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote:
>Applications should not "validate" filenames before attempting to open or
>create a file. Present the name to the file system API and report any error
>back to the user. Application filename validation is what leads to these
>inconsisten
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Tuesday, September 29, 2020 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: blanks at the end of Unix file names - was LMINIT cannot handle
concatenation with more than 16 data sets?
On Tue, 29 Sep
On Tue, 29 Sep 2020 21:28:26 +, Pommier, Rex wrote:
>
>Serious question - what would be the purpose for doing this? I know you can,
>I'm just trying to grasp a good reason for doing so. Security by obscurity
>(not valid in my mind)?
>
Because it's possible. Someone will do it. Test suite
Gil,
Serious question - what would be the purpose for doing this? I know you can,
I'm just trying to grasp a good reason for doing so. Security by obscurity
(not valid in my mind)?
Thanks,
Rex
Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT
',
distinct UNIX
equ...@listserv.ua.edu>
Sent: Tuesday, September 29, 2020 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] LMINIT cannot handle concatenation with more than 16
data sets?
On Tue, 29 Sep 2020 19:48:31 +, Seymour J Metz wrote:
>Broken As Designed (BAD). It actually takes less code
On Tue, 29 Sep 2020 19:48:31 +, Seymour J Metz wrote:
>Broken As Designed (BAD). It actually takes less code to do it right than to
>do it wrong with the current level of DFSMSdfp, although the broken code
>already exists.
RFE?
DESERV? Does DESERV support wildcards, needed by ISRDDN? I
Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, September 28, 2020 9:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] LMINIT cannot handle concatenation with more than 16
data sets?
On Mon, 28 Sep 2020 20:15:43 +, P
On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote:
>Robert,
>
>IDK if this specifically LMMINIT, but when I enter ISRDDN and try to browse a
>library concatenation with greater than 16 libraries in it, I get this:
>
>Only the first sixteen data sets are shown in this list. ISRDDN uses ISPF
on behalf of
Robert Prins
Sent: Monday, September 28, 2020 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LMINIT cannot handle concatenation with more than 16 data sets?
Came across this in an edit macro, and the existing code works around it by
using QBASELIB and testing each dataset in the
: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] LMINIT cannot handle concatenation with more than 16 data
sets?
Came across this in an edit macro, and the existing code works around it by
using QBASELIB and testing each dataset in the ISPPLIB concatenation separately
for a selected member.
Does
Came across this in an edit macro, and the existing code works around it by
using QBASELIB and testing each dataset in the ISPPLIB concatenation separately
for a selected member.
Does anyone know if this limit of 16 is still present, I don't really have a way
to test this right now.
Thanks,
27 matches
Mail list logo
