Re: Zfs from 1 LPAR to another
Thanks Bruce for still helping us. So if IEBGENER cannot reliably process them, nor can ftp apparently, who can? Why can AMATERSE? Where is all this documented? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 07 November 2019 16:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another On Thu, 7 Nov 2019 02:21:29 -0600, Barbara Nitz wrote: >"We don't document that you cannot wash dishes with a CPU!" That's a good one, Barbara! This discussion has come up before, and I thought I remembered someone saying that DFDSS will write blocks up to 64K bytes, so I looked and found the following post from Bruce Black. IMO, he is one of the more knowledgeable who has been here. Perhaps this explains some of the issues with using FTP to transport untersed DFDSS dumps. On Wed, 20 Jul 2005 12:41:01 -0400, Bruce Black wrote: >SDB does not work for RECFM=U, which can't be blocked by definition. >The application (DSS in this case) controls the actually blocksize. > >In any case, DSS writes blocks up to 64K (even though the DCB info says >32760). You can't copy a DSS backup (or an FDR backup) with IEBGENER, >the output will not be usable). > >-- >Bruce A. Black >Senior Software Developer for FDR -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Have you submitted an RCF? You might mention directory information as well. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Vernooij, Kees (ITOP NM) - KLM Sent: Thursday, November 7, 2019 3:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another Ok, back with ftp then. It keeps thing a little simple. As Americans, they should know that they must document that you cannot dry your cat in the microwave. If ftp cannot handle the standard recfm=u format, it should be corrected or documented, not left to the customer to discover it (crashing a system or a migrationproject). Can anyone from IBM comment on this? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: 07 November 2019 09:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another >Did you transport the catalog dump dataset with ftp? Yes. I started out just adrdssu dumping the catalog, then ftp'ing. After restore and import the catalog was broken. Putting terse between the dump and ftp fixed the problem. >If yes, this might again point to ftp. >If not, the problem must be in the dump dataset. Then DFdss dump produces (can >produce) a non-standard recfm=u dataset, that will be processed correctly by >dfdss restore, but might confuse other programs reading it. This should be >documented with DFdss in my opinion. I believe that I later checked about the difference between the untersed dump and the tersed dump with regard to ftp. But I had already lost enough time trying to get things working, so I just blamed ftp. As for documentation - IBM does not document what doesn't work. It always reminds me of my IBM level2 days when I sat beside an IBM developer trying to figure out a problem. It turned out that the customer did something he should not have done, so the developer said "We don't document that you cannot wash dishes with a CPU!" Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://secure-web.cisco.com/1cgR4ORfnSdGTId41MIuPjdrGd0ZQ6ExpSwukTkezAowpK7uENjwAr1R_OqoPiGNdmWoGDPBDaOgXMlTdekO4mM7oT5OTo5I9bcRLsVDad5VAjwBniVz8bf6ESBhCVpYYpZ5gNcVwy6gUzu4l87VXgHWQPLw7oYrkGVJhWNXbk1CeTWu6AmDPNMAmqk87bzoz4uiHfkKUVuBiibDt5KPdyHJVtjsFlpqhsAm4BTznZK6Deq2pHP7ZCPMjWJFH-au5WBO-qLjBGMFLWpM7caoQipwjuu36wREfnOKAMeuKmYQqeyN9_lho9ckdTNl69uSjJ8qqa0kF23NvbZV27gbCWqGFyTC1AA-M-RSg9_zi1p6DqAg-kgmUYz_O79RNhZU5SZwBhw9PMr0MN7-hkEM8XbL1qjJ27G06gLERFlHBHxjmPXWSShFBiNuzn-Bmw92k/http%3A%2F%2Fwww.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: Zfs from 1 LPAR to another
Thanks Tom for quoting Bruce. May he rest in peace knowing that he was a giant among men in this industry! Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, November 7, 2019 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another On Thu, 7 Nov 2019 02:21:29 -0600, Barbara Nitz wrote: >"We don't document that you cannot wash dishes with a CPU!" That's a good one, Barbara! This discussion has come up before, and I thought I remembered someone saying that DFDSS will write blocks up to 64K bytes, so I looked and found the following post from Bruce Black. IMO, he is one of the more knowledgeable who has been here. Perhaps this explains some of the issues with using FTP to transport untersed DFDSS dumps. On Wed, 20 Jul 2005 12:41:01 -0400, Bruce Black wrote: >SDB does not work for RECFM=U, which can't be blocked by definition. >The application (DSS in this case) controls the actually blocksize. > >In any case, DSS writes blocks up to 64K (even though the DCB info says >32760). You can't copy a DSS backup (or an FDR backup) with IEBGENER, >the output will not be usable). > >-- >Bruce A. Black >Senior Software Developer for FDR -- Tom Marchant -- 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: Zfs from 1 LPAR to another
On Thu, 7 Nov 2019 02:21:29 -0600, Barbara Nitz wrote: >"We don't document that you cannot wash dishes with a CPU!" That's a good one, Barbara! This discussion has come up before, and I thought I remembered someone saying that DFDSS will write blocks up to 64K bytes, so I looked and found the following post from Bruce Black. IMO, he is one of the more knowledgeable who has been here. Perhaps this explains some of the issues with using FTP to transport untersed DFDSS dumps. On Wed, 20 Jul 2005 12:41:01 -0400, Bruce Black wrote: >SDB does not work for RECFM=U, which can't be blocked by definition. >The application (DSS in this case) controls the actually blocksize. > >In any case, DSS writes blocks up to 64K (even though the DCB info says >32760). You can't copy a DSS backup (or an FDR backup) with IEBGENER, >the output will not be usable). > >-- >Bruce A. Black >Senior Software Developer for FDR -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Ok, back with ftp then. It keeps thing a little simple. As Americans, they should know that they must document that you cannot dry your cat in the microwave. If ftp cannot handle the standard recfm=u format, it should be corrected or documented, not left to the customer to discover it (crashing a system or a migrationproject). Can anyone from IBM comment on this? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: 07 November 2019 09:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another >Did you transport the catalog dump dataset with ftp? Yes. I started out just adrdssu dumping the catalog, then ftp'ing. After restore and import the catalog was broken. Putting terse between the dump and ftp fixed the problem. >If yes, this might again point to ftp. >If not, the problem must be in the dump dataset. Then DFdss dump produces (can >produce) a non-standard recfm=u dataset, that will be processed correctly by >dfdss restore, but might confuse other programs reading it. This should be >documented with DFdss in my opinion. I believe that I later checked about the difference between the untersed dump and the tersed dump with regard to ftp. But I had already lost enough time trying to get things working, so I just blamed ftp. As for documentation - IBM does not document what doesn't work. It always reminds me of my IBM level2 days when I sat beside an IBM developer trying to figure out a problem. It turned out that the customer did something he should not have done, so the developer said "We don't document that you cannot wash dishes with a CPU!" Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
>Did you transport the catalog dump dataset with ftp? Yes. I started out just adrdssu dumping the catalog, then ftp'ing. After restore and import the catalog was broken. Putting terse between the dump and ftp fixed the problem. >If yes, this might again point to ftp. >If not, the problem must be in the dump dataset. Then DFdss dump produces (can >produce) a non-standard recfm=u dataset, that will be processed correctly by >dfdss restore, but might confuse other programs reading it. This should be >documented with DFdss in my opinion. I believe that I later checked about the difference between the untersed dump and the tersed dump with regard to ftp. But I had already lost enough time trying to get things working, so I just blamed ftp. As for documentation - IBM does not document what doesn't work. It always reminds me of my IBM level2 days when I sat beside an IBM developer trying to figure out a problem. It turned out that the customer did something he should not have done, so the developer said "We don't document that you cannot wash dishes with a CPU!" Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Barbara, Did you transport the catalog dump dataset with ftp? If yes, this might again point to ftp. If not, the problem must be in the dump dataset. Then DFdss dump produces (can produce) a non-standard recfm=u dataset, that will be processed correctly by dfdss restore, but might confuse other programs reading it. This should be documented with DFdss in my opinion. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: 07 November 2019 06:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another >For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that >needed it. Worked fine, until it didn't. IBM's response to the PMR that I >opened is that the only 100% reliable way to FTP a DFDSS dump file was to >terse it first. IBM does not support direct FTP of a DFDSS dump file. So I >now terse every DFDSS dump file before FTPing it to other systems, and I >haven't had another failure in 6 years. As I said, it will work until it >doesn't. And just to add my two cents: A few years back I tried to migrate a (user) catalog from one RDT lpar (where I had things customized) to another RDT lpar (at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS imported the catalog with RC=0, but the content was completely unusable. Trying to access any data set in that catalog on the DASD (that had also been migrated, but not via ftp) resulted in a plethora of strange rc/rsn combinations that really didn't make any sense. I eventually tersed the catalog dump and untersed/restored/imported on the other side. Now the data sets were accessible without any problems. I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I need to send it somewhere via ftp otherwise the results could get unpredictable. I don't think there's anything worse than a dataset that may or may not have been altered subtly. Don't take any chances, even if this is not clearly documented anywhere. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Tom, one reason for IODF Restore to build an unusable file is when it restores with multiple extents. IODF datasets must be single extent only. Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
>For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that >needed it. Worked fine, until it didn't. IBM's response to the PMR that I >opened is that the only 100% reliable way to FTP a DFDSS dump file was to >terse it first. IBM does not support direct FTP of a DFDSS dump file. So I >now terse every DFDSS dump file before FTPing it to other systems, and I >haven't had another failure in 6 years. As I said, it will work until it >doesn't. And just to add my two cents: A few years back I tried to migrate a (user) catalog from one RDT lpar (where I had things customized) to another RDT lpar (at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS imported the catalog with RC=0, but the content was completely unusable. Trying to access any data set in that catalog on the DASD (that had also been migrated, but not via ftp) resulted in a plethora of strange rc/rsn combinations that really didn't make any sense. I eventually tersed the catalog dump and untersed/restored/imported on the other side. Now the data sets were accessible without any problems. I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I need to send it somewhere via ftp otherwise the results could get unpredictable. I don't think there's anything worse than a dataset that may or may not have been altered subtly. Don't take any chances, even if this is not clearly documented anywhere. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
On 11/6/2019 10:02 AM, Vernooij, Kees - KLM , ITOP NM wrote: Can you point to where that is documented? We FTP a lot b.m.o. DFDSS between Sysplexes. Kees. Kees, I cannot find it documented anywhere. It's what IBM told me in response to a PMR. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
No, it has nothing to do with CKD, since it applies equally well to tape. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of John McKown Sent: Wednesday, November 6, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote: > So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has > such a special (internal) format, that FTP cannot always handle it > correctly, why can AMATERSE do this without problems? > A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on DASD, with no imbedded (in the data) of where the record ends. This is a artifact of the ECKD format that only the IBM z (as far as I know) uses. AMATERSE encodes the length of each physical block actually read into its data stream. And it produces FB output. So when you send it somewhere, the LRECL is always known. AMATERSE uses the encoded data in the FB to restore the data onto disk in the same PHYSICAL format that it was unloaded, making it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS format. > > If it FTP only, what is the special problem for FTP? What other dataset > formats are a problem for FTP? > Not FTP only. > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- 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: Zfs from 1 LPAR to another
I'd probably be inclined to use a TERSEd DFDSS dump, too - but that's just because I don't implicitly 'trust' (read: 'understand') UNIXy things. One such 'thing' I was shown was: tar -cf - ¦ ssh -l "cd ; tar -vxf -" Apparently this means something like: "create a tar ball of on stdout then pipe it through to stdin for input to an un-tar command, after logging on to logging on to and cd-ing to " It worked without a problem the only time I used it but, as I say, I was too darn scared of using it again. Too many possible ways of screwing up, as far as I was concerned. Sean On Wed, 6 Nov 2019 at 15:45, David Spiegel wrote: > Hi Itschak AMV"SH, > Why did you use IDTF format instead of TRS? > > Regards, > David > > On 2019-11-06 10:22, ITschak Mugzach wrote: > > Kees, > > > > Dfdss in general is not ftp freindly. When we faced that in a large data > > movement project, we used xmit to convert the file format to xmt on one > > side and rexyeive it on the other side. > > > > ITschak > > > > > > > > בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM < > > kees.verno...@klm.com>: > > > >> So do we. > >> > >> And I wonder what the actual problem is? If the DFDSS dump dataset has > >> such a special (internal) format, that FTP cannot always handle it > >> correctly, why can AMATERSE do this without problems? > >> > >> If it FTP only, what is the special problem for FTP? What other dataset > >> formats are a problem for FTP? > >> > >> Questions, Fear, Uncertainty and Doubt... > >> > >> Kees. > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of Lizette Koehler > >> Sent: 06 November 2019 16:11 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Zfs from 1 LPAR to another > >> > >> I have always FTP a DFDSS dump of "things" - What I was told to do long > >> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. > >> > >> This has never caused an issue (DFDSS ignores the Blksize). And my > >> Transfer have (knock wood) not failed. And I have always been able to > >> restore from the DFDSS dump. > >> > >> > >> Lizette > >> > >> > >>> -Original Message- > >>> From: IBM Mainframe Discussion List On > >>> Behalf Of Vernooij, Kees (ITOP NM) - KLM > >>> Sent: Wednesday, November 06, 2019 8:02 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Zfs from 1 LPAR to another > >>> > >>> Can you point to where that is documented? > >>> We FTP a lot b.m.o. DFDSS between Sysplexes. > >>> > >>> Kees. > >>> > >>> -Original Message- > >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > >>> On Behalf Of Tom Conley > >>> Sent: 06 November 2019 15:46 > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Zfs from 1 LPAR to another > >>> > >>> On 11/5/2019 6:54 PM, Jousma, David wrote: > >>>> Terse, dont terse, your call. I have 100% reliability as long as > >>>> the > >>> destination disk dataset for the ftp is newly created. If the > >>> destination dataset already exists, then yes, there have been problems. > >>>> As you mention there are some specific options on the transfer to > >>>> specify, > >>> and as long as you do, it will work fine. > >>>> Sending the dump file outside the company, probably not bad idea to > >>>> terse > >>> since we are all familiar with it. > >>>> > >>>> __ > >>>> ___ > >>>> > >>>> Dave Jousma > >>>> > >>>> AVP | Manager, Systems Engineering > >>>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > >>>> Rapids, MI 49546 > >>>> > >>>> 616.653.8429 | fax: 616.653.2717 > >>>> > >>>> From: Tom Conley > >>>> Sent: Tuesday, November 5, 2019 5:17 PM > >>>> To: IBM-MAIN@LISTSERV.UA.EDU > >>>> Subject: Re: Zfs from 1 LPAR to another > >>>> > >>>&g
Re: Zfs from 1 LPAR to another
Hi Itschak AMV"SH, Why did you use IDTF format instead of TRS? Regards, David On 2019-11-06 10:22, ITschak Mugzach wrote: > Kees, > > Dfdss in general is not ftp freindly. When we faced that in a large data > movement project, we used xmit to convert the file format to xmt on one > side and rexyeive it on the other side. > > ITschak > > > > בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM < > kees.verno...@klm.com>: > >> So do we. >> >> And I wonder what the actual problem is? If the DFDSS dump dataset has >> such a special (internal) format, that FTP cannot always handle it >> correctly, why can AMATERSE do this without problems? >> >> If it FTP only, what is the special problem for FTP? What other dataset >> formats are a problem for FTP? >> >> Questions, Fear, Uncertainty and Doubt... >> >> Kees. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Lizette Koehler >> Sent: 06 November 2019 16:11 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Zfs from 1 LPAR to another >> >> I have always FTP a DFDSS dump of "things" - What I was told to do long >> ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. >> >> This has never caused an issue (DFDSS ignores the Blksize). And my >> Transfer have (knock wood) not failed. And I have always been able to >> restore from the DFDSS dump. >> >> >> Lizette >> >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Vernooij, Kees (ITOP NM) - KLM >>> Sent: Wednesday, November 06, 2019 8:02 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Zfs from 1 LPAR to another >>> >>> Can you point to where that is documented? >>> We FTP a lot b.m.o. DFDSS between Sysplexes. >>> >>> Kees. >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>> On Behalf Of Tom Conley >>> Sent: 06 November 2019 15:46 >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Zfs from 1 LPAR to another >>> >>> On 11/5/2019 6:54 PM, Jousma, David wrote: >>>> Terse, dont terse, your call. I have 100% reliability as long as >>>> the >>> destination disk dataset for the ftp is newly created. If the >>> destination dataset already exists, then yes, there have been problems. >>>> As you mention there are some specific options on the transfer to >>>> specify, >>> and as long as you do, it will work fine. >>>> Sending the dump file outside the company, probably not bad idea to >>>> terse >>> since we are all familiar with it. >>>> >>>> __ >>>> ___ >>>> >>>> Dave Jousma >>>> >>>> AVP | Manager, Systems Engineering >>>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >>>> Rapids, MI 49546 >>>> >>>> 616.653.8429 | fax: 616.653.2717 >>>> >>>> From: Tom Conley >>>> Sent: Tuesday, November 5, 2019 5:17 PM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: Zfs from 1 LPAR to another >>>> >>>> >>>> **CAUTION EXTERNAL EMAIL** >>>> >>>> **DO NOT open attachments or click on links from unknown senders or >>>> unexpected emails** >>>> >>>> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: >>>>> I always terse the dump file too. Had issues with Restore if the >>>>> file wasn't tersed. >>>>> >>>>> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: >>>>> >>>>>> Dave, >>>>>>I'll do that. The files are not big. >>>>>>They can be sent as ZIP files. >>>>>> Thanks, Pierre >>>>>> >>>>>> -- >>>>>> -- >>>>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email to lists...@listserv.ua.edu with the message: INFO >>>>>> IBM-MAIN >>>>>> >>>>> -
Re: Zfs from 1 LPAR to another
Yes, but what is the problem with recfm=u? Treat it as defined/documented: physical blocks, with undefined internal logic. So don't try to find logic in it. Is this what FTP tries to do? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: 06 November 2019 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote: > So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has > such a special (internal) format, that FTP cannot always handle it > correctly, why can AMATERSE do this without problems? > A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on DASD, with no imbedded (in the data) of where the record ends. This is a artifact of the ECKD format that only the IBM z (as far as I know) uses. AMATERSE encodes the length of each physical block actually read into its data stream. And it produces FB output. So when you send it somewhere, the LRECL is always known. AMATERSE uses the encoded data in the FB to restore the data onto disk in the same PHYSICAL format that it was unloaded, making it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS format. > > If it FTP only, what is the special problem for FTP? What other > dataset formats are a problem for FTP? > Not FTP only. > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com> wrote: > So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has > such a special (internal) format, that FTP cannot always handle it > correctly, why can AMATERSE do this without problems? > A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on DASD, with no imbedded (in the data) of where the record ends. This is a artifact of the ECKD format that only the IBM z (as far as I know) uses. AMATERSE encodes the length of each physical block actually read into its data stream. And it produces FB output. So when you send it somewhere, the LRECL is always known. AMATERSE uses the encoded data in the FB to restore the data onto disk in the same PHYSICAL format that it was unloaded, making it usable once again by DFDSS. IMO, DFDSS should just have used VB or VBS format. > > If it FTP only, what is the special problem for FTP? What other dataset > formats are a problem for FTP? > Not FTP only. > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Kees, Dfdss in general is not ftp freindly. When we faced that in a large data movement project, we used xmit to convert the file format to xmt on one side and rexyeive it on the other side. ITschak בתאריך יום ד׳, 6 בנוב׳ 2019, 17:18, מאת Vernooij, Kees (ITOP NM) - KLM < kees.verno...@klm.com>: > So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has > such a special (internal) format, that FTP cannot always handle it > correctly, why can AMATERSE do this without problems? > > If it FTP only, what is the special problem for FTP? What other dataset > formats are a problem for FTP? > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 06 November 2019 16:11 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > I have always FTP a DFDSS dump of "things" - What I was told to do long > ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. > > This has never caused an issue (DFDSS ignores the Blksize). And my > Transfer have (knock wood) not failed. And I have always been able to > restore from the DFDSS dump. > > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Vernooij, Kees (ITOP NM) - KLM > > Sent: Wednesday, November 06, 2019 8:02 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Zfs from 1 LPAR to another > > > > Can you point to where that is documented? > > We FTP a lot b.m.o. DFDSS between Sysplexes. > > > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Tom Conley > > Sent: 06 November 2019 15:46 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Zfs from 1 LPAR to another > > > > On 11/5/2019 6:54 PM, Jousma, David wrote: > > > Terse, dont terse, your call. I have 100% reliability as long as > > > the > > destination disk dataset for the ftp is newly created. If the > > destination dataset already exists, then yes, there have been problems. > > > > > > As you mention there are some specific options on the transfer to > > > specify, > > and as long as you do, it will work fine. > > > > > > Sending the dump file outside the company, probably not bad idea to > > > terse > > since we are all familiar with it. > > > > > > > > > __ > > > ___ > > > > > > Dave Jousma > > > > > > AVP | Manager, Systems Engineering > > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > > Rapids, MI 49546 > > > > > > 616.653.8429 | fax: 616.653.2717 > > > > > > From: Tom Conley > > > Sent: Tuesday, November 5, 2019 5:17 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Zfs from 1 LPAR to another > > > > > > > > > **CAUTION EXTERNAL EMAIL** > > > > > > **DO NOT open attachments or click on links from unknown senders or > > > unexpected emails** > > > > > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > > >> I always terse the dump file too. Had issues with Restore if the > > >> file wasn't tersed. > > >> > > >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > > >> > > >>> Dave, > > >>> I'll do that. The files are not big. > > >>> They can be sent as ZIP files. > > >>> Thanks, Pierre > > >>> > > >>> -- > > >>> -- > > >>> -- 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 > > >> > > > > > > Wayne beat me to it. Terse any DFDSS file before sending. You may > > > get away with DF
Re: Zfs from 1 LPAR to another
Because TRS produces FB records, whereas, DFSMSdss produces RECFM=U records. On 2019-11-06 10:17, Vernooij, Kees (ITOP NM) - KLM wrote: > So do we. > > And I wonder what the actual problem is? If the DFDSS dump dataset has such a > special (internal) format, that FTP cannot always handle it correctly, why > can AMATERSE do this without problems? > > If it FTP only, what is the special problem for FTP? What other dataset > formats are a problem for FTP? > > Questions, Fear, Uncertainty and Doubt... > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: 06 November 2019 16:11 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > I have always FTP a DFDSS dump of "things" - What I was told to do long ago > and far away was to include BLKSIZE=32760 on the dump file in DFDSS. > > This has never caused an issue (DFDSS ignores the Blksize). And my Transfer > have (knock wood) not failed. And I have always been able to restore from > the DFDSS dump. > > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Vernooij, Kees (ITOP NM) - KLM >> Sent: Wednesday, November 06, 2019 8:02 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Zfs from 1 LPAR to another >> >> Can you point to where that is documented? >> We FTP a lot b.m.o. DFDSS between Sysplexes. >> >> Kees. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Tom Conley >> Sent: 06 November 2019 15:46 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Zfs from 1 LPAR to another >> >> On 11/5/2019 6:54 PM, Jousma, David wrote: >>> Terse, dont terse, your call. I have 100% reliability as long as >>> the >> destination disk dataset for the ftp is newly created. If the >> destination dataset already exists, then yes, there have been problems. >>> As you mention there are some specific options on the transfer to >>> specify, >> and as long as you do, it will work fine. >>> Sending the dump file outside the company, probably not bad idea to >>> terse >> since we are all familiar with it. >>> >>> __ >>> ___ >>> >>> Dave Jousma >>> >>> AVP | Manager, Systems Engineering >>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >>> Rapids, MI 49546 >>> >>> 616.653.8429 | fax: 616.653.2717 >>> >>> From: Tom Conley >>> Sent: Tuesday, November 5, 2019 5:17 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Zfs from 1 LPAR to another >>> >>> >>> **CAUTION EXTERNAL EMAIL** >>> >>> **DO NOT open attachments or click on links from unknown senders or >>> unexpected emails** >>> >>> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: >>>> I always terse the dump file too. Had issues with Restore if the >>>> file wasn't tersed. >>>> >>>> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: >>>> >>>>> Dave, >>>>>I'll do that. The files are not big. >>>>>They can be sent as ZIP files. >>>>> Thanks, Pierre >>>>> >>>>> -- >>>>> -- >>>>> -- 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 >>>> >>> Wayne beat me to it. Terse any DFDSS file before sending. You may >>> get away with DFDSS with mode block and EBCDIC. Until you don't. >>> Terse it for 100% reliability. >>> >>> Regards, >>> Tom Conley >>> >> Dave, >> >> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR >> that needed it. Worked fine, until it didn't. IBM's response to the >> PMR that I opened is that the
Re: Zfs from 1 LPAR to another
So do we. And I wonder what the actual problem is? If the DFDSS dump dataset has such a special (internal) format, that FTP cannot always handle it correctly, why can AMATERSE do this without problems? If it FTP only, what is the special problem for FTP? What other dataset formats are a problem for FTP? Questions, Fear, Uncertainty and Doubt... Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 06 November 2019 16:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another I have always FTP a DFDSS dump of "things" - What I was told to do long ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. This has never caused an issue (DFDSS ignores the Blksize). And my Transfer have (knock wood) not failed. And I have always been able to restore from the DFDSS dump. Lizette > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, November 06, 2019 8:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > Can you point to where that is documented? > We FTP a lot b.m.o. DFDSS between Sysplexes. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Conley > Sent: 06 November 2019 15:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > On 11/5/2019 6:54 PM, Jousma, David wrote: > > Terse, dont terse, your call. I have 100% reliability as long as > > the > destination disk dataset for the ftp is newly created. If the > destination dataset already exists, then yes, there have been problems. > > > > As you mention there are some specific options on the transfer to > > specify, > and as long as you do, it will work fine. > > > > Sending the dump file outside the company, probably not bad idea to > > terse > since we are all familiar with it. > > > > > > __ > > ___ > > > > Dave Jousma > > > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > Rapids, MI 49546 > > > > 616.653.8429 | fax: 616.653.2717 > > > > From: Tom Conley > > Sent: Tuesday, November 5, 2019 5:17 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Zfs from 1 LPAR to another > > > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > >> I always terse the dump file too. Had issues with Restore if the > >> file wasn't tersed. > >> > >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > >> > >>> Dave, > >>> I'll do that. The files are not big. > >>> They can be sent as ZIP files. > >>> Thanks, Pierre > >>> > >>> -- > >>> -- > >>> -- 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 > >> > > > > Wayne beat me to it. Terse any DFDSS file before sending. You may > > get away with DFDSS with mode block and EBCDIC. Until you don't. > > Terse it for 100% reliability. > > > > Regards, > > Tom Conley > > > > Dave, > > For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR > that needed it. Worked fine, until it didn't. IBM's response to the > PMR that I opened is that the only 100% reliable way to FTP a DFDSS > dump file was to terse it first. IBM does not support direct FTP of a > DFDSS dump file. So I now terse every DFDSS dump file before FTPing > it to other systems, and I haven't had another failure in 6 years. As > I said, it will work until it doesn't. > > Regards, > Tom Conley > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, se
Re: Zfs from 1 LPAR to another
I have always FTP a DFDSS dump of "things" - What I was told to do long ago and far away was to include BLKSIZE=32760 on the dump file in DFDSS. This has never caused an issue (DFDSS ignores the Blksize). And my Transfer have (knock wood) not failed. And I have always been able to restore from the DFDSS dump. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, November 06, 2019 8:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > Can you point to where that is documented? > We FTP a lot b.m.o. DFDSS between Sysplexes. > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Conley > Sent: 06 November 2019 15:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > On 11/5/2019 6:54 PM, Jousma, David wrote: > > Terse, dont terse, your call. I have 100% reliability as long as the > destination disk dataset for the ftp is newly created. If the destination > dataset already exists, then yes, there have been problems. > > > > As you mention there are some specific options on the transfer to specify, > and as long as you do, it will work fine. > > > > Sending the dump file outside the company, probably not bad idea to terse > since we are all familiar with it. > > > > __ > > ___ > > > > Dave Jousma > > > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > > Rapids, MI 49546 > > > > 616.653.8429 | fax: 616.653.2717 > > > > From: Tom Conley > > Sent: Tuesday, November 5, 2019 5:17 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Zfs from 1 LPAR to another > > > > > > **CAUTION EXTERNAL EMAIL** > > > > **DO NOT open attachments or click on links from unknown senders or > > unexpected emails** > > > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > >> I always terse the dump file too. Had issues with Restore if the file > >> wasn't tersed. > >> > >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > >> > >>> Dave, > >>> I'll do that. The files are not big. > >>> They can be sent as ZIP files. > >>> Thanks, Pierre > >>> > >>> > >>> -- 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 > >> > > > > Wayne beat me to it. Terse any DFDSS file before sending. You may > > get away with DFDSS with mode block and EBCDIC. Until you don't. > > Terse it for 100% reliability. > > > > Regards, > > Tom Conley > > > > Dave, > > For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that > needed it. Worked fine, until it didn't. IBM's response to the PMR that I > opened is that the only 100% reliable way to FTP a DFDSS dump file was to > terse it first. IBM does not support direct FTP of a DFDSS dump file. So I > now terse every DFDSS dump file before FTPing it to other systems, and I > haven't had another failure in 6 years. As I said, it will work until it > doesn't. > > Regards, > Tom Conley > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > thi
Re: Zfs from 1 LPAR to another
Can you point to where that is documented? We FTP a lot b.m.o. DFDSS between Sysplexes. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: 06 November 2019 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another On 11/5/2019 6:54 PM, Jousma, David wrote: > Terse, dont terse, your call. I have 100% reliability as long as the > destination disk dataset for the ftp is newly created. If the destination > dataset already exists, then yes, there have been problems. > > As you mention there are some specific options on the transfer to specify, > and as long as you do, it will work fine. > > Sending the dump file outside the company, probably not bad idea to terse > since we are all familiar with it. > > __ > ___ > > Dave Jousma > > AVP | Manager, Systems Engineering > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > > 616.653.8429 | fax: 616.653.2717 > > From: Tom Conley > Sent: Tuesday, November 5, 2019 5:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Zfs from 1 LPAR to another > > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: >> I always terse the dump file too. Had issues with Restore if the file >> wasn't tersed. >> >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: >> >>> Dave, >>> I'll do that. The files are not big. >>> They can be sent as ZIP files. >>> Thanks, Pierre >>> >>> >>> -- 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 >> > > Wayne beat me to it. Terse any DFDSS file before sending. You may > get away with DFDSS with mode block and EBCDIC. Until you don't. > Terse it for 100% reliability. > > Regards, > Tom Conley > Dave, For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that needed it. Worked fine, until it didn't. IBM's response to the PMR that I opened is that the only 100% reliable way to FTP a DFDSS dump file was to terse it first. IBM does not support direct FTP of a DFDSS dump file. So I now terse every DFDSS dump file before FTPing it to other systems, and I haven't had another failure in 6 years. As I said, it will work until it doesn't. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
On 11/5/2019 6:54 PM, Jousma, David wrote: Terse, dont terse, your call. I have 100% reliability as long as the destination disk dataset for the ftp is newly created. If the destination dataset already exists, then yes, there have been problems. As you mention there are some specific options on the transfer to specify, and as long as you do, it will work fine. Sending the dump file outside the company, probably not bad idea to terse since we are all familiar with it. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 From: Tom Conley Sent: Tuesday, November 5, 2019 5:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: I always terse the dump file too. Had issues with Restore if the file wasn't tersed. On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: Dave, I'll do that. The files are not big. They can be sent as ZIP files. Thanks, Pierre -- 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 Wayne beat me to it. Terse any DFDSS file before sending. You may get away with DFDSS with mode block and EBCDIC. Until you don't. Terse it for 100% reliability. Regards, Tom Conley Dave, For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that needed it. Worked fine, until it didn't. IBM's response to the PMR that I opened is that the only 100% reliable way to FTP a DFDSS dump file was to terse it first. IBM does not support direct FTP of a DFDSS dump file. So I now terse every DFDSS dump file before FTPing it to other systems, and I haven't had another failure in 6 years. As I said, it will work until it doesn't. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
Same program, different entry points. On Tue, Nov 5, 2019 at 5:03 PM David Spiegel wrote: > > Hi Skip, > It's AMATERSE (with //SYSUT1 and //SYSUT2) > or TRSMAIN (with //INFILE and //OUTFILE). > > Regards, > David > > On 2019-11-05 17:40, Jesse 1 Robinson wrote: > > Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE > > internally within the shop, but I can see how it might be useful. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of > > Tom Conley > > Sent: Tuesday, November 5, 2019 2:16 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Zfs from 1 LPAR to another > > > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > >> I always terse the dump file too. Had issues with Restore if the file > >> wasn't tersed. > >> > >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > >> > >>> Dave, > >>> I'll do that. The files are not big. > >>> They can be sent as ZIP files. > >>> Thanks, Pierre > >>> > >>> - > >>> - 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 > >> > > Wayne beat me to it. Terse any DFDSS file before sending. You may get > > away with DFDSS with mode block and EBCDIC. Until you don't. Terse it for > > 100% reliability. > > > > Regards, > > Tom Conley > > > > > > -- > > 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 -- 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: Zfs from 1 LPAR to another
Terse, dont terse, your call. I have 100% reliability as long as the destination disk dataset for the ftp is newly created. If the destination dataset already exists, then yes, there have been problems. As you mention there are some specific options on the transfer to specify, and as long as you do, it will work fine. Sending the dump file outside the company, probably not bad idea to terse since we are all familiar with it. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 From: Tom Conley Sent: Tuesday, November 5, 2019 5:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Zfs from 1 LPAR to another **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > I always terse the dump file too. Had issues with Restore if the file > wasn't tersed. > > On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > >> Dave, >> I'll do that. The files are not big. >> They can be sent as ZIP files. >> Thanks, Pierre >> >> -- >> 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 > Wayne beat me to it. Terse any DFDSS file before sending. You may get away with DFDSS with mode block and EBCDIC. Until you don't. Terse it for 100% reliability. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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: Zfs from 1 LPAR to another
Hi Skip, It's AMATERSE (with //SYSUT1 and //SYSUT2) or TRSMAIN (with //INFILE and //OUTFILE). Regards, David On 2019-11-05 17:40, Jesse 1 Robinson wrote: > Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE > internally within the shop, but I can see how it might be useful. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Tom Conley > Sent: Tuesday, November 5, 2019 2:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Zfs from 1 LPAR to another > > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: >> I always terse the dump file too. Had issues with Restore if the file >> wasn't tersed. >> >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: >> >>> Dave, >>> I'll do that. The files are not big. >>> They can be sent as ZIP files. >>> Thanks, Pierre >>> >>> - >>> - 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 >> > Wayne beat me to it. Terse any DFDSS file before sending. You may get away > with DFDSS with mode block and EBCDIC. Until you don't. Terse it for 100% > reliability. > > Regards, > Tom Conley > > > -- > 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: Zfs from 1 LPAR to another
Just to be clear: is that AMATERSE? I don't recall ever using IBM's TERSE internally within the shop, but I can see how it might be useful. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Conley Sent: Tuesday, November 5, 2019 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Zfs from 1 LPAR to another On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: > I always terse the dump file too. Had issues with Restore if the file > wasn't tersed. > > On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > >> Dave, >> I'll do that. The files are not big. >> They can be sent as ZIP files. >> Thanks, Pierre >> >> - >> - 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 > Wayne beat me to it. Terse any DFDSS file before sending. You may get away with DFDSS with mode block and EBCDIC. Until you don't. Terse it for 100% reliability. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
On 11/5/2019 3:11 PM, Wayne Bickerdike wrote: I always terse the dump file too. Had issues with Restore if the file wasn't tersed. On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: Dave, I'll do that. The files are not big. They can be sent as ZIP files. Thanks, Pierre -- 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 Wayne beat me to it. Terse any DFDSS file before sending. You may get away with DFDSS with mode block and EBCDIC. Until you don't. Terse it for 100% reliability. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
I always terse the dump file too. Had issues with Restore if the file wasn't tersed. On Wed, Nov 6, 2019, 03:53 Pierre Fichaud wrote: > Dave, > I'll do that. The files are not big. > They can be sent as ZIP files. > Thanks, Pierre > > -- > 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: Zfs from 1 LPAR to another
Dave, I'll do that. The files are not big. They can be sent as ZIP files. Thanks, Pierre -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
On Tue, Nov 5, 2019 at 12:00 PM Jousma, David < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > I transport ZFS's via FTP all the time. DFDSS dump and restore. > That sounds like a winner to me. My first thought was to use the UNIX "pax" utility. But ADRDSSU of the actual zFS LDS dataset sounds better. If the creator of the zFS actually made a separate zFS dataset for the output, with no extraneous files in it. > > > _ > Dave Jousma > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > 616.653.8429 | fax: 616.653.2717 > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Pierre Fichaud > Sent: Tuesday, November 5, 2019 12:58 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Zfs from 1 LPAR to another > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > A customer wants to send us a zFS file created by an IBM product. We > develop at Dallas and don't have the product installed. What should the > customer do to be able to send it to us ? I've looked through the archives > and didn't find what I needed. I can't remember if I saw this in IBM > manuals. > Thanks in advance, Pierre. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION > EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > 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 > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
You should be able to use anything that supports Unix files, including e-mail and various forms of FTP. What do you normally use for file transfer with that customer? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Pierre Fichaud Sent: Tuesday, November 5, 2019 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Zfs from 1 LPAR to another A customer wants to send us a zFS file created by an IBM product. We develop at Dallas and don't have the product installed. What should the customer do to be able to send it to us ? I've looked through the archives and didn't find what I needed. I can't remember if I saw this in IBM manuals. Thanks in advance, Pierre. -- 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: Zfs from 1 LPAR to another
df/DSS DUMP of the ZFS. Use the transportation method of your choice. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pierre Fichaud Sent: Tuesday, November 5, 2019 11:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Zfs from 1 LPAR to another A customer wants to send us a zFS file created by an IBM product. We develop at Dallas and don't have the product installed. What should the customer do to be able to send it to us ? I've looked through the archives and didn't find what I needed. I can't remember if I saw this in IBM manuals. Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Zfs from 1 LPAR to another
I transport ZFS's via FTP all the time. DFDSS dump and restore. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pierre Fichaud Sent: Tuesday, November 5, 2019 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Zfs from 1 LPAR to another **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** A customer wants to send us a zFS file created by an IBM product. We develop at Dallas and don't have the product installed. What should the customer do to be able to send it to us ? I've looked through the archives and didn't find what I needed. I can't remember if I saw this in IBM manuals. Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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
Zfs from 1 LPAR to another
A customer wants to send us a zFS file created by an IBM product. We develop at Dallas and don't have the product installed. What should the customer do to be able to send it to us ? I've looked through the archives and didn't find what I needed. I can't remember if I saw this in IBM manuals. Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
