Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Well, as well as you want to run with data replication on in your normal production site, you want to run with replication on in your DR situation when production transaction are modifying data. Just reverse the replication when starting up the DR site. And reverse replication again after returning to the normal site. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 14 February, 2019 0:41 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up in > smoke, bank website, app down . The Register > > Willy-nilly is about notification and opportunity for preparation. For > example, management declares a surprise DR drill on a Saturday morning. > So the techs execute their well-rehearsed swap-over plan and begin > running production at the DR site. Real live transactions with actual > customer data. The old production site is now obsolete. > > Then Sunday at noon management decides to roll back before the new week > starts off. There is no time to plan. No time to test. The entire > environment has to copied back to prod overlaying the old data. And it > has to work from the get-go. > > Can anyone step up to that challenge? If not there could be some serious > willy damage. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Jaffe > Sent: Tuesday, February 12, 2019 4:04 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Wells Fargo? Well f*&%#d at the moment: Data > center up in smoke, bank website, app down . The Register > > On 2/11/2019 7:06 PM, Jesse 1 Robinson wrote: > > All of this bodes ill for willy-nilly switching back and forth between > data centers unless there's some secret trick(s) I don't know about. > > > I don't know the tricks either. Guess I need to attend more DCM Project- > sponsored sessions at SHARE... ;-) > > I can attest that we have a number of customers that swap workloads > between two sites a couple/few times a year. (Does that count as > willy/nilly?) > > We have one or two with a third site in the mix! Yikes!!! > > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.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: VTL - ISMF Question
Thanks Kevin,
I had to add NULLIFY(ERRORSTATUS) to the command to make it work.
Gadi
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Neubert, Kevin
Sent: Wednesday, February 13, 2019 6:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTL - ISMF Question
Build list of volsers with the ERROR-STATUS in question.
LISTCAT CATALOG('your.VOLCAT.catalog') ALL
Alter volsers accordingly.
ALTER Vvolser VOLENTRY USEATTRIBUTE(SCRATCH) OWNERINFORMATION(' ')
Regards,
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Gadi Ben-Avi
Sent: Wednesday, February 13, 2019 6:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VTL - ISMF Question
Hi,
When I look at the list of scratch volumes in ISMF, I see lots of volumes with
the status 'REJ BY TAP MGT SYS'
I know that if I alter them and select Scratch, they will be returned to the
scratch pool.
Is there a way to do this in Batch or for all of the volumes in one operation.
I have more than 500 of these volumes.
Thanks
Gadi
--
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: VTL - ISMF Question
We're using Control-m?Tape. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Fraser Sent: Wednesday, February 13, 2019 5:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTL - ISMF Question If you have CA1 then there is a utility program CTSSYNC that will do the job for you in batch. Brian On Wed, 13 Feb 2019 at 22:17, Gadi Ben-Avi wrote: > Hi, > > When I look at the list of scratch volumes in ISMF, I see lots of > volumes with the status 'REJ BY TAP MGT SYS' > I know that if I alter them and select Scratch, they will be returned > to the scratch pool. > > Is there a way to do this in Batch or for all of the volumes in one > operation. > I have more than 500 of these volumes. > > Thanks > > Gadi > > > -- > 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: VTL - ISMF Question
It's not about HSM. Just making the tapes available as scratch tapes. -Original Message- From: IBM Mainframe Discussion List On Behalf Of retired mainframer Sent: Wednesday, February 13, 2019 5:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTL - ISMF Question When you say scratch pool do you mean remove from HSM entirely or do you mean mark as available to HSM? Whichever you decide, you can set the ISMF report to a dataset and write a REXX to parse it and generate DELVOL commands. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: Wednesday, February 13, 2019 6:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VTL - ISMF Question > > Hi, > > When I look at the list of scratch volumes in ISMF, I see lots of > volumes with the > status 'REJ BY TAP MGT SYS' > I know that if I alter them and select Scratch, they will be returned > to the scratch pool. > > Is there a way to do this in Batch or for all of the volumes in one operation. > I have more than 500 of these volumes. -- 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
PPRC power failure
Hi One of our DS box in DR had a power failure last night and our production LPARS logon got impacted . When I checked up the RMF i saw many DASD devices were overloaded and flood of PPRC error messages too in SYSLOG. Once we fixed the power failure and re-established the replication the logins and all the application started running. Is there any relationship to system performance with the PPRC failure ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Abend 106 (was Generic query on Region allocation failure)
SCLM is ancient and only slightly revered. No revenue attached to fixing it up. Superc - well I happen to know it's a weird beast and untangling the 24-bit issues is likely too much trouble for the developers. See my SCLM answer Cheers Hank -Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris Sent: Thursday, 17 January 2019 4:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Abend 106 (was Generic query on Region allocation failure) [Default] On 16 Jan 2019 02:57:29 -0800, in bit.listserv.ibm-main 01a0403c5dc1-dmarc-requ...@listserv.ua.edu (Jousma, David) wrote: >Wayne, you need to free up region below the line. We run with an 11M PVT below >the line.Here is our memory map from tasid. > >0 | PSA .. 8K | 1FFF > 2000 | System .. 16K | 5FFF > 6000 | PVT .. 11240K | AF > B0 | CSA ... 2276K | D38FFF > D39000 | PLPA .. 1380K | E91FFF > E92000 | SQA ... 1284K | FD2FFF > FD3000 | R/W Nucleus . 43K | FDD877 > FDE000 | R/O Nucleus .. 13483K | 1D08B2F > 1D09000 | Ext R/W Nuc 320K | 1D58FFF > 1D59000 | Ext SQA .. 90304K | 7588FFF > 7589000 | Ext PLPA . 65844K | B5D5FFF > B5D6000 | Ext CSA . 389288K | 231F > 2320 | Ext PVT 1521664K | 7FFF > >One way we make a bunch of room below the line is to move little used ISPF >modules out of LPA in LINKLIST. > Why the &*^^%* in 2019 should anyone have to move these modules out of LPA? Other than inertia, is there any need for these to be 24 bit? What else is in 24 bit LPA that should have been upgraded to 31 bit long ago? Clark Morris > >++VER(Z038) FMID(HIF7R02). >++MOVE (FLM$CPI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMCPCS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMDDL ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMIO24 ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPCBL) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPFRT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLPGEN) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMLSS ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMPTC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRA ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMRTLIB) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$LNK) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS$SRV) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMS7C ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTBMAP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCCPS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCIDS) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCLGT) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCPP ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTCVER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMMI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTMSI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMTXFER) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMUM ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMVCSUP) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXE ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (FLMXI ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. >++MOVE (ISRSUPC ) SYSLIB(SISPLPA) TOSYSLIB(SISPLOAD) LMOD. > >_ >Dave Jousma >Mainframe Engineering, Assistant Vice President david.jou...@53.com >1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f >616.653.2717 > >-Original Message- >From: IBM Mainframe Discussion List On >Behalf Of Wayne Bickerdike >Sent: Tuesday, January 15, 2019 9:58 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Abend 106 (was Generic query on Region allocation failure) > >**CAUTION EXTERNAL EMAIL** > >**DO NOT open attachments or click on links from unknown senders or >unexpected emails** > >Mark Zeldens excellent IPLINFO shows: > >The real storage size at IPL time was 2048M. >The private area size <16M is 8192K. >The private area size >16M is 1628M. >The CSA size <16M is 4812K. >The CSA size >16M is 300652K. >The SQA size <16M is 1248K. >The SQA size >16M is 15792K. >The maximum V=R region size is 280K. >The default V=R region size is 140K. >The maximum V=V region size is 8168K. > >Based on this: >CVTGDA = C2d(Storage(D2x(CVT + 560),4))/* point to GDA */ >GDACSA = C2d(Storage(D2x(CVTGDA + 108),4)) /* start of CSA addr*/ >GDACSAH = D2x(GDACSA) /* display in hex */ >CSAEND = (GDACSASZ*1024) + GDACSA - 1 /* end of CSA */ >CSAEND = D2x(CSAEND)
Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Sure, managers have been known to do silly things once or twice but there is no need for a surprise, unplanned rollback, right? A realistic DR drill would require a surprise, but the rollback could be planned, no? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, February 13, 2019 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register Willy-nilly is about notification and opportunity for preparation. For example, management declares a surprise DR drill on a Saturday morning. So the techs execute their well-rehearsed swap-over plan and begin running production at the DR site. Real live transactions with actual customer data. The old production site is now obsolete. Then Sunday at noon management decides to roll back before the new week starts off. There is no time to plan. No time to test. The entire environment has to copied back to prod overlaying the old data. And it has to work from the get-go. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
I believe 1st Data (or whatever they're called now) has been doing this for quite a few years. It just takes planning, good network folks, and $$ (and more $$$) Thanks! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, February 13, 2019 4:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register [ EXTERNAL ] Willy-nilly is about notification and opportunity for preparation. For example, management declares a surprise DR drill on a Saturday morning. So the techs execute their well-rehearsed swap-over plan and begin running production at the DR site. Real live transactions with actual customer data. The old production site is now obsolete. Then Sunday at noon management decides to roll back before the new week starts off. There is no time to plan. No time to test. The entire environment has to copied back to prod overlaying the old data. And it has to work from the get-go. Can anyone step up to that challenge? If not there could be some serious willy damage. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, February 12, 2019 4:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register On 2/11/2019 7:06 PM, Jesse 1 Robinson wrote: > All of this bodes ill for willy-nilly switching back and forth between data > centers unless there's some secret trick(s) I don't know about. I don't know the tricks either. Guess I need to attend more DCM Project-sponsored sessions at SHARE... ;-) I can attest that we have a number of customers that swap workloads between two sites a couple/few times a year. (Does that count as willy/nilly?) We have one or two with a third site in the mix! Yikes!!! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.phoenixsoftware.com_=DwIGaQ=huW-Z3760n7oNORvLCN2eBo-Ehm9Q_bNeNJaAMovBjQ=Qowhtqe2n9CP4j5cKgUfmAFB9ziwNIdru4NRZBXkzeA=49Q-M404LvT3sUQF872vNlK2Cx_FVgeDDUtZLruvN_A=6i0og_z3sZX-DN2xGL-L-rbl3KKZoHdu1GWufkOmP3k= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Willy-nilly is about notification and opportunity for preparation. For example, management declares a surprise DR drill on a Saturday morning. So the techs execute their well-rehearsed swap-over plan and begin running production at the DR site. Real live transactions with actual customer data. The old production site is now obsolete. Then Sunday at noon management decides to roll back before the new week starts off. There is no time to plan. No time to test. The entire environment has to copied back to prod overlaying the old data. And it has to work from the get-go. Can anyone step up to that challenge? If not there could be some serious willy damage. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, February 12, 2019 4:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register On 2/11/2019 7:06 PM, Jesse 1 Robinson wrote: > All of this bodes ill for willy-nilly switching back and forth between data > centers unless there's some secret trick(s) I don't know about. I don't know the tricks either. Guess I need to attend more DCM Project-sponsored sessions at SHARE... ;-) I can attest that we have a number of customers that swap workloads between two sites a couple/few times a year. (Does that count as willy/nilly?) We have one or two with a third site in the mix! Yikes!!! -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
HSM question - ML2 copy2 tapes that have no copy1
Hello list, I have a few HSM ML2 duplex tapes that no longer have their corresponding migrate tapes that I can't seem to get rid of. If I try to do DELVOL, I get an error saying they're not defined migrate volumes. What we're doing is migrating our HSM ML2 environment into a VTS (replicated) and eliminating the duplex tapes. I have these 4 duplex tapes from 2015 and 2017 that I can't get rid of. I think HSM still knows about these tapes and if I try to scratch them in the TMS, it says they're owned by an external data manager (ie HSM). Any thoughts on how to cleanly get rid of these tapes? I've looked at TAPEREPL but don't know if that would be a solution or not. TIA, Rex 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: How can I get reports in the Output Queue in SDSF to print
Thanks Vince, I will be sure to post the resolution for this once we get it resolved. Thanks, Ron McCabe Manager of Mainframe/Midrange Systems Mutual of Enumclaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vince Getgood Sent: Wednesday, February 13, 2019 12:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How can I get reports in the Output Queue in SDSF to print Ron, I'm afraid this has now gone outside my area of expertise... From what IBM say it's z/VM that's caused the connection to close, which suggests that the output on the z/OS side is ok. Sorry I can't be of any more help. It would be useful to know what the outcome is though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality Notice: This e- mail and all attachments may contain CONFIDENTIAL information and are meant solely for the intended recipient. It may contain controlled, privileged, or proprietary information that is protected under applicable law and shall not be disclosed to any unauthorized third party. If you are not the intended recipient, you are hereby notified that any unauthorized review, action, disclosure, distribution, or reproduction of any information contained in this e- mail and any attachments is strictly PROHIBITED. If you received this e- mail in error, please reply to the sender immediately stating that this transmission was misdirected, and delete or destroy all electronic and paper copies of this e-mail and attachments without disclosing the contents. This e- mail does not grant or assign rights of ownership in the proprietary subject matter herein, nor shall it be construed as a joint venture, partnership, teaming agreement, or any other formal business relationship. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTL - ISMF Question
Build list of volsers with the ERROR-STATUS in question.
LISTCAT CATALOG('your.VOLCAT.catalog') ALL
Alter volsers accordingly.
ALTER Vvolser VOLENTRY USEATTRIBUTE(SCRATCH) OWNERINFORMATION(' ')
Regards,
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Gadi Ben-Avi
Sent: Wednesday, February 13, 2019 6:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: VTL - ISMF Question
Hi,
When I look at the list of scratch volumes in ISMF, I see lots of volumes with
the status 'REJ BY TAP MGT SYS'
I know that if I alter them and select Scratch, they will be returned to the
scratch pool.
Is there a way to do this in Batch or for all of the volumes in one operation.
I have more than 500 of these volumes.
Thanks
Gadi
--
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: HSM question - ML2 tapes no longer avaialble
IMO, an empty tape has no value. HSM will not even mount attempt to mount it for the recycle. That being said, HDELVOL volser MIGRATION(PURGE) will also work just fine. -Original Message- From: IBM Mainframe Discussion List On Behalf Of retired mainframer Sent: Wednesday, February 13, 2019 9:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM question - ML2 tapes no longer avaialble Two recommendations below > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Allan Staller > Sent: Wednesday, February 13, 2019 7:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HSM question - ML2 tapes no longer avaialble > > For each affected volser: > > HSEND LIST TTOC(volser) ODS(x) > HDEL 'datasetname' for each indicated dataset. Add the PURGE operand to the HDEL command in case any datasets have long retention. > HSEND RECYCLE ALL EXECUTE PERCENTVALID(0) HDELVOL volser MIGRATION(PURGE) might be safer (will not affect any other empty tapes). > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tony Thigpen > Sent: Wednesday, February 13, 2019 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HSM question - ML2 tapes no longer avaialble > > Several years ago, the HSM tapes were migrated from 3490 to 3590. > > At that time, two 3490 tapes were unreadable so the systems programmer just skipped > the recycle and went on to the next tape. So, now I have 2 > 3490 tapes still in my CDS and I want to remove them. These tapes were created back > in 2001, so we are just going to write-off the data on the tapes as 'aged-out'. > > What is the proper procedure to eliminate these volumes from HSM? > > -- > Tony Thigpen -- 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: VTL - ISMF Question
If you have CA1 then there is a utility program CTSSYNC that will do the job for you in batch. Brian On Wed, 13 Feb 2019 at 22:17, Gadi Ben-Avi wrote: > Hi, > > When I look at the list of scratch volumes in ISMF, I see lots of volumes > with the status 'REJ BY TAP MGT SYS' > I know that if I alter them and select Scratch, they will be returned to > the scratch pool. > > Is there a way to do this in Batch or for all of the volumes in one > operation. > I have more than 500 of these volumes. > > Thanks > > Gadi > > > -- > 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: VTL - ISMF Question
When you say scratch pool do you mean remove from HSM entirely or do you mean mark as available to HSM? Whichever you decide, you can set the ISMF report to a dataset and write a REXX to parse it and generate DELVOL commands. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gadi Ben-Avi > Sent: Wednesday, February 13, 2019 6:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VTL - ISMF Question > > Hi, > > When I look at the list of scratch volumes in ISMF, I see lots of volumes with the > status 'REJ BY TAP MGT SYS' > I know that if I alter them and select Scratch, they will be returned to the scratch pool. > > Is there a way to do this in Batch or for all of the volumes in one operation. > I have more than 500 of these volumes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM question - ML2 tapes no longer avaialble
Thanks. Tony Thigpen Allan Staller wrote on 2/13/19 10:02 AM: For each affected volser: HSEND LIST TTOC(volser) ODS(x) HDEL 'datasetname' for each indicated dataset. HSEND RECYCLE ALL EXECUTE PERCENTVALID(0) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Wednesday, February 13, 2019 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HSM question - ML2 tapes no longer avaialble Several years ago, the HSM tapes were migrated from 3490 to 3590. At that time, two 3490 tapes were unreadable so the systems programmer just skipped the recycle and went on to the next tape. So, now I have 2 3490 tapes still in my CDS and I want to remove them. These tapes were created back in 2001, so we are just going to write-off the data on the tapes as 'aged-out'. What is the proper procedure to eliminate these volumes from HSM? -- Tony Thigpen -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM question - ML2 tapes no longer avaialble
Two recommendations below > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Allan Staller > Sent: Wednesday, February 13, 2019 7:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: HSM question - ML2 tapes no longer avaialble > > For each affected volser: > > HSEND LIST TTOC(volser) ODS(x) > HDEL 'datasetname' for each indicated dataset. Add the PURGE operand to the HDEL command in case any datasets have long retention. > HSEND RECYCLE ALL EXECUTE PERCENTVALID(0) HDELVOL volser MIGRATION(PURGE) might be safer (will not affect any other empty tapes). > HTH, > > > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tony Thigpen > Sent: Wednesday, February 13, 2019 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: HSM question - ML2 tapes no longer avaialble > > Several years ago, the HSM tapes were migrated from 3490 to 3590. > > At that time, two 3490 tapes were unreadable so the systems programmer just skipped > the recycle and went on to the next tape. So, now I have 2 > 3490 tapes still in my CDS and I want to remove them. These tapes were created back > in 2001, so we are just going to write-off the data on the tapes as 'aged-out'. > > What is the proper procedure to eliminate these volumes from HSM? > > -- > Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM question - ML2 tapes no longer avaialble
For each affected volser: HSEND LIST TTOC(volser) ODS(x) HDEL 'datasetname' for each indicated dataset. HSEND RECYCLE ALL EXECUTE PERCENTVALID(0) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Wednesday, February 13, 2019 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: HSM question - ML2 tapes no longer avaialble Several years ago, the HSM tapes were migrated from 3490 to 3590. At that time, two 3490 tapes were unreadable so the systems programmer just skipped the recycle and went on to the next tape. So, now I have 2 3490 tapes still in my CDS and I want to remove them. These tapes were created back in 2001, so we are just going to write-off the data on the tapes as 'aged-out'. What is the proper procedure to eliminate these volumes from HSM? -- Tony Thigpen -- 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
HSM question - ML2 tapes no longer avaialble
Several years ago, the HSM tapes were migrated from 3490 to 3590. At that time, two 3490 tapes were unreadable so the systems programmer just skipped the recycle and went on to the next tape. So, now I have 2 3490 tapes still in my CDS and I want to remove them. These tapes were created back in 2001, so we are just going to write-off the data on the tapes as 'aged-out'. What is the proper procedure to eliminate these volumes from HSM? -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VTL - ISMF Question
Hi, When I look at the list of scratch volumes in ISMF, I see lots of volumes with the status 'REJ BY TAP MGT SYS' I know that if I alter them and select Scratch, they will be returned to the scratch pool. Is there a way to do this in Batch or for all of the volumes in one operation. I have more than 500 of these volumes. Thanks Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSSTATE (was Abend 052-512)
Steve Smith wrote: >SYSSTATE OSREL=SYSSTATE,ARCHLVL=OSREL I agree with Steve. That is what we use for code applicable to the new z/OS release. At least for the cases where we know that the code will be running on that release (an exception being such MIGLIB things as IPCS-related parts that might run on an earlier release) z/OS 2.3 introduced the concept of OSREL=MIGLIB which you might think of as the oldest in-full-support release at the time of GA of the release (which was z/OS 2.1 as of z/OS 2.3 GA). Anyway, the mild caveat is that these work if you have only one release in play. A lot of customers (especially during migration) have multiple releases in play. A point: if you invoke z/OS macros, you should expect to provide addressability to static storage (such as where a LTORG might put something). Relative branch might get rid of the need for inlined data, but (even with the immediates) does not intend to get rid of the need for static data. Over time, some macros will "move up" to something more current (even "relative branch" is more current that most defaults) even without a SYSSTATE specification (in particular when not doing so would be more costly than doing so). But my view is that we would not move up to "fully current" because we still want you to be able to compile with the "new release's macros" but run on older (but supported) releases, and typically more releases than are under full support. So for example, a macro might well move up to "assume z/Architecture" but likely not "assume zEC12 instructions" (which are part of the z/OS 2.3 Architecture Level Set) or usually not even "z10" instructions (the z/OS 2.2 ALS) or "z9" instructions. There are likely exceptions, but that's the general thought. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How can I get reports in the Output Queue in SDSF to print
Ron, I'm afraid this has now gone outside my area of expertise... From what IBM say it's z/VM that's caused the connection to close, which suggests that the output on the z/OS side is ok. Sorry I can't be of any more help. It would be useful to know what the outcome is though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
