I am reassured to hear the instruction being executed was being built in storage dynamically obtained for this instance. From the conversation preceding this that was not clear and left me thinking the routine was not actually reentrant, but was writing into itself and relying on the proximity of the two instructions (MVI, then EX) to simulate reentrancy.
Does an executed instruction have to be brought into the I-cache? Or is this just the delay because an instruction references data changed by the preceding instruction? Gary On 2020-10-28 12:28 p.m., Peter Relson wrote:
No one would say that every function is written to perform as well as it conceivably could. Especially when there is no business need. If you can demonstrate a problem due to poor performance of an existing function, then open an RFE and ask for it to be improved. But simply saying that it is not as good as it could be will not be sufficient justification. In the grand scheme of things, one additional "EX" is often not a big deal. As with most performance-related things, it comes down to "how often?". I wouldn't tend to think of a "compiler" (COBOL or otherwise) as generating code to invoke TESTCB. Maybe an LE-provided function would. Maybe I'm mis-thinking. IDA019C1 is a reentrant module. In practice, it is not going to be the case that the storage being written into to create the execute target instruction is in the same cache line as the execute itself (the execute target is built within the caller's 72-byte save area). According to comments in the module, the module was re-written in the early 80's, well after the time that the OP has the source for. I have no idea what it looked like before then. It still does the dynamic building of the TM instruction. As to why the module dynamically builds its TM instruction, it probably did not matter too much back when this module was written (way before the I-cache and D-cache were separated). Probably someone thought it was "clever" and/or "easier" (the processing is table-driven), and no one has made a case to change it. And maybe the limited amount of dynamic storage available to them led them down this path. Peter Relson z/OS Core Technology Design
Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: [email protected] Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
