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 xxxxxx 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 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 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 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. *************************** 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. ********************************************************************************
