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 <ee...@us.ibm.com> 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:ee...@us.ibm.com] >> 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 >ee...@us.ibm.com > >---------------------------------------------------------------------- >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
