Re: Using DFDSS to copy non-extended format dataset to extended format?
My apologies for not responding earlier, but I wanted to try the AMS REPRO first. Unfortunately, I didn't have time for this until now. First, regarding. more detail in my original post. I can understand, and usually post all information I think might help. This time, I probably should have just asked if there is an option to convert from non-EF to EF format during a DSS RESTORE. I promise to try to do better next time ;-) I allocated a new zFS cluster making sure it is in extended format, then I ran an AMS REPRO (none of the zFSs was mounted). Next, I mounted both file systems and comapred the outcome of a ls -alER, as well as some randomly chosen files. This all compares equal, so I'm pretty sure the copy worked well. The AMS copy of the 4GiB data set ran for only 6 minutes. A COPYTREE done previously ran for some 45 minutes. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
No it's not faster. DFSMSdss calls repro under the covers for most VSAM data set copy operations, but buffering is limited to whatever was used when the data set was defined. I hope everyone uses a large BUFSP or BUFND value for REPRO (like 849920). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, June 17, 2014 6:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Using DFDSS to copy non-extended format dataset to extended format? Thanks. I understand. DFDSS is certainly a more efficient data copier than IDCAMS REPRO! On Tue, Jun 17, 2014 at 7:51 AM, Peter Hunkeler p...@gmx.ch wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. So, how about doing trying this: I was curious if it was feasible to perform the task using DFDSS. That's why I haven't YET tried AMS REPRO. Will consider this path next. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Using DFDSS to copy non-extended format dataset to extended format?
That is what I am talking about. However if you look at a typical programmer or production JCL you won't see that in it. Ed On Jun 18, 2014, at 3:49 PM, Ron Hawkins wrote: No it's not faster. DFSMSdss calls repro under the covers for most VSAM data set copy operations, but buffering is limited to whatever was used when the data set was defined. I hope everyone uses a large BUFSP or BUFND value for REPRO (like 849920). Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Tuesday, June 17, 2014 6:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Using DFDSS to copy non-extended format dataset to extended format? Thanks. I understand. DFDSS is certainly a more efficient data copier than IDCAMS REPRO! On Tue, Jun 17, 2014 at 7:51 AM, Peter Hunkeler p...@gmx.ch wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. So, how about doing trying this: I was curious if it was feasible to perform the task using DFDSS. That's why I haven't YET tried AMS REPRO. Will consider this path next. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
I can't answer your question. Especially since I don't know what various ways that you tried. But I did have a possible thought you might want to try. I assume the zFS container is not mounted at some UNIX mount point. So, how about doing trying this: 1) Rename zFS data set (CLUSTER DATA) to a new name. 2) Allocate a new zFS data set with the old name (CLUSTER DATA) name, but with the proper DATACLAS to be extended. This is really just a VSAM LINEAR data set. 3) REPRO from the old zFS data set to the new zFS data set. 4) try to mount the new zFS data set, which has the old name, at the proper UNIX mount point. 5) Profit! (sorry, weird \. - slashdot.org - reference). On Tue, Jun 17, 2014 at 6:35 AM, Peter Hunkeler p...@gmx.ch wrote: A large zFS data set was allocated w/o a dataclass. Now the data set is not extended format, so it cannot grow larger than 4GiB. I was looking into DFDSS COPYing or DUMP/RESTORE into a new extended format zFS data set. I tried various ways, but it seems DFDSS is not willing to copy or restore from non-extended format to extended format. Just to make sure I'm not missing an option that would allow this operation: Is there one? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Using DFDSS to copy non-extended format dataset to extended format?
W dniu 2014-06-17 13:35, Peter Hunkeler pisze: A large zFS data set was allocated w/o a dataclass. Now the data set is not extended format, so it cannot grow larger than 4GiB. I was looking into DFDSS COPYing or DUMP/RESTORE into a new extended format zFS data set. I tried various ways, but it seems DFDSS is not willing to copy or restore from non-extended format to extended format. Just to make sure I'm not missing an option that would allow this operation: Is there one? Did you try IDCAMS REPRO? -- 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 authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
On 06/17/14 07:35, Peter Hunkeler wrote: A large zFS data set was allocated w/o a dataclass. Now the data set is not extended format, so it cannot grow larger than 4GiB. I was looking into DFDSS COPYing or DUMP/RESTORE into a new extended format zFS data set. I tried various ways, but it seems DFDSS is not willing to copy or restore from non-extended format to extended format. Just to make sure I'm not missing an option that would allow this operation: Is there one? -- Peter Hunkeler -- Sorry, no there isn't. The data format under the covers is different. You're going to have to define a new extended format zFS mount it, then perform a file copy operation to get the data moved over. -- Mark Jacobs Time Customer Service Tampa, FL The standard you walk past is the standard you accept. Lt. Gen. David Morrison, Australian Army Chief -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Using DFDSS to copy non-extended format dataset to extended format?
I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. So, how about doing trying this: I was curious if it was feasible to perform the task using DFDSS. That's why I haven't YET tried AMS REPRO. Will consider this path next. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
Thanks. I understand. DFDSS is certainly a more efficient data copier than IDCAMS REPRO! On Tue, Jun 17, 2014 at 7:51 AM, Peter Hunkeler p...@gmx.ch wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. So, how about doing trying this: I was curious if it was feasible to perform the task using DFDSS. That's why I haven't YET tried AMS REPRO. Will consider this path next. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Using DFDSS to copy non-extended format dataset to extended format?
I just tried IDCAMS REPRO for exactly the same purpose. The job shows it worked, but a directory list of the new ZFS showed nothing in it. So I then used the following PAX command: /usr/sbin/mount -t ZFS -f PLEX.OLD.AGGR002.LDS0002 /service2 /usr/sbin/mount -t ZFS -f PLEX.NEW.AGGR002.LDS0002 /service3 cd /service2 pax -rwvCMX -p eW . /service3 This series of commands gave the desired result. Matthew On Tue, 17 Jun 2014 08:00:12 -0500, John McKown john.archie.mck...@gmail.com wrote: Thanks. I understand. DFDSS is certainly a more efficient data copier than IDCAMS REPRO! On Tue, Jun 17, 2014 at 7:51 AM, Peter Hunkeler p...@gmx.ch wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. So, how about doing trying this: I was curious if it was feasible to perform the task using DFDSS. That's why I haven't YET tried AMS REPRO. Will consider this path next. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
On Tue, 17 Jun 2014 14:51:42 +0200, Peter Hunkeler wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. Yeah, but when you post that you have tried various ways, without telling us what ways you tried, you reduce the chances that someone will be able to help you. If you had specified that you tried A, B, C and D and I believe that E will work, I would suggest that you try E. When you don't tell us what you tried, I am far less likely to post a guess. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
W dniu 2014-06-17 21:18, Tom Marchant pisze: On Tue, 17 Jun 2014 14:51:42 +0200, Peter Hunkeler wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. Yeah, but when you post that you have tried various ways, without telling us what ways you tried, you reduce the chances that someone will be able to help you. If you had specified that you tried A, B, C and D and I believe that E will work, I would suggest that you try E. When you don't tell us what you tried, I am far less likely to post a guess. Agreed (and itisn't an attack against the OP). Regarding original problem- I see two interesting issues: 1. What's magic inside zFS which makes the CI-level copy unusable? Extended format adds some suffix to physical blocks, but Control Intervals should remain unchanged by EF. 2. Why DFSMSdss didn't copied no-EF to EF LDS? IMHO it should be supported as IDCAMS REPRO is. Regards -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
I agree with your curiosity. I have never tried to clone a zFS using REPRO, but have copied other VSAM LINEAR data sets (SMS ACDS, SCDS) with no problems. But I didn't change them from non-EF to EF at the same time. Perhaps an EF LINEAR data sets is not identical to a non-EF LINEAR data set in some way. Or perhaps the UNIX formatting thereof is different. Hum, that sounds like a possibility. A non-EF zFS is _known_ to not be 4Gib, and so some internal structures might be unsigned 32 bit whereas in a EF zFS, they need to be 64 bit. Just a SWAG on my part. Perhaps Bill Schoen will put in a good, and definitive, word on this. On Tue, Jun 17, 2014 at 2:34 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-06-17 21:18, Tom Marchant pisze: On Tue, 17 Jun 2014 14:51:42 +0200, Peter Hunkeler wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. Yeah, but when you post that you have tried various ways, without telling us what ways you tried, you reduce the chances that someone will be able to help you. If you had specified that you tried A, B, C and D and I believe that E will work, I would suggest that you try E. When you don't tell us what you tried, I am far less likely to post a guess. Agreed (and itisn't an attack against the OP). Regarding original problem- I see two interesting issues: 1. What's magic inside zFS which makes the CI-level copy unusable? Extended format adds some suffix to physical blocks, but Control Intervals should remain unchanged by EF. 2. Why DFSMSdss didn't copied no-EF to EF LDS? IMHO it should be supported as IDCAMS REPRO is. Regards -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan 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: Using DFDSS to copy non-extended format dataset to extended format?
We routinely use DSS dump/restore to clone/migrate ZFS around the enterprise, but always to similar architecture. The only humongous (EF) ZFS I've created was for ServerPac work space, and I started with an empty volume. I agree with what's been said about radically different internals in EF. Dump/restore is probably out of the question. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/17/2014 01:28 PM Subject:Re: Using DFDSS to copy non-extended format dataset to extended format? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I agree with your curiosity. I have never tried to clone a zFS using REPRO, but have copied other VSAM LINEAR data sets (SMS ACDS, SCDS) with no problems. But I didn't change them from non-EF to EF at the same time. Perhaps an EF LINEAR data sets is not identical to a non-EF LINEAR data set in some way. Or perhaps the UNIX formatting thereof is different. Hum, that sounds like a possibility. A non-EF zFS is _known_ to not be 4Gib, and so some internal structures might be unsigned 32 bit whereas in a EF zFS, they need to be 64 bit. Just a SWAG on my part. Perhaps Bill Schoen will put in a good, and definitive, word on this. On Tue, Jun 17, 2014 at 2:34 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2014-06-17 21:18, Tom Marchant pisze: On Tue, 17 Jun 2014 14:51:42 +0200, Peter Hunkeler wrote: I can't answer your question. Especially since I don't know what various ways that you tried. My intent really only was to make sure I'm not missing a DFDSS option that would do this. I didn't find anything the like in the manual. That's why I didn't post details. Yeah, but when you post that you have tried various ways, without telling us what ways you tried, you reduce the chances that someone will be able to help you. If you had specified that you tried A, B, C and D and I believe that E will work, I would suggest that you try E. When you don't tell us what you tried, I am far less likely to post a guess. Agreed (and itisn't an attack against the OP). Regarding original problem- I see two interesting issues: 1. What's magic inside zFS which makes the CI-level copy unusable? Extended format adds some suffix to physical blocks, but Control Intervals should remain unchanged by EF. 2. Why DFSMSdss didn't copied no-EF to EF LDS? IMHO it should be supported as IDCAMS REPRO is. Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
On Jun 17, 2014, at 2:34 PM, R.S. wrote: ---SNIP-- Regarding original problem- I see two interesting issues: 1. What's magic inside zFS which makes the CI-level copy unusable? Extended format adds some suffix to physical blocks, but Control Intervals should remain unchanged by EF. My understanding is that DFDSS uses IDCAMS under the covers . I an guessing that passing parameters to IDCAMS that IBM specifies various parameters that help make IDCAMS (and other utilities) run faster. 2. Why DFSMSdss didn't copied no-EF to EF LDS? IMHO it should be supported as IDCAMS REPRO is. Regards -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e- mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
On Tue, 17 Jun 2014 13:49:06 -0700, Skip Robinson jo.skip.robin...@sce.com wrote: . The only humongous (EF) ZFS I've created was for ServerPac work space, and I started with an empty volume. My largest zFS is a single SMPNTS data set in one of my sysplexes shared by all the tech teams. It is 4 3390-9 volumes. It is also where I download electronic Severpac deliveries. I clean it up with CRON + Skulker and a shell script (I borrowed and modified) to delete empty directories: # Execute /SMPNTS1 cleanup every Friday at 05:45 # All files over 90 days old are deleted. # # 1) The first command is the skulker command to remove the old files # 2) The second command (rmemptydir) removes empty directores # from /SMPNTS1 at 05:50 am. This is needed because # skulker updates the last reference date of the directories # so it never gets rid of the empty ones. # 3) The third command does a touch to /SMPNTS1/@readme.txt to update the # reference date so skulker will not delete it in the future. # 45 05 * * 5 /etc/skulker -rl /usr/spool/cron/skulker.log /SMPNTS1 90 50 05 * * 5 /etc/rmemptydir /SMPNTS1 /usr/spool/cron/skulker.log 50 05 * * 5 touch /SMPNTS1/@readme.txt -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to copy non-extended format dataset to extended format?
W dniu 2014-06-17 22:49, Skip Robinson pisze: We routinely use DSS dump/restore to clone/migrate ZFS around the enterprise, but always to similar architecture. The only humongous (EF) ZFS I've created was for ServerPac work space, and I started with an empty volume. I agree with what's been said about radically different internals in EF. Dump/restore is probably out of the question. Well, the difference maybe is radically different, but it is very low-level. Regular application using records, keys, numbers and CI's (I mean all VSAM types) should not see any difference. The difference is inside 32-byte suffix appended to each physical block. The block itself is the same, it cannot be different, because it consist of CI's (actually CI consist of blocks), and the CI content is quite well documented. Up to every bit. So the application using CI or record content shouldn't see any difference. Even RBA (for EF, but non-EA) should remain unchanged. What I suspect: a) The copy wasn't performed properly. I can imagine what could be wrong, or rather what discrepancy was important. b) Internal zFS structure relies on RBA and The EF file was also EA, so RBA is different. Also note, the filesystem size depends on VSAM size at the moment of formatting. Maybe different changed size made zFS confusion. Disclaimer: the above are only ideas. -- 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 authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
