Re: Problem applying UA71619 anyone ?
I haven't seen anything related to compile options in this PTF, but I would go with Tony on this - the default options are fine and only because we use what can be considered as a legacy value for this option the compile failed. Moreover, the compile of this source (ISFJREAD) is an indirect consequence - it is not updated itself and the reason it is compiled is due to an update of a macro ($PADDR) it uses, and the compile error has nothing to do with this particular update. Thank you, Jonathan On Wed, 9 Mar 2016 09:06:42 -0500, John Eells <ee...@us.ibm.com> wrote: >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 <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 ? >>>> >>>> >>>> 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. >>> >>> >>> -- >>> 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 >> > > >-- >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
Re: Problem applying UA71619 anyone ?
I was about to before I saw Tony H.'s message with the solution ... Thank you Ed for you help. Jonathan On Tue, 8 Mar 2016 13:47:15 -0600, Ed Gould <edgould1...@comcast.net> wrote: >On Mar 8, 2016, at 10:37 AM, ESHEL Jonathan wrote: > >> Thank you Allan and sorry for not responding earlier. SMPMTS is the >> 1st in our SYSLIB concat and it is empty anyway ... >> >> Regards, Jonathan >> > >Maybe you can show the concatenations? > >Ed > >-- >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
Re: Problem applying UA71619 anyone ?
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 ? >> >> >> 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. > > >-- >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
Re: Problem applying UA71619 anyone ?
Thank you Tony, pity you did not specify on what you were betting because you won ! The COMPAT(SYSLIST) option was the culprit. It comes very probably from our default HLASM options on site, probably for historical reasons, I doubt it is still needed today, but you never know for sure. I added NOCOMPAT to our SMP/E ASM options, and the PTF got applied without a problem. We were indeed doing something weird ... Thank you for your help, Jonathan On Wed, 9 Mar 2016 00:18:19 -0500, Tony Harminc <t...@harminc.net> wrote: >On 8 March 2016 at 12:03, ESHEL Jonathan <j.es...@rsd.com> 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. > >I'm betting that your SMP/E is for some reason configured to pass in >the COMPAT(SYSLIST) option to HLASM. The default is NOCOMPAT. The >options list at the top of the HLASM listing will tell you the >settings and where they came from. > >> If we are the only ones having this problem, we must be doing something very >> weird ... > >If I'm right, then what's weird is where this option came from. Some >other APAR that required it? But it's rare that NOCOMPAT causes >problems. > >Tony H. > >-- >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
Re: Problem applying UA71619 anyone ?
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 ? 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. -- 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
Re: Problem applying UA71619 anyone ?
Thank you Allan and sorry for not responding earlier. SMPMTS is the 1st in our SYSLIB concat and it is empty anyway ... Regards, Jonathan -Message d'origine- De : Staller, Allan [mailto:allan.stal...@wunderman.com] Envoyé : mercredi 2 mars 2016 16:37 Objet : Re: Problem applying UA71619 anyone ? Check you SMP/E DDDEFS for SYSLIB. Ensure SMPMTS is the 1st dataset in the concat... HTH, 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 ? This email ? including attachments ? may contain confidential information. If you are not the intended recipient, do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message. -- 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
Problem applying UA71619 anyone ?
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 ? Thanks to everyone, Jonathan Eshel RSD S.A. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange HMC issue
The name it got, BMC_DHCP may provide a hint. Do you have a BMC product such as BMC MainView SecureHMC running somewhere, perhaps being tested ? Jonathan Eshel -Message d'origine- De : Tony Thigpen [mailto:t...@vse2pdf.com] Envoyé : samedi 21 novembre 2015 06:00 Objet : Strange HMC issue Background: HMC software version 2.11.1 connected to a z10. The HMC is connected to two networks. The first is a small private network with just the laptops in the z10 and the HMC. No other HMCs or other CPUs. The second network is a local network with several items on it, including other HMCs. This network is behind a VPN firewall and is used to access the web services on the HMC. Both interfaces have hard-coded IP addresses. Today we noticed something strange. We had a DHCP address assigned to a box we did not know about. Except for 3 workstations on the network, all other boxes have hard-coded IP addresses. In the DHCP assigned addresses table, the box had provided a name of BMC_DHCP. After a bunch of testing, we isolated the assigned address to the HMC, but the address does not show up in any of the HMC panels that show IP addresses. Items: 1) When we ping the HMC using the hard-coded address, the response is under 3.0ms. 2) When we ping the DHCP assigned address, the response is 10x longer, in the 30.0ms range. 3) The arp tables on another PC show both addresses having the same nic address. 4) The HMC can ping it's own hard-coded address, but it can not ping the DHCP assigned address. 5) We have other CPUs and other HMCs. None of the others are doing the same thing. (z900 though z10). 6) This HMC has the latest software version of all the HMCs. 7) nMap (port mapping tool) says that there are no ports open at this DHCP assigned address. Thoughts on what is happening? Anybody else seeing the same thing? -- Tony Thigpen -- 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
Re: Strange HMC issue
Not really, but by looking around I think I found the BMC in question is not the one I originally thought but a Baseboard Management Controller that provides environmental monitoring for the server. If you look at the Service Guide for HMC and SE GC28-6861-08 (the following link may work or not ... - http://www-01.ibm.com/support/docview.wss?uid=isg2e78d464621f0852572dc0066f772=1) you will see under the 4367 PC configuration step 36 the BMC Network Configuration and the default Host Name is (surprise) BMC_DHCP. If I were you I would search in this direction. Jonathan Eshel On Mon, 23 Nov 2015 08:14:51 -0500, Tony Thigpen <t...@vse2pdf.com> wrote: >That is a good question. > >This machine was about 4 years old when we received it. There may be >something from it's previous install still active. > >Do you know of any way to check the HMC for the BMC client? > >Tony Thigpen > >ESHEL Jonathan wrote on 11/23/2015 03:49 AM: >> The name it got, BMC_DHCP may provide a hint. Do you have a BMC product such >> as BMC MainView SecureHMC running somewhere, perhaps being tested ? >> >> Jonathan Eshel >> >> -Message d'origine- >> De : Tony Thigpen [mailto:t...@vse2pdf.com] >> Envoyé : samedi 21 novembre 2015 06:00 >> Objet : Strange HMC issue >> >> Background: HMC software version 2.11.1 connected to a z10. >> >> The HMC is connected to two networks. The first is a small private network >> with just the laptops in the z10 and the HMC. No other HMCs or other CPUs. >> The second network is a local network with several items on it, including >> other HMCs. This network is behind a VPN firewall and is used to access the >> web services on the HMC. >> >> Both interfaces have hard-coded IP addresses. >> >> Today we noticed something strange. We had a DHCP address assigned to a box >> we did not know about. Except for 3 workstations on the network, all other >> boxes have hard-coded IP addresses. In the DHCP assigned addresses table, >> the box had provided a name of BMC_DHCP. >> >> After a bunch of testing, we isolated the assigned address to the HMC, but >> the address does not show up in any of the HMC panels that show IP addresses. >> >> Items: >> 1) When we ping the HMC using the hard-coded address, the response is under >> 3.0ms. >> 2) When we ping the DHCP assigned address, the response is 10x longer, in >> the 30.0ms range. >> 3) The arp tables on another PC show both addresses having the same nic >> address. >> 4) The HMC can ping it's own hard-coded address, but it can not ping the >> DHCP assigned address. >> 5) We have other CPUs and other HMCs. None of the others are doing the same >> thing. (z900 though z10). >> 6) This HMC has the latest software version of all the HMCs. >> 7) nMap (port mapping tool) says that there are no ports open at this DHCP >> assigned address. >> >> Thoughts on what is happening? >> Anybody else seeing the same thing? >> >> -- >> Tony Thigpen >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JAVA socket timeout exception
Hello everyone, (cross-posting to IBM-MAIN, IBMTCP-L and MVSOE-L) We are experiencing a problem in the current development of a web service application. A request sometimes ends up with a time out exception on both sides. The server is on z/OS, it is a stand-alone server based on javax.xml.ws.Endpoint. The JDK used is 6.0.1 SR7 running on z/OS 1.11. Our usual client application is a web application. However, it seems that problem stands on the server side as we are not experiencing the problem when the server is executed on Unix boxes (mainly linux-x86_64) The test client is executed on a Linux x86-64. client side tests have been executed in eclipse. They show that the client is stuck at SocketInputStream.socketRead0() The problem occurs more often as the server is aging. It also appears that similar stack traces were found in problem description in particular http://www-01.ibm.com/support/docview.wss?uid=swg21622956, though on AIX. The error log on the server follows. Different stack traces are available if needed - I did not include them here to avoid cluttering this message. Any ideas will be greatly appreciated, Thank you, Jonathan Eshel RSD S.A. javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.stream.XMLStreamException: java.net.SocketTimeoutException: write blocked too long] at com.sun.xml.internal.ws.message.jaxb.JAXBMessage.writePayloadTo(JAXBMessage.java:330) at com.sun.xml.internal.ws.message.AbstractMessageImpl.writeTo(AbstractMessageImpl.java:143) at com.sun.xml.internal.ws.encoding.StreamSOAPCodec.encode(StreamSOAPCodec.java:110) at com.sun.xml.internal.ws.encoding.SOAPBindingCodec.encode(SOAPBindingCodec.java:261) at com.sun.xml.internal.ws.transport.http.HttpAdapter.encodePacket(HttpAdapter.java:340) at com.sun.xml.internal.ws.transport.http.HttpAdapter.access$100(HttpAdapter.java:94) at com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:482) at com.sun.xml.internal.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:245) at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:107) at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:92) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77) at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:77) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:80) at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:578) at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:77) at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:550) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929) at java.lang.Thread.run(Thread.java:796) Caused by: javax.xml.bind.MarshalException - with linked exception: [javax.xml.stream.XMLStreamException: java.net.SocketTimeoutException: write blocked too long] at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:284) at com.sun.xml.internal.bind.v2.runtime.BridgeImpl.marshal(BridgeImpl.java:91) at com.sun.xml.internal.bind.api.Bridge.marshal(Bridge.java:108) at com.sun.xml.internal.ws.message.jaxb.JAXBMessage.writePayloadTo(JAXBMessage.java:324) ... 18 more Caused by: javax.xml.stream.XMLStreamException: java.net.SocketTimeoutException: write blocked too long at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwXMLStreamException(StAXMessageProvider.java:64) at com.ibm.xml.xlxp.api.stax.XMLStreamWriterImpl.writeCharacters(XMLStreamWriterImpl.java:748) at com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl$XMLStreamWriterProxy.writeCharacters(XMLOutputFactoryImpl.java:196) at com.sun.xml.internal.bind.v2.runtime.output.XMLStreamWriterOutput.text(XMLStreamWriterOutput.java:151) at com.sun.xml.internal.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.java:306) at com.sun.xml.internal.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$StringImplImpl.writeLeafElement(RuntimeBuiltinLeafInfoImp va:1018) at com.sun.xml.internal.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$StringImplImpl.writeLeafElement(RuntimeBuiltinLeafInfoImp va:997) at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedA sor.java:253) at
Re: JZOS batch launcher (JVMLDMxx) APF ?
Thank you very much Kirk, it works ! I used the linkage instructions suggested in this thread with the version I am using (JVMLDM61) and it worked. Obviously I had already tried to relink the module with AC(1) but had no idea this was the correct way to link it. Regards, Jonathan -Message d'origine- De : Kirk Wolf [mailto:k...@dovetail.com] Envoyé : jeudi 7 mars 2013 20:06 Objet : Re: JZOS batch launcher (JVMLDMxx) APF ? See this: http://www.ibm.com/developerworks/forums/thread.jspa?threadID=256965tstart=0 Kirk Wolf Dovetailed Technologies http://dovetail.com On Thu, Mar 7, 2013 at 9:39 AM, ESHEL Jonathan j.es...@rsd.com wrote: Hello list, Has anyone ever tried to use the JZOS batch launcher to launch a chain that needs to be APF authorized ? It was linked (at least the version I am using from JDK 6.0.1) with AC(0) and I wonder if there is an APF authorized equivalent for it such as BPXBATA2 compared to BPXBATSL ? Maybe another way to get around it ? Thanks a lot, Jonathan RSD SA -- 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
JZOS batch launcher (JVMLDMxx) APF ?
Hello list, Has anyone ever tried to use the JZOS batch launcher to launch a chain that needs to be APF authorized ? It was linked (at least the version I am using from JDK 6.0.1) with AC(0) and I wonder if there is an APF authorized equivalent for it such as BPXBATA2 compared to BPXBATSL ? Maybe another way to get around it ? Thanks a lot, Jonathan RSD SA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
