Re: rsync anyone?

[Rob Schramm]

Pax Directory to dataset on lpar 1, unpax data set to Directory on lpar 2.
Add whatever transmission method in between.

I resisted pax for a long time.. But it always works for me.  I have had
some unpleasant surprises using techniques from *nix that don't always do
what I think they should on z/OS.

YMMV,

Rob Schramm

On Tue, Dec 29, 2015, 11:17 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 28 Dec 2015 21:11:49 -0500, Shmuel Metz (Seymour J.) wrote:
> >
> >>a predominantly ASCII world.
> >
> >I wish! The real world is a morass of different code pages, not always
> >declared in MIME header fields.
> >
> And, irritatingly, when SMTP, either on z/OS or z/VM converts incoming
> messages from (e.g.) ISO8859-1 to IBM-1047 it doesn't adjust the MIME
> headers accordingly.
>
> -- 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: History question - In what year did IBM first release its DF/DSS backup &...

[Ed Finnell]

That's consistent with my recollection. Lots of ESP's(and APARs) back  then 
in prep for XA. Our storage folks were dismayed at performance and abends  
so quickly switched to FDR and Sterling's DMS(?)
 
 
In a message dated 1/2/2016 10:14:37 P.M. Central Standard Time,  
000a2a8c2020-dmarc-requ...@listserv.ua.edu writes:

"Originally released as DFDSS (Data Facility Data Set Services) in  1980."
I don't know if this is a dependable source, but 1980 seems  reasonable for 
the 
first release if the second was in 1983.

I  hadn't noticed this area of bitsavers before. Thanks for the hint,  Joel.


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

Re: So Long, and Thanks For All The Fish

[Vernooij, CP (ITOPT1) - KLM]

I wish you all the best.
We will miss your humor.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: 31 December, 2015 15:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So Long, and Thanks For All The Fish

Shane ...

--
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: Is there a source for detailed, instruction-level performance info?

[Alan Altmark]

On Mon, 28 Dec 2015 11:02:15 -0600, Jerry Callen  wrote:

>I'm not really after detailed timing. I'm looking for implementation details 
>of the same sort used by compiler writers to guide selection of instruction 
>sequences, where the guiding principle is, "How can I avoid pipeline stalls?" 
>As I noted, several SHARE presentations contain SOME of this information, 
>which I've already benefited from, but I'm looking for more.

Just remember that your machine runs more than one thing at a time, and trying 
to over-engineer a solution may end up being suboptimal.  Nice for 
single-thread performance, but it may be irrelevant in terms of overall 
throughput.  If caches are sufficiently polluted by other LPARs, you may find 
no advantage.  Someday they may even violate the law of causality.  Who 
knows

Every processor family has different behaviors.   The longevity of the z 
architecture can be attributed to the fact that we don't get overly carried 
away trying to teach the machines to sit up and beg.  At some point, it's "fast 
enough" and making it go faster is just an academic exercise.   

>I'm still hoping that someone will reveal the existence of a document intended 
>for compiler writers...

Folks who participate in PWD may have access to that kind of information -- I 
don't know.  If you participate in Linux GCC development, then you can see what 
IBM loads upstream for new processors.

Alan Altmark
IBM

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

Re: Is there a source for detailed, instruction-level performance info?

[Alan Altmark]

On Wed, 30 Dec 2015 17:08:26 -0600, Jerry Callen  wrote:
>Bob Rogers (no longer at IBM...) 

Bob rejoined IBM a while back, working in z/VM.

Alan Altmark
IBM

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

Re: Is there a source for detailed, instruction-level performance info?

[Jack J. Woehr]

Alan Altmark wrote:

On Mon, 28 Dec 2015 11:02:15 -0600, Jerry Callen  wrote:


"How can I avoid pipeline stalls?"


Not sure how relevant that this is to mainframe programming, but years ago when 
I designed and executed
with a team of nine a data-heavy server in Unix optimized for multiple cores, 
what we found was that
reroutable queuing of data from one simplistic processing engine to the next 
(with reservoirs for data accumulation)
got the most performance. It was a much more productive approach in light of 
memory, bus and i/o considerations than
executing an arbitrary design and trying to speed it up on the processor cores 
themselves.

That architecture is more or less how OS/400 worked on its best days, btw.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Fibre Chanel Vs FICON

[Anne & Lynn Wheeler]

Kevin Bowling  writes:
> I'm shortly going to be the new owner of a z800 at home.  Looking
> forward to booting and playing with this bistro, what kind of disk array
> do I need?  Is fibre channel storage enough, or is FICON extra special
> at the protocol level?  Is there any way to network boot/emulate storage
> or will I be looking for FICON arrays next?

there are two issues ... one is the FICON protoool running over
fibre-channel standard ... some past posts
http://www.garlic.com/~lynn/submisc.html#ficon

and controller emulation of CKD on industry standard fixed-block disks
(there haven't been any real CKD manufactured for decades).
http://www.garlic.com/~lynn/submain.html#dasd

there have been various past discussions about IBM charging/justifying a
significant $$/mbyte premium for that emulation

trivia

Build Your Own Fibre Channel SAN For Less Than $1000 - Part 1
http://www.smallnetbuilder.com/nas/nas-howto/31485-build-your-own-fibre-channel-san-for-less-than-1000-part-1


-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: IXGLOGR on RSM usage

[Rob Schramm]

Sure.  Stop using logstreams.



The logstream definitions are the only source of behavior change that I am
aware of.

Rob Schramm

On Thu, Dec 31, 2015, 8:36 AM Andrew Metcalfe 
wrote:

> I'm not aware, but that doesn't mean there isn't!
>
> I seem to remember the page fixing (RSM use) for logstream mode SMF being
> specific to SMF's use of dataspaces and not necessarily System Logger's
> real storage use itself. There may have been something in the SMF Logstream
> Redbook that made me think that.
>
> Andrew
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: 30 December 2015 18:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IXGLOGR on RSM usage
>
> Hi Andrew
>
> Thank you for the pointer which helped me in tuning up the SMF logstream.
>
> So when it comes to other logstream structures for DB2,CICS. Is there a
> way to limit their RSM usage as well ?
>
> Nathan
>
>
> On Wednesday 23 December 2015, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Andrew Metcalfe wrote:
> >
> > >Do you have SMF in Logstream mode?
> >
> > The OP said he has SMF in Logstream in thread 'Re: S00C Slip trap for
> > any Stc'.
> >
> > He wrote: "Our SMF logstream has been defined in IXGLOGR with dasdonly. "
> >
> >
> > >If so how many logstreams are defined? Each logstream has its own
> > dataspace/buffers. There are some parameters which govern
> > Logstream/SMF real storage requirements that you may need to tune.
> >
> > Good questions. Thanks for asking.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > 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
>
> This e-mail and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this e-mail
> in error, please notify the sender immediately, delete it from your system
> and do not copy, disclose or otherwise act upon any part of this e-mail or
> its attachments.
>
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays Group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any Internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this e-mail may be monitored by the Barclays Group for operational or
> business reasons.
>
> Any opinion or other information in this e-mail or its attachments that
> does not relate to the business of the Barclays Group is personal to the
> sender and is not given or endorsed by the Barclays Group.
>
> Barclays Bank PLC. Registered in England and Wales (registered no.
> 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United
> Kingdom.
>
> Barclays Bank PLC is authorised by the Prudential Regulation Authority and
> regulated by the Financial Conduct Authority and the Prudential Regulation
> Authority (Financial Services Register No. 122702).
>
> --
> 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