date:20161213

Jesse Robinson wrote:

>And once you have all protections in place, remember that someone has to have 
>the key to master catalog. Whoever that is--including you--may occasionally 
>get caught by a missing alias. At every shop I've worked in, userids are 
>defined and managed by a non-sysprog department. If they set up a new user, 
>especially a new sysprog, a missing alias may be caught only after many data 
>sets have gone to master catalog. So it pays to check now and again even with 
>all recommended protections set up.   

Good catch! I agree 100% with you.

I would check every day, not now and again, that everything is in order.

Just do daily audit on MCAT with event=access and intent = update or higher and 
outcome = success and failure.


retired mainframer wrote:

>In addition to protecting the master catalog, you should prohibit HLQs for 
>which there is not a group or user profile.  Then make it part of your 
>procedures whenever a new user or group is created to simultaneously create 
>the catalog alias.

Indeed. That will save you gray hairs.

We have formal procedures for that. Say for new TSO ids, a request must go to 3 
teams: RACF, storage and billing.

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: HSM old tape cleanup

Linda wrote:

>Listed in the system catalog or the HSM tape catalog, both? 

>You should be able to list the catalogue entries, and IF they match, you could 
>reset the HSM expiration values to a date in the close future, and let them 
>expire through normal HSM processing. 

>Once the datasets are expired and the tapes are scratched you should be able 
>to remove or replace the volumes or mark them as deleted.

Good catch! 

Tony, check also if your tapes are also listed in your tape management system. 
If so, you need to tell it to expire that too.

Groete / Greetings
Elardus Engelbrecht

PS: my memories about HSM, SMS, tape management, catalogs, etc. are fading and 
rusting... ;-[

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

Re: HSM old tape cleanup

2016-12-13 Thread Linda

Hi Tony,

Listed in the system catalog or the HSM tape catalog, both? 

You should be able to list the catalogue entries, and IF they match, you could 
reset the HSM expiration values to a date in the close future, and let them 
expire through normal HSM processing. 

Once the datasets are expired and the tapes are scratched you should be able to 
remove or replace the volumes or mark them as deleted.

HTH,

Linda

Sent from my iPhone

> On Dec 13, 2016, at 2:02 PM, Tony Thigpen  wrote:
> 
> I am looking at my HSM TTOC listing. I have 3 old 3490s that are still 
> listed. I actually have the tapes, but they are unreadable. On two of them, I 
> get a label error:
> IEC514D DCK OR LBL ERR
> 
> On the other one, the TTOC shows:
> RC0378I TTOC RECORD AND TAPE MEDIA CONTENTS ARE INCONSISTENT
> 
> Since I can't migrate these volumes, how do I just delete these active tapes 
> from HSM? They are at least 15 years old so I am not worried about the data 
> that may have been on them.
> 
> -- 
> Tony Thigpen
> 
> --
> 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: LzLabs in ComputerWorld - Multiprise 3000

2016-12-13 Thread Mike Beer


http://www-01.ibm.com/common/ssi/rep_ca/0/897/ENUS199-240/


Am 13.12.2016 um 22:44 schrieb Tony Harminc:

On 13 December 2016 at 13:10, Pommier, Rex  wrote:

Tony, one correction to your comments.  The H70 was the two-way machine.  The 
H50 was the full speed uni, and the
H30 was a knee-capped uni.

Ah - you are quite right. And the P30 was the PWD machine, which did
not change its model number when (effectively) converted to an H50 by
the Linux add-on. There was never a P50 or P70, to my knowledge.

Tony H.

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


Mike Beer

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

Re: IPSEC

2016-12-13 Thread Rob Schramm

TCP packet size issue comes to mind.  IPSEC adds to the total.  Causing
packet fragmentation and has been know to uncover other issues that would
not normally be a problem.

Check with the network folks what it should be set to for IPSEC.

Rob

On Mon, Dec 12, 2016, 10:12 PM scott Ford  wrote:

> All,
>
> I have a dumb question and apologize in advance for asking it here. We have
> a LDAP sitting on Windows being sent data , that's encrypted with AES128
> encryption . The STC on z/OS sends a 32k packet via a socket write and the
> customer has IPSEC turned on. We saw a hang of the Windows LDAP and we had
> the customer turn off IPSEC, everything worked..
>
> We are scratching our heads, wondering if we have a compatibility issue or
> is IPSEC completely transparent to the application...
>
> Can someone enlighten this old man
>
>
> Scott
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Jack J. Woehr


Roger W Suhr wrote:

Yeah, but what kinds of jobs?  It doesn't matter, I won't go back to work for 
IBM,  because their whole philosophy is outdated and backward.  To many levels 
of management, who do only administrative work and talk your head off, but 
don't have a clue what's going on in the industry.


My dear, albeit sour old friends, dig this:

IBM's main mission has always been mobilizing the talent to build, sell and 
support breathtakingly
expensive bleeding-edge technology for organizations who cannot wait for the 
consumer model.

IBM is going to deliver the first widely marketable Quantum Computer.

Happy days are here again!

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

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

Re: HSM old tape cleanup

2016-12-13 Thread Tony Thigpen


Fails. :-(

Issued:
HSEND DELVOL 153818 MIGRATION(PURGE)
Response was:
ARC0260I MIGRATION VOLUME 153818 ENTRY NOT DELETED - VALID DATA MAY 
EXIST ON

ARC0260I (CONT.) VOLUME

For the one of the volumes:
Issued:
HSEND DELVOL 152215 MIGRATION(PURGE)
Response was:
ARC0378I TTOC RECORD AND TAPE MEDIA CONTENTS ARE INCONSISTENT ON TAPE VOLUME
ARC0378I (CONT.) 152215. TAPE VOLUME CANNOT BE DELETED, VALID DATA SETS MAY
ARC0378I (CONT.) EXIST ON THE VOLUME

Tony Thigpen

Allan Staller wrote on 12/13/2016 05:12 PM:

HSEND DELVOL volser type PURGE IIRC


From: IBM Mainframe Discussion List  on behalf of Tony 
Thigpen 
Sent: Tuesday, December 13, 2016 4:02:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HSM old tape cleanup

I am looking at my HSM TTOC listing. I have 3 old 3490s that are still
listed. I actually have the tapes, but they are unreadable. On two of
them, I get a label error:
IEC514D DCK OR LBL ERR

On the other one, the TTOC shows:
RC0378I TTOC RECORD AND TAPE MEDIA CONTENTS ARE INCONSISTENT

Since I can't migrate these volumes, how do I just delete these active
tapes from HSM? They are at least 15 years old so I am not worried about
the data that may have been on them.

--
Tony Thigpen

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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




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

Re: z/OS PDFs

2016-12-13 Thread Greg Boyd

And this evening it's working fine ... no idea what was going on.  But thanks 
for checking!
Greg

Greg Boyd
www.mainframecrypto.com

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Edward Gould

> On Dec 13, 2016, at 7:27 PM, Jack J. Woehr  wrote:
> 
> wjanu...@yahoo.com wrote:
>> Yeah, and when they finish their three months probation, they will get laid 
>> off.
> 
> IBM is on its way up again.

Up is a loose term. Like in space. 
> 
> The institution with the broadest view of business computing in the entire 
> world is about to enter its 2nd Golden Age.
> 
> -- 
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the universe
> www.softwoehr.com # with a fine understanding of human fallibility. - Carl 
> Sagan
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Edward Gould

> On Dec 13, 2016, at 6:21 PM, Edward Finnell 
> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Maybe they'll put a half dozen on the network availability team?

Anything greater than 1 would be nice
> 
> 
> In a message dated 12/13/2016 5:05:57 P.M. Central Standard Time,  
> g...@gabegold.com writes:
> 
> 25,000  people in the U.S. and invest $1 billion over the next four 
> years, laying  out her vision for filling technology jobs in America on  
> 
> 
> --
> 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 Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Roger W Suhr

Yeah, but what kinds of jobs?  It doesn't matter, I won't go back to work for 
IBM,  because their whole philosophy is outdated and backward.  To many levels 
of management, who do only administrative work and talk your head off, but 
don't have a clue what's going on in the industry. 

Sent from my Verizon, Samsung Galaxy smartphone
 Original message From: "Jack J. Woehr"  Date: 
12/13/16  20:27  (GMT-05:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM Lays 
Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting 
wjanu...@yahoo.com wrote:
> Yeah, and when they finish their three months probation, they will get laid 
> off.

IBM is on its way up again.

The institution with the broadest view of business computing in the entire 
world is about to enter its 2nd Golden Age.

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

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

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Jack J. Woehr


wjanu...@yahoo.com wrote:

Yeah, and when they finish their three months probation, they will get laid off.


IBM is on its way up again.

The institution with the broadest view of business computing in the entire 
world is about to enter its 2nd Golden Age.

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

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread wjanulin

Yeah, and when they finish their three months probation, they will get laid off.

Sent from my mobile phone 

-- Original message--
From: Edward Finnell<000248cce9f3-dmarc-requ...@listserv.ua.edu>
Date: Tue, Dec 13, 2016 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU;
Subject:Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

Maybe they'll put a half dozen on the network availability team?

In a message dated 12/13/2016 5:05:57 P.M. Central Standard Time,  
g...@gabegold.com writes:

25,000  people in the U.S. and invest $1 billion over the next four 
years, laying  out her vision for filling technology jobs in America on  

--
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 Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Edward Finnell

Maybe they'll put a half dozen on the network availability team?
 
 
In a message dated 12/13/2016 5:05:57 P.M. Central Standard Time,  
g...@gabegold.com writes:

25,000  people in the U.S. and invest $1 billion over the next four 
years, laying  out her vision for filling technology jobs in America on  


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

Re: 3800 printers

2016-12-13 Thread William Donzelli

> We know that as of a few years ago there were still functioning 3800s. People 
> were buying up the remaining supply of toner on Ebay. However, since formal 
> support ended years ago, and the last functioning machine in our lab was 
> decommissioned, we have no information on where any working 3800s might be.
>
> There may be some in computer museums, though no idea if they are operating.
>
> Why do you want one? Are you trying to print something that requires a 3800?

Yes, I would pursue one if I knew of any prospects. The 3800 was an
important printer in computer history, and I fear I may be too late in
grabbing one for the collection. Any leads (dead or alive machines)
from anyone would be appreciated.

I was in the same boat for 3880 controllers - I just missed the boat,
after seeing dozens upon dozens in the scrap yards, and it has taken
me about ten years to get one.

(and for wanting the blue sky, I would certainly be interested in any
3211s out there...)

--
Will

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

Re: IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Edward Gould

> On Dec 13, 2016, at 5:05 PM, Gabe Goldberg  wrote:
> 
> IBM Chief Executive Officer Ginni Rometty said she plans to hire about 25,000 
> people in the U.S. and invest $1 billion over the next four years, laying out 
> her vision for filling technology jobs in America on the eve of a meeting of 
> industry leaders with President-elect Donald Trump.
> 
> To read the entire article, go to http://bloom.bg/2hq2LLG 
> 
_SNIP

Pardon me but I don’t believe a word of it. Even if its partially true I think 
they will mostly be H1B’s at a lower cost salary.

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

Re: 3800 printers

2016-12-13 Thread Howard Turetzky

We know that as of a few years ago there were still functioning 3800s. People 
were buying up the remaining supply of toner on Ebay. However, since formal 
support ended years ago, and the last functioning machine in our lab was 
decommissioned, we have no information on where any working 3800s might be.

There may be some in computer museums, though no idea if they are operating.

Why do you want one? Are you trying to print something that requires a 3800? 

Howard Turetzky
Ricoh Production Print

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

IBM Lays Out Plans to Hire 25,000 in U.S. Ahead of Trump Meeting

2016-12-13 Thread Gabe Goldberg

IBM Chief Executive Officer Ginni Rometty said she plans to hire about 
25,000 people in the U.S. and invest $1 billion over the next four 
years, laying out her vision for filling technology jobs in America on 
the eve of a meeting of industry leaders with President-elect Donald Trump.


To read the entire article, go to http://bloom.bg/2hq2LLG

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

Re: Question on SPKA and Control Register 3

To close the loop on this, it seems pretty clear that any SVC form of MODESET 
(MODE= and/or KEY=), if the exit condition from the SVC is problem state, 
resets the PKM in CR3 to the settings quoted below. There is no way to get 
KEY=ZERO, problem state, while retaining the ability to issue SPKA X'x0'(0), 
where x is the original program storage key, typically 8 but possibly A through 
F. 

The functioning is a little illogical IMHO, the documentation is misleading 
IMHO, but there's little question that this is the way that it works.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, December 13, 2016 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

I think it is in a less than ideal spot in the text. It appears to apply to the 
SVC form of MODESET in general, not just to the use of the MODE= parameter. I 
believe I am seeing that MODESET KEY=ZERO, in problem state, sets off the 
"other" bits in the PKM.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 13, 2016 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

On Mon, 12 Dec 2016 22:04:45 -0500, Jim Mulder wrote:

>  The MODESET documentation says:
>
>,MODE=PROB,
> MODE=SUP 
>Specifies that the PSW problem state indicator (bit 15) is to be 
>either turned on (PROB) or turned off (SUP). If the MODESET operation 
>completes with a problem state PSW, the caller?s PSW key mask (PKM) is 
>set according to the following rules:
>
>?The bit matching the resulting PSW key is set on.
>?The bit matching key 9 is set on. 
>?For a task attached with ATTACHX using the KEY=NINE parameter, the 
>bits that were on in the PKM of the ATTACHX issuer are set on.
>?All other bits are set off.
>
>If the resulting PSW is in supervisor state, the caller?s PKM is 
>unchanged.

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Phil Smith

Tony Harminc wrote, re  MP3000:
>Ah - you are quite right. And the P30 was the PWD machine, which did
>not change its model number when (effectively) converted to an H50 by
>the Linux add-on. There was never a P50 or P70, to my knowledge.

We were doing Linux at Linuxcare (who'd'a thunk), and I think that might be 
what we had: a de facto P70, even though it wasn't "legal". This wasn't 
cheating: it was with IBM's blessing (I think they had to give us a microcode 
fiddle to enable it).

I remember having 3480s as well, and noting that the tape drives were bigger 
than the CPU, which just felt wrong.

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

Re: HSM old tape cleanup

2016-12-13 Thread Allan Staller

HSEND DELVOL volser type PURGE IIRC

From: IBM Mainframe Discussion List  on behalf of 
Tony Thigpen 
Sent: Tuesday, December 13, 2016 4:02:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HSM old tape cleanup

I am looking at my HSM TTOC listing. I have 3 old 3490s that are still
listed. I actually have the tapes, but they are unreadable. On two of
them, I get a label error:
IEC514D DCK OR LBL ERR

On the other one, the TTOC shows:
RC0378I TTOC RECORD AND TAPE MEDIA CONTENTS ARE INCONSISTENT

Since I can't migrate these volumes, how do I just delete these active
tapes from HSM? They are at least 15 years old so I am not worried about
the data that may have been on them.

--
Tony Thigpen

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

::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.

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

Re: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread retired mainframer

In addition to protecting the master catalog, you should prohibit HLQs for
which there is not a group or user profile.  Then make it part of your
procedures whenever a new user or group is created to simultaneously create
the catalog alias.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Way, Richard
Sent: Tuesday, December 13, 2016 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Prevent allocation of unknown-HLQ data sets?

Realize this is a pretty basic question, but my Google-fu isn't working out
today Can someone tell me the most common / easiest way to prevent
allocating a data set that doesn't have a catalog alias defined yet? We're
hitting situations where someone creates a data set by the HLQ of "TEST",
for example, and because no one created an ALIAS for TEST to a USERCAT, the
catalog entries for those data sets go straight into the MASTERCAT.

I'm almost certain there's a way to do this, but I am struggling whether
it's usually done by RACF or if there's a better / easier way...

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

HSM old tape cleanup

2016-12-13 Thread Tony Thigpen

I am looking at my HSM TTOC listing. I have 3 old 3490s that are still 
listed. I actually have the tapes, but they are unreadable. On two of 
them, I get a label error:

IEC514D DCK OR LBL ERR

On the other one, the TTOC shows:
RC0378I TTOC RECORD AND TAPE MEDIA CONTENTS ARE INCONSISTENT

Since I can't migrate these volumes, how do I just delete these active 
tapes from HSM? They are at least 15 years old so I am not worried about 
the data that may have been on them.


--
Tony Thigpen

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Tony Harminc

On 13 December 2016 at 13:10, Pommier, Rex  wrote:
> Tony, one correction to your comments.  The H70 was the two-way machine.  The 
> H50 was the full speed uni, and the
> H30 was a knee-capped uni.

Ah - you are quite right. And the P30 was the PWD machine, which did
not change its model number when (effectively) converted to an H50 by
the Linux add-on. There was never a P50 or P70, to my knowledge.

Tony H.

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

Re: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Jesse 1 Robinson

And once you have all protections in place, remember that someone has to have 
the key to master catalog. Whoever that is--including you--may occasionally get 
caught by a missing alias. At every shop I've worked in, userids are defined 
and managed by a non-sysprog department. If they set up a new user, especially 
a new sysprog, a missing alias may be caught only after many data sets have 
gone to master catalog. So it pays to check now and again even with all 
recommended protections set up.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, December 13, 2016 11:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Prevent allocation of unknown-HLQ data sets?

Way, Richard wrote:

>Realize this is a pretty basic question, but my Google-fu isn't working out 
>today Can someone tell me the most common / easiest way to prevent 
>allocating a data set that doesn't have a catalog alias defined yet? We're 
>hitting situations where someone creates a data set by the HLQ of "TEST", for 
>example, and because no one created an ALIAS for TEST to a USERCAT, the 
>catalog entries for those data sets go straight into the MASTERCAT.

>I'm almost certain there's a way to do this, but I am struggling whether it's 
>usually done by RACF or if there's a better / easier way...

You need to do several things. You got answers about ONE thing - MCAT, but that 
is not enough!

0. Establish naming standards. Do that properly to start with.
1. MCAT - UACC=READ. UPDATE to storage admin and lucky few who will listen to 
you. READ for RESTRICTED ids.
2. Usercat - UACC=UPDATE. UPDATE to restricted ids for ucats as needed.
3. Use PROTECTALL(FAIL)
4. Fix your RACF profiles.

Optional - If you have a sandbox Sysplex and Prod Sysplex - have separate MCATs 
and perhaps a few shared UCATs. You then need to decide on WHAT ucat you may 
allow ALTER to certain HLQ on what Sysplex. So for example, you allow ALTER on 
HLQ ABC on sandbox, but UPDATE on Prod and so on.

Talk with your RACF admin.

HTH!

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: I/O error substituting symbols in sysin

2016-12-13 Thread Paul Gilmartin

On Tue, 13 Dec 2016 15:29:53 -0500, John Clifford wrote:

>I was always under the impression that any DD * implied lrecl=80 only.
>Adding a lrecl=222 should cause the i/o error. No 
>
I believe that restriction was removed about z/OS 1.5 JES2.  Just
TSO SUBMIT hasn't heard about it yet.  And earlier today I posted
a case that works only with the LRECL=222.

-- gil

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

Re: I/O error substituting symbols in sysin

2016-12-13 Thread John Clifford

I was always under the impression that any DD * implied lrecl=80 only.
Adding a lrecl=222 should cause the i/o error. No 

John Clifford

On Mon, Dec 12, 2016 at 8:40 PM, Anthony Thompson <
anthony.thomp...@nt.gov.au> wrote:

> Pardon for getting the input wrong. New JCL:
> //
> //  EXPORT SYMLIST=*
> //  SET TEST='THIS IS THE VALUE OF THE SUBSTITUTED STRING.'
> //STEP1EXEC PGM=IEBGENER
> //SYSUT1   DD   DATA,SYMBOLS=JCLONLY,DCB=LRECL=222
>   This is a test of symbol use in instream data sets. Test here: 
> /*
> //SYSUT2   DD   SYSOUT=(,)
> //SYSPRINT DD   SYSOUT=(,)
> //SYSINDD   DUMMY
>
> I'm supposing you used the TSO SUBMIT command to submit the job. A foible
> of TSO SUBMIT is that it doesn't do input greater than 80 characters.
>
> So you've got an 80-byte SYSUT1 input but you're telling the system it's
> really 222 bytes. Bang. I/O error.
>
> I put the same JCL above into a dataset with LRECL 222 and submitted it to
> an internal reader via IEBGENER (ICEGENER). Job Finished with RC 0.
>
> Ant.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Tuesday, 13 December 2016 1:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: I/O error substituting symbols in sysin
>
> On 2016-12-12, at 00:56, Anthony Thompson wrote:
>
> > Ran this JCL :
> >
> > //
> > //  EXPORT SYMLIST=*
> > //  SET TEST='THIS IS THE VALUE OF THE SUBSTITUTED STRING.'
> > //STEP1EXEC  PGM=IEBGENER
> > //SYSUT1DD  DATA,SYMBOLS=JCLONLY
> > 
> > /*
> > //SYSUT2DD  SYSOUT=(,)
> > //SYSPRINT  DD  SYSOUT=(,)
> > //SYSIN DD  DUMMY
> >
> > Only removed the DCB on SYSUT1. Job worked.
> >
> Than's not "only".  You also changed the content of SYSUT1 in my example.
> Try it with the SYSUT1 I cited, with or without DCB:
>
> //SYSUT1DD  *,SYMBOLS=JCLONLY,DCB=LRECL=222
>This is a test of symbol use in instream data sets.   Test here: 
>
>
> On 2016-12-12, at 02:50, Anthony Thompson wrote:
>
> > Just so. But anyone can frig around with invalid DCB's and make any
> utility break.
>
> What do you claim was invalid about my DCB.  Cite Reference.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Prevent allocation of unknown-HLQ data sets?

Way, Richard wrote:

>Realize this is a pretty basic question, but my Google-fu isn't working out 
>today Can someone tell me the most common / easiest way to prevent 
>allocating a data set that doesn't have a catalog alias defined yet? We're 
>hitting situations where someone creates a data set by the HLQ of "TEST", for 
>example, and because no one created an ALIAS for TEST to a USERCAT, the 
>catalog entries for those data sets go straight into the MASTERCAT.

>I'm almost certain there's a way to do this, but I am struggling whether it's 
>usually done by RACF or if there's a better / easier way...

You need to do several things. You got answers about ONE thing - MCAT, but that 
is not enough!

0. Establish naming standards. Do that properly to start with.
1. MCAT - UACC=READ. UPDATE to storage admin and lucky few who will listen to 
you. READ for RESTRICTED ids.
2. Usercat - UACC=UPDATE. UPDATE to restricted ids for ucats as needed.
3. Use PROTECTALL(FAIL)
4. Fix your RACF profiles.

Optional - If you have a sandbox Sysplex and Prod Sysplex - have separate MCATs 
and perhaps a few shared UCATs. You then need to decide on WHAT ucat you may 
allow ALTER to certain HLQ on what Sysplex. So for example, you allow ALTER on 
HLQ ABC on sandbox, but UPDATE on Prod and so on.

Talk with your RACF admin.

HTH!

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: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Eric Mendelson

Protect the master catalog

Sent from my iPhone

> On Dec 13, 2016, at 1:57 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Tue, 13 Dec 2016 18:55:21 +, Way, Richard wrote:
>> 
>> Realize this is a pretty basic question, but my Google-fu isn't working out 
>> today Can someone tell me the most common / easiest way to prevent 
>> allocating a data set that doesn't have a catalog alias defined yet? We're 
>> hitting situations where someone creates a data set by the HLQ of "TEST", 
>> for example, and because no one created an ALIAS for TEST to a USERCAT, the 
>> catalog entries for those data sets go straight into the MASTERCAT.
>> 
>> I'm almost certain there's a way to do this, but I am struggling whether 
>> it's usually done by RACF or if there's a better / easier way...
>> 
> Protect the MASTERCAT.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Pommier, Rex

Rich,

A couple items you need to implement to address this.  First is to make the 
master catalog read-only to the vast majority of your world, then to implement 
protect-all.  The first will keep rogue items from showing up in your master 
catalog, the second will keep people from willy-nilly adding whatever they want 
as high level qualifiers.  If there ain't a RACF profile to protect it, it 
doesn't get created.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Way, Richard
Sent: Tuesday, December 13, 2016 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Prevent allocation of unknown-HLQ data sets?

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT.

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way...

Thanks in advance

Rich Way
HPE

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: Prevent allocation of unknown-HLQ data sets?

Your Welcome, I have those moments more now... 
Carmen 

- Original Message -

From: "Richard Way"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 13, 2016 1:07:29 PM 
Subject: Re: Prevent allocation of unknown-HLQ data sets? 

D'oh Thanks!!! 

Rich Way 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Tuesday, December 13, 2016 10:59 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Prevent allocation of unknown-HLQ data sets? 

What I've done in 2 shops was to protect the master catalog(s) set UACC(READ) 
and only update access to your SYSPROG's you trust :) Carmen 
- Original Message - 

From: "Richard Way"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 13, 2016 12:55:21 PM 
Subject: Prevent allocation of unknown-HLQ data sets? 

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT. 

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way... 

Thanks in advance 

Rich Way 
HPE 

-- 
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: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Burrell, Todd

Amen - one shopped I worked in had the master catalog defined with a UACC of 
UPDATE and it took a LONG time to get it cleaned up.  If a new user got created 
with no alias - all their files went into the MASTER.   Took a lot of REPRO 
MERGECAT commands to clean up that mess.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, December 13, 2016 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Prevent allocation of unknown-HLQ data sets?

What I've done in 2 shops was to protect the master catalog(s) set UACC(READ) 
and only update access to your SYSPROG's you trust :) Carmen
- Original Message -

From: "Richard Way" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, December 13, 2016 12:55:21 PM
Subject: Prevent allocation of unknown-HLQ data sets? 

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT. 

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way... 

Thanks in advance 

Rich Way
HPE 

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

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

This email transmission and any accompanying attachments may contain CSX 
privileged and confidential information intended only for the use of the 
intended addressee. Any dissemination, distribution, copying or action taken in 
reliance on the contents of this email by anyone other than the intended 
recipient is strictly prohibited. If you have received this email in error 
please immediately delete it and notify sender at the above CSX email address. 
Sender and CSX accept no liability for any damage caused directly or indirectly 
by receipt of this email.

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

Re: Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Way, Richard

D'oh Thanks!!!

Rich Way

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, December 13, 2016 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Prevent allocation of unknown-HLQ data sets?

What I've done in 2 shops was to protect the master catalog(s) set UACC(READ) 
and only update access to your SYSPROG's you trust :) Carmen
- Original Message -

From: "Richard Way" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, December 13, 2016 12:55:21 PM
Subject: Prevent allocation of unknown-HLQ data sets? 

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT. 

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way... 

Thanks in advance 

Rich Way
HPE 

--
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: LzLabs in ComputerWorld

2016-12-13 Thread Parwez Hamid

Re: MP3000 - nothing good about? If you wanted a full 'function' z System, 
there were alternative options 
available at the time.

The MP3000 addressed the requirements of a certain customer type/set with a 
different price point and. They 
didn't need the same functionality as other z customers of the time. 

In my book ESCON was a real channel and at the time the MP3000 was introduced 
there were lots
of large customers (banks, airlines, utilities etc) still using ESCON I/O. So 
no big deal if the MP3000 didn't have FICON. 

BTW: Are there customers who still have BUS/TAG and ESCON devices today. Yes, 
and they use the Optica channel 
convertor to attach to FICON channels :-)

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

Re: Prevent allocation of unknown-HLQ data sets?

What I've done in 2 shops was to protect the master catalog(s) set UACC(READ) 
and only update access to your SYSPROG's you trust :) 
Carmen 
- Original Message -

From: "Richard Way"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 13, 2016 12:55:21 PM 
Subject: Prevent allocation of unknown-HLQ data sets? 

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT. 

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way... 

Thanks in advance 

Rich Way 
HPE 

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

Prevent allocation of unknown-HLQ data sets?

2016-12-13 Thread Way, Richard

Realize this is a pretty basic question, but my Google-fu isn't working out 
today Can someone tell me the most common / easiest way to prevent 
allocating a data set that doesn't have a catalog alias defined yet? We're 
hitting situations where someone creates a data set by the HLQ of "TEST", for 
example, and because no one created an ALIAS for TEST to a USERCAT, the catalog 
entries for those data sets go straight into the MASTERCAT.

I'm almost certain there's a way to do this, but I am struggling whether it's 
usually done by RACF or if there's a better / easier way...

Thanks in advance

Rich Way
HPE

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

Re: Question on SPKA and Control Register 3

I think it is in a less than ideal spot in the text. It appears to apply to the 
SVC form of MODESET in general, not just to the use of the MODE= parameter. I 
believe I am seeing that MODESET KEY=ZERO, in problem state, sets off the 
"other" bits in the PKM.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 13, 2016 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

On Mon, 12 Dec 2016 22:04:45 -0500, Jim Mulder wrote:

>  The MODESET documentation says:
>
>,MODE=PROB,
> MODE=SUP 
>Specifies that the PSW problem state indicator (bit 15) is to be 
>either turned on (PROB) or turned off (SUP). If the MODESET operation 
>completes with a problem state PSW, the caller?s PSW key mask (PKM) is 
>set according to the following rules:
>
>?The bit matching the resulting PSW key is set on.
>?The bit matching key 9 is set on. 
>?For a task attached with ATTACHX using the KEY=NINE parameter, the  
>bits that were on in the PKM of the ATTACHX issuer are set on.
>?All other bits are set off.
>
>If the resulting PSW is in supervisor state, the caller?s PKM is 
>unchanged.

It looks like the above was added to the z/OS 1.10 edition of the manual.

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

Re: Question on SPKA and Control Register 3

2016-12-13 Thread Tom Marchant

On Mon, 12 Dec 2016 22:04:45 -0500, Jim Mulder wrote:

>  The MODESET documentation says:
>
>,MODE=PROB,
> MODE=SUP 
>Specifies that the PSW problem state indicator 
>(bit 15) is to be either turned on (PROB) or turned off (SUP). If the 
>MODESET operation completes with a problem state PSW, the caller?s 
>PSW key mask (PKM) is set according to the following rules: 
>
>?The bit matching the resulting PSW key is set on.
>?The bit matching key 9 is set on. 
>?For a task attached with ATTACHX using the KEY=NINE parameter, the 
> bits that were on in the PKM of the ATTACHX issuer are set on. 
>?All other bits are set off.
>
>If the resulting PSW is in supervisor state, the caller?s PKM is 
>unchanged.

It looks like the above was added to the z/OS 1.10 edition of the manual.

-- 
Tom Marchant

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Pommier, Rex

My turn.  :-)

Tony, one correction to your comments.  The H70 was the two-way machine.  The 
H50 was the full speed uni, and the H30 was a knee-capped uni.  At a prior job, 
we ran an H50 for several years, ESCON attached to an RVA (anybody remember 
them?  :-)  ) and parallel attached to tape and printer.  We didn't use the 
emulated I/O for anything.  Had a pair of Bus-Tech boxes that handled our 
TCP/IP traffic across ESCON I believe to the H50.  

Funny side story was that we got a know-it-all CxO came in and decided the 
mainframe was too expensive/large/outdated/whatever other negative thing he 
could come up with against it.  He decided we were going to get modern so he 
spent mega-bucks on an HP superdome with all the peripherals.  Physically a 
huge machine.  Well, he showed up one day to show off the new machine to the 
big-wigs and after bragging the HP up to them, he looked around for the 
mainframe he was replacing and literally couldn't find it even though it was 
right in front of him.  He didn't know we were running the mainframe on a box 
the size of a 2 drawer file cabinet.  A couple years later, he was gone, and a 
couple years after that the superdome was gone too.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, December 13, 2016 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LzLabs in ComputerWorld

On 13 December 2016 at 10:34, R.S.  wrote:

> I dare to disagree.

My turn...

> Although MP3000 was better than MP2000, it was still nothing good.

It was *much* better than the MP2000. Very much faster. It was a 390
G5 CPU. Even 2 x G5 on the top model (H50).

A note on the "development only" idea about this machine. There *were* 
development (PWD) models. We had one, at a much reduced price, and we also had 
a free "Linux option" that kept the model number unchanged (P30), but doubled 
the CPU speed and doubled the memory. IIRC the non-PWD models were H30 and H50.

> As a demonstration/learning/portable machine it was much to big.

Sure. The old P390s were about the best for that. But you could always connect 
remotely.

> As a production or development machine the I/O was really poor.

Well... Don't mix the two kinds of I/O. There was the P390/Integrated Server 
style of I/O, all done by OS/2 through the (16-bit!) drivers taken unchanged 
from the P390. This was used for OS/2's own purposes (C drive, etc.) and it was 
possible to map emulated 390 DASD to OS/2 files on this space, exactly as on 
P390. But the "real" DASD I/O was via an STI cable from the G5 CPU to a PCI 
card on the passive backplane. The array of SSA drives connected to the same 
PCI bus, and that I/O was done with no involvement of OS/2 or even the Intel 
CPU.

> No real channels except ESCON.

There was a parallel channel, but IIRC not supported for DASD. Tape and UR 
only. But did you really have old DASD that you wanted to connect via Bus & 
Tag? Maybe a 3380...

> No sysplex capability. A lot of SPOFs.

Yes - SPOF were a problem for a production shop. Though OS/2 could crash and be 
rebooted without crashing the G5. But who wants Sysplex on a machine that size, 
except a development shop (ISV)?

> z800 and followers were not much more expensive, but it's functionality was 
> significantly better.

z800 + DASD + network interface + TN3270/console support of some kind came out 
to a lot more money. But of course speed of a 64-bit program on the MP3000 = 0 
MIPS...

Tony H.

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: Question on SPKA and Control Register 3

Thanks. Yes, adding MODE=SUP to my KEY=ZERO MODESET would obviously solve
the problem, short-term. I have resisted that for three reasons, listed
below roughly in order of importance as I see it. I would welcome comments
on my logic.

1. How do I get back to problem state? I don't want to run the whole
application, which runs for days at a time, mostly in LE C++, in supervisor
state. Using MODESET/SVC 107 to get back defeats the whole purpose of this
exercise. If I don't mind the SVC 107 I could just forget the SPKA entirely
and simply use MODESET KEY=NZERO. Am I correct that there is no "simple"
machine instruction that sets the Problem bit off?
2. I believe in least privilege. I never run supervisor state when program
state will do. It seems a shame to run supervisor state just to work around
an MVS gotcha.
3. I wonder if adding MODE=SUP to MODESET KEY=ZERO slows it down
significantly. Does it double the path length in MVS?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Tuesday, December 13, 2016 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

Yep, it is a bug.

The PSW key mask has key 0 and key9  after the combination. Not key 8. I
would not expect MODESET to alter the key mask.

Of course, I have never found the occasion to run key zero problem state
(since it doesn't prevent overlays). I would use supervisor state and switch
out of key when needed.


On Tue, 13 Dec 2016 08:27:41 -0800 Charles Mills  wrote:

:>Just to continue the experiment and confirm my conclusion, all I have to
do :>to get the below to "work" is remove the last MODESET:
:>
:> MODESET KEY=NZERO Make sure we are in Key 8
:> MODESET MODE=PROB Allow SPKA 8
:>*  ***   MODESET KEY=ZERO  Get access to CSA
:> SPKA  X'80'(0)*** Total experiment ***
:>
:>So I rest my case: a MODESET leaves you in a state where you can do any
SPKA :>you want so long as it is for the key you already are in.
:>
:>Or, turning this from a complaint to the underlying question: if you had
:>code that was executed *very* frequently and needed to be in Key 0
briefly, :>what would you do? Is there any way to avoid the SVC when
returning to Key :>8?

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Phil Smith

Tony Harminc wrote, re  MP3000:
>It was *much* better than the MP2000. Very much faster. It was a 390
>G5 CPU. Even 2 x G5 on the top model (H50).

>A note on the "development only" idea about this machine. There *were*
>development (PWD) models. We had one, at a much reduced price, and we
>also had a free "Linux option" that kept the model number unchanged
>(P30), but doubled the CPU speed and doubled the memory. IIRC the
>non-PWD models were H30 and H50.

Yes! We had that at Linuxcare. We had the extra CPU, full memory, and something 
else was enabled that wasn't normally allowed. We had four LPARs; was it that 
normally you were only allowed two?

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread PINION, RICHARD W.

I worked on a production 7060 (MP3000) H30 for several years.  We did not use 
the internal 
DASD.  The H30 was connected, via ESCON, to a 2105.  The only thing emulated on 
that box was
the OSA, which used the Ethernet card(s) on the PC.  Was it better than a z800 
or z900, definitely
not!  But that was all the organization could afford at that time.  It served 
us for almost eight
years.  We ran a production and test CICS region, TSO/ISPF, and batch.   

Heck, when we converted to z/OS 1.4 from OS/390 2.10, I actually created a 
Integrated Coupling
Facility LPAR, and SYSPLEX'ed the production OS/390 2.10 LPAR to a test z/OS 
1.4 LPAR for testing
purposes.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Tuesday, December 13, 2016 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LzLabs in ComputerWorld

On 13 December 2016 at 10:34, R.S.  wrote:

> I dare to disagree.

My turn...

> Although MP3000 was better than MP2000, it was still nothing good.

It was *much* better than the MP2000. Very much faster. It was a 390
G5 CPU. Even 2 x G5 on the top model (H50).

A note on the "development only" idea about this machine. There *were* 
development (PWD) models. We had one, at a much reduced price, and we also had 
a free "Linux option" that kept the model number unchanged (P30), but doubled 
the CPU speed and doubled the memory. IIRC the non-PWD models were H30 and H50.

> As a demonstration/learning/portable machine it was much to big.

Sure. The old P390s were about the best for that. But you could always connect 
remotely.

> As a production or development machine the I/O was really poor.

Well... Don't mix the two kinds of I/O. There was the P390/Integrated Server 
style of I/O, all done by OS/2 through the (16-bit!) drivers taken unchanged 
from the P390. This was used for OS/2's own purposes (C drive, etc.) and it was 
possible to map emulated 390 DASD to OS/2 files on this space, exactly as on 
P390. But the "real" DASD I/O was via an STI cable from the G5 CPU to a PCI 
card on the passive backplane. The array of SSA drives connected to the same 
PCI bus, and that I/O was done with no involvement of OS/2 or even the Intel 
CPU.

> No real channels except ESCON.

There was a parallel channel, but IIRC not supported for DASD. Tape and UR 
only. But did you really have old DASD that you wanted to connect via Bus & 
Tag? Maybe a 3380...

> No sysplex capability. A lot of SPOFs.

Yes - SPOF were a problem for a production shop. Though OS/2 could crash and be 
rebooted without crashing the G5. But who wants Sysplex on a machine that size, 
except a development shop (ISV)?

> z800 and followers were not much more expensive, but it's functionality was 
> significantly better.

z800 + DASD + network interface + TN3270/console support of some kind came out 
to a lot more money. But of course speed of a 64-bit program on the MP3000 = 0 
MIPS...

Tony H.

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

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

Re: Question on SPKA and Control Register 3

2016-12-13 Thread Binyamin Dissen

Yep, it is a bug.

The PSW key mask has key 0 and key9  after the combination. Not key 8. I would
not expect MODESET to alter the key mask.

Of course, I have never found the occasion to run key zero problem state
(since it doesn't prevent overlays). I would use supervisor state and switch
out of key when needed.


On Tue, 13 Dec 2016 08:27:41 -0800 Charles Mills  wrote:

:>Just to continue the experiment and confirm my conclusion, all I have to do
:>to get the below to "work" is remove the last MODESET:
:>
:> MODESET KEY=NZERO Make sure we are in Key 8
:> MODESET MODE=PROB Allow SPKA 8
:>*  ***   MODESET KEY=ZERO  Get access to CSA
:> SPKA  X'80'(0)*** Total experiment ***
:>
:>So I rest my case: a MODESET leaves you in a state where you can do any SPKA
:>you want so long as it is for the key you already are in.
:>
:>Or, turning this from a complaint to the underlying question: if you had
:>code that was executed *very* frequently and needed to be in Key 0 briefly,
:>what would you do? Is there any way to avoid the SVC when returning to Key
:>8?
:>
:>@Peter, @Jim -- if you're following this, I'm testing on V2R2 but could
:>readily try on V2R1 or V1R13.
:>
:>Charles
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>Behalf Of Charles Mills
:>Sent: Tuesday, December 13, 2016 6:48 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Question on SPKA and Control Register 3
:>
:>Okay, there is just no doubt in my mind that the use of MODESET precludes
:>the use of SPKA (and I'm not certain how to get around it other than to use
:>MODESET (with its attendant SVC) rather than SPKA). It's code that runs
:>millions of times per hour on multiple LPARs so I am trying to minimize
:>gratuitous overhead. Here is the exact failing code (unedited, and yes, I
:>know it's dumb -- I'm trying to illustrate the problem)
:>
:>868  MODESET KEY=NZERO
:>Make sure we are in Key 8  
:>869+* MACDATE Y-3 81030
:>
:>00055C  871+ CNOP  0,4
:>
:>00055C 4510 C56400564   872+ BAL   1,*+8
:>
:>000560 0020 873+ DC
:>B'0010'
:>000564 5810 10000   874+ L 1,0(0,1)
:>
:>000568 0A6B 875+ SVC   107
:>
:>876  MODESET MODE=PROB
:>Allow SPKA 8   
:>877+* MACDATE Y-3 81030
:>
:>00056A 0700 879+ CNOP  0,4
:>
:>00056C 4510 C57400574   880+ BAL   1,*+8
:>
:>000570 0004 881+ DC
:>B'0100'
:>000574 5810 10000   882+ L 1,0(0,1)
:>
:>000578 0A6B 883+ SVC   107
:>
:>884  MODESET KEY=ZERO
:>Get access to CSA  
:>885+* MACDATE Y-3 81030
:>
:>00057A 0700 887+ CNOP  0,4
:>
:>00057C 4510 C58400584   888+ BAL   1,*+8
:>
:>000580 0030 889+ DC
:>B'0011'
:>000584 5810 10000   890+ L 1,0(0,1)
:>
:>000588 0A6B 891+ SVC   107
:>
:>00058A B20A 0080  00080 892  SPKA  X'80'(0)
:>*** Total experiment ***   
:>
:>And here is the result (unedited):
:>
:>CEE3202S The system detected a privileged-operation exception
:>(System Completion Code=0C2). 
:>  Location:
:>
:>Program Unit:  Entry: DIRECTOR Statement:  Offset: +00DA
:>
:>  Machine State:
:>
:>ILC. 0004Interruption Code. 0002
:>
:>PSW. 070D0400 A4991406
:>
:>GPR0. _00022798  GPR1. _0030  GPR2.
:>_00F898C4  GPR3. _0001  
:>GPR4. _2499A9F8  GPR5. _25E98940  GPR6.
:>_2499CB38  GPR7. _25E71528  
:>GPR8. _26093E70  GPR9. _1C7AC560  GPR10
:>_000223BC  GPR11 _25E9336C  
:>GPR12 _24990E78  GPR13 _000226C8  GPR14
:>_A4991388  GPR15 _  
:>FPC.. 
:>
:>FPR0. 45EA1145  FPR1. 43169000  
:>
:>FPR2. 4D5438B2  C38FA400FPR3. 3500  
:>
:>FPR4. 433E8000  FPR5. 41A0  
:>
:>FPR6. 3500  FPR7. 3300  
:>
:>FPR8.

Re: I/O error substituting symbols in sysin

2016-12-13 Thread Paul Gilmartin

On Tue, 13 Dec 2016 01:40:07 +, Anthony Thompson wrote:
>
>So you've got an 80-byte SYSUT1 input but you're telling the system it's 
>really 222 bytes. Bang. I/O error.
>
>I put the same JCL above into a dataset with LRECL 222 and submitted it to an 
>internal reader via IEBGENER (ICEGENER). Job Finished with RC 0.  
>
And now I recall how I came to have a proclivity for specifying DCB parameters
The following job submitted via IEBGENER to INTRDR with RECFM=VB,LRECL=250:

user@OS/390.25.00: cat jclsym2  
   
//
//JCLSYM2   JOB  505303JOB,'Paul Gilmartin',
// MSGLEVEL=(1,1),REGION=16385K
//*
//* Doc: experiment with instream symbol substitution.
//*
//USERCOUTPUT JESDS=ALL,DEFAULT=YES,
//  CLASS=R,PAGEDEF=V0648Z,CHARS=GT12
//*
//  EXPORT SYMLIST=*
//  SET TEST='This is the value of the substituted string.'
//STEP1EXEC  PGM=IEBGENER
//SYSUT1DD  *,SYMBOLS=(JCLONLY,LOGDD)  ,DCB=(LRECL=222),BLKSIZE=444
This is a test of symbol use in instream data sets.  Test here: 
+|+|+|+|+|+|+|+|1
//* This is a test of symbol use in instream data sets.  Test here: This is the 
value of the substituted string.
//SYSUT2DD  SYSOUT=(,)
//SYSPRINT  DD  SYSOUT=(,)
//SYSIN DD  DUMMY
//LOGDD DD  SYSOUT=(,)
//*.+|+|+|+|+|+|+|+|
//
 :w ! JESRECFM=V JESLRECL=250 submit $MVS_HOST
user@OS/390.25.00: 

... fails as is, but succeeds if I enable the DCB parameters.  But if I then
remove the second line in SYSUT1, it fails again.

The rules are complicated.  They need to be explained clearly.  They are not.

-- gil

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

It's been said, those who do not understand Unix are condemned to
re-invent it ... poorly.
We could have a lively discussion about that on this list, but likely we
all agree that those who don't understand mainframes are condemned to
re-invent them (poorly).

I really don't know anything good or bad about LzLabs, but the article
starts with that "mainframes are a pain, but we need them (or need what
they do), and those with skillz are turning grey", and then suggests
that companies can "define" some ethereal thing rather than interest and
train people to roll-up their sleeves.

Yeah ... sounds like cloudy PSI.
What I don't get is how alternate "hardware" addresses the tech debt
problem.

Those who do not understand [technology xyz], especially those who
refuse to bother learning it, are condemned to re-invent it really
really poorly.

-- R; <><

On 12/11/16 23:49, zMan wrote:

http://www.computerworlduk.com/infrastructure/lzlabs-promises-end-mainframe-migration-woes-with-software-defined-approach-3645686/
seems enthralled with LzLabs, but the article doesn't really shed any light
that I can see.

Consider statements like:
*Yet, while considered robust and reliable for certain uses, mainframes are
costly to maintain and difficult to support, particularly due to the
imminent retirement of those with knowledge of a system’s inner workings.*

OK, we can debate this (and have), but then:
*Cresswell described the migration process: “When an application is moved
from the mainframe into our environment we don't recompile it or anything
like that. We literally take the binary code that comes off the mainframe
environment,” Cresswell explained.*

How does this help with the maintenance issue? Do you keep a real z for a
dev platform?

Next graf says:
*“At the time we put it into the container we replace all the APIs with
contemporary ones that reference our software defined mainframe container.”*
Um, right. So that
L R3,540Get TCB address
statement is going to get replaced? Or just replicated/emulated? Or they're
going to emulate all of the data structures in z/OS?

Or is this all a shell game, and it's really just Herc in the cloud?

I'm not opposed to someone doing something to shake things up. But the lack
of detail from Lz is starting to smell like PSI redux.

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Tony Harminc

On 13 December 2016 at 10:34, R.S.  wrote:

> I dare to disagree.

My turn...

> Although MP3000 was better than MP2000, it was still nothing good.

It was *much* better than the MP2000. Very much faster. It was a 390
G5 CPU. Even 2 x G5 on the top model (H50).

A note on the "development only" idea about this machine. There *were*
development (PWD) models. We had one, at a much reduced price, and we
also had a free "Linux option" that kept the model number unchanged
(P30), but doubled the CPU speed and doubled the memory. IIRC the
non-PWD models were H30 and H50.

> As a demonstration/learning/portable machine it was much to big.

Sure. The old P390s were about the best for that. But you could always
connect remotely.

> As a production or development machine the I/O was really poor.

Well... Don't mix the two kinds of I/O. There was the P390/Integrated
Server style of I/O, all done by OS/2 through the (16-bit!) drivers
taken unchanged from the P390. This was used for OS/2's own purposes
(C drive, etc.) and it was possible to map emulated 390 DASD to OS/2
files on this space, exactly as on P390. But the "real" DASD I/O was
via an STI cable from the G5 CPU to a PCI card on the passive
backplane. The array of SSA drives connected to the same PCI bus, and
that I/O was done with no involvement of OS/2 or even the Intel CPU.

> No real channels except ESCON.

There was a parallel channel, but IIRC not supported for DASD. Tape
and UR only. But did you really have old DASD that you wanted to
connect via Bus & Tag? Maybe a 3380...

> No sysplex capability. A lot of SPOFs.

Yes - SPOF were a problem for a production shop. Though OS/2 could
crash and be rebooted without crashing the G5. But who wants Sysplex
on a machine that size, except a development shop (ISV)?

> z800 and followers were not much more expensive, but it's functionality was 
> significantly better.

z800 + DASD + network interface + TN3270/console support of some kind
came out to a lot more money. But of course speed of a 64-bit program
on the MP3000 = 0 MIPS...

Tony H.

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

Re: Question on SPKA and Control Register 3

Just to continue the experiment and confirm my conclusion, all I have to do
to get the below to "work" is remove the last MODESET:

 MODESET KEY=NZERO Make sure we are in Key 8
 MODESET MODE=PROB Allow SPKA 8
*  ***   MODESET KEY=ZERO  Get access to CSA
 SPKA  X'80'(0)*** Total experiment ***

So I rest my case: a MODESET leaves you in a state where you can do any SPKA
you want so long as it is for the key you already are in.

Or, turning this from a complaint to the underlying question: if you had
code that was executed *very* frequently and needed to be in Key 0 briefly,
what would you do? Is there any way to avoid the SVC when returning to Key
8?

@Peter, @Jim -- if you're following this, I'm testing on V2R2 but could
readily try on V2R1 or V1R13.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, December 13, 2016 6:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

Okay, there is just no doubt in my mind that the use of MODESET precludes
the use of SPKA (and I'm not certain how to get around it other than to use
MODESET (with its attendant SVC) rather than SPKA). It's code that runs
millions of times per hour on multiple LPARs so I am trying to minimize
gratuitous overhead. Here is the exact failing code (unedited, and yes, I
know it's dumb -- I'm trying to illustrate the problem)

868  MODESET KEY=NZERO
Make sure we are in Key 8  
869+* MACDATE Y-3 81030

00055C  871+ CNOP  0,4

00055C 4510 C56400564   872+ BAL   1,*+8

000560 0020 873+ DC
B'0010'
000564 5810 10000   874+ L 1,0(0,1)

000568 0A6B 875+ SVC   107

876  MODESET MODE=PROB
Allow SPKA 8   
877+* MACDATE Y-3 81030

00056A 0700 879+ CNOP  0,4

00056C 4510 C57400574   880+ BAL   1,*+8

000570 0004 881+ DC
B'0100'
000574 5810 10000   882+ L 1,0(0,1)

000578 0A6B 883+ SVC   107

884  MODESET KEY=ZERO
Get access to CSA  
885+* MACDATE Y-3 81030

00057A 0700 887+ CNOP  0,4

00057C 4510 C58400584   888+ BAL   1,*+8

000580 0030 889+ DC
B'0011'
000584 5810 10000   890+ L 1,0(0,1)

000588 0A6B 891+ SVC   107

00058A B20A 0080  00080 892  SPKA  X'80'(0)
*** Total experiment ***   

And here is the result (unedited):

CEE3202S The system detected a privileged-operation exception
(System Completion Code=0C2). 
  Location:

Program Unit:  Entry: DIRECTOR Statement:  Offset: +00DA

  Machine State:

ILC. 0004Interruption Code. 0002

PSW. 070D0400 A4991406

GPR0. _00022798  GPR1. _0030  GPR2.
_00F898C4  GPR3. _0001  
GPR4. _2499A9F8  GPR5. _25E98940  GPR6.
_2499CB38  GPR7. _25E71528  
GPR8. _26093E70  GPR9. _1C7AC560  GPR10
_000223BC  GPR11 _25E9336C  
GPR12 _24990E78  GPR13 _000226C8  GPR14
_A4991388  GPR15 _  
FPC.. 

FPR0. 45EA1145  FPR1. 43169000  

FPR2. 4D5438B2  C38FA400FPR3. 3500  

FPR4. 433E8000  FPR5. 41A0  

FPR6. 3500  FPR7. 3300  

FPR8.   FPR9.   

FPR10   FPR11   

FPR12   FPR13   

FPR14   FPR15   

 

Storage dump near condition, beginning at location: 249913F2

  +00 249913F2  07004510 C584 00305810 1A6B  B20A0080
A73E0002 A7840011 E32090F8  |Ed.,x...xd..T..8|

--
For IBM-MAIN subscribe / signoff / archive access instructions,

Re: LzLabs in ComputerWorld

2016-12-13 Thread zMan

"As a production or development machine the I/O was really poor."

Production, sure; we had one for dev, and while it wasn't an I/O screamer,
it was *dev*. So I'll have to disagree. Sure, a z800 would have been
better. So would a z900.

On Tue, Dec 13, 2016 at 10:34 AM, R.S. 
wrote:

> I dare to disagree.
> Although MP3000 was better than MP2000, it was still nothing good.
> As a demonstration/learning/portable machine it was much to big.
> As a production or development machine the I/O was really poor.
> No real channels except ESCON.
> No sysplex capability. A lot of SPOFs.
> z800 and followers were not much more expensive, but it's functionality
> was significantly better.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
>
> W dniu 2016-12-13 o 16:27, zMan pisze:
>
>> Oops, yeah, sorry. For some reason I do that with Gmail threads a lot.
>> Dumb
>> on my part. Thanks.
>>
>> MP3000 was a nice machine. Too bad IBM killed the follow-on.
>>
>> On Tue, Dec 13, 2016 at 10:12 AM, R.S. 
>> wrote:
>>
>> zMan,
>>>
>>> Please, re-read the message you responded to.
>>> Hint: Itschak asked the question, Radoslaw answered.
>>>
>>> Regarding zPDT - indeed, it is licensed to "non production" activities
>>> (*some* development tasks, learning).
>>> The difference is zPDT is a license - you buy the hardware, IBM delivers
>>> you USB key, emulator and right to use ADCD system.
>>> For MP3000 it was (past tense justified) just a small mainframe and one
>>> had to obtain the liceneses separately, as for any other mainframe
>>> machine.
>>>
>>> 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.2016 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.955.696 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: pdf manuals cannot be accessed

Bob,

Thank you for your offered help and support.
The links seem to be working again!

Dejan Stamatovic
CROZ D.O.O.

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

Re: LzLabs in ComputerWorld


I dare to disagree.
Although MP3000 was better than MP2000, it was still nothing good.
As a demonstration/learning/portable machine it was much to big.
As a production or development machine the I/O was really poor.
No real channels except ESCON.
No sysplex capability. A lot of SPOFs.
z800 and followers were not much more expensive, but it's functionality 
was significantly better.


--
Radoslaw Skorupka
Lodz, Poland








W dniu 2016-12-13 o 16:27, zMan pisze:

Oops, yeah, sorry. For some reason I do that with Gmail threads a lot. Dumb
on my part. Thanks.

MP3000 was a nice machine. Too bad IBM killed the follow-on.

On Tue, Dec 13, 2016 at 10:12 AM, R.S. 
wrote:


zMan,

Please, re-read the message you responded to.
Hint: Itschak asked the question, Radoslaw answered.

Regarding zPDT - indeed, it is licensed to "non production" activities
(*some* development tasks, learning).
The difference is zPDT is a license - you buy the hardware, IBM delivers
you USB key, emulator and right to use ADCD system.
For MP3000 it was (past tense justified) just a small mainframe and one
had to obtain the liceneses separately, as for any other mainframe machine.

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.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Dana Mitchell

In the 2000-2001 timeframe we were indeed pitched MP3000 as a replacement CPU 
for a production workload.  As I understood it at the time, the z 
infrastructure and internal DASD ran under, and was dependent upon an OS/2 
hypervisor.  

Dana

On Tue, 13 Dec 2016 12:53:14 +0100, R.S.  wrote:
> W dniu 2016-12-13 o 11:52, Itschak Mugzach pisze:
> Isn't mp3000 licensed to development only?
No.
However I would use past simple tense. ;-)

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread zMan

Oops, yeah, sorry. For some reason I do that with Gmail threads a lot. Dumb
on my part. Thanks.

MP3000 was a nice machine. Too bad IBM killed the follow-on.

On Tue, Dec 13, 2016 at 10:12 AM, R.S. 
wrote:

> zMan,
>
> Please, re-read the message you responded to.
> Hint: Itschak asked the question, Radoslaw answered.
>
> Regarding zPDT - indeed, it is licensed to "non production" activities
> (*some* development tasks, learning).
> The difference is zPDT is a license - you buy the hardware, IBM delivers
> you USB key, emulator and right to use ADCD system.
> For MP3000 it was (past tense justified) just a small mainframe and one
> had to obtain the liceneses separately, as for any other mainframe machine.
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
>
> W dniu 2016-12-13 o 15:44, zMan pisze:
>
> As others have noted, No, it wasn't. I suspect you're confusing MP3000 and
>> zPDT.
>>
>> 2016-12-13 6:53 GMT-05:00 R.S. :
>>
>> W dniu 2016-12-13 o 11:52, Itschak Mugzach pisze:
>>>
>>> Isn't mp3000 licensed to development only?

 No.
>>> However I would use past simple tense. ;-)
>>>
>>>
>>> --
>>> 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.2016 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.955.696 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: Question on SPKA and Control Register 3

ok, thanks, all the example I have specify both for some reason, thanks 
Carmen 

- Original Message -

From: "Charles Mills"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 13, 2016 9:20:36 AM 
Subject: Re: Question on SPKA and Control Register 3 

Neither. They are independent. You can specify either or both independently. 
KEY=0 lets you access everything. MODE=SUPE lets you do everything. (More or 
less.) 

Charles 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Tuesday, December 13, 2016 7:08 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Question on SPKA and Control Register 3 

Sorry again folks - I forgot NOT to send replies via my work email 









Not sure my assembler is very weak, but don't you have to specify supervisor 
state when setting key ZERO, or is that just assumed. 


MODESET KEY=ZERO,MODE=SUP ? 

-- 
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: Question on SPKA and Control Register 3

Neither. They are independent. You can specify either or both independently. 
KEY=0 lets you access everything. MODE=SUPE lets you do everything. (More or 
less.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, December 13, 2016 7:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

Sorry again folks - I forgot NOT to send replies via my work email 









Not sure my assembler is very weak, but don't you have to specify supervisor 
state when setting key ZERO, or is that just assumed. 


MODESET KEY=ZERO,MODE=SUP ? 

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

Re: LzLabs in ComputerWorld


zMan,

Please, re-read the message you responded to.
Hint: Itschak asked the question, Radoslaw answered.

Regarding zPDT - indeed, it is licensed to "non production" activities 
(*some* development tasks, learning).
The difference is zPDT is a license - you buy the hardware, IBM delivers 
you USB key, emulator and right to use ADCD system.
For MP3000 it was (past tense justified) just a small mainframe and one 
had to obtain the liceneses separately, as for any other mainframe machine.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2016-12-13 o 15:44, zMan pisze:

As others have noted, No, it wasn't. I suspect you're confusing MP3000 and
zPDT.

2016-12-13 6:53 GMT-05:00 R.S. :


W dniu 2016-12-13 o 11:52, Itschak Mugzach pisze:


Isn't mp3000 licensed to development only?


No.
However I would use past simple tense. ;-)


--
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.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: Question on SPKA and Control Register 3

Sorry again folks - I forgot NOT to send replies via my work email 









Not sure my assembler is very weak, but don't you have to specify supervisor 
state when setting key ZERO, or is that just assumed. 


MODESET KEY=ZERO,MODE=SUP ? 

Carmen 
- Original Message -

From: "Carmen P Vitullo"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, December 13, 2016 8:53:36 AM 
Subject: Re: Question on SPKA and Control Register 3 

You have received a secure message from "Vitullo, Carmen P" 
 entitled, "RE: Question on SPKA and Control 
Register 3". 

You can view the message (before 12/27/2016) at the following web address: 
https://mg.usablecs.com/enduser/msg.html?x=d-d9057c9216e3623c177c7858279794f718db8ccdf043b3247eae507fc6acdb1417513071aa8049a1b99ad48d25108b9f58a33ed03e4f47ada7fce534cf706344
 


-
 
Delivered with MailGate SC (TM) 
http://www.axway.com 
MailGate SC is a trademark of Axway. 





-- 
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: Question on SPKA and Control Register 3

2016-12-13 Thread Vitullo, Carmen P

You have received a secure message from "Vitullo, Carmen P" 
 entitled, "RE: Question on SPKA and Control 
Register 3".

You can view the message (before 12/27/2016) at the following web address:
  
https://mg.usablecs.com/enduser/msg.html?x=d-d9057c9216e3623c177c7858279794f718db8ccdf043b3247eae507fc6acdb1417513071aa8049a1b99ad48d25108b9f58a33ed03e4f47ada7fce534cf706344


-
Delivered with MailGate SC (TM)
http://www.axway.com
MailGate SC is a trademark of Axway.





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

Re: Question on SPKA and Control Register 3

> When? Does it fail during stuff 1 or stuff 2?

Not certain. At the end of the sequence for sure. Probably in stuff (two).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Tuesday, December 13, 2016 6:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

Charles Mills wrote:

>*  Enter APF-authorized and with Key=8
>  MODESET KEY=ZERO,MODE=SUP
>*  do stuff (one)
>  MODESET MODE=PROB
>*  do stuff (two)
>  MODESET KEY=NZERO

>leaves you in a state in which SPKA 8's will fail.

When? Does it fail during stuff 1 or stuff 2? From what you wrote, I believe it 
is during stuff 2 (after MODE=PROB)?

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

Re: Question on SPKA and Control Register 3

Okay, there is just no doubt in my mind that the use of MODESET precludes
the use of SPKA (and I'm not certain how to get around it other than to use
MODESET (with its attendant SVC) rather than SPKA). It's code that runs
millions of times per hour on multiple LPARs so I am trying to minimize
gratuitous overhead. Here is the exact failing code (unedited, and yes, I
know it's dumb -- I'm trying to illustrate the problem)

868  MODESET KEY=NZERO
Make sure we are in Key 8  
869+* MACDATE Y-3 81030

00055C  871+ CNOP  0,4

00055C 4510 C56400564   872+ BAL   1,*+8

000560 0020 873+ DC
B'0010'
000564 5810 10000   874+ L 1,0(0,1)

000568 0A6B 875+ SVC   107

876  MODESET MODE=PROB
Allow SPKA 8   
877+* MACDATE Y-3 81030

00056A 0700 879+ CNOP  0,4

00056C 4510 C57400574   880+ BAL   1,*+8

000570 0004 881+ DC
B'0100'
000574 5810 10000   882+ L 1,0(0,1)

000578 0A6B 883+ SVC   107

884  MODESET KEY=ZERO
Get access to CSA  
885+* MACDATE Y-3 81030

00057A 0700 887+ CNOP  0,4

00057C 4510 C58400584   888+ BAL   1,*+8

000580 0030 889+ DC
B'0011'
000584 5810 10000   890+ L 1,0(0,1)

000588 0A6B 891+ SVC   107

00058A B20A 0080  00080 892  SPKA  X'80'(0)
*** Total experiment ***   

And here is the result (unedited):

CEE3202S The system detected a privileged-operation exception
(System Completion Code=0C2). 
  Location:

Program Unit:  Entry: DIRECTOR Statement:  Offset: +00DA

  Machine State:

ILC. 0004Interruption Code. 0002

PSW. 070D0400 A4991406

GPR0. _00022798  GPR1. _0030  GPR2.
_00F898C4  GPR3. _0001  
GPR4. _2499A9F8  GPR5. _25E98940  GPR6.
_2499CB38  GPR7. _25E71528  
GPR8. _26093E70  GPR9. _1C7AC560  GPR10
_000223BC  GPR11 _25E9336C  
GPR12 _24990E78  GPR13 _000226C8  GPR14
_A4991388  GPR15 _  
FPC.. 

FPR0. 45EA1145  FPR1. 43169000  

FPR2. 4D5438B2  C38FA400FPR3. 3500  

FPR4. 433E8000  FPR5. 41A0  

FPR6. 3500  FPR7. 3300  

FPR8.   FPR9.   

FPR10   FPR11   

FPR12   FPR13   

FPR14   FPR15   

 

Storage dump near condition, beginning at location: 249913F2

  +00 249913F2  07004510 C584 00305810 1A6B  B20A0080
A73E0002 A7840011 E32090F8  |Ed.,x...xd..T..8|

Any ideas?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, December 13, 2016 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

@Peter, @Bin, it's really failing and there is no flaw (I believe!) in the
SPKA code. Not much code or dump is relevant. Hard to go wrong with SPKA
0(R1) when the contents of R1 in the minidump is xx80 (and yes, the
instruction is still B20A1000 in the display of the code near the PSW
address).

@Jim has the key. The problem is from earlier MODESET macros. I have not
totally put my finger on the exact necessary and sufficient sequence, but
what @Jim seems to be saying, and what I *believe* I am seeing, is the
following:

*  Enter APF-authorized and with Key=8
  MODESET KEY=ZERO,MODE=SUP
*  do stuff (one)
  MODESET MODE=PROB
*  do stuff (two)
  MODESET KEY=NZERO

leaves you in a state in which SPKA 8's will fail.

Or as @Jim puts it

,MODE=PROB,
 MODE=SUP 
Specifies that the PSW problem state indicator (bit 15) is to be either
turned on (PROB) or turned off (SUP). If the MODESET operation completes
with a problem

Re: pdf manuals cannot be accessed

Dejan,

If you need a specific manual. Let me know. I have the 2.2 PDF library 
downloaded.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dejan Stamatovic
Sent: Tuesday, December 13, 2016 9:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: pdf manuals cannot be accessed

It's not just you! 
Working with pdfs  is something I do day in day out!

Dejan Stamatovic

CROZ D.O.O.

--
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: LzLabs in ComputerWorld

2016-12-13 Thread zMan

As others have noted, No, it wasn't. I suspect you're confusing MP3000 and
zPDT.

2016-12-13 6:53 GMT-05:00 R.S. :

> W dniu 2016-12-13 o 11:52, Itschak Mugzach pisze:
>
>> Isn't mp3000 licensed to development only?
>>
> No.
> However I would use past simple tense. ;-)
>
>
> --
> 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.2016 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.955.696 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: pdf manuals cannot be accessed

It's not just you! 
Working with pdfs  is something I do day in day out!

Dejan Stamatovic

CROZ D.O.O.

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

Re: Question on SPKA and Control Register 3

Charles Mills wrote:

>*  Enter APF-authorized and with Key=8
>  MODESET KEY=ZERO,MODE=SUP
>*  do stuff (one)
>  MODESET MODE=PROB
>*  do stuff (two)
>  MODESET KEY=NZERO

>leaves you in a state in which SPKA 8's will fail.

When? Does it fail during stuff 1 or stuff 2? From what you wrote, I believe it 
is during stuff 2 (after MODE=PROB)?

I must admit this thread is interesting. 

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: pdf manuals cannot be accessed

Susan Shumway wrote:

>Yes, indeed, both http://www.redbooks.ibm.com/ and 
>http://publibz.boulder.ibm.com/ seem to be down. 
>I'm sure the necessary folks already know about it and are working on getting 
>them back up and running.

Thanks. I'm grateful for your kindness.

>Use KC in the meantime for the z doc. 

This is what I used today (to look up a SMFPRMxx parameter).

But then, I prefer PDF and Bookmanager formats. Ok, it is perhaps just me... ;-)

(KC webpages and other pages from IBM do sometimes download 
bullet-fast/turtle-slow/light-fast/snail-slow or just nothing... It depends on 
what router is being active all the way from USA to Sunny and Hot and Dry South 
Africa begging for some welcome rain...)

;-D

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: Question on SPKA and Control Register 3

@Peter, @Bin, it's really failing and there is no flaw (I believe!) in the
SPKA code. Not much code or dump is relevant. Hard to go wrong with SPKA
0(R1) when the contents of R1 in the minidump is xx80 (and yes, the
instruction is still B20A1000 in the display of the code near the PSW
address).

@Jim has the key. The problem is from earlier MODESET macros. I have not
totally put my finger on the exact necessary and sufficient sequence, but
what @Jim seems to be saying, and what I *believe* I am seeing, is the
following:

*  Enter APF-authorized and with Key=8
  MODESET KEY=ZERO,MODE=SUP
*  do stuff (one)
  MODESET MODE=PROB
*  do stuff (two)
  MODESET KEY=NZERO

leaves you in a state in which SPKA 8's will fail.

Or as @Jim puts it

,MODE=PROB,
 MODE=SUP 
Specifies that the PSW problem state indicator (bit 15) is to be either
turned on (PROB) or turned off (SUP). If the MODESET operation completes
with a problem state PSW, the caller?s PSW key mask (PKM) is set according
to the following rules: 

?The bit matching the resulting PSW key is set on.
?The bit matching key 9 is set on. 
?For a task attached with ATTACHX using the KEY=NINE parameter, the  bits
that were on in the PKM of the ATTACHX issuer are set on. 
?All other bits are set off.

In other words, if you issue a MODESET MODE=PROB in key zero you lose the
right to issue SPKA 8.

I *think* (still running experiments) that simply following that last
MODESET above with MODESET MODE=PROB solves the problem, or probably just
adding ,MODE=PROB to that last MODESET will do the trick.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Tuesday, December 13, 2016 5:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on SPKA and Control Register 3

>I had guessed that an APF-authorized but otherwise "ordinary" program 
>running with Key 8 would be able to issue an SPKA with an "address" of 
>xx8x in problem state without getting a S0C2.

Whether APF-authorized or not, it can. If your program is getting S0C2, then
you are most likely not doing what you think you are doing.

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

Re: Position available

2016-12-13 Thread Mike Myers


Alan:

I would be interested if this can be done remotely. If so, please fill 
in the details. I am in Goldsboro, NC an hour east of Raleigh. I am a 
long-time z/OS sysprog.


Mike Myers

On 12/12/2016 04:51 PM, Alan Haff wrote:

I work for a multinational ISV and we have an opening for a z/OS sysprog. The system is located 
in the Rocky Mountain west but relocation isn't required. We run z/OS 1.13, 2.1 and 2.2, and 
subsystems include IMS 12, 13 & 14; CICS 3.1, 4.1, 4.2, 5.1 & 5.2; DB2 8, 9 & 10; 
and MQ 7 & 8. The hardware is a z13s (2965-G03) with 88GB of memory, three CPs, three IFLs 
and an ICF, connected to a DS8000 with 33.5 TiB of storage.

Let me know if you're interested and I'll fill you in on the details.

--
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: pdf manuals cannot be accessed

2016-12-13 Thread Susan Shumway

Yes, indeed, both http://www.redbooks.ibm.com/ and 
http://publibz.boulder.ibm.com/ seem to be down. I'm sure the necessary 
folks already know about it and are working on getting them back up and 
running.


Use KC in the meantime for the z doc. If you're desperate for a 
particular Redbook/etc., perhaps somebody else on here has it to pass 
around?


-Sue Shumway

On 12/13/16 6:36 AM, Richards, Robert B. wrote:

http://publibz.boulder.ibm.com/ appears to be down at the moment.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dejan Stamatovic
Sent: Tuesday, December 13, 2016 6:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: pdf manuals can not be accessed

Does anybody have problems with accessing pdf manuals on the following link:

http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r2pdf/#IEA

Dejan Stamatovic

CROZ D.O.O.

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: Question on SPKA and Control Register 3

2016-12-13 Thread Peter Relson

>I had guessed that an APF-authorized but otherwise "ordinary" program
>running with Key 8 would be able to issue an SPKA with an "address" of
>xx8x in problem state without getting a S0C2.

Whether APF-authorized or not, it can. If your program is getting S0C2, 
then you are most likely not doing what you think you are doing.

A "normal" program running on z/OS will be given control in key 8 with PKM 
of x'00C0' allowing SPKA's between keys 8 and 9 (including 8 to 8):

PSW = 0785   7000
 -> 7000'  SPKAB20A0080  
CR 3 =  00C0

Or, using the base-displacement form:

PSW = 0785   7004 
GPR  2 =  FF80
7004'  SPKAB20A2000 
PSW = 0785   7008
 
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: Shopz Hung?

Nah, it migrated over to the Redbooks site! 

But I agree with the Shopz assessment. Everything I submitted yesterday 
"eventually" was processed.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, December 13, 2016 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz Hung?

Yea, that was the symptom I was seeing.   All seems fine this morning however.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Magee
Sent: Monday, December 12, 2016 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz Hung?

What ever it is, I think the same problem is also affecting SMP/E's RECEIVE 
service retrieval.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
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: Shopz Hung?

2016-12-13 Thread Jousma, David

Yea, that was the symptom I was seeing.   All seems fine this morning however.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Magee
Sent: Monday, December 12, 2016 2:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz Hung?

What ever it is, I think the same problem is also affecting SMP/E's RECEIVE 
service retrieval.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: LzLabs in ComputerWorld


W dniu 2016-12-13 o 11:52, Itschak Mugzach pisze:

Isn't mp3000 licensed to development only?

No.
However I would use past simple tense. ;-)

--
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.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: pdf manuals can not be accessed

2016-12-13 Thread Crispin Hugo

No Probs

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dejan Stamatovic
Sent: 13 December 2016 11:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: pdf manuals can not be accessed

Does anybody have problems with accessing pdf manuals on the following link:

http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r2pdf/#IEA

Dejan Stamatovic

CROZ D.O.O.

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

pdf manuals can not be accessed

Does anybody have problems with accessing pdf manuals on the following link:

http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r2pdf/#IEA

Dejan Stamatovic

CROZ D.O.O.

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

Re: Question on SPKA and Control Register 3

2016-12-13 Thread Binyamin Dissen

It would not fail under MVS.

My guess is that you are not checking the correct thing.

Post the minidump.

On Mon, 12 Dec 2016 13:49:09 -0800 Charles Mills  wrote:

:>I had guessed that an APF-authorized but otherwise "ordinary" program
:>running with Key 8 would be able to issue an SPKA with an "address" of
:>xx8x in problem state without getting a S0C2. I appear to have guessed
:>wrong. I just wanted to do a reality check to make sure I had not
:>fat-fingered something: typically a program in Key 8 does *not* have a
:>PSW-key-mask bit of one for SPK 8 in Control Register 3? Is that correct?

:>Just out of curiosity -- why would that be? Why not let a program set its
:>SPK back to its original state?

--
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: LzLabs in ComputerWorld

2016-12-13 Thread Parwez Hamid

The MP3000 came with integrated disk and was not restricted to dev only. A lot 
of 'small' customers used it for production work. Having said this it was ideal 
for dev. End of Service for the system was in 2012.

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

Re: redbooks can not be accessed

2016-12-13 Thread Parwez Hamid

The website is down and they are working on it.

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

Re: redbooks can not be accessed

2016-12-13 Thread Crispin Hugo

I get the same as you.

Crispin Hugo
Systems Specialist
Macro 4 Limited
d: +44 1293 872121 | m: +44 7753951308 | t: +44 1293 872000 | www.macro4.com

      

Registered office: The Orangery, Turners Hill Road, Worth, Crawley, West 
Sussex, RH10 4SS
Registered in England no: 00927588

Please consider the environment and only print this email if you really need to.

This message (including any attachments) contains confidential information that 
is PRIVILEGED, CONFIDENTIAL and/or ATTORNEY WORK PRODUCT and is intended only 
for the individual(s) named herein. If you are not the intended recipient, you 
are hereby notified that any dissemination, distribution or copying of this 
email is strictly prohibited. If you have received this message in error, 
please notify the Macro 4 Postmaster (postmas...@macro4.com) of the error 
immediately, do not read or use the email and any attachments in any manner, 
destroy all copies, and delete it from your system if the communication was 
sent via email. Macro 4 Limited, Tel: +44 1293 872000 Fax: +44 1293 872001.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dejan Stamatovic
Sent: 13 December 2016 10:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: redbooks can not be accessed

Anybody seeing the problem I see?

 http://www.redbooks.ibm.com/

can not be accessed.

Dejan Stamatovic

CROZ D.O.O

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: redbooks can not be accessed

Yes, I am seeing the same thing. It just spins...

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dejan Stamatovic
Sent: Tuesday, December 13, 2016 5:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: redbooks can not be accessed

Anybody seeing the problem I see?

 http://www.redbooks.ibm.com/

can not be accessed.

Dejan Stamatovic

CROZ D.O.O

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

redbooks can not be accessed

Anybody seeing the problem I see?

 http://www.redbooks.ibm.com/

can not be accessed.

Dejan Stamatovic

CROZ D.O.O

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

Re: LzLabs in ComputerWorld

2016-12-13 Thread Itschak Mugzach

Isn't mp3000 licensed to development only?

ITschak

בתאריך 13 בדצמ 2016 12:50,‏ "R.S."  כתב:

> W dniu 2016-12-13 o 11:05, Dave Wade pisze:
>
>> [...]
>> There are many sites out there that have been deserted by IBM who only
>> want to sell "Big Iron". There is nothing like the MP3000 for
>> price/performance available today, yet many were sold. What options are
>> there for users of small mainframes?
>>
>> I can't see IBM prices but the lowest price box appears to be around
>> $75,000. When we bought our MP3000 (used) it was less than half that price,
>> and that included the DASD. I recon that if you are adding DASD then you
>> are looking at $100k -> $150K
>>
> Yes and no.
> You can buy second-hand machine (with support if you want) for "close to
> peanut" price.
> How much it depends, but I would bet you can have CPC+DASD for less than
> $10,000. Or even less if you decide to buy older generation.
>
> --
> 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.2016 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
>
>
> --
> 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: LzLabs in ComputerWorld


W dniu 2016-12-13 o 11:05, Dave Wade pisze:

[...]
There are many sites out there that have been deserted by IBM who only want to sell 
"Big Iron". There is nothing like the MP3000 for price/performance available 
today, yet many were sold. What options are there for users of small mainframes?

I can't see IBM prices but the lowest price box appears to be around $75,000. When 
we bought our MP3000 (used) it was less than half that price, and that included 
the DASD. I recon that if you are adding DASD then you are looking at $100k -> 
$150K

Yes and no.
You can buy second-hand machine (with support if you want) for "close to 
peanut" price.
How much it depends, but I would bet you can have CPC+DASD for less than 
$10,000. Or even less if you decide to buy older generation.


--
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.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: z/OS PDFs