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