Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
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...
In CAAJSdjgcPHDb60=apm36kvymoddqmd2fiefavq6my5zuqxw...@mail.gmail.com, on 03/30/2015 at 08:34 AM, John McKown john.archie.mck...@gmail.com 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 http://patriot.net/~shmuel/resume/brief.html 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...
On Mon, Mar 30, 2015 at 8:06 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In CAAJSdjgcPHDb60=apm36kvymoddqmd2fiefavq6my5zuqxw...@mail.gmail.com, on 03/30/2015 at 08:34 AM, John McKown john.archie.mck...@gmail.com 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...
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 john.archie.mck...@gmail.com wrote: On Mon, Mar 30, 2015 at 8:06 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In CAAJSdjgcPHDb60=apm36kvymoddqmd2fiefavq6my5zuqxw...@mail.gmail.com, on 03/30/2015 at 08:34 AM, John McKown john.archie.mck...@gmail.com 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...
On 31 March 2015 at 10:11, John McKown john.archie.mck...@gmail.com 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...
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...
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...
On Mon, 30 Mar 2015 08:07:02 -0500, Paul Gilmartin paulgboul...@aim.com 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...
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 http://patriot.net/~shmuel/resume/brief.html 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...
In caajsdjhwaswhnq89sqoebd5bny1eccsiqrizzyyfg1rgkz3...@mail.gmail.com, on 03/30/2015 at 06:54 AM, John McKown john.archie.mck...@gmail.com 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 http://patriot.net/~shmuel/resume/brief.html 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...
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
