Re: IKJ56220I max # of datasets reached

[Shmuel Metz (Seymour J.)]

In <0193913060908138.wa.paulgboulderaim@listserv.ua.edu>, on
01/14/2015
   at 04:46 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>But, ISTR reading long ago that DYNAMNBR is policed by the TSO
>ALLOCATE command and that BPXWDYN is exempt from the limit.

The ALLOCATE command is jusy another customer of DYNALLOC and it would
make no sense to put a restriction there. Most allocations are done
via DAIR or directly via DYNALLOC.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Abend S602-0 when in AMODE 64

[Binyamin Dissen]

On Wed, 14 Jan 2015 18:25:30 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015
:>   at 10:05 PM, Binyamin Dissen  said:

:>>What issues do you perceive sharing a STATIC data area?

:>One task overwritinf data used by another task.

If the data is written to, how can it be static?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: IKJ56220I max # of datasets reached

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>... and that BPXWDYN is exempt from the limit.

Where is that exemption documented?


Shmuel Metz (Seymour J.) wrote:

>The ALLOCATE command is jusy another customer of DYNALLOC and it would make no 
>sense to put a restriction there. Most allocations are done via DAIR or 
>directly via DYNALLOC.

Indeed. Plus ISPF services which use IEBCOPY and friends under the covers. 
ALLOCATE or its variants are also 'customer' of DYNALLOC service.

I agree that it makes no sense to put a restriction, but there is a max 
[combined] size of things like TIOT, DCB, etc in your address space for example.

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

Re: Compile COBOL Programs In 64 Bit.

[R.S.]

W dniu 2015-01-15 o 01:51, Tom Ross pisze:

[...]


AMODE 64 COBOL is still being worked on here at IBM.

I (like the other poster) would like to know what you would do with AMODE 64 
COBOL?
Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
code?
We assume that AMODE 64 COBOL will be used for very specialized one-off cases
to solve specific business problems, and that in general 99% of code will be
compiled for AMODE 31 even after we ship AMODE 64 COBOL.

   Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we
do not think very many users will need AMODE 64 in the next 10-15 years.
We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if
you know of any, please SHARE!  (get it? :-)



"640 kB ought to be enough for anybody". ;-)


Regards

--
Radoslaw Skorupka
Lodz, Poland














--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

How does OPEN with DISP=MOD find the end of current data in a PS data set?

[Peter Hunkeler]

Based on a discussion here, I got curious on how OPEN in append mode (DISP=MOD) 
finds the end of the current data in a DASD PS data set. I do have some 
knowledge about VTOC and DSCBs but just never thought about this very question 
in detail.

Some of the actions below do not apply if the data set resides on one volume 
only (i.e. it is *not* multivolume).

This my current assumption. I'm not so much concerned about the fact that some 
information from the VTOCs is being mapped to internal control blocks (e.g. 
DEB) and by what code and when. I'm concentrating on the data in the VTOC and 
how is is used.


1. Allocation (?) has built a list of volumes where the data set has currently 
some space allocated.

2. OPEN needs to find the last volume on which there is current data. DSCB flag 
DS1IND80 indicates of this is the "Last volume contsining data in this data 
set".

I understand this flag to indicate the last volume with current valid data, not 
the last volume where the data set has some space allocated. I.e. if a data set 
gets expanded to a second volume while writing data, I assume this flag is OFF 
on the first but ON on the second volume. If the data set gets rewritten 
(DISP=OLD), and all data written this time fits on the first volume, then the 
flag would be turned ON on the first volume. The data set still has some, now 
unused, space allocated on the second volume, but the VTOC and all tracks are 
left unchanged in this case.

3. Once the last volume is identified, OPEN needs to find the end of current 
valid data on that volume. DS1LSTAR and possibly DS1TTTHI identify the last 
track (and block on that track) that has valid data. OPEN needs to map that 
track number to a cylinder-track address with the help of the extents 
information (DSCB1/DSCB3s).



If the above is roughly correct, then processing for OPEN in append mode will 
increase with the number of extents and volumes. On the other hand, processing 
for OPEN in replace mode (DISP=OLD) will not change, no matter on how many 
extents/volumes the data set has allocated from previous processing.



I appreciate any comment and correction.


--
Peter Hunkeler

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

Re: How does OPEN with DISP=MOD find the end of current data in a PS data set?

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>Based on a discussion here, I got curious on how OPEN in append mode 
>(DISP=MOD) finds the end of the current data in a DASD PS data set. 

>3. Once the last volume is identified, OPEN needs to find the end of current 
>valid data on that volume. 

This is similar what I see when processing tapes. Only the LAST tape is mounted 
for DISP=MOD. Even the VTS is faithfully reproducing this behaviour.


>If the above is roughly correct, then processing for OPEN in append mode will 
>increase with the number of extents and volumes. On the other hand, processing 
>for OPEN in replace mode (DISP=OLD) will not change, no matter on how many 
>extents/volumes the data set has allocated from previous processing.

Uhm, do you want to OPEN it by standard methods (Catalog+SMS and let system do 
the dirty work locating EOF) or do you just want to bypass normal processing 
and work only via the volser and the vtoc?

If you want to bypass normal processing, how will you then handle addition of a 
new extent taking in account of volume limits?

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

SMF RDW

[uweoswald]

Hi,

hope someone can help. I try to understand how a SMF RDW works. Basically I 
have no problems to understand „the whole thing“ as long as the record is not 
„spanned“. To make it clearer: For example a RDW (first 4 Bytes) of 
„33.14.01.00“. OK, x’3314’ tells me that the record is 13.076 Bytes long, but 
how to deal with the remaining part the „0100“? The only thing I know is that 
the record is spanned actually. Does this mean that the next 256 Bytes „after“ 
the first 13.076 Bytes belong together or how is this calculated?!

My question does not belong to a dedicated programming language or to a 
specific record format. I just want to understand „how“.

Thank you in advance for your help.

Regards,
Uwe

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

Re: SMF RDW

[Shane Ginnane]

Start with chapter 20 of "Using datasets" - in the DFSMS bookshelf.

Shane ...

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

Re: SMF RDW

[Elardus Engelbrecht]

uweoswald wrote:

>To make it clearer: For example a RDW (first 4 Bytes) of 33.14.01.00. OK, 
>x'3314' tells me that the record is 13 076 Bytes long,

Correct. A$$uming you write it just as-is. 


> but how to deal with the remaining part the '0100'? 

According to book, these 2 bytes should be zeroes for NON-spanned records. 
Otherwise it is used for spanned records.

Look in 'Variable-Length Record Formats' in book 'DFSMS Using Data Sets' for 
more details. or Chapter 20 as Shane suggested.


In SMF Book this quote:

"The header section must include the record descriptor word (RDW). The RDW is a 
4-byte field that must introduce each SMF record when it is written to the SMF 
data set by the SMFWTM macro instruction. The first two bytes of the RDW must 
contain the length of the logical record (including the four bytes of the RDW). 
The second two bytes are used for variable blocked
spanned records; that is, records that contain more than 32,756 bytes. This 
field (the second two bytes) is set to zero if the record is not spanned. The 
remainder of the record immediately follows the RDW."


>Does this mean that the next 256 Bytes after the first 13.076 Bytes belong 
>together or how is this calculated?!

No, see above quote. You get the next RDW after that 13076 bytes. But you don't 
read in the RDW, you let the system use the RDW to dump the record in that many 
bytes in your memory you reserved for that purpose.

Schematic of NON spanned record:

< ... etc ... >

For spanned records, things are getting interesting and somewhat difficult to 
explain. I'm not going to do that here.


>I just want to understand „how“.

Why? What are you trying to achieve. I'm asking because you can't use RDW 
directly with standard methods.

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

Re: Abend S602-0 when in AMODE 64

[Peter Relson]

>I assume that there is a special method of returning to a AMODE 64 
>caller since there is no mention in the R14 description. I have a 
>vague impression that the low bit of the return address being 1 (as 
>opposed to 0) indicates a return in AMODE 64.

I would say that your assumption is incorrect.

For things like ATTACH and LINK, BR 14 (or BSM 0,14) work fine.

If you have defined that your interface is to be called by BASSM 
(regardless of your AMODE) then you are expected to return by BSM.

If you are called by BASSM from AMODE 64 then it would be true that the 
low bit of R14 would be on.
If you are called by BASR and switch AMODEs, you can issue BSM 14,0 at the 
beginning in order to accommodate BSM 0,14 at the end.

>1) If in AMODE64 when the STIMERX macro was issued, 
>why was bit 32 on in R15? Seems wrong to me.
I'd say it's because you're expected not to need it or care, so no change 
was made to the existing logic which set the high bit on when PSW bit 32 
(on both for AMODE 31 and AMODE 64) is on. Could it have been done 
differently? Sure. Will it be changed? Not likely.

>2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 
>when bit 32 on the base reg was on? 
Because you cannot get a PIC 38 on a LA instruction. As someone mentioned, 
it is just doing architecturally-defined arithmetic.

>>AMODE 64 routines should be using relative branch and generally
>>should  establish addressability to a static data area

>What if the code is shared? That goes against decades of coding to be
>reentrant and refreshable.

There is no conflict with what I wrote versus being reentrant and 
refreshable. If reentrant / refreshable you would also have addressability 
to a dynamic data area.
But you would still use relative branch and would still have 
addressability to whatever static data you need. 

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: IBM Launches the z13 Mainframe

[John P. Baker]

Timothy,

Will IBM be releasing a new edition of the z/Architecture Principles of
Operation publication, or will the SIMD instruction set be documented in a
separate publication, as was the case with the earlier vector facilities?

John P. Baker

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Timothy Sipples
Sent: Thursday, January 15, 2015 1:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBM Launches the z13 Mainframe

If you'd like some introductory information on the Vector Facility for
z/Architecture (SIMD) capabilities, this paper should help:

http://www.redbooks.ibm.com/technotes/tips1259.pdf

Yes, Mathematical Acceleration Subsystem (MASS), Basic Linear Algebra
Subprograms (BLAS), and Automatically Tuned Linear Algebra Software (ATLAS)
are among the functions arriving on z/OS and on Linux on z Systems that
exploit SIMD. Yet another piece of fantastic news.



Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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: IBM Launches the z13 Mainframe

[John McKown]

On Thu, Jan 15, 2015 at 12:31 AM, Timothy Sipples 
wrote:

>
> John McKown writes:
> >This might help people to convert to z/OS. Of
> >course, there is still that nasty EBCDIC
> >issue for any conversion.​
>
> That's just not correct.
>
> z/OS imposes absolutely no requirement to use or to convert to EBCDIC.
> Zero, zip, nada. Store and manage everything in Unicode if you like. (Many
> do and do like.) Or Plutocode, or McKowncode. Choose whatever character
> encoding you like.
>

> Interoperating with EBCDIC-encoded data requires, well, interoperating with
> EBCDIC-encoded data, whether z/OS or another operating system manages and
> stores such data. z/OS provides excellent interoperation capabilities
> should you wish to use them. But such interoperation requirements exist, if
> they exist, no matter where you run.
>

​I think I understand where you're coming from. But this is, in and of
itself, a "nasty EBCDIC" problem because code on z/OS generally _assumes_
that character data is encoded in CP-037 (historic batch?), or maybe
IBM-1047 (UNIX). And code from other systems such as Windows, UNIX, Linux,
Mac assume that ​character data is ASCII (and no, not exactly the same code
page, but "close enough" for the common Latin characters in English). One
way in which EBCDIC is "nasty", that I personally encountered, is that the
"control" versions of A..Z (ctrl-A through ctrl-Z) in ASCII are a simple
bit manipulation to get from the letter encoding to the corresponding
control encoding. To do the same in EBCDIC took a table look-up and a lot
of #define lines in C. The "ugliness" of this is that the C code I was
using looked like:

#define control_character_bit 0x40  /* 0x00, must be off. */
#define CTRL(c) ((c) & control_character_mask)
select (c)
   {
   case CTRL('A'):
...
   break;
   case CTRL('C'):
...
   break;
// and so on
   }

​With ASCII, the CTRL('C') is a calculated value of the literal 'C', which
is acceptable to the C compiler as the "case" operand. On z/OS, I had to
replace all the CTRL('...') with something like CTRL_??? and then #define
each CTRL_A through CTRL_Z with the specific EBCDIC values (which are all
over the place, not neatly organized). Was this really all that difficult?
No. But is was an "ugliness" and an impediment to the port. And I must now
maintain even more differences in the z/OS version and the "normal" UNIX
version of this code. No, I cannot change the upstream UNIX version - it is
GNU software. Can I request that they change their standards? 
 . They likely wouldn't do it because an older version of
this same software actually used my method (individual #define statements)
and they converted away from it to the one which doesn't work on z/OS with
EBCDIC.​ Possibly because it is fewer lines of code to maintain (2 vs. 26).

​That is why I called EBCDIC "ugly". And, to my shame?, I will admit that I
_like_ Java and the fact that it uses UNICODE internally with the external
representation be specifiable by the programmer or by the user. But
historic z/OS code doesn't do this. Nor historic UNIX code. Both _assume_
things about the bit encodings (such as A<
John McKown

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

Re: IBM Launches the z13 Mainframe

[Tom Marchant]

On Thu, 15 Jan 2015 14:31:56 +0800, Timothy Sipples wrote:

>z/OS imposes absolutely no requirement to use or to convert to EBCDIC. 
>Zero, zip, nada. Store and manage everything in Unicode if you like.

Really?

Can I code PARMLIB in Unicode?
Can I get z/OS messages to be issued in Unicode?
Can I operate the system with a Unicode console?
Can I specify input to IBM utilities in Unicode?
Can I issue TSO commands in Unicode?

I could probably ask many more questions like these.

Unless the answer to all of these is "yes", your "absolutely no requirement to 
use" is false.

User data only? Sure. That is considerably more restricted.

-- 
Tom Marchant

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

Re: IBM Launches the z13 Mainframe

[Paul Gilmartin]

On 2015-01-14, at 23:31, Timothy Sipples wrote:

> 
> John McKown writes:
>> This might help people to convert to z/OS. Of
>> course, there is still that nasty EBCDIC
>> issue for any conversion.​
> 
> That's just not correct.
> 
> z/OS imposes absolutely no requirement to use or to convert to EBCDIC.
> Zero, zip, nada. Store and manage everything in Unicode if you like. (Many
> do and do like.) Or Plutocode, or McKowncode. Choose whatever character
> encoding you like.
>  
Huh!?

I have tried building FOSS with the C compiler ASCII option.  It works well
for "Hello, World" but fails miserably for anything real-world, first
because lack of ASCII versions of essential libraries such as Curses and
X11.

There's no support for Plutocode or McKowncode.  Of course, the bare metal
is character set unbiased and Linux runs well in ASCII on the z.  But
John and I are concerned with z/OS which has strong EBCDIC biases.

Have you been swallowing IBM's drugs?  May we expect ASCII versions of
X11 and Curses libraries shortly?

-- gil

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

Re: IBM Launches the z13 Mainframe

[Paul Gilmartin]

On Thu, 15 Jan 2015 07:55:50 -0600, Tom Marchant wrote:

>On Thu, 15 Jan 2015 14:31:56 +0800, Timothy Sipples wrote:
>
>>z/OS imposes absolutely no requirement to use or to convert to EBCDIC. 
>>Zero, zip, nada. Store and manage everything in Unicode if you like.
>
>Really?
>
>Can I code PARMLIB in Unicode?
>Can I get z/OS messages to be issued in Unicode?
>Can I operate the system with a Unicode console?
>Can I specify input to IBM utilities in Unicode?
>Can I issue TSO commands in Unicode?
>
>I could probably ask many more questions like these.
>
>Unless the answer to all of these is "yes", your "absolutely no requirement to 
>use" is false.
> 
I'm waiting for Timothy's answer and apologia.

>User data only? Sure. That is considerably more restricted.
>
And even there I see biases in string constants coded in programs.
HLASM has EBCDIC self-defining terms, but not ASCII self-defining terms.

IEBGENER can probably deal with Unicode data set content, but not
Unicode data set names.

-- gil

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

Re: Abend S602-0 when in AMODE 64

[Shmuel Metz (Seymour J.)]

In , on 01/15/2015
   at 11:12 AM, Binyamin Dissen  said:

>On Wed, 14 Jan 2015 18:25:30 -0500 "Shmuel Metz (Seymour J.)"
> wrote:

>:>In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015
>:>   at 10:05 PM, Binyamin Dissen  said:

>:>>What issues do you perceive sharing a STATIC data area?

>:>One task overwritinf data used by another task.

>If the data is written to, how can it be static?

You're confusin static with constant. A static area is allocated to a
single address for every allocation.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IBM Launches the z13 Mainframe

[Elardus Engelbrecht]

Tom Marchant wrote:

>Can I get z/OS messages to be issued in Unicode?

And having Bookmanager bookies written in all those codepages?

>I could probably ask many more questions like these.
>Unless the answer to all of these is "yes", your "absolutely no requirement to 
>use" is false.

True.


Paul Gilmartin wrote:
 
>I'm waiting for Timothy's answer and apologia.

Or try test TRT for packed / unpacked values. Just remember ASCII numbers 
(packed) are in hex x'30 - x'3F' and EBCDIC are in x'F0' - x'F9'. 

>And even there I see biases in string constants coded in programs.
>HLASM has EBCDIC self-defining terms, but not ASCII self-defining terms.

So I see it too after RTFM. Good catch.


>IEBGENER can probably deal with Unicode data set content, but not Unicode data 
>set names.

or try: OCOPY '/SYSTEM/tmp/blahblah.txt'   HLQ.DSN.NAME

where you specify your folders/filename in Unicode.

I will not go on, especially if you add FTP (transfers *with* translation from 
codepages) in this fray...

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

Re: IKJ56220I max # of datasets reached

[John McKown]

On Thu, Jan 15, 2015 at 3:16 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Paul Gilmartin wrote:
>
> >... and that BPXWDYN is exempt from the limit.
>
> Where is that exemption documented?
>
>
> Shmuel Metz (Seymour J.) wrote:
>
> >The ALLOCATE command is jusy another customer of DYNALLOC and it would
> make no sense to put a restriction there. Most allocations are done via
> DAIR or directly via DYNALLOC.
>
> Indeed. Plus ISPF services which use IEBCOPY and friends under the covers.
> ALLOCATE or its variants are also 'customer' of DYNALLOC service.
>
> I agree that it makes no sense to put a restriction, but there is a max
> [combined] size of things like TIOT, DCB, etc in your address space for
> example.
>
> Groete / Greetings
> Elardus Engelbrecht
>
>
​As best as I understand it, the DYNAMNBR causes the initiator(?) to get a
larger than needed TIOT. Once the TIOT is "full", you can't dynamically
expand its allocation. I don't know how it is done, but there is a new
facility called the XTIOT which some code can use which can bypass the
DYNAMNBR limitation. However, this requires that the access method(?)
support an XTIOT entry. A search will show up some hits on "xtiot +site:
ibm.com". One that I find useful is:
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.idak100/bam12spl.htm%23bam12spl
​
-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

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: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 22:11:35 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>But, ISTR reading long ago that DYNAMNBR is policed by the TSO
>>ALLOCATE command and that BPXWDYN is exempt from the limit.
>
>The ALLOCATE command is jusy another customer of DYNALLOC and it would
>make no sense to put a restriction there. Most allocations are done
>via DAIR or directly via DYNALLOC.
> 
Now, I don't understand.  I just tried:

//STEP  EXEC  PGM=IKJEFT01,DYNAMNBR=10

... with the EXEC:

/* Rexx main program. */
trace C
do I = 1 to 11
address 'TSO' 'allocate dsn(TEST'I') new delete'
if RC<>0 then leave I;  end

do J = 1 to 11
RC = BPXWDYN( 'alloc DSN('userid()'.TEST'J') new delete' ,
'rtddn(D) msg(WTP)' )
if RC<>0 then leave J
say 'Allocated' D;  end J

exit( RC )

... it successfully allocated 22 data sets.  AFAIK, 22 is greater than 10.

What's happening here?

-- gil

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

Re: IKJ56220I max # of datasets reached

[Lizette Koehler]

The DYNAMNBR parameter is used to indicate how many Task I/O Table (TIOT) slots 
to reserve for data sets that may be dynamically allocated during the job step.

The TIOT contains control blocks for every DD allocated in your jobstep ( 
dynamically or via JCL ) .

If you fill the TIOT, no more files may be allocated until some are 
unallocated. TIOT size varies based on operating system settings.

The Dynamnbr tells the system how many data set allocations to hold in 
anticipation of reuse.  (The system actually holds n plus the total number of 
the DD statements used by the step.)

Does that help?

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, January 15, 2015 7:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IKJ56220I max # of datasets reached

On Wed, 14 Jan 2015 22:11:35 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>But, ISTR reading long ago that DYNAMNBR is policed by the TSO 
>>ALLOCATE command and that BPXWDYN is exempt from the limit.
>
>The ALLOCATE command is jusy another customer of DYNALLOC and it would 
>make no sense to put a restriction there. Most allocations are done via 
>DAIR or directly via DYNALLOC.
> 
Now, I don't understand.  I just tried:

//STEP  EXEC  PGM=IKJEFT01,DYNAMNBR=10

... with the EXEC:

/* Rexx main program. */
trace C
do I = 1 to 11
address 'TSO' 'allocate dsn(TEST'I') new delete'
if RC<>0 then leave I;  end

do J = 1 to 11
RC = BPXWDYN( 'alloc DSN('userid()'.TEST'J') new delete' ,
'rtddn(D) msg(WTP)' )
if RC<>0 then leave J
say 'Allocated' D;  end J

exit( RC )

... it successfully allocated 22 data sets.  AFAIK, 22 is greater than 10.

What's happening here?

-- gil

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 22:11:35 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>But, ISTR reading long ago that DYNAMNBR is policed by the TSO
>>ALLOCATE command and that BPXWDYN is exempt from the limit.
>
>The ALLOCATE command is jusy another customer of DYNALLOC and it would
>make no sense to put a restriction there. Most allocations are done
>via DAIR or directly via DYNALLOC.
> 
A little experimenting shows that (at our site?) there is a base number of 5
and the DYNAMNBR coded on the EXEC statement is added to that.  So:

//STEP  EXEC  PGM=IKJEFT01,DYNAMNBR=3
...
/* Rexx main program. */
trace C
do J = 100 to 122
RC = BPXWDYN( 'alloc DSN('userid()'.TEST'J') new delete' ,
'rtddn(D) msg(WTP)' )
if RC<>0 then leave J
say 'Allocated' D;  end J

do I = 1 to 11
address 'TSO' 'allocate dsn(TEST'I') new delete'
if RC<>0 then leave I;  end

exit( RC )

... successfully allocates 23 data sets with BPXWDYN.  ALLOCATE
allocates 7 more and fails on the 8th.

ISTR in that discussion long ago that there's a flag passed to SVC 99
telling it whether to enforce DYNAMNBR.  ALLOCATE tells it to enforce;
BPXWDYN tells it not to enforce.

So, perhaps the answer to the OP might be to use BPXWDYN instead
of ALLOCATE, if possible.

-- gil

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

Re: IBM Launches the z13 Mainframe

[Sam Siegel]

On Thu, Jan 15, 2015 at 6:27 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Tom Marchant wrote:
>
> >Can I get z/OS messages to be issued in Unicode?
>
> And having Bookmanager bookies written in all those codepages?
>
> >I could probably ask many more questions like these.
> >Unless the answer to all of these is "yes", your "absolutely no
> requirement to use" is false.
>
> True.
>
>
> Paul Gilmartin wrote:
>
> >I'm waiting for Timothy's answer and apologia.
>
> Or try test TRT for packed / unpacked values. Just remember ASCII numbers
> (packed) are in hex x'30 - x'3F' and EBCDIC are in x'F0' - x'F9'.
>
> >And even there I see biases in string constants coded in programs.
> >HLASM has EBCDIC self-defining terms, but not ASCII self-defining terms.
>
> So I see it too after RTFM. Good catch.
>
>
> >IEBGENER can probably deal with Unicode data set content, but not Unicode
> data set names.
>
> or try: OCOPY '/SYSTEM/tmp/blahblah.txt'   HLQ.DSN.NAME
>
> where you specify your folders/filename in Unicode.
>
> I will not go on, especially if you add FTP (transfers *with* translation
> from codepages) in this fray...
>
> 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
>

At the hardware level PACK ASCII and UNPACK ASCII are needed because PACK
and UNPACK convert from and to EBCDIC.

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 22:11:35 -0500, Shmuel Metz (Seymour J.)  wrote:
>
>The ALLOCATE command is jusy another customer of DYNALLOC and it would
>make no sense to put a restriction there. Most allocations are done
>via DAIR or directly via DYNALLOC.
> 
It's more complicated than that.  Another opinion:

http://www2.marist.edu:8000/htbin/wlvtype?MVS-OE.54915

Date: Thu, 10 Feb 2011 09:31:27 -0500
Reply-To: MVS OpenEdition 
From: William Schoen 
Subject:  Re: DYNAMNBR for z/OS UNIX Forked Procedure

BPXWDYN is not subject to DYNAMNBR.  If I remember right, only allocations
that use the DALCNVRT TU or do not use DALPERMA TU are subject to this
limit.  BPXWDYN always adds the DALPERMA TU.

-- gil

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

Device to capture keystrokes from wireless keyboards

[Mike Schwab]

http://www.businessinsider.com/samy-kamkar-microsoft-keyboard-keylogger-vulnerability-2015-1

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

z13 unanswered question.

[John McKown]

I have really enjoyed reading about the z13 and some of the new nifties.
And, of course, eventually IBM will give out some harder performance
number. But I'll bet there is one geek question which will not be answered.

How fast could a fully enabled machine mint bitcoins or other
cryptocurrency? How much power would such a machine use while doing so?
"Inquiring minds want to know!"

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

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: z13 unanswered question.

[Grinsell, Don]

Do I sense a new performance metric on the horizon?

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"I'll sleep when I'm dead..."
~ Warren Zevon

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, January 15, 2015 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z13 unanswered question.

I have really enjoyed reading about the z13 and some of the new nifties.
And, of course, eventually IBM will give out some harder performance number. 
But I'll bet there is one geek question which will not be answered.

How fast could a fully enabled machine mint bitcoins or other cryptocurrency? 
How much power would such a machine use while doing so?
"Inquiring minds want to know!"


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

Re: z13 unanswered question.

[Pfister, Nathan]

Out of curiosity, have you (successfully) compiled, and used, a bitcoin miner 
on z/OS Unix?


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, January 15, 2015 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z13 unanswered question.

I have really enjoyed reading about the z13 and some of the new nifties.
And, of course, eventually IBM will give out some harder performance number. 
But I'll bet there is one geek question which will not be answered.

How fast could a fully enabled machine mint bitcoins or other cryptocurrency? 
How much power would such a machine use while doing so?
"Inquiring minds want to know!"

--
​
While a transcendent vocabulary is laudable, one must be eternally careful so 
that the calculated objective of communication does not become ensconced in 
obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

--
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: IKJ56220I max # of datasets reached

[Shmuel Metz (Seymour J.)]

In <6483038090933465.wa.paulgboulderaim@listserv.ua.edu>, on
01/15/2015
   at 09:31 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>It's more complicated than that.

To begin wth, well coded assembler routines will use DYNALLOC
directly.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z13 unanswered question.

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of John McKown
> Sent: Thursday, January 15, 2015 10:41 AM
> 
> [ snip ]
> 
> How fast could a fully enabled machine mint bitcoins or other cryptocurrency? 
> How much power would
> such a machine use while doing so?
> "Inquiring minds want to know!"

Any speculations on what the "z13 Jr" will be called?  The z9, z10 and z12 had 
EC and BC models, but the z196 had the z114 as its "junior" machine.

Maybe z11 ?

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


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

z12 lifrspan

[Dave Day]

According to Wickipedia the release dates for the EC 12 and BC 12 are:

 * zEnterprise BC12 (2828 machine type), introduced on July 23, 2013
 * zEnterprise EC12 (2827 series), introduced on August 28, 2012

You have to wonder how many shops bought big into the above two 
machines, and how long they anticipated the write off time to be.


Does IBM give trade-ins on old equipment sort of like a car dealer?

If I bought a new car in 2012, and wanted to trade it in on a new 
one in 2015, I probably could expect to get 50% of my purchase price as 
a trade-in on a new model.  I wonder what the market is saying about 
this class of machine now?


--Dave


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

Re: z13 unanswered question.

[Martin Packer]

There is no "BC" machine... :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

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



From:   John McKown 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   15/01/2015 16:40
Subject:z13 unanswered question.
Sent by:IBM Mainframe Discussion List 



I have really enjoyed reading about the z13 and some of the new nifties.
And, of course, eventually IBM will give out some harder performance
number. But I'll bet there is one geek question which will not be 
answered.

How fast could a fully enabled machine mint bitcoins or other
cryptocurrency? How much power would such a machine use while doing so?
"Inquiring minds want to know!"

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become 
ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: z13 unanswered question.

[Mike Schwab]

http://www.redbooks.ibm.com/redpieces/pdfs/sg248251.pdf
PDF page 426 shows 36KW capacity and 13KW actual use.
Configuration size and load not shown.
Have you tried running a bitcoin app on a z/System?  Perhaps z/Linux
on Hercules?

On Thu, Jan 15, 2015 at 10:40 AM, John McKown
 wrote:
> I have really enjoyed reading about the z13 and some of the new nifties.
> And, of course, eventually IBM will give out some harder performance
> number. But I'll bet there is one geek question which will not be answered.
>
> How fast could a fully enabled machine mint bitcoins or other
> cryptocurrency? How much power would such a machine use while doing so?
> "Inquiring minds want to know!"
>
> --
>
> While a transcendent vocabulary is laudable, one must be eternally careful
> so that the calculated objective of communication does not become ensconced
> in obscurity.  In other words, eschew obfuscation.
>
> 111,111,111 x 111,111,111 = 12,345,678,987,654,321
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Thu, 15 Jan 2015 12:19:46 -0500, Shmuel Metz (Seymour J.)  wrote:
>
>>It's more complicated than that.
>
>To begin wth, well coded assembler routines will use DYNALLOC
>directly.
> 
Correctness is in the eye of the beholder.  Which do you consider
correct, to DALPERM or not to DALPERM, or should interfaces such
as ALLOCATE and BPXWDYN provide an option.

I hate MVS.  Its surfeit of features is not offset by the usefulness
they provide.  I suspect much of the complexity of DYNALLOC
arises from an attempt to contend with a storage constraint now
to be regarded as ridiculously small.

Allocate DDNAMEs; free them when you're done with them.
What if you exhaust TIOT entries?  Well, DYNALLOC will pick
some to reuse.  What if you really needed them?  Well,
DYNALLOC lets you set a flag on those which are not to
be reused.  And so on.

UNIX has a limit, OPEN_MAX, vaguely similar to DYNAMNBR.
If I attempt to more files than that, open() fails.  There is no
option allowing the kernel to pick some files to close and
proceed.

Simpler Is Better.  How seriously do DOS and UNIX users miss
the ability/need to specify RECFM, LRECL, BLKSIZE, etc. on
their files?

--gil

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

Re: z13 unanswered question.

[Tom Marchant]

On Thu, 15 Jan 2015 10:40:40 -0600, John McKown wrote:

>eventually IBM will give out some harder performance
>number.

LSPR has z13 included.

https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r1

-- 
Tom Marchant

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

Re: z13 unanswered question.

[John McKown]

On Thu, Jan 15, 2015 at 11:07 AM, Pfister, Nathan <
nathan.pfis...@wsscwater.com> wrote:

> Out of curiosity, have you (successfully) compiled, and used, a bitcoin
> miner on z/OS Unix?
>
>
​On the first question: No, I have not compiled a bitcoin mainer on z/OS.
So, of course, I have not run it. Nor will I because it cost real money due
to MSU usage and I'd get keel hauled for wasting money. This is "obviously"
something for a RedBook person, or IBM POK to do? Why? For the P.R. value.
"Yes! The z13 can mine bitcoins​ at 300% of the rate of the best Intel Xeon
based server. But wait! There's more! It can do it a _half_ the power cost!
Call now! Operators are standing by!" I.e. it gives IBM some street cred
with the new generation of I.T.managers who are frustrated, wanna-be
gamers. Or is this just a local phenom?


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

Another z13 questions

[R.S.]

Q1. New machine has 85 LPARs limit. Six CSS'es: 0,1,2,3,4,5. However 
last CSS can have up to 10 LPARs instead of 15.WHY? Why not 90?


Q2. Introduction of XMP (multiple CSS) machines was a big revolution on 
I/O. How does it look in this case (I mean # of CSSes and LPARs)?


Q3. HSA size. From my tests and experience typical HSA size in z9 was 
about 2GB. In z10 it was excluded from "user" memory and fixed at 16GB 
size (IMHO a lot). In EC12 it was doubled: 32GB. Now it was tripled: 
96GB. What is the rationale?



--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Another z13 questions

[zMan]

The other 5 LPARs are used by the NSA.

On Thu, Jan 15, 2015 at 1:44 PM, R.S. 
wrote:

> Q1. New machine has 85 LPARs limit. Six CSS'es: 0,1,2,3,4,5. However last
> CSS can have up to 10 LPARs instead of 15.WHY? Why not 90?
>
> Q2. Introduction of XMP (multiple CSS) machines was a big revolution on
> I/O. How does it look in this case (I mean # of CSSes and LPARs)?
>
> Q3. HSA size. From my tests and experience typical HSA size in z9 was
> about 2GB. In z10 it was excluded from "user" memory and fixed at 16GB size
> (IMHO a lot). In EC12 it was doubled: 32GB. Now it was tripled: 96GB. What
> is the rationale?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
> 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.840.228 złotych.
>
>
> --
> 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 IBM-MAIN

Re: z13 unanswered question.

[Gibney, Dave]

There never is when to "big" one is announced. Are you implying knowledge that 
there won't be a future BC z13?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Martin Packer
> Sent: Thursday, January 15, 2015 9:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z13 unanswered question.
> 
> There is no "BC" machine... :-)
> 
> 
> 
> Cheers, Martin
> 
> 
> 
> Martin Packer,
> 
> zChampion, Principal Systems Investigator,
> 
> Worldwide Banking Center of Excellence, IBM
> 
> 
> 
> +44-7802-245-584
> 
> 
> 
> email: martin_pac...@uk.ibm.com
> 
> 
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> 
> https://urldefense.proofpoint.com/v1/url?u=https://www.ibm.com/developer
> works/mydeveloperworks/blogs/MartinPacker&k=EWEYHnIvm0nsSxnW5y9VI
> w%3D%3D%0A&r=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0A&m=sQpow6UtFUti
> KN7vBhJaJANh5gPiAYgyswhggfW4bRg%3D%0A&s=f16263b57387909d061a47
> 05a05c4311a9756236cf18675dc9feaf29662fe366
> 
> 
> 
> 
> 
> 
> 
> From:   John McKown 
> 
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Date:   15/01/2015 16:40
> 
> Subject:z13 unanswered question.
> 
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> 
> 
> 
> 
> I have really enjoyed reading about the z13 and some of the new nifties.
> 
> And, of course, eventually IBM will give out some harder performance
> 
> number. But I'll bet there is one geek question which will not be
> 
> answered.
> 
> 
> 
> How fast could a fully enabled machine mint bitcoins or other
> 
> cryptocurrency? How much power would such a machine use while doing so?
> 
> "Inquiring minds want to know!"
> 
> 
> 
> --
> 
> ​
> 
> While a transcendent vocabulary is laudable, one must be eternally careful
> 
> so that the calculated objective of communication does not become
> 
> ensconced
> 
> in obscurity.  In other words, eschew obfuscation.
> 
> 
> 
> 111,111,111 x 111,111,111 = 12,345,678,987,654,321
> 
> 
> 
> Maranatha! <><
> 
> John McKown
> 
> 
> 
> --
> 
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> 
> IBM United Kingdom Limited - Registered in England and Wales with number
> 
> 741598.
> 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> 
> 
> 
> 
> 
> --
> 
> 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: z13 unanswered question.

[Chase, John]

Context plus "smiley" suggest he meant there is no "BitCoin" machine.

   -jc-

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Gibney, Dave
> Sent: Thursday, January 15, 2015 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z13 unanswered question.
> 
> There never is when to "big" one is announced. Are you implying knowledge 
> that there won't be a future
> BC z13?
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Martin Packer
> > Sent: Thursday, January 15, 2015 9:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z13 unanswered question.
> >
> > There is no "BC" machine... :-)
> >
> >
> >
> > Cheers, Martin
> >
> >
> >
> > Martin Packer,
> >
> > zChampion, Principal Systems Investigator,
> >
> > Worldwide Banking Center of Excellence, IBM
> >
> >
> >
> > +44-7802-245-584
> >
> >
> >
> > email: martin_pac...@uk.ibm.com
> >
> >
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
> >
> > https://urldefense.proofpoint.com/v1/url?u=https://www.ibm.com/develop
> > er works/mydeveloperworks/blogs/MartinPacker&k=EWEYHnIvm0nsSxnW5y9VI
> > w%3D%3D%0A&r=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0A&m=sQpow6UtFUti
> > KN7vBhJaJANh5gPiAYgyswhggfW4bRg%3D%0A&s=f16263b57387909d061a47
> > 05a05c4311a9756236cf18675dc9feaf29662fe366
> >
> >
> >
> >
> >
> >
> >
> > From:   John McKown 
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Date:   15/01/2015 16:40
> >
> > Subject:z13 unanswered question.
> >
> > Sent by:IBM Mainframe Discussion List 
> >
> >
> >
> >
> >
> >
> >
> > I have really enjoyed reading about the z13 and some of the new nifties.
> >
> > And, of course, eventually IBM will give out some harder performance
> >
> > number. But I'll bet there is one geek question which will not be
> >
> > answered.
> >
> >
> >
> > How fast could a fully enabled machine mint bitcoins or other
> >
> > cryptocurrency? How much power would such a machine use while doing so?
> >
> > "Inquiring minds want to know!"
> >
> >
> >
> > --
> >
> > 
> >
> > While a transcendent vocabulary is laudable, one must be eternally
> > careful
> >
> > so that the calculated objective of communication does not become
> >
> > ensconced
> >
> > in obscurity.  In other words, eschew obfuscation.
> >
> >
> >
> > 111,111,111 x 111,111,111 = 12,345,678,987,654,321
> >
> >
> >
> > Maranatha! <><
> >
> > John McKown
> >
> >
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >
> >
> >
> >
> > Unless stated otherwise above:
> >
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number
> >
> > 741598.
> >
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> >
> >
> >
> >
> >
> > --
> >
> > 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

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


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

Re: Another z13 questions

[R.S.]

W dniu 2015-01-15 o 20:08, zMan pisze:

The other 5 LPARs are used by the NSA.


Do you mean No Such Agency or I missed yet another overloaded acronym 
used here in mainframe context?


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Another z13 questions

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of R.S.
> Sent: Thursday, January 15, 2015 1:32 PM
> 
> W dniu 2015-01-15 o 20:08, zMan pisze:
> > The other 5 LPARs are used by the NSA.
> >
> >
> Do you mean No Such Agency or I missed yet another overloaded acronym used 
> here in mainframe context?

" 'Nonymous Spooks Agency "  (think Edward Snowden).  :-)

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


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

z13 "new"(?) characteristics from RedBook

[John McKown]

I'm reading the Redbook mentioned by Timothy Stipples on the z13. Some
"interesting" things, to me.

1) No zAAPs. So it is Java on your zIIPs now. But up to 2 zIIPs per CP may
be ordered.
1.5) LPAR can exceed 2 zIIPs per assigned CP. I.e. a CEC with 2 CPs & 4
zIIPs can have an LPAR with 1 CP and 3 zIIPs assigned to it.
2) new type of CP: IFP - Integrated Firmware Processor, like a SAP, but for
the "native PCIe" features such as 10 Gb RoGE and zEDC Express
3) Optional water cooling
4) Optional use of HVDC (High Voltage Direct Current) power.
5) SMT (hyperthreading) only on IFL and zIIP engines (not CPs). Apparently
when running SMT, the individual threads can't match the speed of a non-SMT
CP, but their aggregate power may.
6) six 8-core 5.0 Ghz processors in a single SCM. 22 nm technology.
7) SEs are 1U rack machines instead of notebooks.
8) HMC can also be in a 1U rack mounted machine (in the box? it doesn't
say).
9) Ficon Express 16S - 16G/s FICON
10) Curious statement:

If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR
is not required,
and we suggest that a Linux-only LPAR be used instead.

11) HMC remote support _ONLY_ via Internet, no more modem.



-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

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: z13 unanswered question.

[Martin Packer]

By George I think he's got it :-) - as I hope did many others.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

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



From:   "Chase, John" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   15/01/2015 19:15
Subject:Re: z13 unanswered question.
Sent by:IBM Mainframe Discussion List 



Context plus "smiley" suggest he meant there is no "BitCoin" machine.

   -jc-

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Gibney, Dave
> Sent: Thursday, January 15, 2015 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z13 unanswered question.
> 
> There never is when to "big" one is announced. Are you implying 
knowledge that there won't be a future
> BC z13?
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Martin Packer
> > Sent: Thursday, January 15, 2015 9:32 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z13 unanswered question.
> >
> > There is no "BC" machine... :-)
> >
> >
> >
> > Cheers, Martin
> >
> >
> >
> > Martin Packer,
> >
> > zChampion, Principal Systems Investigator,
> >
> > Worldwide Banking Center of Excellence, IBM
> >
> >
> >
> > +44-7802-245-584
> >
> >
> >
> > email: martin_pac...@uk.ibm.com
> >
> >
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
> >
> > https://urldefense.proofpoint.com/v1/url?u=https://www.ibm.com/develop
> > er works/mydeveloperworks/blogs/MartinPacker&k=EWEYHnIvm0nsSxnW5y9VI
> > w%3D%3D%0A&r=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0A&m=sQpow6UtFUti
> > KN7vBhJaJANh5gPiAYgyswhggfW4bRg%3D%0A&s=f16263b57387909d061a47
> > 05a05c4311a9756236cf18675dc9feaf29662fe366
> >
> >
> >
> >
> >
> >
> >
> > From:   John McKown 
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Date:   15/01/2015 16:40
> >
> > Subject:z13 unanswered question.
> >
> > Sent by:IBM Mainframe Discussion List 

> >
> >
> >
> >
> >
> >
> >
> > I have really enjoyed reading about the z13 and some of the new 
nifties.
> >
> > And, of course, eventually IBM will give out some harder performance
> >
> > number. But I'll bet there is one geek question which will not be
> >
> > answered.
> >
> >
> >
> > How fast could a fully enabled machine mint bitcoins or other
> >
> > cryptocurrency? How much power would such a machine use while doing 
so?
> >
> > "Inquiring minds want to know!"
> >
> >
> >
> > --
> >
> > 
> >
> > While a transcendent vocabulary is laudable, one must be eternally
> > careful
> >
> > so that the calculated objective of communication does not become
> >
> > ensconced
> >
> > in obscurity.  In other words, eschew obfuscation.
> >
> >
> >
> > 111,111,111 x 111,111,111 = 12,345,678,987,654,321
> >
> >
> >
> > Maranatha! <><
> >
> > John McKown
> >
> >
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >
> >
> >
> >
> > Unless stated otherwise above:
> >
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number
> >
> > 741598.
> >
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> >
> >
> >
> >
> >
> > --
> >
> > 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

**
Information contained in this e-mail message and in any attachments 
thereto is confidential. If you are not the intended recipient, please 
destroy this message, delete any copies held on your systems, notify the 
sender immediately, and refrain from using or disclosing all or any part 
of its content to any other person.


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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: z13 "new"(?) characteristics from RedBook

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of John McKown
> Sent: Thursday, January 15, 2015 1:49 PM
> 
> I'm reading the Redbook mentioned by Timothy Stipples on the z13. Some 
> "interesting" things, to me.
> 
> [ snip ]
> 10) Curious statement:
> 
> If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR is 
> not required, and we
> suggest that a Linux-only LPAR be used instead.
> 

I believe that's because z/VM is "significantly cheaper" if run in an IFL-only 
LPAR.

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


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

Re: Another z13 questions

[John McKown]

On Thu, Jan 15, 2015 at 1:08 PM, zMan  wrote:

> The other 5 LPARs are used by the NSA.
>
>
​Don't be silly. It only 2 LPARs for the NSA. The other three are one each
for the CIA, FBI, and IRS (to erase email messages, logs, and backups). ​


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

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: Compile COBOL Programs In 64 Bit.

[Steve Thompson]

On 01/14/2015 07:51 PM, Tom Ross wrote:


I (like the other poster) would like to know what you would do with AMODE 64 
COBOL?
Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
code?



Well, if one is interfacing with another IBM product that has its 
data above the BAR, then I could see COBOL needing to be able to 
get to that storage.


CICS and Java apps come to mind.

As for running slower, isn't that a function of the multi-level 
DAT for support of chained segment tables to handle 64bit addressing?


IF 64bit is that much slower, that you would have to give a 
warning, shouldn't that warning have been given to the C/C++ and 
Java crowd? OK, the C/C++ crowd? And the HLASM and PLX (or PL/AS, 
or whatever name it has now) programmers?


It seems that being slower did not / does not seem to slow down 
CICS/TS 5.x or DB2. Just say'n.


Regards,
Steve Thompson

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

Re: z13 "new"(?) characteristics from RedBook

[John McKown]

On Thu, Jan 15, 2015 at 1:53 PM, Chase, John  wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of John McKown
> > Sent: Thursday, January 15, 2015 1:49 PM
> >
> > I'm reading the Redbook mentioned by Timothy Stipples on the z13. Some
> "interesting" things, to me.
> >
> > [ snip ]
> > 10) Curious statement:
> > 
> > If only Linux on z Systems is to be run under z/VM, then a z/VM mode
> LPAR is not required, and we
> > suggest that a Linux-only LPAR be used instead.
> > 
>

​Ah. The verbiage was ​misleading, to me, due to my lack of knowledge about
z/VM and z/Linux. I read that as in an LPAR _without_ z/VM. But in a
Linux-only defined LPAR running multiple Linux guests under z/VM makes a
lot more sense. I don't know how my eyes just skipped over the "under z/MV"
at the front part of the sentence. Perhaps this is why my high school
English teacher kept scolding me for using long sentences.



>
> I believe that's because z/VM is "significantly cheaper" if run in an
> IFL-only LPAR.
>
> -jc-
>


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

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: z13 unanswered question.

[Mike Schwab]

Most bitcoin earning sites require user interaction.

http://www.bitcoinplus.com/howbitcoinworks
This sites (and others) supply you with an application that you run.
When a problem is solved, you get a payment in bitcoins.  Since it
takes a lot of computing time to solve one problem, the problem is
split up and so is the payment.

On Thu, Jan 15, 2015 at 1:15 PM, Chase, John  wrote:
> Context plus "smiley" suggest he meant there is no "BitCoin" machine.
>
>-jc-

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: z13 "new"(?) characteristics from RedBook

[Mark Post]

>>> On 1/15/2015 at 02:49 PM, John McKown  wrote: 
> 10) Curious statement:
> 
> If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR
> is not required,
> and we suggest that a Linux-only LPAR be used instead.
> 

I would say that's true today, not just for newer machines.  A z/VM mode LPAR 
allows you to mix CPs and IFLs, which wouldn't be needed if you're only running 
z/VM and Linux.


Mark Post

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

Re: z13 "new"(?) characteristics from RedBook

[Mark Post]

>>> On 1/15/2015 at 02:53 PM, "Chase, John"  wrote: 
> I believe that's because z/VM is "significantly cheaper" if run in an 
> IFL-only LPAR.

That certainly used to be true, but I'm not at all sure it still is the case.  
If I'm remembering right, z/VM licensing is the same for both CPs and IFLs.  
It's just that if you _do_ have a machine with both and you create a z/VM mode 
LPAR, then the z/VM licensing algorithm includes _all_ those processors instead 
of just CPs or just IFLs.


Mark Post

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

Re: z13 unanswered question.

[Phil Smith III]

Notwithstanding the BC/Bitcoin humor, no, IBM said there will be no EC/BC
distinction. Part of this announcement is simplification-no EC/BC, no
"System z" vs. "zEnterprise". This is a good thing.

 

Now if IBM can just get people to stop saying "zSeries" (now dead for a
decade!). Of course, there are still IBMers with "zSeries" in their titles,
including folks in sales. Pretty sad.back in the day, the IBM branding
police would have had those folks executed!

 

(I noticed that several of the IBM releases yesterday still said "zNext" in
a few places-somebody didn't do a good job of updating after the name got
finalized.)

 

.phsiii


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

Re: z13 unanswered question.

[Martin Packer]

Or "zeeSerious" or "zoss" or "zedoss" or "zeeoss" - all of which I've 
heard many times over. :-) Or even "zee oh ess". :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

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

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



From:   Phil Smith III 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   15/01/2015 20:27
Subject:Re: z13 unanswered question.
Sent by:IBM Mainframe Discussion List 



Notwithstanding the BC/Bitcoin humor, no, IBM said there will be no EC/BC
distinction. Part of this announcement is simplification-no EC/BC, no
"System z" vs. "zEnterprise". This is a good thing.

 

Now if IBM can just get people to stop saying "zSeries" (now dead for a
decade!). Of course, there are still IBMers with "zSeries" in their 
titles,
including folks in sales. Pretty sad.back in the day, the IBM branding
police would have had those folks executed!

 

(I noticed that several of the IBM releases yesterday still said "zNext" 
in
a few places-somebody didn't do a good job of updating after the name got
finalized.)

 

.phsiii


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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: Dataset PACK profile

[Joel Ewing]

On 01/14/2015 06:33 PM, Dan wrote:
> I have a strange memory of a previous thread about ISPF PACKing (probably pre 
> 1995).
> 
> I seem to recall someone from IBM (in the ISPF area) posting a query about 
> the use of the ISPF PACK option.  I believe they were hoping to remove the 
> function.
> I've searched the archives but can't seem to find anything.
> My recollection of the thread was that IBM wanted to remove the capability of 
> turning ON packing but any member that was already packed would remain packed 
> (unless the user requested PACK OFF).  As PACK is still an option that can be 
> enabled someone must have made a strong enough argument to keep the function 
> (although I don't see why).
> 
> Does anyone else recall that discussion or was I dreaming? :D
> If you do recall it, why was it not crippled?
> 
> Thanks,
> Dan D.
> 

I also recall a discussion of this topic with IBMers involved, but it's
been too long to remember the context.  Perhaps it might have been a
query raised by an IBMer at some SHARE Free For All session rather than
an on-line thread.  I remember being one who indicated eliminating PACK
would have caused our installation some problems at the time.  We were
using PACK for long-term storage of source code in PDS libraries, some
of which would have been too large for the single-volume PDS limit
without PACK.  At the time it would have been a non-trivial task to go
to larger 3390 emulated volumes or to logically divide the large
libraries into smaller ones.

I think the idea behind the question was an assumption that cheap DASD
had eliminated the motivation for PACK, or that somehow the hardware
compression feature could be used as a replacement; but data set size
constraints had not been fully considered and at the time hardware
compression was more CP-intensive and also unsupported for PDS/PDSE data
sets.

If a PDSE library could have been multi-volume, that might have been one
path to eliminate our requirement for PACK.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: z13 unanswered question.

[Gibney, Dave]

This could then be a problem for me. The LSPR link has the smallest 2964-401 
with 1 CP and 31 MSU
My current z9-L03 is 28 MSU, but I am capping at 16. But my major vendor (SAG) 
doesn't accept subcapacity.
And, I was seriously "burnt" when we last had a uniprocessor. The smallest 
multi is 60 MSU

My thoughts lately have been that our prepaid maintenance on the z9 would be 
expiring about the same timeframe as a zNext-BC

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Phil Smith III
> Sent: Thursday, January 15, 2015 12:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z13 unanswered question.
> 
> Notwithstanding the BC/Bitcoin humor, no, IBM said there will be no EC/BC
> distinction. Part of this announcement is simplification-no EC/BC, no "System
> z" vs. "zEnterprise". This is a good thing.
> 
> 
> 
> Now if IBM can just get people to stop saying "zSeries" (now dead for a
> decade!). Of course, there are still IBMers with "zSeries" in their titles,
> including folks in sales. Pretty sad.back in the day, the IBM branding police
> would have had those folks executed!
> 
> 
> 
> (I noticed that several of the IBM releases yesterday still said "zNext" in a 
> few
> places-somebody didn't do a good job of updating after the name got
> finalized.)
> 
> 
> 
> .phsiii
> 
> 
> --
> 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: Dataset PACK profile now PDSE's

[Ed Gould]

On Jan 15, 2015, at 2:36 PM, Joel Ewing wrote:

--SNIP---
If a PDSE library could have been multi-volume, that might have  
been one

path to eliminate our requirement for PACK.

--

Joel:
I could SWEAR that in one of the announcements in the last year (or  
so) that PDSE's would support multivolume. Or am I just incorrect.


Ed

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

Re: Boston - what a place

[Ed Gould]

On Jan 13, 2015, at 8:10 AM, Paul Gilmartin wrote:


On Tue, 13 Jan 2015 00:05:53 -0600, Ed Gould wrote:



I'm originally from North Dakota and experienced -41F in the winter
and 108F in the summer.  I finally had enough of that and moved to
Colorado 18 years ago.
Bill


So what is better -41 year around in colorado or the occasion  
+106's ?



!?  http://en.wikipedia.org/wiki/U.S._state_temperature_extremes

And:  http://www.eol.ucar.edu/cgi-bin/weather.cgi? 
site=fl&units=english&period=monthly


(reading from the graph) shows -15F and +60F in the past 30 days.   
No -41F.

-SNIP---



So who said today? seriously some places in Colorado get COLD... OK  
some time in the winter.
Now one time in the 80's chicago got -20  ... which was cold!!! I  
cannot imagine what -41 would be.


Ed

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

Re: Boston - what a place

[Grinsell, Don]

It basically turns it into a time function.  At -41 you freeze that much 
faster.  I grew up in the Icebox of the Nation, International Falls, Minnesota 
and experienced temps in the -30 to -40 range regularly.  We just bundled up 
and went about our business as quickly as possible.  Thankfully I saw the light 
and migrated to the banana belt of the Rocky Mountains.  It's a balmy 16F above 
today!

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"Now -- you will stay in the Comfy Chair until lunch time, with only a cup of 
coffee at eleven."
~ Cardinal Ximinez (aka Michael Palin of Monty Python's Flying Circus)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Thursday, January 15, 2015 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Boston - what a place

On Jan 13, 2015, at 8:10 AM, Paul Gilmartin wrote:

> On Tue, 13 Jan 2015 00:05:53 -0600, Ed Gould wrote:
>>
>>> I'm originally from North Dakota and experienced -41F in the winter 
>>> and 108F in the summer.  I finally had enough of that and moved to 
>>> Colorado 18 years ago.
>>> Bill
>>
>> So what is better -41 year around in colorado or the occasion
>> +106's ?
>>
> !?  http://en.wikipedia.org/wiki/U.S._state_temperature_extremes
>
> And:  http://www.eol.ucar.edu/cgi-bin/weather.cgi? 
> site=fl&units=english&period=monthly
>
> (reading from the graph) shows -15F and +60F in the past 30 days.   
> No -41F.
> -SNIP---


So who said today? seriously some places in Colorado get COLD... OK some time 
in the winter.
Now one time in the 80's chicago got -20  ... which was cold!!! I cannot 
imagine what -41 would be.

Ed

--
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: Compile COBOL Programs In 64 Bit.

[Tom Marchant]

On Wed, 14 Jan 2015 16:51:52 -0800, Tom Ross wrote:

>Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
>code?

I have been puzzling over this since I first read it yesterday. It is difficult 
for me to 
understand why the processor would be significantly slower when running AMODE 
64.

Certainly a program that does nothing but a very large number of L and ST 
instructions 
widely dispersed across memory would run a little faster than an equivalent 
program that 
does an equal number of LG and STG instructions would access twice as much 
memory 
and that could result in more cache misses, hence increased CPU time. Perhaps 
there are 
other situations that could cause an increase in CPU time.

There is another factor, though, that makes this understandable, to me at 
least. The last I 
heard, the only way that LE enabled programs would run AMODE 64 is with XPLINK 
64 program 
linkage. When one program calls another using XPLINK linkage that is already 
initialized, the 
linkage is a little faster than standard linkage. However, when an XPLINK 
program calls a 
non-xplink program, the linkage is MUCH slower.

Why does this matter? Any time a system service must be called that will use 
standard linkage, 
LE must switch between XPLINK and non-XPLINK. One such system service involves 
I/O. GET 
and PUT are called using standard linkage, so any XPLINK program that does lots 
of GETs and/or 
PUTs will suffer from additional linkage overhead.

-- 
Tom Marchant

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

Re: z13 "new"(?) characteristics from RedBook

[J O Skip Robinson]

The Linux-only option is not new. Our z12 and z196 Linux-under-VM LPARs are 
defined with the 'LINUX only' option. I don't recall an explicit reason for the 
recommendation.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Thursday, January 15, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z13 "new"(?) characteristics from RedBook

>>> On 1/15/2015 at 02:53 PM, "Chase, John"  wrote: 
> I believe that's because z/VM is "significantly cheaper" if run in an 
> IFL-only LPAR.

That certainly used to be true, but I'm not at all sure it still is the case.  
If I'm remembering right, z/VM licensing is the same for both CPs and IFLs.  
It's just that if you _do_ have a machine with both and you create a z/VM mode 
LPAR, then the z/VM licensing algorithm includes _all_ those processors instead 
of just CPs or just IFLs.


Mark Post

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

Re: z13 "new"(?) characteristics from RedBook

[Jerry Whitteridge]

Linux Only indicates using IFL's only which are not kneecapped like a GP engine 
may be.  My IFL's are dedicated to the LPAR, unlike the Shared GP engines.

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Thursday, January 15, 2015 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z13 "new"(?) characteristics from RedBook

The Linux-only option is not new. Our z12 and z196 Linux-under-VM LPARs are 
defined with the 'LINUX only' option. I don't recall an explicit reason for the 
recommendation.  

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Post
Sent: Thursday, January 15, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z13 "new"(?) characteristics from RedBook

>>> On 1/15/2015 at 02:53 PM, "Chase, John"  wrote: 
> I believe that's because z/VM is "significantly cheaper" if run in an 
> IFL-only LPAR.

That certainly used to be true, but I'm not at all sure it still is the case.  
If I'm remembering right, z/VM licensing is the same for both CPs and IFLs.  
It's just that if you _do_ have a machine with both and you create a z/VM mode 
LPAR, then the z/VM licensing algorithm includes _all_ those processors instead 
of just CPs or just IFLs.


Mark Post

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


"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

Re: IKJ56220I max # of datasets reached

[Shmuel Metz (Seymour J.)]

In <2185420056656673.wa.paulgboulderaim@listserv.ua.edu>, on
01/15/2015
   at 11:53 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Correctness is in the eye of the beholder.  Which do you consider
>correct, to DALPERM or not to DALPERM,

Both.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z13 "new"(?) characteristics from RedBook

[R.S.]

W dniu 2015-01-15 o 23:07, J O Skip Robinson pisze:

The Linux-only option is not new. Our z12 and z196 Linux-under-VM LPARs are 
defined with the 'LINUX only' option. I don't recall an explicit reason for the 
recommendation.



IMHO Linux-only LPAR type is older than VM LPAR.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.840.228 zotych.


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

Re: z13 "new"(?) characteristics from RedBook

[Shane Ginnane]

On Thu, 15 Jan 2015 13:18:08 -0700, Mark Post wrote:

 On 1/15/2015 at 02:53 PM, "Chase, John"  wrote: 
>> I believe that's because z/VM is "significantly cheaper" if run in an 
>> IFL-only LPAR.
>
>That certainly used to be true, but I'm not at all sure it still is the case.  
>If I'm remembering right, z/VM licensing is the same for both CPs and IFLs.  
>It's just that if you _do_ have a machine with both and you create a z/VM mode 
>LPAR, then the z/VM licensing algorithm includes _all_ those processors 
>instead of just CPs or just IFLs.

I note a SoD to include KVM on the z13.
Hopefully this should allow configurations that make this debate moot - z/VM 
should be not needed at all.
I wonder how that affects SUSE install scripts ...

Shane ...

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

Re: z13 "new"(?) characteristics from RedBook

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Shane Ginnane
> Sent: Thursday, January 15, 2015 3:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z13 "new"(?) characteristics from RedBook
> 
> On Thu, 15 Jan 2015 13:18:08 -0700, Mark Post wrote:
> 
>  On 1/15/2015 at 02:53 PM, "Chase, John"  wrote:
> >> I believe that's because z/VM is "significantly cheaper" if run in an
> >> IFL-only LPAR.
> >
> >That certainly used to be true, but I'm not at all sure it still is the 
> >case.  If I'm
> remembering right, z/VM licensing is the same for both CPs and IFLs.  It's 
> just
> that if you _do_ have a machine with both and you create a z/VM mode LPAR,
> then the z/VM licensing algorithm includes _all_ those processors instead of
> just CPs or just IFLs.
> 
> I note a SoD to include KVM on the z13.
> Hopefully this should allow configurations that make this debate moot - z/VM
> should be not needed at all.

If you can live with 85 or less zLinux instances :)

> I wonder how that affects SUSE install scripts ...
> 
> Shane ...
> 
> --
> 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: Dataset PACK profile now PDSE's

[Joel Ewing]

On 01/15/2015 03:29 PM, Ed Gould wrote:
> On Jan 15, 2015, at 2:36 PM, Joel Ewing wrote:
>> --SNIP---
>> If a PDSE library could have been multi-volume, that might have been one
>> path to eliminate our requirement for PACK.
>>
>> -- 
> Joel:
> I could SWEAR that in one of the announcements in the last year (or so)
> that PDSE's would support multivolume. Or am I just incorrect.
> 
> Ed
> 

z/OS 2.1 "DFSMS Using Data Sets" (2014) still lists single-volume
restriction for PDSE.  But APAR "OA45917 NON-AMS PDSE CAN BE ALLOCATED
AS MULTIVOLUME" reports that an unusable "not valid" PDSE can actually
be allocated as multivolume via JCL in z/OS 2.1, closed FIN 2014-09-04.
 Perhaps the fix will be to make it valid?  In any event too late for me
-- been retired 3 1/2 years.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Dataset PACK profile now PDSE's

[Paul Gilmartin]

On Thu, 15 Jan 2015 17:31:44 -0600, Joel Ewing  wrote:

>On 01/15/2015 03:29 PM, Ed Gould wrote:
>> On Jan 15, 2015, at 2:36 PM, Joel Ewing wrote:
>>> --SNIP---
>>> If a PDSE library could have been multi-volume, that might have been one
>>> path to eliminate our requirement for PACK.
>>>
>>> --
>> Joel:
>> I could SWEAR that in one of the announcements in the last year (or so)
>> that PDSE's would support multivolume. Or am I just incorrect.
>> 
Wouldn't EAV be an alternative solution?  Or is there another restriction?
(54 GB is *so* 20th Century.)

>z/OS 2.1 "DFSMS Using Data Sets" (2014) still lists single-volume
>restriction for PDSE.  But APAR "OA45917 NON-AMS PDSE CAN BE ALLOCATED
>AS MULTIVOLUME" reports that an unusable "not valid" PDSE can actually
>be allocated as multivolume via JCL in z/OS 2.1, closed FIN 2014-09-04.
> Perhaps the fix will be to make it valid?  In any event too late for me
>-- been retired 3 1/2 years.

-- gil

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

Re: Boston - what a place

[Scott Ford]

Ed,

I saw -30 back home in Indiana, I was out in it, with 2+ feet of snow, man it 
was cold and nasty

Scott ford
www.identityforge.com
from my IPAD




> On Jan 15, 2015, at 4:34 PM, Ed Gould  wrote:
> 
>> On Jan 13, 2015, at 8:10 AM, Paul Gilmartin wrote:
>> 
>>> On Tue, 13 Jan 2015 00:05:53 -0600, Ed Gould wrote:
>>> 
 I'm originally from North Dakota and experienced -41F in the winter
 and 108F in the summer.  I finally had enough of that and moved to
 Colorado 18 years ago.
 Bill
>>> 
>>> So what is better -41 year around in colorado or the occasion +106's ?
>>> 
>> !?  http://en.wikipedia.org/wiki/U.S._state_temperature_extremes
>> 
>> And:  
>> http://www.eol.ucar.edu/cgi-bin/weather.cgi?site=fl&units=english&period=monthly
>> 
>> (reading from the graph) shows -15F and +60F in the past 30 days.  No -41F.
>> -SNIP---
> 
> 
> So who said today? seriously some places in Colorado get COLD... OK some time 
> in the winter.
> Now one time in the 80's chicago got -20  ... which was cold!!! I cannot 
> imagine what -41 would be.
> 
> Ed
> 
> --
> 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 Launches the z13 Mainframe

[Timothy Sipples]

John Baker asks:
>Will IBM be releasing a new edition of the z/Architecture Principles of
>Operation publication, or will the SIMD instruction set be documented in a
>separate publication, as was the case with the earlier vector facilities?

I'd predict the former.

As a conceptual preview (if you'd like), take a look at POWER processors'
VSX instructions. That'd be good technical grounding if you're anxious to
do some reading. Treat VSX as inspirational.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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

IBM Launches the z13 Mainframe

[Timothy Sipples]

John McKown writes:
>I think I understand where you're coming from.

I'm glad somebody does. :-)

>But this is, in and of itself, a "nasty EBCDIC" problem
>because code on z/OS generally _assumes_ that character
>data is encoded in CP-037 (historic batch?), or maybe
>IBM-1047 (UNIX).

Yes, you're describing interoperations with EBCDIC-encoded data (and other
programs that operate on such). Often nice to have no matter where Program
B runs if Program A operates on EBCDIC.

Look, I think too many people have this point exactly backwards, and it's
an important point. (And not the first time we've discussed this.) You can
bring a program that operates on ASCII or Unicode (or McKowncode) to z/OS
without lifting a finger with respect to EBCDIC support. Zip, zero, nada.
That's common and getting more common. Let's call that a "Phase 1" port,
and you might very well stop there.

Now, if it happens, in Phase 2 (or Phase 8), you may decide that it'd be
nice if your Program B interoperates with the EBCDIC-encoded data Program A
stores. You have two basic options:

1. Program B could run somewhere else, and you'd have to figure out how to
deal with EBCDIC-encoded data over the wire. (Maybe the operating system or
middleware help you do that.)

2. Program B runs on z/OS, and in addition to all the wire options you have
other options -- the world is your EBCDIC oyster.

Which is better? I'd vote for Option #2. There is/are more flexibility and
more opportunities for providing interoperability as you wish.

BUT that EBCDIC interoperability is NOT a prerequisite to run on z/OS.
Interoperability is ONLY a prerequisite if there is a requirement for
interoperability. That requirement is a completely separate matter, if it
even exists, when it exists.

Very, very important point here, worth practicing. Insist on EBCDIC
interoperability in Phase 1 where no such interoperability exists today
and, well, you're going to have fewer programs on z/OS and have less
ability to make interoperability happen well.

Actually, you said it very well earlier, John, in your Java example: you
just move a Java program over, as-is, compiled, and it runs, unmodified.
There's nothing you *have* to do unless you wish, for other reasons. The
same is true with, for example, C. Compile your C program in ASCII in z/OS
UNIX, run it in ASCII -- no problem. Works great.

EBCDIC interoperability isn't the only example of an attribute that is nice
to have but not a prerequisite to run an application on z/OS. Here are a
couple other examples: support for SMP/E installation and maintenance, SMF
record generation. I suppose some people might stomp their feet and throw a
temper tantrum, insisting on these two (and perhaps other) attributes
before they'll let an application run on "their" z/OS, but that's their
hangup, not z/OS's.

So let's be very careful here to stick to the facts, OK? Fact: EBCDIC
support is NOT a prerequisite to bring a program to z/OS and run it there.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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: Dataset PACK profile now PDSE's

[Joel Ewing]

On 01/15/2015 06:08 PM, Paul Gilmartin wrote:
> On Thu, 15 Jan 2015 17:31:44 -0600, Joel Ewing  wrote:
> 
>> On 01/15/2015 03:29 PM, Ed Gould wrote:
>>> On Jan 15, 2015, at 2:36 PM, Joel Ewing wrote:
 --SNIP---
 If a PDSE library could have been multi-volume, that might have been one
 path to eliminate our requirement for PACK.

 --
>>> Joel:
>>> I could SWEAR that in one of the announcements in the last year (or so)
>>> that PDSE's would support multivolume. Or am I just incorrect.
>>>
> Wouldn't EAV be an alternative solution?  Or is there another restriction?
> (54 GB is *so* 20th Century.)
> 
>> z/OS 2.1 "DFSMS Using Data Sets" (2014) still lists single-volume
>> restriction for PDSE.  But APAR "OA45917 NON-AMS PDSE CAN BE ALLOCATED
>> AS MULTIVOLUME" reports that an unusable "not valid" PDSE can actually
>> be allocated as multivolume via JCL in z/OS 2.1, closed FIN 2014-09-04.
>> Perhaps the fix will be to make it valid?  In any event too late for me
>> -- been retired 3 1/2 years.
> 
> -- gil
> 

PDSEs were originally also restricted to 65535 tracks per volume, but I
notice that restriction was relieved at least by z/OS 1.10.  It's
probable that even 3390-27's would have been large enough to have
allowed our installation to comfortably convert to unPACKed members in
either a PDS or PDSE data set, but we were just beginning to phase in
some 3390-27's when I retired, and at that point there was no motivation
to expend unnecessary effort to change PDS PACK conventions that were
working.

The decision for an installation to use larger volume sizes, even a
3390-27, has implications for backup, recovery, DR support, and DASD
management, which may or may not make that an appropriate or quick
solution; although it is nice to have that alternative if no other
solution exists.  I would think it preferable to have the option of
multivolume PDSEs, so that the decision of maximum installation DASD
volume size could be based on other considerations and not be forced
just by the requirements of a few exceptional data sets.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Boston - what a place

[Ed Gould]

Scott:

If I recall correctly I did go to work that day. Amazingly the EL was  
still running.



Ed

On Jan 15, 2015, at 7:38 PM, Scott Ford wrote:


Ed,

I saw -30 back home in Indiana, I was out in it, with 2+ feet of  
snow, man it was cold and nasty


Scott ford
www.identityforge.com
from my IPAD




On Jan 15, 2015, at 4:34 PM, Ed Gould   
wrote:



On Jan 13, 2015, at 8:10 AM, Paul Gilmartin wrote:


On Tue, 13 Jan 2015 00:05:53 -0600, Ed Gould wrote:

I'm originally from North Dakota and experienced -41F in the  
winter

and 108F in the summer.  I finally had enough of that and moved to
Colorado 18 years ago.
Bill


So what is better -41 year around in colorado or the occasion  
+106's ?



!?  http://en.wikipedia.org/wiki/U.S._state_temperature_extremes

And:  http://www.eol.ucar.edu/cgi-bin/weather.cgi? 
site=fl&units=english&period=monthly


(reading from the graph) shows -15F and +60F in the past 30  
days.  No -41F.

-SNIP---



So who said today? seriously some places in Colorado get COLD...  
OK some time in the winter.
Now one time in the 80's chicago got -20  ... which was cold!!! I  
cannot imagine what -41 would be.


Ed

- 
-

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: z13 unanswered question.

[Timothy Sipples]

>Nor will I because it cost real money due
>to MSU usage and I'd get keel hauled for wasting money.

First of all, I'm quite sure all computing has costs. Except

Unutilized sub-peak 4HRA capacity is as close to free as anything in
computing. Your time is not free, though.

So, just put your Bitcoin mining (or whatever else you want to have fun
with) in a basement/cellar WLM service class. I'm assuming trivial disk
storage requirements, a fair assumption here.

I recall submitting jobs into bottom-of-the-barrel work queues in college.
Most of the time they completed, eventually, and nobody else cared. Idle
time was just wasted time if not consumed. Has this principle been
forgotten? I hope not.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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: Boston - what a place

[Scott Ford]

Ed,

We had a crowned road, lived south of Indy. The ditch along side the road was 
even with the road. We had a neighbor abandon his car and jump and literally 
disappeared in the drift.
My father and I went to get boots and etc. on and finally he surfaced from the 
snow.

Scott ford
www.identityforge.com
from my IPAD




> On Jan 15, 2015, at 11:42 PM, Ed Gould  wrote:
> 
> Scott:
> 
> If I recall correctly I did go to work that day. Amazingly the EL was still 
> running.
> 
> 
> Ed
> 
>> On Jan 15, 2015, at 7:38 PM, Scott Ford wrote:
>> 
>> Ed,
>> 
>> I saw -30 back home in Indiana, I was out in it, with 2+ feet of snow, man 
>> it was cold and nasty
>> 
>> Scott ford
>> www.identityforge.com
>> from my IPAD
>> 
>> 
>> 
>> 
 On Jan 15, 2015, at 4:34 PM, Ed Gould  wrote:
 
> On Jan 13, 2015, at 8:10 AM, Paul Gilmartin wrote:
> 
>> On Tue, 13 Jan 2015 00:05:53 -0600, Ed Gould wrote:
>> 
>> I'm originally from North Dakota and experienced -41F in the winter
>> and 108F in the summer.  I finally had enough of that and moved to
>> Colorado 18 years ago.
>> Bill
> 
> So what is better -41 year around in colorado or the occasion +106's ?
> 
 !?  http://en.wikipedia.org/wiki/U.S._state_temperature_extremes
 
 And:  
 http://www.eol.ucar.edu/cgi-bin/weather.cgi?site=fl&units=english&period=monthly
 
 (reading from the graph) shows -15F and +60F in the past 30 days.  No -41F.
 -SNIP---
>>> 
>>> 
>>> So who said today? seriously some places in Colorado get COLD... OK some 
>>> time in the winter.
>>> Now one time in the 80's chicago got -20  ... which was cold!!! I cannot 
>>> imagine what -41 would be.
>>> 
>>> Ed
>>> 
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: z13 unanswered question.

[Timothy Sipples]

Dave Gibney writes:
>This could then be a problem for me.

Phil Smith wrote:
>IBM said there will be no EC/BC distinction. Part of this
>announcement is simplification-no EC/BC, no
>"System z" vs. "zEnterprise". This is a good thing.

Dave, I like what Phil wrote. Take a look at what he wrote and also what he
didn't write.

As a random observation, Apple offers their iPhone 6 in several different
configurations varying in storage (16, 64, and 128GB), color, and (in a few
cases) localization (e.g. Wi-Fi frequencies vary a bit). They're all Apple
iPhone 6 smartphones. They are not iPhone 6EC ("Except China"), iPhone 6WJ
("Wi-Fi Japan"), or iPhone 6SC ("Saudi Compliant") smartphones. Apple
recently (within the past couple weeks) introduced a SIM-free/unlocked
iPhone 6 in the United States. That, too, is an iPhone 6. It's neither an
iPhone 6SF nor an iPhone 6BC ("Before Calling," insert SIM). They're all
iPhone 6 smartphones.

IBM has many, many configurations of z13, zBC12, and zEC12 servers
available to order today, for purchase or lease, tailored to your specific
needs. In terms of physical model choices we currently offer the following:

Machine Type 2964 Models N30, N63, N96, NC9, NE1
Machine Type 2828 Models H06, H13
Machine Type 2827 Models H20, H43, H66, H89, HA1

At least one of these configurations would be a superb choice for your
machine upgrade, today. Just contact your friendly IBM representative, or
drop me a note if you don't know who that person is. IBM has announced
general availability (GA) of Machine Type 2964 for March 9, 2015, though
(as noted in the announcement letter) a few optional features have later
planned GA dates.

I'm confident IBM will introduce new models, configurations, and features
into the indefinite future, and I'm confident you'll also have great
upgrade choices in the future, too.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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

AW: Re: SMF RDW

[Peter Hunkeler]

>>I just want to understand ?how?.
 >Why?


I genrally say there is no stupid question, but this one is an exception. There 
is no use in asking why someone wants to understand how something works. The OP 
stated that he would like to get a deeper understanding. That should suffice to 
provide information if available instead tring trying to get justification on 
the why.


No offence intended, Elardus, but you just did answer in a similar way to my 
query yesterday. I clearly stated that I'm curious to understand how OPEN 
works. I'm a curious guy.

> I'm asking because you can't use RDW directly with standard methods.


So you don't consider BSAM a standard way of working with data? I do not say it 
is used very often in all days programming, but I still consider this a 
standard method. And you do, well actually you must deal with RDWs and even 
BDWs yourself.


--
Peter Hunkeler




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

AW: SMF RDW

[Peter Hunkeler]

hope someone can help. I try to understand how a SMF RDW works. Basically I 
have no problems to understand ?the whole thing? as long as the record is not 
?spanned?. To make it clearer: For example a RDW (first 4 Bytes) of 
?33.14.01.00?. OK, x?3314? tells me that the record is 13.076 Bytes long, but 
how to deal with the remaining part the ?0100?? The only thing I know is that 
the record is spanned actually. Does this mean that the next 256 Bytes ?after? 
the first 13.076 Bytes belong together or how is this calculated?!




RDWs are 4 bytes. The first two are always the lenght of the record. The fourth 
byte is reserved and is always x'00'. The third byte, the one you're talking 
about, is always x'00' unless the record format is VBS, .i.e. spanned records.


With non spanned records, a logical record must always fit into a single block. 
For spanned format, the logical records may be split into multiple parts, each 
one being written to a separat block. So, there is a first part, there are zero 
or more intermiediate parts, and there is a final part. The rightmost 2 bits of 
the third byte in the RDW indicat just this:
x'01' -> first part, .i.e. a new spanned record starts here.
x'11' -> intermediate part. Note that there is no sequence number. The sequence 
is given by the sequence of the blocks.
x'10' -> The final part, .i.e. the end of the spannded record.


Note that even with spanned format, non-spanned records are allowed besides 
spanned records. I.e. there may be records that do fit in a block, and they 
will have the third byte as x'00'.


--
Peter Hunkeler



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

Re: z12 lifrspan

[Timothy Sipples]

Dave Day writes:
>Does IBM give trade-ins on old equipment sort of like a car dealer?

Sure, you can do that. We'll frequently offer trade-in credit for and haul
out your non-IBM equipment, too. Just ask your friendly IBM representative.

Better yet (or in addition), we offer machine upgrades. You can upgrade
your N-1 or N-2 model generation z System to the latest (N) model
generation. We remove older parts (such as main processors) and replace
them with the new technology parts, and you then have a new model. Your
machine retains its same serial number. The IBM term of art for this
offering is an "MES." It's much simpler than moving whole machines in/out
of your data centers. Cabling, for example, is much easier.

We ask you to plan for an 8 hour upgrade window for your MES, and we'll
start the upgrade when you wish, after you've applied toleration
maintenance (if any) to your software products. If that's 1:00 a.m. on a
Sunday, for example, we can handle that. Coffee for our engineer is
optional but might be appreciated, served a safe distance away from your
machines. :-)

If you already have a Parallel Sysplex or GDPS Active Sites solution you
most likely will not need to take any application service interruption
during the upgrade. If you don't yet have either you have the option to
order another machine to "swing into" a Parallel Sysplex, either on a
temporary or ongoing basis, in order to reduce or eliminate your planned
downtime for the model upgrade(s). We also offer Capacity for Planned
Events (CPE), a type of temporary capacity, if for some reason you cannot
tolerate the temporary capacity reduction associated with a machine
upgrade.

Car model upgrades don't seem to be common.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
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: SMF RDW

[uweoswald]

+1 That makes everything clear. Thank you very much, Peter. This explanation 
was exactly what I want to get...

Am 16.01.2015 um 07:33 schrieb Peter Hunkeler :

> hope someone can help. I try to understand how a SMF RDW works. Basically I 
> have no problems to understand ?the whole thing? as long as the record is not 
> ?spanned?. To make it clearer: For example a RDW (first 4 Bytes) of 
> ?33.14.01.00?. OK, x?3314? tells me that the record is 13.076 Bytes long, but 
> how to deal with the remaining part the ?0100?? The only thing I know is that 
> the record is spanned actually. Does this mean that the next 256 Bytes 
> ?after? the first 13.076 Bytes belong together or how is this calculated?!
> 
> 
> 
> 
> RDWs are 4 bytes. The first two are always the lenght of the record. The 
> fourth byte is reserved and is always x'00'. The third byte, the one you're 
> talking about, is always x'00' unless the record format is VBS, .i.e. spanned 
> records.
> 
> 
> With non spanned records, a logical record must always fit into a single 
> block. For spanned format, the logical records may be split into multiple 
> parts, each one being written to a separat block. So, there is a first part, 
> there are zero or more intermiediate parts, and there is a final part. The 
> rightmost 2 bits of the third byte in the RDW indicat just this:
> x'01' -> first part, .i.e. a new spanned record starts here.
> x'11' -> intermediate part. Note that there is no sequence number. The 
> sequence is given by the sequence of the blocks.
> x'10' -> The final part, .i.e. the end of the spannded record.
> 
> 
> Note that even with spanned format, non-spanned records are allowed besides 
> spanned records. I.e. there may be records that do fit in a block, and they 
> will have the third byte as x'00'.
> 
> 
> --
> 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: z13 "new"(?) characteristics from RedBook

[Timothy Sipples]

John McKown writes:
>2) new type of CP: IFP - Integrated Firmware Processor, like a SAP, but
for
>the "native PCIe" features such as 10 Gb RoGE and zEDC Express

Yes, but you don't even have to think about it. The system comes
pre-configured with the IFP at no additional charge, it's invisible, and
they are not orderable.

>5) SMT (hyperthreading) only on IFL and zIIP engines (not CPs). Apparently
>when running SMT, the individual threads can't match the speed of a
non-SMT
>CP, but their aggregate power may.

The aggregate throughput with SMT enabled on IFLs and zIIPs "almost always"
exceeds (not just matches) the aggregate throughput without SMT. That's why
it's there, and that's why it's generally recommended.

There's a really simple illustration in one of the presentations I saw with
two pictures: a one lane road with a 60 mile per hour speed limit and a two
lane road with a 45 mile per hour speed limit. (Let's assume speed limits
are respected.) Those numbers are not necessarily representative of
relative single thread performance, but that's the idea. You now have the
option to double the lanes per IFL and per zIIP with an elongation of
execution time per thread. Very, very often that's a superb choice to make,
but of course your mileage may vary, which is why you can choose and also
why you can change your mind.

Yes, there's a lot of information already available (with some more coming)
to help you make an informed decision.

>8) HMC can also be in a 1U rack mounted machine (in the box? it doesn't
>say).

You can use a preexisting rack you already have, or you can order one from
IBM if you need one. In either event we recommend placing the HMC within
the 22U to 26U range for best ergonomic results, but that's up to you.

>10) Curious statement:
>
>If only Linux on z Systems is to be run under z/VM, then a z/VM mode LPAR
>is not required,
>and we suggest that a Linux-only LPAR be used instead.
>

ZFS Space issue

[venkat kulkarni]

Hello,
User want me to increase size for this , as it filled by 81%. But when I
checked, this dataset is multi volume and both volume are almost full. So,
now what alternative do I have to increase the size of this ZFS file system
. This is SMS managed dataset and in this storage group, I have one volume
which is 85% full and rest all are 99%.

# df -Pk /support/DGPBY
Filesystem 1024-blocksUsed  Available  Capacity Mounted on

ZFS.SYS01.AGG  14420160115973652822795   81% /support/DGPBY
#

Any suggestion.

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