Re: Transactional Execution - anybody used it?

[Peter Relson]

Rats, posted to ibm-main instead of the (correct) assembler list.

Re-posted.

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: Software vendor trying to force MSU based contract

[Knutson, Samuel]

Most vendor products that provide meaningful value also are internally quite 
large and complex.  Very few if any sites that inherited a source escrow from a 
vendor which goes out of business or sunsets a technology can support those 
products.  Sometimes the products themselves include technology built using 
protected IP from IBM, or other vendors that is protected by non-disclosure 
arrangements.
Consider that source escrow does not automatically imply the ability for a 
company that received an escrow to further disclose or share that IP with 
others (the community).  You mostly likely cannot just take an escrow tape and 
upload it to GitHub.The product might today be something you like but the 
firm is mostly likely going to be better served by locating a replacement than 
by trying to nurse along Abandonware.  Source escrow just isn't worth the 
trouble for most systems infrastructure products.

Just my .02 speaking only for myself.

Best Regards,
Sam Knutson

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, March 02, 2017 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Software vendor trying to force MSU based contract

On Thu, Mar 2, 2017 at 3:00 AM, Dave Wade  wrote:

> I am going to say something you gentlemen may not like...
>
> 1) Do you need the product?
> 2) Do you need continued support, e.g. for legal and compliance reasons?
> 3) is the company in financial difficulties?
>
> If the answer to all these is "yes" then paying the increased charges
> may be your best option. If the company folds or files for protection
> it matters not how many bits of paper you have, if there is no
> business to honor the contracts you have then replacing the product
> may be much more expensive. In my humble IBM is the biggest player of
> these sorts of games and is doing an excellent job of squeezing the
> last drop of blood from its traditional mainframe customers..
>
> .. and throwing lawyers at a problem usually drives the costs up even
> more...
>

​I think you have some very valid points. I don't think that _any_ software 
company offers the following "option", but it is one that I'd like. What I 
_wish_ every company would "require" from a vendor is that should the vendor 
either "go out of business" or "sunset a product", that the customer would get 
a copy of the current source for the product, along with all internal 
documentation. No, I have not been taking any "funny pills". I do realize that 
perhaps all of the current z/OS vendors would like like hyenas if anyone asked 
this of them. Which is yet another reason that I am a FOSS advocate. An 
individual company might not be able to support "some product", but the 
"community" could possibly do so.
--
"Irrigation of the land with seawater desalinated by fusion power is ancient. 
It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

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

Re: Can you use IDCAMS REPRO on zFS files

[Dan Little]

If I do it this way though I won't reclaim any space like I would if I
create a new zFS and copy using pax or copytree.



On Sun, Mar 5, 2017 at 07:38 Peter Hunkeler  wrote:

> >I have someone telling me that I can use a simple IDCAMS ZFS
> [snip]
>
> >Is it possible to use IDCAMS to copy a zFS file and not break the
> structure?
>
>
> Not only possible put inmost cases much faster that copy the data using
> unix commands such as pax of copytree. Here is the fine manual says about
> this:
>
>
> z/OS Distributed File Service zFS Administration Version 2 Release 1
> Increasing the size of a compatibility mode aggregate
> Copying the physical blocks of the aggregate to a larger data set
>
>
> Another method to increase the size of a zFS aggregate is to copy the
> physical blocks of the aggregate to a larger data set using the DFSMS REPRO
> command. This approach is normally faster than using the pax command.
> However, do not format the target zFS data set before using the REPRO
> command. Figure 10 on page 34 shows an example of this approach.
> [snip]
> With this approach, the new VSAM linear data set must not be formatted as
> an empty zFS file system before the REPRO command is used. (If the new data
> set was formatted, the REPRO would copy blocks to the end of the primary
> allocation, not the beginning. The data blocks being copied contain all the
> file system data and the file system information, so formatting is not
> necessary.) Neither file system needs to be mounted. REPRO uses native VSAM
> calls to read and write the blocks.
>
>
> --
> Peter Hunkeler
>
>
>
>
>
> --
> 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: Transactional Execution - anybody used it?

[Peter Relson]

As you might assume, the operating system uses transactional execution.

A caveat: you cannot use it unconditionally. Even if you know you are on 
the right machine. One reason for that is that it cannot be used if z/OS 
is running on/under VM. Another is that we have given the customer a knob 
to ask that transactional execution not be used when they are migrating to 
a new machine and really want, first, to make sure that the machine works 
before worrying about whether new code paths in the software also work. 
This is the MACHMIG statement of the LOADxx parmlib member. You must pay 
attention to the PSA/CVT bit (you can choose which you want to look at) 
which is on when available.

Transactional execution is used, for example, within supervisor, IOS, RSM. 
It is what makes "contractible CPOOL" possible and available.

We tend to look for cases where we can use TBEGINC rather than TBEGIN. 
That is because any use of TBEGIN requires accepting the possibility of 
too many aborts, and providing "traditional serialization" in the fallback 
path. And this means that the user of a transaction must also serialize 
against the user of "traditional serialization". "Traditional 
serialization" could be the local lock, an ENQ, a latch, etc.

One of the use cases is to avoid coarse-grained serialization when 
fine-grained serialization will do. The LOCAL lock is a case of 
coarse-grained serialization. It serializes lots of stuff. But sometimes 
you might be using it to serialize only "your stuff". Yet you are still 
contending for the resource with other users of the LOCAL lock, so could 
be adversely impacted by those cases (and your usage could adversely 
impact others). If you can use TBEGIN(C),  you no longer need to contend 
with other users of the LOCAL lock.

This is a performance-related facility. Performance needs should dictate 
how much you choose to use it.

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: changeman setup on RDT

[Lizette Koehler]

Why not talk to the vendor for assistance.  I usually open problem tickets if I 
do not have a direct route for Q

They will probably be very helpful.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ambrose Jr
> Sent: Sunday, March 05, 2017 7:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: changeman setup on RDT
> 
> Hi,
> 
> How to configure and setup changeman in test lpar which is running in RDT, we
> are planned to move packages from RDT to production lpar (mainframe) . I read
> serena changmean admin guide, came to know it can be setup by remote site
> option.
> 
> I never worked in changeman and no idea how to implement this, if some one
> guide or share some document or links will be more appreciated.
> --
> Regards,
> 
> Ambrose jr.

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

changeman setup on RDT

[Ambrose Jr]

Hi,

How to configure and setup changeman in test lpar which is running in RDT,
we are planned to move packages from RDT to production lpar (mainframe) . I
read serena changmean admin guide, came to know it can be setup by remote
site option.

I never worked in changeman and no idea how to implement this, if some one
guide or share some document or links will be more appreciated.
-- 
Regards,

Ambrose jr.


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

AW: Can you use IDCAMS REPRO on zFS files

[Peter Hunkeler]

>I have someone telling me that I can use a simple IDCAMS Repro
[snip]

>Is it possible to use IDCAMS to copy a zFS file and not break the structure?


Not only possible put inmost cases much faster that copy the data using unix 
commands such as pax of copytree. Here is the fine manual says about this:


z/OS Distributed File Service zFS Administration Version 2 Release 1
Increasing the size of a compatibility mode aggregate
Copying the physical blocks of the aggregate to a larger data set


Another method to increase the size of a zFS aggregate is to copy the physical 
blocks of the aggregate to a larger data set using the DFSMS REPRO command. 
This approach is normally faster than using the pax command. However, do not 
format the target zFS data set before using the REPRO command. Figure 10 on 
page 34 shows an example of this approach.
[snip]
With this approach, the new VSAM linear data set must not be formatted as an 
empty zFS file system before the REPRO command is used. (If the new data set 
was formatted, the REPRO would copy blocks to the end of the primary 
allocation, not the beginning. The data blocks being copied contain all the 
file system data and the file system information, so formatting is not 
necessary.) Neither file system needs to be mounted. REPRO uses native VSAM 
calls to read and write the blocks.


--
Peter Hunkeler





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

Re: Friday fun: trapping message IEC386S.

[Elardus Engelbrecht]

Mike Schwab wrote:

>On the Mir they used cleaners with ethanol leading to atmospheric 
>concentration 10X  the shuttle levels.

>https://www.nap.edu/read/5435/chapter/11#172

My, oh my! Thanks for posting this interesting article and table 7-1 and 7-3 
which are eye-openers! 

I know ethanol is poisonous [1], but I did not know that it can also cause 
problems with eyes amongst other lot of problems.

Thanks Mike for this OT post! ;-)

Groete / greetings
Elardus Engelbrecht

[1] - Sometimes people mix up ethanol containing brews to get drunk, but dies 
instead.

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Wayne Bickerdike]

Not a problem now:

$HASP003 RC=(52),P J247-240  - NO SELECTABLE ENTRIES FOUND
$HASP003   MATCHING SPECIFICATION

On Sun, Mar 5, 2017 at 1:44 AM, Steve Smith  wrote:

> Typos can be deadly in this business... true story (and likely not unique):
>
> Operator is told to purge jobs 247-249.  Types in $PJ247-240 (missed it by
> *that* much).  Which as anyone familiar with JES2 knows, pretty much wiped
> the spool clean.  And JES2 calls *its* problems "catastrophic".
>
> I don't know if that would still "work", I'm sure not going to try it.
>
> sas
>
> p.s. It wasn't me (I have caused some disasters in my career, just not this
> one), The actual numbers I don't remember, but the salient point is the 9 &
> 0 keys are adjacent.  JES2 allows (or did in the 90s) allow job number
> ranges on commands to wrap-around from the max ( at the time) to 1.  It
> did not ask for verification or check for reasonableness.
>
> On Fri, Mar 3, 2017 at 4:20 PM, Steve Beaver 
> wrote:
>
> > The one thing that might be interesting is which AWS site went down, and
> > it they the CIA down
> >
> > Steve
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Vernooij, Kees (ITOPT1) - KLM
> > Sent: Friday, March 3, 2017 8:35 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Check out Massive Amazon cloud service outage disrupts sites
> >
> > It was on Dutch newssites, with the text: "Amazon Web Services (AWS)
> > announced this on Thursday".
> >
> > Kees.
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > > On Behalf Of zMan
> > > Sent: 03 March, 2017 15:31
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Check out Massive Amazon cloud service outage disrupts
> > > sites
> > >
> > > Cite? (Not challenging you, interested!)
> > >
> > > On Fri, Mar 3, 2017 at 3:40 AM, Vernooij, Kees (ITOPT1) - KLM <
> > > kees.verno...@klm.com> wrote:
> > >
> > > > The outage was caused by a typo.
> > > > I remember there were times we made scripts and tested them on our
> > > test
> > > > environments, to avoid silly errors in the production environment...
> > > >
> > > > Kees.
> > > >
> > > > > -Original Message-
> > > > > From: IBM Mainframe Discussion List [mailto:IBM-
> > > m...@listserv.ua.edu] On
> > > > > Behalf Of Edward Finnell
> > > > > Sent: 28 February, 2017 23:47
> > > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > > Subject: Check out Massive Amazon cloud service outage disrupts
> > > sites
> > > > >
> > > > > _Massive  Amazon cloud service outage disrupts sites_
> > > > > (http://www.usatoday.com/story/tech/news/2017/02/28/amazons-cloud-
> > > > > service-goes-down-sites-scramble
> > > > > /98530914/)
> > > > >
> > > > > Wondered why traffic was a little off.
> > > > >
> > > > > --
> > > > > --
> > > --
> > > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > zMan -- "I've got a mainframe and I'm not afraid to use it"
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > > email to lists...@listserv.ua.edu with the message: INFO