Re: Old question
A file sent this way will appear without spool filename/filetype in RDRLIST. If you've got my FILELIST modifs from the VM download library, you can enter Rename in front of such files in RDRLIST and the spool filename/filetype will be set to the original CMS fn/ft (on condition NETDATA/DISK DUMP/PUNCH(HEADER was used). At the other hand: since CP recognizes dynamically added disks, it is easy to make your secondlevel guest LINK to the first level MDISK. And, if you install CPHOST from the VM download lib, a CLASS A user can do CP CP1 LINK somefirstlvluser 191 199 RR password? CP ATTACH 199 * 199 R/O ACC 199 Z 2009/12/18 Perry Ruiter prui...@ca.ibm.com Bob - here's the set up I use on my test system: SYSTEM CONFIG has this one line added: RDEVice 000C Type Reader and I use this EXEC to send files to it: /* * Send a file to my second level ViCom system */ address command arg fn ft fm . if fm = '' then fm = '*' 'STATE' fn ft fm if rc = 0 then do 'CP SPOOL PUNCH PRUITER2 CONT' 'PIPE literal ID PRUITER NAME' fn ft'| punch' 'NETDATA SEND' fn ft fm 'TO PRUITER AT PERRY (NOSPOOL' 'CP SPOOL PUNCH CLOSE NOCONT' end; else say 'File' fn ft fm 'not found' exit That exec ensures the file has a name in queries and the netdata headers are set up so receive, rdrlist, etc. work as expected. Adjust the userids, nodes as for your use (PRUITER2 is the first level userid running CP, PRUITER is the userid on the second level system to receive the file and PERRY is the second level system's node name). IPL CP with the reader empty, send a file, CP START 00C on your second level OPERATOR and the reader will continue to read files as they arrive for the life of the IPL ... Perry Perry Ruiter 250-658-6517 -- Kris Buelens, IBM Belgium, VM customer support
Re: postscript to pdf
I don't know direct (VM) solution, but you may use Linux machine with Ghostscript tools and ssh as the engine (if you have VM 5.4 with ssh). Please send me e-mail if you need more details of that concept. Regards Piotr Gentry, Stephen pisze: Does anyone know of a program/utility/whatever that will run on VM that will convert a postscript file to a pdf file? I know there is an html to pdf; that is not what I want. Ideally, it would be written in Rexx and/or assembler. I also have Cobol available and C+ on the mainframe. I’ve googled but haven’t come up with much. Thanks, Steve -- Piotr Kolasiński Mainframe Integration Group Team Leader Compfort Meridian Polska sp. z o.o. Al. Jerozolimskie 65/79 Warszawa tel. +48 42 6457306 mob. +48 607 216 329 ACM Professional Member IBM Certified Specialist - System z Technical Support V2 IBM Certified Specialist - Power Systems Technical Support for AIX and Linux
Re: News Item: via SlashDot and Computerworld -- IBM's newest mainframe is all Linux
No-such-thing-as-bad-publiciy-dep't ... Well, my brother's been enjoying a mini-boom of interest in his books ever since the photo of, Get a Grip on Physics (in the back of Tiger's car) was published on (among others) the WSJ website. grin Cheers Jeff
AUTO: Mac Holloway out of office (returning 01/04/2010)
I am out of the office until 01/04/2010. I will be on vacation from Friday, December 18 until Monday, January 4. I will only have sporadic access to email. For critical situations or emergencies you can contact me via my cell phone (919) 599-8766. Note: This is an automated response to your message Re: Old question sent on 12/18/09 0:43:50. This is the only notification you will receive while this person is away.
Re: Old question
Thanks to all, I wasn't losing my mind after all. It worked today though I think I did the same things as yesterday. Control cards were right, I had done the SET RDEV, maybe I mistyped the dev type. Anyway, all is well Thanks again. Bob Bates Enterprise Hosting Services w. (469)892-6660 c. (214) 907-5071 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: Old question
I didn't want to interrupt the thread discussion regarding the proper ID card format and procedures. That's good to have documented on the list. But now that Kris has suggested the excellent CPHOST, I'll offer another simple method disk-to-disk copy technique (usable by those not permitted to download tools): Define a minidisk on both systems, on the same DASD at the same extents for both systems. E.g. on *both* systems define in the directory: USER XFERONLY NOLOG MDISK 1000 3390 begcyl endcyl volser RR Normally, defining such overlapping MDISKs is a very bad practice with CMS filesystem mdisks. Overlapping MDISKS, Oh MY!! But in this case you are using it ONLY to transfer files between systems in a pretty manual and serial manner. So... 1) On the 1st level system you link and access the disk R/W, copy some files to it, the release and detach. 2) On the 2nd level system link and access the disk (R/O or R/W), copy the files from it, perhaps erasing them since you will probably need the disk space for file transfers again later. That simple process can be reversed to copy files from the 2nd level to 1st level systems. Now... what happens if you accidentally have the XFERONLY MDISK linked and accessed R/W on both systems, and ... copy files to it from both systems without following the above process? Well, you encounter the same problem that you've been warned about since you first came to z/VM... the CMS filesystem on that disk is trashed; what I call one-way encryption. But so what? Those files were only COPIES of files that you still have on the original 1st or 2nd level system! Just release and DETACH the XFERONLY disk from one of the systems, and from the remaining R/W system format the MDISK and copy the needed files to it again -- this time following the serial process listed above. Result? Either-way file transfer without ID cards, virtual punches and virtual readers, RSCS, or any other communications facilities. This method is especially useful early in the z/VM installation process, when you're trying to get your common tools to the 2nd level system (PROFILE EXEC, PROFILE XEDIT -- by whatever name, etc.). Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Kris Buelens kris.buel...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/18/2009 02:14 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Old question A file sent this way will appear without spool filename/filetype in RDRLIST. If you've got my FILELIST modifs from the VM download library, you can enter Rename in front of such files in RDRLIST and the spool filename/filetype will be set to the original CMS fn/ft (on condition NETDATA/DISK DUMP/PUNCH(HEADER was used). At the other hand: since CP recognizes dynamically added disks, it is easy to make your secondlevel guest LINK to the first level MDISK. And, if you install CPHOST from the VM download lib, a CLASS A user can do CP CP1 LINK somefirstlvluser 191 199 RR password? CP ATTACH 199 * 199 R/O ACC 199 Z 2009/12/18 Perry Ruiter prui...@ca.ibm.com Bob - here's the set up I use on my test system: SYSTEM CONFIG has this one line added: RDEVice 000C Type Reader and I use this EXEC to send files to it: /* * Send a file to my second level ViCom system */ address command arg fn ft fm . if fm = '' then fm = '*' 'STATE' fn ft fm if rc = 0 then do 'CP SPOOL PUNCH PRUITER2 CONT' 'PIPE literal ID PRUITER NAME' fn ft'| punch' 'NETDATA SEND' fn ft fm 'TO PRUITER AT PERRY (NOSPOOL' 'CP SPOOL PUNCH CLOSE NOCONT' end; else say 'File' fn ft fm 'not found' exit That exec ensures the file has a name in queries and the netdata headers are set up so receive, rdrlist, etc. work as expected. Adjust the userids, nodes as for your use (PRUITER2 is the first level userid running CP, PRUITER is the userid on the second level system to receive the file and PERRY is the second level system's node name). IPL CP with the reader empty, send a file, CP START 00C on your second level OPERATOR and the
New Twist Re: Old question
Mike, excellent idea - here is my approach to the same concept I define the 2nd level guests REAL address to the 1st level guest to move things to 2nd level and then link/access them that way of course the 2nd level guest is not UP during this process. * BBH 2nd Level Guest for NEW Version of z/VM 5.4.0 * USER BBHVM540 xx 64M 128M BG ACCOUNT 2 OPERATOR IPL CMS MACH ESA OPTION TODENABLE CONSOLE 0009 3215 T OPERATOR SPECIAL 0040 3270 SPECIAL 0050 3270 SPECIAL 0100 CTCA SPECIAL 0200 CTCA SPECIAL 0312 CTCA SPOOL 0003 PRINTER A SPOOL 000C READER A SPOOL 000D PUNCH A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 0709 5 V3W001 MR READ WRITE MULT * * Start of 2ndlevel definitions * * zVM 5.4.0 access to Maint's 191 Mdisk MDISK 2191 3390 0511 175 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's CF1 Mdisk MDISK 2CF1 3390 0039 120 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 193 Mdisk MDISK 2193 3390 0686 167 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 2CC Mdisk MDISK 22CC 3390 0506 005 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 500 Mdisk MDISK 2500 3390 2503 600 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 19F Mdisk MDISK 219F 3390 9045 100 540RES MR READ WRITE MULT * zVM 5.4.0 access to Autolog1's 191 Mdisk MDISK 3191 3390 3178 001 540RES MR READ WRITE MULT * zVM 5.4.0 access to Operator's 191 Mdisk MDISK 4191 3390 9300 100 540RES MR READ WRITE MULT * zVM 5.4.0 access to vmutil 's 191 Mdisk MDISK 5191 3390 9160 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to watcher 's 191 Mdisk MDISK 6191 3390 9175 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to diskacnt's 191 Mdisk MDISK 7191 3390 9145 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to erep's 191 Mdisk MDISK 8191 3390 9190 100 540RES MR READ WRITE MULT * * End of 2ndlevel definitions * Bill Munson Sr. z/VM Systems Programmer Brown Brothers Harriman CO. 525 Washington Blvd. Jersey City, NJ 07310 201-418-7588 President MVMUA http://www2.marist.edu/~mvmua/ http://www.linkedin.com/in/BillMunson Mike Walter mike.wal...@hewitt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/18/2009 10:34 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Old question I didn't want to interrupt the thread discussion regarding the proper ID card format and procedures. That's good to have documented on the list. But now that Kris has suggested the excellent CPHOST, I'll offer another simple method disk-to-disk copy technique (usable by those not permitted to download tools): Define a minidisk on both systems, on the same DASD at the same extents for both systems. E.g. on *both* systems define in the directory: USER XFERONLY NOLOG MDISK 1000 3390 begcyl endcyl volser RR Normally, defining such overlapping MDISKs is a very bad practice with CMS filesystem mdisks. Overlapping MDISKS, Oh MY!! But in this case you are using it ONLY to transfer files between systems in a pretty manual and serial manner. So... 1) On the 1st level system you link and access the disk R/W, copy some files to it, the release and detach. 2) On the 2nd level system link and access the disk (R/O or R/W), copy the files from it, perhaps erasing them since you will probably need the disk space for file transfers again later. That simple process can be reversed to copy files from the 2nd level to 1st level systems. Now... what happens if you accidentally have the XFERONLY MDISK linked and accessed R/W on both systems, and ... copy files to it from both systems without following the above process? Well, you encounter the same problem that you've been warned about since you first came to z/VM... the CMS filesystem on that disk is trashed; what I call one-way encryption. But so what? Those files were only COPIES of files that you still have on the original 1st or 2nd level system! Just release and DETACH the XFERONLY disk from one of the systems, and from the remaining R/W system format the MDISK and copy the needed files to it again -- this time following the serial process listed above. Result? Either-way file transfer without ID cards, virtual punches and virtual readers, RSCS, or any other communications facilities. This method is especially useful early in the z/VM installation process, when you're trying to get your common tools to the 2nd level system (PROFILE EXEC, PROFILE XEDIT -- by whatever name, etc.). Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Kris Buelens kris.buel...@gmail.com Sent by: The IBM
Re: New Twist Re: Old question
And yet another simple approach, if you have VSSI's VTAPE product, that is. Define the 1st-level system's output library to the 2nd level system as a R/O library and the 2nd level's output to the 1st level as R/O. To send data from the 1st-level to the 2nd, simply write the data to a VTAPE. Then mount that tape on the 2nd-level system. To send the other direction, simply reverse the process. You can do the same thing with only one library defined by defining virtual tape units on the 2nd level system and mounting the VTAPEs from the first level system on them. In this case, the tape devices on the 2nd-level system will appear as real tape drives. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bill Munson Sent: Friday, December 18, 2009 8:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: New Twist Re: Old question Mike, excellent idea - here is my approach to the same concept I define the 2nd level guests REAL address to the 1st level guest to move things to 2nd level and then link/access them that way of course the 2nd level guest is not UP during this process. * BBH 2nd Level Guest for NEW Version of z/VM 5.4.0 * USER BBHVM540 xx 64M 128M BG ACCOUNT 2 OPERATOR IPL CMS MACH ESA OPTION TODENABLE CONSOLE 0009 3215 T OPERATOR SPECIAL 0040 3270 SPECIAL 0050 3270 SPECIAL 0100 CTCA SPECIAL 0200 CTCA SPECIAL 0312 CTCA SPOOL 0003 PRINTER A SPOOL 000C READER A SPOOL 000D PUNCH A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR MDISK 0191 3390 0709 5 V3W001 MR READ WRITE MULT * * Start of 2ndlevel definitions * * zVM 5.4.0 access to Maint's 191 Mdisk MDISK 2191 3390 0511 175 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's CF1 Mdisk MDISK 2CF1 3390 0039 120 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 193 Mdisk MDISK 2193 3390 0686 167 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 2CC Mdisk MDISK 22CC 3390 0506 005 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 500 Mdisk MDISK 2500 3390 2503 600 540RES MR READ WRITE MULT * zVM 5.4.0 access to Maint's 19F Mdisk MDISK 219F 3390 9045 100 540RES MR READ WRITE MULT * zVM 5.4.0 access to Autolog1's 191 Mdisk MDISK 3191 3390 3178 001 540RES MR READ WRITE MULT * zVM 5.4.0 access to Operator's 191 Mdisk MDISK 4191 3390 9300 100 540RES MR READ WRITE MULT * zVM 5.4.0 access to vmutil 's 191 Mdisk MDISK 5191 3390 9160 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to watcher 's 191 Mdisk MDISK 6191 3390 9175 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to diskacnt's 191 Mdisk MDISK 7191 3390 9145 015 540RES MR READ WRITE MULT * zVM 5.4.0 access to erep's 191 Mdisk MDISK 8191 3390 9190 100 540RES MR READ WRITE MULT * * End of 2ndlevel definitions * Bill Munson Sr. z/VM Systems Programmer Brown Brothers Harriman CO. 525 Washington Blvd. Jersey City, NJ 07310 201-418-7588 President MVMUA http://www2.marist.edu/~mvmua/ http://www.linkedin.com/in/BillMunson Mike Walter mike.wal...@hewitt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 12/18/2009 10:34 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Old question I didn't want to interrupt the thread discussion regarding the proper ID card format and procedures. That's good to have documented on the list. But now that Kris has suggested the excellent CPHOST, I'll offer another simple method disk-to-disk copy technique (usable by those not permitted to download tools): Define a minidisk on both systems, on the same DASD at the same extents for both systems. E.g. on *both* systems define in the directory: USER XFERONLY NOLOG MDISK 1000 3390 begcyl endcyl volser RR Normally, defining such overlapping MDISKs is a very bad practice with CMS filesystem mdisks. Overlapping MDISKS, Oh MY!! But in this case you are using it ONLY to transfer files between systems in a pretty manual and serial manner. So... 1) On the 1st level system you link and access the disk R/W, copy some files to it, the release and detach. 2) On the 2nd level system link and access the disk (R/O or R/W), copy the files from it, perhaps erasing them since you will probably need the disk space for file transfers again later. That simple process can be reversed to copy files from the 2nd level to 1st level systems. Now... what happens if you accidentally have the XFERONLY MDISK linked and accessed R/W on both systems, and ... copy files to it
Re: postscript to pdf
We have a similar process now. We wanted to move it all to the mainframe or to Linux on the mainframe. Thanks for your reply. Steve From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Aria Bamdad Sent: Friday, December 18, 2009 12:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: postscript to pdf Others have mentioned various options on doing this. For the record, I had to setup something similar years ago to convert PS files to PDF. What I did was setup a PC with Adobe Acrobat and an FTP server. In Acrobat you can define a directory where a batch automated conversion will be performed for any file that is placed in the directory. The resulting output (PDF) will be placed in an output directory. Using this, I wrote an EXEC that would transfer the PS file from CMS to the PC, and then transfer back the resulting PDF. Worked flawlessly. It is not a pure CMS application however. Aria From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gentry, Stephen Sent: Thursday, December 17, 2009 1:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: postscript to pdf Does anyone know of a program/utility/whatever that will run on VM that will convert a postscript file to a pdf file? I know there is an html to pdf; that is not what I want. Ideally, it would be written in Rexx and/or assembler. I also have Cobol available and C+ on the mainframe. I've googled but haven't come up with much. Thanks, Steve
Re: postscript to pdf
On 12/18/2009 at 12:33 PM, Gentry, Stephen stephen.gen...@lafayettelife.com wrote: We have a similar process now. We wanted to move it all to the mainframe or to Linux on the mainframe. If Linux is an option, then definitely ghostscript will do the job very nicely. I use it a lot personally. For SLES, the ps2pdf command comes with the ghostscript-library package. A simple ps2pdf input.ps output.pdf is all that is normally needed. Mark Post
Re: Old question
I've been using this method ever since I migrated from VM/SP 3 to 4.
Works great! Only once did I screw up because I had both minidisks in
R/W mode and it was easy to recover by reformatting the minidisk.
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 46 years
mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153
Yes, Virginia, there is a Slippery Rock
--
On Fri, 18 Dec 2009 09:34:57 -0600 Mike Walter said:
{snip} I'll offer another
simple method disk-to-disk copy technique (usable by those not permitted
to download tools): Define a minidisk on both systems, on the same DASD at
the same extents for both systems.
Re: Old question
As I said I know there are multiple ways to do what I wanted. I actually use
several different ways of doing it depending on the situation.
I have a small 5.4 running 2nd level that I test apply maintenance on before
any 1st level install. It has a virtual CTC to 1st level RSCS and I send files
back and forth that way.
When I roll out new upgraded releases with a new res, I use the shared minidisk
(R/W on 1st level, R/O on 2nd) to move files up and swap if I need to go the
other way.
In this case I was going to have 6 different systems IPL'd under the same id
(obviously not at the same time). Felt the PUNCH was easiest.
Bob Bates
Enterprise Hosting Services
w. (469)892-6660
c. (214) 907-5071
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf
Of Fran Hensler
Sent: Friday, December 18, 2009 12:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Old question
I've been using this method ever since I migrated from VM/SP 3 to 4.
Works great! Only once did I screw up because I had both minidisks in R/W mode
and it was easy to recover by reformatting the minidisk.
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 46 years
mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153
Yes, Virginia, there is a Slippery Rock
--
On Fri, 18 Dec 2009 09:34:57 -0600 Mike Walter said:
{snip} I'll offer another
simple method disk-to-disk copy technique (usable by those not
permitted to download tools): Define a minidisk on both systems, on the
same DASD at the same extents for both systems.
Re: Old question
As I said I know there are multiple ways to do what I wanted.
Right. With z/VM and most other OS'es there are many ways to skin a cat -
if you're into that sort of thing. Chuckie may be into that, but lets not
go there.
Nonetheless, having the discussion on the list serves to enlighten z/VM
newbies with several additional ways to prepare the meal. Learning from
those who have trod the road of real experience often results in better
understanding than obtuse written doc. Of course, IBM's pubs are rarely
obtuse - but instead serves as example which most other vendor's should
emulate, including a certain two-letter ISV which shall remain nameless.
For those who have not discovered it yet, there is excellent WEB BROWSER
ACCESS to the IBMVM discussion list. It provides outstanding HISTORICAL
SEARCH CAPABILITY - so that when you have a question, you can search the
full history of the list (even before its name change to IBMVM) for
previous similar discussions of related (or ANY!) question. See:
http://listserv.uark.edu/archives/ibmvm.html
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
Bob Bates robert.ba...@wellsfargo.com
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
12/18/2009 01:39 PM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: Old question
As I said I know there are multiple ways to do what I wanted. I actually
use several different ways of doing it depending on the situation.
I have a small 5.4 running 2nd level that I test apply maintenance on
before any 1st level install. It has a virtual CTC to 1st level RSCS and I
send files back and forth that way.
When I roll out new upgraded releases with a new res, I use the shared
minidisk (R/W on 1st level, R/O on 2nd) to move files up and swap if I
need to go the other way.
In this case I was going to have 6 different systems IPL'd under the same
id (obviously not at the same time). Felt the PUNCH was easiest.
Bob Bates
Enterprise Hosting Services
w. (469)892-6660
c. (214) 907-5071
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message. Thank you for your cooperation.
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Fran Hensler
Sent: Friday, December 18, 2009 12:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Old question
I've been using this method ever since I migrated from VM/SP 3 to 4.
Works great! Only once did I screw up because I had both minidisks in R/W
mode and it was easy to recover by reformatting the minidisk.
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 46 years
mailto:f...@zvm.sru.edu http://zvm.sru.edu/~fjh +1.724.738.2153
Yes, Virginia, there is a Slippery Rock
--
On Fri, 18 Dec 2009 09:34:57 -0600 Mike Walter said:
{snip} I'll offer another
simple method disk-to-disk copy technique (usable by those not
permitted to download tools): Define a minidisk on both systems, on the
same DASD at the same extents for both systems.
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
Dougherty, Margaret is out of the office.
I will be out of the office starting 12/18/2009 and will not return until 12/28/2009. I will respond to your message when I return. *** IMPORTANT NOTE*-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
