Re: Intel Virtualization
> -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of glen herrmannsfeldt > Sent: 25 March 2015 16:53 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Intel Virtualization > > > As for the ISA, Intel seems to be very "ad hoc" compared to the z > > architecture. Especially in the virtualization arena. Basically, the z > > has a _single_ virtualization instruction: SIE. > > Intel has I don't know how many different versions of different > > instructions to let hypervisors run at all. I don't know how efficient > > vitualization actually is on Intel. > > But it wouldn't surprise me if it were a pig. > > As far as I know, the biggest advantage z/ has over Intel (and many others) is > the wait state. > > It is sometimes difficult for virtualization to figure out when the guest isn't > doing anything. Most other systems use a null process with a small loop, > while waiting for an interrupt. > (But if you know you are running virtual, there might be some way around it.) > Largely fixed in later Linux, Solaris and Windows kernels (Post Windows/2000, so basically Windows2003 or newer, Solaris 9 or newer, say 12 or 13 years old... > I beleive that the wait state came from the days of usage meters, when the > meter would stop while the processor was waiting. If not for rentals of > S/360, it might not have had the wait state. > > -- glen > >
Intel Virtualization
> As for the ISA, Intel seems to be very "ad hoc" compared to the z > architecture. Especially in the virtualization arena. Basically, > the z has a _single_ virtualization instruction: SIE. > Intel has I don't know how many different versions of different > instructions to let hypervisors run at all. I don't > know how efficient vitualization actually is on Intel. > But it wouldn't surprise me if it were a pig. As far as I know, the biggest advantage z/ has over Intel (and many others) is the wait state. It is sometimes difficult for virtualization to figure out when the guest isn't doing anything. Most other systems use a null process with a small loop, while waiting for an interrupt. (But if you know you are running virtual, there might be some way around it.) I beleive that the wait state came from the days of usage meters, when the meter would stop while the processor was waiting. If not for rentals of S/360, it might not have had the wait state. -- glen
Intel Virtualization (WasRE: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37))
> > As for the ISA, Intel seems to be very "ad hoc" compared to the z > architecture. Especially in the virtualization arena. Basically, the z has a > _single_ virtualization instruction: SIE. Intel has I don't know how many > different versions of different instructions to let hypervisors run at all. I > don't > know how efficient vitualization actually is on Intel. But it wouldn't > surprise > me if it were a pig. > Having run a medium sized organization with 30 physical servers and 300 or so virtual windows images I would say Intel virtualization via a bare metal hypervisor, such as VMWare is pretty efficient. Also whilst you only have SIE there are (or were when I was actively involved) several levels of SIE Assist, just there are various levels of VT on Intel. The Microsoft stuff is less efficient as it uses a thin windows structure which uses more resources. The problem with it is the back end storage, you need to put a lot of effort in getting storage that can deliver the IOPS and low latency you need for a quick database. I am so glad I no longer have to keep telling my manager that the reason the storage is slow is because he has bought cheap disks, and instead of managing for IO performance they formatted RAID6 for capacity and of course when the SQL log backups kick in at lunch time the world goes pear shaped. > -- > 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
Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
I am not sure who of the people that had answered you, you consider to be
arrogant and/or PC centric, but if you refer to my comments than please listen:
1. Assembler (machine language expressed in mnemonics,) on any hardware,
mainframe, SPARC, ARM, Intel, or whatever is as terse to the human eye and
brain as is RE. If you think otherwise, than please show samples to any
non-programmer and ask them.
2. Most none of us on this list is PC centric. The hardware that we know is,
in most cases the mainframe. I don't think that any of us would argue that the
mainframe hardware is by far superior to any of the other popular hardwares.
3. Moreover, almost none of us would argue about the fact that z/OS (and the OS
that run the AS/400, whatever its name is today) are exemplary stable. Many of
us use Windows, Unix, Linux and mainframe Unix, each one has advantages and
disadvantages.
4. RE is a type of software that is not coupled to any specific hardware. It
is available on every major OS on the planet, from z/OS to Unix, Linux,
Windows. It was originated from the Unix world and took over the pattern
matching functionality (Snobol may have better ideas, but it did NOT take off.)
If we leave arrogance out of the debate, please come with a better syntax for
pattern matching (make sure it is as powerful), implement it and show everybody
that it is better and maybe your ideas will take off and replace the terse
syntax of RE.Just two comments, a. Please don't tell us that the Rexx PARSE
verb is good enough, because it is much less powerful then RE. But on the
positive side, it could be a good starting point for your
counter-implementation.b. If you do not see the need for pattern matching, then
that's fine. Other people do it on regular basis.
Ze'ev Atlas
From: John Walker <00c645a0d640-dmarc-requ...@listserv.uga.edu>
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Wednesday, March 25, 2015 9:49 AM
Subject: Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
RE does suck, your arrogant (and PC-typical) comment not withstanding.
Mainframes are MUCH better built than PC's. Yes, PC's are FINALLY starting to
adopt much of the Mainframe architecture and concepts, but they still are an
inferior designed choke-pointed architecture. Feel free to belittle what I
said and I will feel free to laugh at the PC architecture and crappy code, too.
On Tue, 3/24/15, ASSEMBLER-LIST automatic digest system
wrote:
Subject: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Tuesday, March 24, 2015, 11:00 PM
ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
(#2015-37)
#yiv3578040631 body {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 td {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 p {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 a {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
#yiv3578040631 h2 {
font-family:Arial, Helvetica,
sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
#yiv3578040631 h3 {
font-family:Arial, Helvetica,
sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
(#2015-37)
Table of contents:
Regular Expression
Follow-up
TOD (9)
Regular Expression
Follow-up
Regular Expression
Follow-up (03/24)
From: Brent Longborough
TOD
TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: "Tenberg, Kerry"
Re: TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: "Tenberg, Kerry"
Re: TOD (03/24)
From: Dougie Lawson
Re: TOD (03/24)
From: "Blaicher, Christopher Y."
Re: TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: glen herrmannsfeldt
Re: TOD (03/24)
From: Tony Harminc
Browse the ASSEMBLER-LIST
online archives.
Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
What is choke-pointed?
> Date: Wed, 25 Mar 2015 06:49:24 -0700
> From: 00c645a0d640-dmarc-requ...@listserv.uga.edu
> Subject: Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>
> RE does suck, your arrogant (and PC-typical) comment not withstanding.
> Mainframes are MUCH better built than PC's. Yes, PC's are FINALLY starting
> to adopt much of the Mainframe architecture and concepts, but they still are
> an inferior designed choke-pointed architecture. Feel free to belittle what
> I said and I will feel free to laugh at the PC architecture and crappy code,
> too.
>
> On Tue, 3/24/15, ASSEMBLER-LIST automatic digest system
> wrote:
>
> Subject: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: Tuesday, March 24, 2015, 11:00 PM
>
>
>
>
> ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
> (#2015-37)
>
> #yiv3578040631 body {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv3578040631 td {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv3578040631 p {
> font-family:Arial, Helvetica,
> sans-serif;font-size:12px;color:#00;}
> #yiv3578040631 a {
> font-family:Arial, Helvetica,
>
> sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
> #yiv3578040631 h2 {
> font-family:Arial, Helvetica,
> sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
> #yiv3578040631 h3 {
> font-family:Arial, Helvetica,
> sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
> (#2015-37)
> Table of contents:
>
> Regular Expression
> Follow-up
> TOD (9)
>
>
> Regular Expression
> Follow-up
> Regular Expression
> Follow-up (03/24)
> From: Brent Longborough
>
> TOD
> TOD (03/24)
> From: "Ward, Mike S"
>
> Re: TOD (03/24)
> From: "Tenberg, Kerry"
>
> Re: TOD (03/24)
> From: "Ward, Mike S"
>
> Re: TOD (03/24)
> From: "Tenberg, Kerry"
>
> Re: TOD (03/24)
> From: Dougie Lawson
> Re: TOD (03/24)
> From: "Blaicher, Christopher Y."
>
> Re: TOD (03/24)
> From: "Ward, Mike S"
>
> Re: TOD (03/24)
> From: glen herrmannsfeldt
>
> Re: TOD (03/24)
> From: Tony Harminc
>
>
>
>
>
>
>
>
>
> Browse the ASSEMBLER-LIST
> online archives.
>
>
>
>
>
>
>
>
>
>
Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
On Wed, Mar 25, 2015 at 8:49 AM, John Walker <00c645a0d640-dmarc-requ...@listserv.uga.edu> wrote: > RE does suck, your arrogant (and PC-typical) comment not withstanding. > Mainframes are MUCH better built than PC's. Yes, PC's are FINALLY starting > to adopt much of the Mainframe architecture and concepts, but they still are > an inferior designed choke-pointed architecture. Feel free to belittle what > I said and I will feel free to laugh at the PC architecture and crappy code, > too. Hum, you seem quite upset. But regular expressions don't come from the PC environment. They come from the older minicomputer environment. More specifically, they came from the UNIX camp. Certainly not from the Windows camp. I am a Linux partisan in that arena. I hate Windows. The z hardware is most definitely the most reliable on the planet. Beats the out of Intel, ARM, and MIPS. I've had a CPU and an OSA fail on me. But, and this is the biggie, neither of those failures even caused a burp in processing. In the CPU case, a spare CP was brought in and the _firmware_ recovered the instruction in progress. If the hardware hadn't told the SE which told the HMC, I never even would have known. Likewise, when the OSA failed, our second OSA did an ARP takeover and everything continued on it merry way with _no_ disruption to any software component or end user. The "open" systems people called me a liar when I told them that. Their idea of recovery is a "hot standby". Blech. As for the ISA, Intel seems to be very "ad hoc" compared to the z architecture. Especially in the virtualization arena. Basically, the z has a _single_ virtualization instruction: SIE. Intel has I don't know how many different versions of different instructions to let hypervisors run at all. I don't know how efficient vitualization actually is on Intel. But it wouldn't surprise me if it were a pig. -- 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
Re: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
RE does suck, your arrogant (and PC-typical) comment not withstanding.
Mainframes are MUCH better built than PC's. Yes, PC's are FINALLY starting to
adopt much of the Mainframe architecture and concepts, but they still are an
inferior designed choke-pointed architecture. Feel free to belittle what I
said and I will feel free to laugh at the PC architecture and crappy code, too.
On Tue, 3/24/15, ASSEMBLER-LIST automatic digest system
wrote:
Subject: ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015 (#2015-37)
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Tuesday, March 24, 2015, 11:00 PM
ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
(#2015-37)
#yiv3578040631 body {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 td {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 p {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv3578040631 a {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
#yiv3578040631 h2 {
font-family:Arial, Helvetica,
sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
#yiv3578040631 h3 {
font-family:Arial, Helvetica,
sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
ASSEMBLER-LIST Digest - 23 Mar 2015 to 24 Mar 2015
(#2015-37)
Table of contents:
Regular Expression
Follow-up
TOD (9)
Regular Expression
Follow-up
Regular Expression
Follow-up (03/24)
From: Brent Longborough
TOD
TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: "Tenberg, Kerry"
Re: TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: "Tenberg, Kerry"
Re: TOD (03/24)
From: Dougie Lawson
Re: TOD (03/24)
From: "Blaicher, Christopher Y."
Re: TOD (03/24)
From: "Ward, Mike S"
Re: TOD (03/24)
From: glen herrmannsfeldt
Re: TOD (03/24)
From: Tony Harminc
Browse the ASSEMBLER-LIST
online archives.
Re: (Regular Expressions followup)
On Wed, Mar 25, 2015 at 7:43 AM, Farley, Peter x23353 wrote: > It's not just the PDSE bug history. There are still occasional glitches > found and APAR's issued. When was the last time BPAM had an APAR? How can > any business organization that is even moderately concerned with SLA's allow > itself to be forced to use a product that is known to cause production > downtime issues? > I guess we are: (1) living right; (2) lucky; and/or (3) other, in that we have _never_ had a PDSE problem other than a few times, long ago, with some lock contention. Of course, our z/OS system is scheduled to be euthanized come January and is basically moribund now. I guess if we were doing a lot of concurrent updates we might have more problems. > Mostly I think this advance in technology is making CIO's and their managers > scared. As a programmer I long to get the language and runtime improvements > V5 and up will bring. As level-2 support for production issues, on call > 24x7, I shudder at the potential seriousness of production issues caused by > PDSE problems happening at oh-dark-thirty. > I was going to put in some comments about CIOs and Windows, but I got really bitter, so I'd best not. > After all, this is a bet-the-business-on-it proposition. See elided comments on Windows. > > Peter -- 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
Re: (Regular Expressions followup)
It's not just the PDSE bug history. There are still occasional glitches found and APAR's issued. When was the last time BPAM had an APAR? How can any business organization that is even moderately concerned with SLA's allow itself to be forced to use a product that is known to cause production downtime issues? Mostly I think this advance in technology is making CIO's and their managers scared. As a programmer I long to get the language and runtime improvements V5 and up will bring. As level-2 support for production issues, on call 24x7, I shudder at the potential seriousness of production issues caused by PDSE problems happening at oh-dark-thirty. After all, this is a bet-the-business-on-it proposition. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Wednesday, March 25, 2015 8:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: (Regular Expressions followup) On Wed, Mar 25, 2015 at 7:17 AM, John Gilmore wrote: > Program objects and PDSEs are in no way new features. Why all the pother? Cross sysplex sharing is one _good_ reason. It just ain't possible to do reliably in the general case. The main _bad_ reason is that some people still have scars from the early days and have an aversion due to that. I had the same problem back when VSAM first came out. The need for "suballocation" made the DASD person go nuts because hiss VTOC listings didn't show the suballocated DSNs. So he wanted to stay ISAM. -- 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: (Regular Expressions followup)
On Wed, Mar 25, 2015 at 7:17 AM, John Gilmore wrote: > Program objects and PDSEs are in no way new features. Why all the pother? Cross sysplex sharing is one _good_ reason. It just ain't possible to do reliably in the general case. The main _bad_ reason is that some people still have scars from the early days and have an aversion due to that. I had the same problem back when VSAM first came out. The need for "suballocation" made the DASD person go nuts because hiss VTOC listings didn't show the suballocated DSNs. So he wanted to stay ISAM. -- 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
Re: (Regular Expressions followup)
Program objects and PDSEs are in no way new features. Why all the pother? On Wed, Mar 25, 2015 at 8:08 AM, John McKown wrote: > On Tue, Mar 24, 2015 at 10:53 PM, Robert A. Rosenberg > wrote: > > At 13:23 -0500 on 03/23/2015, John McKown wrote about Re: (Regular > > Expressions followup): > > > >> There is a big > >> problem with the desire to advance versus the desire to continue to > >> use what already works. As an example, look at some of the posts in > >> IBM-MAIN about COBOL 5 requiring that the executable be in a PDSE and > >> impossible to run from a PDS. > > > > > > What is generated by the COBOL 5 compiler that that requires the use of a > > PDS/E > > to store the Program Object as opposed to placing it as a Load Module in > a > > PDS? If the requirement is about the compiler itself, what is its > structure > > that requires a PDS/E? > > ref: > http://www-01.ibm.com/support/docview.wss?uid=swg27041176 > > > The need for PDSE datasets and Program Objects are built into the very > core of COBOL V5. Just a few examples of features that COBOL V5 uses > and will use that require Program Objects(PO) and thus PDSE datasets > for executables are: > > Improved init/term scheme relies on user-defined classes in object, > requiring PO > QY-con requires PO > (A performance improvement for RXY (long displacement) instructions. > Condition-sequential RLD support requires PO > A performance improvement for bootstrap invocation > PO can get page mapped 4K at a time for better performance > NOLOAD class DWARF debugging data requires PO > Common reentrancy model with C/C++ requires PO > XPLINK requires PO and will be used for AMODE 64 > > > > -- > 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 > -- John Gilmore, Ashland, MA 01721 - USA
Re: (Regular Expressions followup)
On Tue, Mar 24, 2015 at 10:53 PM, Robert A. Rosenberg wrote: > At 13:23 -0500 on 03/23/2015, John McKown wrote about Re: (Regular > Expressions followup): > >> There is a big >> problem with the desire to advance versus the desire to continue to >> use what already works. As an example, look at some of the posts in >> IBM-MAIN about COBOL 5 requiring that the executable be in a PDSE and >> impossible to run from a PDS. > > > What is generated by the COBOL 5 compiler that that requires the use of a > PDS/E > to store the Program Object as opposed to placing it as a Load Module in a > PDS? If the requirement is about the compiler itself, what is its structure > that requires a PDS/E? ref: http://www-01.ibm.com/support/docview.wss?uid=swg27041176 The need for PDSE datasets and Program Objects are built into the very core of COBOL V5. Just a few examples of features that COBOL V5 uses and will use that require Program Objects(PO) and thus PDSE datasets for executables are: Improved init/term scheme relies on user-defined classes in object, requiring PO QY-con requires PO (A performance improvement for RXY (long displacement) instructions. Condition-sequential RLD support requires PO A performance improvement for bootstrap invocation PO can get page mapped 4K at a time for better performance NOLOAD class DWARF debugging data requires PO Common reentrancy model with C/C++ requires PO XPLINK requires PO and will be used for AMODE 64 -- 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
