Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 restriction is > documented, but why not be uniform? As JCL supports weird dsnames (eg those of tape datasets, perhaps from foreign OSes) provided they are in quotes, would those lines have been ok if the DCB= value was quoted? > As long as STOW and BLDL have existed they have supported > mixed-case member names. Long ago I'm fairly sure I saw possibly not just mixed-case, but every possible character in use in member names of (I think) the SMPMTS, or if not that, one of the other internal SMP/E PDSes. IIRC, SMP/E was just using an incrementing binary counter to create successive 'member names' for storing things. It worked fine - for SMP/E itself - but wasn't something one could work with via ISPF. But then again, one didn't need to. > But most high-level user interfaces > aren't even case-insensitive: they don't find any member name > containing lower case characters. An IBM employee has said > on this list that those names are invalid. Well they weren't invalid back then. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 sure" wasn't there. > > > > Rex > > > > -Original Message- > > From: IBM Mainframe Discussion 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 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 confirmation panel. > > > > I would rather hit an extra enter a hundred times than have to recover a > mistakenly deleted dataset once. > > > > YMMV. That's what makes horse races. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > 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: > > > > > >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 set delete confirmation off > > > > > But they reset in the next session. Couldn't they have made it opt-in > rather than opt-out? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 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 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 confirmation panel. I would rather hit an extra enter a hundred times than have to recover a mistakenly deleted dataset once. YMMV. That's what makes horse races. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 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: > >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 set delete confirmation off > But they reset in the next session. Couldn't they have made it opt-in rather than opt-out? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. 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 confirmation panel. I would rather hit an extra enter a hundred times than have to recover a mistakenly deleted dataset once. YMMV. That's what makes horse races. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 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: > >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 set delete confirmation off > But they reset in the next session. Couldn't they have made it opt-in rather than opt-out? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: > >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 set delete confirmation off > But they reset in the next session. Couldn't they have made it opt-in rather than opt-out? >Or have I misunderstood you? Or is this on V2R3 or R4? > My experience is old. Perhaps the behavior has changed. When I reported my dismay here when it was new, I got rebuttals such as: But what if you intend to disable it momentarily but forget to re-enable it in your next session? ... Is there a "Just once" versus "Forever" checkbox? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
> 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 the delete panel Enter "/" to select option Set data set delete confirmation off Or have I misunderstood you? Or is this on V2R3 or R4? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 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: > >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 with a bigger fool. > I like the phrasing, "... you've underestimated the resourcefulness of your fool." I endorse Doug Gwyn's maxim: Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. Looking for a citation, I found: https://opensource.com/business/14/12/linux-philosophy I'm bookmarking it. But I believe in highway guardrails. Less in sysadmins who "alias rm='rm -i'". And I was irritated when ISPF, which I had long been using suddenly began requiring confirmation on "Delete"; no profile to disable it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, September 30, 2020 12:01 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 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 should attempt to validate externally defined data unless they >*REALLY* know what the rules are: that means hands off of names and e-mail >addresses if you don't know in detail what is permitted in every culture and >in the relevant RFCs. +1 Many (most) web forms reject my RFC-822 valid email address: Paul Gilmartin when I copy-and-paste it from my email header. And they force the local-part to monocase, violating the RFC. And my phone, copied from my Contacts entry: (720) 382- They accept only digits. Some add insult to injury by then reformatting it as I had tried to enter it. And credit card numbers with groups of 4 digits. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 should attempt to validate externally defined data unless they >*REALLY* know what the rules are: that means hands off of names and e-mail >addresses if you don't know in detail what is permitted in every culture and >in the relevant RFCs. +1 Many (most) web forms reject my RFC-822 valid email address: Paul Gilmartin when I copy-and-paste it from my email header. And they force the local-part to monocase, violating the RFC. And my phone, copied from my Contacts entry: (720) 382- They accept only digits. Some add insult to injury by then reformatting it as I had tried to enter it. And credit card numbers with groups of 4 digits. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 *REALLY* know what the rules are: that means hands off of names and e-mail addresses if you don't know in detail what is permitted in every culture and in the relevant RFCs. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: 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 sets? 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. Application filename validation is what leads to these >>inconsistencies. > >I will strongly agree with that, Charles. > However, queue latency provides a (weak) motive for the reader to perform syntax checking so gross errors can be reported promptly. >It goes along with not trying to pre-check the security results ... > Previously, you've mentioned TOCTTOU. Some monitors harshly investigate failed access attempts. For consistency they should likewise investigate security queries with negative results lest a (fe)malefactor try to avoid causing alarms. On Wed, 30 Sep 2020 07:56:57 -0500, Walt Farrell wrote: > >RACF required applications to present the password in upper-case, so the >applications were not at fault for doing so. Blame RACF for that one. > Applications should not attempt to correct user errors. I blame them on that account. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 [mailto:IBM-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 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 >>inconsistencies. > >I will strongly agree with that, Charles. > However, queue latency provides a (weak) motive for the reader to perform syntax checking so gross errors can be reported promptly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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: > >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 with a bigger fool. > I like the phrasing, "... you've underestimated the resourcefulness of your fool." I endorse Doug Gwyn's maxim: Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. Looking for a citation, I found: https://opensource.com/business/14/12/linux-philosophy I'm bookmarking it. But I believe in highway guardrails. Less in sysadmins who "alias rm='rm -i'". And I was irritated when ISPF, which I had long been using suddenly began requiring confirmation on "Delete"; no profile to disable it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 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 LMINIT cannot handle concatenation with more than 16 data sets? 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 suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. 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 restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. > > >Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT >', >distinct UNIX files, would be conflated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 >>inconsistencies. > >I will strongly agree with that, Charles. > However, queue latency provides a (weak) motive for the reader to perform syntax checking so gross errors can be reported promptly. >It goes along with not trying to pre-check the security results ... > Previously, you've mentioned TOCTTOU. Some monitors harshly investigate failed access attempts. For consistency they should likewise investigate security queries with negative results lest a (fe)malefactor try to avoid causing alarms. On Wed, 30 Sep 2020 07:56:57 -0500, Walt Farrell wrote: > >RACF required applications to present the password in upper-case, so the >applications were not at fault for doing so. Blame RACF for that one. > Applications should not attempt to correct user errors. I blame them on that account. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 >inconsistencies. I will strongly agree with that, Charles. It goes along with not trying to pre-check the security results of something like opening or creating a file. They should just try to take the action as requested by the user, and if the system fails the operation they should report the failure. There are too many possibilities of error in trying to duplicate the security requests the system will make anyway, which could lead to either false positive or false negative results, or compromise auditing. Let the component that is responsible for the security make the security decision. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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. Application filename validation is what leads to these >>inconsistencies. >> >I'll emphasize that. Applications and UIs should not modify filenames -- add >blanks; >remove blanks; change case, etc. A related problem arose a while ago when the >requirement (possibly delusional) for mixed-case passwords appeared. Many >applications which though they were doing a users a favor by converting >passwords >to upper case had to be modified. The operation should always have been left >to >the security product. RACF required applications to present the password in upper-case, so the applications were not at fault for doing so. Blame RACF for that one. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
+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. 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 concatenation with more than 16 data sets? 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 suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. 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 restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 >inconsistencies. > I'll emphasize that. Applications and UIs should not modify filenames -- add blanks; remove blanks; change case, etc. A related problem arose a while ago when the requirement (possibly delusional) for mixed-case passwords appeared. Many applications which though they were doing a users a favor by converting passwords to upper case had to be modified. The operation should always have been left to the security product. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 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 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 suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. 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 restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. > > >Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT >', >distinct UNIX files, would be conflated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 suites should verify that other components support it properly. The security needn't be by obscurity. The security product or ACLs could enforce chosen rules. To minimize programmer astonishment the syntax and semantics should be uniform throughout the system. I have a couple experiences older than OMVS. I used ISPF LM services to create some PDS members with hyphens in their names, e.g. FOO-BAR. Subsequently I decided to add ISPF statistics to such members with LMMSTATS. LMMSTATS deems the hyphen a syntax error. 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 restriction is documented, but why not be uniform? As long as STOW and BLDL have existed they have supported mixed-case member names. But most high-level user interfaces aren't even case-insensitive: they don't find any member name containing lower case characters. An IBM employee has said on this list that those names are invalid. But why doesn't STOW report them as errors. I disagree with Emerson about consistency. > > >Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT >', >distinct UNIX files, would be conflated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?
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 files, would be conflated. -- gil The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] LMINIT cannot handle concatenation with more than 16 data sets?
No wild cards, but it does support retrieving a complete member list for the concatenation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@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 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 don't see that in the doc. On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote: > >..., but when I enter ISRDDN and try to browse a library concatenation >with greater than 16 libraries in it, ... Does DESERV support UNIX directories? This is tantalizing: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4280.htm Each name is comprised of a two-byte length field followed by the characters of the name. When searching for names with less than eight characters, the names are padded on the right with blanks to make up eight characters. Names greater than eight characters will have trailing blanks and nulls stripped (to a minimum length of eight) before the search. What, other than UNIX files would have "[n]ames greater than eight characters"? Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. LMINIT refuses UNIX files. Something about F1 DSCB. Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 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 don't see that in the doc. On Mon, 28 Sep 2020 20:15:43 +, Pommier, Rex wrote: > >..., but when I enter ISRDDN and try to browse a library concatenation >with greater than 16 libraries in it, ... Does DESERV support UNIX directories? This is tantalizing: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4280.htm Each name is comprised of a two-byte length field followed by the characters of the name. When searching for names with less than eight characters, the names are padded on the right with blanks to make up eight characters. Names greater than eight characters will have trailing blanks and nulls stripped (to a minimum length of eight) before the search. What, other than UNIX files would have "[n]ames greater than eight characters"? Alas, the padding and stripping mean that 'WOMBAT', 'WOMBAT ', and 'WOMBAT ', distinct UNIX files, would be conflated. LMINIT refuses UNIX files. Something about F1 DSCB. Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] LMINIT cannot handle concatenation with more than 16 data sets?
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? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe 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 +, 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 >services to process DD names and these services are limited to >concatenations of sixteen or fewer data sets. > >Whichleeads me to believe the 16 limit is still there. z/OS 2.4. > Perhaps worse, it does not report members in UNIX files in directories among the 16 supported catenands. So if I have member WOMBAT in a zFS in a SYSLIB concatenation, it may show me a WOMBAT in a later PDS(E) whereas HLASM will use the one in the zFS. Treacherous indeed. I suspect that ISPF uses the antique technique of allocating each catenand with DSORG=PS and parsing directory blocks. Would DESERV do better? I went to SR on this: Record 55733,033,000 Created:04/11/22 ... got an elaborate WAD. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] LMINIT cannot handle concatenation with more than 16 data sets?
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 >services to process DD names and these services are limited to >concatenations of sixteen or fewer data sets. > >Whichleeads me to believe the 16 limit is still there. z/OS 2.4. > Perhaps worse, it does not report members in UNIX files in directories among the 16 supported catenands. So if I have member WOMBAT in a zFS in a SYSLIB concatenation, it may show me a WOMBAT in a later PDS(E) whereas HLASM will use the one in the zFS. Treacherous indeed. I suspect that ISPF uses the antique technique of allocating each catenand with DSORG=PS and parsing directory blocks. Would DESERV do better? I went to SR on this: Record 55733,033,000 Created:04/11/22 ... got an elaborate WAD. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LMINIT cannot handle concatenation with more than 16 data sets?
DFSMSdfp limits a PDS concatenation to 255 extens, where a PDSE or Unix file counts as one extent. You probably need an RFE for ISPF to exploit that support. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List 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 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, Robert -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://secure-web.cisco.com/1UO6oH8s9wM6ggimHQU5QNOCJGmUVt8k87ANYhWKsStKZCm8VEa-TWikbDlfKFttgWcMcyypKN3lYsLWGHY49y95OCSOUD2dcpLqifD8yReMOkED7dt0DfIw8TsJXWliHBs3ZoQagn-n4TsPSbohQR3t2OW6TFUdm8avJPzUKJ9GKuCkVMDUhRyvVNGw3cU4gfMrvHTlf5Mj4BXRMFFfAkWFDr6vFwB1SUcpvlVroLtJT-YSrd1nHMx64hAC8d8X9BFL8xLVn50BrsY0Jan2C9Jd3spQw2ZVV5TOb9pvPIkErEm4bCmu6GkBvqx-MMzKcj8AME5kqGMJHiSntVIGb_u4Cludq5bzmipo1sFSe1SozGar-9o5_RrSHii1Tjm4Fyir8KCaUL0YHPqwxnpgWdde8IE2TXHfAf74v8MtnMC25FDRZzxTTKocahw-6pOXi/https%3A%2F%2Fprino.neocities.org%2F Some REXX code for use on z/OS - https://secure-web.cisco.com/1g98Ki4ecHIy5-u7SFrTOcuH-1_kN8GGU1sUSoe4txArQt1CvL9ZB6saK0vJN6eGHeLUZUV1wYhra_y_JIAQPzrK7m3pFQZNZUGYA0ZNe50Lo9BcE_h4ugXWZPTIEGdU2xjaIVaJ8WY-F-oS_znmw-4mkMml6iwc_R_jqPGRqHTdP25P2w2qOEn2rXQ_yMU90mGx6yguwZs2plJnFlaR1nhbpPZRYFb-OvMvyNk0RRawQvot7BS6_SPftPKy16eUSYmO82lAUTgxhsyVoP-yXD4AzjzrXgyk-qmgAY9vEqpVfzrphVx2UAh7DFRNnJZBS92Jg-H_hcc9Hl1cOaJLBt9oDmbNjDu_lc5r_nkHFeTgQmlTa3qtAdv5INFKcLWOVsTYPDosMw4NTPf9FRb666XIFfZzIwyY3VLoD5imBD9NcgUBUKk9tTKxz6S2MWRhB/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] LMINIT cannot handle concatenation with more than 16 data sets?
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 services to process DD names and these services are limited to concatenations of sixteen or fewer data sets. Which leads me to believe the 16 limit is still there. z/OS 2.4. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Prins Sent: Monday, September 28, 2020 4:46 PM To: 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 anyone know if this limit of 16 is still present, I don't really have a way to test this right now. Thanks, Robert -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/ Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 anyone know if this limit of 16 is still present, I don't really have a way to test this right now. Thanks, Robert -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/ Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
