Re: Best way for a task to give up the CPU and let other tasks run?
Typically, OS services like these and it's Unix equivalent sched_yield() are used in spinlocks. On 2019-10-18 1:20 AM, Mike Hochee wrote: Yes exactly, that is part of what WLM is designed to do. In the real world most shops use WLM service classes and velocity goals to control things like CPU dispatching frequency. I'm sure there exist workloads which tend to defy the controls available in WLM, but I suspect they are quite rare. In all but those rare instances, I'd be inclined to steer clear coding something in a program for the purpose of getting it re-dispatched for some resource. My nickels' worth. Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, October 17, 2019 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best way for a task to give up the CPU and let other tasks run? Caution! This message was sent from outside your organization. Why? If you are waiting for something then you should use system services, e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something then why not let the WLM handle what it's designed to handle? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Thomas David Rivers Sent: Thursday, October 17, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best way for a task to give up the CPU and let other tasks run? Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.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 -- 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: "Exploring z/OS Container Extensions" Meetups in Asia-Pacific
Unfortunately not Wayne, Budget freeze! If not would have preferred Singapore ;) Seriously though, I don't understand why IBM are not coming to Perth! Perth is home to three major vendors (Rocket, HCL and 21st Century), IBM and mainframe customers who are busy modernizing their applications and would be very interested in zCX. The CICS guys from Hursley are coming to Perth this month for a two day event covering lots of interesting topics (including zCX). Hopefully, they will be able to answer most of our questions. On 2019-10-18 11:35 AM, Wayne Bickerdike wrote: Not coming to Perth? See you in Melbourne Dave? On Wed, Oct 16, 2019 at 10:20 PM David Crayford wrote: Not coming to Perth? On 2019-10-16 5:51 PM, Timothy Sipples wrote: If you'd like to find out more about the new z/OS Container Extensions, there are some upcoming Meetups in late November and early December, 2019, across 9 cities in Asia, Australia, and New Zealand. Details and signup links are available here: https://www.meetup.com/IBM-Z-Technical-Community-in-Asia-Pacific/events/ I look forward to meeting at least a few IBM-MAINers in person. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: SWAREQ REXX fails with SWA=ABOVE, works with SWA=BELOW
Bad form to reply to myself, but I should have added this. This gave me a hint: https://www.ibm.com/support/pages/abend0c4-or-other-problems-retrieving-dataset-names-cobol This gave me the answer: https://www-01.ibm.com/support/docview.wss?uid=swg1PI58751 We're moving to z/OS 2.3 which was the source of the environment change. best regards, Peter On Thu, 17 Oct 2019 22:34:44 -0500, Peter Bishop wrote: >Hi, > >in case anyone else is having failures using the old SWAREQ REXX that is >floating around (originally from Gilbert Saint Flour), in our case as part of >a REXX that compares catalogues via the IGGCSI00 program and various other >methods, you will need to change your job class to SWA=BELOW to get it to work. > >After I did that, the mysterious errors relating to rubbish dataset names that >SWAREQ was returning vanished, and normal processing resumed. > >Hope this saves some time for others. > >best regards, >Peter > >-- >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: "Exploring z/OS Container Extensions" Meetups in Asia-Pacific
Not coming to Perth? See you in Melbourne Dave? On Wed, Oct 16, 2019 at 10:20 PM David Crayford wrote: > Not coming to Perth? > > On 2019-10-16 5:51 PM, Timothy Sipples wrote: > > If you'd like to find out more about the new z/OS Container Extensions, > > there are some upcoming Meetups in late November and early December, > 2019, > > across 9 cities in Asia, Australia, and New Zealand. Details and signup > > links are available here: > > > > https://www.meetup.com/IBM-Z-Technical-Community-in-Asia-Pacific/events/ > > > > I look forward to meeting at least a few IBM-MAINers in person. > > > > > > > Timothy Sipples > > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE > > > > > > > E-Mail: sipp...@sg.ibm.com > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SWAREQ REXX fails with SWA=ABOVE, works with SWA=BELOW
Hi, in case anyone else is having failures using the old SWAREQ REXX that is floating around (originally from Gilbert Saint Flour), in our case as part of a REXX that compares catalogues via the IGGCSI00 program and various other methods, you will need to change your job class to SWA=BELOW to get it to work. After I did that, the mysterious errors relating to rubbish dataset names that SWAREQ was returning vanished, and normal processing resumed. Hope this saves some time for others. best regards, Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
mmm.. mmm crow pie. *delicious*... *cough* Rob Schramm Senior Systems Consultant On Thu, Oct 17, 2019 at 4:12 PM Dana Mitchell wrote: > But didn't the OP want a VSAM LDS? > > From the same book: > > Allocating a VSAM Data Set.Any VSAM data set that is SMS-managed and > extended format can have the Extended Addressable attribute. The only > exception is for linear data sets which can have the Extended Addressable > attribute and be non SMS-managed. > > -- > 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: TPX with IBM fault analyser
5 months late but did you get this resolved ? When you say FA data set did you mean parmlib or history ? Unless TPX is getting an abend there should no FA activity. Cheers Hank -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Wednesday, 8 May 2019 04:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TPX with IBM fault analyser You probably want to add this statement to your TPX proc. //IDIOFF DD DUMMY * Disable Fault Analyzer for z/OS * -or- Look in sys1.parmlib(idicnf00) There is probably a INCLUDE(TYPE(STC) type statement. We only allow FA to get involved with batch jobs, so we exclude STC and TSU _ 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 Peter Sent: Tuesday, May 7, 2019 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TPX with IBM fault analyser **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hi Cross posted I am working on a tpx upgrade. When I start the address space for some reason it reads the fault analyser dataset. I have checked throughout the proc to see if by chance I have added that in DD but there isn't any. Not sure from where the TPX is pointing the Fault analyser parm. Does anyone have a similar set up and have any clue ? Peter -- 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 ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Power failure
Jerry, That's true (it's also true if you accidentally IPL a test system using the production paging subsystem) that corrupting/losing critical DASD will cause z/OS to fall over. However, I believe the OP mentioned that the SEs were restarted as well. I don't recall if the z14 has internal battery backup for the SE's or not, but if not, IBM made (in my opinion) a mistake moving from laptops with internal batteries to 1u "pizza boxes" for the SEs without BBU. It sure smells to me like there was some kind of power issue that impacted both of the power feeds coming in to the z14. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jerry Whitteridge Sent: Thursday, October 17, 2019 5:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Power failure I seem to remember that Peter mentioned that they may have had an outage on their Storage Subsystem - if you ripped away all the DASD from under z/OS I'll guarantee you'll be reIPL'ing 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 10/17/2019 03:01:57 PM: > From: Mike Schwab > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/17/2019 02:50 PM > Subject: [EXTERNAL] Re: Power failure > Sent by: IBM Mainframe Discussion List > > I agree. By mistake both power cords lead to the same UPS, or even > the same breaker. Pick a low impact time. Turn each breaker off for > 1 minute then turn back on. Look for anything that went down and > change outlets as needed. Then power off each UPS to check for > different breakers but same UPS. Or isn't there a device that will > send a signal over the line and you can determine which outlets are > wired to that breaker? Or is that only phone / network lines? > > On Thu, Oct 17, 2019 at 10:27 AM Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > > > On Thu, 17 Oct 2019 11:41:24 +0400, Peter wrote: > > > > >We have a dual... connectivity from UPS wired to z14. > > > > > >Even if one goes down and another would take a control > > > > That's what you said. > > > > Some of us are skeptical that it is actually implemented the way > > that you intended that it be implemented. > > > > -- > > Tom Marchant > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Power failure
I seem to remember that Peter mentioned that they may have had an outage on their Storage Subsystem - if you ripped away all the DASD from under z/OS I'll guarantee you'll be reIPL'ing 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 10/17/2019 03:01:57 PM: > From: Mike Schwab > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/17/2019 02:50 PM > Subject: [EXTERNAL] Re: Power failure > Sent by: IBM Mainframe Discussion List > > I agree. By mistake both power cords lead to the same UPS, or even > the same breaker. Pick a low impact time. Turn each breaker off for > 1 minute then turn back on. Look for anything that went down and > change outlets as needed. Then power off each UPS to check for > different breakers but same UPS. Or isn't there a device that will > send a signal over the line and you can determine which outlets are > wired to that breaker? Or is that only phone / network lines? > > On Thu, Oct 17, 2019 at 10:27 AM Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > > > On Thu, 17 Oct 2019 11:41:24 +0400, Peter wrote: > > > > >We have a dual... connectivity from UPS wired to z14. > > > > > >Even if one goes down and another would take a control > > > > That's what you said. > > > > Some of us are skeptical that it is actually implemented the way > > that you intended that it be implemented. > > > > -- > > Tom Marchant > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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: Power failure
I agree. By mistake both power cords lead to the same UPS, or even the same breaker. Pick a low impact time. Turn each breaker off for 1 minute then turn back on. Look for anything that went down and change outlets as needed. Then power off each UPS to check for different breakers but same UPS. Or isn't there a device that will send a signal over the line and you can determine which outlets are wired to that breaker? Or is that only phone / network lines? On Thu, Oct 17, 2019 at 10:27 AM Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 17 Oct 2019 11:41:24 +0400, Peter wrote: > > >We have a dual... connectivity from UPS wired to z14. > > > >Even if one goes down and another would take a control > > That's what you said. > > Some of us are skeptical that it is actually implemented the way > that you intended that it be implemented. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
But didn't the OP want a VSAM LDS? From the same book: Allocating a VSAM Data Set.Any VSAM data set that is SMS-managed and extended format can have the Extended Addressable attribute. The only exception is for linear data sets which can have the Extended Addressable attribute and be non SMS-managed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
STIMER WAIT for a small amount of time; I did this some years ago, when I wanted to show to some students how some parallel running subtasks wrote their messages not sequentially, but mixed; but, as it turned out, every subtask did its complete work in one step, once started, because it never returned the CPU. When I added some STIMER WAITs to the processing of the (identical) subtasks, the messages appeared in mixed order. HTH, kind regards Bernd Am 17.10.2019 um 14:54 schrieb Thomas David Rivers: Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". - Thanks - - Dave R. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DR Sysplex Procedure
At one point, I had a setup that included a SITE system symbol in the CDSs for XCF and CFRM to auto-resolve such things Rob Schramm Senior Systems Consultant On Thu, Oct 17, 2019 at 12:41 PM Elaine Beal wrote: > Yes, I would IPL with a different loadparm to point to COUPLExx with DR > XCF and CFRM > but WLM and LOGR would not change (use same ones as in current environment) > > In falling back, I would use the same current (not DR) XCF/CFRM/WLM/LOGR > > so I would use the same LOGR and WLM for DR and 'prod' > > no chance of messing up 'prod' > > -- > 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: How define a cluster bigger than 4GB?
I must clarify the use of DSNTYPE=LARGE... *sound of buzzer* thanks for playing. Notes from the from the book -- please note 1) Extended format MUST BE system managed 2) DSNTYPE=LARGE does not have to be system managed.. 3) DSNTYPE=LARGE can be supplied via DATACLAS. a google search for "DSNTYPE=LARGE" should take you to this link as well https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.idad400/d4425.htm Cut n paste from the book Allocating an Extended-Format Data Set. Extended format data sets must be system-managed. The mechanism for requesting extended format is through the SMS data class DSNTYPE=EXT parameter and subparameters R (required) or P (preferred). The storage administrator can specify R to ensure the data set is extended. Then, for VSAM data sets the storage administrator can set the extended addressability attribute to Y to request extended addressability. Extended format can also be requested using the DSNTYPE parameter on the JCL DD statement, with values of EXTREQ (required) or EXTPREF (preferred). The DSNTYPE specified on a JCL DD statement overrides any DSNTYPE set for the data class. In addition to a DSNTYPE of EXTENDED, COMPACTION=YES in a data class definition must be specified if you want to request allocation of an extended format data set in the compressed format. A compressed data set can be created using the LIKE keyword on the DD statement and not just through a data class. Allocating a Large Format Data Set. Large format data sets are sequential data sets that can grow beyond 65 535 tracks (4369 cylinders) up to 16,777,215 tracks per volume. Large format data sets can be system-managed or not. You can allocate a large format data set using the DSNTYPE=LARGE parameter on the DD statement, dynamic allocation (SVC 99), TSO/E ALLOCATE, or the access method services ALLOCATE command. The SMS data class can also provide the DSNTYPE value of LARGE, if the data set does not have another DSNTYPE specified or a DSORG value other than PS or PSU. Sitting back sipping coffee, Rob Schramm Senior Systems Consultant On Thu, Oct 17, 2019 at 1:04 PM Dana Mitchell wrote: > Doesn't need to be SMS managed, it just needs to be defined with a > DATACLASS that contains extended addressability = YES. > > Dana > > On Thu, 17 Oct 2019 09:24:28 -0400, Charles Mills > wrote: > > >Well phooey; did not want to cross that bridge. > > > >Thanks for the incredibly quick response. > > > >Charles > > > > > >-Original Message- > >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > >Behalf Of Edgington, Jerry > >Sent: Thursday, October 17, 2019 9:22 AM > >To: IBM-MAIN@LISTSERV.UA.EDU > >Subject: Re: How define a cluster bigger than 4GB? > > > >To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a > >DATACLAS with the extended attribute. > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption questions
We are investigating. There is a caveatand what you are talking about is dataset encryption. There are other facets to "pervasive encryption" including coupling facility encryption if PS, TCPIP encryption, etc. For dataset encryption, IBM is recommending activating ZEDC compression engines, and first compressing the data to be encrypted, there by encrypting less data, reducing the overall costs of it ~5%. Without compression the cost is quite a bit higher in CPU costs - so IBM tells us. _ 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 Cameron Conacher Sent: Thursday, October 17, 2019 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Pervasive Encryption questions **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Good afternoon everyone, We are actively pursuing Pervasive Encryption with our mainframe z14 machines. My question is related to performance. If anyone out there has been down this path, do they have real world metrics to share? It has been suggested that we could expect to see about five percent growth in CPU activity, and other folks have suggested that any CPU increase would be transparent. I will probably lean towards the five percent number, just to feel more confident. Has anyone seen an impact on SYNCSORT with ZPSAVER? I fully expect to do my own before/after comparisons, and if anyone can share any bumps in the road that they experienced, that would be great. Then I can focus on the potential difficulties/challenges. Thanks, ...Cameron -- 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
Pervasive Encryption questions
Good afternoon everyone, We are actively pursuing Pervasive Encryption with our mainframe z14 machines. My question is related to performance. If anyone out there has been down this path, do they have real world metrics to share? It has been suggested that we could expect to see about five percent growth in CPU activity, and other folks have suggested that any CPU increase would be transparent. I will probably lean towards the five percent number, just to feel more confident. Has anyone seen an impact on SYNCSORT with ZPSAVER? I fully expect to do my own before/after comparisons, and if anyone can share any bumps in the road that they experienced, that would be great. Then I can focus on the potential difficulties/challenges. Thanks, ...Cameron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
On 10/17/2019 10:31 AM, Thomas David Rivers wrote: Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED? What about just a regular un-AUTH'd program? CALLDISP does not require privileged execution unless you specify BRANCH=YES. Unauthorized callers should specify BRANCH=NO. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
On Thu, Oct 17, 2019 at 12:31 PM Thomas David Rivers wrote: > Don Poitras wrote: > > >CALLDISP > > > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm > > > > > > > > > Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED? > > What about just a regular un-AUTH'd program? > Doesn't look like it requires any special authorization Environment These are the requirements for the caller: - When BRANCH=NO Environmental factorRequirement Minimum authorization: None. Dispatchable unit mode: Task Cross memory mode: PASN=HASN=SASN AMODE: 24- or 31- or 64-bit ASC mode: Primary Interrupt status: Enabled for I/O and external interrupts Locks: No locks held Control parameters: None. > >- Dave R. - > > p.s. *Thanks* for the pointer... > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- I find television very educational. The minute somebody turns it on, I go into the library and read a good book -- Groucho Marx 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: Best way for a task to give up the CPU and let other tasks run?
When BRANCH=NO Environmental factorRequirement Minimum authorization: None. Dispatchable unit mode: Task Cross memory mode: PASN=HASN=SASN AMODE: 24- or 31- or 64-bit ASC mode: Primary Interrupt status: Enabled for I/O and external interrupts Locks: No locks held Control parameters: None. Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, October 17, 2019 1:31 PM, Thomas David Rivers wrote: > Don Poitras wrote: > > > CALLDISP > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm > > Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED? > > What about just a regular un-AUTH'd program? > > - Dave R. - > > p.s. Thanks for the pointer... > > -- > riv...@dignus.com Work: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
Don Poitras wrote: CALLDISP https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm Yeah - I stumbled over CALLDISP - but isn't that AUTHORIZED? What about just a regular un-AUTH'd program? - Dave R. - p.s. *Thanks* for the pointer... -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
Yes exactly, that is part of what WLM is designed to do. In the real world most shops use WLM service classes and velocity goals to control things like CPU dispatching frequency. I'm sure there exist workloads which tend to defy the controls available in WLM, but I suspect they are quite rare. In all but those rare instances, I'd be inclined to steer clear coding something in a program for the purpose of getting it re-dispatched for some resource. My nickels' worth. Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, October 17, 2019 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best way for a task to give up the CPU and let other tasks run? Caution! This message was sent from outside your organization. Why? If you are waiting for something then you should use system services, e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something then why not let the WLM handle what it's designed to handle? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Thomas David Rivers Sent: Thursday, October 17, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best way for a task to give up the CPU and let other tasks run? Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
Doesn't need to be SMS managed, it just needs to be defined with a DATACLASS that contains extended addressability = YES. Dana On Thu, 17 Oct 2019 09:24:28 -0400, Charles Mills wrote: >Well phooey; did not want to cross that bridge. > >Thanks for the incredibly quick response. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Edgington, Jerry >Sent: Thursday, October 17, 2019 9:22 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: How define a cluster bigger than 4GB? > >To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a >DATACLAS with the extended attribute. > >-- >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: Best way for a task to give up the CPU and let other tasks run?
Why? If you are waiting for something then you should use system services, e.g., ENQ, WAIT, to delay until it occurs; if you are not waiting for something then why not let the WLM handle what it's designed to handle? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Thomas David Rivers Sent: Thursday, October 17, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best way for a task to give up the CPU and let other tasks run? Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://secure-web.cisco.com/1aWH_FeYH8IlEwirJURk9sI7agw2X83FuMWKAE73bQgFjnWwW8-ePX_1xe1c0wvYZd8fcSnekzTSoxHccH5VLqo1rFCH9l3YX-k05mc9h6Ase64ekfUJQccKN7CoeKCb4mPWA65v0tvTLbXvBj_NDoce9MeFrZe7fZoePl7rSLNfSTkWiZtNoKrgNjJAaR56QKA_GzYAnQG1J3QqwTGR2aaONvJRqOZStLx-dDHLw-ANzfr-JqBhHVtxkPlrsOeTXQ5nr8kcqRcEdVKERvT0cBrDKRHbq59tsrJEPtz1qMjVK741J5WNN9JBdkVQ8CVHDOJsDhzqP_OSlWPU3JX2BtgFEtR-6t6ZDm5b1JEGSDbqulEaUL7WgUU6iBjImRoscWih5c4GWGVq3XTLgBcJli_t27401y41mmE7SVQ5PT5JfB_KovcV3dinUMhketMyr/http%3A%2F%2Fwww.dignus.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: DR Sysplex Procedure
Yes, I would IPL with a different loadparm to point to COUPLExx with DR XCF and CFRM but WLM and LOGR would not change (use same ones as in current environment) In falling back, I would use the same current (not DR) XCF/CFRM/WLM/LOGR so I would use the same LOGR and WLM for DR and 'prod' no chance of messing up 'prod' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote: >Does anyone happen to know the best way for a running task >to give up running and let another task run? > >But - this isn't "give up" as in ending the task, just giving up >the CPU to allow another task to run and then returning to this >task. > >Sorta like "I'm done for the moment if something else would like to run". Is the task one that purely uses CPU? Perhaps looping, looking at a queue for something to do, without ever waiting for anything? If so, perhaps it should issue STIMER WAIT when it detects that it has nothing to do. If, OTOH, it waits for an ECB to be posted, or an I/O to complete, or any of a number of other things, it is already relinquishing control. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
For an LDS?CharlesSent from a mobile; please excuse the brevity. Original message From: Rob Schramm Date: 10/17/19 11:07 AM (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How define a cluster bigger than 4GB? *dsntype=large**Allocating a Large Format Data Set.* Large format data sets are sequentialdata sets that can grow beyond 65 535 tracks (4369 cylinders) up to16,777,215 tracks per volume. Large format data sets can be system-managedor not. You can allocate a large format data set using the DSNTYPE=LARGEparameter on the DD statement, dynamic allocation (SVC 99), TSO/E ALLOCATE,or the access method services ALLOCATE command. The SMS data class can alsoprovide the DSNTYPE value of LARGE, if the data set does not have anotherDSNTYPE specified or a DSORG value other than PS or PSU.Rob SchrammSenior Systems ConsultantOn Thu, Oct 17, 2019 at 9:25 AM Charles Mills wrote:> Well phooey; did not want to cross that bridge.>> Thanks for the incredibly quick response.>> Charles>>> -Original Message-> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On> Behalf Of Edgington, Jerry> Sent: Thursday, October 17, 2019 9:22 AM> To: IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: How define a cluster bigger than 4GB?>> To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a> DATACLAS with the extended attribute.>> --> For IBM-MAIN subscribe / signoff / archive access instructions,> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN>--For IBM-MAIN subscribe / signoff / archive access instructions,send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Power failure
On Thu, 17 Oct 2019 11:41:24 +0400, Peter wrote: >We have a dual... connectivity from UPS wired to z14. > >Even if one goes down and another would take a control That's what you said. Some of us are skeptical that it is actually implemented the way that you intended that it be implemented. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
*dsntype=large* *Allocating a Large Format Data Set.* Large format data sets are sequential data sets that can grow beyond 65 535 tracks (4369 cylinders) up to 16,777,215 tracks per volume. Large format data sets can be system-managed or not. You can allocate a large format data set using the DSNTYPE=LARGE parameter on the DD statement, dynamic allocation (SVC 99), TSO/E ALLOCATE, or the access method services ALLOCATE command. The SMS data class can also provide the DSNTYPE value of LARGE, if the data set does not have another DSNTYPE specified or a DSORG value other than PS or PSU. Rob Schramm Senior Systems Consultant On Thu, Oct 17, 2019 at 9:25 AM Charles Mills wrote: > Well phooey; did not want to cross that bridge. > > Thanks for the incredibly quick response. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Edgington, Jerry > Sent: Thursday, October 17, 2019 9:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How define a cluster bigger than 4GB? > > To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a > DATACLAS with the extended attribute. > > -- > 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: Best way for a task to give up the CPU and let other tasks run?
That's awesome Don! So that's how to implement sched_yield()? On 2019-10-17 10:02 PM, Don Poitras wrote: CALLDISP https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote: #1, MVS manages that sort of thing with its wisdom, right? If it thought someone else should run, it would pre-empt you and give control to that other task. #2, any SVC (or PC?) type system service call will cause MVS to re-evaluate who should be dispatched *I think*. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas David Rivers Sent: Thursday, October 17, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best way for a task to give up the CPU and let other tasks run? Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
"I'm done for the moment if something else would like to run" That's not for the task to decide: the dispatcher, under control of WLM, decides whether you get the CPU or will be removed from it to allow another task to run. All based on WLM directions, which you can influence by selecting a Service Class with a certain Goal. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: 17 October, 2019 16:15 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Best way for a task to give up the CPU and let other tasks > run? > > On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote: > > >Does anyone happen to know the best way for a running task > >to give up running and let another task run? > > > >But - this isn't "give up" as in ending the task, just giving up > >the CPU to allow another task to run and then returning to this > >task. > > > >Sorta like "I'm done for the moment if something else would like to run". > > > What does "for the moment" mean? If your process has nothing > more to do, it should just quit. If it needs to wait for an event, > there are various programming interfaces for such things. > > See also setpriority(). > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote: >Does anyone happen to know the best way for a running task >to give up running and let another task run? > >But - this isn't "give up" as in ending the task, just giving up >the CPU to allow another task to run and then returning to this >task. > >Sorta like "I'm done for the moment if something else would like to run". > What does "for the moment" mean? If your process has nothing more to do, it should just quit. If it needs to wait for an event, there are various programming interfaces for such things. See also setpriority(). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
CALLDISP https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieaa100/clldis.htm In article <066301d584f2$b397cdc0$1ac76940$@mcn.org> you wrote: > #1, MVS manages that sort of thing with its wisdom, right? If it thought > someone else should run, it would pre-empt you and give control to that > other task. > #2, any SVC (or PC?) type system service call will cause MVS to re-evaluate > who should be dispatched *I think*. > Charles > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Thomas David Rivers > Sent: Thursday, October 17, 2019 8:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Best way for a task to give up the CPU and let other tasks run? > Does anyone happen to know the best way for a running task > to give up running and let another task run? > But - this isn't "give up" as in ending the task, just giving up > the CPU to allow another task to run and then returning to this > task. > Sorta like "I'm done for the moment if something else would like to run". -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
#1, MVS manages that sort of thing with its wisdom, right? If it thought someone else should run, it would pre-empt you and give control to that other task. #2, any SVC (or PC?) type system service call will cause MVS to re-evaluate who should be dispatched *I think*. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas David Rivers Sent: Thursday, October 17, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Best way for a task to give up the CPU and let other tasks run? Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
Well phooey; did not want to cross that bridge. Thanks for the incredibly quick response. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry Sent: Thursday, October 17, 2019 9:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How define a cluster bigger than 4GB? To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a DATACLAS with the extended attribute. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
The SMS dataclas attribute. EXTENDEDThis column shows whether or not extended addressability ADDRESSABILITY is provided. Extended addressability provides data sets -(27)- with addressability of more than 4 gigabytes. YES Possible values: YES Provides extended addressability. NO Does not provide extended addressability. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Thursday, October 17, 2019 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How define a cluster bigger than 4GB? IIRC the VSAM file needs to be SMS managed and / or a dataclass used the allow for extended attributes. Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, October 17, 2019 8:20:22 AM Subject: How define a cluster bigger than 4GB? I am trying to define an LDS of 5992 or so cylinders and I am getting IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 Which I interpret as saying a non-extended format cluster may not be more than 4GB. Is that what VSAM is telling me? If so, what do I need to do to define it as extended? I don't see any relevant parameter on IDCAMS DEFINE CLUSTER. z/OS V2R1, non SMS volume, FWIW. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How define a cluster bigger than 4GB?
IIRC the VSAM file needs to be SMS managed and / or a dataclass used the allow for extended attributes. Carmen Vitullo - Original Message - From: "Charles Mills" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, October 17, 2019 8:20:22 AM Subject: How define a cluster bigger than 4GB? I am trying to define an LDS of 5992 or so cylinders and I am getting IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 Which I interpret as saying a non-extended format cluster may not be more than 4GB. Is that what VSAM is telling me? If so, what do I need to do to define it as extended? I don't see any relevant parameter on IDCAMS DEFINE CLUSTER. z/OS V2R1, non SMS volume, FWIW. Thanks, Charles -- 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: How define a cluster bigger than 4GB?
To exceed the 4G limit, the VSAM file needs to be defined to SMS, with a DATACLAS with the extended attribute. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, October 17, 2019 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How define a cluster bigger than 4GB? I am trying to define an LDS of 5992 or so cylinders and I am getting IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 Which I interpret as saying a non-extended format cluster may not be more than 4GB. Is that what VSAM is telling me? If so, what do I need to do to define it as extended? I don't see any relevant parameter on IDCAMS DEFINE CLUSTER. z/OS V2R1, non SMS volume, FWIW. Thanks, Charles -- 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
How define a cluster bigger than 4GB?
I am trying to define an LDS of 5992 or so cylinders and I am getting IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON CODE IS IDC3009I IGG0CLEV-110 Which I interpret as saying a non-extended format cluster may not be more than 4GB. Is that what VSAM is telling me? If so, what do I need to do to define it as extended? I don't see any relevant parameter on IDCAMS DEFINE CLUSTER. z/OS V2R1, non SMS volume, FWIW. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
WLM: give the job a Serice Class with Importance=5 and a Velocity=1. It will be thankful for each CPU second that is left unused by all other tasks in the system. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Thomas David Rivers > Sent: 17 October, 2019 14:54 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Best way for a task to give up the CPU and let other tasks run? > > Does anyone happen to know the best way for a running task > to give up running and let another task run? > > But - this isn't "give up" as in ending the task, just giving up > the CPU to allow another task to run and then returning to this > task. > > Sorta like "I'm done for the moment if something else would like to run". > >- Thanks - > - Dave R. - > > -- > riv...@dignus.comWork: (919) 676-0847 > Get your mainframe programming tools at http://www.dignus.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: zOS 2.4 migration guide
I think we all understand, I was actually updating my software instance from a 2.2 instance to my current 2.3 instance. Documentation is still very lacking and in my PMR that I still have open since AUGUST I've stated that fact, this is very disappointing, IBM doc, especially an installation guide and user guide for all things MVS (ZOS) were easy to follow, now defining and configuring a REQUIRED product to send email notifications, defined TCP IP policy agents, and define/deploy z/OS software is deplorable. setting up the software 'INSTANCE' I define the software and where the z/osmf server is running, and my zos global zone, from there, it appears to read the zone(s) and build a configuration, ok, so what happens when I need service? do I have to use z/OSMF to order service, fixes? it's sure looking that way. Guess it's back to decrypting the z/OSMF user guide :( Carmen Vitullo - Original Message - From: "Kurt Quackenbush" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, October 17, 2019 7:51:56 AM Subject: Re: [EXT] Re: zOS 2.4 migration guide On 10/17/2019 3:20 AM, Sean Gleann wrote: > The idea that z/OSMF is intended to eventually replace SMP is quite > depressing, but - disclosure - I remember I had similar difficulty taking > SMP on board some aeons ago... using it is almost second nature now. What? IBM never said z/OSMF is intended to replace SMP/E. Yes, over time we plan to replace the existing ServerPac installation with a z/OSMF based install, but z/OS software will continue to be serviced using PTFs and therefore using SMP/E. 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
Best way for a task to give up the CPU and let other tasks run?
Does anyone happen to know the best way for a running task to give up running and let another task run? But - this isn't "give up" as in ending the task, just giving up the CPU to allow another task to run and then returning to this task. Sorta like "I'm done for the moment if something else would like to run". - Thanks - - Dave R. - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: zOS 2.4 migration guide
On 10/17/2019 3:20 AM, Sean Gleann wrote: The idea that z/OSMF is intended to eventually replace SMP is quite depressing, but - disclosure - I remember I had similar difficulty taking SMP on board some aeons ago... using it is almost second nature now. What? IBM never said z/OSMF is intended to replace SMP/E. Yes, over time we plan to replace the existing ServerPac installation with a z/OSMF based install, but z/OS software will continue to be serviced using PTFs and therefore using SMP/E. 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: STGADMIN.DPDSRN Confusion
Ah. Gotcha. I'll try that next time I need it. Thanks. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Thursday, October 17, 2019 2:01 AM, retired mainframer wrote: > When you list the dataset in 3.4, you have to specify the volume on the input > panel. Then it will present the override option. When you rename the data set > this way, the catalog will not be updated. The assumption being that no one > would rename a dataset actually in use. This feature is designed to let you > rename a different dataset with the same name since the ENQ does not track > the volume. > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Mark Jacobs > > Sent: Wednesday, October 16, 2019 11:35 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: STGADMIN.DPDSRN Confusion > > I was informed via a private communication that IDCAMS (or IEHPROGM) doesn't > > take advantage of this facility class resource, just ISPF/PDF. > > When I tried to rename it in 3.4, it's telling me that the data set is in > > use, and it's not > > giving me the option to bypass the enq and rename the data set. I'd like to > > understand > > why. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, October 16, 2019 2:25 PM, Mike Schwab > > mike.a.sch...@gmail.com wrote: > > > > > I think it is cataloged to that volume. Uncatalog no scratch that dataset. > > > On Wed, Oct 16, 2019 at 9:16 AM Mark Jacobs > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > > > > > I'm attempting to rename an inuse non-vsam dataset, even with read > > > > access to the > > > > STGADMIN.DPDSRN.SYS1.* profile, it's failing with these error messages. > > > > > > > IGD17060I DELETE/RENAME FAILED BECAUSE DATA SET IS OPEN > > > > ON VOLUME Z22C02 > > > > DATA SET IS SYS1.PROD.PARMLIB.NEW > > > > IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS > > > > (040B0446), > > > > > > > STEP2,Z22C02,SYS1.PROD.PARMLIB.NEW > > > > DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE > > > > THIS TEST > > > > > > > IGD17056I RENAME FAILED, DUPLICATE DATA SET NAME ON VOLUME > > > > Z22C02 > > > > > > > DATA SET IS SYS1.PROD.PARMLIB.NEW.ORIG > > > > X'04' X'0B' ENQRET X'46' > > > > Validate DADSM RENAME request; enqueue on SYSDSN failed. Also, the > > > > caller > > > > has appropriate RACF READ authority to be able to specify that the data > > > > set being > > > > renamed is not the data set in use. > > > > > > > See Renaming a Data Set That Might be in Use in z/OS DFSMSdfp Advanced > > > > Services.Sent from ProtonMail, Swiss-based encrypted email. > > > > > > > What am I missing here? > > > > Mark Jacobs > > > > GPG Public Key - > > > > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > > > Mike A Schwab, Springfield IL USA > > > Where do Forest Rangers go to get away from it all? > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: zOS 2.4 migration guide
On 17/10/2019 6:20 pm, Sean Gleann wrote:
On our z14, z/OSMF takes some 60m+ EXCPs and 300 seconds of CPU time
(according to SDSF) before it can even be used...
I have been investigating this exact issue. Looking at SMF 92 records,
it appears that z/OSMF opens, reads and closes the same files thousands
of times.
On my Dallas RDP system z/OSMF also takes about 60m EXCPs to start up.
Startup is still fast - I suspect through caching magic of read only
filesystems or VM read only disks it achieves somewhere between 500K-1M
EXCPs per second and takes 1-2 minutes to start. (I also wonder whether
EXCPs are counted differently against filesystems.)
I wrote a Java program using EasySMF to count the type 92 file close
records by file name. The program:
import java.io.IOException;
import java.time.LocalDateTime;
import java.util.stream.Collectors;
import com.blackhillsoftware.smf.SmfRecordReader;
import com.blackhillsoftware.smf.smf92.*;
public class UssFileCloseCount
{
public static void main(String[] args) throws IOException
{
LocalDateTime start = LocalDateTime.of(2019, 10, 9, 14, 9);
LocalDateTime end = LocalDateTime.of(2019, 10, 9, 14, 11);
try (SmfRecordReader reader = SmfRecordReader.fromDD("INPUT"))
{
reader.include(92,11)
.stream()
.map(record -> Smf92Record.from(record))
.filter(r92 -> r92.smfDateTime().isAfter(start)
&& r92.smfDateTime().isBefore(end))
.filter(r92 ->
r92.identificationSection().smf92jbn().equals("IZUSVR1"))
.flatMap(r92 -> r92.FileCloses().stream())
.collect(Collectors.groupingBy(close -> close.smf92cpn(),
Collectors.counting()))
.entrySet().stream()
.filter(entry -> entry.getValue() > 10)// count > 10
.sorted((a, b) -> b.getValue().compareTo(a.getValue()))
.forEachOrdered(entry ->
System.out.format("%7d %s%n",
entry.getValue(), entry.getKey()));
}
}
}
The result:
1771 ation/helps/eclipse/plugins/com.ibm.cpomessages.help.doc/doc.zip
1719 helps/eclipse/plugins/com.ibm.cpomessages.help.doc/nl/ja/doc.zip
1662 n/helps/eclipse/plugins/com.ibm.tcp.ipsec.ipsec.help.doc/doc.zip
1597 s/eclipse/plugins/com.ibm.tcp.ipsec.ipsec.help.doc/nl/ja/doc.zip
1157 elps/eclipse/plugins/com.ibm.zosmfcore.messages.help.doc/doc.zip
1143 clipse/plugins/com.ibm.zosmfcore.messages.help.doc/nl/ja/doc.zip
1118 ta/cacheAdapt/com.ibm.ws.classloading.sharedlibrary_403/.overlay
903 clipse/plugins/com.ibm.zosmfdeployment.messages.help.doc/doc.zip
877 /plugins/com.ibm.zosmfdeployment.messages.help.doc/nl/ja/doc.zip
771 ipse/plugins/com.ibm.zosmfworkloadmgmt.messages.help.doc/doc.zip
681 eclipse/plugins/com.ibm.zosmfworkflows.messages.help.doc/doc.zip
676 gi/136/data/cacheAdapt/com.ibm.ws.classloading.sharedlibrary_403
652 lugins/com.ibm.zosmfworkloadmgmt.messages.help.doc/nl/ja/doc.zip
628 e/plugins/com.ibm.zosmfworkflows.messages.help.doc/nl/ja/doc.zip
551 n/helps/eclipse/plugins/com.ibm.commserver.zert.help.doc/doc.zip
478 n/helps/eclipse/plugins/com.ibm.zosmfdeployment.help.doc/doc.zip
442 sgi/60/data/cacheAdapt/com.ibm.ws.classloading.sharedlibrary_403
418 /var/zosmf/configuration/helps/eclipse/plugins/doc.zip
348 ipse/plugins/com.ibm.zosmfcapacityprov.messages.help.doc/doc.zip
342 lugins/com.ibm.zosmfcapacityprov.messages.help.doc/nl/ja/doc.zip
191 plugins/com.ibm.zosmfcpm.softwareconfigmessages.help.doc/doc.zip
191 lipse/plugins/com.ibm.zosmfincidentlog.messages.help.doc/doc.zip
188 plugins/com.ibm.zosmfincidentlog.messages.help.doc/nl/ja/doc.zip
188 /eclipse/plugins/com.ibm.zosmfcore.multisysplex.help.doc/doc.zip
185 /plugins/com.ibm.zosmfworkflows.editor.messages.help.doc/doc.zip
181 helps/eclipse/plugins/com.ibm.zosmfworkloadmgmt.help.doc/doc.zip
180 osmfServer/workarea/org.eclipse.osgi/26/data/bundle.origin.cache
178 helps/eclipse/plugins/com.ibm.zosmfcapacityprov.help.doc/doc.zip
175 eclipse/plugins/com.ibm.zosmfcapacityprov.help.doc/nl/ja/doc.zip
173 se/plugins/com.ibm.zosmfcore.multisysplex.help.doc/nl/ja/doc.zip
168 eclipse/plugins/com.ibm.zosmfworkloadmgmt.help.doc/nl/ja/doc.zip
166 lugins/com.ibm.zosmfcore.softwareconfigmessages.help.doc/doc.zip
166 eclipse/plugins/com.ibm.zosmfcpm.softwareconfig.help.doc/doc.zip
165 s/eclipse/plugins/com.ibm.zosmfcpm.resourceprov.help.doc/doc.zip
157 ation/helps/eclipse/plugins/com.ibm.gpmmessages.help.doc/doc.zip
154 /helps/eclipse/plugins/com.ibm.zosmfincidentlog.help.doc/doc.zip
154 helps/eclipse/plugins/com.ibm.gpmmessages.help.doc/nl/ja/doc.zip
151 /eclipse/plugins/com.ibm.zosmfincidentlog.help.doc/nl/ja/doc.zip
149
Re: [EXT] Re: zOS 2.4 migration guide
On 2019-10-17 3:26 PM, Martin Packer wrote: I’m not really claiming to troubleshoot this but I wonder - based on your EXCP count comment - what JVM heap specification people (you) are running with. I wonder if it’s garbage collecting to death. I'm no expert of z/OS Java garbage collection but I'm wondering how it can cause high EXCPs? I suspect it's opening all the zFS files required for WLP. (I’d also observe Liberty Profile has a generally good reputation for being lightweight and swift to start. As always, and z/OSMF Development forgive me for this comment :-) , it depends on what you run in the JVM.) That's my experience. But we have a zIIP. Cheers, Martin Sent from my iPad On 17 Oct 2019, at 08:22, Sean Gleann wrote: On our z14, z/OSMF takes some 60m+ EXCPs and 300 seconds of CPU time (according to SDSF) before it can even be used... (and anything that announces its availability with "...ready to run a smarter planet" just makes me cringe.) Carmen's remark about 'clear documentation' is very much on point. Like him, I've been battling with the Configuration Assistant in order to create a comms policy. Every time I find any documentation that might help me, the examples given show a z/OSMF UI that is different to mine and so the confusion starts right at the point of logging on. I suppose its because z/OSMF is still a very young bit of software and so changes between versions are much more visible. The idea that z/OSMF is intended to eventually replace SMP is quite depressing, but - disclosure - I remember I had similar difficulty taking SMP on board some aeons ago... using it is almost second nature now. Sean On Wed, 16 Oct 2019 at 17:57, Gibney, Dave wrote: No zIIP here either. I guess, it doesn't matter. I expect 1 more migration, 2.1 to 2.2. Then mothballing -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Charles Sent: Wednesday, October 16, 2019 7:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Re: zOS 2.4 migration guide I thought my situation was bad - it only takes 30 minutes at 100% CPU on my test system to bring up z/OSMF. Does anyone run this on a production system? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: Power failure
We have a dual... connectivity from UPS wired to z14. Even if one goes down and another would take a control On Thu, 17 Oct, 2019, 11:39 AM Mike Schwab, wrote: > Maybe the NYC/WE is single power source and it lost power momentarily and > ordered a reboot when it restarted? > > > On Thursday, October 17, 2019, Peter wrote: > > Yes... How can a SE reboot a machine on its own > > > > On Thu, 17 Oct, 2019, 11:02 AM Vernooij, Kees (ITOP NM) - KLM, < > > kees.verno...@klm.com> wrote: > > > >> Still makes you wonder what *good* reason it had to reboot on its own. > >> > >> Kees. > >> > >> > >> > -Original Message- > >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> > Behalf Of Peter > >> > Sent: 17 October, 2019 8:33 > >> > To: IBM-MAIN@LISTSERV.UA.EDU > >> > Subject: Re: Power failure > >> > > >> > Ibm responded > >> > > >> > Says this system reboot could be due to at SE level. > >> > > >> > Half of the log collected got corrupted > >> > > >> > Error data not in cache . > >> > > >> > Still wondering if SE can really reboot the machine on its own. > >> > > >> > > >> > > >> > On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, < > >> > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > >> > > >> > > +1 for what Tom says. I didn’t reply to the earlier email from > Peter > >> > this > >> > > morning, but did you drill down into the "restarted forcibly" > message > >> > that > >> > > you presumably saw on the HMC? I'd also go look for hardware > messages > >> > at > >> > > the CEC level, there should be events there, that you can also drill > >> > down > >> > > into. While you may not see the shutdown (hopefully there is > >> > something), > >> > > you would see more of the startup information. > >> > > > >> > > > >> > > > >> > > >> > __ > >> > ___ > >> > > 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 Tom Marchant > >> > > Sent: Wednesday, October 16, 2019 10:07 AM > >> > > To: IBM-MAIN@LISTSERV.UA.EDU > >> > > Subject: Re: Power failure > >> > > > >> > > **CAUTION EXTERNAL EMAIL** > >> > > > >> > > **DO NOT open attachments or click on links from unknown senders or > >> > > unexpected emails** > >> > > > >> > > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote: > >> > > > >> > > >I looked into audit and log messages during those time frames. > >> > > > > >> > > >I just see a message as system was restarted forcibly. It doesn't > say > >> > > >what caused it. > >> > > > >> > > If power was lost abruptly, there may have been no opportunity to > log > >> > > anything. > >> > > > >> > > >Does IBM receives more detailed message ? > >> > > > >> > > Have you asked IBM? > >> > > > >> > > -- > >> > > Tom Marchant > >> > > > >> > > > -- > >> > > 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 > >> > >> For information, services and offers, please visit our web site: > >> http://www.klm.com. This e-mail and any attachment may contain > >> confidential and privileged material intended for the addressee only.
Re: Power failure
Maybe the NYC/WE is single power source and it lost power momentarily and ordered a reboot when it restarted? On Thursday, October 17, 2019, Peter wrote: > Yes... How can a SE reboot a machine on its own > > On Thu, 17 Oct, 2019, 11:02 AM Vernooij, Kees (ITOP NM) - KLM, < > kees.verno...@klm.com> wrote: > >> Still makes you wonder what *good* reason it had to reboot on its own. >> >> Kees. >> >> >> > -Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> > Behalf Of Peter >> > Sent: 17 October, 2019 8:33 >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: Power failure >> > >> > Ibm responded >> > >> > Says this system reboot could be due to at SE level. >> > >> > Half of the log collected got corrupted >> > >> > Error data not in cache . >> > >> > Still wondering if SE can really reboot the machine on its own. >> > >> > >> > >> > On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, < >> > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: >> > >> > > +1 for what Tom says. I didn’t reply to the earlier email from Peter >> > this >> > > morning, but did you drill down into the "restarted forcibly" message >> > that >> > > you presumably saw on the HMC? I'd also go look for hardware messages >> > at >> > > the CEC level, there should be events there, that you can also drill >> > down >> > > into. While you may not see the shutdown (hopefully there is >> > something), >> > > you would see more of the startup information. >> > > >> > > >> > > >> > >> __ >> > ___ >> > > 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 Tom Marchant >> > > Sent: Wednesday, October 16, 2019 10:07 AM >> > > To: IBM-MAIN@LISTSERV.UA.EDU >> > > Subject: Re: Power failure >> > > >> > > **CAUTION EXTERNAL EMAIL** >> > > >> > > **DO NOT open attachments or click on links from unknown senders or >> > > unexpected emails** >> > > >> > > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote: >> > > >> > > >I looked into audit and log messages during those time frames. >> > > > >> > > >I just see a message as system was restarted forcibly. It doesn't say >> > > >what caused it. >> > > >> > > If power was lost abruptly, there may have been no opportunity to log >> > > anything. >> > > >> > > >Does IBM receives more detailed message ? >> > > >> > > Have you asked IBM? >> > > >> > > -- >> > > Tom Marchant >> > > >> > > -- >> > > 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 >> >> For information, services and offers, please visit our web site: >> http://www.klm.com. This e-mail and any attachment may contain >> confidential and privileged material intended for the addressee only. If >> you are not the addressee, you are notified that no part of the e-mail or >> any attachment may be disclosed, copied or distributed, and that any other >> action related to this e-mail or attachment is strictly prohibited, and may >> be unlawful. If you have received this e-mail by error, please notify the >> sender immediately by return e-mail, and delete this message. >> >> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
Re: [EXT] Re: zOS 2.4 migration guide
I’m not really claiming to troubleshoot this but I wonder - based on your EXCP count comment - what JVM heap specification people (you) are running with. I wonder if it’s garbage collecting to death. (I’d also observe Liberty Profile has a generally good reputation for being lightweight and swift to start. As always, and z/OSMF Development forgive me for this comment :-) , it depends on what you run in the JVM.) Cheers, Martin Sent from my iPad > On 17 Oct 2019, at 08:22, Sean Gleann wrote: > > On our z14, z/OSMF takes some 60m+ EXCPs and 300 seconds of CPU time > (according to SDSF) before it can even be used... > (and anything that announces its availability with "...ready to run a > smarter planet" just makes me cringe.) > > Carmen's remark about 'clear documentation' is very much on point. Like > him, I've been battling with the Configuration Assistant in order to create > a comms policy. > Every time I find any documentation that might help me, the examples given > show a z/OSMF UI that is different to mine and so the confusion starts > right at the point of logging on. > I suppose its because z/OSMF is still a very young bit of software and so > changes between versions are much more visible. > > The idea that z/OSMF is intended to eventually replace SMP is quite > depressing, but - disclosure - I remember I had similar difficulty taking > SMP on board some aeons ago... using it is almost second nature now. > > Sean > >> On Wed, 16 Oct 2019 at 17:57, Gibney, Dave wrote: >> >> No zIIP here either. I guess, it doesn't matter. I expect 1 more >> migration, 2.1 to 2.2. Then mothballing >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Mark Charles >>> Sent: Wednesday, October 16, 2019 7:44 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: [EXT] Re: zOS 2.4 migration guide >>> >>> I thought my situation was bad - it only takes 30 minutes at 100% CPU on >> my >>> test system to bring up z/OSMF. >>> >>> Does anyone run this on a production system? >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to >>> lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: zOS 2.4 migration guide
On our z14, z/OSMF takes some 60m+ EXCPs and 300 seconds of CPU time (according to SDSF) before it can even be used... (and anything that announces its availability with "...ready to run a smarter planet" just makes me cringe.) Carmen's remark about 'clear documentation' is very much on point. Like him, I've been battling with the Configuration Assistant in order to create a comms policy. Every time I find any documentation that might help me, the examples given show a z/OSMF UI that is different to mine and so the confusion starts right at the point of logging on. I suppose its because z/OSMF is still a very young bit of software and so changes between versions are much more visible. The idea that z/OSMF is intended to eventually replace SMP is quite depressing, but - disclosure - I remember I had similar difficulty taking SMP on board some aeons ago... using it is almost second nature now. Sean On Wed, 16 Oct 2019 at 17:57, Gibney, Dave wrote: > No zIIP here either. I guess, it doesn't matter. I expect 1 more > migration, 2.1 to 2.2. Then mothballing > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Mark Charles > > Sent: Wednesday, October 16, 2019 7:44 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: [EXT] Re: zOS 2.4 migration guide > > > > I thought my situation was bad - it only takes 30 minutes at 100% CPU on > my > > test system to bring up z/OSMF. > > > > Does anyone run this on a production system? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Power failure
Yes... How can a SE reboot a machine on its own On Thu, 17 Oct, 2019, 11:02 AM Vernooij, Kees (ITOP NM) - KLM, < kees.verno...@klm.com> wrote: > Still makes you wonder what *good* reason it had to reboot on its own. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Peter > > Sent: 17 October, 2019 8:33 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Power failure > > > > Ibm responded > > > > Says this system reboot could be due to at SE level. > > > > Half of the log collected got corrupted > > > > Error data not in cache . > > > > Still wondering if SE can really reboot the machine on its own. > > > > > > > > On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > +1 for what Tom says. I didn’t reply to the earlier email from Peter > > this > > > morning, but did you drill down into the "restarted forcibly" message > > that > > > you presumably saw on the HMC? I'd also go look for hardware messages > > at > > > the CEC level, there should be events there, that you can also drill > > down > > > into. While you may not see the shutdown (hopefully there is > > something), > > > you would see more of the startup information. > > > > > > > > > > > > __ > > ___ > > > 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 Tom Marchant > > > Sent: Wednesday, October 16, 2019 10:07 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Power failure > > > > > > **CAUTION EXTERNAL EMAIL** > > > > > > **DO NOT open attachments or click on links from unknown senders or > > > unexpected emails** > > > > > > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote: > > > > > > >I looked into audit and log messages during those time frames. > > > > > > > >I just see a message as system was restarted forcibly. It doesn't say > > > >what caused it. > > > > > > If power was lost abruptly, there may have been no opportunity to log > > > anything. > > > > > > >Does IBM receives more detailed message ? > > > > > > Have you asked IBM? > > > > > > -- > > > Tom Marchant > > > > > > -- > > > 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 > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and may > be unlawful. If you have received this e-mail by error, please notify the > sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands,
Re: Power failure
Still makes you wonder what *good* reason it had to reboot on its own. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter > Sent: 17 October, 2019 8:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Power failure > > Ibm responded > > Says this system reboot could be due to at SE level. > > Half of the log collected got corrupted > > Error data not in cache . > > Still wondering if SE can really reboot the machine on its own. > > > > On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, < > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > +1 for what Tom says. I didn’t reply to the earlier email from Peter > this > > morning, but did you drill down into the "restarted forcibly" message > that > > you presumably saw on the HMC? I'd also go look for hardware messages > at > > the CEC level, there should be events there, that you can also drill > down > > into. While you may not see the shutdown (hopefully there is > something), > > you would see more of the startup information. > > > > > > > __ > ___ > > 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 Tom Marchant > > Sent: Wednesday, October 16, 2019 10:07 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Power failure > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote: > > > > >I looked into audit and log messages during those time frames. > > > > > >I just see a message as system was restarted forcibly. It doesn't say > > >what caused it. > > > > If power was lost abruptly, there may have been no opportunity to log > > anything. > > > > >Does IBM receives more detailed message ? > > > > Have you asked IBM? > > > > -- > > Tom Marchant > > > > -- > > 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 For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Power failure
Ibm responded Says this system reboot could be due to at SE level. Half of the log collected got corrupted Error data not in cache . Still wondering if SE can really reboot the machine on its own. On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > +1 for what Tom says. I didn’t reply to the earlier email from Peter this > morning, but did you drill down into the "restarted forcibly" message that > you presumably saw on the HMC? I'd also go look for hardware messages at > the CEC level, there should be events there, that you can also drill down > into. While you may not see the shutdown (hopefully there is something), > you would see more of the startup information. > > > _ > 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 Tom Marchant > Sent: Wednesday, October 16, 2019 10:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Power failure > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote: > > >I looked into audit and log messages during those time frames. > > > >I just see a message as system was restarted forcibly. It doesn't say > >what caused it. > > If power was lost abruptly, there may have been no opportunity to log > anything. > > >Does IBM receives more detailed message ? > > Have you asked IBM? > > -- > Tom Marchant > > -- > 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: STGADMIN.DPDSRN Confusion
When you list the dataset in 3.4, you have to specify the volume on the input panel. Then it will present the override option. When you rename the data set this way, the catalog will not be updated. The assumption being that no one would rename a dataset actually in use. This feature is designed to let you rename a different dataset with the same name since the ENQ does not track the volume. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mark Jacobs > Sent: Wednesday, October 16, 2019 11:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: STGADMIN.DPDSRN Confusion > > I was informed via a private communication that IDCAMS (or IEHPROGM) doesn't > take advantage of this facility class resource, just ISPF/PDF. > > When I tried to rename it in 3.4, it's telling me that the data set is in > use, and it's not > giving me the option to bypass the enq and rename the data set. I'd like to > understand > why. > > Mark Jacobs > > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, October 16, 2019 2:25 PM, Mike Schwab > wrote: > > > I think it is cataloged to that volume. Uncatalog no scratch that dataset. > > > > On Wed, Oct 16, 2019 at 9:16 AM Mark Jacobs > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > > > I'm attempting to rename an inuse non-vsam dataset, even with read access > > > to the > STGADMIN.DPDSRN.SYS1.* profile, it's failing with these error messages. > > > IGD17060I DELETE/RENAME FAILED BECAUSE DATA SET IS OPEN > > > ON VOLUME Z22C02 > > > DATA SET IS SYS1.PROD.PARMLIB.NEW > > > IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS > (040B0446), > > > STEP2,Z22C02,SYS1.PROD.PARMLIB.NEW > > > DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE > THIS TEST > > > IGD17056I RENAME FAILED, DUPLICATE DATA SET NAME ON VOLUME > Z22C02 > > > DATA SET IS SYS1.PROD.PARMLIB.NEW.ORIG > > > X'04' X'0B' ENQRET X'46' > > > Validate DADSM RENAME request; enqueue on SYSDSN failed. Also, the caller > has appropriate RACF READ authority to be able to specify that the data set > being > renamed is not the data set in use. > > > See Renaming a Data Set That Might be in Use in z/OS DFSMSdfp Advanced > Services.Sent from ProtonMail, Swiss-based encrypted email. > > > What am I missing here? > > > Mark Jacobs > > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
