Melvyn, Personally I know of no COBOL internals of any era that deliberately used/uses xCB macros. Some LE component in more recent HLL incarnations may use them, but I'm not even sure that such usage exists.
I think it likely that the VSAM feedback codes available in more recent incarnations of COBOL are probably the direct results from GET RPL/PUT RPL macros rather than specific use of xCB macros. Whether some user-written COBOL code invokes assembler subroutines to use xCB macros is a different animal. Peter -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of MELVYN MALTZ Sent: Monday, October 26, 2020 10:22 PM To: [email protected] Subject: Re: Is TESTCB a bad boy ? EXTERNAL EMAIL Thanks for all the responses, very useful Perhaps I'd better state what environment I'm working in I'm using the MVS 3.8 version of VSAM macros which are in the Public Domain IDA019C1 is the xCB processor and I have the source code from that era All of this has been adapted in z390 so that I have a emulated IBM VSAM environment as far as xCB operations go To respond to most of you To Charles... Rather than send you the unfathomable code from IDA019C1 here is an extract from a z390 trace which shows a typical situation, code followed by source 800FDCCA 0 9291D014 MVI S2(000FF98C)=96 I2=91='j' IDA019C1 00105A MVI TSTOP(REG13),X'91' 800FDCCE 0 440D0014 EX R0=800FD42E S2(000FF98C)=91804001 IDA019C1 00105E EX REG0,BITSTINS(REG13) To Gary... >>>TESTCB has list, execute, and generate forms; they generate reentrant >>>code Mostly they don't, some like MF=G have the potential but as always it's up to the skill of the programmer to ensure re-entrancy To Christopher... As you can see from the above code the instruction doing the mod is about 7K from the instruction being modified, so only that cache would be refreshed, a minor overhead provided is wasn't being done a lot I'm still a little concerned that TESTCB might be used internally by COBOL etc and be taking a performance hit unknown to the users Melvyn Maltz. ----- Original Message ----- From: "Christopher Y. Blaicher" <[email protected]> To: <[email protected]> Sent: Monday, October 26, 2020 7:21 PM Subject: Re: Is TESTCB a bad boy ? >A cache line is 256 bytes. If the code that modifies an instruction is in >the same cache line as the instruction, then multiple cache line refreshes >have to happen. > The cache line for the modified instruction has to be brought into the > data cache and modified. This causes the cache line in the instruction > cache to be invalidated. The cache line then has to be refreshed into the > instruction cache and then the next instruction re-fetched. Doing an EX > causes no cache line refreshes and does not interfere with the pipeline. > As I said, EX has its own set of overheads, but are a very small fraction > of modifying an instruction. > > Chris Blaicher > Technical Architect > Precisely.com > > > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Farley, Peter x23353 > Sent: Monday, October 26, 2020 2:33 PM > To: [email protected] > Subject: Re: Is TESTCB a bad boy ? > > This message originated Externally. Use proper judgement and caution with > attachments, links, or responses. > > > Isn't that true only if the dynamically built instruction isn't in the > same cache line as the code that performs the build and EX? > > I've seen examples where the "built" instruction was a non-reentrant > location in the same CSECT and very near to the "build" instructions. Not > my code, but I have seen it. > > Peter > > -----Original Message----- > From: IBM Mainframe Assembler List <[email protected]> On > Behalf Of Christopher Y. Blaicher > Sent: Monday, October 26, 2020 2:07 PM > To: [email protected] > Subject: Re: Is TESTCB a bad boy ? > > This will not have the same performance hit. > The problem with the MVI was the CPU had to 1) bring the cache line into > the data cache; 2) apply the MVI data; 3) refresh the cache line in the > instruction cache; and finally 4) execute the instruction. > Doing an EX skips steps 1, 2 and 3. EX has its own set of overheads, but > nowhere near what all the cache hits have. > > Chris Blaicher > Technical Architect > Precisely.com > > > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Melvyn Maltz > Sent: Monday, October 26, 2020 11:16 AM > To: [email protected] > Subject: Is TESTCB a bad boy ? > > This message originated Externally. Use proper judgement and caution with > attachments, links, or responses. > > > In ancient times it was common practice to do this sort of thing... > > SWITCH NOP GO > MVI SWITCH+1,X'F0' > > I believe this clears the cache and causes severe performance hits > > In my research into TESTCB for the z390 Project I found that it > dynamically builds the subject instruction for an EX > > Would this have the same performance hit ? > > Melvyn Maltz. > > 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. > 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.
