Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
In 4914821700290639.wa.walt.farrellgmail@bama.ua.edu, on 04/24/2012 at 11:33 AM, Walt Farrell walt.farr...@gmail.com said: As often happens when people include links in sentences, his sentence-ending punctuation (. ) was taken as part of the link. Which is why enclusing a URL in is best practice. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Greg Boyd IBM Advanced Technical Support Supporting Crypto on System z -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
On Tue, 24 Apr 2012 10:00:46 -0500, Greg Boyd wrote: Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Gives me 404: Not Found The requested URL /groups/STM/cavp/documents/shs/shaval.htm. was not found on this server. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
Worked for me. Rob Schramm Senior Systems Consultant Imperium Group On Tue, Apr 24, 2012 at 12:15 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 24 Apr 2012 10:00:46 -0500, Greg Boyd wrote: Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Gives me 404: Not Found The requested URL /groups/STM/cavp/documents/shs/shaval.htm. was not found on this server. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
On Tue, 24 Apr 2012 11:15:37 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 24 Apr 2012 10:00:46 -0500, Greg Boyd wrote: Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Gives me 404: Not Found The requested URL /groups/STM/cavp/documents/shs/shaval.htm. was not found on this server. As often happens when people include links in sentences, his sentence-ending punctuation (. ) was taken as part of the link. Simply remove it and the link works fine. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
On Tue, 24 Apr 2012 12:23:39 -0400, Rob Schramm wrote: Worked for me. Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Gives me 404: Not Found The requested URL /groups/STM/cavp/documents/shs/shaval.htm. was not found on this server. Were you subscribed or reading from the web? Ah! YA LISTSERV stupidity. Looking at the page source: see Cert #1497 at a href=http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm.; ... It's the period at the end. SIGH/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
On Tue, 24 Apr 2012 11:33:08 -0500, Walt Farrell wrote: Starting with ICSF HCR7750 and the z9, ICSF relies on the CPACF hardware on the host for the full SHA support (SHA-1 as well as SHA-2). The CP Assist (CP Assist for Cryptographic Function) is running compliant implementations of the SHA algorithms. For the z196, see Cert #1497 at http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm As often happens when people include links in sentences, his sentence-ending punctuation (. ) was taken as part of the link. Simply remove it and the link works fine. I try _so_ hard not to do that; sometimes I even repair broken links when I reply. Sometimes I slip up. The above further refers to: http://csrc.nist.gov/groups/STM/cavp/documents/shs/SHAVS.pdf The validation seems to be entirely empirical; they don't audit the microcode. This leaves open the possibility of a magic message back door. When SMP/E RECEIVE FROMNETWORK came out, it was followed by an APAR fixing an error in SHA-1 computation. Not the fault of ICSF, but of the way SMP/E invoked it; a buffer alignment logic error. Then there was a second APAR providing tolerance for SHA hashes incorrectly computed in SYSMODs extant before the first APAR. Reasonably safe if some ranges of bytes were processed twice; more problematic if some ranges of bytes were never processed leaving a nook in which a Trojan Horse could hide. Hmmm. This could be the basis for the APAR IO11698 fiasco two years ago in which IBM manfestly allowed an integrity exposure to remain unrepaired but provided a means of limiting access to the dangerous tool. I have been granted the RACF authority as I need it for my job; this indicates that I qualify as highly trusted. But it irritates me that I have never been given instructions concerning what behavior I must avoid in order not to compromise system integrity. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ICSF/CSNBOWH (was: load mmodules copying to other site)
On Tue, 24 Apr 2012 12:05:28 -0500, Paul Gilmartin paulgboul...@aim.com wrote: Hmmm. This could be the basis for the APAR IO11698 fiasco two years ago in which IBM manfestly allowed an integrity exposure to remain unrepaired but provided a means of limiting access to the dangerous tool. No, it's not related to anything like that. I have been granted the RACF authority as I need it for my job; this indicates that I qualify as highly trusted. But it irritates me that I have never been given instructions concerning what behavior I must avoid in order not to compromise system integrity. Having that authority, there's nothing special you neeed to do to avoid compromising system integrity, beyond what you would normally do as someone with the authority to update APF libraries. By granting you that authority, the security administrator has merely indicated his trust that you will not actively try to compromise system security or integrity, and that he trusts you as much as he would had he given you UPDATE to the APF libraries and other sensitive system libraries. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
ICSF/CSNBOWH (was: load mmodules copying to other site)
On Wed, 31 Aug 2011 (last year) 20:07:42 -0500, Paul Gilmartin (I) wrote: If you have ICSF, there's CSNBOWH. See Rexx samples in SYS1.SAMPLIB(CSF*). There's a manual somewhere. A few days ago, I received an off-list communication from a colleague who tried this, then attempted to replicate the ICSF results with two online conversion sites that agreed with each other and disagreed with ICSF. I strongly suspect his problems were ASCII/EBCDIC or newline conventions. Personally, I have great faith in IBM hardware, but how to reassure a skeptic? Perhaps Walt will jump in with a link to an independent certification of ICSF SHA-1. (I replicated the ICSF result with a third online conversion site and with a C program I downloaded from Sourceforge long ago. I was not able to get any result, right or wrong from either of the two sites my correspondent mentioned. NoScript.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: load mmodules copying to other site
In 6533006138111618.wa.paulgboulderaim@bama.ua.edu, on 09/01/2011 at 09:40 PM, Paul Gilmartin paulgboul...@aim.com said: About half. For large values of half. IEBUPDTE will load a PDS IEBUPDTE input has been used as a distibution medium for source code for decades, but it is *not* a PDS load utility and it is not possible to construct an IEBUPDTE input stream to build an arbitrary PDS, even an arbitrary RECFM=FB,LRECL=80 PDS. Next, I'd like to see TRANSMIT and RECEIVE liberated from TSO so I could use them in EXECs, perhaps even under OMVS. Does address TSO XMIT work in a Unix session? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Fri, 2 Sep 2011 08:33:50 -0400, Shmuel Metz (Seymour J.) wrote: IEBUPDTE input has been used as a distibution medium for source code for decades, but it is *not* a PDS load utility and it is not possible to construct an IEBUPDTE input stream to build an arbitrary PDS, even an arbitrary RECFM=FB,LRECL=80 PDS. Agreed. Arbitrary is the key word here. Does address TSO XMIT work in a Unix session? I believe TRANSMIT works; RECEIVE doesn't because I've never been able to reply to the prompt. (IIRC; haven't tried recently.) I could probably do address TSO EXEC some EXEC that stacks the reply then issues the RECEIVE command. But that's unpleasantly convoluted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Dave and Gil, Your suggestion worked fine for a single member: T$SFC:/u/t4sfc: cp -B //'sys3.clist(rdmstat)' /dev/fd1 | cksum 260387907 21600 It also works fine for a sequential file: T$SFC:/u/t4sfc: cp -B //'SYS3.FTP.NETRC' /dev/fd1 | cksum 2567740904 240 It fails for an entire PDS: T$SFC:/u/t4sfc: cp -B //'SYS1.MACLIB' /dev/fd1 | cksum cp: FSUMF137 partitioned data set source and a file target is not allowed It also fails trying to use a classic MVS file (of any DSORG) as input directly to the cksum command: T$SFC:/u/t4sfc: cksum //'SYS1.MACLIB' cksum: FSUM6003 input file //'SYS1.MACLIB': EDC5129I No such file or directory. T$SFC:/u/t4sfc: cksum //'SYS3.FTP.NETRC' cksum: FSUM6003 input file //'SYS3.FTP.NETRC': EDC5129I No such file or directory. Thanks for the pointing in the right direction. I had not noticed the existence of the cksum command. Now to figure out how to do something useful with it. :-) Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Thu, 1 Sep 2011 10:51:14 -0400, Steve Conway wrote: Dave and Gil, Your suggestion worked fine for a single member: T$SFC:/u/t4sfc: cp -B //'sys3.clist(rdmstat)' /dev/fd1 | cksum 260387907 21600 It also works fine for a sequential file: T$SFC:/u/t4sfc: cp -B //'SYS3.FTP.NETRC' /dev/fd1 | cksum 2567740904 240 I said it's newline-ignorant. It won't distinguish betweeh: A B C and: ABC because of the -B. But if you omit the -B it won't distinguish between: ANLB and: A B ... which matters little if RECFM=FB. It fails for an entire PDS: T$SFC:/u/t4sfc: cp -B //'SYS1.MACLIB' /dev/fd1 | cksum cp: FSUMF137 partitioned data set source and a file target is not allowed No hope for that. | cksum expects a single sequential stream. But you could verify a TSO TRANSMIT unloaded archive. It also fails trying to use a classic MVS file (of any DSORG) as input directly to the cksum command: T$SFC:/u/t4sfc: cksum //'SYS1.MACLIB' cksum: FSUM6003 input file //'SYS1.MACLIB': EDC5129I No such file or directory. T$SFC:/u/t4sfc: cksum //'SYS3.FTP.NETRC' cksum: FSUM6003 input file //'SYS3.FTP.NETRC': EDC5129I No such file or directory. Such use of classic data sets is documented and supported for only a handful of utilities (such as cp). It happens to work for several others, but is undocumented and presumably unsupported. Thanks for the pointing in the right direction. I had not noticed the existence of the cksum command. POSIX requires it, else IBM wouldn't have provided it. (That's only approximately true. 1.13 newly provides script which is not a POSIX requirement. I suspect IBM deemed it invaluable for customer problem reporting.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
In 1314835540.55397.yahoomailclas...@web31807.mail.mud.yahoo.com, on 08/31/2011 at 05:05 PM, Cris Hernandez #9 hernandez...@yahoo.com said: I'd start with standard IBM utility (iebupdte) to unload the pds to a sequential file, NFW! That's an update utility, not a load/unload utility. Use TSO XMIT/RECEIVE, which support encapsulating IEBCOPY output in RECFM=FB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Thu, 1 Sep 2011 11:58:47 -0400, Shmuel Metz (Seymour J.) wrote: In 1314835540.55397.yahoomailclas...@web31807.mail.mud.yahoo.com, on 08/31/2011 at 05:05 PM, Cris Hernandez #9 said: I'd start with standard IBM utility (iebupdte) to unload the pds to a sequential file, NFW! That's an update utility, not a load/unload utility. Use TSO XMIT/RECEIVE, which support encapsulating IEBCOPY output in RECFM=FB. About half. IEBUPDTE will load a PDS (given the proper input data, and with some lexical restrictions). But I don't see that it will unload. I wonder whether liberating IEBCOPY from APF in 1.13 will have wonderful consequences. Next, I'd like to see TRANSMIT and RECEIVE liberated from TSO so I could use them in EXECs, perhaps even under OMVS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
You can also ftp the load modules directly: cd 'REMOTE.PDS' lcd 'LOCAL.PDS' bin put *// copies all modules in local.pds to remote.pds -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Tuesday, August 30, 2011 5:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site 1. ftp is working, it is supported (with some limitations) for load module transmission since OS/390 2.10 (AFAIR). 2. There are many methods to do that. One of them, the method allows indirect transmission (z/OS-PC-whatever-z/OS): 1. XMIT A.A DA(your.library) OUTDA(X1) 2. get X1 from z/OS to your PC. Use binary mode! You can use ftp or IND$FILE. 3. move the file from PC to PC, as any other file. Email attachments, pendrives, CD-Rs, diskettes - everything is allowed (but not file modification). 4. Put the file to destination z/OS image. THIS IS IMPORTANT: be sure to use binary mode and PS FB 80 as destination dataset. 5. RECEIVE INDA(X1) Now you should have PDS with the load modules. -- Radoslaw Skorupka Lodz, Poland W dniu 2011-08-30 22:48, Tim Brown pisze: How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists
Re: load mmodules copying to other site
On Tue, 30 Aug 2011 16:48:14 -0400, Tim Brown tbr...@cenhud.com wrote: How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib Check the load module attributes of the source library. AFAIAA, ftp still doesn't handle scatter-load or page-aligned modules very well, but admittedly it has been a long time since I used ftp without XMIT/RECEIVE or TERSE/UNTERSE as others have suggested. Other than those special attributes, as long as you are setting TYPE E, MODE B and have the DCB attributes on your target library the same as that of your source, ftp should work OK. Another option, if you're feeling adventurous, is to use GIMZIP/GIMUNZIP to build an NTS package to ship across. The interface requires some basic knowledge of XML, but it can handle PDS, PDSE, VSAM, and PS files, and can pre-allocate non-existing target datasets on the remote site. A UNIX file system is required to stow the package, but SMP/E itself is not needed (i.e., no RECEIVE FROMNETWORK / FROMNTS) for non-SMP/E installable packages. IOW, GIMZIP/GIMUNZIP can be directly invoked froim JCL. Review the SMP/E books for details. HTH, Art Gutowski Compuware Corporation -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Don't use binary for z/os to z/os. This defeats compression which can speed things up quite a bit. Use binary only when passing through a Windows machine to avoid unwanted translation/corruption. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, August 30, 2011 6:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site XMIT in to a file (see help xmit) ftp (binary) RECEIVE from a file - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Tim Brown tbr...@cenhud.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Tue, 30 Aug 2011 16:48:14 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: load mmodules copying to other site How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. 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, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Wed, 31 Aug 2011 11:19:55 -0500, Hal Merritt wrote: Don't use binary for z/os to z/os. This defeats compression which can speed things up quite a bit. Use binary only when passing through a Windows machine to avoid unwanted translation/corruption. Beware. If, for example, TSO TRANSMIT unloaded data contain a 0x0D15 sequence, this may be translated to ASCII 0x0D0A and interpreted as a network line separator, causing the record to be split at the receiving end. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Depending on your FTP defaults, you may need to explicitly say TYPE E then MODE C. Correctly stating the data type is worth the effort IMHO. However, as I said, data passing through a Windows box is subject to corruption / translation. Again, the suggestion is for z/os to z/os only. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Wednesday, August 31, 2011 11:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site On Wed, 31 Aug 2011 11:19:55 -0500, Hal Merritt wrote: Don't use binary for z/os to z/os. This defeats compression which can speed things up quite a bit. Use binary only when passing through a Windows machine to avoid unwanted translation/corruption. Beware. If, for example, TSO TRANSMIT unloaded data contain a 0x0D15 sequence, this may be translated to ASCII 0x0D0A and interpreted as a network line separator, causing the record to be split at the receiving end. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Wed, 31 Aug 2011 11:37:44 -0500, Hal Merritt wrote: Depending on your FTP defaults, you may need to explicitly say TYPE E then MODE C. Correctly stating the data type is worth the effort IMHO. However, as I said, data passing through a Windows box is subject to corruption / translation. Again, the suggestion is for z/os to z/os only. From a desktop intermediary (I, too, would use one other than Windows) I might do: 501 $ ftp mvs Connected to mvs. 220-FTPD1 IBM FTP CS V1R12 at ..., 17:50:58 on 2011-08-31. ... Remote system type is MVS. ftp binary 200 Representation type is Image ftp quote type e 200 Representation type is Ebcdic NonPrint ftp quote mode c 200 Data transfer mode is Compressed ftp ... I'd verify a checksum after and before. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
What would you use to do a checksum on z/OS? Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@bama.ua.edu Date: 08/31/2011 02:00 PM Subject:Re: load mmodules copying to other site Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Wed, 31 Aug 2011 11:37:44 -0500, Hal Merritt wrote: Depending on your FTP defaults, you may need to explicitly say TYPE E then MODE C. Correctly stating the data type is worth the effort IMHO. However, as I said, data passing through a Windows box is subject to corruption / translation. Again, the suggestion is for z/os to z/os only. From a desktop intermediary (I, too, would use one other than Windows) I might do: 501 $ ftp mvs Connected to mvs. 220-FTPD1 IBM FTP CS V1R12 at ..., 17:50:58 on 2011-08-31. ... Remote system type is MVS. ftp binary 200 Representation type is Image ftp quote type e 200 Representation type is Ebcdic NonPrint ftp quote mode c 200 Data transfer mode is Compressed ftp ... I'd verify a checksum after and before. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Wed, 31 Aug 2011 14:46:50 -0400, Steve Conway wrote: What would you use to do a checksum on z/OS? If you use GIMZIP/GIMUNZIP as Art suggested, a checksum will be created and checked. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Thanks, Tom. I was responding to Gil's post, in which he was going z/OS - desktop - z/OS, no mention of GIMZIP / GIMUNZIP. Guess I just missed the tie-in. Although a z/OS checksum would make dealing with certain auditors easier to satisfy... Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Tom Marchant m42tom-ibmm...@yahoo.com To: IBM-MAIN@bama.ua.edu Date: 08/31/2011 02:56 PM Subject:Re: load mmodules copying to other site Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Wed, 31 Aug 2011 14:46:50 -0400, Steve Conway wrote: What would you use to do a checksum on z/OS? If you use GIMZIP/GIMUNZIP as Art suggested, a checksum will be created and checked. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
W dniu 2011-08-31 18:28, Paul Gilmartin pisze: On Wed, 31 Aug 2011 11:19:55 -0500, Hal Merritt wrote: Don't use binary for z/os to z/os. This defeats compression which can speed things up quite a bit. Use binary only when passing through a Windows machine to avoid unwanted translation/corruption. Beware. If, for example, TSO TRANSMIT unloaded data contain a 0x0D15 sequence, this may be translated to ASCII 0x0D0A and interpreted as a network line separator, causing the record to be split at the receiving end. In fact I've been using load module ftp transmission since OS/390 2.6 (yes, it was unsupported then). It's really works, but under serious restrictions. AFAIK binary keyword is simply default, and it's not out of allowed parameters set. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
In: UNIX System Services Command Reference Document Number SA22-7802-12 There is: CKSUM cksum -- Calculate and display checksums and byte counts Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Conway Sent: Wednesday, August 31, 2011 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site Thanks, Tom. I was responding to Gil's post, in which he was going z/OS - desktop - z/OS, no mention of GIMZIP / GIMUNZIP. Guess I just missed the tie-in. Although a z/OS checksum would make dealing with certain auditors easier to satisfy... Cheers,,,Steve Steven F. Conway, CISSP LA Systems z/OS Systems Support Phone: 703.295.1926 steve_con...@ao.uscourts.gov From: Tom Marchant m42tom-ibmm...@yahoo.com To: IBM-MAIN@bama.ua.edu Date: 08/31/2011 02:56 PM Subject:Re: load mmodules copying to other site Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On Wed, 31 Aug 2011 14:46:50 -0400, Steve Conway wrote: What would you use to do a checksum on z/OS? If you use GIMZIP/GIMUNZIP as Art suggested, a checksum will be created and checked. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
I'd start with standard IBM utility (iebupdte) to unload the pds to a sequential file, send it, then use same utility to create a new pds (or update) from the sequential file. if it gets screwed up in transmit, deal with it when it happens, the messages in the utility output should indicate such when reloaded to pds, plus they won't execute. been a while for me, but it once was standard fare when cobol applications were replicated across multiple sites. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
The standard IBM utility to unload a PDS is IEBCOPY. TRANSMIT uses IEBCOPY to unload the PDS and then encapsulates in in a transmittable format. This suggestions given in this thread (and dozens of others in the past) work. KIS Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Cris Hernandez #9 Sent: Wednesday, August 31, 2011 5:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site I'd start with standard IBM utility (iebupdte) to unload the pds to a sequential file, send it, then use same utility to create a new pds (or update) from the sequential file. if it gets screwed up in transmit, deal with it when it happens, the messages in the utility output should indicate such when reloaded to pds, plus they won't execute. been a while for me, but it once was standard fare when cobol applications were replicated across multiple sites. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Wed, 31 Aug 2011 14:46:50 -0400, Steve Conway steve_con...@ao.uscourts.gov wrote: What would you use to do a checksum on z/OS? cp -B //'DATA.SET.NAME(MEMBER)' /dev/fd/1 | /bin/cksum # (IIRC) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
On Wed, 31 Aug 2011 17:05:40 -0700, Cris Hernandez #9 hernandez...@yahoo.com wrote: I'd start with standard IBM utility (iebupdte) to unload the pds to a sequential file, send it, then use same utility to create a new pds (or update) from the sequential file. if it gets screwed up in transmit, deal with it when it happens, the messages in the utility output should indicate such when reloaded to pds, plus they won't execute. been a while for me, but it once was standard fare when cobol applications were replicated across multiple sites. Hmmm... I've always wondered what happens if you use IEBUPDTE to unload and subsequently reload a JCL library containing IEBUPDTE commands and associated SYSIN data sets? I'd worry less about IEBCOPY/TRANSMIT. After shooting from the hip, I decided to test my /bin/cksum suggestion: user@MVS:131$ _UNIX03=NO cp -B //'sys1.maclib(splevel)' /dev/fd/1 | cksum 3684370417 29440 ... of good quality and suitable for daily use. But it is record-boundary- ignorant. Don't let your auditors know, lest they care. (What's a good DSN(MEMBER) to use for tests/demos such as this?) If you have ICSF, there's CSNBOWH. See Rexx samples in SYS1.SAMPLIB(CSF*). There's a manual somewhere. And my suggestion for FTP: binary quote site type E quote site mode C ... is pretty much guaranteed _not_ to work for load modules. I forgot the Subject: of this thread. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
load mmodules copying to other site
How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. 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, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Try XMIT, TERSE, FTP, UNTERSE, RECEIVE Thank You, Paul Strauss Integrated Technology Delivery, Global Services, IBM L0DB z/OS MVS/Program Products/Security 150 Kettletown Rd. Southbury, CT 06488 (203) 272-2758 strau...@us.ibm.com | | From: | | --| |Tim Brown tbr...@cenhud.com | --| | | To:| | --| |IBM-MAIN@bama.ua.edu | --| | | Date: | | --| |08/30/2011 04:49 PM | --| | | Subject: | | --| |load mmodules copying to other site | --| | | Sent by: | | --| |IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu | --| How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended
Re: load mmodules copying to other site
For a PDS probably don't even need the TERSE, UNTERSE. XMIT with ODSN will produce an 'unloaded' IEBCOPY into a FB 80 3200 dsn. Then FTP bin and RECEIVE IDSN. In a message dated 8/30/2011 3:54:36 P.M. Central Daylight Time, strau...@us.ibm.com writes: Try XMIT, TERSE, FTP, UNTERSE, RECEIVE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
1. ftp is working, it is supported (with some limitations) for load module transmission since OS/390 2.10 (AFAIR). 2. There are many methods to do that. One of them, the method allows indirect transmission (z/OS-PC-whatever-z/OS): 1. XMIT A.A DA(your.library) OUTDA(X1) 2. get X1 from z/OS to your PC. Use binary mode! You can use ftp or IND$FILE. 3. move the file from PC to PC, as any other file. Email attachments, pendrives, CD-Rs, diskettes - everything is allowed (but not file modification). 4. Put the file to destination z/OS image. THIS IS IMPORTANT: be sure to use binary mode and PS FB 80 as destination dataset. 5. RECEIVE INDA(X1) Now you should have PDS with the load modules. -- Radoslaw Skorupka Lodz, Poland W dniu 2011-08-30 22:48, Tim Brown pisze: How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: load mmodules copying to other site
Paul Much thanks , Perfect !! Tim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Strauss Sent: Tuesday, August 30, 2011 4:53 PM To: IBM-MAIN@bama.ua.edu Subject: Re: load mmodules copying to other site Try XMIT, TERSE, FTP, UNTERSE, RECEIVE Thank You, Paul Strauss Integrated Technology Delivery, Global Services, IBM L0DB z/OS MVS/Program Products/Security 150 Kettletown Rd. Southbury, CT 06488 (203) 272-2758 strau...@us.ibm.com | | From: | | --| |Tim Brown tbr...@cenhud.com | --| | | To:| | --| |IBM-MAIN@bama.ua.edu | --| | | Date: | | --| |08/30/2011 04:49 PM | --| | | Subject: | | --| |load mmodules copying to other site | --| | | Sent by: | | --| |IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu | --| How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643
Re: load mmodules copying to other site
XMIT in to a file (see help xmit) ftp (binary) RECEIVE from a file - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Tim Brown tbr...@cenhud.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Tue, 30 Aug 2011 16:48:14 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: load mmodules copying to other site How can one get 1 pds with modules from one site to another, FTP is not working I first tried tersing the pds, transferring via pc/file transfer and untersing and copying Into loadlib The untersed file on the remote end apperars ok via 3.4 but cant copy the modules Into destination loadlib BROWSETECH.TCPIP.SEZALOAD.TRS.UNL Row 1 of 6 Command === Scroll === PAGE Name PromptAlias-of Size TTR AC AM RM _ EZAFTPLC 001904CC 09 0131 ANY _ EZAFTPLD 00066B7C 003501 0131 ANY _ EZAFTPLS 0017962C 004508 0131 ANY _ FTP EZAFTPLC 001904CC 09 0131 ANY _ FTPDEZAFTPLD 00066B7C 003501 0131 ANY _ FTPDNS EZAFTPLS 0017962C 004508 0131 ANY **End** COPY failed From data set . . . . . : TECH.TCPIP.SEZALOAD.TRS.UNL To data set . . . . . . : TCPIP.SEZALOAD The listing from IEBCOPY is displayed below. S M=(FTPDNS) EB1013I COPYING FROM PDS INDD=SYS00181 VOL=CHGUS2 DSN=TECH.TCPIP.SEZALOAD.TRS EB1014I TO PDSE OUTDD=ISP16103 VOL=Z11RS1 DSN=TCPIP.SEZALOAD GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLC BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLD BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01207E BINDER DETECTED AN ERROR WHILE PROCESSING MEMBER EZAFTPLS BINDER RETURN CODE = X'000C' REASON CODE = X'83000503' GW01550I 0 OF 6 SPECIFIED MEMBERS WERE COPIED Thanks, Tim Brown Systems Specialist - Project Leader Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. 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, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
