Re: RSUs
On 5/30/2019 11:32 AM, Styles, Andy , ITS zPlatform Services wrote: Not exactly. It is a set of PTFs that have been extensively tested together by IBM. Then they have been adopted as a whole by many shops. Is that true? I thought it was just the CST that was extensively tested; that's only released quarterly, whereas RSUs are released every month. IBM's RSU (Recommended Service Update) is assigned like this: IBM's monthly RSUs (RSUyy01, 02, 04, 05, 07, ...) identify PTFs that fix HIPER, PE, Security/Integrity, or pervasive problems *AND* have completed a 30 day CST (Consolidated Service Test) cycle. IBM's quarterly RSUs (RSUyy03, 06, 09, 12) identify the usual monthly RSU PTFs as described above, plus all other PTFs that have completed at least a 90 day CST cycle. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Classification: Public > Not exactly. It is a set of PTFs that have been extensively tested together > by IBM. > Then they have been adopted as a whole by many shops. > > -- > Tom Marchant Is that true? I thought it was just the CST that was extensively tested; that's only released quarterly, whereas RSUs are released every month. -- Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On Wed, 29 May 2019 23:06:01 +, Jesse 1 Robinson wrote: >The advertised virtue of RSU is that it represents a well-defined bundle of >fixes that have been tested together in 'many' shops. Not exactly. It is a set of PTFs that have been extensively tested together by IBM. Then they have been adopted as a whole by many shops. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
The advertised virtue of RSU is that it represents a well-defined bundle of fixes that have been tested together in 'many' shops. The idea of tacking on an RSU label to some other fix after the bundle has shipped would seem to violate the definition and compromise its value. I think we agree that it ought not to happen. . . 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 Kurt Quackenbush Sent: Wednesday, May 29, 2019 5:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RSUs On 5/29/2019 3:57 AM, Styles, Andy , ITS zPlatform Services wrote: >> Did you really get more PTFs assigned RSU1903 the second time? Or >> did you simply get more PTFs? Let me explain: > > I believe we received new PTFs - with RSU1903 being assigned to them at the > same time. That's the behaviour I'm querying - and I think you agree - once > IBM has announced RSU1903, there should have been no further PTFs with that > RSU, whether I specify RECOMMENDED or ALL. > >> For the IBM server, when you run RECEIVE ORDER with >> CONTENT(RECOMMENDED), you get back PTFs identified with a Recommended >> Service Update SOURCEID (RSUyymm) *AND* PTFs that resolve critical >> problems (HIPER or PE). PTFs get assigned RSUyynn only once a month, but >> HIPER and PE fixing PTFs can get assigned every day. > > I understand the HIPER/PE fixes, but they surely should not be assigned > RSU1903 after the publish date? Correct. >> However, if you saw any RSU1903 sourceids being assigned during the >> second RECEIVE ORDER, then perhaps the server's behavior requires >> further analysis. If this is the case, a PMR may be warranted, but >> you're going to have to provide proof, as in the SMP/E output for both jobs. > > Well, we're coming up to another RSU date in the next few days. I can attempt > to repeat this, and see what happens. Fair enough. It will be helpful to keep track of changes to your SMP/E environment between your two RECEIVE ORDER jobs, and please be sure to use the same RECEIVE ORDER command. For example, either use FORTGTZONES in both or not at all. My preference is not at all. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- 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: RSUs
On 5/29/2019 3:57 AM, Styles, Andy , ITS zPlatform Services wrote: Did you really get more PTFs assigned RSU1903 the second time? Or did you simply get more PTFs? Let me explain: I believe we received new PTFs - with RSU1903 being assigned to them at the same time. That's the behaviour I'm querying - and I think you agree - once IBM has announced RSU1903, there should have been no further PTFs with that RSU, whether I specify RECOMMENDED or ALL. For the IBM server, when you run RECEIVE ORDER with CONTENT(RECOMMENDED), you get back PTFs identified with a Recommended Service Update SOURCEID (RSUyymm) *AND* PTFs that resolve critical problems (HIPER or PE). PTFs get assigned RSUyynn only once a month, but HIPER and PE fixing PTFs can get assigned every day. I understand the HIPER/PE fixes, but they surely should not be assigned RSU1903 after the publish date? Correct. However, if you saw any RSU1903 sourceids being assigned during the second RECEIVE ORDER, then perhaps the server's behavior requires further analysis. If this is the case, a PMR may be warranted, but you're going to have to provide proof, as in the SMP/E output for both jobs. Well, we're coming up to another RSU date in the next few days. I can attempt to repeat this, and see what happens. Fair enough. It will be helpful to keep track of changes to your SMP/E environment between your two RECEIVE ORDER jobs, and please be sure to use the same RECEIVE ORDER command. For example, either use FORTGTZONES in both or not at all. My preference is not at all. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Classification: Public Hi Kurt, > Did you really get more PTFs assigned RSU1903 the second time? Or did you > simply get > more PTFs? Let me explain: I believe we received new PTFs - with RSU1903 being assigned to them at the same time. That's the behaviour I'm querying - and I think you agree - once IBM has announced RSU1903, there should have been no further PTFs with that RSU, whether I specify RECOMMENDED or ALL. > For the IBM server, when you run RECEIVE ORDER with CONTENT(RECOMMENDED), you > get back > PTFs identified with a Recommended Service Update SOURCEID (RSUyymm) *AND* > PTFs that > resolve critical problems (HIPER or PE). PTFs get assigned RSUyynn only once > a month, > but HIPER and PE fixing PTFs can get assigned every day. I understand the HIPER/PE fixes, but they surely should not be assigned RSU1903 after the publish date? > However, if you saw any RSU1903 sourceids being assigned during the second > RECEIVE ORDER, > then perhaps the server's behavior requires further analysis. If this is the > case, a > PMR may be warranted, but you're going to have to provide proof, as in the > SMP/E output > for both jobs. Well, we're coming up to another RSU date in the next few days. I can attempt to repeat this, and see what happens. > Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when > he applies PTFs. Andy Styles z/Series System Programmer Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On 5/28/2019 12:04 PM, Styles, Andy , ITS zPlatform Services wrote: I've snipped a fair bit of this, but (and I've manually added quoting, so apologies if it breaks): Were any of these PTFs also received in the prior RECEIVE ORDER? And Were they applied and accepted, perhaps purging them from the global zone prior to the latest RECEIVE ORDER? Were they assigned the RSU1903 sourceid in the first, second, or both RECEIVEs? We definitely did not have the second set of fixes in the global zone prior to the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely perhaps) assumed I'd get the latest RSU. This is where this question has arisen from - how did I get more fixes tagged with RSU1903 with a second RECEIVE RECOMMENDED, after the RSU publish date? Did you really get more PTFs assigned RSU1903 the second time? Or did you simply get more PTFs? Let me explain: For the IBM server, when you run RECEIVE ORDER with CONTENT(RECOMMENDED), you get back PTFs identified with a Recommended Service Update SOURCEID (RSUyymm) *AND* PTFs that resolve critical problems (HIPER or PE). PTFs get assigned RSUyynn only once a month, but HIPER and PE fixing PTFs can get assigned every day. Therefore, I fully expect your second RECEIVE ORDER would obtain HIPER or PE fixing PTFs that were not yet available, or not yet assigned HIPER or PE, during your first RECEIVE ORDER. If only HIPER or PRP sourceids were assigned during the second RECEIVE ORDER, and you saw no new RSU1903 sourceids being assigned, then I suggest the server is processing correctly. However, if you saw any RSU1903 sourceids being assigned during the second RECEIVE ORDER, then perhaps the server's behavior requires further analysis. If this is the case, a PMR may be warranted, but you're going to have to provide proof, as in the SMP/E output for both jobs. This last question about when/if RSU1903 was assigned is the important one, but I fear you may not know the answer without the SMPRPT output for the RECEIVEs. I have some stored job output, but I can't guarantee that I have ALL output, so I don't know if it'll be enough, or whether it contains what we're looking for. Fantastic as it is to get support this way, are we moving into PMR territory? Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
My experience is that the RSU doesn't et to RECEIVEORDER until one day after I get the email that the new service level is available > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Styles, Andy (ITS zPlatform Services) > Sent: Tuesday, May 28, 2019 9:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RSUs > > Classification: Public > Hi Kurt, > > I've snipped a fair bit of this, but (and I've manually added quoting, so > apologies if it breaks): > > > Were any of these PTFs also received in the prior RECEIVE ORDER? And > > Were they applied and accepted, perhaps purging them from the global > > zone prior to the latest RECEIVE ORDER? Were they assigned the RSU1903 > sourceid in the first, second, or both RECEIVEs? > > We definitely did not have the second set of fixes in the global zone prior to > the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely > perhaps) assumed I'd get the latest RSU. This is where this question has > arisen from - how did I get more fixes tagged with RSU1903 with a second > RECEIVE RECOMMENDED, after the RSU publish date? > > > This last question about when/if RSU1903 was assigned is the important > > one, but I fear you may not know the answer without the SMPRPT output > for the RECEIVEs. > > I have some stored job output, but I can't guarantee that I have ALL output, > so I don't know if it'll be enough, or whether it contains what we're looking > for. Fantastic as it is to get support this way, are we moving into PMR > territory? > > -- > Andy Styles > z/Series System Programmer > > > Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC95000. Telephone: 0131 225 4555. > > > > Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. > Registered in England and Wales no. 2065. Telephone 0207626 1500. > > > > Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. > Registered in Scotland no. SC327000. Telephone: 03457 801 801. > > > > Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, > London EC2V 7HN. Registered in England and Wales no. 10399850. > > > > Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc > are authorised by the Prudential Regulation Authority and regulated by the > Financial Conduct Authority and Prudential Regulation Authority. > > > > Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly- > owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank > Corporate Markets Wertpapierhandelsbank GmbH has its registered office at > Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is > registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank > Corporate Markets Wertpapierhandelsbank GmbH is supervised by the > Bundesanstalt für Finanzdienstleistungsaufsicht. > > > > Halifax is a division of Bank of Scotland plc. > > > > HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in > Scotland no. SC218813. > > > > This e-mail (including any attachments) is private and confidential and may > contain privileged material. If you have received this e-mail in error, please > notify the sender and delete it (including any attachments) immediately. You > must not copy, distribute, disclose or use any of the information in it or any > attachments. Telephone calls may be monitored or recorded. > > > -- > 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: RSUs
Classification: Public Hi Kurt, I've snipped a fair bit of this, but (and I've manually added quoting, so apologies if it breaks): > Were any of these PTFs also received in the prior RECEIVE ORDER? And Were > they applied and > accepted, perhaps purging them from the global zone prior to the latest > RECEIVE ORDER? Were > they assigned the RSU1903 sourceid in the first, second, or both RECEIVEs? We definitely did not have the second set of fixes in the global zone prior to the second RECEIVE; given I specified RECOMMENDED both times, I (naïvely perhaps) assumed I'd get the latest RSU. This is where this question has arisen from - how did I get more fixes tagged with RSU1903 with a second RECEIVE RECOMMENDED, after the RSU publish date? > This last question about when/if RSU1903 was assigned is the important one, > but I fear you > may not know the answer without the SMPRPT output for the RECEIVEs. I have some stored job output, but I can't guarantee that I have ALL output, so I don't know if it'll be enough, or whether it contains what we're looking for. Fantastic as it is to get support this way, are we moving into PMR territory? -- Andy Styles z/Series System Programmer Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On 5/24/2019 11:24 AM, Styles, Andy , ITS zPlatform Services wrote: I have the SMPGLOG (GLOBAL log), but not the jobs. I'm reluctant to post a large amount of SMPLOG output here, but here (hopefully relevant) snippets: RECEIVE ORDER(ORDERSERVER(ORDRINFO) CONTENT(RECOMMENDED) CLIENT(CLNTINFO) ) . ORDER ORD00018 HAS BEEN SENT TO THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00018-05April2019-08.45.34.407 FOR RECEIVE PROCESSING. Unfortunately the SMPLOG doesn't show us the ASSIGN statements and SOURCEIDs that were processed, which is what I was hoping to see in your output. We then received a bunch of PTFs as a result - I can list them if you wish. Now, yesterday I noticed that I didn't specify a target zone here. There are two target zones in the GLOBAL zone - the previous iteration of this process, and a clone of it (which is the one RSU1903 was eventually applied to), so we can look across multiple target zones to see if/where a PTF is applied. When I re-did the RECEIVE ORDER, I added FORTGTZONE, though to me, that should have made no difference. Hmmm... probably FORTGTZONE is not interesting here, but depending on other activity in your global and target zones, I wouldn't completely rule it out as a factor. I then ended up with this: RECEIVE ORDER(ORDERSERVER(ORDRINFO) CONTENT(RECOMMENDED) CLIENT(CLNTINFO) FORTGTZONES(TGTD) ) . ORDER ORD00020 HAS BEEN SENT TO THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00020-22May2019-17.19.02.141 FOR RECEIVE PROCESSING. And then received the following fixes: SYSMOD ENTRY UA98295 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98305 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98317 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98340 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98341 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98707 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98723 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98804 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98845 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98920 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98954 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98965 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99018 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99029 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99050 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99059 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99094 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99149 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99208 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99224 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99278 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99283 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99306 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI60691 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61245 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61642 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61783 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62355 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62458 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62648 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI63041 WAS STORED IN THE GLOBAL ZONE. Were any of these PTFs also received in the prior RECEIVE ORDER? And Were they applied and accepted, perhaps purging them from the global zone prior to the latest RECEIVE ORDER? Were they assigned the RSU1903 sourceid in the first, second, or both RECEIVEs? This last question about when/if RSU1903 was assigned is the important one, but I fear you may not know the answer without the SMPRPT output for the RECEIVEs. Now, looking back through the log, I can also see quite a few messages like this: MCS UA98840 WAS DELETED FROM THE SMPPTS LIBRARY. MCS UA98840 WAS DELETED FROM THE SMPPTS1 LIBRARY. MCS ENTRY UA98840 WAS STORED IN THE SMPPTS LIBRARY. SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE. RECEIVE PROCESSING WAS SUCCESSFUL FOR SYSMOD UA98840. Which confuses me (not difficult) - why is it already in the SMPPTS dataset? Nonetheless, I didn't do a REJECT of anything first, so it was RECEIVEd ok. The "MCS WAS DELETED..." messages are simply SMP/E making sure there are no duplicate PTF members across your SMPPTS and SMPPTS1 data sets. You can ignore these messages. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On 5/24/2019 10:19 AM, Jousma, David wrote: Bob, I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER Process first uploads an inventory to IBM. Then the order process only sends you what you don’t have. In my opinion a more complete answer is not necessary. Your posts describe the processing of SMP/E RECEIVE ORDER well, thank you Dave. If Bob still has questions or comments, please restate and clarify them. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Bob, I'm not exactly sure what you are asking but if you just run this, it automatically uploads the bitmap to IBM before the order is built. The manual process is only needed if you are actually logging on to ShopZ website to place orders.I only use that when I want to update ShopZ to correctly filter all my installed product versions when ordering PDO's for individual product refreshes between z/OS Serverpac orders. The only requirement for this to run is that you have to be able to communicate with IBM servers from the mainframe you are running from.Here, they let me open the firewall for outbound connections to IBM only on-demand. SETBOUNDARY (GLOBAL) . RECEIVE ORDER (CLIENT (CLIENT) CONTENT (ALL) ORDERSERVER (SERVER) FORTGTZONES (MVSTZN MVSCBT) WAIT(120)) DELETEPKG. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Friday, May 24, 2019 11:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Dave, There's my first problem! I have been using Shopz's RFN with the package they create. :-( I had already stopped using Shopz for daily PTFs orders indicated by Missing Fix, etc., using RECEIVE ORDER processing instead. I saw your example for the inventory. Can the two steps be automatically combined in a batch job and not use SHOPz at all? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, May 24, 2019 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs Bob, I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER Process first uploads an inventory to IBM. Then the order process only sends you what you don’t have. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Friday, May 24, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Kurt, Speaking of RSUs, is there a way to provide an inventory of PTFs already received so that I don't end up reordering and transmitting gigabytes of PTFs that have already been ordered, downloaded and received? As it is now, I am forced to run the RSU job on the weekend so that I stop getting the "17 of 20" failures after hours of wall clock time. And while I am thinking of enhancements, how about an optional check of a mask against a mask of the DDDEF volser that would flag a difference? Yeah, I know, the file allocation report is supposed to be the last line of defense, but sometimes it is tough to spot a one character difference. Ask me how I know. Still not sure why a coworker changed it without letting others know. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, May 24, 2019 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for bo
Re: RSUs
Dave, There's my first problem! I have been using Shopz's RFN with the package they create. :-( I had already stopped using Shopz for daily PTFs orders indicated by Missing Fix, etc., using RECEIVE ORDER processing instead. I saw your example for the inventory. Can the two steps be automatically combined in a batch job and not use SHOPz at all? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, May 24, 2019 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs Bob, I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER Process first uploads an inventory to IBM. Then the order process only sends you what you don’t have. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Friday, May 24, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Kurt, Speaking of RSUs, is there a way to provide an inventory of PTFs already received so that I don't end up reordering and transmitting gigabytes of PTFs that have already been ordered, downloaded and received? As it is now, I am forced to run the RSU job on the weekend so that I stop getting the "17 of 20" failures after hours of wall clock time. And while I am thinking of enhancements, how about an optional check of a mask against a mask of the DDDEF volser that would flag a difference? Yeah, I know, the file allocation report is supposed to be the last line of defense, but sometimes it is tough to spot a one character difference. Ask me how I know. Still not sure why a coworker changed it without letting others know. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, May 24, 2019 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for both jobs please. BTW, as already mentioned, consider using CONTENT(ALL) instead of CONTENT(RECOMMENDED) in the future. I'm hard pressed to think of a good reason to only obtain recommended PTFs these days. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: RSUs
Classification: Public I have the SMPGLOG (GLOBAL log), but not the jobs. I'm reluctant to post a large amount of SMPLOG output here, but here (hopefully relevant) snippets: RECEIVE ORDER(ORDERSERVER(ORDRINFO) CONTENT(RECOMMENDED) CLIENT(CLNTINFO) ) . ORDER ORD00018 HAS BEEN SENT TO THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00018-05April2019-08.45.34.407 FOR RECEIVE PROCESSING. We then received a bunch of PTFs as a result - I can list them if you wish. Now, yesterday I noticed that I didn't specify a target zone here. There are two target zones in the GLOBAL zone - the previous iteration of this process, and a clone of it (which is the one RSU1903 was eventually applied to), so we can look across multiple target zones to see if/where a PTF is applied. When I re-did the RECEIVE ORDER, I added FORTGTZONE, though to me, that should have made no difference. I then ended up with this: RECEIVE ORDER(ORDERSERVER(ORDRINFO) CONTENT(RECOMMENDED) CLIENT(CLNTINFO) FORTGTZONES(TGTD) ) . ORDER ORD00020 HAS BEEN SENT TO THE SERVER AT https://eccgw01.boulder.ibm.com/services/projects/ecc/ws/. ENQ WAS SUCCESSFUL FOR EXCLUSIVE USE OF ORD00020-22May2019-17.19.02.141 FOR RECEIVE PROCESSING. And then received the following fixes: SYSMOD ENTRY UA98295 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98305 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98317 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98340 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98341 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98707 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98723 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98804 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98845 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98920 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98954 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA98965 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99018 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99029 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99050 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99059 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99094 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99149 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99208 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99224 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99278 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99283 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UA99306 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI60691 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61245 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61642 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI61783 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62355 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62458 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI62648 WAS STORED IN THE GLOBAL ZONE. SYSMOD ENTRY UI63041 WAS STORED IN THE GLOBAL ZONE. Now, looking back through the log, I can also see quite a few messages like this: MCS UA98840 WAS DELETED FROM THE SMPPTS LIBRARY. MCS UA98840 WAS DELETED FROM THE SMPPTS1 LIBRARY. MCS ENTRY UA98840 WAS STORED IN THE SMPPTS LIBRARY. SYSMOD ENTRY UA98840 WAS STORED IN THE GLOBAL ZONE. RECEIVE PROCESSING WAS SUCCESSFUL FOR SYSMOD UA98840. Which confuses me (not difficult) - why is it already in the SMPPTS dataset? Nonetheless, I didn't do a REJECT of anything first, so it was RECEIVEd ok. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: 24 May 2019 14:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or
Re: RSUs
I think that the process is similar if ordering manually via ShopZ. The only difference is you have run the inventory job against your zones first, upload that to ShopZ, and use that uploaded report when placing your order for maintenance. //STEP1EXEC PGM=GIMXSID,PARM='WAIT=10MIN,L=ENU' //SYSPRINT DD SYSOUT=* //SMPOUT DD SYSOUT=* //SMPXTOUT DD PATH='/tmp/smpefeatures23', //PATHOPTS=(OWRONLY,OCREAT,OTRUNC), //FILEDATA=BINARY,PATHMODE=(SIRWXU,SIRWXG,SIRWXO) //SYSINDD DATA,DLM=$$ CSI=SMPE.ZOS23.GLOBAL.CSI TARGET=MVSTZN _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Friday, May 24, 2019 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Bob, I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER Process first uploads an inventory to IBM. Then the order process only sends you what you don’t have. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Friday, May 24, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Kurt, Speaking of RSUs, is there a way to provide an inventory of PTFs already received so that I don't end up reordering and transmitting gigabytes of PTFs that have already been ordered, downloaded and received? As it is now, I am forced to run the RSU job on the weekend so that I stop getting the "17 of 20" failures after hours of wall clock time. And while I am thinking of enhancements, how about an optional check of a mask against a mask of the DDDEF volser that would flag a difference? Yeah, I know, the file allocation report is supposed to be the last line of defense, but sometimes it is tough to spot a one character difference. Ask me how I know. Still not sure why a coworker changed it without letting others know. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, May 24, 2019 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for both jobs please. BTW, as already mentioned, consider using CONTENT(ALL) instead of CONTENT(RECOMMENDED) in the future. I'm hard pressed to think of a good reason to only obtain recommended PTFs these days. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is inte
Re: RSUs
On Fri, 24 May 2019 09:38:22 -0400, Kurt Quackenbush wrote: > If you did receive such ASSIGN statements, >and if you still have it, I'd like to see the RECEIVE command output for >both jobs please. If he doesn't have the jobs, will the data from the SMPLOG for that period help? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Bob, I'm sure Kurt will give a more complete answer, but the RECEIVE ORDER Process first uploads an inventory to IBM. Then the order process only sends you what you don’t have. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Friday, May 24, 2019 10:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Kurt, Speaking of RSUs, is there a way to provide an inventory of PTFs already received so that I don't end up reordering and transmitting gigabytes of PTFs that have already been ordered, downloaded and received? As it is now, I am forced to run the RSU job on the weekend so that I stop getting the "17 of 20" failures after hours of wall clock time. And while I am thinking of enhancements, how about an optional check of a mask against a mask of the DDDEF volser that would flag a difference? Yeah, I know, the file allocation report is supposed to be the last line of defense, but sometimes it is tough to spot a one character difference. Ask me how I know. Still not sure why a coworker changed it without letting others know. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, May 24, 2019 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for both jobs please. BTW, as already mentioned, consider using CONTENT(ALL) instead of CONTENT(RECOMMENDED) in the future. I'm hard pressed to think of a good reason to only obtain recommended PTFs these days. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Kurt, Speaking of RSUs, is there a way to provide an inventory of PTFs already received so that I don't end up reordering and transmitting gigabytes of PTFs that have already been ordered, downloaded and received? As it is now, I am forced to run the RSU job on the weekend so that I stop getting the "17 of 20" failures after hours of wall clock time. And while I am thinking of enhancements, how about an optional check of a mask against a mask of the DDDEF volser that would flag a difference? Yeah, I know, the file allocation report is supposed to be the last line of defense, but sometimes it is tough to spot a one character difference. Ask me how I know. Still not sure why a coworker changed it without letting others know. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kurt Quackenbush Sent: Friday, May 24, 2019 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: > We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the > "New Service Levels" email), and got a number of fixes for RSU1903. Over the > last couple of days, it's been discovered that we are missing a few PTFs that > would be part of RSU1903 - or earlier. > > Yesterday, I therefore as an exercise did another RECEIVE ORDER > CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. > > Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU > date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for both jobs please. BTW, as already mentioned, consider using CONTENT(ALL) instead of CONTENT(RECOMMENDED) in the future. I'm hard pressed to think of a good reason to only obtain recommended PTFs these days. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? No, IBM does NOT assign RSU sourceids to PTFs retroactively after the published RSU date. At least its not supposed to work that way. Are you sure on your second RECEIVE ORDER one or more ASSIGN statements for RSU1903 were received? Or did you specify the RSU1903 SOURCEID on the RECEIVE command your self? If you did receive such ASSIGN statements, and if you still have it, I'd like to see the RECEIVE command output for both jobs please. BTW, as already mentioned, consider using CONTENT(ALL) instead of CONTENT(RECOMMENDED) in the future. I'm hard pressed to think of a good reason to only obtain recommended PTFs these days. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
On 5/23/2019 10:18 AM, Styles, Andy , ITS zPlatform Services wrote: Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Andy, This is unfortunately just how the system works. I went over this with IBM service, and PTF's get issued first, then the various SOURCEID's are applied to them via overnight batch processes. So a HIPER fix can be shipped, but the HIPER flag can take 24-48 hours (or longer) to be applied to the PTF. To say this sucks is an understatement, but that's just how IBM rolls. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
Classification: Public David, Okay, that makes some sense, and perhaps is a better way of doing the receive, which I'll perhaps adopt in the future; it still doesn't answer the question of whether IBM retrospectively assign RSUs to PTFs. Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: 23 May 2019 15:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- Once again, I'd recommend specifying RECEIVE ORDER CONTENT(ALL), and then apply SOURCEID(RSU). I run the receive order every week so that in the event there is a problem, I likely have a fix for it available, plus the HOLDDATA is refreshed including marking prior "good" ptf's in error if it has gone bad. I can't say this definitively, but does an order for "recommended" also resolve any pre-req PTF's that may not be marked RSU? I guess I don’t understand the thought process of only receiving some subset of PTF's _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Styles, Andy (ITS zPlatform Services) Sent: Thursday, May 23, 2019 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of
Re: RSUs
correct, SHOPZ allows me to specify RECOMMENDED (RSU) service for '''' products. the JCL for the download contains the order number not a RECEIVE ORDER CONTENT(RECOMMENDED) but generates for example SET BOUNDARY (GLOBAL) . RECEIVE FROMNETWORK( SERVER(SERVINFO) /* TRANSFERONLY <=== NOTE 5 */ CLIENT(CLNTINFO) ) . Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:38:07 AM Subject: Re: RSUs Classification: Public Aha, I think from that perspective, it's effectively RECEIVE ORDER CONTENT(RECOMMENDED); you cannot specify an RSU in Shopz either. Andy Styles z/Series System Programmer / zPlatform Enterprise Technology Services / Group CIO LLOYDS BANKING GROUP M: 07802 309040 | P: 7133 5971 / 020 7204 5971 | E: andy.sty...@lloydsbanking.com A: Lloyds Banking Group, 33 Old Broad Street, London -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:36 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I order via shopz Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:33:33 AM Subject: Re: RSUs Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (inc
Re: RSUs
Once again, I'd recommend specifying RECEIVE ORDER CONTENT(ALL), and then apply SOURCEID(RSU). I run the receive order every week so that in the event there is a problem, I likely have a fix for it available, plus the HOLDDATA is refreshed including marking prior "good" ptf's in error if it has gone bad. I can't say this definitively, but does an order for "recommended" also resolve any pre-req PTF's that may not be marked RSU? I guess I don’t understand the thought process of only receiving some subset of PTF's _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Styles, Andy (ITS zPlatform Services) Sent: Thursday, May 23, 2019 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. ---
Re: RSUs
Classification: Public Aha, I think from that perspective, it's effectively RECEIVE ORDER CONTENT(RECOMMENDED); you cannot specify an RSU in Shopz either. Andy Styles z/Series System Programmer / zPlatform Enterprise Technology Services / Group CIO LLOYDS BANKING GROUP M: 07802 309040 | P: 7133 5971 / 020 7204 5971 | E: andy.sty...@lloydsbanking.com A: Lloyds Banking Group, 33 Old Broad Street, London -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:36 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I order via shopz Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:33:33 AM Subject: Re: RSUs Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSUs
I order via shopz Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:33:33 AM Subject: Re: RSUs Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in En
Re: RSUs
Classification: Public We always (I hope..) get the latest HOLDDATA as well; How do you specify a specific RSU, I didn’t think that was an option for RECEIVE ORDER? Andy Styles z/Series System Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: 23 May 2019 15:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RSUs -- This email has reached the Bank via an external source -- I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- 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 Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapier
Re: RSUs
I don't recall ever doing a RECEIVE ORDER CONTENT(RECOMMENDED) , when I get an email for new service levels, I order the current RSU that's available, I have seen where some PTF's at that level were not applied, mostly because they was no applicable ++VARS, or held for some reason. I'd make sure you receive the current enhanced hold data also, this holddata may release some PTF's that are PRE's or CO-REQ for those PTFs to be applied. Carmen Vitullo - Original Message - From: "Andy Styles (ITS zPlatform Services)" <00d68f765d25-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 23, 2019 9:17:25 AM Subject: RSUs Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- 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
RSUs
Classification: Public Hi all, A question on some behaviour that I think we've noticed over the last few RSUs that have been announced. We did a RECEIVE ORDER CONTENT(RECOMMENDED) in early April (just after the "New Service Levels" email), and got a number of fixes for RSU1903. Over the last couple of days, it's been discovered that we are missing a few PTFs that would be part of RSU1903 - or earlier. Yesterday, I therefore as an exercise did another RECEIVE ORDER CONTENT(RECOMMENDED), and this time got more fixes for RSU1903. Do IBM assign RSU numbers retrospectively to PTFs, after the published RSU date? If so, that's REALLY difficult to manage! Anyone else have any experience of this? Thanks, Andy Styles Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
