Re: Ideas for hash of a sequential data set
Kirk, What about at the physical level, for example an increase in size .? Scott On Sunday, August 23, 2015, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Fri, 21 Aug 2015 15:51:43 -0400, Thomas David Rivers riv...@dignus.com javascript:; wrote: 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... Of course you must read the entire file to compute the hash. But if you save the hashes you can compare any two files without re-reading either in its entierty. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: TRUSTED attribute for IBM tasks
Retired Mainframer, Amen brother..been there my entire Systems Career. I have worked only for a handful of managers who got it. I work for a great one now, thank god. Scott On Sunday, August 23, 2015, retired mainframer retired-mainfra...@q.com wrote: 15+ years ago as I installed the first IBM mainframe the customer had ever seen, I begged the project leader to let someone shadow us as we configured the system so they would have some idea how to deal with any issues that arose after we left. His response: If we have problems, we can always press the help key. You can lead a manager to water but you can't make him think. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU javascript:;] On Behalf Of Ed Finnell Sent: Sunday, August 23, 2015 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: Re: TRUSTED attribute for IBM tasks Ctl, Alt, Del repeat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: TRUSTED attribute for IBM tasks
Something about some road paved with good intentions? Good war story. Dr. Murphy is indeed a busy fellow. And an amazing teacher as most of us remember his lessons well. Thanks for sharing that one. Linda Sent from my iPhone On Aug 22, 2015, at 8:04 PM, J O Skip Robinson jo.skip.robin...@sce.com wrote: The moral of the following war story is that no amount of monitoring or tracing or testing can save you from Dr. Murphy. Some idiot in our shop once misunderstood or misremembered something he thought he had heard. He overrode the built-in (default) PPT entry for JES2 to remove the blessed attributes. Things worked fine for 10 years until someone else innocently created a generic RACF profile that happened to encompass JES2 checkpoint and spool. At the next IPL, JES2 got S913 on his own data sets. It had been so long since the errant PPT entry that even the idiot had no clue it was his fault. The idiot should have been fired, but I'm still here. . . . 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: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of Stu Henderson Sent: Friday, August 21, 2015 12:48 PM To: rac...@listserv.uga.edu Subject: Re: TRUSTED attribute for IBM tasks Joel, Your comments make sense. It would be useful to us all if someone would monitor the logging produced by TRUSTED to see which STCs actually use it and why. It would also be useful if IBM (and other vendor) doc. would provide substantiation, describing the reasoning around statements that some STC needs TRUSTED. And maybe possible work arounds. And maybe why effective change control on the configuration files for these STCs is important. It strikes me that any security weakness in web facing started tasks with TRUSTED would break IBM's Integrity Statement for MVS, since TRUSTED would give access to the FACILITY class rules named CSVAPF. Best regards, Stu On 8/21/2015 2:23 PM, Tilton, Joel wrote: Juan, Well no offense to IBM but I've reached a new level of paranoia with them recommending TRUSTED. Why? I'm glad you asked. :-) Optionally TRUSTED means exactly that and in my experience IXGLOGR, GPMSERVE and even the Netivew UNIX STC can function without TRUSTED. Of course it's much less work to give an STC TRUSTED. If something is optional then I question the requirement to give it TRUSTED. If I were an auditor I would not want a task having this kind of high powered access just because IBM says its optional. Be cautious if you give TRUSTED to anything when you're using SERVAUTH to secure networks and ports. You've just given the task total access to any ports and network zones it wants; just because it is an STC does not mean it should be entitled to such high level of access to your network. I think TRUSTED should really be reserved for core z/OS components like JES or XCF, for example, but certainly not tasks that provide service to end users or listen on ports. My two cents. Hope this helps. Your mileage may vary. Joel Tilton Senior Security Engineer EC Mainframe Security Engineering DTCC Tampa jtil...@dtcc.com +1 813-470-2160 Visit us at www.dtcc.com or follow us on Twitter @The_DTCC and on LinkedIn. To learn about career opportunities at DTCC, please visit dtcc.com/careers. Classification: DTCC Non-Confidential (WHITE) The views I have expressed in this email are my own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of my employer. -Original Message- From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of Mautalen Juan Guillermo Sent: Friday, August 21, 2015 10:13 AM To: rac...@listserv.uga.edu Subject: TRUSTED attribute for IBM tasks Hi! In the MVS Initialization and Tuning Reference book, there is a valuable list of STC that IBM recommends defining as TRUSTED. I always follow this recommendation (even for the OPTIONAL ones). We are currently at z/OS 1.13. However, I was looking at the z/OS 2.1 version of this list, and I see some additions (compared with 1.13 list). For instance: SMSPDSE1, WLM, ZFS. I was wondering whether to change them to TRUSTED right now (when still in 1.13), or wait until migration (that will not happen very soon, and will probably be to 2.2, by the way). Of course, no harm will be done to a task by marking it TRUSTED, but I don't know whether it is indeed a good idea to do it in advance, when we are not yet running the z/OS version suggesting it. What do you think? Thanks in advance, Juan G. Mautalen -- For IBM-MAIN subscribe / signoff / archive access
Re: TRUSTED attribute for IBM tasks
On Sun, 23 Aug 2015 03:04:35 +, J O Skip Robinson wrote: The idiot should have been fired, but I'm still here. Luckily for your shop. All too often the old knowledgeable incumbents are let go, and the outsourcers minions have no bloody idea of the history of the shop. What happened, how to fix it ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRUSTED attribute for IBM tasks
15+ years ago as I installed the first IBM mainframe the customer had ever seen, I begged the project leader to let someone shadow us as we configured the system so they would have some idea how to deal with any issues that arose after we left. His response: If we have problems, we can always press the help key. You can lead a manager to water but you can't make him think. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Sunday, August 23, 2015 5:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRUSTED attribute for IBM tasks Ctl, Alt, Del repeat -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRUSTED attribute for IBM tasks
Ctl, Alt, Del repeat In a message dated 8/23/2015 7:30:44 A.M. Central Daylight Time, ibm-m...@tpg.com.au writes: What happened, how to fix it ... -- 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 15:51:43 -0400, Thomas David Rivers riv...@dignus.com wrote: 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... Of course you must read the entire file to compute the hash. But if you save the hashes you can compare any two files without re-reading either in its entierty. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRUSTED attribute for IBM tasks
Replying to my own post. ;-( So I would like to come to bejeesus on this subject. In trying to compare the IBM default PPT entries with whatever we may have specified, I'm stuck because the new (2.1) D PPT displays first all the Parmlib Values followed by the remaining IBM default values. It seems that a default value overridden by a parmlib entry is not displayed. In other words, I can't see both a default value and a corresponding parmlib value on the same system. I'm disinclined to IPL with no parmlib entries at all just to see what IBM would provide. Does anyone know a straightforward way to compare and contrast installation values with default values? . . . 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 J O Skip Robinson Sent: Saturday, August 22, 2015 8:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRUSTED attribute for IBM tasks The moral of the following war story is that no amount of monitoring or tracing or testing can save you from Dr. Murphy. Some idiot in our shop once misunderstood or misremembered something he thought he had heard. He overrode the built-in (default) PPT entry for JES2 to remove the blessed attributes. Things worked fine for 10 years until someone else innocently created a generic RACF profile that happened to encompass JES2 checkpoint and spool. At the next IPL, JES2 got S913 on his own data sets. It had been so long since the errant PPT entry that even the idiot had no clue it was his fault. The idiot should have been fired, but I'm still here. . . . 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: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of Stu Henderson Sent: Friday, August 21, 2015 12:48 PM To: rac...@listserv.uga.edu Subject: Re: TRUSTED attribute for IBM tasks Joel, Your comments make sense. It would be useful to us all if someone would monitor the logging produced by TRUSTED to see which STCs actually use it and why. It would also be useful if IBM (and other vendor) doc. would provide substantiation, describing the reasoning around statements that some STC needs TRUSTED. And maybe possible work arounds. And maybe why effective change control on the configuration files for these STCs is important. It strikes me that any security weakness in web facing started tasks with TRUSTED would break IBM's Integrity Statement for MVS, since TRUSTED would give access to the FACILITY class rules named CSVAPF. Best regards, Stu On 8/21/2015 2:23 PM, Tilton, Joel wrote: Juan, Well no offense to IBM but I've reached a new level of paranoia with them recommending TRUSTED. Why? I'm glad you asked. :-) Optionally TRUSTED means exactly that and in my experience IXGLOGR, GPMSERVE and even the Netivew UNIX STC can function without TRUSTED. Of course it's much less work to give an STC TRUSTED. If something is optional then I question the requirement to give it TRUSTED. If I were an auditor I would not want a task having this kind of high powered access just because IBM says its optional. Be cautious if you give TRUSTED to anything when you're using SERVAUTH to secure networks and ports. You've just given the task total access to any ports and network zones it wants; just because it is an STC does not mean it should be entitled to such high level of access to your network. I think TRUSTED should really be reserved for core z/OS components like JES or XCF, for example, but certainly not tasks that provide service to end users or listen on ports. My two cents. Hope this helps. Your mileage may vary. Joel Tilton Senior Security Engineer EC Mainframe Security Engineering DTCC Tampa jtil...@dtcc.com +1 813-470-2160 Visit us at www.dtcc.com or follow us on Twitter @The_DTCC and on LinkedIn. To learn about career opportunities at DTCC, please visit dtcc.com/careers. Classification: DTCC Non-Confidential (WHITE) The views I have expressed in this email are my own personal views, and are not endorsed or supported by, and do not necessarily express or reflect, the views, positions or strategies of my employer. -Original Message- From: RACF Discussion List [mailto:rac...@listserv.uga.edu] On Behalf Of Mautalen Juan Guillermo Sent: Friday, August 21, 2015 10:13 AM To: rac...@listserv.uga.edu Subject: TRUSTED attribute for IBM tasks Hi! In the MVS Initialization and Tuning Reference book, there is a valuable list of STC that IBM recommends defining as TRUSTED. I always follow this recommendation (even for the OPTIONAL ones). We are currently at z/OS 1.13.
Re: TRUSTED attribute for IBM tasks
On Mon, 24 Aug 2015 00:23:40 +, J O Skip Robinson jo.skip.robin...@sce.com wrote: I'm disinclined to IPL with no parmlib entries at all just to see what IBM would provide. Does anyone know a straightforward way to compare and contrast installation values with default values? If the default values are still documented in MVS Initialization and Tuning, you could compare the output of D PPT with what the book shows. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 8-byte V-cons
At 18:04 -0700 on 08/21/2015, John Ehrman wrote about 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 Note that there is a MAJOR difference between the value that ends up on a VCON vs an EXTRN'ed ACON. A VCON ends up with the address of the external address. An ACON gets that address ADDED to the original value in the ACON. IOW: EXTRN EXTERNAL DCV(EXTERNAL+4) points at EXTERNAL DCA(EXTERNAL+4) points 4 bytes past EXTERNAL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 8-byte V-cons
On Sun, 23 Aug 2015 21:43:49 -0400, Robert A. Rosenberg wrote: IOW: EXTRN EXTERNAL DCV(EXTERNAL+4) points at EXTERNAL DCA(EXTERNAL+4) points 4 bytes past EXTERNAL Why isn't the former code reported as a syntax error? (If not assembled as coded.) Were V-cons designed to support overlays? Is there any prospect of RMODE(64) overlays? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRUSTED attribute for IBM tasks
Replying to my own post. ;-( So I would like to come to bejeesus on this subject. In trying to compare the IBM default PPT entries with whatever we may have specified, I'm stuck because the new (2.1) D PPT displays first all the Parmlib Values followed by the remaining IBM default values. It seems that a default value overridden by a parmlib entry is not displayed. In other words, I can't see both a default value and a corresponding parmlib value on the same system. I'm disinclined to IPL with no parmlib entries at all just to see what IBM would provide. Does anyone know a straightforward way to compare and contrast installation values with default values? https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/ieae200541.htm Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
