Re: Volume compare utility
Jesse, I may be late to the party, but did you look at using DISKCOMP on from CBT? RON HAWKINS Director, Ipsicsopt Pty Ltd (ACN: 627 705 971) m+61 400029610| t: +1 4085625415 | f: +1 4087912585 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, 18 June 2019 06:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Volume compare utility We have been devoted fans and customers of TDMF since long before IBM acquired it. I stand in awe of its magical properties. But it is a bit clumsy when copying/moving thousands of volumes shared by many LPARs. The method we used this time was far more suited to our purpose. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jerry Whitteridge Sent: Monday, June 17, 2019 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Volume compare utility "What" should have been "way" ! Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 06/17/2019 08:29:34 AM: > From: Jerry Whitteridge > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/17/2019 08:30 AM > Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM Mainframe > Discussion List > > In the (distant) past we've been able to get a temporary license from > the vendor of the target disk for TDMF as part of the deal - might be > one what > of you getting a portion of your bridge. > > Jerry Whitteridge > Delivery Manager / Mainframe Architect GTS - Safeway Account > 602 527 4871 Mobile > jerry.whitteri...@ibm.com > > IBM Services > > IBM Mainframe Discussion List wrote on > 06/16/2019 01:16:35 PM: > > > From: Jesse 1 Robinson > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 06/16/2019 01:16 PM > > Subject: [EXTERNAL] Re: Volume compare utility Sent by: IBM > > Mainframe Discussion List > > > > Maybe if I could throw in the Brooklyn Bridge... > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com -- 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: Use of "trap" facility in z/OS?
The below reply is copied from the google groups interface, looks like it was not sent to this list but just to the web interface. On Thursday, June 20, 2019 at 11:08:16 PM UTC-4, robert...@yahoo.com wrote: > On 20 Jun 2019 06:16:47 -0700, john...@gmail.com (John > McKown) wrote: > > >This is purely speculation, but I like what I've read about the "trap" > >facility. I think it is too bad that z/OS doesn't support the use of TRAP2, > >TRAP4, as well as the compare-and-trap and load-and-trap. I agree that they > >are not _necessary_ since the code can do basically the same thing. The > >only reason that I even bring it up is that the paper "IBM Z / LinuxONE > >System Processor Optimization Primer" by C. Kevin Shum on page 51 > >"Optimization - Instruction Selection (1)" recommends using > >"compare-and-trap" where practical, in particular, for null-pointer > >checking. > > > >Perhaps I should have waited for Friday to post this since it is only > >wishful thinking. > > > Unlike the TRAP2/4 instructions, compare-and-trap and load-and-trap > generate perfectly ordinary data exception, and require no particular > support from the OS. They do set a different DXC, although ignoring > that isn't going to impact much. Yes, but that "perfectly ordinary data exception" requires quite a long code path through z/OS services to handle. That is all well and good for one-off trapped conditions, but what about (for an instance) being able to use TRAP and friends to implement instruction-level debugging software or to implement hardware instruction emulators for instruction tracing of complex programs? For such applications a much more efficient mechanism implementing TRAP processing is needed. Since the low-level TRAP interface is hardware-based it SHOULD be far more efficient to use for such purposes than depending on the existing data-exception-catching services. Of course, any formal z/OS support will likely make that reasonably efficient interface far more complicated and expensive. Just my $0.02USD worth. Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mobile pricing query
Hi Laurence, Jumping in here with a bit of general info: Mobile Workload Pricing is a way of mitigating the impact from mobile requests to the rolling four-hour average. It's a sub-capacity offering (and only really makes sense in that space), so you need to have implemented sub-cap SW pricing (i.e. AWLC, CMLC, etc.). Basically, you need to be able to tag and track the CPU time consumed by mobile transactions. They need to be isolated from work stemming from other sources and originate on an approved mobile device (a smartphone, for example). The redbook I link below discusses the criteria for isolation. If you can easily do this (and meet any qualification criteria) it may very well be a no-brainer. If not easily done, you'd need a deeper analysis to understand what work is necessary to architect the required isolation and how much benefit it would actually buy you (i.e. whether and by how much it would lower your peaks). The least amount of work to implement mobile comes with the ability to tag workloads within WLM. Details on that and more can be found here: https://www.redbooks.ibm.com/redpapers/pdfs/redp5359.pdf Here is an updated (2016) US announcement letter for mobile pricing: https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca=an=897=ENUS216-321 If you have additional questions, please feel free to reach out. You might also take a look at the options under Tailored Fit Pricing for IBM Z, which can provide models that are alternatives to the rolling four-hour average. It's worth at least understanding what your options are - for additional info, see: https://www.ibm.com/it-infrastructure/z/software/pricing-tailored-fit Take care, Andrew Sica -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of "trap" facility in z/OS?
On 2019-06-21 4:59 AM, Tony Harminc wrote: I'm not sure that any of the hardware architecture has been implemented specifically for Linux. ISTR hearing that the primary impetus for implementing 20-bit displacement instructions came from the Linux direction. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hipersocket follows OSI ?
Hi Cross posted One of our distributed team asked us whether hipersocket follows OSI model ? As it is a in memory transfer so I was not sure how to explain them. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z14 SE clocks sync to HMC/NTP
We have an issue where the 2 Support Elements on a z14 (3907) don't have the same clock value and don't match the HMC clock. The HMC is getting the time from an NTP server. There is no STP in this environment, and all the doc seems to talk about using STP. How do we get the SEs to sync up to the clock on the HMC without STP? Regards, Jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of "trap" facility in z/OS?
> I'm not sure that any of the hardware architecture has been implemented > specifically for Linux. I certainly do not know one way or the other whether any hardware features were implemented specifically for Linux, but I do not find it impossible, given that there is a whole series of models marketed specifically for Linux (the LinuxONE series, of course). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Thursday, June 20, 2019 11:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of "trap" facility in z/OS? On Thu, 20 Jun 2019 at 10:58, Farley, Peter x23353 wrote: > > Some time back I started a thread on this forum about writing authorized code > or a PC routine to update the DUCT > architectural control block to populate the TRAP fields to make active use of > the variety of TRAP instructions now provided, > and the common consensus at the time was for me to keep my grubby hands off > the DUCT lest I cause a catastrophic and > possibly ipl-able failure. > > IIRC there was a comment in that thread by one of our regular IBM > contributors that at least one IBM product had gone ahead > and used that technique without dispensation from the core z/OS developers > who were (at least at the time) not happy about > the choice made by those product developers. The interesting question, in my opinion, is how such a scheme got to be in the architecture without z/OS software infrastructure to use it. Dan Greiner commented in another thread about how BIC came to be, and I understand that in recent years there has been close collaboration between the hardware architects and the software people in core z/OS, compilers, LE, and particularly Java groups. But if there's no z/OS support... > We have yet to see any further word from IBM on when or if z/OS will provide > the needed system-level interfaces to "safely" > use TRAP and friends. "Business justification needed" and "ROI" are of > course the usual reasons given for delaying support > for the architected hardware capabilities. Hiring more core z/OS developers > and testers to keep up with support for all of the > hardware capabilities never seems to be on the list of possible solutions. > > z/Linux may or may not be ahead of z/OS in regard to actually using TRAP and > friends, but I don't know where one would look > to find out if and/or how it is implemented there. I'm not sure that any of the hardware architecture has been implemented specifically for Linux. Certainly the IBM Linux coders have shown themselves very adept at exploiting existing features in ways that were perhaps not intended or anticipated by the hardware architects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of "trap" facility in z/OS?
On Fri, Jun 21, 2019 at 6:51 AM Chuck wrote: > TDF of course. > Ah, yes. I remember now. We don't actually use it. But it is a nice tool. Too bad our programmers are basically stuck on using the CompuWare suite. > > Chuck Arney > > -- Money is the root of all evil. Evil is the root of all money. With that in mind, money is made by the government ... Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of "trap" facility in z/OS?
TDF of course. Chuck Arney > On Jun 21, 2019, at 5:42 AM, John McKown wrote: > >> On Thu, Jun 20, 2019 at 6:02 PM Chuck Arney wrote: >> >> The TRAP facility was originally implemented in the hardware for Y2K >> support. It was to be used by products to overlay clock related >> instructions so different clocks/dates could be simulated. At least that >> is what I was told many years ago. >> > > That's what I heard too. But it appears that the hardware people have > enhanced it for other "exceptional" processing, such as C language NULL > pointer testing. At present, as far as I can tell in z/OS, it is not being > used for anything. It would require z/OS support as well as HLL (C/C++) > support. Given some comments in another thread on ASSEMBLER-LIST, I am > guess most HLASM programmers would prefer coding like: > >LT R10,POINTER >JZ NULL_REFERENCE > > instead of using some API (perhaps akin to an ESTAEX or ESPIE type > situation) and using > > LAT R10,POINTER #TRAP IF NULL POINTER > > Of course, using this would require more, non-ISO, changes to the C/C++ > compiler so that programmers would have some way to "trap" the exception. > Which would make the code non-portable. > > So I guess I am once again, out in the parking lot at the wrong stadium. > > > -- > Money is the root of all evil. > Evil is the root of all money. > With that in mind, money is made by the government ... > > > Maranatha! <>< > John McKown > > -- > 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: Use of "trap" facility in z/OS?
On Thu, Jun 20, 2019 at 6:02 PM Chuck Arney wrote: > The TRAP facility was originally implemented in the hardware for Y2K > support. It was to be used by products to overlay clock related > instructions so different clocks/dates could be simulated. At least that > is what I was told many years ago. > That's what I heard too. But it appears that the hardware people have enhanced it for other "exceptional" processing, such as C language NULL pointer testing. At present, as far as I can tell in z/OS, it is not being used for anything. It would require z/OS support as well as HLL (C/C++) support. Given some comments in another thread on ASSEMBLER-LIST, I am guess most HLASM programmers would prefer coding like: LT R10,POINTER JZ NULL_REFERENCE instead of using some API (perhaps akin to an ESTAEX or ESPIE type situation) and using LAT R10,POINTER #TRAP IF NULL POINTER Of course, using this would require more, non-ISO, changes to the C/C++ compiler so that programmers would have some way to "trap" the exception. Which would make the code non-portable. So I guess I am once again, out in the parking lot at the wrong stadium. -- Money is the root of all evil. Evil is the root of all money. With that in mind, money is made by the government ... Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of "trap" facility in z/OS?
On Thu, Jun 20, 2019 at 5:41 PM Chuck wrote: > The TRAP Instructions work fine John. You have used a product that uses > them. > I do? I don't know which product that is. Or is "you" a generic in this case? > > Chuck Arney > > -- Money is the root of all evil. Evil is the root of all money. With that in mind, money is made by the government ... Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Radoslav, Many clients I visited allows local admin authority on windows workstation to the machine user for ease of management. However, we get clients monthly reports on success and failures from some clients of us. Most of them respond well to attacks and block them, so even their workstations are protected. I believe it is a question of budget. Banks can afford protection that hospitals can't (and bankers can afford better medical treatment than others...). If you look at the names of clients that were hit by such attach, it is almost always a client that can't afford a complete security systems. On the mainframe, only few datasets are owned by en users, most of them are not significant to the user (ISPF temporary datasets, some "on work" job or source code libraries that most of them are on the change management store, etc.). How many DB2 data tables can be updated by human clients directly? Near if not zero. So,from the attacker point of view, no much to encrypt,unless he get a service account. This is more complex to perform. and as I always say, security cost you a lot, but if it works, managers doesn't see the value of it. ITschak On Fri, Jun 21, 2019 at 1:04 PM R.S. wrote: > Yes, I don't come to SHARE conferences, I wish, but I don't. > However it seems I saw the presentation on youtube. > AND WHAT? > Yes, I can encrypt my own dataset and loose the key. I'm aware of that. > My question was about real life case. > Every file or dataset can be encrypted or deleted, that's rather > obvious. The question is how many times did it happen on z/OS. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > W dniu 2019-06-18 o 05:09, Charles Mills pisze: > > Because you don't come to SHARE? Specifically, Chad Rikansrud's security > keynote in March of 2017. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > > Sent: Monday, June 17, 2019 1:53 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: mainframe hacking "success stories"? > > > > Did they use z/OS? > > Or maybe Linux on PC? > > Not? > > Windows? > > What a surprise! > > > > BTW: I have heard many times about filese encrypted by ransomware. Why > > it's always Windows? Why the only file encryption on z/OS I ever heard > > is the encryption directed by administrator? > > Why? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > . > > > > > == > > Jeśli nie jesteś adresatem tej wiadomości: > > - powiadom nas o tym w mailu zwrotnym (dziękujemy!), > - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub > zapisałeś na dysku). > Wiadomość ta może zawierać chronione prawem informacje, które może > wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia > (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, > narusza prawo i może podlegać karze. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2018 r. wynosi 169.248.488 złotych. > > If you are not the addressee of this message: > > - let us know by replying to this e-mail (thank you!), > - delete this message permanently (including all the copies which you have > printed out or saved). > This message may contain legally protected information, which may be used > exclusively by the addressee.Please be reminded that anyone who > disseminates (copies, distributes) this message or takes any similar > action, violates the law and may be penalised. > > mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 > Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the > Capital City of Warsaw, 12th Commercial Division of the National Court > Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169,248,488 as at 1 January 2018. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe hacking "success stories"?
Yes, I don't come to SHARE conferences, I wish, but I don't. However it seems I saw the presentation on youtube. AND WHAT? Yes, I can encrypt my own dataset and loose the key. I'm aware of that. My question was about real life case. Every file or dataset can be encrypted or deleted, that's rather obvious. The question is how many times did it happen on z/OS. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-06-18 o 05:09, Charles Mills pisze: Because you don't come to SHARE? Specifically, Chad Rikansrud's security keynote in March of 2017. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, June 17, 2019 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe hacking "success stories"? Did they use z/OS? Or maybe Linux on PC? Not? Windows? What a surprise! BTW: I have heard many times about filese encrypted by ransomware. Why it's always Windows? Why the only file encryption on z/OS I ever heard is the encryption directed by administrator? Why? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
