Re: PPRC power failure
On the sending DASD there is a 1 bit per track table of updated tracks. When each track is sent the bit is reset. When it gets caught up it sets a sync point. On Wed, Feb 13, 2019 at 9:44 PM Peter wrote: > > 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 -- 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: PPRC power failure
Peter, My experience is over a decade old with XRC, but I imagine the potential for some form of read/write/IO pacing is the same and that it could impact performance. Open a PMR and ask IBM. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Wednesday, February 13, 2019 10:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PPRC power failure
For messaging, review of Message Flood Automation rules would seem to be in order: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieae200/msgfld.htm On Wed, Feb 13, 2019 at 9:44 PM Peter wrote: > 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 > -- 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 copy2 tapes that have no copy1
Most likely a continuation of a prior volume. Without going into a lot of detail, if a dataset spans from 1 volume to another the 1st volume in the sequence "owns it". Duplex volumes are never referenced by DFHSM directly. HSEND LIST TTOC will list all primary voulmes. I expect the duplex volumes will also be shown, but I am not sure. It has been too long since I've duplexed. This *will* show the predecessor and successor volumes. I expect the "offending" volsers to be successor volumes. HSEND LIST TTOC(volser) will give you a list of datasets on the volume. Use this to obtain the "English" name of the datset. At this point there are 2 choices. HDELETE 'DSN' for the dataset that spans volumes. This will automatically delete the duplex volumes. Use the output of the HSEND LIST TTOC to obtain the "owning" primary volume. Recycle the "owning" primary volume. The "offending" duplex volumes will be deleted as part of the recycle process. HSEND RECYCLE EXECUTE VOLUME(owning volser) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, February 13, 2019 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 ::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: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Thanks you for Interesting discussion.. Just wanted to know if any organization running Parallel sysplex between two or More CPCs located 12 KM (>7 miles) apart. I find running DEV+TEST and PRODUCTION at different locations and cater for Service Continuity by swapping over to other site with automated CBU/COD. We do have SDRF , Adaptive copy of all our disks but new regulatory retirement is to recover system from TAPE (at a remote Site, couple of thousand kilometers apart from Full Data Backup and transient logs / Journals). interesting time ahead. Kind regards Munif. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DEQ dynamically
It used to be documented; I don't know if it still is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, February 12, 2019 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DEQ dynamically On Tue, 12 Feb 2019 18:35:39 +, Seymour J Metz wrote: >The free doesn't do a DEQ if another step needs the dataset. > Makes sense. Is it documented? Most probably in the description of SVC 99, since it applies alike to all programs, foreground and batch. -- gil -- 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: DEQ dynamically
Well, if you don't mind taking out an initiator, ... What's documented is that DYNALLOC is for allocating and freeing datasets in your jobstep. The Initiator for your job is not in your jobstep. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, February 12, 2019 1:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DEQ dynamically On Tue, 12 Feb 2019 18:25:34 +, Seymour J Metz wrote: >Not in the normal course of events. Don't try this at home. > Why not? o What's the hazard (beyond failure with a message)? o Is that documented? >From: Vernooij, Kees (ITOP NM) - KLM >Sent: Tuesday, February 12, 2019 2:21 AM > >I wonder: can I deallocate a dataset with DYNALLOC, that has been allocated by >the initiator because there is a DD statement? -- gil -- 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: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
We run our parallel Sysplex at 2 locations between 15 and 20 km apart. If you are interested in Parallel Sysplex performance, your next question might/should be: do you run (with CFs in both sites) System Managed CF Structure Duplexing? We are using SMCFSD. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Munif Sadek > Sent: 14 February, 2019 15:55 > 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 > > Thanks you for Interesting discussion.. > > Just wanted to know if any organization running Parallel sysplex between > two or More CPCs located 12 KM (>7 miles) apart. I find running > DEV+TEST and PRODUCTION at different locations and cater for Service > Continuity by swapping over to other site with automated CBU/COD. > > We do have SDRF , Adaptive copy of all our disks but new regulatory > retirement is to recover system from TAPE (at a remote Site, couple of > thousand kilometers apart from Full Data Backup and transient logs / > Journals). > > interesting time ahead. > > Kind regards > Munif. > > -- > 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: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
On Thu, 14 Feb 2019 07:27:36 +, Vernooij, Kees (ITOP NM) - KLM wrote: >Just reverse the replication when starting up the DR site. That isn't necessarily a real DR test. In a real disaster, you may not be able to replicate the data back to the primary site for a considerable period of time. >And reverse replication again after returning to the normal site. That part should be easier. -- 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 can I get reports in the Output Queue in SDSF to print
Vince, We were able to get this issue resolved. IBM support had me issue a QUERY LINK on my z/VM side and noticed that the LINK was in a hold status. They then had me issue a FREE LINK command and after starting the transmitters on the z/OS side everything started working. Not sure how the LINK got in a hold state and hopefully I will be able to find out. Thanks for all your help on this. 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: HSM question - ML2 copy2 tapes that have no copy1
Allan, Sorry, this doesn't help. The LIST TTOC is only showing my VTS-based ML2 tapes which have no duplex. BTW, LIST TTOC does show duplex volumes if they exist. :-) These duplex tapes all have old create dates and so I am confident they are orphans. Now, how to get rid of them. I'll try the TAPEREPL process in a test environment to see what happens. Thanks. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, February 14, 2019 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: HSM question - ML2 copy2 tapes that have no copy1 Most likely a continuation of a prior volume. Without going into a lot of detail, if a dataset spans from 1 volume to another the 1st volume in the sequence "owns it". Duplex volumes are never referenced by DFHSM directly. HSEND LIST TTOC will list all primary voulmes. I expect the duplex volumes will also be shown, but I am not sure. It has been too long since I've duplexed. This *will* show the predecessor and successor volumes. I expect the "offending" volsers to be successor volumes. HSEND LIST TTOC(volser) will give you a list of datasets on the volume. Use this to obtain the "English" name of the datset. At this point there are 2 choices. HDELETE 'DSN' for the dataset that spans volumes. This will automatically delete the duplex volumes. Use the output of the HSEND LIST TTOC to obtain the "owning" primary volume. Recycle the "owning" primary volume. The "offending" duplex volumes will be deleted as part of the recycle process. HSEND RECYCLE EXECUTE VOLUME(owning volser) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, February 13, 2019 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 ::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. --
PARMDD and Symbols in a Started PROC
I know I am late to the party but I am just dipping my toe into the LONGPARM pool. I have a started PROC with the typical sort of symbols declared on the PROC statement. The PROC is two jobsteps, FWIW. The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME And //MYDDNAME DD *,SYMBOLS=JCLONLY Various references to the PROC symbols /* I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first step, and in the second step. The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED for every single one of the symbols. z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. What am I doing wrong? Or is the big picture of what I am attempting to do hopeless? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Charles Mills > Sent: Thursday, February 14, 2019 11:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: PARMDD and Symbols in a Started PROC > > I know I am late to the party but I am just dipping my toe into the LONGPARM > pool. > > > > I have a started PROC with the typical sort of symbols declared on the PROC > statement. > > > > The PROC is two jobsteps, FWIW. > > > > The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME > > > > And > > > > //MYDDNAME DD *,SYMBOLS=JCLONLY > > Various references to the PROC symbols > > /* > > > > I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first > step, and in the second step. > > > > The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED > for every single one of the symbols. > > > > z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. > > > > What am I doing wrong? Or is the big picture of what I am attempting to do > hopeless? > > > > 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: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Actually, Skip, we were almost at the point to be able to do this when we moved to the new data center. And, the procedure is very similar to the way the move was done. With the new data center, both the primary and secondary site had double disk, so that we could mirror in either direction and flashcopy to the secondary copy and run off of it. For a test switch to the secondary site, follow the same procedure we used to do the move: Clean shut down of primary site Run GDPS script to do XRC recovery Shut down XRC and GDPS systems Start XRC and GDPS systems at primary site Run GDPS script to start mirroring with NOCOPY (since primary and secondary are duplicates of each other) Start production systems at secondary site (There are also the network changes for DR that are to be done in here) What was missing when I left: The ability to run XRC/GDPS at primary (although it could also be accomplished using push from secondary instead of pull) The GDPS configuration to mirror back must be kept up to date Going back to primary would follow the same process. If you still have the procedure for the data center move, that will get you 95% of the way there. Of course, this is only good for moving between sites and it requires production outages. In a true DR, there is probably no DASD to mirror back to, even if using push instead of pull. When we had the z10 outage, this would have worked (if we had the duplicate DASD at that time). But as you mentioned, deciding to fail over when you feel you will get your primary site back soon is a tough choice. For SCE, the challenges are the secondary site just being a single CEC that has to have a CBU upgrade to run any production work, so this would all have to happen in a single weekend. You don't want to run at the backup site any longer than necessary if it is not a true disaster. On 2/13/19 3:41 PM, Jesse 1 Robinson wrote: > 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM question - ML2 copy2 tapes that have no copy1
Try HSEND DELVOL(XX) PURGE FORCE(?) I haven't looked up the syntax. Actually, if they are not in the TTOC you can probably just expire them. Not sure if you are using RMM, TMS, or other, but RMM had a quirk, whereby if the tape ever had a permanent error (as defined by having a SWAP associated) the volume would not go scratch until replaced. Don't remember the exact details. Al -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, February 14, 2019 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM question - ML2 copy2 tapes that have no copy1 Allan, Sorry, this doesn't help. The LIST TTOC is only showing my VTS-based ML2 tapes which have no duplex. BTW, LIST TTOC does show duplex volumes if they exist. :-) These duplex tapes all have old create dates and so I am confident they are orphans. Now, how to get rid of them. I'll try the TAPEREPL process in a test environment to see what happens. Thanks. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, February 14, 2019 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: HSM question - ML2 copy2 tapes that have no copy1 Most likely a continuation of a prior volume. Without going into a lot of detail, if a dataset spans from 1 volume to another the 1st volume in the sequence "owns it". Duplex volumes are never referenced by DFHSM directly. HSEND LIST TTOC will list all primary voulmes. I expect the duplex volumes will also be shown, but I am not sure. It has been too long since I've duplexed. This *will* show the predecessor and successor volumes. I expect the "offending" volsers to be successor volumes. HSEND LIST TTOC(volser) will give you a list of datasets on the volume. Use this to obtain the "English" name of the datset. At this point there are 2 choices. HDELETE 'DSN' for the dataset that spans volumes. This will automatically delete the duplex volumes. Use the output of the HSEND LIST TTOC to obtain the "owning" primary volume. Recycle the "owning" primary volume. The "offending" duplex volumes will be deleted as part of the recycle process. HSEND RECYCLE EXECUTE VOLUME(owning volser) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, February 13, 2019 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 ::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
Re: PARMDD and Symbols in a Started PROC
Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- 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: PARMDD and Symbols in a Started PROC
Try doing each one on one line Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Charles Mills > Sent: Thursday, February 14, 2019 11:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > Combo of the two, Lizette. > > There are nine parms spread across three lines. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Thursday, February 14, 2019 10:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > How do you have your parms set in the PARMDD input? > > I was told each parm needs to be on a separate line. Not sure how accurate > that is. > > Have you tried individual lines? > > Which way is your input coded? > > >//MYDDNAME DD *,SYMBOLS=JCLONLY >PARM1,PARM2,PARM3,etc > > Or >//MYDDNAME DD *,SYMBOLS=JCLONLY >PARM1 >PARM2 >PARM3 > Etc... > > -- > 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: PARMDD and Symbols in a Started PROC
I tried spreading the first three parms across three lines -- no difference. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I really and truly have // EXPORT SYMLIST=* I've used that before in batch jobs and you know how we lazy programmers are -- I just copied it over. Why? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
OK, I am making some progress. I got past the JCL error by coding a bunch of dummy // SET FOO=&PARM1 statements. I am not getting errors from the program. I can see that no symbol substitution has been done. Is there any restriction on DD *,SYMBOLS in a started PROC? Where should the EXPORT statement go? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD and Symbols in a Started PROC I know I am late to the party but I am just dipping my toe into the LONGPARM pool. I have a started PROC with the typical sort of symbols declared on the PROC statement. The PROC is two jobsteps, FWIW. The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME And //MYDDNAME DD *,SYMBOLS=JCLONLY Various references to the PROC symbols /* I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first step, and in the second step. The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED for every single one of the symbols. z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. What am I doing wrong? Or is the big picture of what I am attempting to do hopeless? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
> // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
Job cards can be specified in members for libraries defined in MSTJCL00 - //IEFJOBS concatenation - job cards can be specified - also in any proclib member in //IEFPDSI concatenation. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC > // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
The EXPORT needs to precede the PROC statement, but I am not sure if that is legal for a STARTed PROC. In my experience at z/OS level 2.2, for regular batch JCL you must put the EXPORT prior to any SET's **and** prior to any PROC *execution* in order to catch the PROC default values. And I agree it would be helpful for IBM to supply specific examples for this area. Most of what I know about the subject is via trial-and-error. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC > // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: >> // EXPORT gets specified first before any // SET stmts > >How do I do that in a PROC where the SETs are implicit in the PROC >statement, which is the very first statement? > >//procname PROC PARM1=value,PARM2=value Try this: //procname PROC PARM1=value,PARM2=value // EXPORT SYMLIST=* // SET PARM1=&PARM1 // SET PARM2=&PARM2 -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 10:02:26 -0800, Charles Mills wrote: > ... >I have a started PROC with the typical sort of symbols declared on the PROC >statement. >... >The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME > >//MYDDNAME DD *,SYMBOLS=JCLONLY > >I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first >step, and in the second step. > The JCL Ref. says: Chapter 17. EXPORT statement Purpose: Use the EXPORT statement to make specific JCL symbols available to the job step program. I suspect that "JCL symbols" means SET symbols but excludes PROC args. IBM makes too damned many rules. A name should be a name, whether SET or a PROC arg. > ... >The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED >for every single one of the symbols. > .. Tnat message has struck me as insane design since I first encountered it over 40 years ago. Completely backwards. What sane language designer would allow reference to an undefined symbol but fail definition a symbol with no references. (Perhaps a warning, not an error, on the latter would be a courtesy to the programmer.) >What am I doing wrong? Or is the big picture of what I am attempting to do >hopeless? > No more hopeful than an RFE to straighten out the whole mess. And did you know that if a symbol is SET to different values before and after the DD * statement, the one *after* is used!? -- gil -- 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
Or I'm wondering if Global Mirror directly from DS8886 to DS8886 might be worth looking into, simplifying that process by eliminating XRC. That takes an extra copy of each DASD volume at each site though. On 2/14/2019 10:12 AM, Stuart zseries wrote: What was missing when I left: The ability to run XRC/GDPS at primary (although it could also be accomplished using push from secondary instead of pull) The GDPS configuration to mirror back must be kept up to date -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 10:57:06 -0800, Charles Mills wrote: > ... >Would it kill IBM to have some meaningful examples in the JCL reference? > The JCL Ref. contains a section: Using symbols in started task JCL Example: using JCL symbols Prepare to be disappointed. I see no meaningful example. Only a couple forlorn snippets. > ... >Try this: >//procname PROC PARM1=value,PARM2=value >// EXPORT SYMLIST=* >// SET PARM1=&PARM1 >// SET PARM2=&PARM2 Doesn't this run afoul of a rule elsewhere in the Ref. that symbols are not to be defined in terms of other symbols. I've tried it; it works, even on both sides of the "=". But I must recognize that if I do so and my program breaks I get to keep both pieces. -- gil -- 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 copy2 tapes that have no copy1
I get "entry not defined". Unfortunately that doesn't help, because on my playground I have duplex tapes with their primary ML2 tape still existent, and I get the same "not defined" message. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, February 14, 2019 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: HSM question - ML2 copy2 tapes that have no copy1 Try HSEND DELVOL(XX) PURGE FORCE(?) I haven't looked up the syntax. Actually, if they are not in the TTOC you can probably just expire them. Not sure if you are using RMM, TMS, or other, but RMM had a quirk, whereby if the tape ever had a permanent error (as defined by having a SWAP associated) the volume would not go scratch until replaced. Don't remember the exact details. Al -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, February 14, 2019 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: HSM question - ML2 copy2 tapes that have no copy1 Allan, Sorry, this doesn't help. The LIST TTOC is only showing my VTS-based ML2 tapes which have no duplex. BTW, LIST TTOC does show duplex volumes if they exist. :-) These duplex tapes all have old create dates and so I am confident they are orphans. Now, how to get rid of them. I'll try the TAPEREPL process in a test environment to see what happens. Thanks. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Thursday, February 14, 2019 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: HSM question - ML2 copy2 tapes that have no copy1 Most likely a continuation of a prior volume. Without going into a lot of detail, if a dataset spans from 1 volume to another the 1st volume in the sequence "owns it". Duplex volumes are never referenced by DFHSM directly. HSEND LIST TTOC will list all primary voulmes. I expect the duplex volumes will also be shown, but I am not sure. It has been too long since I've duplexed. This *will* show the predecessor and successor volumes. I expect the "offending" volsers to be successor volumes. HSEND LIST TTOC(volser) will give you a list of datasets on the volume. Use this to obtain the "English" name of the datset. At this point there are 2 choices. HDELETE 'DSN' for the dataset that spans volumes. This will automatically delete the duplex volumes. Use the output of the HSEND LIST TTOC to obtain the "owning" primary volume. Recycle the "owning" primary volume. The "offending" duplex volumes will be deleted as part of the recycle process. HSEND RECYCLE EXECUTE VOLUME(owning volser) HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Wednesday, February 13, 2019 4:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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 ::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, destro
Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register
Tom - Global Mirror only requires the extra set of DASD at the receiving site (or at least that is how we are setup). However you'd then need the ability to reverse the replication so could need extra at the primary site (our plan states if we declare we are in the DR site for an extended period - discourages those Managers from the willy decisions Skip referred to) 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 02/14/2019 12:47:46 PM: > From: Tom Brennan > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/14/2019 12:48 PM > Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up > in smoke, bank website, app down . The Register > Sent by: IBM Mainframe Discussion List > > Or I'm wondering if Global Mirror directly from DS8886 to DS8886 might > be worth looking into, simplifying that process by eliminating XRC. > That takes an extra copy of each DASD volume at each site though. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote: >>// SET PARM2=&PARM2 > >Doesn't this run afoul of a rule elsewhere in the Ref. that symbols >are not to be defined in terms of other symbols. What rule is that? Where is it documented? -- Tom Marchant -- 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 might be posting twice here but I've been reading the list via Google Groups and posting there not realizing that the posts don't necessary hit the mailing list. So I've done the proper thing and subscribed to the list. Sorry for any confusion. Anyway when I started DR planning and Sysplex I found the following video from the Washington Systems Center very helpful. https://youtu.be/cew5lQaWSpw On Fri, Feb 15, 2019, 9:24 AM Jerry Whitteridge Tom - Global Mirror only requires the extra set of DASD at the receiving > site (or at least that is how we are setup). However you'd then need the > ability to reverse the replication so could need extra at the primary site > (our plan states if we declare we are in the DR site for an extended period > - discourages those Managers from the willy decisions Skip referred to) > > 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 > 02/14/2019 12:47:46 PM: > > > From: Tom Brennan > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 02/14/2019 12:48 PM > > Subject: Re: Wells Fargo? Well f*&%#d at the moment: Data center up > > in smoke, bank website, app down . The Register > > Sent by: IBM Mainframe Discussion List > > > > Or I'm wondering if Global Mirror directly from DS8886 to DS8886 might > > be worth looking into, simplifying that process by eliminating XRC. > > That takes an extra copy of each DASD volume at each site though. > > > -- > 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: PARMDD and Symbols in a Started PROC
@Tom's got it. Thanks. EXPORT works in a PROC and so forth but must come before the definition of the symbols it exports. (Again, seems kind of backwards, but what do I know?) I think I could have done //jobname JOB ... // EXPORT SYMLIST=* //procname PROC ... But I have never coded a started PROC with a JOB (and I know you can, but it was just a wormhole I did not want to go down at this moment) so I did more or less what Tom suggests. //procname PROC PARM1=value1,PARM2=value2 // EXPORT SYMLIST=* // SET $PARM1=PARM1 // SET $PARM2=PARM2 ... //MYPARMDD DD *,SYMBOLS=JCLONLY $PARM1,$PARM2,... And it is all working. Gosh some better doc AND SOME MEANINGFUL EXAMPLES would be appreciated. Thanks all here for the help. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, February 14, 2019 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: >> // EXPORT gets specified first before any // SET stmts > >How do I do that in a PROC where the SETs are implicit in the PROC >statement, which is the very first statement? > >//procname PROC PARM1=value,PARM2=value Try this: //procname PROC PARM1=value,PARM2=value // EXPORT SYMLIST=* // SET PARM1=&PARM1 // SET PARM2=&PARM2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
+1 And easy for me to say but wouldn't it be trivial to fix? Just pull out the code that checks for unused symbols? No compatibility issues -- no one is conceivably COUNTING ON a JCL error in that situation. Wasn't assembler the model for JCL? Assembler allows unreferenced fields. (Although interestingly my C++ compiler warns me about unused stack and formal parameter variables.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, February 14, 2019 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC >The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED >for every single one of the symbols. > .. Tnat message has struck me as insane design since I first encountered it over 40 years ago. Completely backwards. What sane language designer would allow reference to an undefined symbol but fail definition a symbol with no references. (Perhaps a warning, not an error, on the latter would be a courtesy to the programmer.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I'm keeping this as my set of examples - Thanks Charles 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 02/14/2019 02:07:07 PM: > From: Charles Mills > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/14/2019 02:07 PM > Subject: Re: PARMDD and Symbols in a Started PROC > Sent by: IBM Mainframe Discussion List > > @Tom's got it. Thanks. > > EXPORT works in a PROC and so forth but must come before the > definition of the symbols it exports. (Again, seems kind of > backwards, but what do I know?) > > I think I could have done > > //jobname JOB ... > // EXPORT SYMLIST=* > //procname PROC ... > > But I have never coded a started PROC with a JOB (and I know you > can, but it was just a wormhole I did not want to go down at this > moment) so I did more or less what Tom suggests. > > //procname PROC PARM1=value1,PARM2=value2 > // EXPORT SYMLIST=* > // SET $PARM1=PARM1 > // SET $PARM2=PARM2 > ... > //MYPARMDD DD *,SYMBOLS=JCLONLY >$PARM1,$PARM2,... > > And it is all working. Gosh some better doc AND SOME MEANINGFUL > EXAMPLES would be appreciated. > > Thanks all here for the help. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Tom Marchant > Sent: Thursday, February 14, 2019 11:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: > > >> // EXPORT gets specified first before any // SET stmts > > > >How do I do that in a PROC where the SETs are implicit in the PROC > >statement, which is the very first statement? > > > >//procname PROC PARM1=value,PARM2=value > > Try this: > //procname PROC PARM1=value,PARM2=value > // EXPORT SYMLIST=* > // SET PARM1=&PARM1 > // SET PARM2=&PARM2 > > -- > 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 long may a console command be?
Well, now that I have STC LONGPARM working, how long can the START command be? The commands reference describes two formats. It says most commands can use format one, and it may be up to 126 characters. And it says three specific commands must use format two, and does not indicate a maximum length. So that begs two questions: - May all commands use format two? - What is the maximum length for format two? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote: >I think I could have done > >//jobname JOB ... >// EXPORT SYMLIST=* >//procname PROC ... Maybe. I had a similar problem a few years ago, but in my case, I had a PROC that was used in some jobs. I don't remember if I tried using the EXPORT in each of the jobs that invoked the PROC. >But I have never coded a started PROC with a JOB (and I know you can, but it >was just a wormhole I did not want to go down at this moment) IIRC, when you code a started job, you don't use PROC. When you start the task, specifying PARM1=value1,etc., it inserts a SET statement after the JOB card. I don't know how you would code default values for your parameters. >so I did more or less what Tom suggests. > >//procname PROC PARM1=value1,PARM2=value2 >// EXPORT SYMLIST=* >// SET $PARM1=PARM1 >// SET $PARM2=PARM2 >... >//MYPARMDD DD *,SYMBOLS=JCLONLY > $PARM1,$PARM2,... I did something like that too, but then I found out (at the suggestion of IBM) that I could use the same symbol name, like this: // SET PARM1=&PARM1 It looks strange, but it works. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
NP Jerry. I *suspect* what Tom suggested would work and would be simpler than what I did. // SET PARM1=&PARM1 Rather than // SET $PARM1=&PARM1 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Thursday, February 14, 2019 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC I'm keeping this as my set of examples - Thanks Charles 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 02/14/2019 02:07:07 PM: > From: Charles Mills > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/14/2019 02:07 PM > Subject: Re: PARMDD and Symbols in a Started PROC > Sent by: IBM Mainframe Discussion List > > @Tom's got it. Thanks. > > EXPORT works in a PROC and so forth but must come before the > definition of the symbols it exports. (Again, seems kind of > backwards, but what do I know?) > > I think I could have done > > //jobname JOB ... > // EXPORT SYMLIST=* > //procname PROC ... > > But I have never coded a started PROC with a JOB (and I know you > can, but it was just a wormhole I did not want to go down at this > moment) so I did more or less what Tom suggests. > > //procname PROC PARM1=value1,PARM2=value2 > // EXPORT SYMLIST=* > // SET $PARM1=PARM1 > // SET $PARM2=PARM2 > ... > //MYPARMDD DD *,SYMBOLS=JCLONLY >$PARM1,$PARM2,... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 14:28:35 -0600, Tom Marchant wrote: >On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote: > >>>// SET PARM2=&PARM2 >> >>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols >>are not to be defined in terms of other symbols. > >What rule is that? Where is it documented? > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/jdefine.htm Defining and nullifying JCL symbols o Do not specify JCL symbols within other JCL symbols. The results can be unpredictable, especially if the imbedded JCL symbol is not previously defined. Long ago, I submitted an RCF asking for a clarification of whether the "within" refers to the symbol name or the substitution text (I've tried both, and both work.) I don't see that any change has been made to the Ref. Looking for that passage, I was astonished and dismayed at the huge volume of text in the JCL Ref concerning symbols, their definition, and use. I consider this not an indication of good documentation but of bad design. There are rules and exceptions to the rules and exceptions to the exceptions. And "unpredictable" is shirking design responsibility. The semantics of any construct should be well-documented (and simple). The programmer's use of any construct for which the designer could not specify a semantic should be treated as an error. Simpler is better. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The 200 year old computer
Starts with the Jacquard loom using punched cards, Babich's unfinished difference engine, and Holreith's punched cards for the 1890 census. https://www.youtube.com/watch?v=R7-a7kzlk9g -- 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: The 200 year old computer
https://en.wikipedia.org/wiki/Antikythera_mechanism In a message dated 2/14/2019 4:41:47 PM Central Standard Time, mike.a.sch...@gmail.com writes: Starts with the Jacquard loom using punched cards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DEQ dynamically
I wonder: can I deallocate a dataset with DYNALLOC, that has been allocated by the initiator because there is a DD statement? Kees. Table 1. Verb code 02 (dynamic unallocation) – Text unit keys, mnemonics, and functions Hex text unit key MnemonicDYNALLOC function . 0007 DUNUNALCSpecifies deallocation even if the resource has the permanently allocated attribute. . DUNUNALC specifies that the resource is to be deallocated even if it has the permanently allocated attribute. The remove in-use option key (DUNREMOV) is mutually exclusive with DUNUNALC. When you code this key, # must be zero; LEN and PARM are not specified. Example: To specify the unalloc option, code: KEY# LENPARM 0007 - - I have used this with success since the very late '70's to deallocate datasets that were allocated in JCL. It is currently in a product that is in the field. Probably the reason you don't see this so much is there is rarely a need for it. But when you need it, you need it. Larry Chenevert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DELETE FMID
Hi I am trying to reapply a FMID to the target zone of DB2 but it is failing to apply even though I have specified REDO with FMID and it's Associated PTF. I have checked the global zone that this FMID is already in RECEIVED,APPLIED, ACCEPT status. What will be the best approach to reapply the FMID from global zone ? Will it be good to DELETE THE FMID from target zone and apply again ? Any comments are much appreciated Peter -- 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
It might not be possible in a real (total) disaster to reverse the replication. However, the DR procedures can also be used in different situations. The simplest is a partial disaster or other problem, like a problem in the CPU room, without problems in the DISK room. Or we executed the procedure when a potential dangerous action was to be carries out on the powersupply in one of the buidlings. In both situatoins you execute the DR procedure with the clear intent to return soon to normal operation. In these cases you will like to reverse replication, to keep both mirrors intact. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Marchant > Sent: 14 February, 2019 17:58 > 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 > > On Thu, 14 Feb 2019 07:27:36 +, Vernooij, Kees (ITOP NM) - KLM > wrote: > > >Just reverse the replication when starting up the DR site. > > That isn't necessarily a real DR test. In a real disaster, you may not > be able to > replicate the data back to the primary site for a considerable period of > time. > > >And reverse replication again after returning to the normal site. > > That part should be easier. > > -- > Tom Marchant > > -- > 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
