So, just to close the loop...do we correctly document the required options?
ESHEL Jonathan wrote:
Thank you John. The problem was found thanks to Tony H. as a wrong HLASM
compile option used by us - COMPAT(SYSLIST).
Regards, Jonathan
On Tue, 8 Mar 2016 12:29:48 -0500, John Eells <[email protected]> wrote:
In that case, assuming a local modification is not in the mix and
causing the problem somehow, I suggest you open a PMR with JES2 Level 2
(COMPID 5752SC1BH). Our PTFs should be installable without error (once
you include any PE fixing PTFs, of course) whether you use source and
soruce update installation (i.e., ++SRC & ++SRCUPD) or not (i.e., ++MOD).
ESHEL Jonathan wrote:
Thank you John and apologies for not doing it earlier. We did use GROUPEXTEND
initially so OA44222 was in the package already. We also tried today to apply
it specifically, but no joy. UA71619 is preq'ed by UA72148 (the fix of OA44222)
and it does not apply due to the ISFJREAD compile failure.
The thing is that this compile error is quite strange, It is around this CALL
macro:
CALL
(15),((R14),WORRSUM,=A(L'RECSNO),=A(1),=X'00',=X'00',=X'00',=X'00',=A(0),WORERRMG),LINKINST=BASR,PLIST4=,PLIST8=YES,MF=(E,WORCALL)
This call looks "heavy" but there is actually nothing wrong with it. I tried to
code it in a small program and it compiles without a problem. In the IBM source, for some
reason it takes everything from the second parameter (WORRSUM) on as one long parameter
instead of 9, so obviously the resulting LA instruction gets an error.
If we are the only ones having this problem, we must be doing something very
weird ...
Regards, Jonathan
-----Message d'origine-----
De : John Eells [mailto:[email protected]]
Envoy� : mercredi 2 mars 2016 17:14
Objet : Re: Problem applying UA71619 anyone ?
ESHEL Jonathan wrote:
We are trying to apply the PTF's that install the new JSON parser support under
z/OS 2.1 (as of 2.2 it's integrated into the base system), and have a problem
with one of the prereqs - UA71619. It's an assembler error when SMPE is
compiling SDSF module ISFJREAD and the usage of the CALL macro seems to be
shaky - it's actually an SDSF macro ISFXB2C using ISFCALL using CALL using
IHBOPLTX).
Has anyone had or seen something similar ?
<snip>
UA71619 has been PE for quite some time (by OA44222 in January 2014). I
suggest that you RECEIVE current service and HOLDDATA and use GROUPEXTEND to
pull in the fixes.
<snip>
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
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
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
