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" <[email protected]>
Sent by: "The IBM z/VM Operating System" <[email protected]>
12/18/2009 02:14 AM
Please respond to
"The IBM z/VM Operating System" <[email protected]>
To
[email protected]
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 <[email protected]>
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.
