There were different situations.
First of all, a co-worker on the project (from Kyndryl) helped us by
identifying the modules which were in trouble.
I guess he used special traces or performance reports; don't know which
sort of reports exactly. But he found
the SIIS hits somehow.
Then, when I knew the modules to examine, I found different situations
... some examples:
1) IBM macros with inline parameter lists with SIIS issues (TIME for
example, but others, too)
- with register parameters mostly
2) home grown macros with the same problem
3) LOOPs built by home grown SP macros with decimal control variables
inside the instruction stream (!)
4) internal subroutines built by local macros where local static data
immediately followed the code (same cache line)
5) other (more sophisticated) problems
I will tell you briefly what I did:
1) change the macros to list/execute form, as suggested by IBM, or
switch to other (home grown) services
2) same as 1) or fix the macros to use a separate (workarea) DSECT,
which is present in all our modules
3) fix the SP macros
4) if possible, move the data to the workarea DSECT; if not, enter some
space before the data, so that the
data resides in the next cache line (256 bytes)
5) if possible, separate data from the instructions by moving it to the
workarea which is provided by the
(already existent) startup macro; this also allows for baseless coding
in most situations
Because the modules affected are part of the basic IMS framework of the
customer and carry the daily
IMS dialog services with some thousand users, these modifications had to
be tested carefully, before
putting them into production. The project started in the beginning of
2021 and was terminated successfully
half a year later with (almost) no problems or downtimes.
HTH, kind regards
Bernd
Am 09.12.2023 um 15:38 schrieb Mike Schwab:
Putting DS and modified DCs into a separate area?
On Sat, Dec 9, 2023 at 5:17 AM Bernd Oppolzer <[email protected]>
wrote:
Hi,
there is no such option;
this is not possible, because with ASSEMBLER, the programmer has full
control about where he or she puts the information elements,
be it static data or code. There is no magic engine like the optimizer
with compilers which can do anything about that.
This said:
I had a project in 2021 with a large customer which had very old
ASSEMBLER programs from the 1980s, which had heavy SIIS problems
(store into instruction stream) which had to be resolved. I found out
that some of them can easily be resolved by the use of clever macros
which separate the static data from the code (by putting them in a
different CSECT or DSECT). The details are too complicated to discuss here,
but in the end, the changes to the code were minimal. And in the end, we
achieved our project goals in time and budget.
HTH, kind regards
Bernd
Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:
Hello everyone,
Recently i have seen some discussions related to assembler performance
to use the L1 cache of the processor better and not mixing instructions and
data.
Can you enlighten me which assembler option can be used for this purpose?
Thanks in advance
Best Regards
Ituriel do Nascimento Neto
z/OS System Programmer
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
