Discussion:
Lack of Support for Doc for COBOL
(too old to reply)
Steve Thompson
2017-09-01 12:22:06 UTC
Permalink
Raw Message
COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS dates.

So here is a response to a document error that was acknowledged as being valid:

------

Thanks for your comment. You are correct: abbreviation for TEST|NOTEST should be none, and SEP|NOSEP should be the abbreviations for the TEST suboptions SEPARATE|NOSEPARATE.

However, we do not update the COBOL V4.2 documentation any longer. We now support continuous documentation delivery for COBOL V6.1 and V5.2 only.

Sorry for the inconveniences caused. Let us know if you have further questions.

Thanks,
Dana Zhang 张丹

COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM

------

The manual has not been updated since “Second Edition (August 2009)”. So one wonders how many errors in the doc have been reported that were not applied to this manual.


Regards,
Steve Thompson


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-01 13:53:54 UTC
Permalink
Raw Message
Sad.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Steve Thompson
Sent: Friday, September 1, 2017 5:22 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Lack of Support for Doc for COBOL

COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
dates.

So here is a response to a document error that was acknowledged as being
valid:

------

Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
should be none, and SEP|NOSEP should be the abbreviations for the TEST
suboptions SEPARATE|NOSEPARATE.

However, we do not update the COBOL V4.2 documentation any longer. We now
support continuous documentation delivery for COBOL V6.1 and V5.2 only.

Sorry for the inconveniences caused. Let us know if you have further
questions.

Thanks,
Dana Zhang 张丹

COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM

------

The manual has not been updated since “Second Edition (August 2009)”. So
one wonders how many errors in the doc have been reported that were not
applied to this manual.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-09-04 15:25:29 UTC
Permalink
Raw Message
Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott
Post by Charles Mills
Sad.
Charles
-----Original Message-----
Behalf Of Steve Thompson
Sent: Friday, September 1, 2017 5:22 AM
Subject: Lack of Support for Doc for COBOL
COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS dates.
------
Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
should be none, and SEP|NOSEP should be the abbreviations for the TEST
suboptions SEPARATE|NOSEPARATE.
However, we do not update the COBOL V4.2 documentation any longer. We now
support continuous documentation delivery for COBOL V6.1 and V5.2 only.
Sorry for the inconveniences caused. Let us know if you have further questions.
Thanks,
Dana Zhang 张丹
COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM
------
The manual has not been updated since “Second Edition (August 2009)”. So
one wonders how many errors in the doc have been reported that were not
applied to this manual.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Scott Ford
IDMWORKS
z/OS Development

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2017-09-04 17:02:04 UTC
Permalink
Raw Message
"... continuous documentation delivery ..." Huh. Didn't we used to have that with a few little things IBM called TNL's?

For hardcover textbooks they issue "Errata" texts on the bookseller or author's website(s). IBM could do that much, but choose not to. Not sad but dumb, IMHO.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of scott Ford
Sent: Monday, September 04, 2017 11:26 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott
Post by Charles Mills
Sad.
Charles
-----Original Message-----
Behalf Of Steve Thompson
Sent: Friday, September 1, 2017 5:22 AM
Subject: Lack of Support for Doc for COBOL
COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS dates.
------
Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
should be none, and SEP|NOSEP should be the abbreviations for the TEST
suboptions SEPARATE|NOSEPARATE.
However, we do not update the COBOL V4.2 documentation any longer. We now
support continuous documentation delivery for COBOL V6.1 and V5.2 only.
Sorry for the inconveniences caused. Let us know if you have further questions.
Thanks,
Dana Zhang 张丹
COBOL Information Developer, PMP
DevOps Systems ID, China Development Lab, IBM
------
The manual has not been updated since “Second Edition (August 2009)”. So
one wonders how many errors in the doc have been reported that were not
applied to this manual.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Scott Ford
IDMWORKS
z/OS Development

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

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-04 23:25:36 UTC
Permalink
Raw Message
Post by scott Ford
Very, considering there are literally hundreds if not thousands of shops
still using COBOL..
Scott
Amen to that Scott. At one place I worked there were on the order of 100,000+ (I have forgotten the exact number).
And that was in user libraries. I was curious and ran it on our link list and found 40.
They are still running everyday and keep working.
BTW the *oldest* COBOL program I found was from 1986.

Ed


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Ross
2017-09-05 17:28:29 UTC
Permalink
Raw Message
Post by scott Ford
Very, considering there are literally hundreds if not thousands of shops
still using COBOL..
Yes, it is unfortunate, but for a serious error we would reconsider our position
on COBOL V4 documentation.

In this case, the reported bug was very minor, and most of the many many COBOL
shops are already using COBOL V5 or V6, whose manuals are getting updated.

The number of defects reported against COBOL V4 is almost zero! That is one of
the reasons why we are considering dropping support for COBOL V4.

Cheers,
TomR >> COBOL is the Language of the Future! <<

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2017-09-05 21:50:09 UTC
Permalink
Raw Message
How about an II APAR with notes about errors in the manuals?
Post by Tom Ross
Post by scott Ford
Very, considering there are literally hundreds if not thousands of shops
still using COBOL..
Yes, it is unfortunate, but for a serious error we would reconsider our position
on COBOL V4 documentation.
In this case, the reported bug was very minor, and most of the many many COBOL
shops are already using COBOL V5 or V6, whose manuals are getting updated.
The number of defects reported against COBOL V4 is almost zero! That is one of
the reasons why we are considering dropping support for COBOL V4.
Cheers,
TomR >> COBOL is the Language of the Future! <<
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-06 01:14:47 UTC
Permalink
Raw Message
Post by Tom Ross
The number of defects reported against COBOL V4 is almost zero! That is one of
the reasons why we are considering dropping support for COBOL V4.
Sorry to persuade you otherwise. After much talk to/from management we are delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and COBOL, they are delaying it as long as they can.
They understand that they are out of service but to quote one VP better to be out of service than to loose load modules and that means downtime and they can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much as upper management. The CIO is aware and not happy but he got burned with PDSE and he agrees that it is worth the chance. I was surprised at their resistance but when you here venom coming out of a VP’s mouth about PDSE’s you would understand.
I tried to get the programmers resistance to have them write down their issues, but I had a feeling they didn’t have to justify much as the VP was really pissed.
When IBM makes enemies like this over one portion of the OS, they are asking IMO to loose a customer.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-06 01:20:22 UTC
Permalink
Raw Message
Post by Tom Ross
Post by Tom Ross
The number of defects reported against COBOL V4 is almost zero! That
is one of
Post by Tom Ross
the reasons why we are considering dropping support for COBOL V4.
Sorry to persuade you otherwise. After much talk to/from management we are
delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I
agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and
COBOL, they are delaying it as long as they can.
They understand that they are out of service but to quote one VP better to
be out of service than to loose load modules and that means downtime and
they can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much
as upper management. The CIO is aware and not happy but he got burned with
PDSE and he agrees that it is worth the chance. I was surprised at their
resistance but when you here venom coming out of a VP’s mouth about PDSE’s
you would understand.
I tried to get the programmers resistance to have them write down their
issues, but I had a feeling they didn’t have to justify much as the VP was
really pissed.
When IBM makes enemies like this over one portion of the OS, they are
asking IMO to loose a customer.
​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.
Post by Tom Ross
Ed
--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Thompson
2017-09-06 02:15:46 UTC
Permalink
Raw Message
<SNIPPAGE>
Post by John McKown
​We must live right. We use PDSE libraries for most "production" libraries
(load & "sysin"). We have have _no_ problems. But I'd be willing to bet
that is because we are a single system "sysplex" with little sharing.​ We
used to be a two system basic (not parallel) sysplex, but did not have any
problems then either. Likely because all updates to the PDSEs were done on
a single member of the 'plex.
Where I work, we run parallel sysplex. We have multiple LPARs in
the main sysplex and it was decided to make our Load Libs PDSE
some years back (perhaps z/OS 1.13?).

However, I've experienced a PDSE failure using z/OS 1.13 at a
different shop. Thankfully it was a PDSE holding listing members
and not the source members. I also lost the Loadlib associated
with it. So I can appreciate the angst.

With the changes that IBM has made to support PDSE, we have not
had, that I am aware of, any PDSE failures since I was hired.

Meanwhile, I am a bit concerned that problems are not being
addressed in COBOL manuals, even if they are "small" or
"insignificant" problems.

Those insignificant DOC problems cause headaches for people
writing code to do translation. The difference is, I recognized
immediately how wrong this was (I'm not doing translation, but
something related).

Now, for INSPECT TALLYING and EVALUATE, I had to go to a third
party's explanation to get my COBOL code to work. Yep, I had to
go to a Fujitsu COBOL manual to get an example. The one I had
when I was writing SMF code on a W/NT 4.0 box many years ago.

Mind you, not the first time for me to use either verb, but there
was some interesting things I needed to do and the COBOL 4.2
manual just didn't do it for me. One look at what was said with
the Fujitsu book and I recognized how I was misreading IBM's doc.

Regards,
Steve Thompson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-09-06 16:18:39 UTC
Permalink
Raw Message
I understand the PDSE fear, though we've not run in to any issues. I don't understand what programmers don't like about COBOL V5/V6. Do you have any concrete examples? Just wondering. I like the new compiler releases. The NUMCHECK option, when used in development, looks to be very interesting and useful.

Frank

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Edward Gould <***@COMCAST.NET>
Sent: Tuesday, September 5, 2017 7:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL
Post by Tom Ross
The number of defects reported against COBOL V4 is almost zero! That is one of
the reasons why we are considering dropping support for COBOL V4.
Sorry to persuade you otherwise. After much talk to/from management we are delaying going to the next v6(?) in COBOL.
We/they don’t trust PDSE. It has broken once to often for this customer (I agree) and they lost load modules up the ying yang.
They also got feedback from the programmers and how they hate the new COBOL’s.
Management knows that sooner or later they have to go but between PDSE and COBOL, they are delaying it as long as they can.
They understand that they are out of service but to quote one VP better to be out of service than to loose load modules and that means downtime and they can’t afford downtime.
The auditors know about this but as it turns out they hate PDSe’s as much as upper management. The CIO is aware and not happy but he got burned with PDSE and he agrees that it is worth the chance. I was surprised at their resistance but when you here venom coming out of a VP’s mouth about PDSE’s you would understand.
I tried to get the programmers resistance to have them write down their issues, but I had a feeling they didn’t have to justify much as the VP was really pissed.
When IBM makes enemies like this over one portion of the OS, they are asking IMO to loose a customer.

Ed

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-06 16:42:12 UTC
Permalink
Raw Message
I think when you are maintaining 30-year-old 50,000-line programs the phrase
"slight incompatibility" sends shivers up your spine.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues. I don't
understand what programmers don't like about COBOL V5/V6. Do you have any
concrete examples? Just wondering. I like the new compiler releases. The
NUMCHECK option, when used in development, looks to be very interesting and
useful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2017-09-06 16:52:15 UTC
Permalink
Raw Message
With the use of the proper compile options I have not heard of any compatibility issues in our environment. Indeed the original COBOL V5 release did have some. But I believe that IBM has now made it possible, with the correct compiler options, to get the same results (albeit with generally better generated machine code) as with COBOL V4. There may, of course, still be some edge cases.

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Charles Mills <***@MCN.ORG>
Sent: Wednesday, September 6, 2017 10:43 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I think when you are maintaining 30-year-old 50,000-line programs the phrase
"slight incompatibility" sends shivers up your spine.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues. I don't
understand what programmers don't like about COBOL V5/V6. Do you have any
concrete examples? Just wondering. I like the new compiler releases. The
NUMCHECK option, when used in development, looks to be very interesting and
useful.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-07 11:36:57 UTC
Permalink
Raw Message
Post by Frank Swarbrick
I understand the PDSE fear, though we've not run in to any issues. I don't understand what programmers don't like about COBOL V5/V6. Do you have any concrete examples? Just wondering. I like the new compiler releases. The NUMCHECK option, when used in development, looks to be very interesting and useful.
Frank
Frank,
The mere mention that it needs PDSe send spine tingling messages to the nerve center and sooner or later the VP’s get involved and when they hear PDSe they say its too soon come back it 5 years when it is bug free.
The COBOL itself issue is that (this is bits and pieces I have heard) they just do not like it and the documentation sucks (I agree) I have read some of the manuals and at times you need to be a lawyer to understand them. With one manual I photo copied a few pages and went back to my desk to see if I could understand it and after 15 minutes of talking out loud to myself while trying to understand it, I ripped the pages up and threw them away. I never wanted to see the damn manual again and didn’t want to have to explain it aloud as I can’t.

Ed

Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-06 02:31:43 UTC
Permalink
Raw Message
Post by Mike Schwab
How about an II APAR with notes about errors in the manuals?
​Just to be my usual "out in left field" self, I wish that IBM would allow
all "no longer available or maintained" manuals to have their "source"
released using the CC​-NC-SA license ( https://creativecommons.org/
licenses/by-nc-sa/4.0/). I do understand why they don't, I guess. But "in a
perfect world" it would be nice. Even nicer would be if they'd use TeX ( tɛx
) ​for​ the source.
--
Caution! The OP is an hyperpolysyllabicsesquipedalianist and this email may
cause stress to those with hippopotomonstrosesquipedaliophobia.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-06 17:39:47 UTC
Permalink
Raw Message
Well into the 1970s, there were legions of IT folks who did not trust VSAM. There was a droll little ditty of the 'If it...then it's...' type. The last line went, 'If it...but it doesn't work, then it's VSAM'.

So is there anyone left who so mistrusts VSAM that they cannot commit to a technology upgrade? I think that we've finally got past that hang-up. PDSE is ready for prime time.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Wednesday, September 06, 2017 9:53 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Lack of Support for Doc for COBOL

With the use of the proper compile options I have not heard of any compatibility issues in our environment. Indeed the original COBOL V5 release did have some. But I believe that IBM has now made it possible, with the correct compiler options, to get the same results (albeit with generally better generated machine code) as with COBOL V4. There may, of course, still be some edge cases.

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Charles Mills <***@MCN.ORG>
Sent: Wednesday, September 6, 2017 10:43 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I think when you are maintaining 30-year-old 50,000-line programs the phrase "slight incompatibility" sends shivers up your spine.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Wednesday, September 6, 2017 9:20 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

I understand the PDSE fear, though we've not run in to any issues. I don't understand what programmers don't like about COBOL V5/V6. Do you have any concrete examples? Just wondering. I like the new compiler releases. The NUMCHECK option, when used in development, looks to be very interesting and useful.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-07 01:24:01 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
Well into the 1970s, there were legions of IT folks who did not trust VSAM. There was a droll little ditty of the 'If it...then it's...' type. The last line went, 'If it...but it doesn't work, then it's VSAM'.
So is there anyone left who so mistrusts VSAM that they cannot commit to a technology upgrade? I think that we've finally got past that hang-up. PDSE is ready for prime time.
The PDSe outage brought the company to its knees. They do NOT want to see the same thing happening again. All the higher up operating officers got their hands slapped and not nicely either. They lost their bonuses and lost vacation time and a few other things that I am not sure of so I won’t speculate.
I know that there are some necessary PDSe’s but have hidden that fact from them. My boss told me never to tell anyone that we have some.
I think is we ever had another outage for PDSe they would be out shopping for another vendor and I wouldn’t blame them. I would leave if they ever tried to bring in a replacement.
They are extremely weary of JAVA as well, I expect then to get over it in time, but I am not going to push it.

Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-09-07 10:23:05 UTC
Permalink
Raw Message
Post by Edward Gould
Post by Jesse 1 Robinson
I think that we've finally got past that hang-up. PDSE is ready for prime time.
The PDSe outage brought the company to its knees. They do NOT want to see the same thing happening again. All the higher up operating officers got their hands slapped and not nicely either. They lost their bonuses and lost vacation time and a few other things that I am not sure of so I won’t speculate.
I'm glad I don't work for a company who punish people for problems they
we're not responsible for. If a PDSE problem really did bring your
company to it's knees then your company probably needs to review it's
procedures.
Post by Edward Gould
I know that there are some necessary PDSe’s but have hidden that fact from them. My boss told me never to tell anyone that we have some.
I think is we ever had another outage for PDSe they would be out shopping for another vendor and I wouldn’t blame them. I would leave if they ever tried to bring in a replacement.
They are extremely weary of JAVA as well, I expect then to get over it in time, but I am not going to push it.
Java is a word not an acronym.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-09-07 11:09:53 UTC
Permalink
Raw Message
Post by David Crayford
Post by Edward Gould
Post by Jesse 1 Robinson
I think that we've finally got past that hang-up. PDSE is ready for prime time.
The PDSe outage brought the company to its knees. They do NOT want to
see the same thing happening again. All the higher up operating
officers got their hands slapped and not nicely either. They lost
their bonuses and lost vacation time and a few other things that I am
not sure of so I won’t speculate.
I'm glad I don't work for a company who punish people for problems
they we're not responsible for. If a PDSE problem really did bring
your company to it's knees then your company probably needs to review
it's procedures.
I know companies which are not ready for computers at all.
PDSE is so new... ;-)
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


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

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

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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2017-09-07 11:15:58 UTC
Permalink
Raw Message
Post by R.S.
Post by David Crayford
Post by Edward Gould
Post by Jesse 1 Robinson
I think that we've finally got past that hang-up. PDSE is ready for prime time.
The PDSe outage brought the company to its knees. They do NOT want
to see the same thing happening again. All the higher up operating
officers got their hands slapped and not nicely either. They lost
their bonuses and lost vacation time and a few other things that I
am not sure of so I won’t speculate.
I'm glad I don't work for a company who punish people for problems
they we're not responsible for. If a PDSE problem really did bring
your company to it's knees then your company probably needs to review
it's procedures.
Of course I meant *were. Bloody iPhone.
Post by R.S.
I know companies which are not ready for computers at all.
PDSE is so new... ;-)
My goodness what would they say if somebody suggested using the z/OS
Unix file system? :)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pommier, Rex
2017-09-07 12:58:36 UTC
Permalink
Raw Message
Re: Java is a word not an acronym... Just Another Vague Acronym?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Thursday, September 07, 2017 5:24 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL
Post by Edward Gould
Post by Jesse 1 Robinson
I think that we've finally got past that hang-up. PDSE is ready for prime time.
The PDSe outage brought the company to its knees. They do NOT want to see the same thing happening again. All the higher up operating officers got their hands slapped and not nicely either. They lost their bonuses and lost vacation time and a few other things that I am not sure of so I won’t speculate.
I'm glad I don't work for a company who punish people for problems they
we're not responsible for. If a PDSE problem really did bring your
company to it's knees then your company probably needs to review it's
procedures.
Post by Edward Gould
I know that there are some necessary PDSe’s but have hidden that fact from them. My boss told me never to tell anyone that we have some.
I think is we ever had another outage for PDSe they would be out shopping for another vendor and I wouldn’t blame them. I would leave if they ever tried to bring in a replacement.
They are extremely weary of JAVA as well, I expect then to get over it in time, but I am not going to push it.
Java is a word not an acronym.

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


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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-09-11 17:00:07 UTC
Permalink
Raw Message
In looking at the news, I'm wondering if encryption would have
prevented any of the known data breaches. I'm thinking of Equifax,
Anthem, Target and Yahoo for starters. If one steals a database, they
need to be able to steal the means to read it which would mean they
have a computer compatible with the target company and the
corresponding software. While dumps of tape files can give probable
hits, if the record descriptions aren't available, there is at least
some difficultly in guessing which fields are what. How did the
thefts work and to what extent did the thieves appear to the system as
valid users?

Are test systems, even with data masking applied to production data,
of use to thieves?

What are the risks of encryption? Loss of password or keys seems a
noticeable risk as does compromise of same.

Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2017-09-08 05:56:50 UTC
Permalink
Raw Message
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.

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: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-09-08 13:52:32 UTC
Permalink
Raw Message
[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
Post by Timothy Sipples
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.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2017-09-13 18:51:21 UTC
Permalink
Raw Message
[Default] On 7 Sep 2017 22:56:50 -0700, in bit.listserv.ibm-main
Post by Timothy Sipples
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
Post by Timothy Sipples
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-14 05:46:49 UTC
Permalink
Raw Message
Post by Clark Morris
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-***@LISTSERV.UA.EDU] On
Behalf Of Clark Morris
Sent: Wednesday, September 13, 2017 8:52 PM
To: IBM-***@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
Post by Clark Morris
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-09-08 06:14:16 UTC
Permalink
Raw Message
Post by Timothy Sipples
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.
Jimmy Iovine said it well: "Never stop being of service."
Still, the idea that safe, regulated sharing of a PDSE can only be guaranteed
to members of a single sysplex, seems to hint that IBM thought at time
that no one will ever need more than one sysplex.
Doesn't it seem so?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2017-09-08 07:11:38 UTC
Permalink
Raw Message
We're a small shop. We *really* don't want to be paying thousands every
month just for the "privilege" of being able to report bugs with, and
get fixes for, our non-Linux mainframe software. (IMHO such support
ought to be included free as part of MLC and S&S payments, but that's a
discussion for another day...)
I agree. So does IBM.

Your mainframe Monthly License Charges (MLC) and Subscription and Support
(S&S) include IBM Program Services at no additional charge. See here for
details:

https://www.ibm.com/support/customercare/sas/f/handbook/offerings.html
#section2

Quoting IBM, "Program Services is a support element of some IBM products
that allows you to report suspected IBM defects to IBM...." I like how IBM
clarifies that suspected (and actual) *non-IBM* defects aren't part of the
deal. Speak with your therapist about those other defects. :-)

SoftwareXcel, and its successors, provide additional support services above
and beyond Program Services, notably including some "how-to" support.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2017-09-08 15:15:55 UTC
Permalink
Raw Message
Post by Timothy Sipples
SoftwareXcel, and its successors, provide additional support services above
and beyond Program Services, notably including some "how-to" support.
It used to be that if you didn't have at least SoftwareXcel Basic
Edition, you could not logon to IBMLink to search for fixes, you could
not open PMRs electronically (you had L1 voice only), and you could not
download PTFs electronically (you had tape only).

Are you saying that I can now search for fixes, open PMRs
electronically, and download PTFs electronically without paying for
SoftwareXcel Basic Edition? Please elaborate!

Haha! Never in my life have I asked anything resembling a "how to"
question via a support channel. I don't think that's even possible with
SoftwareXcel Basic Edition! LOL
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rugen, Len
2017-09-08 15:59:44 UTC
Permalink
Raw Message
If I have to ask how-to, isn't it a DOC apar? :-O


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Friday, September 8, 2017 10:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: SoftwareXcel Discontinued
Post by Timothy Sipples
SoftwareXcel, and its successors, provide additional support services
above and beyond Program Services, notably including some "how-to" support.
It used to be that if you didn't have at least SoftwareXcel Basic Edition, you could not logon to IBMLink to search for fixes, you could not open PMRs electronically (you had L1 voice only), and you could not download PTFs electronically (you had tape only).

Are you saying that I can now search for fixes, open PMRs electronically, and download PTFs electronically without paying for SoftwareXcel Basic Edition? Please elaborate!

Haha! Never in my life have I asked anything resembling a "how to"
question via a support channel. I don't think that's even possible with SoftwareXcel Basic Edition! LOL

--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-09-08 23:06:22 UTC
Permalink
Raw Message
To me it boggles the mind that a company would charge extra for Web-based support as opposed to voice-based support. Most software companies, if anything, use the opposite approach.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Friday, September 8, 2017 8:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: SoftwareXcel Discontinued
Post by Timothy Sipples
SoftwareXcel, and its successors, provide additional support services
above and beyond Program Services, notably including some "how-to" support.
It used to be that if you didn't have at least SoftwareXcel Basic Edition, you could not logon to IBMLink to search for fixes, you could not open PMRs electronically (you had L1 voice only), and you could not download PTFs electronically (you had tape only).

Are you saying that I can now search for fixes, open PMRs electronically, and download PTFs electronically without paying for SoftwareXcel Basic Edition? Please elaborate!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-08 18:00:41 UTC
Permalink
Raw Message
We've had the extended version for so long that I can't remember life without it. What I do remember is that several years back, our software license folks 'forgot' to pay the SoftwareXcel bill. We were suddenly unable to report problems via ServiceLink. It got straightened out in a few days, but it was jarring to go unsupported.

And yes, we have periodically used the Q&A service, though we could probably get along without that. It's nice to be able to report a 'problem' without knowing in advance whether it's a defect in the product or a defect in our understanding.

I don't know the boundaries between basic and extended.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Friday, September 08, 2017 8:17 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SoftwareXcel Discontinued
Post by Timothy Sipples
SoftwareXcel, and its successors, provide additional support services
above and beyond Program Services, notably including some "how-to" support.
It used to be that if you didn't have at least SoftwareXcel Basic Edition, you could not logon to IBMLink to search for fixes, you could not open PMRs electronically (you had L1 voice only), and you could not download PTFs electronically (you had tape only).

Are you saying that I can now search for fixes, open PMRs electronically, and download PTFs electronically without paying for SoftwareXcel Basic Edition? Please elaborate!

Haha! Never in my life have I asked anything resembling a "how to"
question via a support channel. I don't think that's even possible with SoftwareXcel Basic Edition! LOL

--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2017-09-08 18:16:48 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
We've had the extended version for so long that I can't remember life without it. What I do remember is that several years back, our software license folks 'forgot' to pay the SoftwareXcel bill. We were suddenly unable to report problems via ServiceLink. It got straightened out in a few days, but it was jarring to go unsupported.
You weren't unsupported. (Just ask Timothy Sipples.) But, you probably
had L1 voice support via 1-800-IBM-SERV only.

If you needed a fix, I'm not sure how they would send it to you these
days. Years ago it was tape only without SoftwareXcel. Yuck!
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-08 20:30:44 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
We've had the extended version for so long that I can't remember life without it. What I do remember is that several years back, our software license folks 'forgot' to pay the SoftwareXcel bill. We were suddenly unable to report problems via ServiceLink. It got straightened out in a few days, but it was jarring to go unsupported.
You weren't unsupported. (Just ask Timothy Sipples.) But, you probably had L1 voice support via 1-800-IBM-SERV only.
If you needed a fix, I'm not sure how they would send it to you these days. Years ago it was tape only without SoftwareXcel. Yuck!
Ed,

Don’t you remember the dialup connection the systems had with Boulder?
*MANY* a time I dowloaded apars from Boulder. It wasn’t fun but more interesting that you had the power of the cpu’s and you were limited to 600 baud.

Ed
--
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-08 19:09:55 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
We've had the extended version for so long that I can't remember life without it. What I do remember is that several years back, our software license folks 'forgot' to pay the SoftwareXcel bill. We were suddenly unable to report problems via ServiceLink. It got straightened out in a few days, but it was jarring to go unsupported.
And yes, we have periodically used the Q&A service, though we could probably get along without that. It's nice to be able to report a 'problem' without knowing in advance whether it's a defect in the product or a defect in our understanding.
I don't know the boundaries between basic and extended.
Jesse,

About 25 years ago, we were in the middle of purchase an IBM system. We had some questions on it (mostly operational).
We asked our so called IBM-Rep to find out the answers. He told us, we would have to sign a $25K service contract to get the answers. I looked at him and said if we have to pay IBM for simple questions, we will go elsewhere. I called up a friend at IBM and he was happy to supply the answers and suggested some other issues we should look at. I told him the next time he was in town, dinner was on me. Total cost to the company was $73 and it was deductible. We never asked IBM another question. We also went to 3rd party suppliers for disk/tape etc. I just used my black book of friends and the total cost of the was $25 for a bottle of wine. I made sure our IBM rep know where we went for questions that IBM should have been happy to answer, we went elsewhere. I also made sure that we severed all ties to IBM after that except for maintenance of software. We turned our backs on IBM. That is what short-sightedness of IBM has brought on.

Ed
Post by Jesse 1 Robinson
.
.
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-08 18:15:49 UTC
Permalink
Raw Message
From the get-go (mid 90s) we created multiple sysplexes for business reasons. Long before sysplex, it was the practice here not to share *anything* among 'systems', each of which had its own purpose: sandbox, development, production, etc. For us it was natural (and surprisingly easy) to convert each system into its own separate sysplex. Sharing was kept within a strict functional unit. Sysplex was the new unit.

I understand that many (most?) shops did not evolve that way. When I first heard at SHARE about the PDSE requirement for COBOL, I was concerned that many shops would have to change their way of doing business. It's not an insurmountable problem, but it's a 'gate' to moving forward. Unfortunately a shop that has shared PDS forever sees little business benefit in creating and maintaining multiple PDSEs even though the post-conversion overhead is minimal.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Giliad Wilf
Sent: Thursday, September 07, 2017 11:15 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Lack of Support for Doc for COBOL
Post by Timothy Sipples
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.
Jimmy Iovine said it well: "Never stop being of service."
Still, the idea that safe, regulated sharing of a PDSE can only be guaranteed to members of a single sysplex, seems to hint that IBM thought at time that no one will ever need more than one sysplex.
Doesn't it seem so?


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2017-09-12 14:29:16 UTC
Permalink
Raw Message
Post by Clark Morris
In looking at the news, I'm wondering if encryption would have
prevented any of the known data breaches.
The short answer: "Yes."

The implementation details matter a lot and influence the success rates.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
scott Ford
2017-09-12 14:42:19 UTC
Permalink
Raw Message
Guys,

I am curious has anyone published how these places were hacked, i.e.;
method ...
This way one maybe prevent it.

Scott
Post by Timothy Sipples
Post by Clark Morris
In looking at the news, I'm wondering if encryption would have
prevented any of the known data breaches.
The short answer: "Yes."
The implementation details matter a lot and influence the success rates.
------------------------------------------------------------
--------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

***@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-09-13 11:29:15 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-09-13 12:53:36 UTC
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-09-13 13:14:14 UTC
Permalink
Raw Message
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
Post by Elardus Engelbrecht
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,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-13 17:26:56 UTC
Permalink
Raw Message
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Wednesday, September 13, 2017 6:15 AM
To: IBM-***@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
Post by Elardus Engelbrecht
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2017-09-13 17:37:52 UTC
Permalink
Raw Message
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
Post by 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
-----Original Message-----
Sent: Wednesday, September 13, 2017 6:15 AM
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
Post by Elardus Engelbrecht
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-13 17:42:09 UTC
Permalink
Raw Message
Post by 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
​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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2017-09-13 17:56:36 UTC
Permalink
Raw Message
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
Post by John McKown
Post by 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
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,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-13 17:38:15 UTC
Permalink
Raw Message
Post by 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?)
​If the question about "Draconian" is actual, it comes from "draco" or
"dragon". And most dragons are hard *sses.​
Post by Jesse 1 Robinson
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
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2017-09-13 18:32:35 UTC
Permalink
Raw Message
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 :)
Post by 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
-----Original Message-----
Sent: Wednesday, September 13, 2017 6:15 AM
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
Post by Elardus Engelbrecht
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Anne & Lynn Wheeler
2017-09-15 22:03:02 UTC
Permalink
Raw Message
we were somewhat involved in (original) cal. data breach notification
act ... having been brought in to help wordsmith the electronic
signature act and several of the players were heavily involved in
privacy ... and had done in depth public surveys and #1 was fraudulent
financial transactions somewhat as the result of various kinds of
breaches (before notification each member of public thot it was isolated
incident affecting only them). Problem was that little or nothing was
being done about the breaches and it was hoped that publicity from the
notifications might prompt corrective action. The issue is that entities
normally take security measures in self interest/protection. In the case
of breaches, it wasn't the institutions that are risk, but the
public. Since then there has been a dozen or so federal bills proposed
about evenly divided between those similar to the cal. state act and
those that effectively negate need for notification (in some cases,
specifying a combination of information compromised that would
essentially never occur).

We had aksi been brought in as consultants into small client/server
startup that wanted to do payment transactions on their server, they had
also invented this technology called "SSL" they wanted to use, the
result is now frequently called "electronic commerce". Somewhat for
having done "electronic commerce", we get brought in to the X9A10
financial standard working group that had been given the requirement to
preserve the integrity of finanical infrastructure for *ALL* retail
payments. We did detailed end-to-end vulnerability and exploit studies
of various kinds of payments and eventually wrote a standard that
slightly changes the current paradigm ... and eliminates the ability of
crooks to use information from previous transactions, records and/or
account numbers to perform fraudulent transaction. As a result it is no
longer necessary to hide/encrypt such information ... either in transit
and/or at rest (somewhat negating the earlier work with SSL for
electronic commerce).

dual-use metaphor; transaction account number is used for business
processes and must be readily available for scores of business processes
and millions of locations around the planet. at the same time it is used
for authentication&authorization and therefor must *NEVER* be
divulged. The conflicting requirements has resulted in us observing that
even if the planet was buried under miles of information hiding
encryption, it still wouldn't stop information leakage

security proportional to risk metaphor; value of transaction information
to merchant is profit from the transaction ... possibly a couple of
dollars (and value to infrastructure operators a few cents) while the
value of the information to the crooks is the account balance and/or
credit limit. As a result, the crooks may be able to outspend attacking
the system by a factor of 100 times what the defenders can afford to
spend.

Part of the issue now is there are lot of stakeholders with vested
interest in the unchanged paradigm.
--
virtualization experience starting Jan1968, online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-09-13 18:58:12 UTC
Permalink
Raw Message
Post by Clark Morris
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-09-13 19:37:34 UTC
Permalink
Raw Message
Post by Paul Gilmartin
Post by Clark Morris
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
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Timothy Sipples
2017-09-14 05:38:36 UTC
Permalink
Raw Message
Post by 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)?
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.
Post by Peter Relson
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: ***@sg.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-09-14 12:12:25 UTC
Permalink
Raw Message
The LPA is built as part of the IPL process, but only load modules
not programs objects can be loaded into PLA at that time because
program objects live in PDS/Es.
The LPA statement in PROGxx is processed at the end of IPL.
PDSEs can be included at that time.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm

This is a recurring complaint about PDSEs, but I don't see the merit
in it. MVS has provided a mechanism to include program objects when
it is IPLed.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2017-09-14 12:33:39 UTC
Permalink
Raw Message
Post by Clark Morris
In looking at the news, I'm wondering if encryption would have
prevented any of the known data breaches. I'm thinking of Equifax,
Anthem, Target and Yahoo for starters.
The Anthem breach was the result of a phishing attack, and an internal machine was compromised. At that point, the bad guys are so far inside the tent that it's not clear what would have helped. See https://www.bankinfosecurity.com/new-in-depth-analysis-anthem-breach-a-9627

Target was more interesting: the POS terminal software was compromised, and so it was stealing data that was being passed through the payments path in the clear. Encryption *in the terminal* would have stopped that. See http://www.zdnet.com/article/anatomy-of-the-target-data-breach-missed-opportunities-and-lessons-learned/ and lots of others (since this is an older one, there's lots out there if you search "target breach analysis").

Finally, Yahoo has been breached repeatedly. A bit of Googling finds focus on why the most recent breach was fruitful: the bad guys stole unsalted MD5-hashed passwords, thus allowing a rainbow table to be used against the data. This is so basic and obvious in the security business that I think most people at that point said "It doesn't matter how exactly the data was exfiltrated-Yahoo was just asking for it". But I'm sure there are more detailed discussions out there.

The key to making encryption be as effective as possible is to only decrypt the data occasionally. That means that transparent encryption, such as whole-file encryption in z/OS, isn't that effective. It's not useless, but it's not as effective as application-level encryption, simply because it means that things "below" the application in the stack can be breached and allow data theft (as opposed to what I might call "byte theft", i.e., stealing encrypted data, which is of no value).

Of course if the application is truly breached, all is lost-if the application has rights to cleartext data.

<puts on vendor hat>
Using format-preserving data protection means that many applications can operate on the data in its protected state, without changes. Simplest example: a credit card number (PAN). However many applications you have that touch PANs, the only ones that ever need the cleartext are the ones that ingest them from the outside world (web pages, customer service applications, et al.) and the one that passes it to the processor for authorization/settlement. And *maybe* some folks in fraud prevention. Otherwise, it's just a magic 15- or 16-digit number (soon to be more digits, o boy): all you care about is that it's consistent and unique, and that it looks like a PAN. So if you protect the middle six digits (all that PCI DSS requires) *as soon as you acquire it*, then several good things are true:


1) All of the other applications are safer (note that "r"!) because they will never touch cleartext

2) All of the other applications are out of PCI scope

3) All of the other applications need no changes

4) Data is interoperable with other systems, including ASCII systems, without requiring decryption before transmission

5) The attack surface for PANs (assuming proper control of key access, etc., of course) is limited to the acquiring applications and the application that does authorization/settlement

So with relatively little effort, you've protected a lot of the system.

Again, as others have noted, defense-in-depth means you also want DASD encryption, you also want encrypted backups, you also may use whole-file encryption in cases where data has to be stored as cleartext.
<removes vendor hat>
Post by Clark Morris
If one steals a database, they
need to be able to steal the means to read it which would mean they
have a computer compatible with the target company and the
corresponding software. While dumps of tape files can give probable
hits, if the record descriptions aren't available, there is at least
some difficultly in guessing which fields are what. How did the
thefts work and to what extent did the thieves appear to the system as
valid users?
True, but any protection you're imputing there is "security by obscurity". If I had managed to get into Equifax and acquired a raw dump of a 10TB database, I think I could find a z/OS system somewhere (or build one) and figure out how to read it so I could monetize that dump. Or maybe I'd just do analysis and make some guesses.
Post by Clark Morris
Are test systems, even with data masking applied to production data,
of use to thieves?
If they have improper access to real data, sure; and if they provide a way to understand data flows and connections to enable attacks on production, also yes. That is, if a test system isn't secure "because it's just a test system", and that lets bad guys bang on it unnoticed until they find a hole that they can then use on the production system, then definitely.
Post by Clark Morris
What are the risks of encryption? Loss of password or keys seems a
noticeable risk as does compromise of same.
Encryption mantra: "Encryption is easy; key management is hard". So definitely. Performance is another issue-done badly, it can be a killer, especially (obviously) in real-time processing: if adding encryption means that web "Buy" button now takes 30 seconds, folks will stop using that site. If adding encryption means the nightly batch window now takes 36 hours...

All good questions, and obviously you pushed some of my favorite buttons! I'll stop now :)
--
...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
Micro Focus (Voltage)

***@microfocus.com
T 703-476-4511
M 703-568-6662
Herndon, VA

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2017-09-15 00:43:29 UTC
Permalink
Raw Message
Post by Phil Smith
All good questions, and obviously you pushed some of my favorite buttons! I'll stop now :)
Great notes Phil. Thanks!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-14 15:30:39 UTC
Permalink
Raw Message
Thanks for the Draco education. ;-)

One point I failed to mention is the question of why US companies should be overwrought by an EU regulation. This is still in the 'opinion' stage, but it was pointed out at SHARE that the data breach penalty is intended to protect EU citizens--wherever they might reside. Surely Equifax holds data on an untold number of EU citizens. That could make the company hugely liable even though it's a US company. How this might shake out in court is anybody's guess, but properly encrypting data is surely the best defense.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Mike Schwab
Sent: Wednesday, September 13, 2017 10:58 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

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:39 PM, Mike Schwab
Post by 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
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-14 15:42:33 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
Thanks for the Draco education. ;-)
One point I failed to mention is the question of why US companies should
be overwrought by an EU regulation. This is still in the 'opinion' stage,
but it was pointed out at SHARE that the data breach penalty is intended to
protect EU citizens--wherever they might reside. Surely Equifax holds data
on an untold number of EU citizens. That could make the company hugely
liable even though it's a US company. How this might shake out in court is
anybody's guess, but properly encrypting data is surely the best defense.
​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
Post by Jesse 1 Robinson
.
.
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
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mark Regan
2017-09-14 16:08:13 UTC
Permalink
Raw Message
Just FYI...
Equifax hack preventable with patch
http://thehill.com/policy/cybersecurity/350616-equifax-hack-due-to-patchable-security-flaw
On Thu, Sep 14, 2017 at 10:31 AM, Jesse 1 Robinson <
Post by Jesse 1 Robinson
Thanks for the Draco education. ;-)
One point I failed to mention is the question of why US companies should
be overwrought by an EU regulation. This is still in the 'opinion' stage,
but it was pointed out at SHARE that the data breach penalty is intended
to
Post by Jesse 1 Robinson
protect EU citizens--wherever they might reside. Surely Equifax holds
data
Post by Jesse 1 Robinson
on an untold number of EU citizens. That could make the company hugely
liable even though it's a US company. How this might shake out in court
is
Post by Jesse 1 Robinson
anybody's guess, but properly encrypting data is surely the best defense.
​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
Post by Jesse 1 Robinson
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 <(323)%20715-0595> Mobile
626-543-6132 <(626)%20543-6132> Office ⇐=== NEW
--
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,
--
Regards,

Mark T. Regan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Pew, Curtis G
2017-09-14 16:34:04 UTC
Permalink
Raw Message
Post by John McKown
IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
When I gave a presentation about encryption to our programmers a few years back, one thing I said was “Encryption never solves your problem. Instead, it transforms your problem into a different problem, which may be easier to solve.” (I was thinking specifically about key management, but even that’s not the whole story.) The important point here is that just throwing encryption at a security issue doesn’t resolve it. Encryption is a valuable tool that properly used can be a significant part of a security solution, but by itself doesn’t magically solve anything.
--
Pew, Curtis G
***@austin.utexas.edu
ITS Systems/Core/Administrative Services


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2017-09-15 00:40:00 UTC
Permalink
Raw Message
Post by John McKown
​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?

http://www.bbc.com/news/technology-41257576

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-15 12:50:23 UTC
Permalink
Raw Message
Post by Tom Brennan
Post by John McKown
​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them the
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed because
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
http://www.bbc.com/news/technology-41257576
​That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2017-09-15 19:14:41 UTC
Permalink
Raw Message
Hiring competent people. That's so 20th-century. Get with the program, man!
Post by John McKown
Post by Tom Brennan
Post by John McKown
​IMO, encrypting data is a very good defense. Another good defense is
hiring competent people rather than inexpensive people and giving them
the
Post by Tom Brennan
Post by John McKown
time to design, code, and test their solutions. I don't have statistics,
but many attacks are based on coding errors such as the infamous "SQL
Injection" attacks. ​On the almost hilarious attacks which succeed
because
Post by Tom Brennan
Post by John McKown
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin". Of
course, the people & time requirements that I mentioned "cost too much" and
"delay time to market". Today's world is based on think up something in the
morning, design over lunch, create before dinner, ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
http://www.bbc.com/news/technology-41257576
​That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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,
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-15 19:32:41 UTC
Permalink
Raw Message
Post by zMan
Hiring competent people. That's so 20th-century. Get with the program, man!
​Amusingly, from some of what I've read, one of the reasons for the COBOL
language was so that "lower trained" enlisted men (& women) could produce
quality code just using the English language ( versus Fortran et al). We
are _still_ coming up with languages for "the average person"
(inexperienced & inexpensive) to be able to write quality code which​ "just
works". Too bad the hardware people haven't come up with the DWIM opcode
yet.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2017-09-14 18:14:07 UTC
Permalink
Raw Message
When I gave a presentation about encryption to our programmers a few years back, one thing I said was "Encryption never solves your problem. Instead, it transforms your problem into a different problem, which may be easier to solve." (I was thinking specifically about key management, but even that's not the whole story.) The important point here is that just throwing encryption at a security issue doesn't resolve it. Encryption is a valuable tool that properly used can be a significant part of a security solution, but by itself doesn't magically solve anything.
That's great-sums it up very nicely!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Giliad Wilf
2017-09-14 18:15:45 UTC
Permalink
Raw Message
Yes, but no PDSE may be listed in LPALSTxx, and since LPALSTxx must list SYS1.LPALIB, it can't be a PDSE.
Post by Tom Marchant
The LPA is built as part of the IPL process, but only load modules
not programs objects can be loaded into PLA at that time because
program objects live in PDS/Es.
The LPA statement in PROGxx is processed at the end of IPL.
PDSEs can be included at that time.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm
This is a recurring complaint about PDSEs, but I don't see the merit
in it. MVS has provided a mechanism to include program objects when
it is IPLed.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-09-14 20:23:10 UTC
Permalink
Raw Message
Post by Giliad Wilf
Yes, but no PDSE may be listed in LPALSTxx, and since LPALSTxx
must list SYS1.LPALIB, it can't be a PDSE.
It is true that SYS1.LPALIB cannot be a PDSE, but who cares?
It isn't important. MVS has long had a mechanism to include
program objects in LPA when the system is IPLed.
--
Tom Marchant
Post by Giliad Wilf
Post by Tom Marchant
The LPA is built as part of the IPL process, but only load modules
not programs objects can be loaded into PLA at that time because
program objects live in PDS/Es.
The LPA statement in PROGxx is processed at the end of IPL.
PDSEs can be included at that time.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/proglpa.htm
This is a recurring complaint about PDSEs, but I don't see the merit
in it. MVS has provided a mechanism to include program objects when
it is IPLed.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-15 19:20:28 UTC
Permalink
Raw Message
I have to keep harping on this. The looming EU regulation on hacking is a potentially huge legal liability. You cannot defend yourself in court by arguing that you hire the best people. You can defend yourself only by showing that the hacked data was encrypted.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!
On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
Post by Tom Brennan
Post by John McKown
​IMO, encrypting data is a very good defense. Another good defense
is hiring competent people rather than inexpensive people and
giving them
the
Post by Tom Brennan
Post by John McKown
time to design, code, and test their solutions. I don't have
statistics, but many attacks are based on coding errors such as the
infamous "SQL Injection" attacks. ​On the almost hilarious attacks
which succeed
because
Post by Tom Brennan
Post by John McKown
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin".
Of course, the people & time requirements that I mentioned "cost too much"
and
"delay time to market". Today's world is based on think up
something in the morning, design over lunch, create before dinner,
ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
http://www.bbc.com/news/technology-41257576
​That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bill Wilkie
2017-09-15 19:35:23 UTC
Permalink
Raw Message
What if your data was encrypted, you read it into a sort, put the sort output to a data set where it was NOT encrypted, and someone copied it? Or, they got it from sort work areas that were left on disk and not erased? Does that count?


Bill


________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Jesse 1 Robinson <***@SCE.COM>
Sent: Friday, September 15, 2017 7:21 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Would encryption have prevented known major breaches?

I have to keep harping on this. The looming EU regulation on hacking is a potentially huge legal liability. You cannot defend yourself in court by arguing that you hire the best people. You can defend yourself only by showing that the hacked data was encrypted.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!
On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
Post by Tom Brennan
Post by John McKown
IMO, encrypting data is a very good defense. Another good defense
is hiring competent people rather than inexpensive people and
giving them
the
Post by Tom Brennan
Post by John McKown
time to design, code, and test their solutions. I don't have
statistics, but many attacks are based on coding errors such as the
infamous "SQL Injection" attacks. On the almost hilarious attacks
which succeed
because
Post by Tom Brennan
Post by John McKown
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin".
Of course, the people & time requirements that I mentioned "cost too much"
and
"delay time to market". Today's world is based on think up
something in the morning, design over lunch, create before dinner,
ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576&data=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f0771%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636411001169882688&sdata=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4QugDNJVVHCc%3D&reserved=0
That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-15 19:41:18 UTC
Permalink
Raw Message
Post by Bill Wilkie
What if your data was encrypted, you read it into a sort, put the sort
output to a data set where it was NOT encrypted, and someone copied it? Or,
they got it from sort work areas that were left on disk and not erased?
Does that count?
​I was told of a company, back in the 3330 days, where the accounting dept
had their own set of 3330 disk packs. All their data & their temporary data
sets were on these packs. When the "secure" accounting cycle was running​,
a person from the department brought those pack down. The operators removed
the normal temporary storage disks, then mounted the accounting data & work
disks. When the cycle ended, the department person took the packs back to
the accounting dept and locked them up in a safe. Now that was fairly
secure. Oh, and the output was actually taken off the printer by the
accounting person. This was in OS/MVT days, and there was no TSO on that
system.
Post by Bill Wilkie
Bill
________________________________
Sent: Friday, September 15, 2017 7:21 PM
Subject: Re: Would encryption have prevented known major breaches?
I have to keep harping on this. The looming EU regulation on hacking is a
potentially huge legal liability. You cannot defend yourself in court by
arguing that you hire the best people. You can defend yourself only by
showing that the hacked data was encrypted.
.
.
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
-----Original Message-----
Sent: Friday, September 15, 2017 12:16 PM
Subject: (External):Re: Would encryption have prevented known major breaches?
Hiring competent people. That's so 20th-century. Get with the program, man!
On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
Post by Tom Brennan
Post by John McKown
IMO, encrypting data is a very good defense. Another good defense
is hiring competent people rather than inexpensive people and
giving them
the
Post by Tom Brennan
Post by John McKown
time to design, code, and test their solutions. I don't have
statistics, but many attacks are based on coding errors such as the
infamous "SQL Injection" attacks. On the almost hilarious attacks
which succeed
because
Post by Tom Brennan
Post by John McKown
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin".
Of course, the people & time requirements that I mentioned "cost too
much"
Post by Tom Brennan
Post by John McKown
and
"delay time to market". Today's world is based on think up
something in the morning, design over lunch, create before dinner,
ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
https://nam04.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576&
data=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f
0771%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%
7C636411001169882688&sdata=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4Q
ugDNJVVHCc%3D&reserved=0
That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bill Wilkie
2017-09-17 18:58:54 UTC
Permalink
Raw Message
John:


I worked in a shop where we did the same thing. The biggest problem we had was that we put labels on the disk in the center, and after a while the labels would fly off and they stuck between platters and screwed up the mechanism. But they were secure. Even WE couldn't read them. At that same shop we used 3420 POTTER tape drives with small tapes and large block sizes that SUCKED the tapes off the reels because you couldn't find an UNWRINKLED piece of tape to write a large block.


When I started out in operations, the Payroll guy would come into the computer room with his payroll tapes, guard them with his life while creating the payroll, then take all of the tapes and stand by the printer while the reports and checks were being cut. Nobody was allowed near him. Then, as soon as he was done, he would take the old payroll master files, remove the external labels and put the tapes on the scratch pile and leave. Needles to say the operators and DEBE were busy for the rest of the day.


And speaking of DEBE, I worked at one place where we actually had to log the start and end computer meter time for each shift. If you didn't log about 6 hours, they thought you were goofing off and you got called in. Most of the time on third shift when you started at midnight, you were done by 1:00 AM because everything bombed, but when you didn't move the meter by about 6 hours, you got in trouble. So....... most of the operators would start DEBE which as you know just looped till you cancelled it. Those guys were told they did a GREAT job. I refused to do it and got called on the carpet because I only logged about 2 hours. These companies had to spend MILLIONS and produced nothing. Ah ,,,,,,,the good old days.


I figured I could write jobs that abended just as well so I went into programming. I couldn't even SPELL programmer but now I are one! LOL!


Bill


From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of John McKown <***@GMAIL.COM>
Sent: Friday, September 15, 2017 7:42 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Would encryption have prevented known major breaches?
Post by Bill Wilkie
What if your data was encrypted, you read it into a sort, put the sort
output to a data set where it was NOT encrypted, and someone copied it? Or,
they got it from sort work areas that were left on disk and not erased?
Does that count?
I was told of a company, back in the 3330 days, where the accounting dept
had their own set of 3330 disk packs. All their data & their temporary data
sets were on these packs. When the "secure" accounting cycle was running,
a person from the department brought those pack down. The operators removed
the normal temporary storage disks, then mounted the accounting data & work
disks. When the cycle ended, the department person took the packs back to
the accounting dept and locked them up in a safe. Now that was fairly
secure. Oh, and the output was actually taken off the printer by the
accounting person. This was in OS/MVT days, and there was no TSO on that
system.
Post by Bill Wilkie
Bill
________________________________
Sent: Friday, September 15, 2017 7:21 PM
Subject: Re: Would encryption have prevented known major breaches?
I have to keep harping on this. The looming EU regulation on hacking is a
potentially huge legal liability. You cannot defend yourself in court by
arguing that you hire the best people. You can defend yourself only by
showing that the hacked data was encrypted.
.
.
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
-----Original Message-----
Sent: Friday, September 15, 2017 12:16 PM
Subject: (External):Re: Would encryption have prevented known major breaches?
Hiring competent people. That's so 20th-century. Get with the program, man!
On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
Post by Tom Brennan
Post by John McKown
IMO, encrypting data is a very good defense. Another good defense
is hiring competent people rather than inexpensive people and
giving them
the
Post by Tom Brennan
Post by John McKown
time to design, code, and test their solutions. I don't have
statistics, but many attacks are based on coding errors such as the
infamous "SQL Injection" attacks. On the almost hilarious attacks
which succeed
because
Post by Tom Brennan
Post by John McKown
"whomever" didn't bother to configure the security on some piece of
equipment, and left the administrator credentials as "admin/admin".
Of course, the people & time requirements that I mentioned "cost too
much"
Post by Tom Brennan
Post by John McKown
and
"delay time to market". Today's world is based on think up
something in the morning, design over lunch, create before dinner,
ship the next morning.
Did you mention admin/admin because of this news report, or just
coincidence?
https://nam04.safelinks.protection.outlook.com/?url=
http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576&
data=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f
0771%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%
7C636411001169882688&sdata=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4Q
ugDNJVVHCc%3D&reserved=0
That was the reason. I just couldn't remember if it was Equifax or
something else in the news recently; and I was too lazy to double check.
--
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jack J. Woehr
2017-09-17 21:38:27 UTC
Permalink
Raw Message
Okay, I have the answer to the Equifax question.

I obtained the answer by the simple act of freezing my records on all three services:

Experian and Transunion: Had to jump through many verification hoops, answer trick questions.

Equifax: One simple basic info screen and I'm the owner of my account freeze.

Reveals everything we need to know about the breach, don't you think?
--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-09-15 19:36:46 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
I have to keep harping on this. The looming EU regulation on hacking is a
potentially huge legal liability. You cannot defend yourself in court by
arguing that you hire the best people. You can defend yourself only by
showing that the hacked data was encrypted.
​I think that more than encryption would need to be shown​. I'm thinking
that the algorithm must be "robust" (or whatever word the crypto people
use). If not, then let's just use ROT13. Oh, and you'd best be sure that
the passphrase, digital cert, etc is properly secured. It doesn't do any
good to encrypt a file and have the decryption key be easily found.
Post by Jesse 1 Robinson
.
.
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
--
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-09-15 20:14:32 UTC
Permalink
Raw Message
I think that more than encryption would need to be shown. I'm thinking
that the algorithm must be "robust" (or whatever word the crypto people
use). If not, then let's just use ROT13.
It's always best to use double ROT13 for defence in depth.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2017-09-15 20:34:23 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
I have to keep harping on this. The looming EU regulation on hacking is a potentially huge legal liability. You cannot defend yourself in court by arguing that you hire the best people. You can defend yourself only by showing that the hacked data was encrypted.
Sure, and that IS worth repeating. GDPR is going to be a bus that hits a few folks before the even know it exists, I suspect.

I assume the point of "hire competent people" was "because they'll be smart enough not to use admin/admin for the management system logon". While "competent" doesn't necessarily imply doing the right thing all the time, using admin/admin definitely precludes the use of the term "competent", I submit!

...phsiii

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Phil Smith
2017-09-17 22:37:35 UTC
Permalink
Raw Message
Post by Jack J. Woehr
Okay, I have the answer to the Equifax question.
Experian and Transunion: Had to jump through many verification hoops, answer trick questions.
Equifax: One simple basic info screen and I'm the owner of my account freeze.
Reveals everything we need to know about the breach, don't you think?
Ouch. True, but you missed Innovis-the fourth, soon (I expect) to be one of the Big Three.

A kinder interpretation is that EFX decided that they'd pissed people off enough already, and should make it easy to freeze-they also stopped charging for it even in states like mine where they're allowed to do so. Innovis also doesn't charge, but I expect that's because they're relatively small, can't afford to irritate people. Not saying that EFX deserves this interpretation, just sayin' that it's possible.

...phsiii

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Beverly Caldwell
2017-09-18 15:50:41 UTC
Permalink
Raw Message
I encrypt my SSN by making up a new one every time some ahole asks for it.
Post by Jack J. Woehr
Post by Jack J. Woehr
Okay, I have the answer to the Equifax question.
I obtained the answer by the simple act of freezing my records on all
Experian and Transunion: Had to jump through many verification hoops,
answer trick questions.
Post by Jack J. Woehr
Equifax: One simple basic info screen and I'm the owner of my account
freeze.
Post by Jack J. Woehr
Reveals everything we need to know about the breach, don't you think?
Ouch. True, but you missed Innovis-the fourth, soon (I expect) to be one of the Big Three.
A kinder interpretation is that EFX decided that they'd pissed people off
enough already, and should make it easy to freeze-they also stopped
charging for it even in states like mine where they're allowed to do so.
Innovis also doesn't charge, but I expect that's because they're relatively
small, can't afford to irritate people. Not saying that EFX deserves this
interpretation, just sayin' that it's possible.
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...