Re: Do not FTP DFDSS dump files without tersing them first
On Fri, 2 May 2014 18:37:13 -0400, Pinnacle wrote: To those who have advocated sending DFDSS dumps in FTP with block mode and EBCDIC, it works great, except when it doesn't. Got an I/O error today during a restore. DFDSS level 2 said to terse it first, and viola! It worked. So I'm done with block mode FTP for DFDSS dump files. Keep using it at your own risk. You're on borrowed time. o Was this transferred directly from z/OS to z/OS? (I suspect so, since I know no other OS that supports TYPE E, MODE B). o What were the attributes of the DFDSS dump (RECFM, LRECL, BLKSIZE)? o Were the data set attributes communicated to the recipient (z/OS FTP automates most, but perhaps not all of these)? o Is DFDSS sensitive to block boundaries? Does FTP with TYPE E MODE B preserve these? (I suspect not,) o Is there an APARable failure here (data corruption)? o Did FTP report a transmission error? Is failure to report such an error APARable? What TYPE and MODE did you use when you successfully transferred the TERSEd dump? I know (but have not reported) that the similar STRU R has one (at least) specific repeatable instance of corruption: empty records are padded with one blank. Really, really, it's a design deficiency of FTP that it can't reliably and reproducibly from one z/OS system to another, nor even from a z/OS system to a foreign OS waystation, thence to another z/OS system replicating the original z/OS data set. Adding QUOTE SITE TERSE and LOCSITE TERSE to FTP's repertoire would be a significant step toward this objective, and eliminate an error-prone additional step at each end. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Do not FTP DFDSS dump files without tersing them first
On Fri, 2 May 2014 20:48:49 -0500, John McKown wrote: I agree that is the best. I have, so far, been successful simply by using the STRU R command. That is not a SITE option, but a z/OS ftp server command. But it's easy to break STRU R. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AT-TLS question
Yes, it does the encryption (and more important - the negotiation) without the z/OS application having to be aware, though the app can be if it wants to. [snip] Trying to summarize what I understand so far. An SSL capable application does all the handshake and en/decryption stuff by itself. If one end does *not* know how to talk SSL, AT/TLS can jump in and do the handshake and en/decryption on the non-SSL. On the SSL end, then the traffic will be passed on to the application unchanged, i.e. encrypted. I'll have to read about this in the appropriate doc. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: PFA
Is there any reason not to make this /u/pfa? I have /u configured for automount and it would be automatic :) The principle of least astonishment? Standard UNIX directory names are (mostly) just a convention. /u is intended for interactive user's data. You may place there whatever other stuff you like. PFA is a system service. On z/OS UNIX, such data is usually placed under /usr/lpp or the like. autmount can also provide automatic mounting on other placed, if you like. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PFA
On Fri, 2 May 2014 19:44:00 +, Gibney, Dave wrote: So, I am looking at all this nice new stuff :) Which since I have no zIIP/zAAP will run more Java on my CP :( Be prepared to be underwhelmed. Especially if you don't have System Logger active. On small non-zIIP enabled machines the payback is damn near zero - for not inconsiderable CPU consumption. Shane ... err, forgot the rant tags ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: AT-TLS question
Yes, that's basically it as I now understand. We currently have it configured for CICS sockets but now also want to configure it where z/OS is the client and Websphere on windows is the SSL client. See below for SHARE presentation. https://share.confex.com/share/120/webprogram/Session12775.html Jim Mc On 3 May 2014 09:01, Peter Hunkeler p...@gmx.ch wrote: Yes, it does the encryption (and more important - the negotiation) without the z/OS application having to be aware, though the app can be if it wants to. [snip] Trying to summarize what I understand so far. An SSL capable application does all the handshake and en/decryption stuff by itself. If one end does *not* know how to talk SSL, AT/TLS can jump in and do the handshake and en/decryption on the non-SSL. On the SSL end, then the traffic will be passed on to the application unchanged, i.e. encrypted. I'll have to read about this in the appropriate doc. -- Peter Hunkeler -- 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: Do not FTP DFDSS dump files without tersing them first
We have lots of users sending SMF and similar data via ftp, and whether the file is tersed or not, the problem we encounter is that about half of the sites have to specify QUOTE PASV to successfully send their data, while the other half will fail (and after transferring tens of megabytes before the failure) until that option is removed. So we can only tell users to try one and if it fails try the other. Barry Merrill Herbert W. “Barry” Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com – invoices/PO/Payment supp...@mxg.com– technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 – prefer email, still works -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, May 03, 2014 1:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Do not FTP DFDSS dump files without tersing them first On Fri, 2 May 2014 18:37:13 -0400, Pinnacle wrote: To those who have advocated sending DFDSS dumps in FTP with block mode and EBCDIC, it works great, except when it doesn't. Got an I/O error today during a restore. DFDSS level 2 said to terse it first, and viola! It worked. So I'm done with block mode FTP for DFDSS dump files. Keep using it at your own risk. You're on borrowed time. o Was this transferred directly from z/OS to z/OS? (I suspect so, since I know no other OS that supports TYPE E, MODE B). o What were the attributes of the DFDSS dump (RECFM, LRECL, BLKSIZE)? o Were the data set attributes communicated to the recipient (z/OS FTP automates most, but perhaps not all of these)? o Is DFDSS sensitive to block boundaries? Does FTP with TYPE E MODE B preserve these? (I suspect not,) o Is there an APARable failure here (data corruption)? o Did FTP report a transmission error? Is failure to report such an error APARable? What TYPE and MODE did you use when you successfully transferred the TERSEd dump? I know (but have not reported) that the similar STRU R has one (at least) specific repeatable instance of corruption: empty records are padded with one blank. Really, really, it's a design deficiency of FTP that it can't reliably and reproducibly from one z/OS system to another, nor even from a z/OS system to a foreign OS waystation, thence to another z/OS system replicating the original z/OS data set. Adding QUOTE SITE TERSE and LOCSITE TERSE to FTP's repertoire would be a significant step toward this objective, and eliminate an error-prone additional step at each end. -- gil -- 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: AW: Re: AT-TLS question
That should have said SSL server and not SSL client obviously. Jim Mc. On 3 May 2014 10:28, Jim McAlpine jim.mcalp...@gmail.com wrote: Yes, that's basically it as I now understand. We currently have it configured for CICS sockets but now also want to configure it where z/OS is the client and Websphere on windows is the SSL client. See below for SHARE presentation. https://share.confex.com/share/120/webprogram/Session12775.html Jim Mc On 3 May 2014 09:01, Peter Hunkeler p...@gmx.ch wrote: Yes, it does the encryption (and more important - the negotiation) without the z/OS application having to be aware, though the app can be if it wants to. [snip] Trying to summarize what I understand so far. An SSL capable application does all the handshake and en/decryption stuff by itself. If one end does *not* know how to talk SSL, AT/TLS can jump in and do the handshake and en/decryption on the non-SSL. On the SSL end, then the traffic will be passed on to the application unchanged, i.e. encrypted. I'll have to read about this in the appropriate doc. -- Peter Hunkeler -- 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: Dynamic TSO Submit Exit
Thanks for the feedback. We have our module in the linklist. I can test with an lla refresh or steplib. I'm going to be closing some loopholes, so if there is major pushback, I wanted to be able to quickly change back. Sent from my iPhone On May 2, 2014, at 5:20 PM, Skip Robinson jo.skip.robin...@sce.com wrote: A TSO/E exit can be localized to a single person or group for testing. Put it in an APF STEPLIB and only folks who have it their logon PROC will run the code. I stumbled on that a long time ago when I took a problem to Level 2 only to discover that I was using some ancient version of it in my STEPLIB. (Assuming that has not changed...) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Jon Perryman jperr...@pacbell.net To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/02/2014 09:48 AM Subject:Re: Dynamic TSO Submit Exit Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I opted not to suggest LINKLST. Some companies use LLA refresh for production move process. Others propogate LLA refresh to all system. I suggested using MLPA because it's not a permanent change so an IPL will revert back to the original (if not in real LPA/LINKLST dataset). Jon Perryman. From: John McKown john.archie.mck...@gmail.com Our IKJEFF10 (TSO submit exit) exists in LINKLIST. As I recall, in the past, I have simply replaced the module in the proper library and did an F LLA,REFRESH to start using the new version. Again, IIRC, this exit is invoked by the TMP using a simple LINK (or something like LINK) instruction. It may be necessary to have your TSO users logoff and back on to pick up the new copy of the exit. -- 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: Do not FTP DFDSS dump files without tersing them first
On Sat, 3 May 2014 05:45:23 -0500, Barry Merrill wrote: We have lots of users sending SMF and similar data via ftp, and whether the file is tersed or not, the problem we encounter is that about half of the sites have to specify QUOTE PASV to successfully send their data, while the other half will fail (and after transferring tens of megabytes before the failure) until that option is removed. So we can only tell users to try one and if it fails try the other. Is SFTP an option? It avoids a lot of such complexity. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PFA
So you don't think PFA is worthwhile either? I have been considering recommending not starting PFA or HZR, but I was not sure how it would be taken. Brian On Sat, 3 May 2014 03:29:21 -0500, Shane Ginnane ibm-m...@tpg.com.au wrote: On Fri, 2 May 2014 19:44:00 +, Gibney, Dave wrote: So, I am looking at all this nice new stuff :) Which since I have no zIIP/zAAP will run more Java on my CP :( Be prepared to be underwhelmed. Especially if you don't have System Logger active. On small non-zIIP enabled machines the payback is damn near zero - for not inconsiderable CPU consumption. Shane ... err, forgot the rant tags ... -- 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: IEBUPDTE alternatives
I think this might be APARable. Its worth a try. Ed On May 2, 2014, at 11:15 AM, Phil Sidler wrote: At one time I set up IEBUPDTE (or SMP/E USERMOD ++MACUPD) jobs to update some IBM sample programs before I used them to make it easier to tell what was updated from the supplied source and possible make migration to new releases easier. Now, going to a new CICS release, the sample programs no longer have sequence numbers. This breaks my IEBUPDTE process for sure. (It also breaks ISPF COMPARE to see what has changed!) Perhaps someone can save me some time and tell me what they're doing for this? TIA,... -- 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: IEBUPDTE alternatives
On 2014-05-02, at 12:04, Jousma, David wrote: As for your question, my suggestion is to instead of using IEBUPDTE statements, is to copy the entire source program, and make a SMPE usermod out of it with your changes added to it(sufficiently documented, of course). We already do this with a few IBM supplied source programs for TWS. It's not too bad to manage, you just run the compare against your modified usermod with the new source to see whats changed, and then reapply your local modifications to the new version of the source in your usermod. Replacing an elegantly automated process with a crude and tedious manual one. Sigh. On 2014-05-03, at 22:26, Ed Gould wrote: I think this might be APARable. Its worth a try. Party on, Wayne! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Sidler Sent: Friday, May 02, 2014 12:15 PM At one time I set up IEBUPDTE (or SMP/E USERMOD ++MACUPD) jobs to update some IBM sample programs before I used them to make it easier to tell what was updated from the supplied source and possible make migration to new releases easier. Now, going to a new CICS release, the sample programs no longer have sequence numbers. This breaks my IEBUPDTE process for sure. (It also breaks ISPF COMPARE to see what has changed!) Perhaps someone can save me some time and tell me what they're doing for this? An alternative to IEBUPDTE is patch, supplied by z/OS, which does not require sequence numbers. Patch is much improved if you have diff3, not supplied by z/OS, but readily available elsewhere. SuperC provides the UPDCMS8 option which produces DELTA output in a form suitable for input to CMS UPDATE, and UPDMVS8 which produces DELTA output in a form suitable for SYSIN for IEBUPDTE. UPDCMS8 requires only that the OLD comparand have valid sequence numbers; UPDMVS8 requires that both OLD and NEW have valid sequence numbers. YTF!? Faced with this, I use the UPDCMS8 option, and have written a fairly simple Rexx filter to tranform UPDCMS8 format to UPDMVS8. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMM and tape dataset block size
Hello experts, I am trying to determine the tape dataset block size, can I trust what recorded in TMS's catalog? Is the block size accurate? If the answer is YES, then I will not bother to dump SMF 21. regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
