8-byte V-cons
Someone asked recently >>(Do 64-bit V-CONs exist?) and someone else replied >I don't think so, but 64-bit AD-cons with EXTRN do. try a VD-type adcon. (See the HLASM Language Reference.) Regards... John - 555 Bailey Ave, San Jose CA 95141 USA +1-408-463-3543 (fax -3873) TIE 543- ehr...@us.ibm.com; VMID = EHRMAN at STLVM27 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
Paul Gilmartin wrote:
On Fri, 21 Aug 2015 09:53:49 -0400, Thomas David Rivers wrote:
So - perhaps I'm confused... but are you saying you want
a procedure that potentially reads the entire data set to determine
if you need to read the entire data set?
If the hash is sufficiently strong, you needn't read the entire data set
more than once, nor preserve the older version(s), but only the hash.
If a collision is unlikely within the lifetime of the universe, don't worry.
OTOH:
Ron Rivest estimated in 1977 that factoring a 125-digit
number would require 40 quadrillion years, ...
but with technological advances such a problem was solved 17
years later.
https://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage
-- gil
How do you compute this sufficiently strong hash on the file to see
if it matches the one you have from a previous computation, without
reading (probably) the entire file? If something could be devised, it would
be a good tool in the toolbox...
- Dave R. -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 13:04:47 -0500, Mark Zelden wrote: >> >>(And long ago, MVS-OE mentioned "charcase lower" as a preventive.) >> I believe this was not in the original design, but provided at a later release in order to forestall the DoS exposure. >>Suppose you have "/u/mzelden". While it's unmounted I do "cd /u/MZelden". >>Automount issues (something like) an ENQ EXC on MZELDEN.TPLEX.ZFS. >>While that's in effect you can't mount "/u/mzelden". Not a DoS of your >>entire system, just of your HOME. (At least this applied to HFS; zFS >>might be different.) > >So, OMVS / ZFS address spaces have the access and it gets mounted >in a microsecond on my very fast z13 with flash disk. :-) > Not for only a microsecond, but for at least as long as it takes to time out and dismount. And if I can "cd /u/MZelden", for as long as I tarry there. But that requires that I have at least search authority on the directory. >But seriously, where's the exposure? > I believe IBM covered it because they perceived it. Can you try "cd /u/MZelden" and observe the result? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 12:10:32 -0500, Mark Zelden wrote: > I found I didn't have the "setuid no" >on one of my sandbox LPARs. Now it has me thinking... was that parm always >there >and at one point when I learned about the exposure, or was it added at some >point in >OS/390. > It's always been there, as far as I know. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 17:05:40 +, J O Skip Robinson wrote: >It probably was understood by everyone who knows squat about OMVS. ;-) > >So I tracked this down via a symlink: > >name * >type ZFS >filesystem .HOME1.HFS >mode rdwr >duration 30 >delay 10 >allocuser space(10,2) cyl >lowercase yes > >Same for z/OS 1.13 and 2.1. It does not look like your display. No reference >to setuid. Does that mean we're taking the default of 'yes'? Yes, that should mean you are taking the default of setuid, and you have the exposure that I mentioned. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 11:22:31 -0600, Paul Gilmartin wrote: >On 2015-08-21, at 11:05, Mark Zelden wrote: >> filesystem .TPLEX.ZFS >>> Beware also of "uc_name", which allows a nuisance (perhaps inadvertent) >>> DoS attack. Prevent this with either "charcase lower" or "charcase upper" >>> (or "asis_name"), at the cost of losing some flexibility in naming. >>> >>> (Would asis_name with DISABLE(DSNCHECK) also work?) >>> >> >> Can you please expound on that and provide an example of how this can >> be used to DoS my systems? BTW, I've seen this in many IBM examples, >> manuals, presentations etc. >> >(And long ago, MVS-OE mentioned "charcase lower" as a preventive.) > >Suppose you have "/u/mzelden". While it's unmounted I do "cd /u/MZelden". >Automount issues (something like) an ENQ EXC on MZELDEN.TPLEX.ZFS. >While that's in effect you can't mount "/u/mzelden". Not a DoS of your >entire system, just of your HOME. (At least this applied to HFS; zFS >might be different.) > So, OMVS / ZFS address spaces have the access and it gets mounted in a microsecond on my very fast z13 with flash disk. :-) But seriously, where's the exposure? Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ Where's the exposure? Mark Best Regards / Mit freundlichen Grüßen, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On 2015-08-21, at 11:10, Mark Zelden wrote: > On Fri, 21 Aug 2015 17:05:40 +, J O Skip Robinson > wrote: > >> SXQgcHJvYmFibHkgd2FzIHVuZGVyc3Rvb2QgYnkgZXZlcnlvbmUgd2hvIGtub3dzIHNxdWF0IGFi >> b3V0IE9NVlMuIDstKQ0KDQpTbyBJIHRyYWNrZWQgdGhpcyBkb3duIHZpYSBhIHN5bWxpbms6DQoN >> Cm5hbWUgICAgICAgICAgICAgICAqICAgICAgICAgICAgICAgICAgICANCnR5cGUgICAgICAgICAg > > > > ugh.. above is what I get when I reply from the web archives, so that's why > I'm not quoting > some OPs. I see it more and more. > And L-Soft accepts SRs only from customers. Have you tried reporting the problem through the list owner? (Other LISTSERVs misbehave likewise.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
On 2015-08-21, at 10:17, van der Grijn, Bart (B) wrote: > > We take hash values of all our system datasets daily for change control > purposes. We use superc in batch for this (at least for PS/PDS/VSAM). It > takes some time but it has worked well so far. We compare the file with > itself and specify OVSUML,FILECMP > Does this impose a line length limit? ISTR getting a warning from SuperC that only 150 columns are compared. Does it read the data set twice, or use a cache for the second? What hash? CRC-32? MD5? SHA-1? ...? Can you choose? (I tried to RTFM on Knowledge Center. Real hard to find what I want.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On 2015-08-21, at 11:05, Mark Zelden wrote: > >>> filesystem .TPLEX.ZFS >>> >> Beware also of "uc_name", which allows a nuisance (perhaps inadvertent) >> DoS attack. Prevent this with either "charcase lower" or "charcase upper" >> (or "asis_name"), at the cost of losing some flexibility in naming. >> >> (Would asis_name with DISABLE(DSNCHECK) also work?) >> > > Can you please expound on that and provide an example of how this can > be used to DoS my systems? BTW, I've seen this in many IBM examples, > manuals, presentations etc. > (And long ago, MVS-OE mentioned "charcase lower" as a preventive.) Suppose you have "/u/mzelden". While it's unmounted I do "cd /u/MZelden". Automount issues (something like) an ENQ EXC on MZELDEN.TPLEX.ZFS. While that's in effect you can't mount "/u/mzelden". Not a DoS of your entire system, just of your HOME. (At least this applied to HFS; zFS might be different.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 17:05:40 +, J O Skip Robinson wrote: >SXQgcHJvYmFibHkgd2FzIHVuZGVyc3Rvb2QgYnkgZXZlcnlvbmUgd2hvIGtub3dzIHNxdWF0IGFi >b3V0IE9NVlMuIDstKQ0KDQpTbyBJIHRyYWNrZWQgdGhpcyBkb3duIHZpYSBhIHN5bWxpbms6DQoN >Cm5hbWUgICAgICAgICAgICAgICAqICAgICAgICAgICAgICAgICAgICANCnR5cGUgICAgICAgICAg ugh.. above is what I get when I reply from the web archives, so that's why I'm not quoting some OPs. I see it more and more. Yes, it means you are taking the default of yes. I found I didn't have the "setuid no" on one of my sandbox LPARs. Now it has me thinking... was that parm always there and at one point when I learned about the exposure, or was it added at some point in OS/390. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
It probably was understood by everyone who knows squat about OMVS. ;-) So I tracked this down via a symlink: name * type ZFS filesystem .HOME1.HFS mode rdwr duration 30 delay 10 allocuser space(10,2) cyl lowercase yes Same for z/OS 1.13 and 2.1. It does not look like your display. No reference to setuid. Does that mean we're taking the default of 'yes'? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Friday, August 21, 2015 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Catalog for OMVS datasets On Fri, 21 Aug 2015 16:17:16 +, J O Skip Robinson wrote: >Mark, > >What are you displaying in your example? Sorry, since we were talking about automount I thought it would be understood. It was the /etc/auto.map.u contents - pointed to by /etc/auto.master Best Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 10:18:03 -0500, Paul Gilmartin wrote: >On Fri, 21 Aug 2015 09:33:00 -0500, Mark Zelden wrote: > >>On Fri, 21 Aug 2015 08:56:31 -0500, Walt Farrell wrote: >>> >>>To prevent that security exposure you need to ensure that the mount >>>specifications for all those userid-prefixed zFS data sets specify NOSETUID, >>>which is not the default. >> >>Thanks Walt! Great point that I didn't think to mention because I set this >>up so long >>ago I forgot about that consideration. I do have that set on the systems / >>sysplexes >>that use the user's HLQ. For example: >> >>name * >>type ZFS >>filesystem .TPLEX.ZFS >>mode rdwr >>duration 10 >>delay 10 >>setuid no >>allocuser space(2,1) cyl >> >Beware also of "uc_name", which allows a nuisance (perhaps inadvertent) >DoS attack. Prevent this with either "charcase lower" or "charcase upper" >(or "asis_name"), at the cost of losing some flexibility in naming. > >(Would asis_name with DISABLE(DSNCHECK) also work?) > Can you please expound on that and provide an example of how this can be used to DoS my systems? BTW, I've seen this in many IBM examples, manuals, presentations etc. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 16:17:16 +, J O Skip Robinson wrote: >Mark, > >What are you displaying in your example? Sorry, since we were talking about automount I thought it would be understood. It was the /etc/auto.map.u contents - pointed to by /etc/auto.master Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
I seem to have missed the first part of this discussion, so this might have been mentioned, or might not be relevant. We take hash values of all our system datasets daily for change control purposes. We use superc in batch for this (at least for PS/PDS/VSAM). It takes some time but it has worked well so far. We compare the file with itself and specify OVSUML,FILECMP Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Thursday, August 20, 2015 1:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ideas for hash of a sequential data set Charles, I think that you misunderstood me. I'm suggesting that the cheap first hash (used to rule out common changes) would be over a combination of: - the first n bytes of the data set (just like you suggested) - the F1/F8 DSCB (which has stuff like DS1LSTAR and DS1TRBAL which helps to detect common changes to the end Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Aug 20, 2015 at 12:41 PM, Charles Mills wrote: > Right. That's a better idea. Seek to end minus 'n' and go from there. > > Only small negative is that if you did the first 'n' bytes and then needed > to do the whole file, you could just keep going rather than starting over. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Kirk Wolf > Sent: Thursday, August 20, 2015 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Ideas for hash of a sequential data set > > That is certainly a possibility, but wouldn't help in the (common) case of > a change that just appends to the end. Perhaps hashing both the "first n > bytes" with the F1/8 DSCB (which has information about the last TTR and > bytes in the last track) would cover more of the common changes than either > alone. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
Mark, What are you displaying in your example? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Friday, August 21, 2015 7:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Catalog for OMVS datasets On Fri, 21 Aug 2015 08:56:31 -0500, Walt Farrell wrote: >On Fri, 21 Aug 2015 08:40:38 -0500, Mark Zelden wrote: > >> >>User zFSes (automounted) are a mixture between the two major companies I >>support. >>One of them uses their personal HLQ, for example userid.OMVS.ZFS, and >>the other one uses a system HLQ, for example SYSO.userid.ZFS or >>SYS.OMVS.userid.zFS. >>I can see why there is a recommendation for the latter because the >>average user really doesn't need access to their physical file system, >>but I also don't have a problem with the HLQ being the same as all their >>other files. >>The user can delete their zFS all they want and they aren't going to >>destroy anything in the system or any other persons data nor application data. > >If you're going to have zFS data sets prefixed with user IDs you need to be >very careful how you mount them. You probably know that, but others may not. >The real danger with such data sets is that the users can update them >directly, and change the permission bits and other metadata for files, such >that executable files within the zFS will run with UID(0) (superuser) or some >other user's authority, or run APF-authorized or program-controlled. > >To prevent that security exposure you need to ensure that the mount >specifications for all those userid-prefixed zFS data sets specify NOSETUID, >which is not the default. > >-- >Walt Thanks Walt! Great point that I didn't think to mention because I set this up so long ago I forgot about that consideration. I do have that set on the systems / sysplexes that use the user's HLQ. For example: name * type ZFS filesystem .TPLEX.ZFS mode rdwr duration 10 delay 10 setuid no allocuser space(2,1) cyl Best Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Joke of the week...
Poor taste, poor judgement, not even technical please refrain. In a message dated 8/21/2015 8:18:39 A.M. Central Daylight Time, elardus.engelbre...@sita.co.za writes: I once stand on the pavement watching to see how the police handles a riot -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 09:33:00 -0500, Mark Zelden wrote: >On Fri, 21 Aug 2015 08:56:31 -0500, Walt Farrell wrote: >> >>To prevent that security exposure you need to ensure that the mount >>specifications for all those userid-prefixed zFS data sets specify NOSETUID, >>which is not the default. > >Thanks Walt! Great point that I didn't think to mention because I set this up >so long >ago I forgot about that consideration. I do have that set on the systems / >sysplexes >that use the user's HLQ. For example: > >name * >type ZFS >filesystem .TPLEX.ZFS >mode rdwr >duration 10 >delay 10 >setuid no >allocuser space(2,1) cyl > Beware also of "uc_name", which allows a nuisance (perhaps inadvertent) DoS attack. Prevent this with either "charcase lower" or "charcase upper" (or "asis_name"), at the cost of losing some flexibility in naming. (Would asis_name with DISABLE(DSNCHECK) also work?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
On Fri, 21 Aug 2015 09:53:49 -0400, Thomas David Rivers wrote: > >So - perhaps I'm confused... but are you saying you want >a procedure that potentially reads the entire data set to determine >if you need to read the entire data set? > If the hash is sufficiently strong, you needn't read the entire data set more than once, nor preserve the older version(s), but only the hash. If a collision is unlikely within the lifetime of the universe, don't worry. OTOH: Ron Rivest estimated in 1977 that factoring a 125-digit number would require 40 quadrillion years, ... but with technological advances such a problem was solved 17 years later. https://en.wikipedia.org/wiki/The_Magic_Words_are_Squeamish_Ossifrage -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 08:56:31 -0500, Walt Farrell wrote: >On Fri, 21 Aug 2015 08:40:38 -0500, Mark Zelden wrote: > >> >>User zFSes (automounted) are a mixture between the two major companies I >>support. >>One of them uses their personal HLQ, for example userid.OMVS.ZFS, and the >>other >>one uses a system HLQ, for example SYSO.userid.ZFS or SYS.OMVS.userid.zFS. >>I can see why there is a recommendation for the latter because the average >>user really doesn't need access to their physical file system, but I also >>don't have a problem with the HLQ being the same as all their other files. >>The user can delete their zFS all they want and they aren't going to destroy >>anything in the system or any other persons data nor application data. > >If you're going to have zFS data sets prefixed with user IDs you need to be >very careful how you mount them. You probably know that, but others may not. >The real danger with such data sets is that the users can update them >directly, and change the permission bits and other metadata for files, such >that executable files within the zFS will run with UID(0) (superuser) or some >other user's authority, or run APF-authorized or program-controlled. > >To prevent that security exposure you need to ensure that the mount >specifications for all those userid-prefixed zFS data sets specify NOSETUID, >which is not the default. > >-- >Walt Thanks Walt! Great point that I didn't think to mention because I set this up so long ago I forgot about that consideration. I do have that set on the systems / sysplexes that use the user's HLQ. For example: name * type ZFS filesystem .TPLEX.ZFS mode rdwr duration 10 delay 10 setuid no allocuser space(2,1) cyl Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Admin query
As others have pointed out. This does not seem to be part of the IBM default set of STGADMIN.IGG profiles. Do you have a CDT you maintain? If so, are there notes indicating this entry? When you list the STGADMIN.IGG.CATALOG.SECURITY.CHANGE - what is the date for the entry? Most likely this is from a different product as an addition. Some vendors do make things look like IBM names, but they are not really from IBM. If it does not show up in the http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.12.0/com.ibm.zos.r12.idai200/da6i2280.htm%23da6i2280 z/OS 1.12.0>DFSMS>DFSMS Access Method Services for Catalogs>Appendix A. Security Authorization Levels>Required RACF Authorization Tables Then it is not likely to be part of IBM's suite. To add/del alias STGADMIN.IGG.DEFDEL.UALIAS is typically used. Lizette > -Original Message- > From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of > David Constable > Sent: Friday, August 21, 2015 4:37 AM > To: rac...@listserv.uga.edu > Subject: Re: Storage Admin query > > Elardus, > > The user was trying to create an ALIAS for a DB2 Dataset. This has been done > many time before, but failed this week. In the end, our Access Services team > had to create a RACF DATASET profile for the ALIAS. > > It has always been my understanding that access is always checked against > the REAL DATASET and not the ALIAS, and we have never had to do this > before. This resource may be a complete red herring, but it's the only > unusual access check that I can see for this period and this user. > > The RACF Profile STGADMIN.IGG.* has been around since 1990, but I have > never seen the STGADMIN.IGG.CATALOG.SECURITY.CHANGE resource > mentioned before. > > Regards > > Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Fri, 21 Aug 2015 08:40:38 -0500, Mark Zelden wrote: > >User zFSes (automounted) are a mixture between the two major companies I >support. >One of them uses their personal HLQ, for example userid.OMVS.ZFS, and the other >one uses a system HLQ, for example SYSO.userid.ZFS or SYS.OMVS.userid.zFS. >I can see why there is a recommendation for the latter because the average >user really doesn't need access to their physical file system, but I also >don't have a problem with the HLQ being the same as all their other files. >The user can delete their zFS all they want and they aren't going to destroy >anything in the system or any other persons data nor application data. If you're going to have zFS data sets prefixed with user IDs you need to be very careful how you mount them. You probably know that, but others may not. The real danger with such data sets is that the users can update them directly, and change the permission bits and other metadata for files, such that executable files within the zFS will run with UID(0) (superuser) or some other user's authority, or run APF-authorized or program-controlled. To prevent that security exposure you need to ensure that the mount specifications for all those userid-prefixed zFS data sets specify NOSETUID, which is not the default. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
Kirk Wolf wrote: I'm trying to come up with an efficient way to see if a non-VSAM data set has been changed. Flipping the DS1IND08 bit is not an option, nor can I install SMF hooks, etc in the OS. The problem, of course, is that DSCBs don't have "last update timestamps". My initial whack at this would be to use a two-part hash: part 1: a shortened SHA1-hash of the format-1/8 DSCB part 2: a full SHA-1 hash of all of the data The goal is to calculate something when I read an entire data set and keep it, and then later I can use this to later know if I need to read the data again. So: a part 1 match is non-informative (the data set could still have changed, although not likely) a part 1 mismatch would tell me that most probably the data set has changed (or just moved?). I would then have to read the entire data set to determine if it really has changed. Thoughts? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN So - perhaps I'm confused... but are you saying you want a procedure that potentially reads the entire data set to determine if you need to read the entire data set? - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Catalog for OMVS datasets
On Thu, 20 Aug 2015 08:21:07 -0700, David G. Schlecht wrote: >How do you catalog your OMVS datasets? > A data set is a data sets is a data set. I remember when just about all shops had different HLQs for VSAM (PROD, PRODV, TEST, TESTV etc..). I'm sure a lot of those legacy standards still exist but I bet newer standards in most shops don't distinguish by HLQ VSAM vs. non-vsam (maybe a letter somewhere in on of the mlq nodes). My setup is pretty much what Skip wrote. System / sysres z/OS unix files are in the master catalog (just like all the other sysres data sets) with a HLQ of SYS1 (SYS1.OMVS.&sysres.** to be specific). "In house" z/OS unix files use the same HLQs as other system "in house" data sets (proclibs, ISPF libs, etc.). These include /etc, /var and other sysplex unix file systems. Some of them are "directory" file systems and are just mount points for other file systems. The HLQs vary by sysplex / company. ISV or program product unix files have various HLQs, again depending on the sysplex / company and also on some sysplexes the standards have a different HLQ for different tech teams. For example, the CICS team uses CICS.** for their data sets and the unix files follow those same standards. Some sysplexes all ISV product system data sets have the same set of HLQs (with a P/D/T in the HLQ denoting production, development, or test). Any unix file associated with that product would have the same HLQ. None of the HLQs mentioned above are in the master catalog. A data set is a data set is a data set. :-) User zFSes (automounted) are a mixture between the two major companies I support. One of them uses their personal HLQ, for example userid.OMVS.ZFS, and the other one uses a system HLQ, for example SYSO.userid.ZFS or SYS.OMVS.userid.zFS. I can see why there is a recommendation for the latter because the average user really doesn't need access to their physical file system, but I also don't have a problem with the HLQ being the same as all their other files. The user can delete their zFS all they want and they aren't going to destroy anything in the system or any other persons data nor application data. On Thu, 20 Aug 2015 16:59:18 +, Jousma, David wrote: >No real concerns either way in a single system shop. However, if you do >Sysplex >Shared filesystem "SYSPLEX(YES)" in BPXPRMxx then there is a requirement for >them >to be in a usercat connected to all systems that are sharing or you will have >problems. Change the word "usercat" to "catalog". None of our sysres unix files are in user catalogs. Some of the sysplexes have an HLQ like SYSO (O = OMVS) for things like /etc and that HLQ is in the master catalog. It doesn't have to be, but that's what was done a long time ago. Of course the master catalog is shared in each sysplex. Best Regards / Mit freundlichen Grüßen, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: Joke of the week...
I once stand on the pavement watching to see how the police handles a riot. A big, really big mean Captain is in charge and he looks at those unruly people. Wow, they’re angry about something... He shouts: ‘Water Cannon!’ Pt. The water pushed those people back a half streetblock far, but those rioters just stand up and come back, wet clothes and all. Captain: ‘Pepper Spray’ Pstt!! Those people got sprayed, but they come back! With teary eyes and snotty noses they still come back to assault the police. Captain: ‘Beat the h*ll out of them!!’ A special team rushed out with batons, whips and shields. They beat and beat and beat all those people. Ouch! But hey, these people come back! Again! With bruises and all! Captain: ‘Let them out!’ These guys in blue let their angry dogs out. Those dogs bite the h*ll out of those people. They scrambled out in more directions that a compass have. All is over and there is PEACE, PEACE and PEACE at last! I go over to the Captain and ask him, ‘Why all the trouble? Why now the dogs first?’ He growled at me, ‘Those dogs takes no sh*t. They don’t eat anything unless it is washed, spiced and tenderised.’ ;-D Groete / Greetings Elardus Engelbrecht! “When getting advice, believe half of what you read and none of what you hear.” ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
On Thu, 20 Aug 2015 11:55:22 -0500 Kirk Wolf wrote: :>I'm trying to come up with an efficient way to see if a non-VSAM data set :>has been changed. :>Flipping the DS1IND08 bit is not an option, nor can I install SMF hooks, :>etc in the OS. But can you read SMF? Why these restrictions? Why do you need to know? What if it is changed and then changed back? Is that considered a change? IOW, what is the business case? :>The problem, of course, is that DSCBs don't have "last update timestamps". :>My initial whack at this would be to use a two-part hash: :>part 1: a shortened SHA1-hash of the format-1/8 DSCB :>part 2: a full SHA-1 hash of all of the data :>The goal is to calculate something when I read an entire data set and keep :>it, and then later I can use this to later know if I need to read the data :>again. :>So: a part 1 match is non-informative (the data set could still have :>changed, although not likely) :> a part 1 mismatch would tell me that most probably the data set has :>changed (or just moved?). I would then have to read the entire data set to :>determine if it really has changed. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
Kirk Wolf wrote: >I'm trying to come up with an efficient way to see if a non-VSAM data set has >been changed. Which changes do you want to check: copy / move / recall / migrate / rename / append / overwrite all or parts? What non-VSAM? PS / PDS / PDS-E? Do you check that ALL parts have been changed or only a subset? Say your non-VSAM spans multiple volsers, but on volser 3 a little overwriting of 1 character must be picked up by your hash? >Flipping the DS1IND08 bit is not an option, nor can I install SMF hooks, etc >in the OS. No hooks? So that also means no SVC99 intercept? >The problem, of course, is that DSCBs don't have "last update timestamps". So I see that after RTFM... Until you get a solution, why not set audit to that dataset for all access attempts and then check for UPDATE or higher attempt? Plus LOGOPTIONS ALWAYS in RACF for datasets? Of course, for APF-ed and Trusted/Privileged STCs, this will perhaps not work... Alternatively, could you be kind to tell us why you want to see if it has been changed or not? Perhaps there are other solutions? What about asking big blue to see if there is some reserved, but unused field you can use? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
StGADMIN Resource
Hi all, I am trying to find out what the following resourse does :- STGADMIN.IGG.CATALOG.SECURITY.CHANGE I've checked the DFSMFS manuals, but can't find any reference to it, and I've asked our storage guys and they don't recognise it. Any Clues? I've cross posted to RACF-L Cheers Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS DELETE MASK and Recalls
John, As you might have read, the problem is determined to be a CA-DISK problem. You can reassure the developer, that his software is working correctly. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: 19 August, 2015 18:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS DELETE MASK and Recalls kees.verno...@klm.com (Vernooij, CP - KLM , ITOPT1) wrote: > Hello, > > Some time ago we got the great enhancement that IDCAMS DELETE did not recall > a dataset anymore. > Then we got the great enhancement to easily delete large amount of datasets > with IDCAMS DELETE MASK. > > However, DELETE MASK appears to recall the datasets again. Is this as > intended, and documented? Why can't we have both great enhancements together? I forwarded your post to the developer, who was surprised, because the data sets should not be recalled by IDCAMS DELETE. He asks that you open a PMR. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ideas for hash of a sequential data set
Kirk Wolf wrote: >I'm trying to come up with an efficient way to see if a non-VSAM data set >has been changed. Kirk, do you have some more details on your particular use case(s) you could share? I started typing a reply with at least a couple possible non-hashing, lower resource approaches -- upon first impression hashing seems like it'd be heavy handed and awkward here -- but I find I'm speculating (guessing?) too much too soon. As examples, which type(s) of non-VSAM data sets? When do you want to know they've changed -- within what time period? (Nightly?) Who/what wants to know? Bill Gates? :-) A program on the same z/OS system? What type of program? Are there any other facilities/features we should assume or not assume are present/eligible to be used on that z/OS system? (You mentioned a couple, duly noted.) What release(s) of z/OS? Is it enough to know there was a *possible* change (e.g. sensing open for writing/input), or is sensing an actual data set change required? Anything else you can think of that I didn't ask? :-) Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
