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
Also known as the “chicken out” prompt. :-)
On Wed, Sep 30, 2020 at 14:50 Pommier, Rex wrote:
> z/OS 2.4, it does not remember shutting those options off. I'm OK with
> the behavior and could take it either way but I know I'd be recovering user
> datasets much more often if the "are you
z/OS 2.4, it does not remember shutting those options off. I'm OK with the
behavior and could take it either way but I know I'd be recovering user
datasets much more often if the "are you sure" wasn't there.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
I *think* it remembers the option on the main panel, assuming you actually exit
ISPF rather than 622'ing.
I *like* the behavior. I don't mind the extra "are you sure?" on a single
dataset delete -- has saved my @ss once or twice -- and if I am deleting a
bunch, I set it off on the first
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
> And I was irritated when ISPF, which I had long been using suddenly began
> requiring confirmation on "Delete"; no profile to disable it.
For dataset delete from 3.4?
On the main panel
Enter "/" to select option
/ Confirm Data Set Delete
/ Confirm Member Delete
And on
Rule 0: If your data-entry form has syntax requirements, indicate them on the
form. That includes requiring or prohibiting punctuation.
As for uppercasing the local part of an e-mail address, that is the sin for
which there is no forgiveness.
--
Shmuel (Seymour J.) Metz
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
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
should attempt to validate externally defined data unless they
Yeah, like every rule, there are exceptions. If on some particular system there
were a very high overhead for a failed file open (or some analogous operation)
then that might justify pre-validating an operand.
Charles
-Original Message-
From: IBM Mainframe Discussion List
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
Gil,
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 somebody
makes something foolproof, the universe comes up
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.
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
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.
+1
On 2020-09-30 7:59 AM, 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 inconsistencies.
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
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
inconsistencies.
Charles
-Original Message-
From: IBM
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
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
20 matches
Mail list logo
