date:20190512

I believe concatenation now uses the largest blksize, not the first one.   Not 
sure about LRECL

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

Re: Concatenating VB and FB ?

2019-05-12 Thread Chris Hoelscher

I think it's fair to say ... the results will be  variable

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Sunday, May 12, 2019 11:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Concatenating VB and FB ?

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.idad400%2Fd4394b.htmdata=02%7C01%7Cchoelscher%40humana.com%7Caffdbb292a924709276408d6d74f2934%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C636933132321402330sdata=nVHZbWmnyyG5gOsrzGsgyQ4kjxtfvTok0CJTNZAFAwM%3Dreserved=0

It uses the DCB of the FIRST DSN in the concatenation.
If F(B), then each block must be a multiple of the LRECL of the First DSN.  
Pretty sure the VB won't be.  And the length fields would be read as data.
If V(B), then each record cannot exceed cannot exceed the LRECL of the First 
DSN.  And the first bytes of a F DSN would be treated as the length.

On Sun, May 12, 2019 at 9:35 PM Tim Hare  wrote:
>
> I seem to be finding different answers on this.
>
> A vendor used to ship some files as PDSes with RECFM=FB and LRECL=80 (BLKSIZE 
> 23440).   User-customized members at this shop were put in a different PDS, 
> with the same attributes, and concatenated in cataloged procedures,  ahead of 
> the vendor's libraries.  Pretty standard practice I'm sure most are familiar 
> with.
>
> Suddenly, because (I'm told) of a merging of code bases at the vendor, their 
> PDSes are now RECFM=VB and LRECL=2044 (BLKSIZE 27998) !   My instincts tell 
> me this isn't going to work well, but with changes in concatenation of 
> libraries over the course of my career I'm not sure.Here's what I think:  
> because of the "new" rule where the largest BLKSIZE sets the buffer size, 
> we'll be OK for reading the blocks (23440 fits into 27998)  but  when we try 
> to read a member from the VB library, the RDWs are going to mess things up.
>
> I have tried searching for the answer,  but haven't, apparently, found the 
> right source yet.
>
> What say you all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability, sex,
sexual orientation, gender identity, or religion. Humana Inc. and its 
subsidiaries do not
exclude people or treat them differently because of race, color, national 
origin, age,
disability, sex, sexual orientation, gender identity, or religion.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.

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

Re: Concatenating VB and FB ?

2019-05-12 Thread Mike Schwab

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/d4394b.htm

It uses the DCB of the FIRST DSN in the concatenation.
If F(B), then each block must be a multiple of the LRECL of the First
DSN.  Pretty sure the VB won't be.  And the length fields would be
read as data.
If V(B), then each record cannot exceed cannot exceed the LRECL of the
First DSN.  And the first bytes of a F DSN would be treated as the
length.

On Sun, May 12, 2019 at 9:35 PM Tim Hare  wrote:
>
> I seem to be finding different answers on this.
>
> A vendor used to ship some files as PDSes with RECFM=FB and LRECL=80 (BLKSIZE 
> 23440).   User-customized members at this shop were put in a different PDS, 
> with the same attributes, and concatenated in cataloged procedures,  ahead of 
> the vendor's libraries.  Pretty standard practice I'm sure most are familiar 
> with.
>
> Suddenly, because (I'm told) of a merging of code bases at the vendor, their 
> PDSes are now RECFM=VB and LRECL=2044 (BLKSIZE 27998) !   My instincts tell 
> me this isn't going to work well, but with changes in concatenation of 
> libraries over the course of my career I'm not sure.Here's what I think:  
> because of the "new" rule where the largest BLKSIZE sets the buffer size, 
> we'll be OK for reading the blocks (23440 fits into 27998)  but  when we try 
> to read a member from the VB library, the RDWs are going to mess things up.
>
> I have tried searching for the answer,  but haven't, apparently, found the 
> right source yet.
>
> What say you all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: ind$file - omvs copy equivalent

I don't understand why the OP wants to receive it to USS and then copy it to an 
MVS dataset when they could run FTP under TSO and receive the XMI file directly?

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

Re: SMS ACS Routine Decompiler

I would have assumed that "SELECT WHEN" would be processed into different 
things internally than "IF/THEN/ELSE",  but your evidence would imply 
otherwise... it implies that "SELECT WHEN" is perhaps pre-processed into 
"IF/THEN/ELSE" statements before "compiling".  Either that, or someone tried to 
write one themselves and it wasn't very good 

I wonder if IBM has such a tool?  If they do, perhaps your client can convince 
IBM of the need to help them out?  I know we got some APF rebuilt by IBM one 
time, after libraries were lost.

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

Concatenating VB and FB ?

I seem to be finding different answers on this.

A vendor used to ship some files as PDSes with RECFM=FB and LRECL=80 (BLKSIZE 
23440).   User-customized members at this shop were put in a different PDS, 
with the same attributes, and concatenated in cataloged procedures,  ahead of 
the vendor's libraries.  Pretty standard practice I'm sure most are familiar 
with.

Suddenly, because (I'm told) of a merging of code bases at the vendor, their 
PDSes are now RECFM=VB and LRECL=2044 (BLKSIZE 27998) !   My instincts tell me 
this isn't going to work well, but with changes in concatenation of libraries 
over the course of my career I'm not sure.Here's what I think:  because of 
the "new" rule where the largest BLKSIZE sets the buffer size, we'll be OK for 
reading the blocks (23440 fits into 27998)  but  when we try to read a member 
from the VB library, the RDWs are going to mess things up.   

I have tried searching for the answer,  but haven't, apparently, found the 
right source yet.

What say you all?

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

Re: mainframe hacking "success stories"?

Let’s ask Microsoft about mainframe security. They probably know more. It’s 
really pretty simple. If it was easy to hack the mainframe, why isn’t it being 
hacked? That’s where the real money is. That’s where trillions of dollars are 
transferred daily.
Now I remember why I lurked. Too many experts who aren’t.

Sent from Yahoo Mail for iPhone

On Sunday, May 12, 2019, 8:42 PM, Phil Smith III  wrote:

Bill Johnson posted a couple more links to mainframe blog posts from a 
mainframe vendor-more asking the barber if you need a shave; but even ignoring 
that, you don't appear to have actually read the articles, Bill.

The first one 

  says IBM Z is more secure because it's less common. That's not inherent 
security; that's like saying your car is less vulnerable because you park it 
far from the madding crowd. It may be *attacked* less, but that doesn't make it 
inherently more *secure*.

The second article 
  cites a 
bunch of fun statistics, including repeating that many large enterprises use 
them. Again, that says nothing about superior technology or security: the 
L-word (legacy) can entirely explain this. It doesn't *have* to, but you're 
just not coming up with any evidence to support your position, sir.

You also asked:

> Can you provide evidence that says non mainframe platforms are as secure or 
> more secure than the mainframe? 

I'm not the one making claims about one technology being gooderT than another: 
I'm merely suggesting that there's no evidence to support your assertion that 
IBM Z is more secure. Asking for support of an unsubstantiated assertion is 
always reasonable-otherwise I can claim the moon is made of green cheese and 
expect you to believe it, right?

.phsiii

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

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

Re: mainframe hacking "success stories"?

I forgot, the mainframe experts can’t be trusted.

Sent from Yahoo Mail for iPhone

On Sunday, May 12, 2019, 8:42 PM, Phil Smith III  wrote:

Bill Johnson posted a couple more links to mainframe blog posts from a 
mainframe vendor-more asking the barber if you need a shave; but even ignoring 
that, you don't appear to have actually read the articles, Bill.

The first one 

  says IBM Z is more secure because it's less common. That's not inherent 
security; that's like saying your car is less vulnerable because you park it 
far from the madding crowd. It may be *attacked* less, but that doesn't make it 
inherently more *secure*.

The second article 
  cites a 
bunch of fun statistics, including repeating that many large enterprises use 
them. Again, that says nothing about superior technology or security: the 
L-word (legacy) can entirely explain this. It doesn't *have* to, but you're 
just not coming up with any evidence to support your position, sir.

You also asked:

> Can you provide evidence that says non mainframe platforms are as secure or 
> more secure than the mainframe? 

I'm not the one making claims about one technology being gooderT than another: 
I'm merely suggesting that there's no evidence to support your assertion that 
IBM Z is more secure. Asking for support of an unsubstantiated assertion is 
always reasonable-otherwise I can claim the moon is made of green cheese and 
expect you to believe it, right?

.phsiii

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

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

Re: mainframe hacking "success stories"?

2019-05-12 Thread Phil Smith III

Bill Johnson posted a couple more links to mainframe blog posts from a 
mainframe vendor-more asking the barber if you need a shave; but even ignoring 
that, you don't appear to have actually read the articles, Bill.

 

The first one 

  says IBM Z is more secure because it's less common. That's not inherent 
security; that's like saying your car is less vulnerable because you park it 
far from the madding crowd. It may be *attacked* less, but that doesn't make it 
inherently more *secure*.

 

The second article 
  cites a 
bunch of fun statistics, including repeating that many large enterprises use 
them. Again, that says nothing about superior technology or security: the 
L-word (legacy) can entirely explain this. It doesn't *have* to, but you're 
just not coming up with any evidence to support your position, sir.

 

You also asked:

> Can you provide evidence that says non mainframe platforms are as secure or 
> more secure than the mainframe? 

 

I'm not the one making claims about one technology being gooderT than another: 
I'm merely suggesting that there's no evidence to support your assertion that 
IBM Z is more secure. Asking for support of an unsubstantiated assertion is 
always reasonable-otherwise I can claim the moon is made of green cheese and 
expect you to believe it, right?

 

.phsiii


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

Re: mainframe hacking "success stories"?

li...@akphs.com (Phil Smith III) writes:
> https://en.wikipedia.org/wiki/Xeon_Phi
>
> Up to 72 cores per chip, so up to 144 threads per socket. On an
> eight-socket motherboard, that's, um, a lot.

they announced they are discontinue Phi
https://www.extremetech.com/extreme/290963-intel-quietly-kills-off-xeon-phi

... but latest production server XEON announced last month have up to 56
cores per socket and up to eight sockets. from recent post
http://www.garlic.com/~lynn/2019c.html#9

Most recent announce (last month) 56-core (processors) Platinum 9200
https://www.anandtech.com/show/14182/hands-on-with-the-56core-xeon-platinum-9200-cpu-intels-biggest-cpu-package-ever
https://www.servethehome.com/intel-xeon-platinum-9200-formerly-cascade-lake-ap-launched/
https://www.storagereview.com/intel_releases_second_generation_intel_xeon_scalable_cpus
https://www.hpcwire.com/2019/04/02/intel-launches-second-gen-scalable-xeons-with-up-to-56-cores/

"We are delivering 8-core Xeons all the way up to 56-core, the highest
core count we've ever delivered on Xeon," said Shenoy. "We are
delivering support for 1- 2- 4- and 8-socket glueless support for Xeon."

... snip ...

aka eight socket, 56/socket, max 448 cores-processors sharing same
memory providing large number of TIPS (1000s BIPS) computation power in
single system.

IBM sold off its (intel) server business about the time the server chip
makers started saying that they are shipping over half their chips
directly to the big cloud megadatacenters ... for going on two decades,
the big cloud megadatacenters claim that they assemble their own servers
at 1/3rd the cost of brand name servers (aka cloud operators view
dataprocessing as a cost rather than profit).

big cloud megadatacenters have so radically reduced their server system
cost to a point that power & cooling have become major cost ... and they
are focusing on total costs, including electricity/cooling cost per
computation ... even getting special chip versions that improve
computation electricity/cooling costs. However, the highest performance
server chips can double the power reqirements for less than twice than
the computation throughput.

a big cloud megadatacenter will have over half million blade systems
with millions of processors, being operated by 80-120 people (enormous
automation) ... doubling the number of systems (for total computational
power), can easily be net financial win, for optimal computation per
power (and large cloud operations have several such
megadatacenters around the world).

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

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

Re: mainframe hacking "success stories"?

More asserting.
https://blog.syncsort.com/2018/09/mainframe/mainframes-secure-even-more-secure/ 

Sent from Yahoo Mail for iPhone

On Sunday, May 12, 2019, 2:26 PM, Phil Smith III  wrote:

Charles Mills wrote, in part:

>The mainframe seems to me to have also some "architectural" advantages. It

>seems to support a denser "clustering." It does not seem to me that there is

>anything in the Windows/Linux world that duplicates the advantages of 100 or

>so very-closely-coupled (sharing all main storage potentially) CPUs. Sure,

>you can link a thousand Windows or Linux 8-way servers on a super-fast net,

>and it is fine for some things -- incredibly powerful for some of them, but

>it seems there are some things the mainframe architecture is inherently

>better at.

Actually, various RISC servers such as SPARC have servers with hundreds of 
processors sharing memory; even Intel machines do. Xeon Phi, for example:

https://en.wikipedia.org/wiki/Xeon_Phi

Up to 72 cores per chip, so up to 144 threads per socket. On an eight-socket 
motherboard, that's, um, a lot.

And I'm not sure I buy the value of this on IBM Z anyway: what's the largest 
single image you know of in terms of CPUs? Yes, a z14 can have 170, but nobody 
runs that way. It's like owning a Bugatti and driving it downtown: you've got 
the biggest on the block, but you can't use most of its capabilities.

Friend's comment along these lines:
It's a mug's game to obsess about the biggest possible model in a product line, 
as most people don't need or buy them (it isn't to Z advantage anyway).  There 
is a price premium for the "biggest box" and it's less flexible, and more of a 
single point of failure or single planned outage. General practice is to buy 
boxes that are big enough with room to spare of course, add more as needed, and 
run modern applications that don't need a monolithic single system in the first 
place.

And Bill Johnson wrote:

>I'm a huge fan of the mainframe. And security is not the ONLY reason for 
>staying on it. But is a major reason large companies do.

Assertion without evidence, easy to ignore. I tend to share this bias but have 
no compelling evidence that IBM Z in general, or even z/OS specifically, is 
inherently more secure than another platform. It may tend to be, by tradition 
and history-that is, typical mainframe security posture and change methodology 
leads to greater security-but that's not inherent in the platform. Can you 
support this claim?

Your article 

 , BTW, is (a) from IBM ("never ask the barber if you need a shave") and (b) 
proves my point more than yours:

The mainframe owes much of its popularity and longevity to its inherent 
reliability and stability, a result of careful and steady technological 
advances that have been made since the introduction of the System/360T in 1964. 
No other computer architecture can claim as much continuous, evolutionary 
improvement, while maintaining compatibility with previous releases.

The first sentence says "This has a long history and is therefore good", which 
of course makes no sense. The second says "compatibility [legacy!] is what 
makes this good".

It goes on to make laughable assertions:

Many of today's busiest Web sites store their production databases on a 
mainframe host. 

Seriously? "busiest"? Like, say, Google, Instagram, Facebook, Pinterest, 
Amazon, Wal-Mart? I don't think so. (Yes, Wal-Mart uses IBM Z but their backend 
is Teradata.) IBM really needs to stop saying dumb things like this, as it just 
makes the rest of the world snicker.

Or:

Corporations use mainframes for applications that depend on scalability and 
reliability. For example, a banking institution could use a mainframe to host 
the database of its customer accounts, for which transactions can be submitted 
from any of thousands of ATM locations worldwide.

Nothing inherent to IBM Z there. Those ATMs aren't running on IBM Z, either, eh?

Again, apply some critical thinking to the claims. They just don't stand up. 20 
years ago, perhaps. Today, not so much. And this makes me sad, both for the 
platform and for IBM, who seem to be denying the reality.

.phsiii

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

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

Re: mainframe hacking "success stories"?

Asserting with evidence.
https://blog.syncsort.com/2018/06/mainframe/9-mainframe-statistics/ 

Sent from Yahoo Mail for iPhone

On Sunday, May 12, 2019, 2:26 PM, Phil Smith III  wrote:

Charles Mills wrote, in part:

>The mainframe seems to me to have also some "architectural" advantages. It

>seems to support a denser "clustering." It does not seem to me that there is

>anything in the Windows/Linux world that duplicates the advantages of 100 or

>so very-closely-coupled (sharing all main storage potentially) CPUs. Sure,

>you can link a thousand Windows or Linux 8-way servers on a super-fast net,

>and it is fine for some things -- incredibly powerful for some of them, but

>it seems there are some things the mainframe architecture is inherently

>better at.

Actually, various RISC servers such as SPARC have servers with hundreds of 
processors sharing memory; even Intel machines do. Xeon Phi, for example:

https://en.wikipedia.org/wiki/Xeon_Phi

Up to 72 cores per chip, so up to 144 threads per socket. On an eight-socket 
motherboard, that's, um, a lot.

And I'm not sure I buy the value of this on IBM Z anyway: what's the largest 
single image you know of in terms of CPUs? Yes, a z14 can have 170, but nobody 
runs that way. It's like owning a Bugatti and driving it downtown: you've got 
the biggest on the block, but you can't use most of its capabilities.

Friend's comment along these lines:
It's a mug's game to obsess about the biggest possible model in a product line, 
as most people don't need or buy them (it isn't to Z advantage anyway).  There 
is a price premium for the "biggest box" and it's less flexible, and more of a 
single point of failure or single planned outage. General practice is to buy 
boxes that are big enough with room to spare of course, add more as needed, and 
run modern applications that don't need a monolithic single system in the first 
place.

And Bill Johnson wrote:

>I'm a huge fan of the mainframe. And security is not the ONLY reason for 
>staying on it. But is a major reason large companies do.

Assertion without evidence, easy to ignore. I tend to share this bias but have 
no compelling evidence that IBM Z in general, or even z/OS specifically, is 
inherently more secure than another platform. It may tend to be, by tradition 
and history-that is, typical mainframe security posture and change methodology 
leads to greater security-but that's not inherent in the platform. Can you 
support this claim?

Your article 

 , BTW, is (a) from IBM ("never ask the barber if you need a shave") and (b) 
proves my point more than yours:

The mainframe owes much of its popularity and longevity to its inherent 
reliability and stability, a result of careful and steady technological 
advances that have been made since the introduction of the System/360T in 1964. 
No other computer architecture can claim as much continuous, evolutionary 
improvement, while maintaining compatibility with previous releases.

The first sentence says "This has a long history and is therefore good", which 
of course makes no sense. The second says "compatibility [legacy!] is what 
makes this good".

It goes on to make laughable assertions:

Many of today's busiest Web sites store their production databases on a 
mainframe host. 

Seriously? "busiest"? Like, say, Google, Instagram, Facebook, Pinterest, 
Amazon, Wal-Mart? I don't think so. (Yes, Wal-Mart uses IBM Z but their backend 
is Teradata.) IBM really needs to stop saying dumb things like this, as it just 
makes the rest of the world snicker.

Or:

Corporations use mainframes for applications that depend on scalability and 
reliability. For example, a banking institution could use a mainframe to host 
the database of its customer accounts, for which transactions can be submitted 
from any of thousands of ATM locations worldwide.

Nothing inherent to IBM Z there. Those ATMs aren't running on IBM Z, either, eh?

Again, apply some critical thinking to the claims. They just don't stand up. 20 
years ago, perhaps. Today, not so much. And this makes me sad, both for the 
platform and for IBM, who seem to be denying the reality.

.phsiii

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

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

Re: mainframe hacking "success stories"?

0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) writes:
> Until the mid-1990s, mainframes provided the only acceptable meansof
> handling the data processing requirements of a large business. These
> requirementswere then (and are often now) based on running large and
> complex programs,such as payroll and general ledger processing.

late 80s through early 90s there were lots of news stories about moving
off mainframes to "killer micros" ... and IBM has gone into the red. IBM
was being reorganized into the 13 "baby blues" in preparation for
breaking up the company ... when new CEO was brought in and reversed the
breakup.

late 70s & early 80s, I was involved in the original SQL/relational
implementation, System/R and the technology transfer to Endicott for
SQL/DS ("under the radar", while corporation was preoccupied with the
official next generation DBMS, "EAGLE"). When "EAGLE" finally imploded,
there was request about how fast could System/R be ported to MVS
... which was eventually released as DB2, originally for decision
support only.

Late 80s, was doing RS/6000 high availability HA/6000, but I quickly
change the name to HA/CMP because doing cluster scaleup,
technical/scientific with national labs and commercial with RDBMS
vendors. I'm also asked to write a section for the corporate strategic
continuous availability document. The section gets pulled when both
Rochester (AS/400) and POK (mainframe) complained they can't meet the
requirements.

Post about Jan1992 meeting in Ellison's conference room on 128-way
http://www.garlic.com/~lynn/95.html#13 one of the Oracle executives in
the room, said he was the major person in STL handling the tech transfer
to STL for DB2. Within a couple weeks of the Ellison meeting, cluster
scaleup is transferred, announced as supercomputer for
technical/scientific *ONLY*, and we are told we can't work on anything
with more than four processors. A few months later we leave. Part of the
issue was that mainframe DB2 were complaining that if I was allowed to
continue, it would be at least 5yrs ahead of what they were doing.

Later two of the oracle people in the Ellison meeting have left and are
at small client/server startup responsible for somehting called
"commerce server" and we are brought in as consultants because they want
to do payment transactions on the server, the startup had also invented
this technology they call "SLL", the result is now frequently called
"electronic commerce". For having done "electronic commerce", get
invited into lots of other financial industry activities.

In the mid/late 90s, lots of financial was overruning their (cobal batch
mainframe) overnight financial settlement window (globalization cutting
window size and increasing workload). Numerous were spending billions on
"straight through processing" (each transaction is settled as it
executes), leveraging huge parallelization with large number of "killer
micros".  Turns out that they were using parallelization libraries that
introduced 100 times the overhead of cobol batch. They were warned
(including by me) about the problem, which they continued to ignore
... until large scale pilots went down spectacularly in flames (overhead
totally swamping anticipated increase in throughput with large numbers
of killer micros)

Decade later, I was involved in taking some technology to financial
industry groups, that had allowed high level business rules to be
specified ... that then were decomposed into fine-grain SQL statements
(easily parallelized). The implementation enormously reduced the
development and maintenance effort for large, complex business
operations ... and heavily leveraged vendor efforts in enormous
throughput for large clustered & parallel RDBMS (including IBMs). Was
able to demonstrate enormously complex business processing with many
times the throughput of any existing implementations. Initially it had
high level of acceptance, but then ran into brick wall. We were
eventually told that lots of the executives still bore the scars from
the enormous parallelization failures in the 90s and it would take all
of them retiring before it was tried again.

trivia: 2000, did some performance work on 450k statement cobol program
that did overnight batch settlement running every night on >40
max. configured mainframes (number of mainframes required to finish in
the overnight batch window).

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

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

Re: mainframe hacking "success stories"?

2019-05-12 Thread Phil Smith III

Charles Mills wrote, in part:

>The mainframe seems to me to have also some "architectural" advantages. It

>seems to support a denser "clustering." It does not seem to me that there is

>anything in the Windows/Linux world that duplicates the advantages of 100 or

>so very-closely-coupled (sharing all main storage potentially) CPUs. Sure,

>you can link a thousand Windows or Linux 8-way servers on a super-fast net,

>and it is fine for some things -- incredibly powerful for some of them, but

>it seems there are some things the mainframe architecture is inherently

>better at.

Actually, various RISC servers such as SPARC have servers with hundreds of 
processors sharing memory; even Intel machines do. Xeon Phi, for example:

https://en.wikipedia.org/wiki/Xeon_Phi

Up to 72 cores per chip, so up to 144 threads per socket. On an eight-socket 
motherboard, that's, um, a lot.

And I'm not sure I buy the value of this on IBM Z anyway: what's the largest 
single image you know of in terms of CPUs? Yes, a z14 can have 170, but nobody 
runs that way. It's like owning a Bugatti and driving it downtown: you've got 
the biggest on the block, but you can't use most of its capabilities.

Friend's comment along these lines:
It's a mug's game to obsess about the biggest possible model in a product line, 
as most people don't need or buy them (it isn't to Z advantage anyway).  There 
is a price premium for the "biggest box" and it's less flexible, and more of a 
single point of failure or single planned outage. General practice is to buy 
boxes that are big enough with room to spare of course, add more as needed, and 
run modern applications that don't need a monolithic single system in the first 
place.

And Bill Johnson wrote:

>I'm a huge fan of the mainframe. And security is not the ONLY reason for 
>staying on it. But is a major reason large companies do.

Assertion without evidence, easy to ignore. I tend to share this bias but have 
no compelling evidence that IBM Z in general, or even z/OS specifically, is 
inherently more secure than another platform. It may tend to be, by tradition 
and history-that is, typical mainframe security posture and change methodology 
leads to greater security-but that's not inherent in the platform. Can you 
support this claim?

Your article 

 , BTW, is (a) from IBM ("never ask the barber if you need a shave") and (b) 
proves my point more than yours:

The mainframe owes much of its popularity and longevity to its inherent 
reliability and stability, a result of careful and steady technological 
advances that have been made since the introduction of the System/360T in 1964. 
No other computer architecture can claim as much continuous, evolutionary 
improvement, while maintaining compatibility with previous releases.

The first sentence says "This has a long history and is therefore good", which 
of course makes no sense. The second says "compatibility [legacy!] is what 
makes this good".

It goes on to make laughable assertions:

Many of today's busiest Web sites store their production databases on a 
mainframe host. 

Seriously? "busiest"? Like, say, Google, Instagram, Facebook, Pinterest, 
Amazon, Wal-Mart? I don't think so. (Yes, Wal-Mart uses IBM Z but their backend 
is Teradata.) IBM really needs to stop saying dumb things like this, as it just 
makes the rest of the world snicker.

Or:

Corporations use mainframes for applications that depend on scalability and 
reliability. For example, a banking institution could use a mainframe to host 
the database of its customer accounts, for which transactions can be submitted 
from any of thousands of ATM locations worldwide.

Nothing inherent to IBM Z there. Those ATMs aren't running on IBM Z, either, eh?

Again, apply some critical thinking to the claims. They just don't stand up. 20 
years ago, perhaps. Today, not so much. And this makes me sad, both for the 
platform and for IBM, who seem to be denying the reality.

.phsiii

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

Re: mainframe hacking "success stories"?

0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) writes:
> Right, my articles are flawed. Yet, real mainframe hacks can be
> counted on one hand. And many of those are hypothetical or were
> achieved via someone hacking a laptop (MSFT) or acquiring a valid
> userid because of someone’s stupidity. If hackers wanted to go where
> the money is, and banks would be the place, they would target the
> mainframe since nearly every bank in the world uses one. 

one of the hack story issues is those using mainframes for critical
systems (especially financial) do quite a bit to keep such things
out of the news

I was in financial sector CIP meetings in white house annex
https://en.wikipedia.org/wiki/Critical_infrastructure_protection and
major issues was to make sure that the financial ISAC
https://www.fsisac.com/
wasn't subject to FOIA
https://en.wikipedia.org/wiki/Freedom_of_Information_Act_(United_States)

Was also brought in to help wordsmith some cal. state legislation. At
the time they were working on electronic signature, data breach
notification, and opt-in personal information sharing. There were
participants that were heavily into privacy issues and had done detailed
consumer/public privacy studies. The number one issue was "identity
theft", primarily information leaking used for fraudulent financial
transactions. The problem at the time was little being done about the
leaks & breaches (other than obscuring source of the problem). The issue
is normally entities take security issues in self-interest, in the case
of most of the information leaks/breaches, the institutions weren't at
risk, it was the public. It was hoped that publicity from breach
notifications might motivate corrective action.

Since then then there have been numerous federal data breach
notification bills introduced ... about half similar to the
cal. legislation and the other half with requirements that almost never
would be met (eliminating need for majority of breach notifications).

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

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

Re: mainframe hacking "success stories"?

I also have a minor in law enforcement. I was going to be an FBI agent at one 
time. There is no perfect security. But, there are varying degrees of security. 
The security at my bank is better than at my house. Mainframe security is 
better than other platforms. It’s a major selling point.


Sent from Yahoo Mail for iPhone


On Sunday, May 12, 2019, 12:27 PM, ITschak Mugzach  wrote:

Security only mentioned twice in the article, mainly in access control.
None was related to the OS as a secure platform. I agree it has the
potential, but the actual grade in many sites I tested are poor. it returns
me to the fact that security is something cultural and depend on your role.
if you are measured only for availability, why care about security? this is
how many technicians think, not only for mainframes...

A periodic testing of security health (White, Gray or Black box PT) is of
value only to the time of test. and as it take long time to complete, it
might be false finding weeks later as systems are changing all time.

ITschak

On Sun, May 12, 2019 at 6:43 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

>  Can you provide evidence that says non mainframe platforms are as secure
> or more secure than the mainframe? I'll wait in Cleveland as the airport is
> being held hostage to an attack and ransom to return its system files back.
> Cleveland acknowledges for first time Hopkins airport hack involved
> ransomware
>
> |
> |
> |
> |  |  |
>
>  |
>
>  |
> |
> |  |
> Cleveland acknowledges for first time Hopkins airport hack involved rans...
>
> The city did not respond to an email address seeking contact with airport
> officials.
>  |
>
>  |
>
>  |
>
>
>
>
>    On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III <
> li...@akphs.com> wrote:
>
>  You know, I'm as big a fan of the mainframe as anyone. I've used
> mainframes for at least 45 of my 58 years on this planet, have made my
> living off them for almost 40 of those, and continue to do so.
>
>
>
> But the articles Bill Johnson is citing as proof that the mainframe is so
> superior to other platforms are seriously weak, if read with a critical eye.
>
>
>
> For those of us in the mainframe part of the industry, failing to
> recognize that the mainframe is in trouble is beyond folly-it's hastening
> its demise. Every year, more customers migrate away because they can, or at
> least think they can. The real value of the mainframe today is in the
> business logic implemented in billions of lines of COBOL and assembler and
> PL/I and the rest. Reimplementing that from the ground up is what fails
> every time, whether spectacularly (as in, it flat-out doesn't work and has
> to be scrapped) or not (with "only" significant loss of function and/or
> bugs that the folks on the ground must work through with great cost and
> pain).
>
>
>
> We as mainframe fans need to keep our eyes on that ball, and use that
> extremely compelling argument against migration, not wave our hands and say
> "It's gooderT!" and expect that to somehow prevail against the evidence.
>
>
>
> .phsiii
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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




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

Re: mainframe hacking "success stories"?

2019-05-12 Thread ITschak Mugzach

Security only mentioned twice in the article, mainly in access control.
None was related to the OS as a secure platform. I agree it has the
potential, but the actual grade in many sites I tested are poor. it returns
me to the fact that security is something cultural and depend on your role.
if you are measured only for availability, why care about security? this is
how many technicians think, not only for mainframes...

A periodic testing of security health (White, Gray or Black box PT) is of
value only to the time of test. and as it take long time to complete, it
might be false finding weeks later as systems are changing all time.

ITschak

On Sun, May 12, 2019 at 6:43 PM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

>  Can you provide evidence that says non mainframe platforms are as secure
> or more secure than the mainframe? I'll wait in Cleveland as the airport is
> being held hostage to an attack and ransom to return its system files back.
> Cleveland acknowledges for first time Hopkins airport hack involved
> ransomware
>
> |
> |
> |
> |  |  |
>
>  |
>
>  |
> |
> |  |
> Cleveland acknowledges for first time Hopkins airport hack involved rans...
>
> The city did not respond to an email address seeking contact with airport
> officials.
>  |
>
>  |
>
>  |
>
>
>
>
> On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III <
> li...@akphs.com> wrote:
>
>  You know, I'm as big a fan of the mainframe as anyone. I've used
> mainframes for at least 45 of my 58 years on this planet, have made my
> living off them for almost 40 of those, and continue to do so.
>
>
>
> But the articles Bill Johnson is citing as proof that the mainframe is so
> superior to other platforms are seriously weak, if read with a critical eye.
>
>
>
> For those of us in the mainframe part of the industry, failing to
> recognize that the mainframe is in trouble is beyond folly-it's hastening
> its demise. Every year, more customers migrate away because they can, or at
> least think they can. The real value of the mainframe today is in the
> business logic implemented in billions of lines of COBOL and assembler and
> PL/I and the rest. Reimplementing that from the ground up is what fails
> every time, whether spectacularly (as in, it flat-out doesn't work and has
> to be scrapped) or not (with "only" significant loss of function and/or
> bugs that the folks on the ground must work through with great cost and
> pain).
>
>
>
> We as mainframe fans need to keep our eyes on that ball, and use that
> extremely compelling argument against migration, not wave our hands and say
> "It's gooderT!" and expect that to somehow prevail against the evidence.
>
>
>
> .phsiii
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: mainframe hacking "success stories"?

 
Cleveland acknowledges for first time Hopkins airport hack involved ransomware
  Updated Apr 29, 2019;  Posted Apr 29, 2019  
City officials say 95 percent of the flight and baggage screens are operational.
   0 shares   
By Mark Naymik, cleveland.com 
   
CLEVELAND, Ohio – All of last week, Mayor Frank Jackson’s administration 
downplayed the nature of the malfunctions that disabled flight and baggage 
information screens at Cleveland Hopkins International Airport, sources said.

The computer system that run the screens, which went dark last Monday, were 
compromised by a form malware that sought a ransom from the city, multiple 
sources told cleveland.com. Airport officials, however, did not respond to any 
such demands.
 
Contacted Monday about the assertions, Cleveland’s Chief Information Officer 
Donald Phillips told cleveland.com that the city did not intend to mislead the 
public – and the media - about the problem.

“We were giving you what we knew at the time,” he said.

Phillips acknowledged that he considers the malware involved to be form of 
ransomware. He said the city was asked by the malware to respond to an email 
address for more information about the hack but the city did not respond.

“We never responded and moved on to fix it,” he said.

In public statements last week, Jackson’s administration described the problem 
as a technical issue. The mayor’s office also had declined to even to 
acknowledge that the city contacted the FBI about the case, though the FBI has 
confirmed as much. On Friday, the city said the systems were affected by a form 
of malware, but maintained that did not equate to being hacked.

Chief of Communications Valarie McCall said Monday that the city has a meeting 
at 10 a.m. today with city officials and its “federal partners” and will update 
the public later this afternoon.
 
Phillips said “95 percent” of the system operating the screens was back online.

The malware attack has not affected flights schedules or security operations at 
the airport. The city has denied reports by some media that other systems, such 
as the airport’s payroll and timekeeping, were affected. There is no evidence 
that they were affected by the malware.
 

On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III  
wrote:  
 
 You know, I'm as big a fan of the mainframe as anyone. I've used mainframes 
for at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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

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

Re: mainframe hacking "success stories"?

 Can you provide evidence that says non mainframe platforms are as secure or 
more secure than the mainframe? I'll wait in Cleveland as the airport is being 
held hostage to an attack and ransom to return its system files back.
Cleveland acknowledges for first time Hopkins airport hack involved ransomware

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Cleveland acknowledges for first time Hopkins airport hack involved rans...

The city did not respond to an email address seeking contact with airport 
officials.
 |

 |

 |




On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III  
wrote:  
 
 You know, I'm as big a fan of the mainframe as anyone. I've used mainframes 
for at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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

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

Re: mainframe hacking "success stories"?

2019-05-12 Thread Matt Hogstrom

I generally agree with the assertion below that the value in the mainframe is 
the investment in intellectual property by businesses to develop their core 
logic that supports their business goals.  The mainframe has had, and continues 
to support, superior technology that quite honestly has been replicated on 
distributed over the year (VMware and virtualization to containers and now 
schedulers like K8S).  It has value and it has its shortcomings.   

We need to focus on the continued value and not the “success” of the past.  
We’re on legacy version 4 by my counting.  The original mainframes, then 
distributed technologies (lots of applications written there that are 
standalone), then client server and now cloud as a methodology; not a location, 
not a noun.  The key lesson historically is we never shift everything to the 
next big thing, we blend them, tend them and continue the business on 
successive “strata” of computing evolutions.  If the mainframe is chest 
pounding of past success it’s relevancy to the current and future technologies 
is diminished.

Matt Hogstrom
PGP key 0F143BC1
> On Saturday, May 11, 2019, 7:54 PM, Phil Smith III  wrote:
> 
> 
> For those of us in the mainframe part of the industry, failing to recognize 
> that the mainframe is in trouble is beyond folly-it's hastening its demise. 
> Every year, more customers migrate away because they can, or at least think 
> they can. The real value of the mainframe today is in the business logic 
> implemented in billions of lines of COBOL and assembler and PL/I and the 
> rest. Reimplementing that from the ground up is what fails every time, 
> whether spectacularly (as in, it flat-out doesn't work and has to be 
> scrapped) or not (with "only" significant loss of function and/or bugs that 
> the folks on the ground must work through with great cost and pain).
> 
> 
> 
> We as mainframe fans need to keep our eyes on that ball, and use that 
> extremely compelling argument against migration, not wave our hands and say 
> "It's gooderT!" and expect that to somehow prevail against the evidence.
> 
> 
> 
> .phsiii
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

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

Re: mainframe hacking "success stories"?

 I also worked at a major bank 15 years ago and I can assure you security was 
the major reason we stayed on the MF. 

On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III  
wrote:  
 
 You know, I'm as big a fan of the mainframe as anyone. I've used mainframes 
for at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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

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

Re: mainframe hacking "success stories"?

 Heck with the link.
  Mainframe concepts
| Previous topic |Next topic |Contents |Glossary |Contact z/OS |PDF


Who uses mainframes and why do they do it?

Mainframe concepts

 |
| 
|  |


So, who uses mainframes? Just about everyone has used amainframe computer at 
one point or another. If you ever used an automatedteller machine (ATM) to 
interact with your bank account, you used a mainframe.

Today, mainframe computers play a central role in the daily operationsof most 
of the world's largest corporations. While other forms of computingare used 
extensively in business in various capacities, the mainframe occupiesa coveted 
place in today's e-business environment. In banking,finance, health care, 
insurance, utilities, government, and a multitude ofother public and private 
enterprises, the mainframe computer continues tobe the foundation of modern 
business.

Until the mid-1990s, mainframes provided the only acceptable meansof handling 
the data processing requirements of a large business. These requirementswere 
then (and are often now) based on running large and complex programs,such as 
payroll and general ledger processing.

The mainframe owes much of its popularity and longevity to its 
inherentreliability and stability, a result of careful and steady technological 
advancesthat have been made since the introduction of the System/360™ in 1964. 
No other computerarchitecture can claim as much continuous, evolutionary 
improvement, whilemaintaining compatibility with previous releases.

Because of these design strengths, the mainframe is often used by IT 
organizationsto host the most important, mission-critical applications. 
Theseapplications typically include customer order processing, financial 
transactions,production and inventory control, payroll, as well as many other 
types ofwork.

One common impression of a mainframe's user interface is the 80x24-character 
"greenscreen" terminal, named for the old cathode ray tube (CRT) monitors 
fromyears ago that glowed green. In reality, mainframe interfaces today look 
muchthe same as those for personal computers or UNIX® systems. When a business 
applicationis accessed through a Web browser, there is often a mainframe 
computer performingcrucial functions behind the scenes.

Many of today's busiest Web sites store their production databases on 
amainframe host. New mainframe hardware and software products are ideal forWeb 
transactions because they are designed to allow huge numbers of usersand 
applications to rapidly and simultaneously access the same data 
withoutinterfering with each other. This security, scalability, and reliability 
iscritical to the efficient and secure operation of contemporary 
informationprocessing.

Corporations use mainframes for applications that depend on scalabilityand 
reliability. For example, a banking institution could use a mainframeto host 
the database of its customer accounts, for which transactions canbe submitted 
from any of thousands of ATM locations worldwide.

Businesses today rely on the mainframe to:
   
   - Perform large-scale transaction processing (thousands of transactionsper 
second) 
   - Support thousands of users and application programs concurrently 
accessingnumerous resources
   - Manage terabytes of information in databases
   - Handle large-bandwidth communication

The roads of the information superhighway often lead to a mainframe.
   
   - Mainframe strengths: Reliability, availability, and serviceability   
The reliability, availability, and serviceability (or "RAS")of a computer 
system have always been important factors in data processing.When we say that a 
particular computer system "exhibits RAS characteristics," wemean that its 
design places a high priority on the system remaining in serviceat all times. 
Ideally, RAS is a central design feature of all aspects of acomputer system, 
including the applications.
   - Mainframe strengths: Security   
One of a firm's most valuable resources is its data: Customer lists,accounting 
data, employee information, and so on. This critical data needsto be securely 
managed and controlled, and, simultaneously, made availableto those users 
authorized to see it. The mainframe computer has extensivecapabilities to 
simultaneously share, but still protect, the firm's data amongmultiple users.
   - Mainframe strengths: Scalability   
It has been said that the only constant is change. Nowhere is thatstatement 
more true than in the IT industry. In business, positive resultscan often 
trigger a growth in IT infrastructure to cope with increased demand.The degree 
to which the IT organization can add capacity without disruptionto normal 
business processes or without incurring excessive overhead 
(nonproductiveprocessing) is largely determined by the scalability of the 
particularcomputing platform.
   - Mainframe strength: Continuing compatibility   
Mainframe customers tend to have a very large financial investmentin their 
applications and data.

Re: mainframe hacking "success stories"?

2019-05-12 Thread zMan

No link there.

On Sun, May 12, 2019 at 11:21 AM Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

>  Maybe this link will be more likeable?
> IBM Knowledge Center
>
>
>
> |
> |
> |  |
> IBM Knowledge Center
>
>

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

Re: mainframe hacking "success stories"?

Fixing the link and proving I’m a mainframer at the same time.
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zmainframe/zconc_whousesmf.htm
 


Sent from Yahoo Mail for iPhone


On Saturday, May 11, 2019, 7:54 PM, Phil Smith III  wrote:

You know, I'm as big a fan of the mainframe as anyone. I've used mainframes for 
at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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



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

Re: mainframe hacking "success stories"?

 Maybe this link will be more likeable?
IBM Knowledge Center



| 
| 
|  | 
IBM Knowledge Center


 |

 |

 |




On Saturday, May 11, 2019, 7:54:17 PM EDT, Phil Smith III  
wrote:  
 
 You know, I'm as big a fan of the mainframe as anyone. I've used mainframes 
for at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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

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

Re: mainframe hacking "success stories"?

I’m a huge fan of the mainframe. And security is not the ONLY reason for 
staying on it. But is a major reason large companies do.


Sent from Yahoo Mail for iPhone


On Saturday, May 11, 2019, 7:54 PM, Phil Smith III  wrote:

You know, I'm as big a fan of the mainframe as anyone. I've used mainframes for 
at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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



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

Re: mainframe hacking "success stories"?

Right, my articles are flawed. Yet, real mainframe hacks can be counted on one 
hand. And many of those are hypothetical or were achieved via someone hacking a 
laptop (MSFT) or acquiring a valid userid because of someone’s stupidity. If 
hackers wanted to go where the money is, and banks would be the place, they 
would target the mainframe since nearly every bank in the world uses one. 


Sent from Yahoo Mail for iPhone


On Saturday, May 11, 2019, 7:54 PM, Phil Smith III  wrote:

You know, I'm as big a fan of the mainframe as anyone. I've used mainframes for 
at least 45 of my 58 years on this planet, have made my living off them for 
almost 40 of those, and continue to do so.

 

But the articles Bill Johnson is citing as proof that the mainframe is so 
superior to other platforms are seriously weak, if read with a critical eye.

 

For those of us in the mainframe part of the industry, failing to recognize 
that the mainframe is in trouble is beyond folly-it's hastening its demise. 
Every year, more customers migrate away because they can, or at least think 
they can. The real value of the mainframe today is in the business logic 
implemented in billions of lines of COBOL and assembler and PL/I and the rest. 
Reimplementing that from the ground up is what fails every time, whether 
spectacularly (as in, it flat-out doesn't work and has to be scrapped) or not 
(with "only" significant loss of function and/or bugs that the folks on the 
ground must work through with great cost and pain).

 

We as mainframe fans need to keep our eyes on that ball, and use that extremely 
compelling argument against migration, not wave our hands and say "It's 
gooderT!" and expect that to somehow prevail against the evidence.

 

.phsiii


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



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

Re: DS8000 Simulator

2019-05-12 Thread Benjamin Huntsman

Closest thing is to install the GUI locally and use offline mode if you have 
access to the customer discs.  But that’s just the GUI.  There’s no way to use 
DSCLI without a real DS to connect to.

-Ben

Sent from my iPhone

> On May 11, 2019, at 11:54 PM, Peter  wrote:
> 
> Hi
> 
> Is there a simulator version for DS8K ?
> I want to download and for self learning.
> 
> Peter
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: mainframe hacking "success stories"?