Re: z/osmf missing directory
Never mind - again. The SMP/E job to put the new workflow choked on installing the PTF but apparently got far enough to create the directory. This install is going to cause me to want to retire! Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, March 28, 2024 3:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] z/osmf missing directory Hi again, Got past my last problem and now while trying to apply UJ93002 to get the 3.1 workflow loaded into the filesystem, the apply failed because /usr/lpp/bcp/upgrade doesn't exist. While I can manually go into the FS and create the directory, I'm concerned that I missed some step that should have created it and others. The only hits I've found in doing searches online are telling me that installing a particular PTF will put the new workflow in this location. So my questions are 1) is it safe for me to just create this directory, and if not, where is the step(s) that I missed that would create it for me? TIA (again) Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/osmf missing directory
Hi again, Got past my last problem and now while trying to apply UJ93002 to get the 3.1 workflow loaded into the filesystem, the apply failed because /usr/lpp/bcp/upgrade doesn't exist. While I can manually go into the FS and create the directory, I'm concerned that I missed some step that should have created it and others. The only hits I've found in doing searches online are telling me that installing a particular PTF will put the new workflow in this location. So my questions are 1) is it safe for me to just create this directory, and if not, where is the step(s) that I missed that would create it for me? TIA (again) Rex -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
On Thu, 28 Mar 2024 17:26:46 +, Jousma, David wrote: >Ding ding ding…..Gil gets the prize!... > >Coding EBCDIC, and STRU R was the magic potion. > And no one knows why. FTP appears designed to ignore conventions and frustrate programmers.\ Once I coded: //SYSUT1 DD RECFM=U,... ... PUT DD:SYSUT1 ... expecting FTP to behave like IEBGENER or any well-behaved utility, treat each block as an unformatted record, and transfer RDWs and BDWs as data. Instead, it appeared to ignore my allocation attributes and use those in the DSCB instead. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
It is. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Michael Oujesky Date: Thursday, March 28, 2024 at 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Just a thought, but is Connect Direct available? Michael At 12: 26 PM 3/28/2024, Jousma, David wrote: >Ding ding ding…. . Gil gets the prize! Off-list >send me your favorite adult beverage and where >to send it, and I’ll have it delivered Just a thought, but is Connect Direct available? Michael This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Just a thought, but is Connect Direct available? Michael At 12:26 PM 3/28/2024, Jousma, David wrote: Ding ding ding ..Gil gets the prize! Off-list send me your favorite adult beverage and where to send it, and Ill have it delivered to your door! Coding EBCDIC, and STRU R was the magic potion. EZA2509I 16169 megabytes transferred - 10 second interval rate 150928.44 KB/sec - Overall transfer rate 130424.81 KB/sec EZA2509I 17603 megabytes transferred - 10 second interval rate 150308.75 KB/sec - Overall transfer rate 131845.13 KB/sec EZA2509I 19080 megabytes transferred - 10 second interval rate 154934.56 KB/sec - Overall transfer rate 133384.38 KB/sec EZA2509I 20516 megabytes transferred - 10 second interval rate 150550.75 KB/sec - Overall transfer rate 134457.31 KB/sec EZA2509I 21989 megabytes transferred - 10 second interval rate 154457.94 KB/sec - Overall transfer rate 135633.81 KB/sec 250 Transfer completed successfully. DSS running at the remote end REST INDD(TAPE) ODY(RST02A) ADMIN ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'REST ' ADR109I (R/I)-RI01 (01), 2024.088 13:22:47 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2024.088 13:22:47 EXECUTION BEGINS ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 1:17â¯PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Will give that a shot Gil. Running now, at the fast speed. Well if if ADRDSSU at the remote end can read the file Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List Will give that a shot Gil. Running now, at the fast speed. Well if if ADRDSSU at the remote end can read the file Dave Jousma Vice President | Director, Technology Engineering This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: Slow FTP's
Ding ding ding…..Gil gets the prize! Off-list send me your favorite adult beverage and where to send it, and I’ll have it delivered to your door! Coding EBCDIC, and STRU R was the magic potion. EZA2509I 16169 megabytes transferred - 10 second interval rate 150928.44 KB/sec - Overall transfer rate 130424.81 KB/sec EZA2509I 17603 megabytes transferred - 10 second interval rate 150308.75 KB/sec - Overall transfer rate 131845.13 KB/sec EZA2509I 19080 megabytes transferred - 10 second interval rate 154934.56 KB/sec - Overall transfer rate 133384.38 KB/sec EZA2509I 20516 megabytes transferred - 10 second interval rate 150550.75 KB/sec - Overall transfer rate 134457.31 KB/sec EZA2509I 21989 megabytes transferred - 10 second interval rate 154457.94 KB/sec - Overall transfer rate 135633.81 KB/sec 250 Transfer completed successfully. DSS running at the remote end REST INDD(TAPE) ODY(RST02A) ADMIN ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'REST ' ADR109I (R/I)-RI01 (01), 2024.088 13:22:47 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2024.088 13:22:47 EXECUTION BEGINS ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT AND WAS CREATED BY Z/OS DFSMSDSS VERSION Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Will give that a shot Gil. Running now, at the fast speed. We’ll if if ADRDSSU at the remote end can read the file Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List Will give that a shot Gil. Running now, at the fast speed. We’ll if if ADRDSSU at the remote end can read the file Dave Jousma Vice President | Director, Technology Engineering This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Will give that a shot Gil. Running now, at the fast speed. We’ll if if ADRDSSU at the remote end can read the file Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 12:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's On Thu, 28 Mar 2024 14: 41: 32 +, rpinion865 wrote: >As you have determined, it seems that MODE B (Block Mode) is the kicker. Using XMIT or TERSE would eliminate the need for MODE B. But we all know there is CPU consumption from using On Thu, 28 Mar 2024 14:41:32 +, rpinion865 wrote: >As you have determined, it seems that MODE B (Block Mode) is the kicker. >Using XMIT or TERSE would eliminate the need for MODE B. But we all know >there is CPU consumption from using those two utilities on both ends. > Might STRU R be preferable to MODE B? (But O discovered that STRU R garbles RECFM=VBS.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM VTS and cloud
Another option is IBM Cloud Tape Connector. One of its capabilities is Virtual Tape Replication, which replicates tape data sets to cloud object storage. If interested in finding out more, please email me at wilc...@us.ibm.com and I can connect you with the SME. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
On Thu, 28 Mar 2024 14:41:32 +, rpinion865 wrote: >As you have determined, it seems that MODE B (Block Mode) is the kicker. >Using XMIT or TERSE would eliminate the need for MODE B. But we all know >there is CPU consumption from using those two utilities on both ends. > Might STRU R be preferable to MODE B? (But O discovered that STRU R garbles RECFM=VBS.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM VTS and cloud
I sent your question to Joe Swingler, TS7700 architect and replied as follows: "As of today, a single TS7700 can be either cloud attached or tape attached, but not both. So, a third TS7700C would be needed or one of the two tape attach boxes would have to become only cloud attached." Glenn Wilcock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
The doc says.. Mode B Sets the block mode. In block mode, data is transmitted as a series of data blocks, preceded by one or more header bytes. Block mode preserves the logical record boundaries of the data set or file. When MOde is set to B, the data transfer type must be EBCDIC. Mode S Sets the stream mode. In stream mode, data is transmitted as a stream of bytes. Any data transfer type can be used with stream mode. *Stream mode is efficient because data block information is nottransferred.* ** Why worry about EBCDIC? as it is z/OS to z/OS you want binary mode. *___* With Mode S it may send data in chunks for the send and receive size (so up to MB chunks). With Mode B it may send a count of records before wait, - which may be in 100's of bytes. If you issue TSO NETSTAT ALL ( PORT 22 it will display data for all FTP connections. For the one of interest, look at SendBufferSize:/ ReceiveBufferSize: CongestionWindow: MaximumSegmentSize: DSField: Round-trip information: Smooth trip time:SmoothTripVariance: ReXmt: ReXmtCount: DupACKs:RcvWnd: With Dynamic Right Sizing you should have Send buffers > 64KB - perhaps 1MB ( and receive buffer at the remote end) Bytes Out/Segments out give you a rough measure of the amount of data sent per packet. If you send me the data from each end, I can have a look at if for you Colin On Thu, 28 Mar 2024 at 14:32, Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Max, > > As mentioned, the 50Gb file with MODE B and EBCDIC is slow. Same file > just binary mode, it is fast. Of course, cant transmit a DSS dump as just > binary. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 10:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Dave, it becomes more interesting. Could it depend on the file data itself > ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same > kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar > 2024 alle ore > > > Dave, > > > > it becomes more interesting. > > Could it depend on the file data itself ? > > > > Have you tried a BIG file, EBCDIC with mostly the same data inside ? > > Same kind of transmission, MODE B and EBCDIC. > > > > Regards. > > Max. > > > > > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
As you have determined, it seems that MODE B (Block Mode) is the kicker. Using XMIT or TERSE would eliminate the need for MODE B. But we all know there is CPU consumption from using those two utilities on both ends. Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:31 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > And all lpars are at the same levels of software. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: Jousma, David david.jou...@53.com > > Date: Thursday, March 28, 2024 at 10:30 AM > To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Max, > > As mentioned, the 50Gb file with MODE B and EBCDIC is slow. Same file just > binary mode, it is fast. Of course, cant transmit a DSS dump as just binary. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Massimo Biancucci 05a019256424-dmarc-requ...@listserv.ua.edu > > Date: Thursday, March 28, 2024 at 10:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Dave, it becomes more interesting. Could it depend on the file data itself ? > Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same > kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar > 2024 alle ore > > > Dave, > > > > it becomes more interesting. > > Could it depend on the file data itself ? > > > > Have you tried a BIG file, EBCDIC with mostly the same data inside ? > > Same kind of transmission, MODE B and EBCDIC. > > > > Regards. > > Max. > > > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
And all lpars are at the same levels of software. Dave Jousma Vice President | Director, Technology Engineering From: Jousma, David Date: Thursday, March 28, 2024 at 10:30 AM To: IBM Mainframe Discussion List Subject: Re: Slow FTP's Max, As mentioned, the 50Gb file with MODE B and EBCDIC is slow. Same file just binary mode, it is fast. Of course, cant transmit a DSS dump as just binary. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Dave, it becomes more interesting. Could it depend on the file data itself ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar 2024 alle ore Dave, it becomes more interesting. Could it depend on the file data itself ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind of transmission, MODE B and EBCDIC. Regards. Max. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Max, As mentioned, the 50Gb file with MODE B and EBCDIC is slow. Same file just binary mode, it is fast. Of course, cant transmit a DSS dump as just binary. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 10:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Dave, it becomes more interesting. Could it depend on the file data itself ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar 2024 alle ore Dave, it becomes more interesting. Could it depend on the file data itself ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind of transmission, MODE B and EBCDIC. Regards. Max. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
There is no compression involved.As mentioned, the transfer is only slow when using MODE B, EBCDIC on the FTP. If I remove those, and just do a binary file transfer, it flies. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's What about non-zEDC compression for the destination output dataset? Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10: 08 AM, Jousma, David <01a0403c5dc1-dmarc-request@ LISTSERV. UA. EDU> wrote: > As I mentioned, What about non-zEDC compression for the destination output dataset? Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:08 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
David, far from me the idea XMIT would have solved. It's a try to understand if problem is related to the FTP server or client. :D Regards. Max Il giorno gio 28 mar 2024 alle ore 15:11 David Spiegel < 0468385049d1-dmarc-requ...@listserv.ua.edu> ha scritto: > Hi Max, > XMIT??? ... They would probably exceed some limit long before the > transmission begins. > > Regards, > David > > On 2024-03-28 09:57, Massimo Biancucci wrote: > > Dave, > > > > did you try the basic PING and TRACERTE to see if there's anything > > different ? > > Is it a basic FTP ? SFTP ? FTPS ? > > > > Did you try with XMIT through JNE (if available) to measure any > difference ? > > > > Best regards. > > Max > > > > Il giorno gio 28 mar 2024 alle ore 14:54 Styles, Andy (CIO GS - Core > > Infrastructure & IT Operations ) < > > 00d68f765d25-dmarc-requ...@listserv.ua.edu> ha scritto: > > > >> Classification: Public > >> > >> Do you have access to any other kind of transfer mechanism, and if so, > >> does it happen with that too? (thinking Connect:Direct for example). > >> Is the target device of the transfer the same on fast vs slow? > >> > >> Andy Styles > >> z/Series Systems Programmer > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > Behalf > >> Of Jousma, David > >> Sent: Thursday, March 28, 2024 1:14 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Slow FTP's > >> > >> *** This email is from an external source - be careful of attachments > and > >> links. Please report suspicious emails *** > >> > >> There is, but same for all lpars involved. > >> > >> Dave Jousma > >> Vice President | Director, Technology Engineering > >> > >> > >> > >> > >> > >> From: IBM Mainframe Discussion List on > behalf > >> of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > >> Date: Thursday, March 28, 2024 at 9:12 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Slow FTP's > >> Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at > 8: > >> 03 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > edu> > >> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 > bytes > >> > >> > >> Is there a firewall or switch in the path? > >> > >> > >> > >> Joe > >> > >> > >> > >> On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < > >> > >> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > >> > >> > >> > >>> Joe, > >>> I had not, just did, worse yet > >>> EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 > >>> KB/sec - Overall transfer rate 1281.27 KB/sec > >>> EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 > >>> KB/sec - Overall transfer rate 1059.52 KB/sec > >>> EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 > >>> KB/sec - Overall transfer rate 969.15 KB/sec > >>> Dave Jousma > >>> Vice President | Director, Technology Engineering > >>> From: IBM Mainframe Discussion List on > >>> behalf > >>> of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > >>> Date: Thursday, March 28, 2024 at 8:56 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Slow FTP's > >>> Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 > >>> at > >>> 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > >>> edu> wrote: > All, > > Grasping at straws here, IBM support center is > >>> baffled too. > > >>> Have you tried MODE S (streaming) and TYPE E? > >>> Joe > >>> On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < > >>> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > Grasping at straws here, IBM support center is baffled too. > To clone z/OS maintenance to various disconnected sysplex’s I do a > DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file > transfers > >>> to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to > other > systems on the same CEC.With IBM support help, we’ve narrowed down > >>> the > problem to the specification of MODE B and EBCDIC on the transfer > since > >>> it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > So, we are a GDPS shop. The oddity is that all the “fast” transfers > >> are > >> > to the K systems(control systems), and all the “slow” transfers are > to > >>> the > traditional application systems. TEST, DEV, PROD makes no > difference, > >>> nor > does LPAR busy or not busy. > It seems there is something configured differently on the “slow” > systems > that is affecting mode b, ebcdic file transfers, but for the life of > me, > >>> I > cannot put my finger on what, nor can the support center, except > that the > issue is at the remote end, in that the OS
Re: Slow FTP's
Dave, it becomes more interesting. Could it depend on the file data itself ? Have you tried a BIG file, EBCDIC with mostly the same data inside ? Same kind of transmission, MODE B and EBCDIC. Regards. Max. Il giorno gio 28 mar 2024 alle ore 15:09 Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> ha scritto: > As I mentioned, a standard binary transfer runs all day to all lpars at > 140Mb/sec. It seems that only DSS dump files with MODE B, and EBCDIC > specified slows them down. > > I have reached out to our network/firewall teams to see if there some sort > of data inspection going on. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) < > 00d68f765d25-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 9:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Classification: Public Do you have access to any other kind of transfer > mechanism, and if so, does it happen with that too? (thinking Connect: > Direct for example). Is the target device of the transfer the same on fast > vs slow? Andy Styles z/Series > > > Classification: Public > > > > Do you have access to any other kind of transfer mechanism, and if so, > does it happen with that too? (thinking Connect:Direct for example). > > Is the target device of the transfer the same on fast vs slow? > > > > Andy Styles > > z/Series Systems Programmer > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
What about non-zEDC compression for the destination output dataset? Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 10:08 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > As I mentioned, a standard binary transfer runs all day to all lpars at > 140Mb/sec. It seems that only DSS dump files with MODE B, and EBCDIC > specified slows them down. > > I have reached out to our network/firewall teams to see if there some sort of > data inspection going on. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of > Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) > 00d68f765d25-dmarc-requ...@listserv.ua.edu > > Date: Thursday, March 28, 2024 at 9:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Slow FTP's > Classification: Public Do you have access to any other kind of transfer > mechanism, and if so, does it happen with that too? (thinking Connect: Direct > for example). Is the target device of the transfer the same on fast vs slow? > Andy Styles z/Series > > > Classification: Public > > > > Do you have access to any other kind of transfer mechanism, and if so, does > it happen with that too? (thinking Connect:Direct for example). > > Is the target device of the transfer the same on fast vs slow? > > > > Andy Styles > > z/Series Systems Programmer > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
Hi Max, XMIT??? ... They would probably exceed some limit long before the transmission begins. Regards, David On 2024-03-28 09:57, Massimo Biancucci wrote: Dave, did you try the basic PING and TRACERTE to see if there's anything different ? Is it a basic FTP ? SFTP ? FTPS ? Did you try with XMIT through JNE (if available) to measure any difference ? Best regards. Max Il giorno gio 28 mar 2024 alle ore 14:54 Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) < 00d68f765d25-dmarc-requ...@listserv.ua.edu> ha scritto: Classification: Public Do you have access to any other kind of transfer mechanism, and if so, does it happen with that too? (thinking Connect:Direct for example). Is the target device of the transfer the same on fast vs slow? Andy Styles z/Series Systems Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Thursday, March 28, 2024 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's *** This email is from an external source - be careful of attachments and links. Please report suspicious emails *** There is, but same for all lpars involved. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8: 03 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: Joe, I had not, just did, worse yet EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 KB/sec - Overall transfer rate 1281.27 KB/sec EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 KB/sec - Overall transfer rate 1059.52 KB/sec EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 KB/sec - Overall transfer rate 969.15 KB/sec Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: All, Grasping at straws here, IBM support center is baffled too. To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. There is some environmental issue causing slow file transfers to some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the same CEC.With IBM support help, we’ve narrowed down the problem to the specification of MODE B and EBCDIC on the transfer since it is a DSS dump. Remove those, and the transfer is fast on the slow systems, and still fast on the fast systems. Obviously that isn’t a solution though. So, we are a GDPS shop. The oddity is that all the “fast” transfers are to the K systems(control systems), and all the “slow” transfers are to the traditional application systems. TEST, DEV, PROD makes no difference, nor does LPAR busy or not busy. It seems there is something configured differently on the “slow” systems that is affecting mode b, ebcdic file transfers, but for the life of me, I cannot put my finger on what, nor can the support center, except that the issue is at the remote end, in that the OS cannot offload the data fast enough, so TCPIP/FTP is slowing the transfer pace. A virtual adult beverage of choice to the one that can point in a direction to look…. Dave Jousma Vice President | Director, Technology Engineering This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access
Re: Slow FTP's
As I mentioned, a standard binary transfer runs all day to all lpars at 140Mb/sec. It seems that only DSS dump files with MODE B, and EBCDIC specified slows them down. I have reached out to our network/firewall teams to see if there some sort of data inspection going on. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) <00d68f765d25-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Classification: Public Do you have access to any other kind of transfer mechanism, and if so, does it happen with that too? (thinking Connect: Direct for example). Is the target device of the transfer the same on fast vs slow? Andy Styles z/Series Classification: Public Do you have access to any other kind of transfer mechanism, and if so, does it happen with that too? (thinking Connect:Direct for example). Is the target device of the transfer the same on fast vs slow? Andy Styles z/Series Systems Programmer This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Max, Yes tracerte’s have been run, packet traces. It is standard FTP, no SSL encryption going on. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Massimo Biancucci <05a019256424-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Dave, did you try the basic PING and TRACERTE to see if there's anything different ? Is it a basic FTP ? SFTP ? FTPS ? Did you try with XMIT through JNE (if available) to measure any difference ? Best regards. Max Il giorno gio 28 mar 2024 Dave, did you try the basic PING and TRACERTE to see if there's anything different ? Is it a basic FTP ? SFTP ? FTPS ? Did you try with XMIT through JNE (if available) to measure any difference ? Best regards. Max This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
All between 4 z15’s Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's How about processors (z15/z16)? On Thu, Mar 28, 2024 at 7: 30 AM Jousma, David <01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone How about processors (z15/z16)? On Thu, Mar 28, 2024 at 7:30 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it is > a DSS dump. Remove those, and the transfer is fast on the slow systems, and > still fast on the fast systems. Obviously that isn’t a solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems that > is affecting mode b, ebcdic file transfers, but for the life of me, I cannot > put my finger on what, nor can the support center, except that the issue is > at the remote end, in that the OS cannot offload the data fast enough, so > TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a direction > to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Dave, did you try the basic PING and TRACERTE to see if there's anything different ? Is it a basic FTP ? SFTP ? FTPS ? Did you try with XMIT through JNE (if available) to measure any difference ? Best regards. Max Il giorno gio 28 mar 2024 alle ore 14:54 Styles, Andy (CIO GS - Core Infrastructure & IT Operations ) < 00d68f765d25-dmarc-requ...@listserv.ua.edu> ha scritto: > Classification: Public > > Do you have access to any other kind of transfer mechanism, and if so, > does it happen with that too? (thinking Connect:Direct for example). > Is the target device of the transfer the same on fast vs slow? > > Andy Styles > z/Series Systems Programmer > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Jousma, David > Sent: Thursday, March 28, 2024 1:14 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > > *** This email is from an external source - be careful of attachments and > links. Please report suspicious emails *** > > There is, but same for all lpars involved. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 9:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8: > 03 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> > wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes > > > Is there a firewall or switch in the path? > > > > Joe > > > > On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Joe, > > > > > > I had not, just did, worse yet > > > > > > EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 > > > KB/sec - Overall transfer rate 1281.27 KB/sec > > > EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 > > > KB/sec - Overall transfer rate 1059.52 KB/sec > > > EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 > > > KB/sec - Overall transfer rate 969.15 KB/sec > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > From: IBM Mainframe Discussion List on > > behalf > > > of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > > > Date: Thursday, March 28, 2024 at 8:56 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Slow FTP's > > > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 > > at > > > 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > > > edu> wrote: > All, > > Grasping at straws here, IBM support center is > > > baffled too. > > > > > > > > > > Have you tried MODE S (streaming) and TYPE E? > > > > > > > > > > > > Joe > > > > > > > > > > > > On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < > > > > > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > > > > > > > > All, > > > > > > > > > > > > > > Grasping at straws here, IBM support center is baffled too. > > > > > > > > > > > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a > > > DFDSS > > > > > > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > > > > > > transfer. There is some environmental issue causing slow file > > > transfers > > > to > > > > > > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to > > > other > > > > > > > systems on the same CEC.With IBM support help, we’ve narrowed down > > > the > > > > > > > problem to the specification of MODE B and EBCDIC on the transfer > > > since > > > it > > > > > > > is a DSS dump. Remove those, and the transfer is fast on the slow > > > > > > > systems, and still fast on the fast systems. Obviously that isn’t a > > > > > > > solution though. > > > > > > > > > > > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers > are > > > > > > > to the K systems(control systems), and all the “slow” transfers are > > > to > > > the > > > > > > > traditional application systems. TEST, DEV, PROD makes no difference, > > > nor > > > > > > > does LPAR busy or not busy. > > > > > > > > > > > > > > It seems there is something configured differently on the “slow” > > > systems > > > > > > > that is affecting mode b, ebcdic file transfers, but for the life of > > > me, > > > I > > > > > > > cannot put my finger on what, nor can the support center, except > > > that the > > > > > > > issue is at the remote end, in that the OS cannot offload the data > > > fast > > > > > > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > > > > > > > > > > > A virtual adult beverage of choice to the one that can point in a > > > > > > > direction to look…. > > > > > > > > > > > > > > > > > > > > > Dave Jousma > > > > > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > > > >
Re: Slow FTP's
Classification: Public Do you have access to any other kind of transfer mechanism, and if so, does it happen with that too? (thinking Connect:Direct for example). Is the target device of the transfer the same on fast vs slow? Andy Styles z/Series Systems Programmer -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Thursday, March 28, 2024 1:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's *** This email is from an external source - be careful of attachments and links. Please report suspicious emails *** There is, but same for all lpars involved. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8: 03 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 > KB/sec - Overall transfer rate 1281.27 KB/sec > EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 > KB/sec - Overall transfer rate 1059.52 KB/sec > EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 > KB/sec - Overall transfer rate 969.15 KB/sec > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on > behalf > of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 8:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 > at > 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > edu> wrote: > All, > > Grasping at straws here, IBM support center is > baffled too. > > > > Have you tried MODE S (streaming) and TYPE E? > > > > Joe > > > > On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > All, > > > > > > Grasping at straws here, IBM support center is baffled too. > > > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a > > DFDSS > > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > > transfer. There is some environmental issue causing slow file > > transfers > to > > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to > > other > > > systems on the same CEC.With IBM support help, we’ve narrowed down > the > > > problem to the specification of MODE B and EBCDIC on the transfer > > since > it > > > is a DSS dump. Remove those, and the transfer is fast on the slow > > > systems, and still fast on the fast systems. Obviously that isn’t a > > > solution though. > > > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > > > to the K systems(control systems), and all the “slow” transfers are > > to > the > > > traditional application systems. TEST, DEV, PROD makes no difference, > nor > > > does LPAR busy or not busy. > > > > > > It seems there is something configured differently on the “slow” > > systems > > > that is affecting mode b, ebcdic file transfers, but for the life of > > me, > I > > > cannot put my finger on what, nor can the support center, except > > that the > > > issue is at the remote end, in that the OS cannot offload the data > > fast > > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > > > A virtual adult beverage of choice to the one that can point in a > > > direction to look…. > > > > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > This e-mail transmission contains information that is confidential > > and > may > > > be privileged. It is intended only for the addressee(s) named above. If > > > you receive this e-mail in error, please do not read, copy or > > disseminate > > > it in any manner. If you are not the intended recipient, any > > disclosure, > > > copying, distribution or use of the contents of this information is > > > prohibited. Please reply to the message immediately by informing the > sender > > > that the message was misdirected. After replying, please erase it > > from > your > > > computer system. Your assistance in correcting this error is appreciated. > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff /
Re: Slow FTP's
FWIW I transferred a DSS dump of a z/OS 2.4 SYS1.LINKLIB (3540 tracks) to a test LPAR that is capped and to a production LPAR that is not capped. On the test LPAR I got 31MB/sec and on the production LPAR I got 70MB/sec. Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 9:36 AM, Mike Schwab <05962a42dc49-dmarc-requ...@listserv.ua.edu> wrote: > How about processors (z15/z16)? > > On Thu, Mar 28, 2024 at 7:30 AM Jousma, David > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu wrote: > > > All, > > > > Grasping at straws here, IBM support center is baffled too. > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > transfer. There is some environmental issue causing slow file transfers to > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > > systems on the same CEC. With IBM support help, we’ve narrowed down the > > problem to the specification of MODE B and EBCDIC on the transfer since it > > is a DSS dump. Remove those, and the transfer is fast on the slow systems, > > and still fast on the fast systems. Obviously that isn’t a solution though. > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > > the K systems(control systems), and all the “slow” transfers are to the > > traditional application systems. TEST, DEV, PROD makes no difference, nor > > does LPAR busy or not busy. > > > > It seems there is something configured differently on the “slow” systems > > that is affecting mode b, ebcdic file transfers, but for the life of me, I > > cannot put my finger on what, nor can the support center, except that the > > issue is at the remote end, in that the OS cannot offload the data fast > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > A virtual adult beverage of choice to the one that can point in a direction > > to look…. > > > > Dave Jousma > > Vice President | Director, Technology Engineering > > > > This e-mail transmission contains information that is confidential and may > > be privileged. It is intended only for the addressee(s) named above. If you > > receive this e-mail in error, please do not read, copy or disseminate it in > > any manner. If you are not the intended recipient, any disclosure, copying, > > distribution or use of the contents of this information is prohibited. > > Please reply to the message immediately by informing the sender that the > > message was misdirected. After replying, please erase it from your computer > > system. Your assistance in correcting this error is appreciated. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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: Slow FTP's
How about processors (z15/z16)? On Thu, Mar 28, 2024 at 7:30 AM Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it is > a DSS dump. Remove those, and the transfer is fast on the slow systems, and > still fast on the fast systems. Obviously that isn’t a solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems that > is affecting mode b, ebcdic file transfers, but for the life of me, I cannot > put my finger on what, nor can the support center, except that the issue is > at the remote end, in that the OS cannot offload the data fast enough, so > TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a direction > to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
There is, but same for all lpars involved. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8: 03 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 > KB/sec - Overall transfer rate 1281.27 KB/sec > EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 > KB/sec - Overall transfer rate 1059.52 KB/sec > EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 > KB/sec - Overall transfer rate 969.15 KB/sec > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 8:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at > 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > edu> wrote: > All, > > Grasping at straws here, IBM support center is > baffled too. > > > > Have you tried MODE S (streaming) and TYPE E? > > > > Joe > > > > On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > All, > > > > > > Grasping at straws here, IBM support center is baffled too. > > > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > > transfer. There is some environmental issue causing slow file transfers > to > > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > > > systems on the same CEC.With IBM support help, we’ve narrowed down > the > > > problem to the specification of MODE B and EBCDIC on the transfer since > it > > > is a DSS dump. Remove those, and the transfer is fast on the slow > > > systems, and still fast on the fast systems. Obviously that isn’t a > > > solution though. > > > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > > > to the K systems(control systems), and all the “slow” transfers are to > the > > > traditional application systems. TEST, DEV, PROD makes no difference, > nor > > > does LPAR busy or not busy. > > > > > > It seems there is something configured differently on the “slow” systems > > > that is affecting mode b, ebcdic file transfers, but for the life of me, > I > > > cannot put my finger on what, nor can the support center, except that the > > > issue is at the remote end, in that the OS cannot offload the data fast > > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > > > A virtual adult beverage of choice to the one that can point in a > > > direction to look…. > > > > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > This e-mail transmission contains information that is confidential and > may > > > be privileged. It is intended only for the addressee(s) named above. If > > > you receive this e-mail in error, please do not read, copy or disseminate > > > it in any manner. If you are not the intended recipient, any disclosure, > > > copying, distribution or use of the contents of this information is > > > prohibited. Please reply to the message immediately by informing the > sender > > > that the message was misdirected. After replying, please erase it from > your > > > computer system. Your assistance in correcting this error is appreciated. > > > > > > -- > > > 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 > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended
Re: Slow FTP's
Is there a firewall or switch in the path? Joe On Thu, Mar 28, 2024 at 8:03 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Joe, > > I had not, just did, worse yet > > EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 > KB/sec - Overall transfer rate 1281.27 KB/sec > EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 > KB/sec - Overall transfer rate 1059.52 KB/sec > EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 > KB/sec - Overall transfer rate 969.15 KB/sec > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on behalf > of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> > Date: Thursday, March 28, 2024 at 8:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Slow FTP's > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at > 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. > edu> wrote: > All, > > Grasping at straws here, IBM support center is > baffled too. > > > > Have you tried MODE S (streaming) and TYPE E? > > > > Joe > > > > On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > All, > > > > > > Grasping at straws here, IBM support center is baffled too. > > > > > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > > > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > > > transfer. There is some environmental issue causing slow file transfers > to > > > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > > > systems on the same CEC.With IBM support help, we’ve narrowed down > the > > > problem to the specification of MODE B and EBCDIC on the transfer since > it > > > is a DSS dump. Remove those, and the transfer is fast on the slow > > > systems, and still fast on the fast systems. Obviously that isn’t a > > > solution though. > > > > > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > > > to the K systems(control systems), and all the “slow” transfers are to > the > > > traditional application systems. TEST, DEV, PROD makes no difference, > nor > > > does LPAR busy or not busy. > > > > > > It seems there is something configured differently on the “slow” systems > > > that is affecting mode b, ebcdic file transfers, but for the life of me, > I > > > cannot put my finger on what, nor can the support center, except that the > > > issue is at the remote end, in that the OS cannot offload the data fast > > > enough, so TCPIP/FTP is slowing the transfer pace. > > > > > > A virtual adult beverage of choice to the one that can point in a > > > direction to look…. > > > > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > This e-mail transmission contains information that is confidential and > may > > > be privileged. It is intended only for the addressee(s) named above. If > > > you receive this e-mail in error, please do not read, copy or disseminate > > > it in any manner. If you are not the intended recipient, any disclosure, > > > copying, distribution or use of the contents of this information is > > > prohibited. Please reply to the message immediately by informing the > sender > > > that the message was misdirected. After replying, please erase it from > your > > > computer system. Your assistance in correcting this error is appreciated. > > > > > > -- > > > 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 > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > -- > 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
Re: Slow FTP's
Joe, I had not, just did, worse yet EZA1485I 12902400 bytes transferred - 10 second interval rate 1281.27 KB/sec - Overall transfer rate 1281.27 KB/sec EZA1485I 21381120 bytes transferred - 10 second interval rate 838.65 KB/sec - Overall transfer rate 1059.52 KB/sec EZA1485I 29491200 bytes transferred - 10 second interval rate 791.23 KB/sec - Overall transfer rate 969.15 KB/sec Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Joe Monk <05971158733e-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7: 31 AM Jousma, David < 01a0403c5dc1-dmarc-request@ listserv. ua. edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > to the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems > that is affecting mode b, ebcdic file transfers, but for the life of me, I > cannot put my finger on what, nor can the support center, except that the > issue is at the remote end, in that the OS cannot offload the data fast > enough, so TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a > direction to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > -- > 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
Thanks Colin, We’ve already taken packet traces of both, and sent to IBM. They see the send window being reduced automatically by TCPIP because the remote end cannot keep up. the problem only surfaces when doing EBCDIC and BLOCK transfers. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Colin Paice <059d4daca697-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's Dave, I've been working on a TCP session monitor. It reports MB/Second + changes to the TCP parameters, such as change in window size, buffer size etc. all of which affect throughput. I can let you have a copy of the program if you are interested. Dave, I've been working on a TCP session monitor. It reports MB/Second + changes to the TCP parameters, such as change in window size, buffer size etc. all of which affect throughput. I can let you have a copy of the program if you are interested. colinpai...@gmail.com it reports //SYSPRINT Using --PORT 22 --SLEEP 10 --COUNT 10 --TCPIP TCPIP HH:MM:SS,remote ,BytesI,BytesO,,SegsI , SegsO,,BI/Sec,BO/Sec,,ReXmtC, 08:33:23,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:23,10.1.0.2:4 , 676, 45832,,54,63,,67, 4583,, 0, 08:33:33,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:33,10.1.0.2:4 ,52, 27452,,15,28,, 5, 2745,, 0, 08:33:43,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, Freeing entry 10.1.0.2:41984 08:33:53,10.1.0.2:37728 , 156, 1164,,14,11,,15, 116,, 0, 08:33:53,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:04,10.1.0.2:37728 , 416, 71932,,50,77,,37, 6539,, 0, 08:34:04,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, The first time the program sees a connection it dumps out 10.1.0.2:41984 JOBNAME SSHD4 Interface TAP0 10.1.0.2:41984 ResourceId:45 InSegs:37 OutSegs:31 SSThresh: 65535 10.1.0.2:41984 OutBuffered: 0 InBuffered: 0 10.1.0.2:41984 ReXmtCount: 0CongestionWnd: 41760 RoundTripTime: 4 RoundTripVar:11 10.1.0.2:41984 SndBufSize: 65536 SndWnd: 64128 MaxSndWnd: 64256 SendMSS: 1452 10.1.0.2:41984 RcvBufSize: 65536 RcvWnd:131020 Lcl0WindowCount: 0 Rmt0WindowCount: 0 10.1.0.2:41984 If TCPIP parameters change, such as window size you get in //CHANGE 08:33:23 10.1.0.2:4 NWMConnRoundTripTime n:2 - o:4 = -2 08:33:23 10.1.0.2:4 NWMConnRoundTripVar n:2 - o:7 = -5 08:33:33 10.1.0.2:4 NWMConnRoundTripTime n:3 - o:2 = 1 08:33:33 10.1.0.2:4 NWMConnRoundTripVar n:3 - o:2 = 1 08:33:53 10.1.0.2:37728 NWMConnCongestionWnd n:36000 - o:20160 = 15840 08:33:53 10.1.0.2:37728 NWMConnRoundTripTime n:6 - o:10 = -4 08:33:53 10.1.0.2:37728 NWMConnRoundTripVar n:17 - o:29 = -12 08:33:53 10.1.0.2:37728 NWMConnRcvWnd n:131020 - o:130176 = 844 On Thu, 28 Mar 2024 at 12:31, Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > to the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems > that is affecting mode b, ebcdic file transfers, but for the life of me, I > cannot put my finger on what, nor can the support center, except that the > issue is at the remote end, in that the OS cannot offload the
Re: Slow FTP's
Have you tried MODE S (streaming) and TYPE E? Joe On Thu, Mar 28, 2024 at 7:31 AM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > to the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems > that is affecting mode b, ebcdic file transfers, but for the life of me, I > cannot put my finger on what, nor can the support center, except that the > issue is at the remote end, in that the OS cannot offload the data fast > enough, so TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a > direction to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
Thank you, we’ve already compared TCPIP configurations, and they are identical Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> Date: Thursday, March 28, 2024 at 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Slow FTP's z/OS TCP/IP is not my area of expertise. I would check to insure the ITRACE and PKTTRACE are turned off, and take a look at TCPCONFIG TCPMAXRCVBUFRSIZE TCPRCVBUFRSIZE TCPSENDBFRSIZE And, another possibility D TCPIP,tcpipname,NETSTAT,DEV Look z/OS TCP/IP is not my area of expertise. I would check to insure the ITRACE and PKTTRACE are turned off, and take a look at TCPCONFIG TCPMAXRCVBUFRSIZE TCPRCVBUFRSIZE TCPSENDBFRSIZE And, another possibility D TCPIP,tcpipname,NETSTAT,DEV Look for CHECKSUMOFFLOAD YES Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 8:30 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. > There is some environmental issue causing slow file transfers to some systems > (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the > same CEC. With IBM support help, we’ve narrowed down the problem to the > specification of MODE B and EBCDIC on the transfer since it is a DSS dump. > Remove those, and the transfer is fast on the slow systems, and still fast on > the fast systems. Obviously that isn’t a solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems that > is affecting mode b, ebcdic file transfers, but for the life of me, I cannot > put my finger on what, nor can the support center, except that the issue is > at the remote end, in that the OS cannot offload the data fast enough, so > TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a direction > to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Slow FTP's
z/OS TCP/IP is not my area of expertise. I would check to insure the ITRACE and PKTTRACE are turned off, and take a look at TCPCONFIG TCPMAXRCVBUFRSIZE TCPRCVBUFRSIZE TCPSENDBFRSIZE And, another possibility D TCPIP,tcpipname,NETSTAT,DEV Look for CHECKSUMOFFLOAD YES Sent with Proton Mail secure email. On Thursday, March 28th, 2024 at 8:30 AM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. > There is some environmental issue causing slow file transfers to some systems > (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the > same CEC. With IBM support help, we’ve narrowed down the problem to the > specification of MODE B and EBCDIC on the transfer since it is a DSS dump. > Remove those, and the transfer is fast on the slow systems, and still fast on > the fast systems. Obviously that isn’t a solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are to > the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems that > is affecting mode b, ebcdic file transfers, but for the life of me, I cannot > put my finger on what, nor can the support center, except that the issue is > at the remote end, in that the OS cannot offload the data fast enough, so > TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a direction > to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > 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: Slow FTP's
Dave, I've been working on a TCP session monitor. It reports MB/Second + changes to the TCP parameters, such as change in window size, buffer size etc. all of which affect throughput. I can let you have a copy of the program if you are interested. colinpai...@gmail.com it reports //SYSPRINT Using --PORT 22 --SLEEP 10 --COUNT 10 --TCPIP TCPIP HH:MM:SS,remote ,BytesI,BytesO,,SegsI , SegsO,,BI/Sec,BO/Sec,,ReXmtC, 08:33:23,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:23,10.1.0.2:4 , 676, 45832,,54,63,,67, 4583,, 0, 08:33:33,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:33,10.1.0.2:4 ,52, 27452,,15,28,, 5, 2745,, 0, 08:33:43,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, Freeing entry 10.1.0.2:41984 08:33:53,10.1.0.2:37728 , 156, 1164,,14,11,,15, 116,, 0, 08:33:53,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:04,10.1.0.2:37728 , 416, 71932,,50,77,,37, 6539,, 0, 08:34:04,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:4 , 0, 0,, 0, 0,, 0, 0,, 0, The first time the program sees a connection it dumps out 10.1.0.2:41984 JOBNAME SSHD4 Interface TAP0 10.1.0.2:41984 ResourceId:45 InSegs:37 OutSegs:31 SSThresh: 65535 10.1.0.2:41984 OutBuffered: 0 InBuffered: 0 10.1.0.2:41984 ReXmtCount: 0CongestionWnd: 41760 RoundTripTime: 4 RoundTripVar:11 10.1.0.2:41984 SndBufSize: 65536 SndWnd: 64128 MaxSndWnd: 64256 SendMSS: 1452 10.1.0.2:41984 RcvBufSize: 65536 RcvWnd:131020 Lcl0WindowCount: 0 Rmt0WindowCount: 0 10.1.0.2:41984 If TCPIP parameters change, such as window size you get in //CHANGE 08:33:23 10.1.0.2:4 NWMConnRoundTripTime n:2 - o:4 = -2 08:33:23 10.1.0.2:4 NWMConnRoundTripVar n:2 - o:7 = -5 08:33:33 10.1.0.2:4 NWMConnRoundTripTime n:3 - o:2 = 1 08:33:33 10.1.0.2:4 NWMConnRoundTripVar n:3 - o:2 = 1 08:33:53 10.1.0.2:37728 NWMConnCongestionWnd n:36000 - o:20160 = 15840 08:33:53 10.1.0.2:37728 NWMConnRoundTripTime n:6 - o:10 = -4 08:33:53 10.1.0.2:37728 NWMConnRoundTripVar n:17 - o:29 = -12 08:33:53 10.1.0.2:37728 NWMConnRcvWnd n:131020 - o:130176 = 844 On Thu, 28 Mar 2024 at 12:31, Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC.With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > to the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems > that is affecting mode b, ebcdic file transfers, but for the life of me, I > cannot put my finger on what, nor can the support center, except that the > issue is at the remote end, in that the OS cannot offload the data fast > enough, so TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a > direction to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > >
Slow FTP's
All, Grasping at straws here, IBM support center is baffled too. To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file transfer. There is some environmental issue causing slow file transfers to some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other systems on the same CEC. With IBM support help, we’ve narrowed down the problem to the specification of MODE B and EBCDIC on the transfer since it is a DSS dump. Remove those, and the transfer is fast on the slow systems, and still fast on the fast systems. Obviously that isn’t a solution though. So, we are a GDPS shop. The oddity is that all the “fast” transfers are to the K systems(control systems), and all the “slow” transfers are to the traditional application systems. TEST, DEV, PROD makes no difference, nor does LPAR busy or not busy. It seems there is something configured differently on the “slow” systems that is affecting mode b, ebcdic file transfers, but for the life of me, I cannot put my finger on what, nor can the support center, except that the issue is at the remote end, in that the OS cannot offload the data fast enough, so TCPIP/FTP is slowing the transfer pace. A virtual adult beverage of choice to the one that can point in a direction to look…. Dave Jousma Vice President | Director, Technology Engineering This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFsort error message
As for many abend codes, the numbers relate to SVC number. Open SVC is 19, which is x'13' hence many OPEN issues are 213 or 913 and so on. EOV SVC is 55, which is x'37', hence many out of space issues are D37, E37 and so on. This informal rule applies to many other SVCs as well. Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob T Roller Sent: 27 March 2024 17:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFsort error message One of the most important things I learned 45 years ago was 37 is always a space issue. 13 was an open issue and 14 a close issue. Sent from [Proton Mail](https://proton.me/mail/home) for iOS On Tue, Mar 26, 2024 at 1:24 PM, Ron Thomas <[0600304cab5d-dmarc-requ...@listserv.ua.edu](mailto:On Tue, Mar 26, 2024 at 1:24 PM, Ron Thomas < wrote: > Hi All - > > We are getting a sort error on a huge file . Below are the details > from log > > Parm cards used > SORT FIELDS=COPY > > Error Log details > > ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT > SELECTED ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION > MODULE DEFAULTS ICE088I 0 ITGB9059.STEP02 .SORT , INPUT LRECL = 317, > BLKSIZE = 27896, TYPE = ICE093I 0 MAIN STORAGE = > (MAX,33554432,33554432) ICE156I 0 MAIN STORAGE ABOVE 16MB = > (33497072,33497072) ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 > ,SPANINC=RC16,VLSCMP=N,SZERO=Y, ICE128I 0 OPTIONS: > SIZE=33554432,MAXLIM=1048576,MINLIM=450560,EQUALS=N,LIST=Y,ER > ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=FULL > ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT= > ICE130I 0 OPTIONS: RESALL=8192,RESINV=0,SVC=109 > ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT= ICE131I 0 OPTIONS: > TMAXLIM=33554432,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW > ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE > ,EXITC ICE133I 0 OPTIONS: HIPRMAX=0 > ,DSPSIZE=2000,ODMAXBF=2097152,SOLRF=N,VLLONG=N > ICE235I 0 OPTIONS: NULLOUT=RC0 > ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y,TUNE=STOR,EXPMAX=2000 > ,EXPOLD=MAX ,E ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN ICE889I 0 > CT=MAX , SB=3, L=0, D=, CCW=1MAM ICE902I 0 O I PP11 ICE906I 1 > ST=ABOVE,SR=33497072,RC=0 ICE907I 1 > ST=ABOVE,SA=33497056,NF=1,LF=33497056,SF=33497056 > ICE906I 1 ST=BELOW,SR=98320,RC=0 > ICE907I 1 ST=BELOW,SA=49152,NF=1,LF=49152,SF=49152 > ICE231I 0 STORAGE USED FOR OUTFIL : BELOW 16M = 20480, ABOVE 16M = > 2119680 ICE231I 0 STORAGE USED FOR OUTFIL : BELOW 16M = 20480, ABOVE > 16M = 2119680 ICE855I 0 SORTOUT : TX=N, R=J, L=J, B=D, BL=0, BR=0, > DCT=37, VS=N, RU=X, SB=8 ICE210I 0 SORTOUT : EXCP USED, LRECL = 317, > BLKSIZE = 27896, TYPE = FB ICE751I 2 EF-I80638 CB-NONE F0-NONE > DA-I76950 ICE185A 0 AN SE37 ABEND WAS ISSUED BY DFSORT, ANOTHER > PROGRAM OR AN EXIT (PHASE > > Job Step work file details . Allocated SORTWK50 files > > XXSORTWK09 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK10 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK11 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK12 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK13 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK14 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK15 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK16 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK17 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK18 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > XXSORTWK19 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,()) > IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200)) > > //SORTOUT DD DSN=KGN01.PS.RPCFIL.AMT.ACTV.UNLD.FINAL1.HDR, > // SPACE=(CYL,(1200,500),RLSE),VOL=(,,,99), > // RECFM=FB,DSORG=PS, > // DISP=(NEW,CATLG,DELETE),LRECL=317,BLKSIZE=0 > //SYSIN DD DSN=MK.PS.PROD.PARMLIB(PSJH06P),DISP=SHR > > Could someone please let us know what needs to be done here? > > Regards > Ron T > > -- > 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
