Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Vernooij, Kees (ITOP NM) - KLM]

With a proper GDPS implementation, you don't even need a clean shutdown. A 
Hyperswap can be done at any moment (we test it regularly). 

Kees


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: 12 February, 2019 7:13
> 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
> 
> As soon as you start production at the DR site, you need to start
> replication to your next site (production or third site).
> If you have a clean shutdown and the mirroring software supports it,
> you might be able to swap primary and secondary to avoid having to
> copy the volumes.
> 
> On Mon, Feb 11, 2019 at 9:06 PM Jesse 1 Robinson
>  wrote:
> >
> > Sorry Mike. That's what management seems to believe. It's what we've
> done for TWENTY years. It allows us to fail over to the 'DR site' at
> will. Including for-real failover where DR becomes the day-to-day home
> from then on. That's not the hard part. The hard part is that after
> failover, production now lives at the DR site, yet it's officially
> temporary. All new REAL customer data now lives over the hill and
> through the woods, not at home.
> >
> > -- 1000's of volumes/UCBs worth of data that is suddenly obsolete 'at
> home' and therefore useless.
> >
> > -- A GDPS mapping of all prod volumes to DR secondary volumes.
> >
> > -- A GDPS mapping of all secondary volumes to tertiary volumes, which
> we actually IPL from. If we IPL'ed and ran with secondary volumes,
> mirroring would be destroyed until we resynched.
> >
> >  -- We're under the gun to move back 'home' with some alacrity because
> two CECs are required for CF redundancy. DR has only one CEC for
> economy.
> >
> > 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.
> >
> > .
> > .
> > 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 Mike Schwab
> > Sent: Monday, February 11, 2019 5:03 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
> >
> > Mirroring the DASD to the backup site.
> >
> > On Mon, Feb 11, 2019 at 4:50 PM Jesse 1 Robinson
>  wrote:
> > >
> > > I have nothing but admiration for a shop that can slosh workload
> back and forth between two data centers. There are those that can and
> those (like us) that cannot. How does one get from the first group into
> the second?
> > >
> > > .
> > > .
> > > 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-
> m...@listserv.ua.edu]
> > > On Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > > Sent: Monday, February 11, 2019 5:58 AM
> > > 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
> > >
> > > We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in
> the other site, a CF in both sites and Dasd mirrored between the sites.
> > > Our DRP consists of moving workload from 1 site's LPARs to the
> corresponding LPARs in the other site and adding capacity b.m.o. CBUs.
> No manipulation of LPARs.
> > > We do this from time to time, sometimes as part of a DRP test,
> recently also because of a potentially disastrous power maintenance in a
> site.
> > > A piece of cake, compared to the comments I read above.
> > >
> > > Kees.
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List
> > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller
> > > > Sent: 11 February, 2019 14:30
> > > > 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
> > > >
> > > > I have heard of a company in the Far East the periodically (every
> 6
> > > > mths., IIRC) flips from site A to site B (and back).
> > > > Aus(?) to Phillipines ?) and back.
> > > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Savor, Thomas (Alpharetta)
> > > > Sent: Friday, February 8, 2019 7:08 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
> > > >
> > > > 

Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Vernooij, Kees (ITOP NM) - KLM]

Do you mean: from  the first into the second or vica versa?
It all is a matter of the right contracts, if your company can afford the costs 
of course.

As to Mikes answer: you do mirror data constantly from the first to the second 
datacenter, don't you? Why would you move to the second center if there is no 
data?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: 11 February, 2019 23:50
> 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
> 
> I have nothing but admiration for a shop that can slosh workload back
> and forth between two data centers. There are those that can and those
> (like us) that cannot. How does one get from the first group into the
> second?
> 
> .
> .
> 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 Vernooij, Kees (ITOP NM) - KLM
> Sent: Monday, February 11, 2019 5:58 AM
> 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
> 
> We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the
> other site, a CF in both sites and Dasd mirrored between the sites.
> Our DRP consists of moving workload from 1 site's LPARs to the
> corresponding LPARs in the other site and adding capacity b.m.o. CBUs.
> No manipulation of LPARs.
> We do this from time to time, sometimes as part of a DRP test, recently
> also because of a potentially disastrous power maintenance in a site.
> A piece of cake, compared to the comments I read above.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Allan Staller
> > Sent: 11 February, 2019 14:30
> > 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
> >
> > I have heard of a company in the Far East the periodically (every 6
> > mths., IIRC) flips from site A to site B (and back).
> > Aus(?) to Phillipines ?) and back.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Savor, Thomas (Alpharetta)
> > Sent: Friday, February 8, 2019 7:08 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
> >
> > >We've been doing DR mirroring for 20 years. It gets tested often.
> > >We've
> > moved production twice to another >data center using our procedures.
> > What we've never done is run production in another location
> > >temporarily. 'Temporary' means move it, run it until at least one
> > transaction is committed, then move it >*all* back. That is hugely
> > complex and costly.
> >
> > >A lot of management fantasizes about a big A-B switch that we throw
> > >one
> > way or the other. So wrong.
> >
> > About 5-6 years ago, I was working as a vendor (Daily Support) for
> > Credit Card Software for Halifax/Bank of Scotland.  I believe the
> > first time I was given a "heads up" was when we were supporting 12
> > Million Cardholders.  The "Heads up" was that on Friday evening at 6pm
> > Main site was going to shut down and the whole weekend PRODUCTION was
> > going to run on DR site, then 6am Monday Morning, Main site is to come
> > back up and continue as if nothing happened !!!  I literally peed  in
> my pants !!!
> > Probably everyone in Atlanta could hear me...NO !!!  Thinking
> > of all the network signons with Visa and Mastercard...all the credit
> > card Authorizations...there was absolutely zero chance of this working
> > without issues.
> >
> > Well, came in Monday morning after receiving no calls over the
> > week-end everything was fine.  We ran the Batch Monday night...and
> > that would be pulling in transactions from over the week-end from DR
> site.
> > NO ISSUES !!!   Everything was fine.
> >
> > Whoever did this, from a Systems perspectiveI tip my hat.  I've
> > never seen someone do this with Production, but it worked fine...so
> > what do I know.  Never seen anyone else do this in my 42 years of
> > Mainframing either.
> >
> > Unfortunately, Halifax/Bank of Scotland is no longer with us.  They
> > were absorbed by Lloyds Banking Group.
> >
> >
> > Thanks,
> > Tom Savor
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > ::DISCLAIMER::
> > 

Re: DEQ dynamically

[Vernooij, Kees (ITOP NM) - KLM]

Where does the term 'reference count' come from? If the initiator deallocates a 
dataset, either because of step-end or because of FREE with CLOSE, it dequeues 
the dataset if no subsequent step needs the dataset anymore.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 11 February, 2019 22:14
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> On Mon, 11 Feb 2019 20:15:29 +, Seymour J Metz wrote:
> 
> >Only if the job doesn't have a subsequent step with a DD for the same
> dataset.
> >
> Why?  I never did a DYNALLOC ALLOCATE; only a FREE, and that should set
> the reference count to 0.
> 
> Or does the reference count count each step mentioning the DSN?
> 
> (This is much messier nowadays that it's possible to downgrade an ENQ.)
> 
> >
> >From: IBM Paul Gilmartin
> >Sent: Monday, February 11, 2019 2:54 PM
> >
> >On Mon, 11 Feb 2019 16:40:49 +, Seymour J Metz wrote:
> >>
> >>BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC
> (SVC 99) as any other allocation.
> >>
> >>GRS maintains a global reference count for any resource, not just
> SYSDSN.
> >>
> >Does that imply that if I have a DSN allocated by a JCL DD statement
> and I do a
> >DYNALLOC FREE, the count becomes 0 and the DSN is immediately available
> to
> >other jobs?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Vernooij, Kees (ITOP NM) - KLM]

I wonder: can I deallocate a dataset with DYNALLOC, that has been allocated by 
the initiator because there is a DD statement?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 11 February, 2019 21:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> Only if the job doesn't have a subsequent step with a DD for the same
> dataset.
> 
> 
> --
> 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: Monday, February 11, 2019 2:54 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> On Mon, 11 Feb 2019 16:40:49 +, Seymour J Metz wrote:
> >
> >BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC
> (SVC 99) as any other allocation.
> >
> >GRS maintains a global reference count for any resource, not just
> SYSDSN.
> >
> Does that imply that if I have a DSN allocated by a JCL DD statement and
> I do a
> DYNALLOC FREE, the count becomes 0 and the DSN is immediately available
> to
> other jobs?
> 
> -- 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

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: DEQ dynamically

[Vernooij, Kees (ITOP NM) - KLM]

AFAIK either the initiator does the ENQ (when there is a DD statement) OR 
dynamic allocation does the ENQ (when the code does a DYNALLOC). The same 
applies to the DEQ.

To avoid deadlocks the initiator does all ENQs ahead before starting the job. 
DYNALLOC returns "not available" when another task/job has the ENQ. This is 
often forgotten by REXX/CLIST and SAS coders, who assume they will get the 
dataset, when they allocate it dynamically.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 11 February, 2019 17:41
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> When the Initiator frees a dataset and no subsequent step has a DD for
> it, the Initiator does a DEQ. If there is a subsequent dynamic
> allocation, then the Initiator does a new ENQ; there's always a
> possibility that some other job will get there first.
> 
> BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC
> 99) as any other allocation.
> 
> GRS maintains a global reference count for any resource, not just
> SYSDSN.
> 
> 
> --
> 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: Monday, February 11, 2019 11:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> On Mon, 11 Feb 2019 06:43:14 -0600, John McKown wrote:
> >
> >One thing that I sometimes do is include a FREE=CLOSE on a DD if I am
> >certain that the application will only read if once, say at start up,
> for
> >configuration information.
> >
> How does that work if a subsequent job step contains a DD statement for
> the same DSN?
> 
> I would guess that the control blocks for the job step (TIOT? JFCB?) are
> cleaned up but the initiator continues to hold the ENQ.
> 
> Or just a JCL error?
> 
> And something similar should apply to a BPXWDYN('free') of a DSN
> allocated
> by JCL.
> 
> And if a program redundantly ALLOCATEs then FREEs a DSN allocated in
> JCL?  Does GRS maintain a reference count of the ENQ QHAME/RNAME?
> 
> -- 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

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

[Mike Schwab]

As soon as you start production at the DR site, you need to start
replication to your next site (production or third site).
If you have a clean shutdown and the mirroring software supports it,
you might be able to swap primary and secondary to avoid having to
copy the volumes.

On Mon, Feb 11, 2019 at 9:06 PM Jesse 1 Robinson
 wrote:
>
> Sorry Mike. That's what management seems to believe. It's what we've done for 
> TWENTY years. It allows us to fail over to the 'DR site' at will. Including 
> for-real failover where DR becomes the day-to-day home from then on. That's 
> not the hard part. The hard part is that after failover, production now lives 
> at the DR site, yet it's officially temporary. All new REAL customer data now 
> lives over the hill and through the woods, not at home.
>
> -- 1000's of volumes/UCBs worth of data that is suddenly obsolete 'at home' 
> and therefore useless.
>
> -- A GDPS mapping of all prod volumes to DR secondary volumes.
>
> -- A GDPS mapping of all secondary volumes to tertiary volumes, which we 
> actually IPL from. If we IPL'ed and ran with secondary volumes, mirroring 
> would be destroyed until we resynched.
>
>  -- We're under the gun to move back 'home' with some alacrity because two 
> CECs are required for CF redundancy. DR has only one CEC for economy.
>
> 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.
>
> .
> .
> 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 Mike Schwab
> Sent: Monday, February 11, 2019 5:03 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
>
> Mirroring the DASD to the backup site.
>
> On Mon, Feb 11, 2019 at 4:50 PM Jesse 1 Robinson  
> wrote:
> >
> > I have nothing but admiration for a shop that can slosh workload back and 
> > forth between two data centers. There are those that can and those (like 
> > us) that cannot. How does one get from the first group into the second?
> >
> > .
> > .
> > 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 Vernooij, Kees (ITOP NM) - KLM
> > Sent: Monday, February 11, 2019 5:58 AM
> > 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
> >
> > We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the 
> > other site, a CF in both sites and Dasd mirrored between the sites.
> > Our DRP consists of moving workload from 1 site's LPARs to the 
> > corresponding LPARs in the other site and adding capacity b.m.o. CBUs. No 
> > manipulation of LPARs.
> > We do this from time to time, sometimes as part of a DRP test, recently 
> > also because of a potentially disastrous power maintenance in a site.
> > A piece of cake, compared to the comments I read above.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller
> > > Sent: 11 February, 2019 14:30
> > > 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
> > >
> > > I have heard of a company in the Far East the periodically (every 6
> > > mths., IIRC) flips from site A to site B (and back).
> > > Aus(?) to Phillipines ?) and back.
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Savor, Thomas (Alpharetta)
> > > Sent: Friday, February 8, 2019 7:08 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
> > >
> > > >We've been doing DR mirroring for 20 years. It gets tested often.
> > > >We've
> > > moved production twice to another >data center using our procedures.
> > > What we've never done is run production in another location
> > > >temporarily. 'Temporary' means move it, run it until at least one
> > > transaction is committed, then move it >*all* back. That is hugely
> > > complex and costly.
> > >
> > > >A lot of management fantasizes about a big A-B switch that we throw
> > > >one
> > > way or the other. So wrong.
> > >
> > > About 5-6 years ago, I was working as a vendor (Daily Support) for
> > > Credit Card Software for 

Re: Hmc for z as a virtual appliance?

[Timothy Sipples]

Seymour Metz wrote:
>Another issue is whether an application that communicates with a remote
>HMC would have model dependencies and, if so, what models to test against.

Yes, agreed, that's possible. There can also be slight differences after
the HMC receives a code update.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Jesse 1 Robinson]

Sorry Mike. That's what management seems to believe. It's what we've done for 
TWENTY years. It allows us to fail over to the 'DR site' at will. Including 
for-real failover where DR becomes the day-to-day home from then on. That's not 
the hard part. The hard part is that after failover, production now lives at 
the DR site, yet it's officially temporary. All new REAL customer data now 
lives over the hill and through the woods, not at home. 

-- 1000's of volumes/UCBs worth of data that is suddenly obsolete 'at home' and 
therefore useless. 

-- A GDPS mapping of all prod volumes to DR secondary volumes.   

-- A GDPS mapping of all secondary volumes to tertiary volumes, which we 
actually IPL from. If we IPL'ed and ran with secondary volumes, mirroring would 
be destroyed until we resynched. 

 -- We're under the gun to move back 'home' with some alacrity because two CECs 
are required for CF redundancy. DR has only one CEC for economy.  

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. 

.
.
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 Mike Schwab
Sent: Monday, February 11, 2019 5:03 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

Mirroring the DASD to the backup site.

On Mon, Feb 11, 2019 at 4:50 PM Jesse 1 Robinson  
wrote:
>
> I have nothing but admiration for a shop that can slosh workload back and 
> forth between two data centers. There are those that can and those (like us) 
> that cannot. How does one get from the first group into the second?
>
> .
> .
> 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 Vernooij, Kees (ITOP NM) - KLM
> Sent: Monday, February 11, 2019 5:58 AM
> 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
>
> We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the 
> other site, a CF in both sites and Dasd mirrored between the sites.
> Our DRP consists of moving workload from 1 site's LPARs to the corresponding 
> LPARs in the other site and adding capacity b.m.o. CBUs. No manipulation of 
> LPARs.
> We do this from time to time, sometimes as part of a DRP test, recently also 
> because of a potentially disastrous power maintenance in a site.
> A piece of cake, compared to the comments I read above.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller
> > Sent: 11 February, 2019 14:30
> > 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
> >
> > I have heard of a company in the Far East the periodically (every 6 
> > mths., IIRC) flips from site A to site B (and back).
> > Aus(?) to Phillipines ?) and back.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Savor, Thomas (Alpharetta)
> > Sent: Friday, February 8, 2019 7:08 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
> >
> > >We've been doing DR mirroring for 20 years. It gets tested often.
> > >We've
> > moved production twice to another >data center using our procedures.
> > What we've never done is run production in another location
> > >temporarily. 'Temporary' means move it, run it until at least one
> > transaction is committed, then move it >*all* back. That is hugely 
> > complex and costly.
> >
> > >A lot of management fantasizes about a big A-B switch that we throw 
> > >one
> > way or the other. So wrong.
> >
> > About 5-6 years ago, I was working as a vendor (Daily Support) for 
> > Credit Card Software for Halifax/Bank of Scotland.  I believe the 
> > first time I was given a "heads up" was when we were supporting 12 
> > Million Cardholders.  The "Heads up" was that on Friday evening at 
> > 6pm Main site was going to shut down and the whole weekend 
> > PRODUCTION was going to run on DR site, then 6am Monday Morning, 
> > Main site is to come back up and continue as if nothing happened !!!  I 
> > literally peed  in my pants !!!
> > Probably everyone in Atlanta could hear me...NO !!!  
> > Thinking of all the 

Re: Tape Mount Management

[Russell Witt]

As Kees has already mentioned; if you want to add chargeback for tape - that is 
easy. I know that both the CA MICS product and the MXG product both have 
interfaces to CA 1 and CA TLMS to gather information on how much data has been 
stored on tape (and how long that data has resided on tape). And with both CA 1 
and CA TLMS we keep track (for Virtual Tape users) of both "how much data did 
the application write" and "how much cache was used" (basically, before and 
after compression). And it is more than just block-count times block-size like 
in the olden days. 

Sounds like you simply need to have your chargeback system start to interface 
to your tape management system.

Russell Witt
CA 1 Development

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Benik, John E
Sent: Thursday, January 31, 2019 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tape Mount Management

Thank you for all the feedback.  Even though we are all virtual tape, I am 
under the impression that not all the data residing on tape should be.  Yes 
it's virtual and therefore disk, but many of the JCL used today is old and 
since there is no chargeback for tape, users continue to write their data to 
tape.  I am looking into this to help determine where the data should reside.  
The best will probably be looking at smaller tapes and having those go to disk 
instead.  I'm thinking starting with 50 MB.  



John Benik | Optum
Senior Systems Management Analyst  – Mainframe Storage, Network Hosting 
Services Optum Technology
12125 Technology Drive
Eden Prairie, MN 55344

O) 1-952-833-7765
C) 1-612-616-3984



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, January 30, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Tape Mount Mangement

On Wed, 30 Jan 2019 17:30:34 +0100, R.S. wrote:
>
>My other impression is it's simpler to change gazillion (usually less) 
>of JCL jobs to explicitly point datasets to DASD than using TMM.
>
Might a JCLLIB member that SETs a few JCL symbols facilitate this?
Reduce a gazillion to a handful?  Nowadays JCL symbols can even be resolved in 
SYSIN.

>Of course virtual tape reliefs many pains of tape, but keeping things 
>in old way is not good for the future.
> 
IBM sometimes seems to have the opposite impression.  "Compatibility".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail, including attachments, may include confidential and/or proprietary 
information, and may be used only by the person or entity to which it is 
addressed. If the reader of this e-mail is not the intended recipient or his or 
her authorized agent, the reader is hereby notified that any dissemination, 
distribution or copying of this e-mail is prohibited. If you have received this 
e-mail in error, please notify the sender by replying to this message and 
delete this e-mail immediately.


--
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

IBM Cloud Private 3.1.2 Adds Full "Manage From" Support

[Timothy Sipples]

Crossposted to IBM-MAIN and LINUX-390.

This feature I'm describing has been available in beta form for a few
months now, but I'd like to draw your attention to IBM Cloud Private
Version 3.1.2 which was released a couple days ago. Version 3.1.2 includes
official support for "manage from" Linux on IBM Z and LinuxONE. That is,
you can now create and run an entire Docker- and Kubernetes-based cloud
environment, including all management-related nodes, on one IBM Z or
LinuxONE server. Alternatively, you can create and deploy a hybrid cloud
across multiple servers (wherever they're located) and with all the cloud
services managed from IBM Cloud Private for Linux on IBM Z or LinuxONE.

Yes, you can download and use IBM Cloud Private Community Edition at no
charge, including for Linux on IBM Z and LinuxONE systems. The IBM Cloud
Private Version 3.1.2 Community Edition is available from Docker Hub, or at
least it shortly will be whenever the next Docker Hub "push" occurs. If the
Community Edition is all you need, great, enjoy! If you'd like formal IBM
support (to open PMRs, etc.) and/or the additional runtimes and
capabilities (such as management node high availability) provided in other
IBM Cloud Private editions, those are available for purchase if you wish.
You can purchase monthly IBM Cloud Private licenses with monthly support or
perpetual licenses with annual, renewable support and subscription, as you
prefer, so it's all very flexible.

IBM Secure Service Container for IBM Cloud Private for Linux on Z and
LinuxONE adds uniquely strong security protections to cloud deployments.
However, even in IBM Cloud Private Community Edition you can exploit
certain special security features, notably TLS/SSL network encryption that
leverages IBM Crypto Express hardware security modules (HSMs) and their
uniquely strong key protections.

If you have z/OS and/or z/VM, you can tap into their cloud provisioning
capabilities using z/OS Cloud Provisioning and Management and the z/VM
Cloud Connector, respectively. Those particular features are available
with/for the base operating systems at no additional charge. I'll need more
than a couple sentences to explain how that all works, but that'll probably
be a topic for another, future post.

IBM Cloud Private Version 3.1.2 highlights are described here:

https://www.ibm.com/developerworks/community/blogs/fe25b4ef-ea6a-4d86-a629-6f87ccf4649e/entry/IBM_Cloud_Private_Version_3_1_2_is_available?lang=en

The main landing page for IBM Cloud Private for Linux on IBM Z and LinuxONE
is here:

https://www.ibm.com/us-en/marketplace/cloud-private-on-z-and-linuxone

Have fun!


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Mike Schwab]

Mirroring the DASD to the backup site.

On Mon, Feb 11, 2019 at 4:50 PM Jesse 1 Robinson
 wrote:
>
> I have nothing but admiration for a shop that can slosh workload back and 
> forth between two data centers. There are those that can and those (like us) 
> that cannot. How does one get from the first group into the second?
>
> .
> .
> 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 Vernooij, Kees (ITOP NM) - KLM
> Sent: Monday, February 11, 2019 5:58 AM
> 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
>
> We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the 
> other site, a CF in both sites and Dasd mirrored between the sites.
> Our DRP consists of moving workload from 1 site's LPARs to the corresponding 
> LPARs in the other site and adding capacity b.m.o. CBUs. No manipulation of 
> LPARs.
> We do this from time to time, sometimes as part of a DRP test, recently also 
> because of a potentially disastrous power maintenance in a site.
> A piece of cake, compared to the comments I read above.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Allan Staller
> > Sent: 11 February, 2019 14:30
> > 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
> >
> > I have heard of a company in the Far East the periodically (every 6
> > mths., IIRC) flips from site A to site B (and back).
> > Aus(?) to Phillipines ?) and back.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Savor, Thomas (Alpharetta)
> > Sent: Friday, February 8, 2019 7:08 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
> >
> > >We've been doing DR mirroring for 20 years. It gets tested often.
> > >We've
> > moved production twice to another >data center using our procedures.
> > What we've never done is run production in another location
> > >temporarily. 'Temporary' means move it, run it until at least one
> > transaction is committed, then move it >*all* back. That is hugely
> > complex and costly.
> >
> > >A lot of management fantasizes about a big A-B switch that we throw
> > >one
> > way or the other. So wrong.
> >
> > About 5-6 years ago, I was working as a vendor (Daily Support) for
> > Credit Card Software for Halifax/Bank of Scotland.  I believe the
> > first time I was given a "heads up" was when we were supporting 12
> > Million Cardholders.  The "Heads up" was that on Friday evening at 6pm
> > Main site was going to shut down and the whole weekend PRODUCTION was
> > going to run on DR site, then 6am Monday Morning, Main site is to come
> > back up and continue as if nothing happened !!!  I literally peed  in my 
> > pants !!!
> > Probably everyone in Atlanta could hear me...NO !!!  Thinking
> > of all the network signons with Visa and Mastercard...all the credit
> > card Authorizations...there was absolutely zero chance of this working
> > without issues.
> >
> > Well, came in Monday morning after receiving no calls over the
> > week-end everything was fine.  We ran the Batch Monday night...and
> > that would be pulling in transactions from over the week-end from DR site.
> > NO ISSUES !!!   Everything was fine.
> >
> > Whoever did this, from a Systems perspectiveI tip my hat.  I've
> > never seen someone do this with Production, but it worked fine...so
> > what do I know.  Never seen anyone else do this in my 42 years of
> > Mainframing either.
> >
> > Unfortunately, Halifax/Bank of Scotland is no longer with us.  They
> > were absorbed by Lloyds Banking Group.
> >
> >
> > Thanks,
> > Tom Savor
> >
> > --
> > 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 

Re: Wells Fargo? Well f*&%#d at the moment: Data center up in smoke, bank website, app down . The Register

[Jesse 1 Robinson]

I have nothing but admiration for a shop that can slosh workload back and forth 
between two data centers. There are those that can and those (like us) that 
cannot. How does one get from the first group into the second?

.
.
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 Vernooij, Kees (ITOP NM) - KLM
Sent: Monday, February 11, 2019 5:58 AM
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

We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the other 
site, a CF in both sites and Dasd mirrored between the sites.
Our DRP consists of moving workload from 1 site's LPARs to the corresponding 
LPARs in the other site and adding capacity b.m.o. CBUs. No manipulation of 
LPARs.
We do this from time to time, sometimes as part of a DRP test, recently also 
because of a potentially disastrous power maintenance in a site.
A piece of cake, compared to the comments I read above.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Allan Staller
> Sent: 11 February, 2019 14:30
> 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
> 
> I have heard of a company in the Far East the periodically (every 6 
> mths., IIRC) flips from site A to site B (and back).
> Aus(?) to Phillipines ?) and back.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Savor, Thomas (Alpharetta)
> Sent: Friday, February 8, 2019 7:08 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
> 
> >We've been doing DR mirroring for 20 years. It gets tested often. 
> >We've
> moved production twice to another >data center using our procedures.
> What we've never done is run production in another location
> >temporarily. 'Temporary' means move it, run it until at least one
> transaction is committed, then move it >*all* back. That is hugely 
> complex and costly.
> 
> >A lot of management fantasizes about a big A-B switch that we throw 
> >one
> way or the other. So wrong.
> 
> About 5-6 years ago, I was working as a vendor (Daily Support) for 
> Credit Card Software for Halifax/Bank of Scotland.  I believe the 
> first time I was given a "heads up" was when we were supporting 12 
> Million Cardholders.  The "Heads up" was that on Friday evening at 6pm 
> Main site was going to shut down and the whole weekend PRODUCTION was 
> going to run on DR site, then 6am Monday Morning, Main site is to come 
> back up and continue as if nothing happened !!!  I literally peed  in my 
> pants !!!
> Probably everyone in Atlanta could hear me...NO !!!  Thinking 
> of all the network signons with Visa and Mastercard...all the credit 
> card Authorizations...there was absolutely zero chance of this working 
> without issues.
> 
> Well, came in Monday morning after receiving no calls over the 
> week-end everything was fine.  We ran the Batch Monday night...and 
> that would be pulling in transactions from over the week-end from DR site.
> NO ISSUES !!!   Everything was fine.
> 
> Whoever did this, from a Systems perspectiveI tip my hat.  I've 
> never seen someone do this with Production, but it worked fine...so 
> what do I know.  Never seen anyone else do this in my 42 years of 
> Mainframing either.
> 
> Unfortunately, Halifax/Bank of Scotland is no longer with us.  They 
> were absorbed by Lloyds Banking Group.
> 
> 
> Thanks,
> Tom Savor
> 
> --
> 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 

Re: How can I get reports in the Output Queue in SDSF to print

[McCabe, Ron]

Vince,

I do not know what is on port 3603 on z/VM and I don't know how to find out 
what is there.  I got the Query NODE/LINE commands to work after you pointed 
out that they are RSCS commands...I kept trying to run them from TCPMAINT.

When I start the LINK from z/VM and then very quickly start it from z/OS, z/OS 
responds with that it is already started.

I sent the last requested trace / SVC dump to IBM support late Friday...I'm 
hoping to hear something today but it was a very large trace/dump so I would 
not be surprised if I do not hear anything until tomorrow.

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vince Getgood
Sent: Monday, February 11, 2019 2:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I get reports in the Output Queue in SDSF to print

Ron,
You have an established session from JES's Netserv to z/VM -

EZZ2587I JES2S001 7D6F 10.100.5.71..175   10.100.5.73..3603  
Establsh

(What's at port 3603 on z/VM btw?)

Your start link looks successful, both on z/VM & z/OS - that seems to suggest 
that the network is ok.

The QUERY LINK and QUERY NODE commands are RSCS commands, not "normal" z/VM 
commands - sorry.

I'd try the start link again, and very quickly after, issue the $SN,N=your z/VM 
node number (or $SN,SOCKET=your z/VM socket number) on the z/OS system.  You 
need to get nje networking er, working, before anything else.

Let me know the outcome.

What have IBM come up with?

--
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: DEQ dynamically

[Paul Gilmartin]

On Mon, 11 Feb 2019 20:15:29 +, Seymour J Metz wrote:

>Only if the job doesn't have a subsequent step with a DD for the same dataset.
> 
Why?  I never did a DYNALLOC ALLOCATE; only a FREE, and that should set
the reference count to 0.

Or does the reference count count each step mentioning the DSN?

(This is much messier nowadays that it's possible to downgrade an ENQ.)

>
>From: IBM Paul Gilmartin 
>Sent: Monday, February 11, 2019 2:54 PM
>
>On Mon, 11 Feb 2019 16:40:49 +, Seymour J Metz wrote:
>>
>>BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC 99) 
>>as any other allocation.
>>
>>GRS maintains a global reference count for any resource, not just SYSDSN.
>>
>Does that imply that if I have a DSN allocated by a JCL DD statement and I do a
>DYNALLOC FREE, the count becomes 0 and the DSN is immediately available to
>other jobs?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Seymour J Metz]

Only if the job doesn't have a subsequent step with a DD for the same dataset.


--
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: Monday, February 11, 2019 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DEQ dynamically

On Mon, 11 Feb 2019 16:40:49 +, Seymour J Metz wrote:
>
>BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC 99) 
>as any other allocation.
>
>GRS maintains a global reference count for any resource, not just SYSDSN.
>
Does that imply that if I have a DSN allocated by a JCL DD statement and I do a
DYNALLOC FREE, the count becomes 0 and the DSN is immediately available to
other jobs?

-- 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: What is the bit that causes the bypassing of dataset ENQ

[Seymour J Metz]

That's only available if you're authorized.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Sunday, February 10, 2019 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the bit that causes the bypassing of dataset ENQ

A kind soul offline points out S99NORES.

(No wonder I couldn't find it in the TCB.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, February 10, 2019 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What is the bit that causes the bypassing of dataset ENQ

IIRC there is a bit that causes dataset allocation to bypass the normal ENQ.
It is used, for example, by backup programs.



Can anyone share the name of the bit flag? I searched TCB, ASCB and JSCB.



Don't worry, I'm not going to use it willy-nilly. I'm not going to code it
at all. It is for a presentation I am putting together.



Thanks,

Charles




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Hmc for z as a virtual appliance?

[Seymour J Metz]

Another issue is whether an application that communicates with a remote HMC 
would have model dependencies and, if so, what models to test against.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Sunday, February 10, 2019 9:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmc for z as a virtual appliance?

Mike Schwab:
>What serial number does he use if he doesn't have a z## processor?
>He only wants to test with the HMC.

There's another important question, a technical question: how does he plug
an IBM Z/IBM LinuxONE Hardware Management Console (HMC) into a ZPDT?
Answer: He doesn't. The ZPDT does not provide any connectivity for a HMC.

So, to answer your question: if he wants a HMC, he will use an IBM Z or IBM
LinuxONE machine that he buys, leases, or (if someone is willing) borrows.
As the ZPDT redbook carefully explains, the ZPDT simply does not provide or
support a Hardware Management Console. To develop for, to test, and/or to
use a HMC, you need a HMC...a feature of IBM Z and IBM LinuxONE machines,
probably an IBM Z machine in this case since some HMC functions are only
associated with IBM Z machines.

There's no game or marketing trick here. The HMC cannot get anything done
without an IBM Z or IBM LinuxONE machine and all that it provides,
including the physical and logical interfaces that the HMC relies on.

IBM offers several IBM Z Trial Programs here:

https://secure-web.cisco.com/1n0nki2vDdfIMn0AJ9tkIljxphg-omyO8mbM-82CIWKJRdJqmNxtH0O6Zrik2oMl0NSx7VgpSYs20BUZ2uIsL0Pigfub8pAO00C17ybDBs-hF3O17CF2QH5_KCOx365Gb8E2x0fp6TG7uWZJvFQ1MCnAKbkH3K_SF7oF-FSWVDDjcXMA2QqDr5TiXUnBIj56vkeVtZNqXbnh30y8anNXxLqYEePUaSTvCJEBRLCoNydNtwCXFQO8KbvM0bM4NEIQSaikwOUUOp2LHBExHoQKnCAglPaGciR4Vz9PM69X6eih1wEJBZVjCAE-xXMNxCEW2LnAev5Y7hMGHiPo3EYeW5tkUKOWHK2QOa_YYKR2DOvHrNJZ3hjR4RbO212nddOeCdtaWmdO4JUfaJB_i3YSmM6yr7lBTBZEE6llHWTqI6DWvAnA6bC03izRRm6erXapW/https%3A%2F%2Fwww.ibm.com%2Fit-infrastructure%2Fz%2Fresources%2Ftrial

If someone would like to put in a formal request (via RFE) for a Remote HMC
trial, I don't see any problem in asking. I have no idea how IBM would
respond to such a request, and I don't know if it's technically viable, but
it doesn't hurt to ask.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Seymour J Metz]

An application can generally deallocate any dataset that it is not using. If 
you want to deallocate a dataset from some other address space, drop that 
keyboard and surrender.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Jake Anderson 
Sent: Sunday, February 10, 2019 11:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DEQ dynamically

Hi

Is it possible to deallocate a dataset without recycling address space.

The dataset is users one and for some reason I would like to know if we can
Dynamically remove it from allocation


Jake

--
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

[Paul Gilmartin]

On Mon, 11 Feb 2019 16:40:49 +, Seymour J Metz wrote:
>
>BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC 99) 
>as any other allocation.
>
>GRS maintains a global reference count for any resource, not just SYSDSN.
> 
Does that imply that if I have a DSN allocated by a JCL DD statement and I do a
DYNALLOC FREE, the count becomes 0 and the DSN is immediately available to
other jobs?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the bit that causes the bypassing of dataset ENQ

[Charles Mills]

I did not recall the exact operation of the bit flag. If I'd recalled that it 
was an SVC 99 flag rather than some sort of global flag I might well have found 
it myself.

Why criticize people for asking a question? If they knew the answer they would 
not have to ask the question -- 'tis true.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Sunday, February 10, 2019 6:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the bit that causes the bypassing of dataset ENQ

On Sun, 10 Feb 2019 14:08:15 -0800, Charles Mills  wrote:

>A kind soul offline points out S99NORES.
>
>(No wonder I couldn't find it in the TCB.)

It also would have helped if you'd said you were interested in -dynamic- data 
set allocation, rather than simply data set allocation. It changes the answer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Seymour J Metz]

When the Initiator frees a dataset and no subsequent step has a DD for it, the 
Initiator does a DEQ. If there is a subsequent dynamic allocation, then the 
Initiator does a new ENQ; there's always a possibility that some other job will 
get there first.

BPXWDYN is just a fron end; ultimately it goes to the same DYNALLOC (SVC 99) as 
any other allocation.

GRS maintains a global reference count for any resource, not just SYSDSN.


--
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: Monday, February 11, 2019 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DEQ dynamically

On Mon, 11 Feb 2019 06:43:14 -0600, John McKown wrote:
>
>One thing that I sometimes do is include a FREE=CLOSE on a DD if I am
>certain that the application will only read if once, say at start up, for
>configuration information.
>
How does that work if a subsequent job step contains a DD statement for
the same DSN?

I would guess that the control blocks for the job step (TIOT? JFCB?) are
cleaned up but the initiator continues to hold the ENQ.

Or just a JCL error?

And something similar should apply to a BPXWDYN('free') of a DSN allocated
by JCL.

And if a program redundantly ALLOCATEs then FREEs a DSN allocated in
JCL?  Does GRS maintain a reference count of the ENQ QHAME/RNAME?

-- 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

[John McKown]

On Mon, Feb 11, 2019 at 10:13 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 11 Feb 2019 06:43:14 -0600, John McKown wrote:
> >
> >One thing that I sometimes do is include a FREE=CLOSE on a DD if I am
> >certain that the application will only read if once, say at start up, for
> >configuration information.
> >
> How does that work if a subsequent job step contains a DD statement for
> the same DSN?
>
> I would guess that the control blocks for the job step (TIOT? JFCB?) are
> cleaned up but the initiator continues to hold the ENQ.
>
> Or just a JCL error?
>
> And something similar should apply to a BPXWDYN('free') of a DSN allocated
> by JCL.
>
> And if a program redundantly ALLOCATEs then FREEs a DSN allocated in
> JCL?  Does GRS maintain a reference count of the ENQ QHAME/RNAME?
>
> -- gil
>

Excellent questions! I was blinded by an assumption that the address space
was a single step started task.


-- 
I just burned 2000 calories!
That's the last time I'll nap with brownies in the oven.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Paul Gilmartin]

On Mon, 11 Feb 2019 06:43:14 -0600, John McKown wrote:
>
>One thing that I sometimes do is include a FREE=CLOSE on a DD if I am
>certain that the application will only read if once, say at start up, for
>configuration information.
> 
How does that work if a subsequent job step contains a DD statement for
the same DSN?

I would guess that the control blocks for the job step (TIOT? JFCB?) are
cleaned up but the initiator continues to hold the ENQ.

Or just a JCL error?

And something similar should apply to a BPXWDYN('free') of a DSN allocated
by JCL.

And if a program redundantly ALLOCATEs then FREEs a DSN allocated in
JCL?  Does GRS maintain a reference count of the ENQ QHAME/RNAME?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

SYSSTATE (was Abend 052-512)

[Peter Relson]

(Everyone should do this)

Help the poor macros out. Tell them via SYSSTATE OSREL and ARCHLVL what 
the macros are allowed to assume.
Unless you like lousy code.

The XM services were written when non-stacking PCs were the only thing 
available and the interface for non-stacking PC requires various hoops to 
be jumped through. But those PC's were changed to stacking many releases 
ago (z/OS 1.6). 

For the most part we try not to assume things about what release you might 
be running your code on, and thus the default remains to expand the way it 
originally did. But you almost always know better. Share that information. 
Unless you like extra STM, ESAR, SSAR, LM in your expansions. At a 
minimum, pick the oldest release your code might run on. If that oldest 
release is older than z/OS 1.6, perhaps you could consider changing your 
business model.

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: DEQ dynamically

[Elardus Engelbrecht]

Jake Anderson wrote:

>Is it possible to deallocate a dataset without recycling address space.

Why? What are you trying to solve? Or, rather, what are you trying to break?

In short - no. You stop the application [1].


>The dataset is users one and for some reason I would like to know if we can 
>Dynamically remove it from allocation.

Stop the holder of that dataset and upon cleanup the dataset will be released 
by the system.

Use D GRS command or ENQ in ISRDDN to see who is holding your dataset and how. 
Then you stop these ENQ holders.

As others said about FREE=CLOSE, in REXX you do a ALLOC, do stuff, then a FREE.

As others said, perhaps (?) with an APF-ed program standing outside the ENQ 
holder address space, you can do 'tricks' at your own career ending peril and 
serious data loss.

Groete / Greetings
Elardus Engelbrecht

[1] - Or you give a command (if so programmed in the first place of course, say 
in a menu item or inside the program logic) to do a FREE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Lizette Koehler]

So it will depend on what Address space "owns" the dataset.

If CICS, then there are vendor tools to close and open files to CICS.

Please provide a little more detail on what "owns" the file.

If the address space was not written to allow dynamic allocation/deallocation 
of a file, then you will need to see how to accomplish that.

If it is a vendor product, contact the vendor

If it is a home grown process, review the code to see if what you want can be 
incorporated into the function.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Jake Anderson
> Sent: Sunday, February 10, 2019 9:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DEQ dynamically
> 
> Hi
> 
> Is it possible to deallocate a dataset without recycling address space.
> 
> The dataset is users one and for some reason I would like to know if we can
> Dynamically remove it from allocation
> 
> 
> Jake
> 

--
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

[Vernooij, Kees (ITOP NM) - KLM]

Yes sure: Weights, Defined Capacities and Group Capacities. 
And all done automated by SA, after one push on the button: change LPAR 
controls, activate CBU, move workloads.
LPAR memory etc. are sufficient to take the combined load, but we have defined 
reserved memory just in case.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 11 February, 2019 15:07
> 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
> 
> Kees, I would hope that - as part of adding the capacity - you adjust
> LPAR
> definitions, especially weights. Even if that is a "null" adjustment.
> 
> Cheers, Martin
> 
> Martin Packer
> 
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
> or
> 
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
> 
> 
> Youtube channel:
> https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> 
> 
> 
> From:   "Vernooij, Kees (ITOP NM) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   11/02/2019 13:59
> 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 
> 
> 
> 
> We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the
> other site, a CF in both sites and Dasd mirrored between the sites.
> Our DRP consists of moving workload from 1 site's LPARs to the
> corresponding LPARs in the other site and adding capacity b.m.o. CBUs.
> No
> manipulation of LPARs.
> We do this from time to time, sometimes as part of a DRP test, recently
> also because of a potentially disastrous power maintenance in a site.
> A piece of cake, compared to the comments I read above.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of Allan Staller
> > Sent: 11 February, 2019 14:30
> > 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
> >
> > I have heard of a company in the Far East the periodically (every 6
> > mths., IIRC) flips from site A to site B (and back).
> > Aus(?) to Phillipines ?) and back.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf
> > Of Savor, Thomas (Alpharetta)
> > Sent: Friday, February 8, 2019 7:08 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
> >
> > >We've been doing DR mirroring for 20 years. It gets tested often.
> We've
> > moved production twice to another >data center using our procedures.
> > What we've never done is run production in another location
> > >temporarily. 'Temporary' means move it, run it until at least one
> > transaction is committed, then move it >*all* back. That is hugely
> > complex and costly.
> >
> > >A lot of management fantasizes about a big A-B switch that we throw
> one
> > way or the other. So wrong.
> >
> > About 5-6 years ago, I was working as a vendor (Daily Support) for
> > Credit Card Software for Halifax/Bank of Scotland.  I believe the
> first
> > time I was given a "heads up" was when we were supporting 12 Million
> > Cardholders.  The "Heads up" was that on Friday evening at 6pm Main
> site
> > was going to shut down and the whole weekend PRODUCTION was going to
> run
> > on DR site, then 6am Monday Morning, Main site is to come back up and
> > continue as if nothing happened !!!  I literally peed  in my pants !!!
> > Probably everyone in Atlanta could hear me...NO !!!  Thinking
> of
> > all the network signons with Visa and Mastercard...all the credit card
> > Authorizations...there was absolutely zero chance of this working
> > without issues.
> >
> > Well, came in Monday morning after receiving no calls over the week-
> end
> > everything was fine.  We ran the Batch Monday night...and that
> would
> > be pulling in transactions from over the week-end from DR site.
> > NO ISSUES !!!   Everything was fine.
> >
> > Whoever did this, from a Systems perspectiveI tip my hat.  I've
> > never seen someone do this with Production, but it worked fine...so
> what
> > do I know.  Never seen anyone else do this in my 42 years of
> Mainframing
> > either.
> >
> > Unfortunately, Halifax/Bank of Scotland is no longer with us.  They
> were
> > absorbed by Lloyds Banking Group.
> >
> >
> > Thanks,
> > Tom Savor
> >
> > --
> 

Re: General question about toleration maintenance

[Tom Marchant]

On Sat, 9 Feb 2019 20:04:20 -0600, Joel C. Ewing wrote:

>Normally "Toleration PTF" is a term used for a PTF for version A of a
>product to keep it from going bonkers when it sees some construct
>introduced by new feature in a  later version B of the same product. 

That is one form of toleration PTF. Another is a PTF to a third party 
product so that it will work with a new release of the operating system 
or of some other product, for example, a compiler. Yet another is so 
that the product will be able to run in the presence of new hardware.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday history query

[Bill Ogden]

In the old IBM, "GEM" was Government, Education, Medical. 

Bill Ogden


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday history query

[Pew, Curtis G]

On Feb 10, 2019, at 10:02 PM, Timothy Sipples 
mailto:sipp...@sg.ibm.com>> wrote:

I'll guess the letter relates in some way to the IBM Data Processing
Division's Government, Education and Medical (GEM) Region. The GEM Region
was an IBM sales and marketing organization for about five years from 1966
to 1971. It catered to IBM customers in those industries and was
headquartered in Washington, D.C.

I sent some possible GEM Region-related leads to Curtis offline.


Thanks so much. I’m pretty sure this is the answer; I know that, at least later 
in his career, he was in the Federal Systems Division.


--
Pew, Curtis G
curtis@austin.utexas.edu






--
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

[Martin Packer]

Kees, I would hope that - as part of adding the capacity - you adjust LPAR 
definitions, especially weights. Even if that is a "null" adjustment.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "Vernooij, Kees (ITOP NM) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/02/2019 13:59
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 



We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the 
other site, a CF in both sites and Dasd mirrored between the sites.
Our DRP consists of moving workload from 1 site's LPARs to the 
corresponding LPARs in the other site and adding capacity b.m.o. CBUs. No 
manipulation of LPARs.
We do this from time to time, sometimes as part of a DRP test, recently 
also because of a potentially disastrous power maintenance in a site.
A piece of cake, compared to the comments I read above.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 11 February, 2019 14:30
> 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
> 
> I have heard of a company in the Far East the periodically (every 6
> mths., IIRC) flips from site A to site B (and back).
> Aus(?) to Phillipines ?) and back.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Savor, Thomas (Alpharetta)
> Sent: Friday, February 8, 2019 7:08 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
> 
> >We've been doing DR mirroring for 20 years. It gets tested often. We've
> moved production twice to another >data center using our procedures.
> What we've never done is run production in another location
> >temporarily. 'Temporary' means move it, run it until at least one
> transaction is committed, then move it >*all* back. That is hugely
> complex and costly.
> 
> >A lot of management fantasizes about a big A-B switch that we throw one
> way or the other. So wrong.
> 
> About 5-6 years ago, I was working as a vendor (Daily Support) for
> Credit Card Software for Halifax/Bank of Scotland.  I believe the first
> time I was given a "heads up" was when we were supporting 12 Million
> Cardholders.  The "Heads up" was that on Friday evening at 6pm Main site
> was going to shut down and the whole weekend PRODUCTION was going to run
> on DR site, then 6am Monday Morning, Main site is to come back up and
> continue as if nothing happened !!!  I literally peed  in my pants !!!
> Probably everyone in Atlanta could hear me...NO !!!  Thinking of
> all the network signons with Visa and Mastercard...all the credit card
> Authorizations...there was absolutely zero chance of this working
> without issues.
> 
> Well, came in Monday morning after receiving no calls over the week-end
> everything was fine.  We ran the Batch Monday night...and that would
> be pulling in transactions from over the week-end from DR site.
> NO ISSUES !!!   Everything was fine.
> 
> Whoever did this, from a Systems perspectiveI tip my hat.  I've
> never seen someone do this with Production, but it worked fine...so what
> do I know.  Never seen anyone else do this in my 42 years of Mainframing
> either.
> 
> Unfortunately, Halifax/Bank of Scotland is no longer with us.  They were
> absorbed by Lloyds Banking Group.
> 
> 
> Thanks,
> Tom Savor
> 
> --
> 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 

Re: Friday history query

[Pew, Curtis G]

On Feb 9, 2019, at 12:06 AM, Mike Schwab 
mailto:mike.a.sch...@gmail.com>> wrote:

https://en.wikipedia.org/wiki/Timeline_of_operating_systems

Possible matches:
1955 General Motors Operating System for IBM 701.
1956 GM-NAA I/O for IBM 704.


Thanks for the link, but I’m pretty sure this was on a System/360. I think the 
letter was prompted in part by an event that my father once described to me, 
which I posted on my blog: My father and 
technology


--
Pew, Curtis G
curtis@austin.utexas.edu






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Friday history query

[Pew, Curtis G]

On Feb 9, 2019, at 5:47 AM, Joe Monk 
mailto:joemon...@gmail.com>> wrote:

Any chance we could get some more info? Who was the signer? Is there any
address/location info on the letter?


The letter was signed “H. H. Rumph”. I googled him too, but didn’t find 
anything. The letter was written in Washington, D. C. and says he worked in D. 
C.  in April and half of May 1966, and then in Sunnyvale, CA through July 15, 
the date of the letter. Another clue is that it mentions my father’s working 
knowledge of the “teleprocessing support area.”

Thanks for your interest.


--
Pew, Curtis G
curtis@austin.utexas.edu






--
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

[Vernooij, Kees (ITOP NM) - KLM]

We run in 2 sites continuously. Mainly Prod in 1 site and Dev/Acc in the other 
site, a CF in both sites and Dasd mirrored between the sites.
Our DRP consists of moving workload from 1 site's LPARs to the corresponding 
LPARs in the other site and adding capacity b.m.o. CBUs. No manipulation of 
LPARs.
We do this from time to time, sometimes as part of a DRP test, recently also 
because of a potentially disastrous power maintenance in a site.
A piece of cake, compared to the comments I read above.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 11 February, 2019 14:30
> 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
> 
> I have heard of a company in the Far East the periodically (every 6
> mths., IIRC) flips from site A to site B (and back).
> Aus(?) to Phillipines ?) and back.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Savor, Thomas (Alpharetta)
> Sent: Friday, February 8, 2019 7:08 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
> 
> >We've been doing DR mirroring for 20 years. It gets tested often. We've
> moved production twice to another >data center using our procedures.
> What we've never done is run production in another location
> >temporarily. 'Temporary' means move it, run it until at least one
> transaction is committed, then move it >*all* back. That is hugely
> complex and costly.
> 
> >A lot of management fantasizes about a big A-B switch that we throw one
> way or the other. So wrong.
> 
> About 5-6 years ago, I was working as a vendor (Daily Support) for
> Credit Card Software for Halifax/Bank of Scotland.  I believe the first
> time I was given a "heads up" was when we were supporting 12 Million
> Cardholders.  The "Heads up" was that on Friday evening at 6pm Main site
> was going to shut down and the whole weekend PRODUCTION was going to run
> on DR site, then 6am Monday Morning, Main site is to come back up and
> continue as if nothing happened !!!  I literally peed  in my pants !!!
> Probably everyone in Atlanta could hear me...NO !!!  Thinking of
> all the network signons with Visa and Mastercard...all the credit card
> Authorizations...there was absolutely zero chance of this working
> without issues.
> 
> Well, came in Monday morning after receiving no calls over the week-end
> everything was fine.  We ran the Batch Monday night...and that would
> be pulling in transactions from over the week-end from DR site.
> NO ISSUES !!!   Everything was fine.
> 
> Whoever did this, from a Systems perspectiveI tip my hat.  I've
> never seen someone do this with Production, but it worked fine...so what
> do I know.  Never seen anyone else do this in my 42 years of Mainframing
> either.
> 
> Unfortunately, Halifax/Bank of Scotland is no longer with us.  They were
> absorbed by Lloyds Banking Group.
> 
> 
> Thanks,
> Tom Savor
> 
> --
> 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.
> 
> 
> 
> 

Re: DEQ dynamically

[Allan Staller]

JCL, FREE=CLOSE on the relevant DD statement. Unfortunately require a 
recycle.

Several system level programs do this routinely.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Sunday, February 10, 2019 10:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DEQ dynamically

Hi

Is it possible to deallocate a dataset without recycling address space.

The dataset is users one and for some reason I would like to know if we can 
Dynamically remove it from allocation


Jake

--
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

[Allan Staller]

I have heard of a company in the Far East the periodically (every 6 mths., 
IIRC) flips from site A to site B (and back).
Aus(?) to Phillipines ?) and back.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Savor, Thomas (Alpharetta)
Sent: Friday, February 8, 2019 7:08 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

>We've been doing DR mirroring for 20 years. It gets tested often. We've moved 
>production twice to another >data center using our procedures. What we've 
>never done is run production in another location >temporarily. 'Temporary' 
>means move it, run it until at least one transaction is committed, then move 
>it >*all* back. That is hugely complex and costly.

>A lot of management fantasizes about a big A-B switch that we throw one way or 
>the other. So wrong.

About 5-6 years ago, I was working as a vendor (Daily Support) for Credit Card 
Software for Halifax/Bank of Scotland.  I believe the first time I was given a 
"heads up" was when we were supporting 12 Million Cardholders.  The "Heads up" 
was that on Friday evening at 6pm Main site was going to shut down and the 
whole weekend PRODUCTION was going to run on DR site, then 6am Monday Morning, 
Main site is to come back up and continue as if nothing happened !!!  I 
literally peed  in my pants !!!  Probably everyone in Atlanta could hear 
me...NO !!!  Thinking of all the network signons with Visa and 
Mastercard...all the credit card Authorizations...there was absolutely zero 
chance of this working without issues.

Well, came in Monday morning after receiving no calls over the week-end 
everything was fine.  We ran the Batch Monday night...and that would be 
pulling in transactions from over the week-end from DR site.
NO ISSUES !!!   Everything was fine.

Whoever did this, from a Systems perspectiveI tip my hat.  I've never seen 
someone do this with Production, but it worked fine...so what do I know.  Never 
seen anyone else do this in my 42 years of Mainframing either.

Unfortunately, Halifax/Bank of Scotland is no longer with us.  They were 
absorbed by Lloyds Banking Group.


Thanks,
Tom Savor

--
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: DEQ dynamically

[John McKown]

On Mon, Feb 11, 2019 at 6:14 AM Vernooij, Kees (ITOP NM) - KLM <
kees.verno...@klm.com> wrote:

> I am happy there is no command to deallocate a dataset behind the back of
> the application that enqueued it.
> Jikes.
>
> Kees.
>
>
I can envision writing an APF authorized program which could scheduled an
SRB in to a specified address space which would the do a DYNALLOC operation
to deallocate a DD name in that address space. But to the best of my
knowledge (poor in this case) the deallocation will fail if the DD is
"opened". And if not open, yanking an allocation out from under a program
is a very good way to cause an outage, or even worse a silent failure.

One thing that I sometimes do is include a FREE=CLOSE on a DD if I am
certain that the application will only read if once, say at start up, for
configuration information.

-- 
I just burned 2000 calories!
That's the last time I'll nap with brownies in the oven.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[Vernooij, Kees (ITOP NM) - KLM]

I am happy there is no command to deallocate a dataset behind the back of the 
application that enqueued it. 
Jikes.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: 11 February, 2019 12:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DEQ dynamically
> 
> Do you mean using something like an operator command? If so, not that I
> know of.
> 
> On Sun, Feb 10, 2019, 22:55 Jake Anderson  wrote:
> 
> > Hi
> >
> > Is it possible to deallocate a dataset without recycling address
> space.
> >
> > The dataset is users one and for some reason I would like to know if
> we can
> > Dynamically remove it from allocation
> >
> >
> > Jake
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DEQ dynamically

[John McKown]

Do you mean using something like an operator command? If so, not that I
know of.

On Sun, Feb 10, 2019, 22:55 Jake Anderson  Hi
>
> Is it possible to deallocate a dataset without recycling address space.
>
> The dataset is users one and for some reason I would like to know if we can
> Dynamically remove it from allocation
>
>
> Jake
>
> --
> 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: XMIT Manager and CP1047 (or rather CP1046.9921875)

[Robert Prins]

On 2019-02-10 20:16, Seymour J Metz wrote:
Every release that I have ever used has had issues with translation, ever 
since the original ASCII support for tape.


Do you mean UTF-8 or UTF-EBCDIC (https://en.wikipedia.org/wiki/UTF-EBCDIC)?


UTF-8, I didn't even know there was something like UTF-EBCDIC!

Flow is UTF-8 (on a white box) -> IND$FILE -> lots of gibberish on z/OS -> 
process -> processed gibberish -> IND$FILE -> nice unchanged UTF-8, at least 
when extracted with XMIT Manager and its CP1046.9921875 codepage


Processing on z/OS doesn't touch the gibberish itself, it only has to calculate 
the actual length in UFT-8 characters, and that's done using the translate and 
sum PL/I builtins, using metadata in the original (white box) input file.


Robert
--
Robert AH Prins
robert(a)prino(d)org


From: IBM Mainframe Discussion List  on behalf of Robert 
Prins 
Sent: Saturday, February 9, 2019 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: XMIT Manager and CP1047 (or rather CP1046.9921875)

Over the last week or so I've been having a discussion with Denis Molony about
his XmitApp, a platform-agnostic, it's written in Java, viewer for XMIT files,
see 

As is, it (currently) only shows the contents of the xmit file in one of the
panels, and he's hit a snag. One of my PDS's he's using contains text that comes
from uploaded-to-z/OS UTF-8 encoded text (which basically means all UTF-8
characters are mangled beyond recognition on z/OS). It's processed on z/OS, and
the results, also containing UTF-8 encoded text is downloaded to Windoze
(unmangling the mangled mess again), but XmitApp using CP1047 screws up
codepoints 0x15 and 0x25, and if you take a look at those two code points on
https://en.wikipedia.org/wiki/EBCDIC_1047>, shiver...

0x15 is NL (Newline)  (Unicode 0085)
0x25 is LF (Linefeed) (Unicode 000A)

I never realised that EBCDIC had two of the same, just different...

Extract the files with Neil Johnston-Ward's XMIT Manager from the cbttape.org
site @ , and the UTF-8 encoded characters
show up OK. Do it with the official CP1047 and they don't.

So load XMIT Manager.exe into a hex-editor, I'm (still) using HxD 1.7.7.0 from
, and look for the translate table NJW uses (just
do a find for 'abcdef') and you'll see that he has swapped the ASCII characters
for the 0x15 and 0x25 code points from those in the "official" CP1047...

Denis has found an APAR dating back to 2010,
, that seems to
confirm that, for Java in mixed environments, i.e. z/OS vs little white boxes,
NJW is correct in swapping them.

Can anyone provide any more insights? For what it's worth, I'm currently
restricted to doing the round-trip transfers using IND$FILE (Upload as ASCII,
download of XMIT (obviously) binary), but I would appreciate if anyone can check
what happens if they are done using FTP or the WSA. I've attached, in the hope
it survives, utf-8.zip.txt with a bit of UTF-8 encoded data to experiment with.
It's all the UTF-8 encoded data that's in use in the test file, and consists of
European (and a few Japanese) place names.




--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
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 Getgood]

Ron,
You have an established session from JES's Netserv to z/VM - 

EZZ2587I JES2S001 7D6F 10.100.5.71..175   10.100.5.73..3603  
Establsh

(What's at port 3603 on z/VM btw?)

Your start link looks successful, both on z/VM & z/OS - that seems to suggest 
that the network is ok.

The QUERY LINK and QUERY NODE commands are RSCS commands, not "normal" z/VM 
commands - sorry.

I'd try the start link again, and very quickly after, issue the $SN,N=your z/VM 
node number (or $SN,SOCKET=your z/VM socket number) on the z/OS system.  You 
need to get nje networking er, working, before anything else.

Let me know the outcome.

What have IBM come up with?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN