Re: Millicode Instructions
Some millicode instructions will outperform their PoOp-code counterparts because millicode has access to hardware features not available to ordinary code. For example, MVCL(E) has the ability to move data under certain conditions without loading it into cache. (You can't do that with looping MVC.) Millicode routines also have access to the MVCX instruction which performs a variable-length MVC -- something ordinary programs cannot do without using the EXecute instruction. MVCX sounds like it would be usefull for non-millicode, any idea why it was not externalized? Is there a coresponding CLCX? -- Richard
Re: Storage and Tokens
The CVTUSER and TCBUSER fields have always been worthless precisely because you can't count on them. There's no documented interface, so nobody actually uses them - or at least not without taking their hero pills and pulling on the kevlar undies first. CC I have lost my hero pills, and my kevlar undies have long since disintegrated, but we have been using both of these for more than 40 years. Perhaps you mean no vendor uses them, which is understandable. These fields were created before there were 3rd party vendors, so I have always assumed they were for customer use. -- Richard
Re: Storage and Tokens
Some years ago, prior to IBM's adoption of the vendor table, I went to a conference. During my absence the local CA salesman, who happened to be golfing with the company president, talked him into doing performance measurement on our MVS system. One of my systems people installed their software; nobody noticed that we were no longer collecting accounting data, or printing billing information on the jobs. Since then I place eye-catchers in control blocks, and check for their presence. Some diligence after installing new software suffices to keep things safe. I guess we have been luckier, never had a conflict. We also have eye-catchers that are checked for on each access. -- Richard
