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"
Sent by: "The IBM z/VM Operating System"
12/18/2009 01:39 PM
Please respond to
"The IBM z/VM Operating System"
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.
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
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: 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 > Sent by: The IBM z/VM Operating System > 12/18/2009 10:34 AM > Please respond to > The IBM z/VM Operating System > > > 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.
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 Sent by: The IBM z/VM Operating System 12/18/2009 10:34 AM Please respond to The IBM z/VM Operating System 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.
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" Sent by: "The IBM z/VM Operating System" 12/18/2009 02:14 AM Please respond to "The IBM z/VM Operating System" 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 CP ATTACH 199 * 199 R/O ACC 199 Z 2009/12/18 Perry Ruiter 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 seco
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
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 CP ATTACH 199 * 199 R/O ACC 199 Z 2009/12/18 Perry Ruiter > > 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: Old question
>Hi all, >I know there are other ways of doing this, but I can't let go of this now that I've thought about it. > >I have a simple 2nd level test system running. I want to send a file from 1st level to a user on the 2nd level system. I'm trying to use a process from the dark ages of VM/370. > >SPOOL D LEVEL2 >SPOOL D CONT >PUNCH PUNCH HEADER A ( NOH >PUNCH THIS FILE A ( NOH >SPOOL D NOCONT >CLOSE D > >On 2nd level do a START C and the file goes where it needs. The question comes about the contents of PUNCH HEADER file: > >USERID MYID >:READ THIS FILE > >Card one is wrong and I can't remember/find the correct format. HCPRSR431E says it should be ID MYID or USERID MYID but neither works. > >Ideas? > > >Bob Bates >Enterprise Hosting Services >w. (469)892-6660 >c. (214) 907-5071 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
Re: Old question
If the file went to userid MYID on the second level, then card one is
OK. Maybe it's format of the files? Try using DISK DUMP instead of
second PUNCH or try this:
/* send file(s) to the second level vm */
arg fn ft fm userid . '(' option
if userid = ''
then userid = 'MAINT'
'CP SP PU VM2 CLASS X CONT NOH NAME VM2 PUNCH'
'EXECIO 1 PUNCH (STRING ID' userid
if abbrev('FILELIST', option, 1)
then 'PIPE <' fn ft fm '| SPECS /DISK DUMP/ 1 W1-3 NW | CMS'
else 'DISK DUMP' fn ft fm
'CP SP PU CLOSE'
'CP SP PU OFF CLASS A NOCONT NON'
Ivica
On Fri, Dec 18, 2009 at 9:30 AM, Bob Bates wrote:
> Hi all,
> I know there are other ways of doing this, but I can't let go of
> this now that I've thought about it.
>
> I have a simple 2nd level test system running. I want to send a file
> from 1st level to a user on the 2nd level system. I'm trying to use a
> process from the dark ages of VM/370.
>
> SPOOL D LEVEL2
> SPOOL D CONT
> PUNCH PUNCH HEADER A ( NOH
> PUNCH THIS FILE A ( NOH
> SPOOL D NOCONT
> CLOSE D
>
> On 2nd level do a START C and the file goes where it needs. The
> question comes about the contents of PUNCH HEADER file:
>
> USERID MYID
> :READ THIS FILE
>
> Card one is wrong and I can't remember/find the correct format.
> HCPRSR431E says it should be ID MYID or USERID MYID but neither works.
>
> Ideas?
>
>
> 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
Bob, I recall doing this a long time ago too. Just tried it again, since my z/VM 5.4 system is sitting there in a second level guest, waiting for clients to test. The ID card format I used is ID MAINT and the file was punched to the reader for my second level guest. I had to fight with the 00C on the second level to get it to start though. Had to use: SET REDEVICE 00C TYPE READER VARY ON 00C CP START UR 00C To make it work, but it did.The file is in MAINT's RDR on the second level guest. But I did not put the :READ card in with the ID card. Just the one ID line. PUNCH will put the :READ at the top of the second file if you want it - leave off the (NOH On Thu, Dec 17, 2009 at 4:30 PM, Bob Bates wrote: > Hi all, > I know there are other ways of doing this, but I can't let go of > this now that I've thought about it. > > I have a simple 2nd level test system running. I want to send a file > from 1st level to a user on the 2nd level system. I'm trying to use a > process from the dark ages of VM/370. > > SPOOL D LEVEL2 > SPOOL D CONT > PUNCH PUNCH HEADER A ( NOH > PUNCH THIS FILE A ( NOH > SPOOL D NOCONT > CLOSE D > > On 2nd level do a START C and the file goes where it needs. The > question comes about the contents of PUNCH HEADER file: > > USERID MYID > :READ THIS FILE > > Card one is wrong and I can't remember/find the correct format. > HCPRSR431E says it should be ID MYID or USERID MYID but neither works. > > Ideas? > > > 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
That agrees with my memory. I tried it, and it just worked. I'm not clear what you mean with "the file goes where it needs." I guess that means it ends up in the reader of the intended userid? Then the real reader logic's working and your USERID card is okay. Are you using READCARD to receive it? It appears RECEIVE no longer looks inside a plain file for a :READ card and considers it to be an unnamed file, I believe once upon a time RECEIVE would invoke READCARD for such a file, but that seems no longer to be the case. READCARD still processes the :READ record correctly, however. -- Mike Harding z/VM System Support mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 457-9183 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System wrote on 12/17/2009 02:30:17 PM: > From: Bob Bates > To: IBMVM@LISTSERV.UARK.EDU > Date: 12/17/2009 02:30 PM > Subject: Old question > Sent by: The IBM z/VM Operating System > > Hi all, > I know there are other ways of doing this, but I can't let > go of this now that I've thought about it. > > I have a simple 2nd level test system running. I want to > send a file from 1st level to a user on the 2nd level system. I'm > trying to use a process from the dark ages of VM/370. > > SPOOL D LEVEL2 > SPOOL D CONT > PUNCH PUNCH HEADER A ( NOH > PUNCH THIS FILE A ( NOH > SPOOL D NOCONT > CLOSE D > > On 2nd level do a START C and the file goes where it needs. > The question comes about the contents of PUNCH HEADER file: > > USERID MYID > :READ THIS FILE > > Card one is wrong and I can't remember/find the correct > format. HCPRSR431E says it should be ID MYID or USERID MYID but > neither works. > > Ideas? > > > 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." > > > >
