Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

2017-09-13 Thread Charles Mills
> In my opinion PDSE design wasn't and still isn't ready for prime time.
> It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB because it
depends on a started task.

Kind of an arbitrary standard, isn't it? I could argue VSAM or DB2 are not
ready for prime time because you can't use them for SYS1.NUCLEUS residence.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, September 13, 2017 8:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support
for Doc for COBOL

[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced 
>Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.

In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB because it
depends on a started task.  While I would agree that SYS1.NUCLEUS could be 

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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread Timothy Sipples
Peter Relson wrote:
>Isn't the answer really: no, it would not have prevented the breach but it
>would have prevented the breach from having the undesirable effects (e.g.,
>exposing sensitive data)?

First of all, a strong, multi-layered defense can indeed prevent (inner)
breaches even as you've (re)defined them. A successful breach often
involves "leapfrogging." That is, the attacker penetrates the first (only?)
line of defense, obtains unencrypted or too weakly encrypted credentials,
then uses those credentials to penetrate the next layer. Indeed, this is
precisely the reason why KDFAES support was added to RACF some time ago.
(Please turn KDFAES, passphrases, and, preferably, multi-factor
authentication on if you haven't already! And try to make sure that RACF or
your other security manager is put back in charge of at least
authorization. If RACF only knows about server-level IDs because
authorization has been fully delegated elsewhere, that's probably bad.)

In my view, your definition is not what most people mean with the word
"breach." I agree with most people. I don't think a hyper technical
definition is too useful here, and it could easily be misleading and take
precious focus off what the planet really needs. If your definition of
"breach" holds, then you have to clarify why sending sensitive data over a
properly encrypted VPN connection, or discarding/recycling a properly
encrypted and physically intact disk or tape, is not a "breach." Those
patterns also involve someone potentially or actually able to intercept,
record, and do whatever they wish with the encrypted data. The data, in
encrypted form, is made public. But properly encrypted data, without access
to the private key, is useless. Properly encrypted data could be burned
onto CDs and mailed to every household -- AOL style -- and there'd be no
breach in any sensible meaning of the word.

Dictionaries appear to agree with me (and others):

http://www.dictionary.com/browse/breach?s=t

As an analogy, a police or military force will often, quite deliberately,
allow an attacker entry into a particular zone. Even facilitate and
encourage that entry. Is that a "breach"? No, it's not. The reason they do
this is because it makes it easier to catch the attacker and to gather
evidence, as in police sting operations. It is *then* possible for
operational security to be breached if the attacker is more clever than
expected, but that's rare.

So I disagree with your definition of "breach." I would use words like
"unauthorized copying of encrypted data with no security impact" to
describe what you're describing.

Elardus Engelbrecht wrote:
>If breachers are insiders themselves, you're basically out
>of luck and goodbye to your [sensitive and unencrypted] data.

No, I disagree again. In my view we shouldn't perpetuate the myth that the
"god administrator" is necessary. It's just not true. We know how to
design, deliver, and operate systems that do not require operators and
administrators to be deities, at least not solo deities. We know how to
prevent insider attacks. The whole concept of "inside" versus "outside" is
outmoded at best. It's "Maginot Line" thinking, and it demonstrably doesn't
work.

Many organizations have already adopted a non-god IT approach, quite
successfully. z/OS Data Set Encryption, properly implemented, is one of the
unique capabilities that can help.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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


AW: Re: IEFSCHAS - Using more CPU

2017-09-13 Thread Peter Hunkeler
>Sometimes I see SMF 30 for Master Scheduler AS showing very large amounts of 
>memory. >>SMF 30 is extremely unreliable for memory anyway, so I'm not sure 
>what to make of that.

You confuse me, Martin. I was not asking about the Master Scheduler (*MASTER*) 
nor about memory usage. What did you meant to tell me?


--
Peter Hunkeler


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


AW: Re: IEFSCHAS - Using more CPU

2017-09-13 Thread Peter Hunkeler
>IEFSCHAS is the "scheduler address space".
 >
>One of its functions is to handle cross-system ENF notifications.


Thanks. I knew it means "scheduling address space" but I was wondering what is 
being scheduled from there. So ENF signals are one part, you say. What else 
does it schedule? Just curious.


The correlation to GRS contention seems reasonable reason in our case. The GRS 
instance which is the "contention resolver" (can't remember how it is called 
right now) is using more CPU as well.


--
Peter Hunkeler



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


Re: Reload nucleus module dynamically

2017-09-13 Thread Peter Hunkeler


>Long time ago and when MVS first came out, we used to do this quite often 
>(once a week). A product we had called DUO (DOS under MVS). DUO maintained a 
>table in the nucleus for which dos jobs were running. They had a bug in their 
>code that would not delete entries. We had to go in and blank out the job 
>names that were not running(so as not to have to IPL). We finally got tired of 
>doing this and wrote a program that did it. 
Worked like a charm. They asked for the program and we were not in a good mood 
so we said no. It took them a year to figure out how to do it.My memory is hazy 
here but I think the degression was  
“duo” -> went to some company in Dallas? and then a year or two later CA bought 
them out. By then we had gotten rid of all the jobs. One of the long time 
contributors to IBM-Main used to work for the company if he hasn’t retired 
maybe he could speak up?


Ed, not sure how your comment relates to the topic at hand. You can always 
write a program to modify just about any bit in storage, but that has nothing 
to do with native support by the operating system. 
-- 
Peter Hunkeler 
 


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


Re: dynamic rexx function package

2017-09-13 Thread Ron hesketh
Hi Lionel,
 If I've understood correctly, you can use IRXSUBCM to dynamically 
define a host command enviroment.
I've used it for a DB2 host command environment I wrote years ago, long 
before the days of DSNREXX.
REXHCE is a rexx function I wrote to call IRXSUBCM .

CALL REXHCE "ADD","DB2","REXDB2"; 
 
ADDRESS DB2 "CONNECT "SSID  ;
 
do db2 stuff

CALL REXHCE "DELETE",ADD","DB2","REXDB2"; 

Regards,
   Ron



From:   "Dyck, Lionel B. (TRA)" 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   13/09/2017 09:05 PM
Subject:dynamic rexx function package
Sent by:IBM Mainframe Discussion List 



Has anyone developed a dynamic rexx function package tool that can be 
called when a rexx exec starts and then be easily removed when it ends - 
kinda like dynamic steplib?

(cross posted to ibm-main, tso-rexx, and ispf-l)
--
Lionel B. Dyck
Mainframe Systems Programmer - TRA


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

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

___

This email has been scanned by the Bankwest Email Security System.
___



___
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.

This electronic transmission including any attachments is intended only
for those to whom it is addressed. It may contain copyright material or
information that is confidential, privileged or exempt from disclosure by law.
Any claim to privilege is not waived or lost by reason of mistaken transmission
of this information. If you are not the intended recipient you must not
distribute or copy this transmission and should please notify the sender.
Your costs for doing this will be reimbursed by the sender.

We do not accept liability in connection with computer virus, data corruption,
delay, interruption, unauthorised access or unauthorised amendment.
___


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

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


Re: AW: Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Andrew Rowley

On 13/09/2017 3:00 PM, Peter Hunkeler wrote:
I don't understand what you mean by "before the job starts but not 
before initiation".
I was thinking of the assignment to an initiator as initiation, but you 
are right, that is backwards and probably the wrong terminology. I guess 
initiation is what is done by the initiator, so what I should have said 
is something like "not before being assigned to an initiator".


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Mark Jacobs - Listserv
As it happened to work out, we had a scheduled DR test this week, but 
our mainframe is now in Poughkeepsie at an IBM data center.


Mark Jacobs



Edward Gould 
September 13, 2017 at 6:35 PM

Thanks for the memory jar.
Did your company go into DR mode when IRMA hit?

Ed


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Mark Jacobs - Listserv 
September 13, 2017 at 3:57 PM
University Computing Company (UCC), later known as UCCel. I think that 
DUO was UCC-2, TMS was UCC-1.


Mark Jacobs


Edward Gould 
September 13, 2017 at 3:41 PM

On Sep 13, 2017, at 12:11 PM, Peter Hunkeler  wrote:


What modules do you want to reload? If that is in LPA and/or Linklist, you 
better be careful before issuing commands to refresh them. Of course YMMV.

Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is the 
linklist. They are different beasts. The first two are different areas in the 
virtual address space map, the third is noting but a list of data set to be 
searched for load modules. The OP asked about dynamically updating the nucleus, 
and this is nothing that MVS supports up to date.


--
Peter Hunkeler


Peter:
Long time ago and when MVS first came out, we used to do this quite often (once 
a week). A product we had called DUO (DOS under MVS). DUO maintained a table in 
the nucleus for which dos jobs were running. They had a bug in their code that 
would not delete entries. We had to go in and blank out the job names that were 
not running(so as not to have to IPL). We finally got tired of doing this and 
wrote a program that did it.
Worked like a charm. They asked for the program and we were not in a good mood 
so we said no. It took them a year to figure out how to do it.My memory is hazy 
here but I think the degression was
“duo” ->  went to some company in Dallas? and then a year or two later CA 
bought them out. By then we had gotten rid of all the jobs. One of the long time 
contributors to IBM-Main used to work for the company if he hasn’t retired maybe 
he could speak up?

Ed



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


Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 'phish...@timeinc.com'.

Peter Hunkeler 
September 13, 2017 at 1:11 PM


Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is 
the linklist. They are different beasts. The first two are different 
areas in the virtual address space map, the third is noting but a list 
of data set to be searched for load modules. The OP asked about 
dynamically updating the nucleus, and this is nothing that MVS 
supports up to date.



--
Peter Hunkeler





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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Elardus Engelbrecht 
September 13, 2017 at 8:43 AM

You better listen to Binyamin Dissen who kinldy replied to you.

What modules do you want to reload? If that is in LPA and/or Linklist, 
you better be careful before issuing commands to refresh them. Of 
course YMMV.


If these modules are SVC modules, I would recommend you to rather IPL.

But ask your ISV, they wrote the product and they certainly can assist 
you way better than IBM-MAIN.


If still unsure, put all your updated libraries on another set of 
volsers and IPL.


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether 

Re: Reload nucleus module dynamically

2017-09-13 Thread Edward Gould
> On Sep 13, 2017, at 2:57 PM, Mark Jacobs - Listserv 
>  wrote:
> 
> University Computing Company (UCC), later known as UCCel. I think that DUO 
> was UCC-2, TMS was UCC-1.
> 
> Mark Jacobs

Thanks for the memory jar.
Did your company go into DR mode when IRMA hit?

Ed


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


Re: Reload nucleus module dynamically

2017-09-13 Thread Blaicher, Christopher Y.
Updating a table, even if it is in there as a load module, that happens to be 
in the NUC is one thing.  Replacing a module in the NUC is a whole different 
thing.  I could see loading a replacement module into fixed CSA and changing a 
pointer to it, assuming the address for it is in a system vector or control 
block.  Updating the NUC itself while it is running?  Not happening.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Wednesday, September 13, 2017 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Reload nucleus module dynamically

> On Sep 13, 2017, at 12:11 PM, Peter Hunkeler  wrote:
>
>> What modules do you want to reload? If that is in LPA and/or Linklist, you 
>> better be careful before issuing commands to refresh them. Of course YMMV.
>
>
> Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is the 
> linklist. They are different beasts. The first two are different areas in the 
> virtual address space map, the third is noting but a list of data set to be 
> searched for load modules. The OP asked about dynamically updating the 
> nucleus, and this is nothing that MVS supports up to date.
>
>
> --
> Peter Hunkeler

Peter:
Long time ago and when MVS first came out, we used to do this quite often (once 
a week). A product we had called DUO (DOS under MVS). DUO maintained a table in 
the nucleus for which dos jobs were running. They had a bug in their code that 
would not delete entries. We had to go in and blank out the job names that were 
not running(so as not to have to IPL). We finally got tired of doing this and 
wrote a program that did it.
Worked like a charm. They asked for the program and we were not in a good mood 
so we said no. It took them a year to figure out how to do it.My memory is hazy 
here but I think the degression was “duo” -> went to some company in Dallas? 
and then a year or two later CA bought them out. By then we had gotten rid of 
all the jobs. One of the long time contributors to IBM-Main used to work for 
the company if he hasn’t retired maybe he could speak up?

Ed

>
>


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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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


Re: DB2

2017-09-13 Thread Barry Merrill
It's not exactly what you asked for, but this 1995 Newsletter Note provides
some information on DB2 I/O counts in SMF 42 Subtype 6 records,
MXG dataset TYPE42DS.  
2. It has always been impossible to track DB2 I/O activity (because the
Media Manager thought itself so fast that it was not necessary to
count I/Os!), but now, the TYPE42DS dataset (from type 42 SMF data)
records both interval and close statistics on ALL datasets (not just
those managed by SMS).  As both the DB2 Database and Tablespace or
Indexspace names are contained in the DSNAME in TYPE42DS, you can
analyze DB2 I/O for each tablespace for each DB2 subsystem. The naming
pattern for the DB2 VSAM datasets looks like this:
   DSNAME=subsystem.DSNDBD.database.table
or, written with MXG variable names (from T102S105 dataset):
   DSNAME=QWHSSSID.DSNDBD.QW0105DN.QW0105TN
asQWHSSSID is the DB2 subsystem Name (almost always DB2...)
  DSNDBD   is a constant string for the data component
  QW0105DN is the DB2 Database Name, and
  QW0105TN is the DB2 Tablespace or Indexspace Name.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Driscoll
Sent: Wednesday, September 13, 2017 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DB2

Q1 - Yes
Q2 - No, DB2 performance records report on the physical level, so the DBID an 
OBID, internal 2 byte fields the uniquely identify the space (table or index) 
being accessed is reported on, not the table id, which is a logical construct. 
There are some audit records that contain DB2 table OBID's, but they are only 
captured at the first access of the thread.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, September 13, 2017 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DB2

Are there any DB2 systems level people in the Group?

Is there a SMF DB2 performance record/or just record that contains the name of 
the table(s) being accessed In the DB2 Space

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 877.328.2932 
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

--
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: Reload nucleus module dynamically

2017-09-13 Thread Mark Jacobs - Listserv
University Computing Company (UCC), later known as UCCel. I think that 
DUO was UCC-2, TMS was UCC-1.


Mark Jacobs


Edward Gould 
September 13, 2017 at 3:41 PM

On Sep 13, 2017, at 12:11 PM, Peter Hunkeler  wrote:


What modules do you want to reload? If that is in LPA and/or Linklist, you 
better be careful before issuing commands to refresh them. Of course YMMV.

Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is the 
linklist. They are different beasts. The first two are different areas in the 
virtual address space map, the third is noting but a list of data set to be 
searched for load modules. The OP asked about dynamically updating the nucleus, 
and this is nothing that MVS supports up to date.


--
Peter Hunkeler


Peter:
Long time ago and when MVS first came out, we used to do this quite often (once 
a week). A product we had called DUO (DOS under MVS). DUO maintained a table in 
the nucleus for which dos jobs were running. They had a bug in their code that 
would not delete entries. We had to go in and blank out the job names that were 
not running(so as not to have to IPL). We finally got tired of doing this and 
wrote a program that did it.
Worked like a charm. They asked for the program and we were not in a good mood 
so we said no. It took them a year to figure out how to do it.My memory is hazy 
here but I think the degression was
“duo” ->  went to some company in Dallas? and then a year or two later CA 
bought them out. By then we had gotten rid of all the jobs. One of the long time 
contributors to IBM-Main used to work for the company if he hasn’t retired maybe 
he could speak up?

Ed



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


Please be alert for any emails that may ask you for login information or 
directs you to login via a link. If you believe this message is a phish or 
aren't sure whether this message is trustworthy, please send the original 
message as an attachment to 'phish...@timeinc.com'.

Peter Hunkeler 
September 13, 2017 at 1:11 PM


Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is 
the linklist. They are different beasts. The first two are different 
areas in the virtual address space map, the third is noting but a list 
of data set to be searched for load modules. The OP asked about 
dynamically updating the nucleus, and this is nothing that MVS 
supports up to date.



--
Peter Hunkeler





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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Elardus Engelbrecht 
September 13, 2017 at 8:43 AM

You better listen to Binyamin Dissen who kinldy replied to you.

What modules do you want to reload? If that is in LPA and/or Linklist, 
you better be careful before issuing commands to refresh them. Of 
course YMMV.


If these modules are SVC modules, I would recommend you to rather IPL.

But ask your ISV, they wrote the product and they certainly can assist 
you way better than IBM-MAIN.


If still unsure, put all your updated libraries on another set of 
volsers and IPL.


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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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


Re: CSST question

2017-09-13 Thread Tom Marchant
On Wed, 13 Sep 2017 08:59:02 -0500, Walt Farrell wrote:

>Again, I'm not an expert, but this is my interpretation: When you 
>do something that serializes, the CPU ensures that all fetches and 
>stores that have conceptually _completed_ by other CPUs are 
>actually complete before you proceed.

Does it? I read it differently. The way I read it is that all fetches and 
stores (and some other things) that have conceptually completed by 
_this_ CPU are actually complete before you proceed.

-- 
Tom Marchant

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Edward Gould
> On Sep 13, 2017, at 12:11 PM, Peter Hunkeler  wrote:
> 
>> What modules do you want to reload? If that is in LPA and/or Linklist, you 
>> better be careful before issuing commands to refresh them. Of course YMMV.
> 
> 
> Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is the 
> linklist. They are different beasts. The first two are different areas in the 
> virtual address space map, the third is noting but a list of data set to be 
> searched for load modules. The OP asked about dynamically updating the 
> nucleus, and this is nothing that MVS supports up to date.
> 
> 
> --
> Peter Hunkeler

Peter:
Long time ago and when MVS first came out, we used to do this quite often (once 
a week). A product we had called DUO (DOS under MVS). DUO maintained a table in 
the nucleus for which dos jobs were running. They had a bug in their code that 
would not delete entries. We had to go in and blank out the job names that were 
not running(so as not to have to IPL). We finally got tired of doing this and 
wrote a program that did it.
Worked like a charm. They asked for the program and we were not in a good mood 
so we said no. It took them a year to figure out how to do it.My memory is hazy 
here but I think the degression was 
“duo” -> went to some company in Dallas? and then a year or two later CA bought 
them out. By then we had gotten rid of all the jobs. One of the long time 
contributors to IBM-Main used to work for the company if he hasn’t retired 
maybe he could speak up?

Ed

> 
> 


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


Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

2017-09-13 Thread John Eells

Paul Gilmartin wrote:

On Wed, 13 Sep 2017 15:52:27 -0300, Clark Morris wrote:


In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
because it depends on a started task.  ...


In turn, I'd expect that prohibits program objects in SYS1.LPALIB.



Much of the PDSE code lives in LPALIB.  This precludes the use of 
program objects in any IPL-time LPA list data set.  The use of the PDSE 
started tasks (SMSPDSE and SMSPDSE1) are secondary to being able to 
build PLPA to begin with.


--
John Eells
IBM Poughkeepsie
ee...@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: CSST question

2017-09-13 Thread Greg Dyck

On 9/13/2017 12:26 PM, Charles Mills wrote:

Question: is there any way for the 'examining' code, possibly running on a
different CPU, to be assured of seeing a consistent (either 'before' or
'after') POINTER and ADDRESS contents? Possibly with serialization at some
point?


In general, no.

The architecture only guarantees storage consistency if the data is in 
the same double word, aligned on a double word boundary, in the general 
case (such as using LM or STM) or the same quad word, aligned on a quad 
word boundary, for a defined set of instructions (such as CDSG).


Regards,
Greg

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


Re: CSST question

2017-09-13 Thread Greg Dyck

On 9/12/2017 9:35 AM, Charles Mills wrote:

Disabling for interruptions is not sufficient in a multi-processor world, right?


Disabling for interrupts guarantees, even in a multi-processing world, 
that the executing unit of work will not lose control from the 
perspective of the logical CP that is executing under *most* cases. 
Disablement does not, at least as implemented/defined by MVS, include 
disabling for machine checks.  The cost of disabling and enabling is 
fairly costly, as well, and limited to supervisor state code, where you 
can guarantee that all data can be referenced without any resolvable 
program checks.  A lot of constraints... and the possibility exists in a 
virtualized world that the logical CP could lose control of the physical 
CP between two instructions even while disabled.



I don't pretend to be the world's biggest machine instruction expert. Am I 
reading the PoOp correctly that a task wishing another task's CSST to 
effectively appear to be entirely atomic (from its CPU's point of view) could 
achieve that effect by issuing a serialization instruction (BCR 15,0)?


Again, the intent is *not* for CSST to effectively appear to be entirely 
atomic.  Because it may not.  It is to guarantee that either the 
compare-and-swap and the footprint updates *both* occur (with or without 
being interrupted), or neither of the updates occur.  And it works for 
problem program state requestors.



What about interrupts to the observing task? Suppose it were re-dispatched on a 
different CPU after the BCR and before observing storage?


The observing task gets what it gets, and being (or not being) 
re-dispatched would not be significant.


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


Re: DB2

2017-09-13 Thread Wayne Driscoll
Q1 - Yes
Q2 - No, DB2 performance records report on the physical level, so the DBID an 
OBID, internal 2 byte fields the uniquely identify the space (table or index) 
being accessed is reported on, not the table id, which is a logical construct. 
There are some audit records that contain DB2 table OBID's, but they are only 
captured at the first access of the thread.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Wednesday, September 13, 2017 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DB2

Are there any DB2 systems level people in the Group?

Is there a SMF DB2 performance record/or just record that contains the name of 
the table(s) being accessed In the DB2 Space

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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


DB2

2017-09-13 Thread Steve Beaver
Are there any DB2 systems level people in the Group?

Is there a SMF DB2 performance record/or just record that contains the name
of the table(s) being accessed
In the DB2 Space

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


Re: PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

2017-09-13 Thread Paul Gilmartin
On Wed, 13 Sep 2017 15:52:27 -0300, Clark Morris wrote:
>
>In my opinion PDSE design wasn't and still isn't ready for prime time.
>It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
>because it depends on a started task.  ...
> 
In turn, I'd expect that prohibits program objects in SYS1.LPALIB.

-- gil

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


PDSE design flaws and need for COBOL 4.2 was Re: Lack of Support for Doc for COBOL

2017-09-13 Thread Clark Morris
[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
sipp...@sg.ibm.com (Timothy Sipples) wrote:

>IBM first introduced PDSEs about 27 years ago. IBM first introduced Java on
>OS/390 about 21 years ago.
>
>That's a long, long time ago.
>
>It's impossible to defend stubborn opposition to these and to other highly
>mature technologies. Business (and the business of government) will get
>done, with or without you. If that's how you choose to (mis)behave, then I
>can't criticize managers who decide to chuck you in the garbage heap of
>history. If you won't change, then you should be/will be changed. I suppose
>we can quibble about how much change makes business sense in particular
>contexts, but zero is the wrong answer.

In my opinion PDSE design wasn't and still isn't ready for prime time.
It couldn't and still can't handle SYS1.NUCLEUS and SYS1.LPALIB
because it depends on a started task.  While I would agree that
SYS1.NUCLEUS could be just a very big IPL text, that still leaves
SYS1.LPALIB and any other data sets read during systems
initialization.  Also the design of limiting PDSE sharing to being
within a sysplex contravened what many shops were doing.  It is like
being required to have BiSync controllers for consoles since channel
attached SNA controllers couldn't be accessed until the VTAM started
task was up (something that still rankles 30+ years later).  In both
cases limited functionality enabling use of data sets or devices
during system initialization could and should have been built into NIP
/ SYS1.NUCLEUS or SYS1.LPALIB.  I can not comment on the reliability
of PDSE when used as specified by IBM with sharing only within a
sysplex but the rate of corrective service and frequency of hiper
APARs would tell the story.  I remember the long teething period for
ICF catalogs.

Clark Morris
>
>Jimmy Iovine said it well: "Never stop being of service."
>
>(My views are my own.)
>
>
>Timothy Sipples
>IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
>E-Mail: sipp...@sg.ibm.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread Tom Brennan
Of course I think encryption helps security, but it can't stop someone 
from hacking a different way, such as using the methods already setup to 
decrypt data (like I think Steve was referring to).  For example, if I 
could get on a system and eventually get APF dataset authority, I could 
hack into RACF or even IOS/ICSF and watch the bits fly by, hopefully 
without much notice.  At that level, encryption is meaningless.  I'd 
even bet the Equifax data was encrypted internally.


Better for all of us would be to have people stop relying on things like 
my name and SSN for identification, making the Equifax dump relatively 
useless.  Yes, I want a chip embedded under my skin!  I'll even take 
chip number 666 if nobody else wants it :)


Jesse 1 Robinson wrote:
There was a lot of discussion at SHARE this summer about the impact of the new EU regulation that imposes Draconian penalties on a company that fails to report data breaches *very* quickly. (Who was Dracon anyway, and why such a hard *ss?) The EU rule stipulates that if breached data is encrypted, then there is no obligation to report and no penalty. The difference in cost to a large company ought to pay for several z14s.  


.
.
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 Steve Smith
Sent: Wednesday, September 13, 2017 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

The bottom line is this: stolen encrypted data is much harder to use, or it 
takes time and effort to crack it.  But no encryption seals all the attack 
vectors, many of which would bypass encryption.

E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
the data *is* encrypted.  (in my experiments with it, it's actually more 
difficult to get a glimpse at the encrypted data than to see it in the clear).  
So a bad guy who breaches the system in a way that impersonates an authorized 
user won't be bothered by the encryption at all.

Crypto-wizards know exactly how hard it is to crack particular forms of 
encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
machine to do it; or far less likely a mathematical genius finds a better 
algorithm.  Now, if their implementation has some fatal back-door that gets 
exploited, then they'd deserve much more than embarrassment.

sas

On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
 wrote:


Peter Relson wrote:



Isn't the answer really: no, it would not have prevented the breach but it 
would have prevented the breach from having the undesirable effects (e.g., 
exposing sensitive data)?


Actually in my humble opinion, there are TWO answers - Yes and No.

It depends on how the breach took place in the first place.

If breachers are insiders themselves, you're basically out of luck and goodbye 
to your [sensitive and unencrypted] data.

If breachers can install nefarious software on your z/OS users workstation, 
they can mis-use those workstations to steal [and perhaps decrypt] whatever 
they want.

If you are leaving a hole somewhere where (non-SSL) application, FTP and TELNET 
for example, are open to the outside world, then you deserves to be punished.

... etc ...




If breached data is encrypted, I believe that there is not a regulatory 
requirement to report the breach.


I don't know about rules and regulations, but I believe ALL breaches should be 
reported somehow. Of course, red faces will follow despite the encrypted data.

Perhaps if someone can really decrypt it, then big blue has a red face...

Groete / Greetings
Elardus Engelbrecht




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


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


Re: [EXTERNAL] Re: dynamic rexx function package

2017-09-13 Thread Nims,Alva John (Al)
Yep, that is it in generic form, RXSUBCOM is just a specific name someone gave 
it.

Thank you, John.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, September 13, 2017 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: dynamic rexx function package

On Wed, Sep 13, 2017 at 12:58 PM, Nims,Alva John (Al) 
wrote:

> Hint: RXSUBCOM
>
> Caveat: A version is available with DB2 or there is the version 
> available
> from: Open Software Technologies product REXXTOOLS/MVS
>
> "RXSUBCOM: a function for dynamically maintaining host command 
> environments. As with RXFUNC, RXSUBCOM pre-loads the load module 
> associated with a function to enhance performance."  [this is from the 
> REXXTOOLS/MVS Documentation, but I also believe it applies to the DB2 
> version]
>
> Now the BAD (or "My Bad!"):  Sorry, but I do not how to get a copy of 
> RXSUBCOM or source, to you and second, I do not know how to write a 
> package for RXSUBCOM.  Maybe I should have said "Tease" instead of 
> "Hint" above. :-)
>
> Basically what I am trying to say is that, YES, what I think you want 
> is available, but how to get there ?  I HAVE NO CLUE!
>
> Maybe you will have better luck to find something out there about 
> RXSUBCOM and its ability to update the "host command table?"
>
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
>
>
​I'm not certain, but I think this may be what is wanted:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-5F2.1.0_com.ibm.zos.v2r1.ikja300_funcpk.htm=DwIFaQ=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=0Ef64GJS77DVfhr5GGKZeQ=KsgtoUM0N6G87W1v-AQ1dYWc0qn6NepO9apoJkAYVt4=Ls39SI2-wv7FmXqVO59zRqiiZNYj7eQYpQDtxIsoSro=
 

[quote]

You can write your own external functions and subroutines, which allow you to 
extend the capabilities of the REXX language. You can write external functions 
or subroutines that supplement the built-in functions or TSO/E external 
functions that are provided. You can also write a function to replace one of 
the functions that is provided. For example, if you want a new substring 
function that performs differently from the SUBSTR built-in function, you can 
write your own substring function and name it STRING.
Users at your installation can then use the STRING function in their execs.

[/quote]​


--
UNIX was not designed to stop you from doing stupid things, because that would 
also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

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


Re: [EXTERNAL] Re: dynamic rexx function package

2017-09-13 Thread John McKown
On Wed, Sep 13, 2017 at 12:58 PM, Nims,Alva John (Al) 
wrote:

> Hint: RXSUBCOM
>
> Caveat: A version is available with DB2 or there is the version available
> from: Open Software Technologies product REXXTOOLS/MVS
>
> "RXSUBCOM: a function for dynamically maintaining host command
> environments. As with RXFUNC, RXSUBCOM pre-loads the load module associated
> with a function to enhance performance."  [this is from the REXXTOOLS/MVS
> Documentation, but I also believe it applies to the DB2 version]
>
> Now the BAD (or "My Bad!"):  Sorry, but I do not how to get a copy of
> RXSUBCOM or source, to you and second, I do not know how to write a package
> for RXSUBCOM.  Maybe I should have said "Tease" instead of "Hint" above. :-)
>
> Basically what I am trying to say is that, YES, what I think you want is
> available, but how to get there ?  I HAVE NO CLUE!
>
> Maybe you will have better luck to find something out there about RXSUBCOM
> and its ability to update the "host command table?"
>
> Al Nims
> Systems Admin/Programmer 3
> UFIT
> University of Florida
> (352) 273-1298
>
>
​I'm not certain, but I think this may be what is wanted:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/funcpk.htm

[quote]

You can write your own external functions and subroutines, which allow you
to extend the capabilities of the REXX language. You can write external
functions or subroutines that supplement the built-in functions or TSO/E
external functions that are provided. You can also write a function to
replace one of the functions that is provided. For example, if you want a
new substring function that performs differently from the SUBSTR built-in
function, you can write your own substring function and name it STRING.
Users at your installation can then use the STRING function in their execs.

[/quote]​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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


Re: [EXTERNAL] Re: dynamic rexx function package

2017-09-13 Thread Nims,Alva John (Al)
Hint: RXSUBCOM

Caveat: A version is available with DB2 or there is the version available from: 
Open Software Technologies product REXXTOOLS/MVS

"RXSUBCOM: a function for dynamically maintaining host command environments. As 
with RXFUNC, RXSUBCOM pre-loads the load module associated with a function to 
enhance performance."  [this is from the REXXTOOLS/MVS Documentation, but I 
also believe it applies to the DB2 version]

Now the BAD (or "My Bad!"):  Sorry, but I do not how to get a copy of RXSUBCOM 
or source, to you and second, I do not know how to write a package for 
RXSUBCOM.  Maybe I should have said "Tease" instead of "Hint" above. :-)

Basically what I am trying to say is that, YES, what I think you want is 
available, but how to get there ?  I HAVE NO CLUE!

Maybe you will have better luck to find something out there about RXSUBCOM and 
its ability to update the "host command table?"

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, September 13, 2017 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: dynamic rexx function package

My thought was to avoid creating a function package and all that goes with it 
and hoping there was a dynamic way to do it.

Or at least to dynamically load a rexx function module at the start of an exec 
so that it would be referenced in storage rather than being loaded/deleted when 
used, and then to unload it when done.

I may be off base but it seems like a nice thing to do to improve the 
performance when using modules for rexx functions and not having to create a 
function package.

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Wednesday, September 13, 2017 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: dynamic rexx function package

Lionel.

Don;t know what exactly the need, but TSO (Rexx) supplies environment 
initialization & termination exits.

ITschak

On Wed, Sep 13, 2017 at 4:05 PM, Dyck, Lionel B. (TRA) 
wrote:

> Has anyone developed a dynamic rexx function package tool that can be 
> called when a rexx exec starts and then be easily removed when it ends
> - kinda like dynamic steplib?
>
> (cross posted to ibm-main, tso-rexx, and ispf-l)
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM**  (Information Security 
Contiguous Monitoring) **|  *

--
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: Would encryption have prevented known major breaches?

2017-09-13 Thread Mike Schwab
Draco is the formal name of a constellation.
https://en.wikipedia.org/wiki/Draco_(constellation)
The laws Draco instituted included the death penalty for many crime.
And if a fire breathing dragon breaths on you, you are toast.

On Wed, Sep 13, 2017 at 12:43 PM, John McKown
 wrote:
> On Wed, Sep 13, 2017 at 12:39 PM, Mike Schwab 
> wrote:
>
>> https://en.wikipedia.org/wiki/Draconian
>>
>> https://en.wikipedia.org/wiki/Draco_(lawgiver)
>> Draco, law scribe who replaced informal oral laws with harsh written
>> laws and a court system 650-600 BC, Athens, Greece
>>
>>
> Interesting, I was misinformed about Draco (being a dragon per a different
> post in this thread).
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread John McKown
On Wed, Sep 13, 2017 at 12:39 PM, Mike Schwab 
wrote:

> https://en.wikipedia.org/wiki/Draconian
>
> https://en.wikipedia.org/wiki/Draco_(lawgiver)
> Draco, law scribe who replaced informal oral laws with harsh written
> laws and a court system 650-600 BC, Athens, Greece
>
>
​Interesting, I was misinformed about Draco (being a dragon per a different
post in this thread).​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread John McKown
On Wed, Sep 13, 2017 at 12:28 PM, Jesse 1 Robinson 
wrote:

> There was a lot of discussion at SHARE this summer about the impact of the
> new EU regulation that imposes Draconian penalties on a company that fails
> to report data breaches *very* quickly. (Who was Dracon anyway, and why
> such a hard *ss?)


​If the question about "Draconian" is actual, it comes from "draco" or
"dragon". And most dragons are hard *sses.​



> The EU rule stipulates that if breached data is encrypted, then there is
> no obligation to report and no penalty. The difference in cost to a large
> company ought to pay for several z14s.


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


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Jesse 1 Robinson
I learned early on as a programmer trainee the effects of DISP=NEW for GDG(+1). 
My first assignment was to analyze existing data in this GDG. +1 was always 'in 
creation' by an online system. In order to read a previous version, it was not 
sufficient to specify DISP=SHR for an older generation; the exclusive ENQ 
blocked any allocation by GDG base name. I had to specify an older data set by 
fully qualified name. Same restriction for batch and TSO.

.
.
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 Scott Ballentine
Sent: Wednesday, September 13, 2017 6:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: GDG +1 dynamic allocation collision between two 
concurrent jobs

I'll confirm what several others have suggested.  In job 1, Allocation gets the 
ENQ on the GDG base name (MANAGED.TEST.GDG in this case) before allocating the 
generation data set.  Since NEW was specified, the ENQ is obtained exclusive.  
We'll also get the ENQ for the GDS (MANAGED.TEST.GDG.GV00) exclusive, and 
we hold both until you unallocate it.  Job 2 also tries to get the ENQ on the 
GDG base name, and since Job 1 holds it exclusive, you get S99ERROR 0210 (data 
set unavailable.)

Holding both ENQs keeps things somewhat "sane" - if multiple jobs are trying 
create or delete generations at the same time, then generations might not get 
rolled in properly or duplicate data sets can occur or "holes" can be created 
where some generations are missing.

Batch JCL will wait for ENQs, so if these DDs were coded in JCL, job 2 would 
end up waiting for job 1 to unallocate the GDG.  Batch allocation has more 
information to work with when it comes to deadlock prevention than dynamic 
allocation, so dynamic allocation is a little different - you can wait if you 
ask for it (and are an authorized program), but waiting isn't the default.  I'm 
not sure if BPXWDYN supports waiting for data sets, but I suspect it doesn't.

There's a few tricks you can try.  Job 2 can have its own wait and retry logic 
(like others have already suggested.)  Allocating the GDS using the ...GV00 
name does not get the ENQ for the base name, so you could do something like 
allocate the (+1), get the ...GV00 name, unallocate it, and then reallocate 
with the GV00 name and write your data.  That doesn't eliminate the window 
where the base name is held, but it could significantly shrink it.  (There is a 
chance that somebody could play with your data set in the window where it is 
unallocated, so this might not be a viable option - that's for you to decide 
based on what your application is doing.)

-Scott Ballentine (sbal...@us.ibm.com)
 z/OS Device Allocation Development


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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread Mike Schwab
https://en.wikipedia.org/wiki/Draconian

https://en.wikipedia.org/wiki/Draco_(lawgiver)
Draco, law scribe who replaced informal oral laws with harsh written
laws and a court system 650-600 BC, Athens, Greece

On Wed, Sep 13, 2017 at 12:28 PM, Jesse 1 Robinson
 wrote:
> There was a lot of discussion at SHARE this summer about the impact of the 
> new EU regulation that imposes Draconian penalties on a company that fails to 
> report data breaches *very* quickly. (Who was Dracon anyway, and why such a 
> hard *ss?) The EU rule stipulates that if breached data is encrypted, then 
> there is no obligation to report and no penalty. The difference in cost to a 
> large company ought to pay for several z14s.
>
> .
> .
> 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 Steve Smith
> Sent: Wednesday, September 13, 2017 6:15 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Would encryption have prevented known major breaches?
>
> The bottom line is this: stolen encrypted data is much harder to use, or it 
> takes time and effort to crack it.  But no encryption seals all the attack 
> vectors, many of which would bypass encryption.
>
> E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
> the data *is* encrypted.  (in my experiments with it, it's actually more 
> difficult to get a glimpse at the encrypted data than to see it in the 
> clear).  So a bad guy who breaches the system in a way that impersonates an 
> authorized user won't be bothered by the encryption at all.
>
> Crypto-wizards know exactly how hard it is to crack particular forms of 
> encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
> machine to do it; or far less likely a mathematical genius finds a better 
> algorithm.  Now, if their implementation has some fatal back-door that gets 
> exploited, then they'd deserve much more than embarrassment.
>
> sas
>
> On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
>  wrote:
>> Peter Relson wrote:
>>
>>>Isn't the answer really: no, it would not have prevented the breach but it 
>>>would have prevented the breach from having the undesirable effects (e.g., 
>>>exposing sensitive data)?
>>
>> Actually in my humble opinion, there are TWO answers - Yes and No.
>>
>> It depends on how the breach took place in the first place.
>>
>> If breachers are insiders themselves, you're basically out of luck and 
>> goodbye to your [sensitive and unencrypted] data.
>>
>> If breachers can install nefarious software on your z/OS users workstation, 
>> they can mis-use those workstations to steal [and perhaps decrypt] whatever 
>> they want.
>>
>> If you are leaving a hole somewhere where (non-SSL) application, FTP and 
>> TELNET for example, are open to the outside world, then you deserves to be 
>> punished.
>>
>> ... etc ...
>>
>>
>>>If breached data is encrypted, I believe that there is not a regulatory 
>>>requirement to report the breach.
>>
>> I don't know about rules and regulations, but I believe ALL breaches should 
>> be reported somehow. Of course, red faces will follow despite the encrypted 
>> data.
>>
>> Perhaps if someone can really decrypt it, then big blue has a red face...
>>
>> 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



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

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Allan Staller
How do you propose to handle reference by relative generation if multiple 
entities can change relativity?



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Wednesday, September 13, 2017 12:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDG +1 dynamic allocation collision between two concurrent jobs

On Wed, Sep 13, 2017 at 8:45 AM, Scott Ballentine 
wrote:

> Holding both ENQs keeps things somewhat "sane" - if multiple jobs are 
> trying create or delete generations at the same time, then generations 
> might not get rolled in properly or duplicate data sets can occur or 
> "holes" can be created where some generations are missing.
>
>
I appreciate your response.  I don't question that this is how it works, but I 
don't really agree that this is the only sane implementation.

- "generations might not get rolled in properly"
 this can happen in other ways, right?

-  "duplicate data sets can occur"
 With SMS?  In this case the goovoo data set is cataloged at allocation 
time and also ENQed

- "holes can be created where some generations are missing"
 this can also happen in other ways.

"Extended GDG" support added new options, but IMO it is a pity that concurrency 
was not considered as an option when creating new generations.
  All of the suggested "tricks" to support this use case might lead one to 
consider using something besides a GDG.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
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: Would encryption have prevented known major breaches?

2017-09-13 Thread Jesse 1 Robinson
There was a lot of discussion at SHARE this summer about the impact of the new 
EU regulation that imposes Draconian penalties on a company that fails to 
report data breaches *very* quickly. (Who was Dracon anyway, and why such a 
hard *ss?) The EU rule stipulates that if breached data is encrypted, then 
there is no obligation to report and no penalty. The difference in cost to a 
large company ought to pay for several z14s.  

.
.
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 Steve Smith
Sent: Wednesday, September 13, 2017 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

The bottom line is this: stolen encrypted data is much harder to use, or it 
takes time and effort to crack it.  But no encryption seals all the attack 
vectors, many of which would bypass encryption.

E.G.  z/OS Data Set Encryption is so transparent, many users won't even know 
the data *is* encrypted.  (in my experiments with it, it's actually more 
difficult to get a glimpse at the encrypted data than to see it in the clear).  
So a bad guy who breaches the system in a way that impersonates an authorized 
user won't be bothered by the encryption at all.

Crypto-wizards know exactly how hard it is to crack particular forms of 
encryption.  It's nothing to IBM's shame if someone builds a powerful enough 
machine to do it; or far less likely a mathematical genius finds a better 
algorithm.  Now, if their implementation has some fatal back-door that gets 
exploited, then they'd deserve much more than embarrassment.

sas

On Wed, Sep 13, 2017 at 8:54 AM, Elardus Engelbrecht 
 wrote:
> Peter Relson wrote:
>
>>Isn't the answer really: no, it would not have prevented the breach but it 
>>would have prevented the breach from having the undesirable effects (e.g., 
>>exposing sensitive data)?
>
> Actually in my humble opinion, there are TWO answers - Yes and No.
>
> It depends on how the breach took place in the first place.
>
> If breachers are insiders themselves, you're basically out of luck and 
> goodbye to your [sensitive and unencrypted] data.
>
> If breachers can install nefarious software on your z/OS users workstation, 
> they can mis-use those workstations to steal [and perhaps decrypt] whatever 
> they want.
>
> If you are leaving a hole somewhere where (non-SSL) application, FTP and 
> TELNET for example, are open to the outside world, then you deserves to be 
> punished.
>
> ... etc ...
>
>
>>If breached data is encrypted, I believe that there is not a regulatory 
>>requirement to report the breach.
>
> I don't know about rules and regulations, but I believe ALL breaches should 
> be reported somehow. Of course, red faces will follow despite the encrypted 
> data.
>
> Perhaps if someone can really decrypt it, then big blue has a red face...
>
> 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: CSST question

2017-09-13 Thread Charles Mills
@Peter, thank you.

Assume that code in question were to issue a CSST that successfully swapped
POINTER and stored a value at ADDRESS.

Question: is there any way for the 'examining' code, possibly running on a
different CPU, to be assured of seeing a consistent (either 'before' or
'after') POINTER and ADDRESS contents? Possibly with serialization at some
point?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, September 13, 2017 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSST question

I thought Greg Dyck's post perfectly answered the what's and why's,
including the sole reason for which the instruction was created.

Disablement for external and I/O interrupts prevents the work unit from
being undispatched in between the serialized operation and the store that
sets the footprint.
CSST accomplishes that by combining the two into one instruction. Not having
to disable is of course simpler and also makes this function available to
problem state programs (since they cannot disable).

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Kirk Wolf
On Wed, Sep 13, 2017 at 8:45 AM, Scott Ballentine 
wrote:

> Holding both ENQs keeps things somewhat "sane" - if multiple jobs are
> trying create or delete generations at the same time, then generations
> might not get rolled in properly or duplicate data sets can occur or
> "holes" can be created where some generations are missing.
>
>
I appreciate your response.  I don't question that this is how it works,
but I don't really agree that this is the only sane implementation.

- "generations might not get rolled in properly"
 this can happen in other ways, right?

-  "duplicate data sets can occur"
 With SMS?  In this case the goovoo data set is cataloged at allocation
time and also ENQed

- "holes can be created where some generations are missing"
 this can also happen in other ways.

"Extended GDG" support added new options, but IMO it is a pity that
concurrency was not considered as an option when creating new generations.
  All of the suggested "tricks" to support this use case might lead one to
consider using something besides a GDG.


Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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


AW: Re: Reload nucleus module dynamically

2017-09-13 Thread Peter Hunkeler
>What modules do you want to reload? If that is in LPA and/or Linklist, you 
>better be careful before issuing commands to refresh them. Of course YMMV.


Well, the nucleus is the nucleus, LPA is the LPA, and the linklist is the 
linklist. They are different beasts. The first two are different areas in the 
virtual address space map, the third is noting but a list of data set to be 
searched for load modules. The OP asked about dynamically updating the nucleus, 
and this is nothing that MVS supports up to date.


--
Peter Hunkeler





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


Re: [EXTERNAL] Re: dynamic rexx function package

2017-09-13 Thread Dyck, Lionel B. (TRA)
My thought was to avoid creating a function package and all that goes with it 
and hoping there was a dynamic way to do it.

Or at least to dynamically load a rexx function module at the start of an exec 
so that it would be referenced in storage rather than being loaded/deleted when 
used, and then to unload it when done.

I may be off base but it seems like a nice thing to do to improve the 
performance when using modules for rexx functions and not having to create a 
function package.

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Wednesday, September 13, 2017 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: dynamic rexx function package

Lionel.

Don;t know what exactly the need, but TSO (Rexx) supplies environment 
initialization & termination exits.

ITschak

On Wed, Sep 13, 2017 at 4:05 PM, Dyck, Lionel B. (TRA) 
wrote:

> Has anyone developed a dynamic rexx function package tool that can be 
> called when a rexx exec starts and then be easily removed when it ends 
> - kinda like dynamic steplib?
>
> (cross posted to ibm-main, tso-rexx, and ispf-l)
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM**  (Information Security 
Contiguous Monitoring) **|  *

--
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: dynamic rexx function package

2017-09-13 Thread ITschak Mugzach
Lionel.

Don;t know what exactly the need, but TSO (Rexx) supplies environment
initialization & termination exits.

ITschak

On Wed, Sep 13, 2017 at 4:05 PM, Dyck, Lionel B. (TRA) 
wrote:

> Has anyone developed a dynamic rexx function package tool that can be
> called when a rexx exec starts and then be easily removed when it ends -
> kinda like dynamic steplib?
>
> (cross posted to ibm-main, tso-rexx, and ispf-l)
> --
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM**  (Information Security
Contiguous Monitoring) **|  *

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


Re: RPL macro

2017-09-13 Thread Don Poitras
RPL usage is how programs, well, _use_ VTAM. So certainly they increase
buffer usage. It's a meaningless question though as without RPL
usage, VTAM wouldn't _do_ anything.

It's like asking, "Does DCB usage increase the buffer usage of QSAM".
Sure it does. Why wouldn't it?

In article  
you wrote:
> Hi

> Does RPL usage increases the buffer usage of VTAM ?

> On 13-Sep-2017 5:09 PM, "Don Poitras"  wrote:

> > In article  > gmail.com> you wrote:
> > > Hi
> > > Just trying to understand the functions OF RPL macro.
> > > Is it just primarily used FOR VSAM or it can be used by any other product
> > > for copying ?
> > > Peter
> >
> > It's analogous to how the DCB is used for sequential datasets. Used
> > by VSAM and VTAM. RPL is for the get and put part, the ACB describes
> > VSAM dataset or the VTAM application program. Not just copying, but
> > all I/O.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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


Re: IBM-MAIN Digest - 11 Sep 2017 to 12 Sep 2017 (#2017-255)

2017-09-13 Thread Tony Harminc
On 13 September 2017 at 00:59, Timothy Sipples  wrote:

> That said, Linux dm-crypt/LUKS and eCryptfs enjoy wonderfully, uniquely
> high performance on the IBM z14 and LinuxONE Emperor II machines, and with
> Crypto Express strong key protections and IBM Secure Service Container
> support, too. It's lovely.

I'm sure it's lovely. But "wonderfully, uniquely high performance"? As
compared to what? An earlier generation of IBM z machines, perhaps?
But surely not to an Intel server like the IBM (sorry - Lenovo) x3650
with a Xeon E5-2600 v2 processor from 2014 or so? The one Lynn Wheeler
likes to talk about on this list.

Tony H.

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


Re: SoftwareXcel Discontinued

2017-09-13 Thread Ed Jaffe

On 9/12/2017 10:21 PM, Timothy Sipples wrote:


Anyway, you started this thread because you were concerned about not being
able to obtain support services you want, affordably. I and others have
painstakingly pointed out that you actually have access to the support
services you want, after clarifying in a follow-up post: electronically
opening PMRs (for suspected defects), obtaining PTFs and release updates,
and searching for APARs. As far as I can tell, everything you asked for,
you get with your MLC and S We've provided the Web links already, and
multiple people confirm they work. Isn't this good news? Haven't we
addressed all your concerns now? "May we close this PMR as RESOLVED?" :-)


If you had actually read my updates, you would already know that our IBM 
support contract expires January 27, 2018 and that last week I gave the 
order that it not be renewed.


I intend to report to SHARE (and to the community at large) via the Bit 
Bucket, my experiences thereafter with attempting to obtain 
usable/convenient program support for z/OS, z/VM and z/VSE. I'll likely 
provide only a brief "Heads Up. Here's what we're doing..." in 
Sacramento and then follow up five months later in Salt Lake City with 
all of the gory details...


Feel free to watch the post-conference video(s) on YouTube if you're 
interested.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Giliad Wilf
Maybe the code to be replaced is just a vendor's type 1, 2, or 6 SVC routine in 
the range 255 to 200.

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


Re: dynamic rexx function package

2017-09-13 Thread Steve Beaver
I have seen some REXX EXEC packages and they are relatively easy to write in
HLASM

The downside is that they would have to be put on the LNKLST or reallocated
on the ISPLLIB, and like everything
Else in zOS, you would have to the IKJ member in Parmlib for it to function
properly  

Steve   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Dyck, Lionel B. (TRA)
Sent: Wednesday, September 13, 2017 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: dynamic rexx function package

Has anyone developed a dynamic rexx function package tool that can be called
when a rexx exec starts and then be easily removed when it ends - kinda like
dynamic steplib?

(cross posted to ibm-main, tso-rexx, and ispf-l)
--
Lionel B. Dyck
Mainframe Systems Programmer - TRA


--
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: CSST question

2017-09-13 Thread Peter Relson
I thought Greg Dyck's post perfectly answered the what's and why's, 
including the sole reason for which the instruction was created.

Disablement for external and I/O interrupts prevents the work unit from 
being undispatched in between the serialized operation and the store that 
sets the footprint.
CSST accomplishes that by combining the two into one instruction. Not 
having to disable is of course simpler and also makes this function 
available to problem state programs (since they cannot disable).

One might ask "if you were disabled for external and I/O interrupts, could 
LPAR undispatch you from the processor in between the serialized operation 
and the store?". The answer must be "yes", but this would not be visible 
to the work unit.  As far as z/OS was concerned, the work unit would still 
be dispatched.

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: CSST question

2017-09-13 Thread Charles Mills
Ah. Got it. Thanks.



CharlesSent from a mobile; please excuse the brevity.
 Original message From: Walt Farrell  
Date: 9/13/17  3:59 PM  (GMT+01:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 
CSST question 
On Wed, 13 Sep 2017 11:02:25 +0200, Charles Mills  wrote:

>> Note that it says the store into the first operand will appear to occur 
>> before the store into 
>> the second operand, but it does NOT say that an observing CPU will see both 
>> stores or neither.
>
>Again, not arguing, just trying to fully understand. In your answer above, did 
>you consider this sentence from the PoOp description?
>
>"A serialization function is performed before the operation begins and again 
>after the operation is completed."

Yes, I did. But as Binyamin says, you need to understand what CPU serialization 
entails.

Again, I'm not an expert, but this is my interpretation: When you do something 
that serializes, the CPU ensures that all fetches and stores that have 
conceptually _completed_ by other CPUs are actually complete before you 
proceed. But CSST has two block-concurrent operations with a tiny window 
between the first store and the second store. Therefore, if a CSST occurs on a 
different CPU in theory your serialization coulde occur between the first and 
second store operations, and your serialization could complete and allow you to 
see the result of the first but not the second operation.

-- 
Walt

--
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: AW: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Paul Gilmartin
On Wed, 13 Sep 2017 07:18:13 +0200, Peter Hunkeler wrote:
>
>>Is there a way around this?
> >
>>Even with SMS-managed GDGs, where the generation is cataloged at
>>allocation, two jobs that dynamically allocate +1 generations (with GDGNT)
>>will collide.
>
>Not according to the FM "DFSMS Using Data Sets", which says under "Submitting 
>Multiple Jobs to Update a Generation Data Group": Submitting Multiple Jobs to 
>Update a Generation Data Group
>This topic provides guidelines that you can use when you submit multiple jobs 
>that update a particular GDG:
>- No two jobs running concurrently can refer to the same GDG.
>
In this thread, (too) much of the discussion has focused on batch JCL, whereas
the original question concerned dynamic allocation (see "Subject:" line).  If a
program allocates a GDG only dynamically, not mentioning it in JCL:

o When are the various ENQs dequed?

o Does relative generation 0 refer to the same absolute DSN in every exec
  in every step even though intervening steps may have dynamically added
  generations?

o What control block holds the anchor(s) needed to do this?

o Is any execution environment created by fork() counted as a separate job?

o How may a program which allocates generation +1 dynamically discover
  the absolute DSN?

>- For batch or dynamic allocation jobs that specify relative generation 
>numbers, the system enqueues the GDG base name as shared or exclusive, 
>depending on the highest disposition that is used in the job. The GDG base 
>name is exclusive if the highest job disposition is NEW or MOD. The GDG base 
>name is shared if the highest job disposition is SHR. This safeguard prevents 
>concurrent users from updating the GDG by adding or deleting generation data 
>sets while other users are using the GDG.
>- For batch or dynamic allocation jobs that use absolute generation data 
>setnames, the system does not enqueue the GDG base. Multiple users are able to 
>update the GDG by deleting or adding generation data sets at the same time. 
>This situation does not affect the integrity of the GDG or generation data 
>sets. However, jobs that use relative generation numbers might obtain the 
>wrong generation, because the numbers can change. Even if you use absolute 
>generation numbers, a job might accidentally replace a generation data set 
>that another job is using.
>The only time that you can use absolute generation numbers is when you need to 
>run concurrent jobs that use the same GDG and at least one of the jobs uses a 
>disposition of NEW or MOD. Ensure that the jobs do not accidentally overlay a 
>generation data set that another job is using.
>Restriction: Be careful when you update GDGs because two or more jobs can 
>compete for the same resource and accidentally replace the generation data set 
>with the wrong version in the GDG. To prevent two users from allocating the 
>same absolute generation data set, take one of the following actions:
>o Specify DISP=OLD.
>o Specify DISP=SHR and open the data set for output.
>
Does opening for output cause an EXC ENQ even when allocated DISP=SHR?

-- gil

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


Re: RPL macro

2017-09-13 Thread Peter
Hi

Does RPL usage increases the buffer usage of VTAM ?

On 13-Sep-2017 5:09 PM, "Don Poitras"  wrote:

> In article  gmail.com> you wrote:
> > Hi
> > Just trying to understand the functions OF RPL macro.
> > Is it just primarily used FOR VSAM or it can be used by any other product
> > for copying ?
> > Peter
>
> It's analogous to how the DCB is used for sequential datasets. Used
> by VSAM and VTAM. RPL is for the get and put part, the ACB describes
> VSAM dataset or the VTAM application program. Not just copying, but
> all I/O.
>
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
>
> --
> 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: CSST question

2017-09-13 Thread Walt Farrell
On Wed, 13 Sep 2017 11:02:25 +0200, Charles Mills  wrote:

>> Note that it says the store into the first operand will appear to occur 
>> before the store into 
>> the second operand, but it does NOT say that an observing CPU will see both 
>> stores or neither.
>
>Again, not arguing, just trying to fully understand. In your answer above, did 
>you consider this sentence from the PoOp description?
>
>"A serialization function is performed before the operation begins and again 
>after the operation is completed."

Yes, I did. But as Binyamin says, you need to understand what CPU serialization 
entails.

Again, I'm not an expert, but this is my interpretation: When you do something 
that serializes, the CPU ensures that all fetches and stores that have 
conceptually _completed_ by other CPUs are actually complete before you 
proceed. But CSST has two block-concurrent operations with a tiny window 
between the first store and the second store. Therefore, if a CSST occurs on a 
different CPU in theory your serialization coulde occur between the first and 
second store operations, and your serialization could complete and allow you to 
see the result of the first but not the second operation.

-- 
Walt

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Scott Ballentine
I'll confirm what several others have suggested.  In job 1, Allocation gets the 
ENQ on the GDG base name (MANAGED.TEST.GDG in this case) before allocating the 
generation data set.  Since NEW was specified, the ENQ is obtained exclusive.  
We'll also get the ENQ for the GDS (MANAGED.TEST.GDG.GV00) exclusive, and 
we hold both until you unallocate it.  Job 2 also tries to get the ENQ on the 
GDG base name, and since Job 1 holds it exclusive, you get S99ERROR 0210 (data 
set unavailable.)

Holding both ENQs keeps things somewhat "sane" - if multiple jobs are trying 
create or delete generations at the same time, then generations might not get 
rolled in properly or duplicate data sets can occur or "holes" can be created 
where some generations are missing.

Batch JCL will wait for ENQs, so if these DDs were coded in JCL, job 2 would 
end up waiting for job 1 to unallocate the GDG.  Batch allocation has more 
information to work with when it comes to deadlock prevention than dynamic 
allocation, so dynamic allocation is a little different - you can wait if you 
ask for it (and are an authorized program), but waiting isn't the default.  I'm 
not sure if BPXWDYN supports waiting for data sets, but I suspect it doesn't.

There's a few tricks you can try.  Job 2 can have its own wait and retry logic 
(like others have already suggested.)  Allocating the GDS using the ...GV00 
name does not get the ENQ for the base name, so you could do something like 
allocate the (+1), get the ...GV00 name, unallocate it, and then reallocate 
with the GV00 name and write your data.  That doesn't eliminate the window 
where the base name is held, but it could significantly shrink it.  (There is a 
chance that somebody could play with your data set in the window where it is 
unallocated, so this might not be a viable option - that's for you to decide 
based on what your application is doing.)

-Scott Ballentine (sbal...@us.ibm.com)
 z/OS Device Allocation Development

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


Re: AW: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Paul Gilmartin
On Wed, 13 Sep 2017 07:29:43 +0200, Peter Hunkeler wrote:

>I think the main problem here is dynamic allocation (SVC99) is not allowing 
>the unauthorized caller to specify it should enqueue uncondtionally. For that 
>reason BPXWDYN, TSO ALLOCATE, etc return  with "data set in use" instead of 
>offering the option to wait until it becomes available.
> 
That's allowed if the request specifies S99WTDSN.  That, in turn, requires
APF authorization, assuming an authorized program can be trusted to
circumvent deadlocks.

-- gil

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Tom Marchant
On Wed, 13 Sep 2017 16:16:03 +0530, Peter wrote:

>Is there a way to dynamically update a nucleus ?

"A Nucleus"? Do you mean the MVS Nucleus? If so, I wouldn't try it.

>I have applied a PTF for a product (ISV)  and it has updated nucleus.

You have an ISV product that requires an update to the MVS Nucleus?
I wonder why.

-- 
Tom Marchant

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Lizette Koehler
All good answers so far 

  1  Nucleus is loaded at NIP or very early in the IPL Process.  Unless 
otherwise directed by the ISV, it will require an IPL to update
  2  The MCS entry for your ptf (if SMP/E installed) will document how to 
install the fix
  3  As others have stated, contact the ISV for assistance on how to install 
the fix in Nucleus


Lizette 



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Wednesday, September 13, 2017 3:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Reload nucleus module dynamically
> 
> Hello
> 
> Apology for the dummy question.
> 
> Is there a way to dynamically update a nucleus ?
> 
> I have applied a PTF for a product (ISV)  and it has updated nucleus.
> 
> Is it possible to reload dynamically ?
> 
> Peter
> 

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Allan Staller
I wonder how this plays with the new (z/OS 2.2?) enqueue demotion?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Wednesday, September 13, 2017 12:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: GDG +1 dynamic allocation collision between two concurrent jobs

Sorry, sending out too early. I repost with the full list of guidelines



>Is there a way around this?  
 > 
>Even with SMS-managed GDGs, where the generation is cataloged at 
>allocation, two jobs that dynamically allocate +1 generations (with 
>GDGNT) will collide.
 
 
 
 
Not according to the FM "DFSMS Using Data Sets", which says under "Submitting 
Multiple Jobs to Update a Generation Data Group": Submitting Multiple Jobs to 
Update a Generation Data Group This topic provides guidelines that you can use 
when you submit multiple jobs that update a particular GDG:
- No two jobs running concurrently can refer to the same GDG.
- For batch or dynamic allocation jobs that specify relative generation 
numbers, the system enqueues the GDG base name as shared or exclusive, 
depending on the highest disposition that is used in the job. The GDG base name 
is exclusive if the highest job disposition is NEW or MOD. The GDG base name is 
shared if the highest job disposition is SHR. This safeguard prevents 
concurrent users from updating the GDG by adding or deleting generation data 
sets while other users are using the GDG.
- For batch or dynamic allocation jobs that use absolute generation data 
setnames, the system does not enqueue the GDG base. Multiple users are able to 
update the GDG by deleting or adding generation data sets at the same time. 
This situation does not affect the integrity of the GDG or generation data 
sets. However, jobs that use relative generation numbers might obtain the wrong 
generation, because the numbers can change. Even if you use absolute generation 
numbers, a job might accidentally replace a generation data set that another 
job is using.
The only time that you can use absolute generation numbers is when you need to 
run concurrent jobs that use the same GDG and at least one of the jobs uses a 
disposition of NEW or MOD. Ensure that the jobs do not accidentally overlay a 
generation data set that another job is using.
Restriction: Be careful when you update GDGs because two or more jobs can 
compete for the same resource and accidentally replace the generation data set 
with the wrong version in the GDG. To prevent two users from allocating the 
same absolute generation data set, take one of the following actions:
o Specify DISP=OLD.
o Specify DISP=SHR and open the data set for output.


--
Peter Hunkeler



--
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: Would encryption have prevented known major breaches?

2017-09-13 Thread Elardus Engelbrecht
Peter Relson wrote:

>Isn't the answer really: no, it would not have prevented the breach but it 
>would have prevented the breach from having the undesirable effects (e.g., 
>exposing sensitive data)?

Actually in my humble opinion, there are TWO answers - Yes and No.

It depends on how the breach took place in the first place. 

If breachers are insiders themselves, you're basically out of luck and goodbye 
to your [sensitive and unencrypted] data.

If breachers can install nefarious software on your z/OS users workstation, 
they can mis-use those workstations to steal [and perhaps decrypt] whatever 
they want.

If you are leaving a hole somewhere where (non-SSL) application, FTP and TELNET 
for example, are open to the outside world, then you deserves to be punished.

... etc ...


>If breached data is encrypted, I believe that there is not a regulatory 
>requirement to report the breach.

I don't know about rules and regulations, but I believe ALL breaches should be 
reported somehow. Of course, red faces will follow despite the encrypted data.

Perhaps if someone can really decrypt it, then big blue has a red face...

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: Reload nucleus module dynamically

2017-09-13 Thread Elardus Engelbrecht
Peter wrote:

>Is there a way to dynamically update a nucleus ?
>I have applied a PTF for a product (ISV)  and it has updated nucleus.
>Is it possible to reload dynamically ?

You better listen to Binyamin Dissen who kinldy replied to you.

What modules do you want to reload? If that is in LPA and/or Linklist, you 
better be careful before issuing commands to refresh them. Of course YMMV.

If these modules are SVC modules, I would recommend you to rather IPL.

But ask your ISV, they wrote the product and they certainly can assist you way 
better than IBM-MAIN.

If still unsure, put all your updated libraries on another set of volsers and 
IPL.

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: Downloading publications from IBM

2017-09-13 Thread Randy Hoekstra
https://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US=SRX=GI18-0278-00

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


Re: Reload nucleus module dynamically

2017-09-13 Thread Binyamin Dissen
On Wed, 13 Sep 2017 16:16:03 +0530 Peter  wrote:

:>Apology for the dummy question.

Not at all dummy.

:>Is there a way to dynamically update a nucleus ?

Yes, by updating memory.

:>I have applied a PTF for a product (ISV)  and it has updated nucleus.

:>Is it possible to reload dynamically ?

Ask the ISV. Best not to risk this yourself.

--
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: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Giliad Wilf
The behaviour I recall seeing in batch environment is that when a new 
GDG dataset is being created, GDG base is being ENQ'ed exclusively.
 
For any other job attempting creation of another dataset per the same
GDG base - this base must be *IMMEDIATELY* available, or the second 
request will be failed on some JCL error, not being waited upon for base
availability.
 
I think I've seen something like "DATA SET RESERVATION UNSUCCESSFUL",
or alike.

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


Re: RPL macro

2017-09-13 Thread Don Poitras
In article  
you wrote:
> Hi
> Just trying to understand the functions OF RPL macro.
> Is it just primarily used FOR VSAM or it can be used by any other product
> for copying ?
> Peter

It's analogous to how the DCB is used for sequential datasets. Used
by VSAM and VTAM. RPL is for the get and put part, the ACB describes
VSAM dataset or the VTAM application program. Not just copying, but
all I/O.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Tom Marchant
On Tue, 12 Sep 2017 16:06:47 -0500, Paul Gilmartin wrote:

>>In a subsequent job, assuming no other GDS created for that GDG, 
>>these same data sets would be -2 and -1.
>>
>Then I'd have expected -1 and 0.  But I'm often wrong.  Fencepost errors and 
>all.

Yes, you are correct.

-- 
Tom Marchant

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


Re: Would encryption have prevented known major breaches?

2017-09-13 Thread Peter Relson
Isn't the answer really: no, it would not have prevented the breach but it 
would have prevented the breach from having the undesirable effects (e.g., 
exposing sensitive data)?
If breached data is encrypted, I believe that there is not a regulatory 
requirement to report the breach.

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


Reload nucleus module dynamically

2017-09-13 Thread Peter
Hello

Apology for the dummy question.

Is there a way to dynamically update a nucleus ?

I have applied a PTF for a product (ISV)  and it has updated nucleus.

Is it possible to reload dynamically ?

Peter

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


Re: CSST question

2017-09-13 Thread Binyamin Dissen
On Wed, 13 Sep 2017 11:02:25 +0200 Charles Mills  wrote:

:>> Note that it says the store into the first operand will appear to occur 
before the store into 
:>> the second operand, but it does NOT say that an observing CPU will see both 
stores or neither.

:>Again, not arguing, just trying to fully understand. In your answer above, 
did you consider this sentence from the PoOp description?

:>"A serialization function is performed before the operation begins and again 
after the operation is completed."

I suggest that you read the "CPU Serialization" in the POPs.  It doesn't work
the way that you think.

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Walt Farrell
:>Sent: Tuesday, September 12, 2017 5:08 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: CSST question
:>
:>On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills  wrote:
:>
:>>Disabling for interruptions is not sufficient in a multi-processor world, 
right?
:>>
:>>I don't pretend to be the world's biggest machine instruction expert. 
:>>Am I reading the PoOp correctly that a task wishing another task's CSST 
:>>to effectively appear to be entirely atomic (from its CPU's point of view) 
could achieve that effect by issuing a serialization instruction (BCR 15,0)?
:>
:>I won't pretend to be an expert, either, but I do not think a serialization 
operation will make CSST appear fully atomic to other CPUs. Serialization 
ensures that all operand fetches by other CPUs, and all operand stores by other 
CPUs, that occurred conceptually before the serializing instruction, will 
complete before the serializing instruction resumes.
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: IEFSCHAS - Using more CPU

2017-09-13 Thread Martin Packer
Sometimes I see SMF 30 for Master Scheduler AS showing very large amounts 
of memory.

SMF 30 is extremely unreliable for memory anyway, so I'm not sure what to 
make of that.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

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



From:   Rob Scott 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   13/09/2017 10:55
Subject:Re: IEFSCHAS - Using more CPU
Sent by:IBM Mainframe Discussion List 



Peter



IEFSCHAS is the "scheduler address space".



One of its functions is to handle cross-system ENF notifications.



If the increased CPU consumption is down to an increase in cross-system 
ENF signals, then by far the most likely cause is an increase in GRS 
contention (as the other x-system ENF event codes are unlikely to be able 
to be generated *that* frequently).



Rob Scott



-Original Message-

From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Peter Hunkeler

Sent: Wednesday, September 13, 2017 8:05 AM

To: IBM-MAIN@LISTSERV.UA.EDU

Subject: IEFSCHAS - Using more CPU



Not that I would think there is a problem, but in a problem situation, I 
saw IEFSCHAS using more CPU than normal. I never cared to understand what 
exactly IEFSCHAS does. Can anyone tell me?







--

Peter Hunkeler



--

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



Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 
02451 ■ Main Office Toll Free Number: +1 877.328.2932

Contact Customer Support: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__my.rocketsoftware.com_RocketCommunity_RCEmailSupport=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=tDABgwv6w4Ui8Rv71SyOJmAbAMhIiORmsWI3oYuW6Wg=GRbzvDnbCqE2hkme778zN87MBG2gXHg8-5ejmN49PRk=
 


Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rocketsoftware.com_manage-2Dyour-2Demail-2Dpreferences=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=tDABgwv6w4Ui8Rv71SyOJmAbAMhIiORmsWI3oYuW6Wg=u9WMl72cHrqwiRXFurA4HCMK0SKMly-Yip9ZuEHfUyo=
 


Privacy Policy - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rocketsoftware.com_company_legal_privacy-2Dpolicy=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=tDABgwv6w4Ui8Rv71SyOJmAbAMhIiORmsWI3oYuW6Wg=lID0XpPjHxcAJFGHA3CYFkr5qTY9-adPiKBzLdjhOP8=
 






This communication and any attachments may contain confidential 
information of Rocket Software, Inc. All unauthorized use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
notify Rocket Software immediately and destroy all copies of this 
communication. Thank you.



--

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

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





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


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


Re: IEFSCHAS - Using more CPU

2017-09-13 Thread Rob Scott
Peter

IEFSCHAS is the "scheduler address space".

One of its functions is to handle cross-system ENF notifications.

If the increased CPU consumption is down to an increase in cross-system ENF 
signals, then by far the most likely cause is an increase in GRS contention (as 
the other x-system ENF event codes are unlikely to be able to be generated 
*that* frequently).

Rob Scott

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Wednesday, September 13, 2017 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEFSCHAS - Using more CPU

Not that I would think there is a problem, but in a problem situation, I saw 
IEFSCHAS using more CPU than normal. I never cared to understand what exactly 
IEFSCHAS does. Can anyone tell me?



--
Peter Hunkeler

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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


Re: CSST question

2017-09-13 Thread Charles Mills
> Note that it says the store into the first operand will appear to occur 
> before the store into 
> the second operand, but it does NOT say that an observing CPU will see both 
> stores or neither.

Again, not arguing, just trying to fully understand. In your answer above, did 
you consider this sentence from the PoOp description?

"A serialization function is performed before the operation begins and again 
after the operation is completed."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Tuesday, September 12, 2017 5:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSST question

On Tue, 12 Sep 2017 16:36:44 +0200, Charles Mills  wrote:

>Disabling for interruptions is not sufficient in a multi-processor world, 
>right?
>
>I don't pretend to be the world's biggest machine instruction expert. 
>Am I reading the PoOp correctly that a task wishing another task's CSST 
>to effectively appear to be entirely atomic (from its CPU's point of view) 
>could achieve that effect by issuing a serialization instruction (BCR 15,0)?

I won't pretend to be an expert, either, but I do not think a serialization 
operation will make CSST appear fully atomic to other CPUs. Serialization 
ensures that all operand fetches by other CPUs, and all operand stores by other 
CPUs, that occurred conceptually before the serializing instruction, will 
complete before the serializing instruction resumes.

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


Re: RPL macro

2017-09-13 Thread Binyamin Dissen
On Wed, 13 Sep 2017 13:50:07 +0530 Peter  wrote:

:>Just trying to understand the functions OF RPL macro.

You mean GENCB BLK=RPL?

:>Is it just primarily used FOR VSAM or it can be used by any other product
:>for copying ?

How would you want to use it?

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


RPL macro

2017-09-13 Thread Peter
Hi

Just trying to understand the functions OF RPL macro.

Is it just primarily used FOR VSAM or it can be used by any other product
for copying ?

Peter

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


Re: GDG +1 dynamic allocation collision between two concurrent jobs

2017-09-13 Thread Mike Schwab
If you work with Relative GDG numbers, the whole GDG is enqued until
the job ends.  Bypass by using a specific GV00 in your JCL.  Or a
different GDG base name.

On Tue, Sep 12, 2017 at 11:54 AM, Kirk Wolf  wrote:
> Is there a way around this?
>
> Even with SMS-managed GDGs, where the generation is cataloged at
> allocation, two jobs that dynamically allocate +1 generations (with GDGNT)
> will collide.
>
> For example, from two different jobs:
>
> (job 1)
> ./bpxwdyn.rexx "alloc fi(mydd) da('managed.test.gdg(+1)') recfm(v,b) new
> catalog gdgnt lrecl(1028)"
> BPXWDYN RC= 0  (0x0)
>
> (job 2)
> ./bpxwdyn.rexx "alloc fi(mydd) da('managed.test.gdg(+1)') recfm(v,b) new
> catalog gdgnt lrecl(1028)"
>
> BPXWDYN RC= 34603008  (0x210)
> IKJ56225I DATA SET MANAGED.TEST.GDG ALREADY IN USE, TRY LATER+
> IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER
> IEFA110I DATA SET CONTENTION
> ...
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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


IEFSCHAS - Using more CPU

2017-09-13 Thread Peter Hunkeler
Not that I would think there is a problem, but in a problem situation, I saw 
IEFSCHAS using more CPU than normal. I never cared to understand what exactly 
IEFSCHAS does. Can anyone tell me?



--
Peter Hunkeler

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