You went on a OCO rant without answering my question. I looked in the
POPs manual and found the two differences between the use of ESAR and
ESAIR -
* In the EXTRACT SECONDARY ASN AND INSTANCE operation, the
SASTEIN, bits 0-31 of control register 3, is placed in bit positions
0-31 of general register Rx. In the EXTRACT SECONDARY ASN operation,
bits 0-31 of general register Rx remain unchanged.
* Operation exception (if the ASN-and-LX-reuse facility is not
installed, ESAIR only)
The second is only an issue if the minimum support level for DB2 and
MQ is machines without that feature - Otherwise it is a non-issue.
Just adding a check to the launch modules to test for the feature
would not work since a negative result would need to not have the
change made to the code. Hopefully all the machines you run the code
on would have the feature OR you could add the requirement to the new
version that has the ESAIR code.
As to the first difference, does the high byte of register Rx (the
referenced register in the instruction) affect the code? - IOW: Do
you look at it or just use the result as supplied independent of if
it came from a ESAR or ESAIR?
Only once these questions get answered does the issue of OCO come
into play since we have no access to the code to look at. It is my
contention that so long as I can swap a ESAR with a ESAIR (and know
that the ESAIR is supported) then just doing a mass replacement of
ESARs with ESAIRs should be doable with minimal effort.
Just use ISPF and concatenate the library with the source code behind
an empty PDS (or PDSE). Do a mass find/replace on that concatenation
and any member that uses the ESAR command with end up in the empty
PDS with ESAIR commands being used. Compile that, convert the object
decks into a SYSMODs, and feed it to SMPE and you have an upgraded
version of the load modules.
I know the above is simplistic but it amounts to a good model of the
sequence of steps that would be needed.
At 22:03 -0400 on 08/13/2012, John Gilmore wrote about Re:
REPLACEMENT ASID SHORTAGE:
As usual, OCO makes an external judgment all but impossible. We are
at the mercy of an IBM development group's not necessarily
disinterested judgment.
Would it not be possible, without breaching OCO, to provide a more
quantitative, confidence-inspiring statement than ". . . there would
be considerable cost to convert all of these to ESAIR."
This conversion is in the womb of time, inescapably so; the only
intereresting question is that of its timing.
--jg
On 8/13/12, Robert A. Rosenberg <hal9...@panix.com> wrote:
At 17:45 -0400 on 08/13/2012, Jim Mulder wrote about Re: REPLACEMENT
ASID SHORTAGE:
"Since DB2 and MQ use the ESAR instruction, they cannot be
called from a job using a reuseable ASID. Most annoying."
I have been told that their are many instances of ESAR
to the caller's address space throughout the DB2 and MQ
code, so there would be considerable cost to convert all
of these to ESAIR.
If the calling sequence (ie: the parms), return codes, and usage of
the two instructions are the same (ie: Changing a ESAR instruction to
a ESAIR one requires no other change to the code) then a simple mass
find/replace and recompile would seem to be a simple way of fixing
the issue. If on the other hand, changing one instruction to the
other requires manual updates/changes to each use then I can see why
they feel that it would be expensive/impractical.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
