Re: shopz UJ01255
it was superseded by UJ02346 in PUT2003 which was contained in RSU2006. so I would imagine that if it was already supped just 2 months later that getting it now would probably not be a productive use of your time. While you can install by PUT, I would not. I think it's far better to stick with RSU's. Less work (for me) and less problems. Unless you actually really and truly need one (or more) of the non-RSU (yet) fixes, I would not order them them, or at least not install them. There is too much chance of (eventual) error before the RSU testing is complete. Brian On Wed, 30 Sep 2020 21:24:27 -0500, R Hey wrote: >Thanks for the replies. > >I ordered UJ01255, it had PUT2001 (no RSU 8 months later). > >I did raise the issue with support, was told : > > UJ01255 was not included in RSU2001. > It didn't not meet the following criteria: > -Severity 1 or 2 > -HIPER > -PEFIX > -Security/integrity > -Special Attention > -Pervasiveness > >I've read/heard that one should order RECOMMENDED, then apply srcid(RSU). >I did an ORDER-ALL today for zos 2.3 & got 490 PTFs more than I got 2 weeks >ago for RECOMENDED. >20 of them has RSU2008, 391 had PUT. > >So if I apply RSU**, I'll miss 391+ PTFs. > >How do you guys do apply, srcid(PUT)? > >Thanks, >Rez > >-- >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: shopz UJ01255
Thanks for the replies. I ordered UJ01255, it had PUT2001 (no RSU 8 months later). I did raise the issue with support, was told : UJ01255 was not included in RSU2001. It didn't not meet the following criteria: -Severity 1 or 2 -HIPER -PEFIX -Security/integrity -Special Attention -Pervasiveness I've read/heard that one should order RECOMMENDED, then apply srcid(RSU). I did an ORDER-ALL today for zos 2.3 & got 490 PTFs more than I got 2 weeks ago for RECOMENDED. 20 of them has RSU2008, 391 had PUT. So if I apply RSU**, I'll miss 391+ PTFs. How do you guys do apply, srcid(PUT)? Thanks, Rez -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASMA500W using _boundary_ on ORG statement
CNOP 0,8? On 30/09/2020 14:13, Peter Relson wrote: >> ORG *,8 > Curious: Does this do anything that "DS0D" doesn't do? > Wouldn't "DS0D" be more typical for "I want the next thing to be on a > doubleword boundary? > It certainly is for those of us who learned assembler long before SECTALGN > (and this form of ORG) even existed. > > It might be true that the ASMA500W message is not the write message for > "ORG ,8" but that is assuming that you know what boundary is being > processed for such a case. The "null" first operand might have some effect > on things. Or maybe it really is just a parsing glitch (and is an error). > > Peter Relson > z/OS Core Technology Design > > > -- > 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: SMPe Sourceid in GLOBAL not in TARGET
Since I'm seeing nothing applied and no errors listed, my best guess is that any PTFs in the GLOBAL zone are; 1) Already applied 2) For different FMIDs from those that are already installed in the target zone 3) For a different SREL Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, September 30th, 2020 at 7:27 PM, Bill Giannelli wrote: > I have a sourceid in a global zone that doesnt show up in the target zone. > When I run an apply it fails with : > > APPLY > > PTFS > > APARS > > GROUPEXTEND > > NOJCLR > > BYPASS(HOLDSYS(DB2BIND,DOC,ACTION,DELETE)) > > CHECK > > . > > GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. > > How do I get the sourceid into the target zone? > > thanks > > Bill > > - > > 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
SMPe Sourceid in GLOBAL not in TARGET
I have a sourceid in a global zone that doesnt show up in the target zone. When I run an apply it fails with : APPLY PTFS APARS GROUPEXTEND NOJCLR BYPASS(HOLDSYS(DB2BIND,DOC,ACTION,DELETE)) CHECK . GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY COMMAND. How do I get the sourceid into the target zone? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: usleep()
I don't believe so. Which other platforms? https://man7.org/linux/man-pages/man3/usleep.3.html On Wed, Sep 30, 2020 at 4:19 PM Phil Smith III wrote: > The usleep() function in z/OS is documented as taking a single operand > that must be less than 1M; on other platforms, it must be *at least* 1M. It > also generates no error, and just returns instantly if you give it a value > of 1M or more. > > > > This seems.poor. Anyone got any insight/guesses? Yes, I realize it's > deprecated. > > > > All I can think of is that when it was implemented in z/OS it was done > deliberately to discourage use, but I'd rather it ABENDed than just > returning instantly and causing a spin, personally. > > > -- > 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
usleep()
The usleep() function in z/OS is documented as taking a single operand that must be less than 1M; on other platforms, it must be *at least* 1M. It also generates no error, and just returns instantly if you give it a value of 1M or more. This seems.poor. Anyone got any insight/guesses? Yes, I realize it's deprecated. All I can think of is that when it was implemented in z/OS it was done deliberately to discourage use, but I'd rather it ABENDed than just returning instantly and causing a spin, personally. -- 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, 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: FTPS Handshake Error
When you define the certificates to RACF do you have to issue some kind of RACF refresh command for ICSF? In my case we use Top Secret. I have followed your list of debug tips and I can't find anything wrong. Except for the question I posed. Thank you, Roberto On Wed, Sep 30, 2020 at 9:17 AM Wendell Lovewell < 01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote: > Hello Roberto. > > In RACF-land, I'd look for an ICH message on the console to make sure you > don't need to PERMIT the client or the server access to the keyring. I've > found the gsk trace file to be very helpful--if the security manager > doesn't tell you via a console message. Telling PAGENT about the security > change might also be needed on the side that's failing. > > Here is a section of some documentation I wrote up for debugging such > errors for one of our products: > > - > (One of the examples:) > EZD1287I TTLS Error RC: 406 Initial Handshake 477 > LOCAL: 172.29.127.60..1173 > REMOTE: 172.29.127.60..5401 > JOBNAME: MBXWL RULE: MBX_STC_Rule > > The RC values are most helpful. Since there is a policy used for both > inbound (MBX_CICS_Rule) and outbound (MBX_STC_Rule—note the rules in play > are also displayed on the console), there will likely be two EZD1287I > messages displayed if there is a problem. (Both sides will experience a > problem.) You can find an explanation for these in the SC14-7495-30 > Cryptographic Services System Secure Sockets Layer Programming manual, > currently in chapter 13. > > SC27-3651-30 IP Configuration Reference contains the syntax for the AT-TLS > policy (/etc/pagent_TTLS.conf). > > GC27-3652-30 IP Diagnosis Guide may be useful if you are getting GSK > errors. > > SA23-2292-30 Security Server RACF Command Language Reference contains the > syntax for the RACDCERT instructions. > > If you need to see the GKY messages, set the Trace value in the > TTLSGroupAction parms for both the MBX_CICS_Rule and MBX_STC_Rule to Trace > 255. When you upload /etc/pagent_TTLS.conf, the policy agent will > re-install the policy. > > If you make RACF changes to the keyrings, you need to tell the policy > agent to refresh it’s settings for them. You can do this by changing the > EnvironmentAction value & reloading the pagent_TTLS.conf file. > > - > > HTH, > Wendell > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Politics: Poli (many) - tics (blood sucking parasites) -- 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: NVAS MVS 2.1 help
Peter, We are running NVAS 2.1, but it has been a LONG time since we implemented it and I don't remember all of the details. Here is link to the manuals if you don't have it already: http://publib.boulder.ibm.com/tividd/td/NetViewAccessServices2.1.html IIRC there are 2 exits provided by IBM. One is the Logon Exit will interacts with RACF to allow NVAS to use RACF for user validation. If you don't specify a group name on the NVAS logon it will use your default group and match that to your NVAS group. All of our groups are either Public (normal users) or External (security admins and sysprogs). I think the difference between public and members of external groups can customize certain NVAS settings (order of applications on their menu, jump keys, ect. ) and public groups just use what is defined for them by the NVAS admins. The other is a administration exit. I don't think this one is required but it allows you to keep NVAS related setting in RACF and mange them from NVAS. However, IIRC this requires whomever is administrating NVAS to have the appropriate RACF security levels. That is, if they are administrating groups, they have to group special for those groups in RACF, if they are administrating the NVAS system they need RACF special. For some reason I don't think we are using the one from IBM. This information is is the Customization Manual. -- John G. -- 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: LUW (was: DFDSS support for ZFS files query)
Well, when I dump a catalog I don't want to dump the associated data sets, but catalogs are very different animals from Uix directories. -- 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 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: LUW (was: DFDSS support for ZFS files query) On Wed, 30 Sep 2020 20:35:11 +1000, Andrew Rowley wrote: >On 30/09/2020 6:03 pm, Seymour J Metz wrote: >> The DSS manual say that when you specify a directory, it does not dump the >> files under that directory. That's very different from the behavior of, >> e.g., tar. > >I guess I shouldn't be surprised, given how often IBM don't do things >the way I hoped. > It seems even less useful than the analogous DUMPing a catalog but not the associated data sets. On Wed, 30 Sep 2020 08:09:12 +0100, Sean Gleann wrote: > >'...use 'pax'...' That's what we do now and it is precisely the thing I'm >trying to move away from. We have data files for a specific system that >consist of a 'z/OS files component' and a 'USS files component'. Both are >dumped in separate independent jobs, and we see a danger that the two >resulting 'dump' files could conceivably get out of synchronisation. > Ouch! But you need to assure likewise that the various "z/OS *files*" aren't out of sync with each other. Perhaps Flash copy of all the z/OS files *and* the z/FS *aggregate*. And you still may need to quiesce other operations in order to get a consistent point-in-time view. You need Logical Unit of Work encapsulation with a scope that DFSMS simply doesn't provide. Does it help to "pax -w ... >z/OS data set" and include that in the DUMP manifest? Same job; different step. This leads me to wonder about the co-isolation of PDSE DESERV and STOW DISC. Do those serialize in a way that ensures a consistent point-in-time view of PDSE membership by other jobs? Pipe dream: Logical Unit of Work isolation of multiple catalog updates replacing multiple data set entries in a manner that appears atomic to other jobs. -- 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: ASMA500W using _boundary_ on ORG statement
ORG *,8 doesn't do anything that DS 0D doesn't do, but ORG *,256 has no DS equivalent. The syntax diagram in the HLASM reference shows ORG ,8 to be invalid syntax, so there is no way that the message could be legitimate; there should have been a message for syntax error. Of course, it would be nice if there were valid syntax for specifying high water mark with alignment. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Wednesday, September 30, 2020 9:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ASMA500W using _boundary_ on ORG statement >ORG *,8 Curious: Does this do anything that "DS0D" doesn't do? Wouldn't "DS0D" be more typical for "I want the next thing to be on a doubleword boundary? It certainly is for those of us who learned assembler long before SECTALGN (and this form of ORG) even existed. It might be true that the ASMA500W message is not the write message for "ORG ,8" but that is assuming that you know what boundary is being processed for such a case. The "null" first operand might have some effect on things. Or maybe it really is just a parsing glitch (and is an error). Peter Relson z/OS Core Technology Design -- 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: ASMA500W using _boundary_ on ORG statement
An APAR would be appropriate for the incorrect error message, and you might consider an RFE to allow alignment on an omitted (high bound) relocatable expression. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Pew, Curtis G Sent: Wednesday, September 30, 2020 9:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASMA500W using _boundary_ on ORG statement On Sep 30, 2020, at 8:13 AM, Peter Relson wrote: > >> ORG *,8 > > Curious: Does this do anything that "DS0D" doesn't do? > Wouldn't "DS0D" be more typical for "I want the next thing to be on a > doubleword boundary? > It certainly is for those of us who learned assembler long before SECTALGN > (and this form of ORG) even existed. > > It might be true that the ASMA500W message is not the write message for > "ORG ,8" but that is assuming that you know what boundary is being > processed for such a case. The "null" first operand might have some effect > on things. Or maybe it really is just a parsing glitch (and is an error). When I started out I wanted a larger boundary (256), but when that didn’t work I tried reducing the boundary and increasing SECTALGN to see if it would help. Also, if I understand how ORG works correctly, the semantics of using ‘*’ for the expression are different from omitting an expression. The first sets the location counter to its current value (before increasing it to the boundary) while the second sets it to the highest available location in the current CSECT. So if I need to make sure I’m at the end of the current control section (this code is in a macro, so I won’t in general know that the location counter is already there) I’ll need two ORG statements: ORG , ORG *,256 That seems less than optimal. -- Pew, Curtis G curtis@austin.utexas.edu -- 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?
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: ASMA500W using _boundary_ on ORG statement
HLASM is a mainframe assembler, so it's legitimate here. It's also legitimate on the assembler list, with a smaller but more focused audience. -- 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:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASMA500W using _boundary_ on ORG statement On Wed, 30 Sep 2020 09:13:57 -0400, Peter Relson wrote: >>ORG *,8 > >Curious: Does this do anything that "DS0D" doesn't do? > What construct allows the user to control the content of the slack bytes? How much does it matter? What construct truncates the TXT record? How much does it matter? Does this topic belong on ASSEMBLER-LIST? How much does it matter? -- 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: DFDSS support for ZFS files query
You are correct. For now, you must specify all the path names, but we understand this is a capability that ought to be provided in DFSMSdss. As others have mentioned, you may be able to use other tools to craft a list of path names and use that to generate DFSMSdss SYSIN statements. There is an existing RFE to provide the capability to dump an entire directory including all the files and sub-directories, if you feel this is an important feature to be included in the product please cast your vote here: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=140801 Ernesto E. Figueroa DFSMSdss Development Lead erfig...@us.ibm.com IBM SystemsGroup -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTPS Handshake Error
Thank you both Wendell and Mike. I am following your recommendations for debugging. On Wed, Sep 30, 2020 at 9:17 AM Wendell Lovewell < 01e9c0ee0673-dmarc-requ...@listserv.ua.edu> wrote: > Hello Roberto. > > In RACF-land, I'd look for an ICH message on the console to make sure you > don't need to PERMIT the client or the server access to the keyring. I've > found the gsk trace file to be very helpful--if the security manager > doesn't tell you via a console message. Telling PAGENT about the security > change might also be needed on the side that's failing. > > Here is a section of some documentation I wrote up for debugging such > errors for one of our products: > > - > (One of the examples:) > EZD1287I TTLS Error RC: 406 Initial Handshake 477 > LOCAL: 172.29.127.60..1173 > REMOTE: 172.29.127.60..5401 > JOBNAME: MBXWL RULE: MBX_STC_Rule > > The RC values are most helpful. Since there is a policy used for both > inbound (MBX_CICS_Rule) and outbound (MBX_STC_Rule—note the rules in play > are also displayed on the console), there will likely be two EZD1287I > messages displayed if there is a problem. (Both sides will experience a > problem.) You can find an explanation for these in the SC14-7495-30 > Cryptographic Services System Secure Sockets Layer Programming manual, > currently in chapter 13. > > SC27-3651-30 IP Configuration Reference contains the syntax for the AT-TLS > policy (/etc/pagent_TTLS.conf). > > GC27-3652-30 IP Diagnosis Guide may be useful if you are getting GSK > errors. > > SA23-2292-30 Security Server RACF Command Language Reference contains the > syntax for the RACDCERT instructions. > > If you need to see the GKY messages, set the Trace value in the > TTLSGroupAction parms for both the MBX_CICS_Rule and MBX_STC_Rule to Trace > 255. When you upload /etc/pagent_TTLS.conf, the policy agent will > re-install the policy. > > If you make RACF changes to the keyrings, you need to tell the policy > agent to refresh it’s settings for them. You can do this by changing the > EnvironmentAction value & reloading the pagent_TTLS.conf file. > > - > > HTH, > Wendell > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Politics: Poli (many) - tics (blood sucking parasites) -- 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: ASMA500W using _boundary_ on ORG statement
On Wed, 30 Sep 2020 09:13:57 -0400, Peter Relson wrote: >>ORG *,8 > >Curious: Does this do anything that "DS0D" doesn't do? > What construct allows the user to control the content of the slack bytes? How much does it matter? What construct truncates the TXT record? How much does it matter? Does this topic belong on ASSEMBLER-LIST? How much does it matter? -- 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 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: ASMA500W using _boundary_ on ORG statement
On Sep 30, 2020, at 8:13 AM, Peter Relson wrote: > >> ORG *,8 > > Curious: Does this do anything that "DS0D" doesn't do? > Wouldn't "DS0D" be more typical for "I want the next thing to be on a > doubleword boundary? > It certainly is for those of us who learned assembler long before SECTALGN > (and this form of ORG) even existed. > > It might be true that the ASMA500W message is not the write message for > "ORG ,8" but that is assuming that you know what boundary is being > processed for such a case. The "null" first operand might have some effect > on things. Or maybe it really is just a parsing glitch (and is an error). When I started out I wanted a larger boundary (256), but when that didn’t work I tried reducing the boundary and increasing SECTALGN to see if it would help. Also, if I understand how ORG works correctly, the semantics of using ‘*’ for the expression are different from omitting an expression. The first sets the location counter to its current value (before increasing it to the boundary) while the second sets it to the highest available location in the current CSECT. So if I need to make sure I’m at the end of the current control section (this code is in a macro, so I won’t in general know that the location counter is already there) I’ll need two ORG statements: ORG , ORG *,256 That seems less than optimal. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTPS Handshake Error
Hello Roberto. In RACF-land, I'd look for an ICH message on the console to make sure you don't need to PERMIT the client or the server access to the keyring. I've found the gsk trace file to be very helpful--if the security manager doesn't tell you via a console message. Telling PAGENT about the security change might also be needed on the side that's failing. Here is a section of some documentation I wrote up for debugging such errors for one of our products: - (One of the examples:) EZD1287I TTLS Error RC: 406 Initial Handshake 477 LOCAL: 172.29.127.60..1173 REMOTE: 172.29.127.60..5401 JOBNAME: MBXWL RULE: MBX_STC_Rule The RC values are most helpful. Since there is a policy used for both inbound (MBX_CICS_Rule) and outbound (MBX_STC_Rule—note the rules in play are also displayed on the console), there will likely be two EZD1287I messages displayed if there is a problem. (Both sides will experience a problem.) You can find an explanation for these in the SC14-7495-30 Cryptographic Services System Secure Sockets Layer Programming manual, currently in chapter 13. SC27-3651-30 IP Configuration Reference contains the syntax for the AT-TLS policy (/etc/pagent_TTLS.conf). GC27-3652-30 IP Diagnosis Guide may be useful if you are getting GSK errors. SA23-2292-30 Security Server RACF Command Language Reference contains the syntax for the RACDCERT instructions. If you need to see the GKY messages, set the Trace value in the TTLSGroupAction parms for both the MBX_CICS_Rule and MBX_STC_Rule to Trace 255. When you upload /etc/pagent_TTLS.conf, the policy agent will re-install the policy. If you make RACF changes to the keyrings, you need to tell the policy agent to refresh it’s settings for them. You can do this by changing the EnvironmentAction value & reloading the pagent_TTLS.conf file. - HTH, Wendell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ASMA500W using _boundary_ on ORG statement
>ORG *,8 Curious: Does this do anything that "DS0D" doesn't do? Wouldn't "DS0D" be more typical for "I want the next thing to be on a doubleword boundary? It certainly is for those of us who learned assembler long before SECTALGN (and this form of ORG) even existed. It might be true that the ASMA500W message is not the write message for "ORG ,8" but that is assuming that you know what boundary is being processed for such a case. The "null" first operand might have some effect on things. Or maybe it really is just a parsing glitch (and is an error). Peter Relson z/OS Core Technology Design -- 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: Searching MLPA module
>Is it possible to delete a E-MLPA module dynamically ? No. Why would you want to? It is possible to delete a dynamic-LPA module dynamically but it is almost always a system integrity error to do so because it is often impossible to be certain that there is no code executing within it (possibly even temporarily undispatched). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LUW (was: DFDSS support for ZFS files query)
On Wed, 30 Sep 2020 20:35:11 +1000, Andrew Rowley wrote: >On 30/09/2020 6:03 pm, Seymour J Metz wrote: >> The DSS manual say that when you specify a directory, it does not dump the >> files under that directory. That's very different from the behavior of, >> e.g., tar. > >I guess I shouldn't be surprised, given how often IBM don't do things >the way I hoped. > It seems even less useful than the analogous DUMPing a catalog but not the associated data sets. On Wed, 30 Sep 2020 08:09:12 +0100, Sean Gleann wrote: > >'...use 'pax'...' That's what we do now and it is precisely the thing I'm >trying to move away from. We have data files for a specific system that >consist of a 'z/OS files component' and a 'USS files component'. Both are >dumped in separate independent jobs, and we see a danger that the two >resulting 'dump' files could conceivably get out of synchronisation. > Ouch! But you need to assure likewise that the various "z/OS *files*" aren't out of sync with each other. Perhaps Flash copy of all the z/OS files *and* the z/FS *aggregate*. And you still may need to quiesce other operations in order to get a consistent point-in-time view. You need Logical Unit of Work encapsulation with a scope that DFSMS simply doesn't provide. Does it help to "pax -w ... >z/OS data set" and include that in the DUMP manifest? Same job; different step. This leads me to wonder about the co-isolation of PDSE DESERV and STOW DISC. Do those serialize in a way that ensures a consistent point-in-time view of PDSE membership by other jobs? Pipe dream: Logical Unit of Work isolation of multiple catalog updates replacing multiple data set entries in a manner that appears atomic to other jobs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS support for ZFS files query
I'm hoping that it's still a 'work in progress' & that one day I'll be able
to say 'DUMP PATH INCLUDE('/foldera/folderb/**') or something close to that.
Sean
On Wed, 30 Sep 2020 at 11:35, Andrew Rowley
wrote:
> On 30/09/2020 6:03 pm, Seymour J Metz wrote:
> > The DSS manual say that when you specify a directory, it does not dump
> the files under that directory. That's very different from the behavior of,
> e.g., tar.
>
> I guess I shouldn't be surprised, given how often IBM don't do things
> the way I hoped.
>
> It does seem to be less useful than it could have been. I wonder what
> the thinking was when it was being designed?
>
> Andrew Rowley
>
> --
> 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: DFDSS support for ZFS files query
On 30/09/2020 6:03 pm, Seymour J Metz wrote: The DSS manual say that when you specify a directory, it does not dump the files under that directory. That's very different from the behavior of, e.g., tar. I guess I shouldn't be surprised, given how often IBM don't do things the way I hoped. It does seem to be less useful than it could have been. I wonder what the thinking was when it was being designed? Andrew Rowley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS support for ZFS files query
The DSS manual say that when you specify a directory, it does not dump the files under that directory. That's very different from the behavior of, e.g., tar. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Andrew Rowley Sent: Wednesday, September 30, 2020 3:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS support for ZFS files query I haven't tested it myself, but what I would hope is that it works like unix utilities, where the file you specify could actually be a directory. It is pretty common when using tar etc. to set the working directory, and specify e.g. "." (a dot) to select the current directory, or specify a subdirectory name. You can then restore to a different location by setting a different working directory before the restore, i.e. all names are relative to the working directory. On 29/09/2020 5:52 pm, Sean Gleann wrote: > As far as I can see, I have to specify the WORKINGDIRECTORY to establish > the starting point for the DUMP operation, then use INCLUDE to _explicitly_ > specify the files I want. The available documentation states: > "DFSMSdss does not provide wildcard support when processing UNIX files." > which, for my purposes, is a complete show-stopper. -- Andrew Rowley Black Hill Software -- 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: DFDSS support for ZFS files query
I haven't tested it myself, but what I would hope is that it works like unix utilities, where the file you specify could actually be a directory. It is pretty common when using tar etc. to set the working directory, and specify e.g. "." (a dot) to select the current directory, or specify a subdirectory name. You can then restore to a different location by setting a different working directory before the restore, i.e. all names are relative to the working directory. On 29/09/2020 5:52 pm, Sean Gleann wrote: As far as I can see, I have to specify the WORKINGDIRECTORY to establish the starting point for the DUMP operation, then use INCLUDE to _explicitly_ specify the files I want. The available documentation states: "DFSMSdss does not provide wildcard support when processing UNIX files." which, for my purposes, is a complete show-stopper. -- Andrew Rowley Black Hill Software -- 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: DFDSS support for ZFS files query
Wayne: Yes, it does look like each file or path has to be explicitly defined Paul: '...akin to asking DFMSMdss to select individual PDS members' is an analogy I had not seen. Thank you. And of course, DFSMSdss has never been able to do this and it's unlikely it ever will; '...filenames containing NL...' Again, something I had not considered. I can confidently say that in the situation that is driving my investigation that does not happen _now_, but that's no guarantee it won't occur in the future; '...use 'pax'...' That's what we do now and it is precisely the thing I'm trying to move away from. We have data files for a specific system that consist of a 'z/OS files component' and a 'USS files component'. Both are dumped in separate independent jobs, and we see a danger that the two resulting 'dump' files could conceivably get out of synchronisation. It looks like what I want is not possible at present and is unlikely to be so in the future. Thanks for your responses, Gentlemen. I'm going to abandon this particular investigation for now. On Tue, 29 Sep 2020 at 16:19, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 29 Sep 2020 08:52:38 +0100, Sean Gleann wrote: > > >I'm currently investigating the use of DFDSS DUMP PATH to secure data held > >in UNIX files and folders. > >... > >"DFSMSdss does not provide wildcard support when processing UNIX files." > >... > >I can see a possible method of including a massaged version of 'ls' output > >in the INCLUDE parameter, but I don't see this as a particularly workable > >solution. > > > The better utility for that is "find" rather than "ls". "find" supports > wildcards > and boolean expressions; "ls" supports neither. The massaging would need > to protect special characters with a scheme supported by DFSMSdss. > Filenames containing NL are a particular challenge. > > ALas, z/OS's "find" does not support the precious "-print0" extension. > > What you're asking is akin to asking DFSMSdss to select individual PDS > members. > > >Also, with a DUMP of data comes the requirement to be able to RESTORE it > to > >- possibly - a different WORKINGDIRECTORY, but I haven't got that far yet. > > > Use 'pax". Mr. Natural sez, Use the right tool for the job. > > -- 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
