Re: class C3 commands taking long
Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- 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: class C3 commands taking long
Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.comwrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- 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
Re: class C3 commands taking long
baby eklavya wrote: Any idea why MVS class C3 commands take so long to execute . While I see it is probably ROUTE command, where is 'class C3' documented? It seems like console address space can't process more than 50 commands at a time . We had to clear the command queue often to relieve the contention . Check your limits in CONSOLxx. For example: MLIM, LOGLIM, RLIM as well as ROUTTIME too. Do you have any exits which handle the commands? Or is your system just too busy? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSort support for REXX E15?
The issue is not how to invoke DFSORT thru rexx - LINKMVS works fine (though it is sad that DFSORT does not support the alternate DDNAME parameter). I wish to sort all dsnames that fit pattern prefix.Dyyymmdd.Thhmmss. As these are not GDG's, JCL alone will not do the job. I need step (1), find the matches, (2) create a sortin, (3) deal with more than 255 instances (or whatever is the DDNAME CONCAT maximum, etc. Or I can write an E15 that allocates and reads each one at a time. And I wish an all rexx solution. I ended up having step (1) combine them all into one big file and then doing a SORT. But it adds an extra pass across all of the data. On Sun, 23 Feb 2014 19:19:48 -0800 Sri h Kolusu skol...@us.ibm.com wrote: :Hi, : :Here are a couple of examples that show how to invoke DFSORT from REXX. : :http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/11.3? : :Further if you have any questions please let us know : :Kolusu :DFSORT Development :IBM Corporation : :IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on :02/23/2014 01:19:10 AM: : : From: Binyamin Dissen bdis...@dissensoftware.com : To: IBM-MAIN@listserv.ua.edu, : Date: 02/23/2014 01:19 AM : Subject: DFSort support for REXX E15? : Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu : : I want to run a sort for a series of files that fit a dsname pattern. : : The simple approach would be an E15 which runs thru the list of files, :and : rexx is simpler than assembler. : : Seems like SYNCSORT has had that option for a while. : : -- : Binyamin Dissen bdis...@dissensoftware.com : http://www.dissensoftware.com : : Director, Dissen Software, Bar Grill - Israel : : : Should you use the mailblocks package and expect a response from me, : you should preauthorize the dissensoftware.com domain. : : I very rarely bother responding to challenge/response systems, : especially those from irresponsible companies. : : -- : 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 -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSort support for REXX E15?
You got it, though I was referring to standard non-compiled rexx. On Sun, 23 Feb 2014 22:51:27 -0600 Ed Gould edgould1...@comcast.net wrote: :Hi: : :Maybe I am misunderstanding the original op statement. :I *THOUGHT* that the original op was doing : : sort field=(1,5,ch,a) : sort e15=(rexxe15,...) : end :// :Somewhere before this they had compiled a rexx program (using the :rexx compiler) :Is that what the original op did, if not could he explain clearer? : :Ed : : : :On Feb 23, 2014, at 9:19 PM, Sri h Kolusu wrote: : : Hi, : : Here are a couple of examples that show how to invoke DFSORT from : REXX. : : http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ : ice1ca60/11.3? : : Further if you have any questions please let us know : : Kolusu : DFSORT Development : IBM Corporation : : IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on : 02/23/2014 01:19:10 AM: : : From: Binyamin Dissen bdis...@dissensoftware.com : To: IBM-MAIN@listserv.ua.edu, : Date: 02/23/2014 01:19 AM : Subject: DFSort support for REXX E15? : Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu : : I want to run a sort for a series of files that fit a dsname pattern. : : The simple approach would be an E15 which runs thru the list of : files, : and : rexx is simpler than assembler. : : Seems like SYNCSORT has had that option for a while. : : -- : Binyamin Dissen bdis...@dissensoftware.com : http://www.dissensoftware.com : : Director, Dissen Software, Bar Grill - Israel : : : Should you use the mailblocks package and expect a response from me, : you should preauthorize the dissensoftware.com domain. : : I very rarely bother responding to challenge/response systems, : especially those from irresponsible companies. : : - : - : 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 -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: class C3 commands taking long
We submitted a batch job having around 60 - 70 vary commands routed to 3 LPARS using COMMAND statement and we saw that the commands were queued up for long . A display of GRS contention showed that there was a system level enq on SYSZMCS by the console address space . The route commands were processing really slow and we had to remove the commands using CMDS REMOVE . Is there a real problem or is this something normal when several route commands are queued for execution ? ,Below is a sample of our CONSOLxx definitions and it is same across each LPAR in the plex . SYSP100 TYPE=MCS STATUS=ACT-SYSP DEFINED=(SYSP) MATCHED=(SYSP) ATTRIBUTES ON SYSP AUTH=(MASTER)CMDSYS=*NBUF=0 DEV=0211 LOGON=OPTIONAL USERID=N/A MFORM=(T,S,J)AREA=(Z)PFKTAB=PFKTAB00 USE=FC DEL=RD RTME=1RNUM=20 SEG=20CON=N LEVEL=(ALL) MONITOR=(JOBNAMES) INTIDS=N UNKNIDS=N ROUT=(1-10,12-128) MSCOPE=(*) On Mon, Feb 24, 2014 at 2:19 PM, Jake anderson justmainfra...@gmail.comwrote: Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.com wrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- 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
Re: class C3 commands taking long
It is documented in MVS system Commands manual - under Command Flooding section http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieag100%2Fiea2g1b134.htm We dont have any exits in place to handle commands . But the manuals states only 50 commands can run in console/master address space at a time . So obviously it was wrong to run 70 + commands in batch . But even after resubmitting the jobs with less than 50 commands at a time later on , it was still taking time to complete . On Mon, Feb 24, 2014 at 3:41 PM, baby eklavya baby.ekla...@gmail.comwrote: We submitted a batch job having around 60 - 70 vary commands routed to 3 LPARS using COMMAND statement and we saw that the commands were queued up for long . A display of GRS contention showed that there was a system level enq on SYSZMCS by the console address space . The route commands were processing really slow and we had to remove the commands using CMDS REMOVE . Is there a real problem or is this something normal when several route commands are queued for execution ? ,Below is a sample of our CONSOLxx definitions and it is same across each LPAR in the plex . SYSP100 TYPE=MCS STATUS=ACT-SYSP DEFINED=(SYSP) MATCHED=(SYSP) ATTRIBUTES ON SYSP AUTH=(MASTER)CMDSYS=*NBUF=0 DEV=0211 LOGON=OPTIONAL USERID=N/A MFORM=(T,S,J)AREA=(Z)PFKTAB=PFKTAB00 USE=FC DEL=RD RTME=1RNUM=20 SEG=20CON=N LEVEL=(ALL) MONITOR=(JOBNAMES) INTIDS=N UNKNIDS=N ROUT=(1-10,12-128) MSCOPE=(*) On Mon, Feb 24, 2014 at 2:19 PM, Jake anderson justmainfra...@gmail.comwrote: Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.com wrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- 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
Re: class C3 commands taking long
Can you share your Contention output ? How long is it happening ? Recently ? On Mon, Feb 24, 2014 at 3:50 PM, baby eklavya baby.ekla...@gmail.comwrote: It is documented in MVS system Commands manual - under Command Flooding section http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieag100%2Fiea2g1b134.htm We dont have any exits in place to handle commands . But the manuals states only 50 commands can run in console/master address space at a time . So obviously it was wrong to run 70 + commands in batch . But even after resubmitting the jobs with less than 50 commands at a time later on , it was still taking time to complete . On Mon, Feb 24, 2014 at 3:41 PM, baby eklavya baby.ekla...@gmail.com wrote: We submitted a batch job having around 60 - 70 vary commands routed to 3 LPARS using COMMAND statement and we saw that the commands were queued up for long . A display of GRS contention showed that there was a system level enq on SYSZMCS by the console address space . The route commands were processing really slow and we had to remove the commands using CMDS REMOVE . Is there a real problem or is this something normal when several route commands are queued for execution ? ,Below is a sample of our CONSOLxx definitions and it is same across each LPAR in the plex . SYSP100 TYPE=MCS STATUS=ACT-SYSP DEFINED=(SYSP) MATCHED=(SYSP) ATTRIBUTES ON SYSP AUTH=(MASTER)CMDSYS=*NBUF=0 DEV=0211 LOGON=OPTIONAL USERID=N/A MFORM=(T,S,J)AREA=(Z)PFKTAB=PFKTAB00 USE=FC DEL=RD RTME=1RNUM=20 SEG=20CON=N LEVEL=(ALL) MONITOR=(JOBNAMES) INTIDS=N UNKNIDS=N ROUT=(1-10,12-128) MSCOPE=(*) On Mon, Feb 24, 2014 at 2:19 PM, Jake anderson justmainfra...@gmail.com wrote: Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.com wrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP: 526-021-50-88. Wed ug stanu na dzie 01.01.2014 r. kapita zak adowy mBanku S.A. (w ca o ci wp acony) wynosi 168.696.052 z ote. -- 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: Convert Tcp/IP translate tables from binary to source
On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: class C3 commands taking long
ISG343I 17.28.56 GRS STATUS 866 S=SYSTEM SYSZMCS ROUTE-GROUP--CNID SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS SYSP CONSOLE0009 00775078 EXCLUSIVEOWN SYSP CONSOLE0009 00785400 EXCLUSIVEWAIT SYSP CONSOLE0009 0077C140 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB830 EXCLUSIVEWAIT SYSP CONSOLE0009 008EBDE0 EXCLUSIVEWAIT SYSP CONSOLE0009 00785A90 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB610 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB478 EXCLUSIVEWAIT SYSP CONSOLE0009 008EF590 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB218 EXCLUSIVEWAIT SYSP CONSOLE0009 008EF268 EXCLUSIVEWAIT SYSP CONSOLE0009 008EDB80 EXCLUSIVEWAIT SYSP CONSOLE0009 008ED960 EXCLUSIVEWAIT SYSP CONSOLE0009 0076B470 EXCLUSIVEWAIT SYSP CONSOLE0009 0076B738 EXCLUSIVEWAIT On Mon, Feb 24, 2014 at 3:53 PM, Jake anderson justmainfra...@gmail.comwrote: Can you share your Contention output ? How long is it happening ? Recently ? On Mon, Feb 24, 2014 at 3:50 PM, baby eklavya baby.ekla...@gmail.com wrote: It is documented in MVS system Commands manual - under Command Flooding section http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieag100%2Fiea2g1b134.htm We dont have any exits in place to handle commands . But the manuals states only 50 commands can run in console/master address space at a time . So obviously it was wrong to run 70 + commands in batch . But even after resubmitting the jobs with less than 50 commands at a time later on , it was still taking time to complete . On Mon, Feb 24, 2014 at 3:41 PM, baby eklavya baby.ekla...@gmail.com wrote: We submitted a batch job having around 60 - 70 vary commands routed to 3 LPARS using COMMAND statement and we saw that the commands were queued up for long . A display of GRS contention showed that there was a system level enq on SYSZMCS by the console address space . The route commands were processing really slow and we had to remove the commands using CMDS REMOVE . Is there a real problem or is this something normal when several route commands are queued for execution ? ,Below is a sample of our CONSOLxx definitions and it is same across each LPAR in the plex . SYSP100 TYPE=MCS STATUS=ACT-SYSP DEFINED=(SYSP) MATCHED=(SYSP) ATTRIBUTES ON SYSP AUTH=(MASTER)CMDSYS=*NBUF=0 DEV=0211 LOGON=OPTIONAL USERID=N/A MFORM=(T,S,J)AREA=(Z)PFKTAB=PFKTAB00 USE=FC DEL=RD RTME=1RNUM=20 SEG=20CON=N LEVEL=(ALL) MONITOR=(JOBNAMES) INTIDS=N UNKNIDS=N ROUT=(1-10,12-128) MSCOPE=(*) On Mon, Feb 24, 2014 at 2:19 PM, Jake anderson justmainfra...@gmail.com wrote: Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.com wrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not
Re: class C3 commands taking long
This looks to be similar to your issue : http://www-01.ibm.com/support/docview.wss?uid=isg1OA18994 On Mon, Feb 24, 2014 at 4:02 PM, baby eklavya baby.ekla...@gmail.comwrote: ISG343I 17.28.56 GRS STATUS 866 S=SYSTEM SYSZMCS ROUTE-GROUP--CNID SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS SYSP CONSOLE0009 00775078 EXCLUSIVEOWN SYSP CONSOLE0009 00785400 EXCLUSIVEWAIT SYSP CONSOLE0009 0077C140 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB830 EXCLUSIVEWAIT SYSP CONSOLE0009 008EBDE0 EXCLUSIVEWAIT SYSP CONSOLE0009 00785A90 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB610 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB478 EXCLUSIVEWAIT SYSP CONSOLE0009 008EF590 EXCLUSIVEWAIT SYSP CONSOLE0009 008EB218 EXCLUSIVEWAIT SYSP CONSOLE0009 008EF268 EXCLUSIVEWAIT SYSP CONSOLE0009 008EDB80 EXCLUSIVEWAIT SYSP CONSOLE0009 008ED960 EXCLUSIVEWAIT SYSP CONSOLE0009 0076B470 EXCLUSIVEWAIT SYSP CONSOLE0009 0076B738 EXCLUSIVEWAIT On Mon, Feb 24, 2014 at 3:53 PM, Jake anderson justmainfra...@gmail.com wrote: Can you share your Contention output ? How long is it happening ? Recently ? On Mon, Feb 24, 2014 at 3:50 PM, baby eklavya baby.ekla...@gmail.com wrote: It is documented in MVS system Commands manual - under Command Flooding section http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieag100%2Fiea2g1b134.htm We dont have any exits in place to handle commands . But the manuals states only 50 commands can run in console/master address space at a time . So obviously it was wrong to run 70 + commands in batch . But even after resubmitting the jobs with less than 50 commands at a time later on , it was still taking time to complete . On Mon, Feb 24, 2014 at 3:41 PM, baby eklavya baby.ekla...@gmail.com wrote: We submitted a batch job having around 60 - 70 vary commands routed to 3 LPARS using COMMAND statement and we saw that the commands were queued up for long . A display of GRS contention showed that there was a system level enq on SYSZMCS by the console address space . The route commands were processing really slow and we had to remove the commands using CMDS REMOVE . Is there a real problem or is this something normal when several route commands are queued for execution ? ,Below is a sample of our CONSOLxx definitions and it is same across each LPAR in the plex . SYSP100 TYPE=MCS STATUS=ACT-SYSP DEFINED=(SYSP) MATCHED=(SYSP) ATTRIBUTES ON SYSP AUTH=(MASTER)CMDSYS=*NBUF=0 DEV=0211 LOGON=OPTIONAL USERID=N/A MFORM=(T,S,J)AREA=(Z)PFKTAB=PFKTAB00 USE=FC DEL=RD RTME=1RNUM=20 SEG=20CON=N LEVEL=(ALL) MONITOR=(JOBNAMES) INTIDS=N UNKNIDS=N ROUT=(1-10,12-128) MSCOPE=(*) On Mon, Feb 24, 2014 at 2:19 PM, Jake anderson justmainfra...@gmail.com wrote: Ok this for ROUTE Command in CONSOLE.. it would vary from shop to shop and time depends upon the configuration.(CONSOLxx). So in your Shop, how long does it takes ? On Mon, Feb 24, 2014 at 1:58 PM, baby eklavya baby.ekla...@gmail.com wrote: Class C3 commands are ordinary attached commands that run in the CONSOLE address space . Such as Route commands On Mon, Feb 24, 2014 at 1:01 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-02-24 01:14, baby eklavya pisze: Hello , Any idea why MVS class C3 commands take so long to execute . What is class C3? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale usun t wiadomo w czaj c w to wszelkie
Re: IBM assembler copybook
On Mon, 24 Feb 2014 18:15:07 +1100 Wayne Bickerdike wayn...@gmail.com wrote: :ASM to PL/I should be quite simple. :PL3 becomes FIXED DEC(3,0) etc. Not (5,?) ? :CL6 becomes CHAR(6), : :BL1 becomes BIT(8) (I think) : : : : :On Mon, Feb 24, 2014 at 12:35 PM, Ron Thomas ron5...@gmail.com wrote: : : We have fileaid and i belive it only supports cobol and PL/1. Can this : copybook be converted to PL/1 and whether we can edit the bit maps and : manupulate the same , i.e 1 byte 8 bits and each bit whether we can edit : something ? : : Thanks : Ron T : : -- : For IBM-MAIN subscribe / signoff / archive access instructions, : send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN : -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: class C3 commands taking long
baby eklavya wrote: ISG343I 17.28.56 GRS STATUS 866 S=SYSTEM SYSZMCS ROUTE-GROUP--CNID SYSNAMEJOBNAME ASID TCBADDR EXC/SHRSTATUS SYSP CONSOLE0009 00775078 EXCLUSIVEOWN SYSP CONSOLE0009 00785400 EXCLUSIVEWAIT Hmm, so you want to do over 50 commands on all LPARS together with the ROUTE commands? That limit is there to prevent a standstill on your SysPlex. There is one simple solution: Use a timer to spread up your command load. Do your commands on one LPAR, wait and then next LPAR, etc. Or do one command(s) with/without ROUTE, wait and do next command, etc. The same goes for IPL: spread up your command workload to avoid IPL problems with STCs starting up in wrong sequences. PS: Thanks, now I know what is C3 class commands as seen from this thread. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
In aa6ff5ba011f44418bf62c515f71757d21bed...@ch2wpexch1.na.ds.ussco.com, on 02/21/2014 at 07:58 PM, Chase, John jch...@ussco.com said: We think we have a diagnosis; waiting for the programmer to compile/link the suggested change and verify operation. If resolved, I'll post the diagnosis we came up with. But the diagnosis we came up with raised two questions: Q1: Where does the system place the PARM= string when the program is loaded from a PDSE? Q2: Where does the system place the PARM= string when the program is loaded from a PDS? Our tentative diagnosis depends on there being a difference. That doesn't make much sense; The Initiator processes the PARM *before* it attaches the job step. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CamelCase Field Names (Was: Re: HLASM continuation...)
Rats, sorry. Meant for assembler-list. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CamelCase Field Names (Was: Re: HLASM continuation...)
The DSECTs have improved greatly in recent years, but the executed macro-language statements are often plain wrong, Examples, please? We're unlikely to correct something that we don't know is broken. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
SLR R0,R0 IC R1,0(,R1) CHI R1,=H'13' BNE ... Ignoring that this is lousy code (unless, perhaps, the value is looked at again, in which case having it in a reg could be advantageous), I hope that this was a slightly incomplete snippet, or a typo; R1 needs to be zeroed for the IC/CHI, not R0. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Convert Tcp/IP translate tables from binary to source
It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why does a dataset that should never migrate does occassionally (hsm)
Hi Mike, i think you have 2 basic problems. The first is that primary days in your mgmtclas definition is set to blank, and as far as hsm is concerned, the default is 2 days if there is no entry. Which leads onto the second problem, and it looks like your job scheduler allocates but does not open the dataset until it needs its, so the last referenced date field does not get updated untill you run your plans or a job is submitted from it (if its a job library). Getting migrated is a big indicator that the dsn is free at that point and not allocated. As per other repliers, checking the hsm logs for the dataset will tell you the reason for the migration. Also, as the other repliers have said, the simple way round it is to change the mgmtclass to one where primary days is a decent figure (i.e ) or cmd/migrate is none. If you've already got suitable mgmtclas's available, a simple alter against the dataset can change it and bring in your new one. kind regards Dave *** Hi, we have a mainframe dataset that is used daily used in our automated scheduling processes. Occassionally, our ops support gets paged out because a process is delayed and it turns out it was because said dataset was migrated and had to be recalled. this dataset's management class has nolimit on expires, and blanks for 'Primary Days' Partial Release is 'yes' so could hsm be migrating this dsn in Primary space mgmt, despite we have primary-days set to blanks??? And if so, short of setting partial release to no, how can we keep an sms managed dataset from ever migrating at all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Convert Tcp/IP translate tables from binary to source
Out of curiosity, exactly where do you see the lowercase letter e? Is it on a separate line, or between the hex numbers on each line? Or are you referring to the file produced by CONVXLAT? I tested it with TCIP.STANDARD.TCPXLBIN, and it looks ok on my system. I also ran CONVXLAT with the resulting file and it produced an identical binary table. Bill On Mon, 24 Feb 2014 15:10:06 +0200, Gadi wrote: It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Convert Tcp/IP translate tables from binary to source
I see the e in the first character on every line and then between each pair of hex characters The first line looks like this: e00e01e02e03e37e2De2Ee2Fe16e05e25e0Be0Ce0De0Ee0F Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source Out of curiosity, exactly where do you see the lowercase letter e? Is it on a separate line, or between the hex numbers on each line? Or are you referring to the file produced by CONVXLAT? I tested it with TCIP.STANDARD.TCPXLBIN, and it looks ok on my system. I also ran CONVXLAT with the resulting file and it produced an identical binary table. Bill On Mon, 24 Feb 2014 15:10:06 +0200, Gadi wrote: It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
On Mon, Feb 24, 2014 at 7:06 AM, Peter Relson rel...@us.ibm.com wrote: SLR R0,R0 IC R1,0(,R1) CHI R1,=H'13' BNE ... Ignoring that this is lousy code (unless, perhaps, the value is looked at again, in which case having it in a reg could be advantageous), I hope that this was a slightly incomplete snippet, or a typo; R1 needs to be zeroed for the IC/CHI, not R0. Peter Relson It was a typo on my part. The IC and CHI were for R0, not R1. I am guessing that the compiler has a template for this which can also be used with wchar characters and so generates something that will work with them too (in general, just replacing the IC with a ICM for a wchar?). As I think I said in the original post, I failed compiler class in college. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Convert Tcp/IP translate tables from binary to source
I was able to reproduce your problem with the e characters. If this command (which is what I wrote): od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 was entered with an e after the quotes, like this: od -An -tx1 -j256 xlbin_2 | tr -s ' ' e tcpx_2 or with a string beginning with e, like this: od -An -tx1 -j256 xlbin_2 | tr -s ' ' exit tcpx_2 then consecutive spaces will be reduced to one space and the one space will be changed to an e. A simple demonstration: echo 01 02 03 | tr -s 01 02 03 echo 01 02 03 | tr -s e e01e02e03 echo 01 02 03 | tr -s exit e01e02e03 It looks like you may have run the command a little differently than the way I gave it to you. Maybe my message got mangled in transit to you. It looks intact on the IBM-MAIN web interface. Bill On Mon, 24 Feb 2014 15:42:06 +0200, Gadi wrote: I see the e in the first character on every line and then between each pair of hex characters The first line looks like this: e00e01e02e03e37e2De2Ee2Fe16e05e25e0Be0Ce0De0Ee0F Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source Out of curiosity, exactly where do you see the lowercase letter e? Is it on a separate line, or between the hex numbers on each line? Or are you referring to the file produced by CONVXLAT? I tested it with TCIP.STANDARD.TCPXLBIN, and it looks ok on my system. I also ran CONVXLAT with the resulting file and it produced an identical binary table. Bill On Mon, 24 Feb 2014 15:10:06 +0200, Gadi wrote: It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSort support for REXX E15?
On Mon, 24 Feb 2014 07:35:10 +, Martin Packer wrote: I think the original question was about using REXX in an E15 exit (or equivalently an E35). This is something I've contemplated doing in the past but the required machinery is beyond me (or at least my patience). :-) I'm also not sure about performance and function : If each pass through the exit (once per record) causes a fresh REXX environment to be created, with fresh variables it's not good: It would be expensive. Some, though certainly not all, of this could be accomplished by connecting a POSIX pipe from the output of the Rexx script to SORTIN. It might suffice for the OP's need. Part of the charm of a REXX exit would be passing variables between invocations of the exit. On the upside there are lots of possibilities if a REXX exit - whether as a sample or as product function - were created. Such Rexx support would be valuable not only for DFSort but for many other z/OS utilities. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.9 under z/VM 6.3 on zBC12
I've got a few comments on this question/response; 1) WLM under zOS 1.9 isn't going to recognize any processor later than an z196, so you might have some interesting decisions made by it. 2) If you're using ICSF, it might not recognize CryptoExpress 4 cards. 3) Depending on your ISV software products, vendors might have problems generating license codes for an zEC12/zBC12 processor. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Westerman Sent: Monday, February 24, 2014 12:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 1.9 under z/VM 6.3 on zBC12 The short answer is yes. And you don't need to get the extended end of life updates for z/os 1.9 to do it. Brian -- 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: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Chase, John
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mike Bell
the first thing to check would be entry point - a non-zero entry point
is one of the easiest things to loose in a LKED.
ENTRY_POINT = LOAD_POINT, but the DB2 interface was the first CSECT in the
load module.
We think we have a diagnosis; waiting for the programmer to compile/link the
suggested change and
verify operation. If resolved, I'll post the diagnosis we came up with. But
the diagnosis we came up
with raised two questions:
Q1: Where does the system place the PARM= string when the program is loaded
from a PDSE?
Q2: Where does the system place the PARM= string when the program is loaded
from a PDS?
Our tentative diagnosis depends on there being a difference.
And absent confirmation or refutation of the proposition that the system passes
the PARM= string differently depending on whether the job step program is
loaded from a PDS vs a PDSE, we've concluded the following based on observation
and dump analysis:
1. The application program itself held the defect, in that it marked the end
of the PARM= string by moving a flag byte to the first byte after the PARM=
string: MVI PARMADDR+PARMLEN,x'80'.
2. For the decades when the application program resided in a PDS, it executed
without problem. We never knew the exact location of the PARM= string in
storage, because it never mattered. We weren't aware the program was broken;
therefore it was never fixed.
3. When the program was executed from a PDSE, IFF the length of the PARM=
string was exactly 16 (or perhaps any exact multiple of 8), the PARM= string
was passed to the application program with its last byte immediately preceding
the first instruction at the program's load point (which in this case was also
the program's entry point; the instruction is 90ECD00C STM 14,12,12(13).
4. The first CSECT in the load module is the DB2 High-level Language Interface
('HLI') stub, which was loaded at address x'7000'. The application
program's CSECT appeared at x'73B0', and its first instruction was also
90ECD00C.
5. At invocation, the DB2 HLI performed the STM 14,12,12(13) and did its
thing, eventually branching to the application program's CSECT.
6. After setting up standard linkage convention, the application program
proceeded to mark the end of the PARM= string via MVI PARMADDR+PARMLEN, x'80'
(which in the PDSE case with 16-byte parm overwrote the STM opcode in the DB2
HLI, changing it to SSM).
7. Later in its processing, the application program issued an EXEC SQL call,
which caused a branch to the DB2 HLI.
8. The DB2 HLI's first instruction having been changed to a privileged
instruction, the application abended S0C2 because it was not running in
supervisor state.
The fix was simple: Change the move of the flag byte to a compare of current
position within the PARM= string to its ending address.
We'd still like to know why loading the program from a PDSE apparently changed
how (and more importantly, where) the system passed the PARM= string.
-jc-
**
Information contained in this e-mail message and in any attachments thereto is
confidential. If you are not the intended recipient, please destroy this
message, delete any copies held on your systems, notify the sender immediately,
and refrain from using or disclosing all or any part of its content to any
other person.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
On Mon, Feb 24, 2014 at 9:02 AM, Chase, John jch...@ussco.com wrote: snip We'd still like to know why loading the program from a PDSE apparently changed how (and more importantly, where) the system passed the PARM= string. -jc- I would consider this explanation to be unlikely. The PARM is where it always was. But what _may_ have changed is where the program was loaded. I would consider it very likely that program fetch from a PDS is old code and program fetch from a PDSE is likely totally different code. Have you confirmed that the load address in both cases is the same and that the PARM address is different? Another thought could be that if the program is fetched to the same location, perhaps the initiator is doing something else which is causing a different set of STORAGE OBTAINs and RELEASEs which could affect where the free storage exists which is gotten for the PARM. So perhaps just being in a PDSE does cause a difference, but not a deliberate difference. It may be a just because difference. Just a couple of weird thoughts. Maybe I've been looking at weird HLASM generated code from the C compiler too long. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
john.archie.mck...@gmail.com (John McKown) writes: Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? two people from the Los Gatos VLSI lab originally did mainframe pascal for VLSI chip tools ... this goes on eventually to become the vs/pascal product. Amoung other things it was used to implement the original mainframe TCP/IP support. It originally had some performance issues ... getting around 44kbytes/sec throughput using 3090 processor. However, I did the RFC1044 changes and in some tuning tests at Cray Research got sustained channel media throughput between Cray and 4341 using only modest amount of the 4341 processor (possibly 500 times improvement in bytes moved per instruction executed). past posts mentioning doing rfc 1044 support http://www.garlic.com/~lynn/subnetwork.html#1044 One of the issues is the (pascal) implementation had none of the exploits that have been epidemic in c-language implementions ... observation it is about as hard for a programmer to *NOT* have such exploits in c-language as it is for a pascal programmer to have such problems. past posts mentioning c-language exploits http://www.garlic.com/~lynn/subintegrity.html#buffer in the period that IBM had gone into the red and was re-organized into the 13 baby blues in preparation for breaking up the company (until the board brought in Gerstner who reversed the breakup and resurrect the company) ... there was big move for business operations to get off of proprietary tools platforms. Part of this was to transfer proprietary tools to standard industry tool vendors and get them running on industry standar platforms. I had to do one such pascal 50,000+ lines of code vlsi application. Problem was that pascal on some of these other platforms appeared to have been used for little else than introduction to programming classes (one such platform was in the local area, but they had outsourced their pascal support to someplace 12 time zones away, located near a space launch center). -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Mon, Feb 24, 2014 at 9:02 AM, Chase, John jch...@ussco.com wrote: snip We'd still like to know why loading the program from a PDSE apparently changed how (and more importantly, where) the system passed the PARM= string. -jc- I would consider this explanation to be unlikely. The PARM is where it always was. But what _may_ have changed is where the program was loaded. I would consider it very likely that program fetch from a PDS is old code and program fetch from a PDSE is likely totally different code. Have you confirmed that the load address in both cases is the same and that the PARM address is different? Not with this specific program (remember, it never abended when loaded from a PDS). But generally, I've observed that the job step program (EXEC PGM=program) gets loaded on a page boundary, usually at the bottom of private region (x'7000' in our case) when below the line (and this application is AMODE(24) ). Another thought could be that if the program is fetched to the same location, perhaps the initiator is doing something else which is causing a different set of STORAGE OBTAINs and RELEASEs which could affect where the free storage exists which is gotten for the PARM. So perhaps just being in a PDSE does cause a difference, but not a deliberate difference. It may be a just because difference. Just a couple of weird thoughts. Maybe I've been looking at weird HLASM generated code from the C compiler too long. Speaking of weird thoughts, how's this: If loaded from a PDS, the PARM= buffer is 102 bytes long, with the parm length stored in the first halfword and the parm string left-justified. If loaded from a PDSE, the parm string is RIGHT-justified in the PARM= buffer so the first byte is on a doubleword boundary, and the parm length is prepended to it in the halfword immediately preceding the first byte of the PARM string. That is what appears to be happening, anyway. :-) -jc- You don't have the patent on weird. :-) ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MIH Setting for DS8100/DS8300
We randomly run into a problem where DFDSS Flashcopy gets an ADR935W error. Looking at the return/reason codes, it says it was unable to complete an establish request because of the request being canceled by system Missing Interrupt Handler (MIH) processing. We found that the output device on the flash was not listed in our IOS member. We thought we had all our DASD listed with 45 second times. Apparently, we missed some on our last upgrade. The book says you can use the word DASD with a time to set all DASD devices instead of listing them in ranges. That would make it a lot simpler. My questions are do we need to list the ranges individually or do we need to list them at all? It would seem we do need to code them since the error was that it timed out due to MIH processing. Thanks, Bobby Herring Texas Farm Bureau Insurance Waco, TX [http://infonet.txfb-ins.com//images//email-signature-image.jpg] WWW.TXFB-INS.COMhttp://www.txfb-ins.com CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. Texas Farm Bureau Insurance Companies received the highest numerical score among auto insurance providers in Texas in the proprietary J.D. Power 2013 U.S. Auto Insurance Study(SM). Study based on 45,521 total responses measuring 8 providers in Texas and measures opinions of consumers with their auto insurance provider. Proprietary study results are based on experiences and perceptions of consumers surveyed March –April 2013. Your experiences may vary. Visit jdpower.com. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
Again, my thanks to all for the help, which was my fault in not realizing
that I had used the -o switch instead of the -O switch and so was not
having my code optimized.
On the off chance that anybody was wondering why I was doing this, it was
just a test to try to determine the best way to see if a C string ended
with a \r, or carriage return. Why? Because sometimes people here goof up
and ftp a Windows file to the mainframe, but do it from a UNIX server.
Well, they don't, but we share an NAS box between Windows an Linux servers.
So the file on the z sometimes has an extraneous \r at the very end of the
line. One good thing this did for me was point out that I was really doing
it wrong. I found the address of the end of the string using with the code
argv[i]+strlen(argv[i]). But the strlen() code generated actually found
the end of the string using the SRST and then converted that to an integer
(size_t), which I then converted right back to an address. So I searched
and found the strchr() routine which can find the terminating null and
returns its address. Using this function resulted in a TRT in a loop. Which
I didn't much care for. So I looked at the memchr() function. But it
requires a maximum length. Now, since I'm looking for a \0. And since a
proper C string is \0 delimited, I _ASSuMEd_ that the string was properly
delimited. This allowed me to use an arbitrary length for the memchr()
call. So I used 0x7fff, or 2GiB. That seems more than large enough to
me.
The code is now:
for(i=0; iargc; i++) {
if ('\r'==*( (char *) memchr(argv[i],'\0',0x7fff)-1)
*( (char *) memchr(argv[i],'\0',0x7fff)-1) = '\0';
}
Of course, this would really be done after the fgets() call. The code
generated is lovely:
* if ('\r' == *(findend-1))
Lr5,(*)uchar*(r2,r1,0)
LR r6,r5
LA r0,0
AL r6,=F'2147483647'
SRST r6,r5
JO *-4
BL @1L13
LA r6,0
@1L13DS 0H
AHI r6,H'-1'
CLI (*)uchar(r6,0),13
BNE @1L5
**(findend-1)='\0';
MVI (*)uchar(r6,0),0
@1L5 DS 0H
where findend is:
#define findend (char *)memchr(argv[i],'\0',0x7fff) // for ease to
change method
I need to cast the (void *) from memchr() to a (char *) in order to
subtract 1 from it. Of course, this can S0C4 if the string is not \0
delimited. Or it could possibly corrupt a byte of innocent storage. But
this should not happen in my planned use since fgets() should return a
pointer to a \0 delimited string or NULL. And I _will_ check for NULL.
On Sat, Feb 22, 2014 at 11:16 PM, John McKown
john.archie.mck...@gmail.comwrote:
Just for fun, I wrote a very small C program. I compiled it on Linux/Intel
using GCC 4.8.2. I then got it compiled on z/OS 1.13. The program is very
small:
#include stdlib.h
#include stdio.h
#include string.h
#undef strlen
int main (int argc, char *argv[]) {
int i;
for(i=0;iargc;i++) {
if ('\r' == *(argv[i]+strlen(argv[i])) )
*(argv[i]+strlen(argv[i]))='\0';
}
return 0;
}
snip/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM assembler copybook
In 4528858360446052.wa.ron5174gmail@listserv.ua.edu, on 02/23/2014 at 11:23 AM, Ron Thomas ron5...@gmail.com said: Hello. I am new to assembler so not sure whether i am asking the right query? We have a assembler copybook and the corresponding file is a VSAM KSDS. I'm not sure what you mean by a copybook. My best guess is that you mean a member in SYSLIB that contains a DSECT mapping the records in the file, rather than an ACB for the file. Are you looking for a utility that will take a DSECT or the ADATA from assembling a DSECT and use it to produce a formatted listing of the file? If not, what are you asking for? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
In 1068899486.316495.1393186164299.javamail.r...@comcast.net, on 02/23/2014 at 08:09 PM, DASDBILL2 dasdbi...@comcast.net said: Just for future reference, since the name of this list-server is IBM Mainframe Discussion List, what particular IBM systems, other than System/360 and its descendants, are also called mainframe systems? Large machines older than S/360, plus some non-IBM machines that would be out of scope here. Boundaries are fuzzy, but I'd call the 7000 series other than the 7010 mainframes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM assembler copybook
In cahtjz9lpe6q2ades818nb0a1pd1v3o2a27_7ktkptr3ctdo...@mail.gmail.com, on 02/24/2014 at 06:15 PM, Wayne Bickerdike wayn...@gmail.com said: ASM to PL/I should be quite simple. PL3 becomes FIXED DEC(3,0) etc. WTF? PL3 is 24 bits; that's 5 digits and a sign. Why would it not be DEC(5)? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
We'd still like to know why loading the program from a PDSE apparently changed how (and more importantly, where) the system passed the PARM= string. PDSEs are 4K page oriented, so when loaded, they are generally going to start at a 4K boundary. When loading from a PDS, fetch processing simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Mon, 24 Feb 2014 09:00:43 -0500, Shmuel Metz (Seymour J.) wrote: on 02/23/2014 at 08:09 PM, DASDBILL2 said: Just for future reference, since the name of this list-server is IBM Mainframe Discussion List, what particular IBM�systems, other than System/360 and its descendants, are also called mainframe systems? Large machines older than S/360, plus some non-IBM machines that would be out of scope here. ... Surely, when comparing technologies hardware and software from other vendors should not be considered off-charter. Hmmm... The PDP-6, for example, had no data channels. All I/O was performed by the CPU, usually in interrupt handlers. And the hardware architecture was such that such an interrupt handler could be coded in a single instruction (plus one more to dismiss the interrupt). An amusing idea with short life expectancy. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIH Setting for DS8100/DS8300
Bobby, From our default IEAIOSnn member. MIH DASD=01:00 HYPERPAV=YES ZHPF=YES Individual addresses can be used to override these values. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Herring, Bobby Sent: Monday, February 24, 2014 7:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] MIH Setting for DS8100/DS8300 We randomly run into a problem where DFDSS Flashcopy gets an ADR935W error. Looking at the return/reason codes, it says it was unable to complete an establish request because of the request being canceled by system Missing Interrupt Handler (MIH) processing. We found that the output device on the flash was not listed in our IOS member. We thought we had all our DASD listed with 45 second times. Apparently, we missed some on our last upgrade. The book says you can use the word DASD with a time to set all DASD devices instead of listing them in ranges. That would make it a lot simpler. My questions are do we need to list the ranges individually or do we need to list them at all? It would seem we do need to code them since the error was that it timed out due to MIH processing. Thanks, Bobby Herring Texas Farm Bureau Insurance Waco, TX [http://infonet.txfb-ins.com//images//email-signature-image.jpg] WWW.TXFB-INS.COMhttp://www.txfb-ins.com CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. Texas Farm Bureau Insurance Companies received the highest numerical score among auto insurance providers in Texas in the proprietary J.D. Power 2013 U.S. Auto Insurance Study(SM). Study based on 45,521 total responses measuring 8 providers in Texas and measures opinions of consumers with their auto insurance provider. Proprietary study results are based on experiences and perceptions of consumers surveyed March –April 2013. Your experiences may vary. Visit jdpower.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: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder We'd still like to know why loading the program from a PDSE apparently changed how (and more importantly, where) the system passed the PARM= string. PDSEs are 4K page oriented, so when loaded, they are generally going to start at a 4K boundary. When loading from a PDS, fetch processing simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). Correct. So that suggests that, when the program was loaded from a PDS, it got loaded at whatever doubleword-aligned address the GETMAIN happened to acquire, which was not necessarily on a page boundary. In fact, the load module is more than two pages in length but less than three pages, so it appears it was just lucky that the insertion of the flag byte at the end of the PARM string didn't cause (even) a S0C4. I think we discussed changing to VSM USEZOSV1R9RULES(NO) when we migrated from 1.9 to 1.11, but apparently it got lost in the shuffle. And now we're preparing for z/OS 2.1 (or its follow-on), from 1.13. I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. I think I've lost the link I had to documentation on USEZOSV1R9RULES; can you provide a current one, please? Thanks, -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: class C3 commands taking long
I've seen that happen issuing a lot of ROUTE commands from a batch job when the response of the command being routed was suppressed. Try adding T=0 to your ROUTE commands. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
paulgboul...@aim.com (Paul Gilmartin) writes: Surely, when comparing technologies hardware and software from other vendors should not be considered off-charter. re: http://www.garlic.com/~lynn/2014c.html#62 Optimization, CPU time, and related issues http://www.garlic.com/~lynn/2014c.html#64 Optimization, CPU time, and related issues http://www.garlic.com/~lynn/2014c.html#88 Optimization, CPU time, and related issues Stretch http://en.wikipedia.org/wiki/IBM_7030_Stretch Harvest http://en.wikipedia.org/wiki/IBM_7950_Harvest End of IBM Advanced Computing Systems ... includes Amdahls account of IBM executives terminating the project because they were afraid that it might advanced computing state-of-the-art too fast and they would loose control of the market ... at the end, it discusses some of the acs-360 features that show up more than 20yrs later in es/9000 http://people.cs.clemson.edu/~mark/acs_end.html because I had lots of access to early engineering 4341 ... i was periodically asked to do benchmarks ... including LLNL looking at having 70 4341 in a compute farm (4341 environmentals made it possible to deploy out in departmnental areas ... sort of leading edge of the coming distributed computing tsunmai ... and its price/performance got it increasing use for compute farms ... sort of the coming cluster supercomputers). ... some old 4341 email http://www.garlic.com/~lynn/lhwemail.html#43xx POK 3033 management at one point felt so threatened by 4341 cluster compute farms that they got internal allocation of critical 4341 manufacturing component cut in half recent post with old 158, 3031, 4341 comparisons for LLNL (about same as 3031 1/4-1/3 faster than 370/158) http://www.garlic.com/~lynn/2014c.html#61 I Must Have Been Dreaming (36-bit word needed for ballistics?) above also has numbers for 145, 168-3, 360/91 and cdc6600 (original commercial supercomputer) 370/158 vax have been used as baseline for Dhrystone benchmarks ... both doing appox. same number of iterations/sec ... considered to be approx. 1MIPS. some recent posts about BIPS benchmark comparisons: http://www.garlic.com/~lynn/2014.html#94 Santa has a Mainframe! http://www.garlic.com/~lynn/2014.html#97 Santa has a Mainframe! http://www.garlic.com/~lynn/2014b.html#27 IBM sells x86 server business to Levono http://www.garlic.com/~lynn/2014b.html#102 CPU time http://www.garlic.com/~lynn/2014c.html#22 US Federal Reserve pushes ahead with Faster Payments planning -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 quote | *VSM* *USEZOSV1R9RULES(NO|YES)* | YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from | its historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior | for user-region private area subpools that are both below and above | the line to be implemented. Thus DQEs can be merged where possible. | The default is YES to provide a seamless migration. However, IBM | recommends that you specify USEZOSV1R9RULES(NO) to obtain a | performance benefit for applications with long DQE/FQE chains for | user-region private area subpools. /quote On Mon, Feb 24, 2014 at 11:46 AM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jim Mulder We'd still like to know why loading the program from a PDSE apparently changed how (and more importantly, where) the system passed the PARM= string. PDSEs are 4K page oriented, so when loaded, they are generally going to start at a 4K boundary. When loading from a PDS, fetch processing simply does a GETMAIN for the storage. If the size of the module is at least 2 pages, but not a page multiple, the Getmained storage (and thus the load module) will be aligned to end on a 4K boundary if D DIAG shows VSM USEZOSV1R9RULES(YES) or it will be aligned to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) Your results suggest that you are using the default of VSM USEZOSV1R9RULES(YES). Correct. So that suggests that, when the program was loaded from a PDS, it got loaded at whatever doubleword-aligned address the GETMAIN happened to acquire, which was not necessarily on a page boundary. In fact, the load module is more than two pages in length but less than three pages, so it appears it was just lucky that the insertion of the flag byte at the end of the PARM string didn't cause (even) a S0C4. I think we discussed changing to VSM USEZOSV1R9RULES(NO) when we migrated from 1.9 to 1.11, but apparently it got lost in the shuffle. And now we're preparing for z/OS 2.1 (or its follow-on), from 1.13. I would expect the location of the PARM= string to be the same, regardless of PDS vs. PDSE. However, I would expect that changing the setting for VSM USEZOSV1R9RULES will change the location of the PARM= string. I think I've lost the link I had to documentation on USEZOSV1R9RULES; can you provide a current one, please? Thanks, -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
On 24 February 2014 10:44, Anne Lynn Wheeler l...@garlic.com wrote: two people from the Los Gatos VLSI lab originally did mainframe pascal for VLSI chip tools ... this goes on eventually to become the vs/pascal product. Amoung other things it was used to implement the original mainframe TCP/IP support. It originally had some performance issues ... getting around 44kbytes/sec throughput using 3090 processor. However, I did the RFC1044 changes and in some tuning tests at Cray Research got sustained channel media throughput between Cray and 4341 using only modest amount of the 4341 processor (possibly 500 times improvement in bytes moved per instruction executed). past posts mentioning doing rfc 1044 support You've mentioned this a number of times, but I don't think you've explained what you did to the Pascal code to get a 500x improvement. Was the original code exceptionally bad, was your new code exceptionally brilliant, did you take advantage of some knowledge of the VS Pascal code generator or were your changes applicable to code in any language...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
t...@harminc.net (Tony Harminc) writes: You've mentioned this a number of times, but I don't think you've explained what you did to the Pascal code to get a 500x improvement. Was the original code exceptionally bad, was your new code exceptionally brilliant, did you take advantage of some knowledge of the VS Pascal code generator or were your changes applicable to code in any language...? only a little of it was vs pascal specific ... most of it was doing fast pathing for the most common case. also the communication group had been doing a lots to try and make tcp/ip perform as badly as possible ... and as a result, there was little or no optimization. The other was they limited the channel attach box to a lan bridge ... so the translation from tcp/ip to LAN packets had to be done in the mainframe. I was able to channel attach a TCP/IP router box ... which eliminated a whole bunch of slow serialized processing in the mainframe code (and the channel attached router box was much higher performance than the communication group channel attached LAN bridge). http://www.garlic.com/~lynn/subnetwork.html#1044 i've also told the story about later ... the communication group subcontracting tcp/ip support implemented in vtam. the initial implementation had TCP throughput much faster than approx. equivalent LU6.2. The communication group told the subcontractor that everybody knows that a *CORRECT* implementation of TCP is much slower than LU6.2 and they would only be paying for a *CORRECT* implementation. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSort support for REXX E15?
Martin,
Thanks for clarifying what OP really wanted.
Binaymin Dissen,
Here are the answers to your questions.
Q.it is sad that DFSORT does not support the alternate DDNAME parameter).
Answer : DFSORT indeed supports alternate DDnames with option SORTDD.
SORTDD= Specifies a four-character prefix for the ddnames to be used
when you dynamically invoke DFSORT more than once in a program step. The
four characters replace SORT in the following ddnames: SORTIN, SORTOUT,
SORTINn, SORTINnn, SORTOFd, SORTOFdd, SORTWKd, SORTWKdd, SORTJNF1,
SORTJNF2 and SORTCNTL. This allows you to use a different set of ddnames
for each call to DFSORT.
Check this link which explains in detail about SORTDD here
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/3.14
Q.I wish to sort all dsnames that fit pattern prefix.Dyyymmdd.Thhmmss. As
these are not GDG's, JCL alone will not do the job. I need step (1), find
the
matches, (2) create a sortin, (3) deal with more than 255 instances (or
whatever is the DDNAME CONCAT maximum, etc. Or I can write an E15 that
allocates and reads each one at a time. And I wish an all rexx solution.I
ended up having step (1) combine them all into one big file and then doing
a
SORT. But it adds an extra pass across all of the data.
Answer : It is indeed possible with JCL as DFSORT can dynamically BUILD a
JCL and submit it via INTRDR reading the LISTCAT output. we can
dynamically create multiple steps concatenating DD's to the limit.
Here is a DFSORT JCL which will build a dynamic JCL reading the LISTCAT
output. A brief explanation of the job.
Step0100 : Run LISTCAT with LEVEL on your HLQ. This will get the results
like this
READY
LISTCAT LEVEL('KOLUSU') NAMES
NONVSAM --- KOLUSU.IPCS
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.AAA
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.ABD
...
NONVSAM --- KOLUSU.D0125.T1859
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0322.T2359
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0325.T0859
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0326.T0859
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0326.T0959
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0326.T2359
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T0859
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T0959
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1059
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1159
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1259
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1359
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1459
IN-CAT --- SYS1.BIG982.ICFCAT
NONVSAM --- KOLUSU.D0327.T1559
IN-CAT --- SYS1.BIG982.ICFCAT
Now our intention is to pick record with KOLUSU.Dyyy.Thhmm names.
The DSNAME start in position 17 for a length of 44. So we will use an
INCLUDE cond to pick all the desired records. You may need to adjust the
positions to suit your needs here. Just change the Include cond positions.
Once we picked the desired records, we use WHEN=GROUP to tag them to
step/concatenation limit and build a dynamic JCL. Now look at the output
from Step0200 SORTOUT DD. It should have generated the JCL need to sort
the records from the files that matched criteria. If the generated JCL
looks good then change the following statement //SORTOUT DD SYSOUT=* to
//SORTOUT DD SYSOUT=(*,INTRDR),RECFM=FB
//STEP0100 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=L,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE),
//DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)
//SYSTSIN DD *
LISTCAT LEVEL('KOLUSU') NAMES
//*
//STEP0200 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DISP=SHR,DSN=L
//SORTOUT DD SYSOUT=*
//SYSINDD *
OPTION COPY
INCLUDE COND=(01,7,CH,EQ,C'NONVSAM',AND,
24,1,CH,EQ,C'D',AND,
25,4,FS,EQ,NUM,AND,
30,1,CH,EQ,C'T',AND,
31,4,FS,EQ,NUM,AND,
35,1,CH,EQ,C' ')
INREC IFTHEN=(WHEN=INIT,BUILD=(C'//',9X,C'DD DISP=SHR,DSN=',17,44)),
IFTHEN=(WHEN=GROUP,RECORDS=254,PUSH=(81:ID=5,SEQ=3)),
IFTHEN=(WHEN=(86,3,ZD,EQ,1),OVERLAY=(3:C'SORTIN'))
OUTFIL REMOVECC,BUILD=(1,80),INCLUDE=(81,5,ZD,LT,255),
HEADER1=('//DYNJCL01 JOB (ACCNT,INFO),''','NAME''',',',/,
'// CLASS=A,',/,
'// MSGCLASS=H,',/,
'// MSGLEVEL=(1,1),',/,
'// TIME=NOLIMIT,',/,
'// NOTIFY=NAME',/, ,
'//*'),
SECTIONS=(81,5,
HEADER3=('//STP',81,5,' EXEC PGM=SORT',/,
'//SYSOUT DD SYSOUT=*'),
TRAILER3=('//*',/,
'//SORTOUT DD DSN=HLQ.STP',81,5,'.OUTPUT,',/,
'// DISP=(NEW,CATLG,DELETE),',/,
'//
Re: SOURCEID (again)
SMP/E releases before V3R5 cannot process the MCS input that is developed specifically for V3R5, nor can they process data in the SMPCSI data set. In SMP/E V3R4, if your SOURCEID value meets either of the following conditions, a message is shown to indicate that your operand contains a value that cannot be processed by the current release of SMP/E Your SOURCEID value is 9 to 64 characters in length. Your SOURCEID value contains a character other than uppercase alphabetic (A-Z), numeric (0-9), or national (@,#,$). Is the message mentioned GIM58903W? If not, which? GIM34401I (THE operand OPERAND CONTAINS A VALUE THAT CANNOT BE PROCESSED BY THE CURRENT RELEASE OF SMP/E. SMP/E VERSION ver RELEASE rel (OR HIGHER) IS REQUIRED.) (I can't find doc for SMP/E 3.4.) Was toleration for long SOURCEIDs introduced by APAR for earlier than SMP/E 3.5? Which APAR? SMP/E V3.3 and V3.4, PTF UO00700 and UO00701, APAR IO07480. Or does the above apply only when SMP/E 3.4 attempts to process a long SOURCEID in a CSI that needs upgrade? How far back, chronologically and in z/OS release, do support and/or toleration for long SOURCEIDs extend? SMP/E V3.3 is part of z/OS V1.6, so with APAR IO07480, z/OS V1.6 will tolerate long sourceids. (BTW, I was told here lately that there's no limit on number of SOURCEIDs for a SYSMOD. But apparently too many can cause operational difficulties: GIM25903E SMP/E COULD NOT ADD ++ASSIGN SOURCEID sourceid TO SYSMOD ENTRY sysmod BECAUSE THE NUMBER OF ELEMENTS IN THE ENTRY EXCEEDED THE CURRENT PEMAX VALUE. apparently there's a workaround. Probably not a practical concern.) The max is 32,767, so its not a practical concern, that's why you were told there is no limit. Why oh why are you asking questions about this old stuff? All currently supported releases of SMP/E and z/OS support long sourceids. The last release of z/OS that only tolerated long sourceids was V1.9 (contained SMP/E V3.4), which ended service support in September 2010. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SOURCEID (again)
On Mon, 24 Feb 2014 14:13:04 -0500, Kurt Quackenbush wrote: Why oh why are you asking questions about this old stuff? All currently supported releases of SMP/E and z/OS support long sourceids. The last release of z/OS that only tolerated long sourceids was V1.9 (contained SMP/E V3.4), which ended service support in September 2010. We have downlevel customers from whom we try to wring the last penny of revenue. Other ISVs frequenting these lists have described similar practices: Why don't you use ...? Some of our customers might not have that! Thanks for the APAR numbers. And some of the language I read suggests that even customers running the latest SMP/E, but with a non-upgraded CSI may encounter problems. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
Was the original code exceptionally bad, was your new code exceptionally brilliant, When I worked on Strobe we saw this all of the time. One shop saw job runtime drop from 24 hours to eight minutes. We could only wonder what they had done in the first place. Bob Shannon Ex-Programart -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DSLIST block commands [was: Deleting multiple data sets]
Woo Hoo, Elardus! After all these years of griping about having to use an X on many lines of DSLIST results, you've pointed out my lack of investigation. //X ... // works beautifully! Tks *very* much. signature = 6 lines follows Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 -Original Message- From: Elardus Engelbrecht [mailto:elardus.engelbre...@sita.co.za] Sent: February 21, 2014 04:16 Subject: Re: Deleting multiple data sets Paul Gilmartin wrote: [snip] o Type D in front of each on a DSLIST menu. Why? Use //D before first DSN and // at last one in =3.4 list. Turn off confirmation before that or just at the first DSN. [snip] Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Convert Tcp/IP translate tables from binary to source
Hi Bill, I see the problem, It looks like the exit oget 'tcpx_2' tcpx2 lines were concatinated to the end of the od command. Since I wasn't sure what was being done, I just copied and pasted. I will try again tommorow, and see what happpens. Thanks for your help Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey [yak36...@yahoo.com] Sent: 24 February 2014 16:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source I was able to reproduce your problem with the e characters. If this command (which is what I wrote): od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 was entered with an e after the quotes, like this: od -An -tx1 -j256 xlbin_2 | tr -s ' ' e tcpx_2 or with a string beginning with e, like this: od -An -tx1 -j256 xlbin_2 | tr -s ' ' exit tcpx_2 then consecutive spaces will be reduced to one space and the one space will be changed to an e. A simple demonstration: echo 01 02 03 | tr -s 01 02 03 echo 01 02 03 | tr -s e e01e02e03 echo 01 02 03 | tr -s exit e01e02e03 It looks like you may have run the command a little differently than the way I gave it to you. Maybe my message got mangled in transit to you. It looks intact on the IBM-MAIN web interface. Bill On Mon, 24 Feb 2014 15:42:06 +0200, Gadi wrote: I see the e in the first character on every line and then between each pair of hex characters The first line looks like this: e00e01e02e03e37e2De2Ee2Fe16e05e25e0Be0Ce0De0Ee0F Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source Out of curiosity, exactly where do you see the lowercase letter e? Is it on a separate line, or between the hex numbers on each line? Or are you referring to the file produced by CONVXLAT? I tested it with TCIP.STANDARD.TCPXLBIN, and it looks ok on my system. I also ran CONVXLAT with the resulting file and it produced an identical binary table. Bill On Mon, 24 Feb 2014 15:10:06 +0200, Gadi wrote: It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
Excellent forensics. And thanks for the detailed explanation.
Bill Fairchild
- Original Message -
From: John Chase jch...@ussco.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, February 24, 2014 9:02:54 AM
Subject: Re: S0C2 in DB2 application program (was Stored Procedure) IFF run
from a PDSE
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Chase, John
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mike Bell
the first thing to check would be entry point - a non-zero entry point
is one of the easiest things to loose in a LKED.
ENTRY_POINT = LOAD_POINT, but the DB2 interface was the first CSECT in the
load module.
We think we have a diagnosis; waiting for the programmer to compile/link the
suggested change and
verify operation. If resolved, I'll post the diagnosis we came up with. But
the diagnosis we came up
with raised two questions:
Q1: Where does the system place the PARM= string when the program is loaded
from a PDSE?
Q2: Where does the system place the PARM= string when the program is loaded
from a PDS?
Our tentative diagnosis depends on there being a difference.
And absent confirmation or refutation of the proposition that the system passes
the PARM= string differently depending on whether the job step program is
loaded from a PDS vs a PDSE, we've concluded the following based on observation
and dump analysis:
1. The application program itself held the defect, in that it marked the end
of the PARM= string by moving a flag byte to the first byte after the PARM=
string: MVI PARMADDR+PARMLEN,x'80'.
2. For the decades when the application program resided in a PDS, it executed
without problem. We never knew the exact location of the PARM= string in
storage, because it never mattered. We weren't aware the program was broken;
therefore it was never fixed.
3. When the program was executed from a PDSE, IFF the length of the PARM=
string was exactly 16 (or perhaps any exact multiple of 8), the PARM= string
was passed to the application program with its last byte immediately preceding
the first instruction at the program's load point (which in this case was also
the program's entry point; the instruction is 90ECD00C STM 14,12,12(13).
4. The first CSECT in the load module is the DB2 High-level Language Interface
('HLI') stub, which was loaded at address x'7000'. The application
program's CSECT appeared at x'73B0', and its first instruction was also
90ECD00C.
5. At invocation, the DB2 HLI performed the STM 14,12,12(13) and did its
thing, eventually branching to the application program's CSECT.
6. After setting up standard linkage convention, the application program
proceeded to mark the end of the PARM= string via MVI PARMADDR+PARMLEN, x'80'
(which in the PDSE case with 16-byte parm overwrote the STM opcode in the DB2
HLI, changing it to SSM).
7. Later in its processing, the application program issued an EXEC SQL call,
which caused a branch to the DB2 HLI.
8. The DB2 HLI's first instruction having been changed to a privileged
instruction, the application abended S0C2 because it was not running in
supervisor state.
The fix was simple: Change the move of the flag byte to a compare of current
position within the PARM= string to its ending address.
We'd still like to know why loading the program from a PDSE apparently changed
how (and more importantly, where) the system passed the PARM= string.
-jc-
**
Information contained in this e-mail message and in any attachments thereto is
confidential. If you are not the intended recipient, please destroy this
message, delete any copies held on your systems, notify the sender immediately,
and refrain from using or disclosing all or any part of its content to any
other person.
--
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: IBM assembler copybook
Your guess is correct. Copybook is the way most Assembler programmers for DOS/360 or VSE systems pronounce DSECT. Bill Fairchild - Original Message - From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, February 24, 2014 7:53:29 AM Subject: Re: IBM assembler copybook In 4528858360446052.wa.ron5174gmail@listserv.ua.edu, on 02/23/2014 at 11:23 AM, Ron Thomas ron5...@gmail.com said: Hello. I am new to assembler so not sure whether i am asking the right query? We have a assembler copybook and the corresponding file is a VSAM KSDS. I'm not sure what you mean by a copybook. My best guess is that you mean a member in SYSLIB that contains a DSECT mapping the records in the file, rather than an ACB for the file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
I bet if you timed it the strchr() TRT in a loop is faster.
On 25/02/2014, at 12:19 AM, John McKown john.archie.mck...@gmail.com wrote:
Again, my thanks to all for the help, which was my fault in not realizing
that I had used the -o switch instead of the -O switch and so was not
having my code optimized.
On the off chance that anybody was wondering why I was doing this, it was
just a test to try to determine the best way to see if a C string ended
with a \r, or carriage return. Why? Because sometimes people here goof up
and ftp a Windows file to the mainframe, but do it from a UNIX server.
Well, they don't, but we share an NAS box between Windows an Linux servers.
So the file on the z sometimes has an extraneous \r at the very end of the
line. One good thing this did for me was point out that I was really doing
it wrong. I found the address of the end of the string using with the code
argv[i]+strlen(argv[i]). But the strlen() code generated actually found
the end of the string using the SRST and then converted that to an integer
(size_t), which I then converted right back to an address. So I searched
and found the strchr() routine which can find the terminating null and
returns its address. Using this function resulted in a TRT in a loop. Which
I didn't much care for. So I looked at the memchr() function. But it
requires a maximum length. Now, since I'm looking for a \0. And since a
proper C string is \0 delimited, I _ASSuMEd_ that the string was properly
delimited. This allowed me to use an arbitrary length for the memchr()
call. So I used 0x7fff, or 2GiB. That seems more than large enough to
me.
The code is now:
for(i=0; iargc; i++) {
if ('\r'==*( (char *) memchr(argv[i],'\0',0x7fff)-1)
*( (char *) memchr(argv[i],'\0',0x7fff)-1) = '\0';
}
Of course, this would really be done after the fgets() call. The code
generated is lovely:
* if ('\r' == *(findend-1))
Lr5,(*)uchar*(r2,r1,0)
LR r6,r5
LA r0,0
AL r6,=F'2147483647'
SRST r6,r5
JO *-4
BL @1L13
LA r6,0
@1L13DS 0H
AHI r6,H'-1'
CLI (*)uchar(r6,0),13
BNE @1L5
**(findend-1)='\0';
MVI (*)uchar(r6,0),0
@1L5 DS 0H
where findend is:
#define findend (char *)memchr(argv[i],'\0',0x7fff) // for ease to
change method
I need to cast the (void *) from memchr() to a (char *) in order to
subtract 1 from it. Of course, this can S0C4 if the string is not \0
delimited. Or it could possibly corrupt a byte of innocent storage. But
this should not happen in my planned use since fgets() should return a
pointer to a \0 delimited string or NULL. And I _will_ check for NULL.
On Sat, Feb 22, 2014 at 11:16 PM, John McKown
john.archie.mck...@gmail.comwrote:
Just for fun, I wrote a very small C program. I compiled it on Linux/Intel
using GCC 4.8.2. I then got it compiled on z/OS 1.13. The program is very
small:
#include stdlib.h
#include stdio.h
#include string.h
#undef strlen
int main (int argc, char *argv[]) {
int i;
for(i=0;iargc;i++) {
if ('\r' == *(argv[i]+strlen(argv[i])) )
*(argv[i]+strlen(argv[i]))='\0';
}
return 0;
}
snip/
--
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: IBM assembler copybook
It would be DEC(5) I'm sure he'll work through this without taking everything literally. An ISPF edit macro could easily do the job CHANGE ALL PL3 FIXED DEC(5,0) ; etc.. On Tue, Feb 25, 2014 at 1:13 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cahtjz9lpe6q2ades818nb0a1pd1v3o2a27_7ktkptr3ctdo...@mail.gmail.com, on 02/24/2014 at 06:15 PM, Wayne Bickerdike wayn...@gmail.com said: ASM to PL/I should be quite simple. PL3 becomes FIXED DEC(3,0) etc. WTF? PL3 is 24 bits; that's 5 digits and a sign. Why would it not be DEC(5)? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
As I posted recently in another thread, I certainly appreciate the intellectual
challenge etc., etc. of finding the absolute fastest way of performing some
machine function.
However, I hope you realize that in real life the exact speed of TRT versus
SRST is going to be dwarfed by the cost of the I/O.
Possibly dwarfed by the cost of the optimized compile ... g
The costs of TRT and SRST may vary with the length of the data read, and with
other activity on the machine (due to cache sharing).
Integer arithmetic -- converting pointer + length to pointer -- should be
almost free. I would not base any decision on whether or not one had to convert
a length to an address or not.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Monday, February 24, 2014 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious observation: lack of a simple optimization in a C program
Again, my thanks to all for the help, which was my fault in not realizing that
I had used the -o switch instead of the -O switch and so was not having my code
optimized.
On the off chance that anybody was wondering why I was doing this, it was just
a test to try to determine the best way to see if a C string ended with a \r,
or carriage return. Why? Because sometimes people here goof up and ftp a
Windows file to the mainframe, but do it from a UNIX server.
Well, they don't, but we share an NAS box between Windows an Linux servers.
So the file on the z sometimes has an extraneous \r at the very end of the
line. One good thing this did for me was point out that I was really doing it
wrong. I found the address of the end of the string using with the code
argv[i]+strlen(argv[i]). But the strlen() code generated actually found the
end of the string using the SRST and then converted that to an integer
(size_t), which I then converted right back to an address. So I searched and
found the strchr() routine which can find the terminating null and returns its
address. Using this function resulted in a TRT in a loop. Which I didn't much
care for. So I looked at the memchr() function. But it requires a maximum
length. Now, since I'm looking for a \0. And since a proper C string is \0
delimited, I _ASSuMEd_ that the string was properly delimited. This allowed me
to use an arbitrary length for the memchr() call. So I used 0x7fff, or
2GiB. That seems more than large enough to me.
The code is now:
for(i=0; iargc; i++) {
if ('\r'==*( (char *) memchr(argv[i],'\0',0x7fff)-1)
*( (char *) memchr(argv[i],'\0',0x7fff)-1) = '\0'; }
Of course, this would really be done after the fgets() call. The code generated
is lovely:
* if ('\r' == *(findend-1))
Lr5,(*)uchar*(r2,r1,0)
LR r6,r5
LA r0,0
AL r6,=F'2147483647'
SRST r6,r5
JO *-4
BL @1L13
LA r6,0
@1L13DS 0H
AHI r6,H'-1'
CLI (*)uchar(r6,0),13
BNE @1L5
**(findend-1)='\0';
MVI (*)uchar(r6,0),0
@1L5 DS 0H
where findend is:
#define findend (char *)memchr(argv[i],'\0',0x7fff) // for ease to change
method
I need to cast the (void *) from memchr() to a (char *) in order to subtract 1
from it. Of course, this can S0C4 if the string is not \0 delimited. Or it
could possibly corrupt a byte of innocent storage. But this should not happen
in my planned use since fgets() should return a pointer to a \0 delimited
string or NULL. And I _will_ check for NULL.
On Sat, Feb 22, 2014 at 11:16 PM, John McKown
john.archie.mck...@gmail.comwrote:
Just for fun, I wrote a very small C program. I compiled it on
Linux/Intel using GCC 4.8.2. I then got it compiled on z/OS 1.13. The
program is very
small:
#include stdlib.h
#include stdio.h
#include string.h
#undef strlen
int main (int argc, char *argv[]) {
int i;
for(i=0;iargc;i++) {
if ('\r' == *(argv[i]+strlen(argv[i])) )
*(argv[i]+strlen(argv[i]))='\0';
}
return 0;
}
snip/
--
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: Convert Tcp/IP translate tables from binary to source
Hi Bill, I found the problem, and now the od command is producing the correct output. Thanks for your help Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 3:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source Out of curiosity, exactly where do you see the lowercase letter e? Is it on a separate line, or between the hex numbers on each line? Or are you referring to the file produced by CONVXLAT? I tested it with TCIP.STANDARD.TCPXLBIN, and it looks ok on my system. I also ran CONVXLAT with the resulting file and it produced an identical binary table. Bill On Mon, 24 Feb 2014 15:10:06 +0200, Gadi wrote: It's not perfect (I see the lowercase letter e between the entries), but it's something I can work with. Thanks. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Monday, February 24, 2014 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Convert Tcp/IP translate tables from binary to source On Mon, 24 Feb 2014 09:06:11 +0200, Gadi wrote: Hi, I need to convert a customized binary version of a TCP/IP translation table to the source version. Is there a way to do this? I know that the CONVXLAT program will do the reverse. Thanks Gadi If it is an SBCS table named prefix.WHATEVER.TCPXLBIN: (from ISPF 6 or TSO READY) oput whatever.tcpxlbin 'xlbin_2' binary omvs od -An -tx1 -j256 xlbin_2 | tr -s ' ' tcpx_2 exit oget 'tcpx_2' tcpx2 (there is a space between the 2 quotes after tr -s) (cleanup: in omvs remove xlbin_2 and tcpx_2) The sequential data set tcpx2 will contain source suitable for CONVXLAT. There will be a blank line at the end of tcpx2, but it is harmless. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.9 under z/VM 6.3 on zBC12
They are not trying to run on the hardware directly, they are asking about running under z/VM as a guest. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.9 under z/VM 6.3 on zBC12
Brian, We don't have z/VM, we will use only for the migration in case to be required. You must tell me what will be the best migration path with or w/o z/VM. biut an the end we can remove z/VM or keepit, depends of the solution and if it's necessary. On Tue, Feb 25, 2014 at 10:04 AM, Brian Westerman brian_wester...@syzygyinc.com wrote: They are not trying to run on the hardware directly, they are asking about running under z/VM as a guest. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Regards Jose Munoz Senior IT Architect (+965) 99925167 Kuwait -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
List sysmods applied on a certain date
Hi, Is it possible to lis all sysmods (ptfs) applied on a certain date, or during a date range? Thanks Gadi לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
