Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Tony Harminc]

On 31 March 2015 at 10:11, John McKown  wrote:

> The fact that programmers are too lazy to use protect keys does not
> make them "worthless". If _I_ were writing APF code which required me
> to store data in _common_ memory (ECSA for example), then I would most
> definitely _not_ use key 8. Given that I'm a paranoid person, I would
> likely use fetch protected key 10 storage.

Then you would likely get a B78-5C abend. Key 10 is a user key. Surely
most shops run with ALLOWUSERKEYCSA(NO) these days.

> Of course, I imagine that we'd both agree that using a data space and AR mode 
> would be superior.

Perhaps... Though some have compared it to the Intel 286 (and others)
segmented architecture that's long gone in modern ia systems.

> The problem with that _might_ be if the data truly needed to be,
> potentially, addressable in _every_ address space. That could be quite
> "tricky" to do. Or at least a bit complicated compared to ECSA
> storage.

There's Above The Bar shared storage (not to be confused with ATB
common, which might also be applicable).

Tony H.

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Rob Schramm]

XES & XCF for advances

PDSE - mixed bag .. Mostly advances.. And some .. Well ... just plain weird.

zFS over HFS - advance

Open Edition / unix system services / USS  / z/unix. - Mixed bag - b2 to c2
bad, TCPIP good,  ported tools/open source good, java jrio - blunder, java
jzos - advance.

Rob Schramm
On Mar 31, 2015 10:12 AM, "John McKown" 
wrote:

> On Mon, Mar 30, 2015 at 8:06 PM, Shmuel Metz (Seymour J.)
>  wrote:
> > In
> > ,
> > on 03/30/2015
> >at 08:34 AM, John McKown  said:
> >
> >>This is one main reason why I prefer the UNIX fork() philosophy
> >>rather than "threading".
> >
> > That philosophy led to the insanity that a command can't pass back an
> > environment variable to its caller.
>
> OTOH, it stops the child from corrupting the parent's environment
> variable space. And I do have a technique which can do _something_
> about that. A short example would be to run the following in a UNIX
> shell.
>
> $(echo export BUBBA=bubba) # run the stdout of the enclosed command as
> commands in the parent shell.
>
> Yes, this is simplistic, but it results in the environment variable
> BUBBA being set to "bubba" in the parent's shell. Of course, the
> application needs to be written with this approach in mind. It can't
> just use the setenv() or putenv() function.
>
> >
> >>But I still like the isolation of protect keys.
> >
> > What isolation? With everybody and his brother running key 8, the
> > storage key mechanism is worthless for shared memory.
>
> The fact that programmers are too lazy to use protect keys does not
> make them "worthless". If _I_ were writing APF code which required me
> to store data in _common_ memory (ECSA for example), then I would most
> definitely _not_ use key 8. Given that I'm a paranoid person, I would
> likely use fetch protected key 10 storage. Of course, I imagine that
> we'd both agree that using a data space and AR mode would be superior.
> The problem with that _might_ be if the data truly needed to be,
> potentially, addressable in _every_ address space. That could be quite
> "tricky" to do. Or at least a bit complicated compared to ECSA
> storage.
>
> >
> > "Ignorance of Multics considered harmful"
> >
> > --
> >  Shmuel (Seymour J.) Metz, SysProg and JOAT
>
> --
> If you sent twitter messages while exploring, are you on a textpedition?
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[John McKown]

On Mon, Mar 30, 2015 at 8:06 PM, Shmuel Metz (Seymour J.)
 wrote:
> In
> ,
> on 03/30/2015
>at 08:34 AM, John McKown  said:
>
>>This is one main reason why I prefer the UNIX fork() philosophy
>>rather than "threading".
>
> That philosophy led to the insanity that a command can't pass back an
> environment variable to its caller.

OTOH, it stops the child from corrupting the parent's environment
variable space. And I do have a technique which can do _something_
about that. A short example would be to run the following in a UNIX
shell.

$(echo export BUBBA=bubba) # run the stdout of the enclosed command as
commands in the parent shell.

Yes, this is simplistic, but it results in the environment variable
BUBBA being set to "bubba" in the parent's shell. Of course, the
application needs to be written with this approach in mind. It can't
just use the setenv() or putenv() function.

>
>>But I still like the isolation of protect keys.
>
> What isolation? With everybody and his brother running key 8, the
> storage key mechanism is worthless for shared memory.

The fact that programmers are too lazy to use protect keys does not
make them "worthless". If _I_ were writing APF code which required me
to store data in _common_ memory (ECSA for example), then I would most
definitely _not_ use key 8. Given that I'm a paranoid person, I would
likely use fetch protected key 10 storage. Of course, I imagine that
we'd both agree that using a data space and AR mode would be superior.
The problem with that _might_ be if the data truly needed to be,
potentially, addressable in _every_ address space. That could be quite
"tricky" to do. Or at least a bit complicated compared to ECSA
storage.

>
> "Ignorance of Multics considered harmful"
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

-- 
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Paul Gilmartin]

On Mon, 30 Mar 2015 21:06:52 -0400, Shmuel Metz (Seymour J.)  wrote:
>
>>This is one main reason why I prefer the UNIX fork() philosophy
>>rather than "threading".
>
>That philosophy led to the insanity that a command can't pass back an
>environment variable to its caller.
> 
Much alleviated by the mechanism of command substitution.

And hauntingly similar to the JCL insanity that one job step can't
pass back a JCL variable to be used in the PARM to a subsequent
step.  And nothing similar to command substitution available as
an alternative.

-- gil

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Shmuel Metz (Seymour J.)]

In
,
on 03/30/2015
   at 08:34 AM, John McKown  said:

>This is one main reason why I prefer the UNIX fork() philosophy
>rather than "threading".

That philosophy led to the insanity that a command can't pass back an
environment variable to its caller.

>But I still like the isolation of protect keys.

What isolation? With everybody and his brother running key 8, the
storage key mechanism is worthless for shared memory.

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

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Shmuel Metz (Seymour J.)]

In
,
on 03/30/2015
   at 06:54 AM, John McKown  said:

>To me, one of the biggest pluses is the "hardware memory key". 

Better than nothing, and available before S/360 supported virtual
memory, but inferior to other mechanisms. I'll take segment/ring-based
protection any day. Even block relocation is arguably better.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Shmuel Metz (Seymour J.)]

In <39bc7.33e0233e.424a7...@aol.com>, on 03/30/2015
   at 05:36 AM, Ed Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> said:

>Be interesting to see a survey of biggest advances, or biggest 
>blunders since we started.

Sometimes they're the same, e.g., Project Stretch may have been the
most profitable "failure" IBM ever had.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[John McKown]

On Mon, Mar 30, 2015 at 8:07 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 30 Mar 2015 06:54:57 -0500, John McKown wrote:
>
>
>>To me, one of the biggest pluses is the "hardware memory key". As now
>>used by z/OS, it really helps with reliability because, properly used,
>>it enforces separation of authority (ability to write) by major OS
>>subsystem.  E.g. JES2 code can't step on VTAM memory in common
>>storage.
>>
> Certainly an effective accommodation to the single address space limitation
> of its time.  but consider the gyrations the TSO TMP performs to run
> a mixture of privileged and unprivileged tasks in a single address space.
> (It might be better if all authorized programs had the discipline to
> obtain storage only in system key and unauthorized were restricted to
> user key, and if instead of JSCBAUTH there were a similar flag, but
> with TCB rather than job step scope so subtasks could be dispatched in
> suitable PSW keys.  Alas, no one anticipated,)

Well, with APF code, you could create a new JSCB to be used with the
ATTACHX macro. The new JSCB would be associated with the new TCB and
have the JSCBAUTH bit OFF. Unfortunately, this still has a security
hole due to the fact that the APF code and the non-APF code are
running in the same address space and likely both going to be running
in key 8. And so the unauthorized code could possibly corrupt (perhaps
maliciously) the memory of the APF code, causing it to "do bad
things".

This is one main reason why I prefer the UNIX fork() philosophy rather
than "threading". At least when the other code is not under my
personal control. Too bad that creating a new z/OS address space is so
expensive compared to something like Linux. Of course, one reason is
due to the fact that a z/OS address space has a lot of system level
TCBs set up inside it before the user code is even looked at. Which
explains the use of the BPXAS "UNIX initiator" address spaces.

>
> Nowadays, isn't segment protection with multiple address spaces a better
> approach?

That doesn't protect memory in COMMON storage such as ECSA. It is
significantly better than MVT's use of different keys 1..15 to
separate memory for regions in real memory. Of course, IBM has done
some really good things to reduce use of COMMON storage, such as dual
address space, and especially AR mode. But I still like the isolation
of protect keys. Maybe I'm just old fashioned in this regard .

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



-- 
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Mohammad Khan]

On Mon, 30 Mar 2015 08:07:02 -0500, Paul Gilmartin  wrote:

>
>>To me, one of the biggest pluses is the "hardware memory key". As now
>>used by z/OS, it really helps with reliability because, properly used,
>>it enforces separation of authority (ability to write) by major OS
>>subsystem.  E.g. JES2 code can't step on VTAM memory in common
>>storage.
>> 
>Certainly an effective accommodation to the single address space limitation
>of its time.  but consider the gyrations the TSO TMP performs to run
>a mixture of privileged and unprivileged tasks in a single address space.
>(It might be better if all authorized programs had the discipline to
>obtain storage only in system key and unauthorized were restricted to
>user key, and if instead of JSCBAUTH there were a similar flag, but
>with TCB rather than job step scope so subtasks could be dispatched in
>suitable PSW keys.  Alas, no one anticipated,)
>
>Nowadays, isn't segment protection with multiple address spaces a better
>approach?
>

Yes, but only to a certain extent as different address spaces still have some 
common areas. Moreover application servers ( CICS, WAS ) running transactions 
on behalf of multiple users in the same address space are conceptually not that 
different from MVT.

Mohammad

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Paul Gilmartin]

On Mon, 30 Mar 2015 06:54:57 -0500, John McKown wrote:

>On Mon, Mar 30, 2015 at 4:36 AM, Ed Finnell wrote:
>> Good, bad or indifferent IBM-Main is coming up on 29 yrs( in June).
>> 
Only 29?  I thought OS/MVT/ASP, the focus of the drift, was quite
obsolescent 29 years ago.

Let's all thank Mark Post for supplying interesting, relevant, timely 
information.

>> Be interesting to see a survey of biggest advances, or biggest  blunders
>> since we started.
>
>Channeling gil: EBCDIC!
> 
The classic:
http://www.bobbemer.com/P-BIT.HTM

(I wonder who has been maintaining the site for the last 11 years?)

>To me, one of the biggest pluses is the "hardware memory key". As now
>used by z/OS, it really helps with reliability because, properly used,
>it enforces separation of authority (ability to write) by major OS
>subsystem.  E.g. JES2 code can't step on VTAM memory in common
>storage.
> 
Certainly an effective accommodation to the single address space limitation
of its time.  but consider the gyrations the TSO TMP performs to run
a mixture of privileged and unprivileged tasks in a single address space.
(It might be better if all authorized programs had the discipline to
obtain storage only in system key and unauthorized were restricted to
user key, and if instead of JSCBAUTH there were a similar flag, but
with TCB rather than job step scope so subtasks could be dispatched in
suitable PSW keys.  Alas, no one anticipated,)

Nowadays, isn't segment protection with multiple address spaces a better
approach?

-- gil

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[John McKown]

On Mon, Mar 30, 2015 at 4:36 AM, Ed Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> Good, bad or indifferent IBM-Main is coming up on 29 yrs( in June).
>
> Be interesting to see a survey of biggest advances, or biggest  blunders
> since we started.

Channeling gil: EBCDIC!

To me, one of the biggest pluses is the "hardware memory key". As now
used by z/OS, it really helps with reliability because, properly used,
it enforces separation of authority (ability to write) by major OS
subsystem.  E.g. JES2 code can't step on VTAM memory in common
storage.

-- 
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...

[Ed Finnell]

Good, bad or indifferent IBM-Main is coming up on 29 yrs( in June).
 
Be interesting to see a survey of biggest advances, or biggest  blunders 
since we started.
 
 
In a message dated 3/30/2015 3:01:04 A.M. Central Daylight Time,  
elardus.engelbre...@sita.co.za writes:

I think  I should perhaps add 'mainframe (including z/OS) discussions', 
just to be  fair... 

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