Re: DDR'ing 3390 DASD To Remote Location
¿SPXTAPE will support dump to disk in the future? Thanks 2008/8/20 Dave Jones [EMAIL PROTECTED] Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
This is huge! Thanks Jiri! If we were all on FBA, then copying disks would be as trivial as copying files because the disk would be must a big block-o-bytes. But since z/VM is still saddled with ye olde CKD tricks because of the indirect influence of z/OS, this new ability to *convert* a disk (image) to a block-o-bytes is ... well, it's HUGE. Awesome! -- R;
Re: Isolating one Linux guest in the DMZ
We do use a separate OSA for our DMZed linux servers. They are all on a vswitch and the firewall stuff does some IP address translation so that the address you see on the outside is not the same as the linux thinks it is. I would like to have a linux svm to act as a firewall between our outside vswitch and inside vswitch and hypersocket but arguing with the network/firewall/cybersecurity people isn't very productive. We let them do the security out in their hardware. /Tom Kern Fred Schmidt wrote: Hi fellow listers, Our z/VM environment currently sits behind a firewall. We would like to allow one Linux guest to act as an Internet server. We do not however want to expose the other Linux guests or the z/VM environment itself to the outside world. We are using VSWITCH. Is this possible? What options are there? Do we require a separate OSA for the Linux guest in the DMZ? As I'm not a comm's guy, please keep it simple. Thanks in advance. Regards, Fred Schmidt Department of Business and Employment Data Centre Services (DCS) Northern Territory Government, Australia
Re: DDR'ing 3390 DASD To Remote Location
CA's V/Seg does backup and restore DCSS/NSS/NLS/UCR files to disk and maintain the original Date/Time/OriginID information when/if the files are restored from the backup. Of course the restored file does inherit a new SpoolFileNumber ... and there is no automated remote capability. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, August 20, 2008 09:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I'm surprised that your posting about being able to backup/restore DCSS/NSS files to disk was not jumped on by a lot of people. I'd love to have that. Does it/can it restore the original creation DCSS/NSS date? The date problem and the fact that IBM's DCSSBKUP only works with DCSS's, not NSS's, is a big drawback. This is especially significant, given my new, remote, connection to Cornell. I'm semi-retired and working from my house in Plano, TX. I'd like to be able to minimize the calls to operations to mount a tape. If you want to contact me off-line, I'm [EMAIL PROTECTED] Jim Dave Jones wrote: Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
Re: Isolating one Linux guest in the DMZ
On Thursday, 08/21/2008 at 01:18 EDT, Fred Schmidt [EMAIL PROTECTED] wrote: Our z/VM environment currently sits behind a firewall. We would like to allow one Linux guest to act as an Internet server. We do not however want to expose the other Linux guests or the z/VM environment itself to the outside world. We are using VSWITCH. Is this possible? What options are there? Do we require a separate OSA for the Linux guest in the DMZ? Tell your comms guy that you don't need either a separate OSA (for a 2nd VSWITCH) or another VLAN on your existing VSWITCH (making it VLAN-aware on a trunk port). There are other security measures you may be required to take, but they aren't related to comms, so make sure your network security folks agree with your plan to put an Internet and intranet servers in the same z/VM LPAR. If they have issues then you can take security to the next level using mandatory access controls (RACF with SECLABELs). Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Please let us know where we can find it when you are ready. Sounds pretty good to me.. Another step towards a tapeless society. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Dave Jones Sent: Wednesday, August 20, 2008 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Isolating one Linux guest in the DMZ
ur z/VM environment currently sits behind a firewall. We would like to allow one Linux guest to act as an Internet server. We do not however want to expose the other Linux guests or the z/VM environment itself to the outside world. We are using VSWITCH. Good. That makes a few things possible. Is this possible? What options are there? Do we require a separate OSA for the Linux guest in the DMZ? Not necessarily. The easiest thing to do is to have your network guys engineer a new VLAN, and move the guest you want to expose onto that VLAN. That requires no physical hardware changes, and the networking guys can do all the routing that needs to happen outside the box. As long as there are no other network connections to the exposed guest, you can't get from there to any of the other guests. The assumption is that you're using VLAN-aware VSWITCHes, and that your networking guys understand how to make the magic connections to create and propagate a VLAN in your network. These days, that's a fairly safe bet. If you have spare money or excessively paranoid security weenies, you could get another OSA and dedicate it to that one guest. It's a waste of money, but technically valid. As I'm not a comm's guy, please keep it simple. Thanks in advance. You'll want to work closely with the network guys. Show them the 1st paragraph above, and they'll get it. -- db
Re: DDR'ing 3390 DASD To Remote Location
¿SPXTAPE will support dump to disk in the future? There's a requirement for supporting PIPE connections like the DDR mods that were just made available. Status is unknown at the moment other than IBM has seen it and seems to understand the desire for the function, but hasn't made any public statements of when or if they will do this. It would be nice, though, wouldn't it? (BTW, Jiri - the DDR work looks good for us. Beer is definitely on us next time.) -- db
Re: DDR'ing 3390 DASD To Remote Location
Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Gang, I've just sent it off to Fran to be included on his VM download web page. He'll post a note here when it's ready to go. There are two (somewhat cryptic) documentation files included. Huegel, Thomas wrote: Please let us know where we can find it when you are ready. Sounds pretty good to me.. Another step towards a tapeless society. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Dave Jones Sent: Wednesday, August 20, 2008 11:34 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DDR'ing 3390 DASD To Remote Location
And it does have that very important prereq - you must have V/Seg. Another option is VSSI's VTAPE. It is possible to use a VTAPE as the device for SPXTAPE . However, before you try it, make sure you have a current build of VTAPE. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Imler, Steven J Sent: Thursday, August 21, 2008 4:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location CA's V/Seg does backup and restore DCSS/NSS/NLS/UCR files to disk and maintain the original Date/Time/OriginID information when/if the files are restored from the backup. Of course the restored file does inherit a new SpoolFileNumber ... and there is no automated remote capability. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Wednesday, August 20, 2008 09:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location I'm surprised that your posting about being able to backup/restore DCSS/NSS files to disk was not jumped on by a lot of people. I'd love to have that. Does it/can it restore the original creation DCSS/NSS date? The date problem and the fact that IBM's DCSSBKUP only works with DCSS's, not NSS's, is a big drawback. This is especially significant, given my new, remote, connection to Cornell. I'm semi-retired and working from my house in Plano, TX. I'd like to be able to minimize the calls to operations to mount a tape. If you want to contact me off-line, I'm [EMAIL PROTECTED] Jim Dave Jones wrote: Hi, Jiri. This is way cool, many thanks for doing the work and sharing it. I think it's going to make life a bit easier for some folks. Some suggestions: 1) There seems to be an undocumented option in at least the FTPGET stage -- -DVDEOF. Of course, this might have meaning only in the case of doing a DVD transfer. 2) split the help text for the FTPGET and FTPPUT stages into separate help files. 3) convert the HELP file from simple text to the standard CMS HELPFILE format. If you'd like, I can help you with that. As far as SPXTAPE being upgraded to support files instead of being tape only, we've got a handy little utility here that will backup and restore all types of DCSS/NSS/UR/etc spool files to/from CMS files, with the only exceptions being DUMP and TRACE files. For UR spool files (RDR,PRT,PUN) it collects all such files from a given user into one CMS file, making moving and restoring them easier. It can also process individual rdr/prt/pun files from the collection as well. If there is any interest in such a thing, let me know, and I'll document it a bit better and put it up on one the the popular VM download web sites. Again, thanks a lot, Jiri. Jiri Stehlik wrote: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
Re: DDR'ing 3390 DASD To Remote Location
Dave Jones' SFB VMARC is now on my download page at http://zvm.sru.edu/~download or http://zvm.sru.edu/~download/SFB.VMARC As Dave says in his DOC: The normal distribution is for z/VM 5.1 5.2 and 5.3 I haven't been able to get it to work in z/VM 3.1 . Note that the download may be slow because this is the beginning of the semester and students are fiercely dropping and adding courses. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- On Thu, 21 Aug 2008 10:22:32 -0500 Dave Jones said: Gang, I've just sent it off to Fran to be included on his VM download web page. He'll post a note here when it's ready to go. There are two (somewhat cryptic) documentation files included.
z/VM 5.2 and the 2GB Line
I have been unable to come up with the magic search argument to get this list to spit out the answer to the question, What is the total GB of virtual storage, the sum of the VM sizes, can z/VM 5.2 handle without running into the dreaded 2GB line constraint?, so I will ask the list. What is it? Regards, Richard Schuh
HiperSockets Question
Hi Alan, I thought I sent this out last night but it does not look like it went so I am sending it again. If for some reason you did get this I apologize for sending it again. Not to belabor the subject I just want to make sure I understand. Here is what my issue was. I processed many SQL queries of DB2 tables via DB2 connect running on a z/OS LPAR down to a Linux server running on the same machine but a different z/VM LPAR without any issues. Until, we ran across some queries that were larger than all of the others. These queries failed (timed out). We saw in the DB2 connect trace that the size of the queries was about 2.3K. We knew it was a size issue because when we did a 'SELECT *' on the tables, basically reducing the size it worked. After a lot of effort we found that there was an extra route in the Linux routing table that sent the data bound for one of the z/OS LPARS over to our z/VM where it then was routed by the TCP/IP stack on z/VM to the z/OS LPAR over the HiperSockets LINK. This LINK happened to have a MTU size of 1500. When we removed the bogus route from the Linux routing table causing the SQL queries in question to travel over a HiperSockets LINK with a MTU size of 16348 they were successful. It appears that the difference in the MTU sizes was the problem. My question is does the MTU size mismatch cause the problem? I thought that even if the packets were fragmented they would still get over in full. Sorry for being so wordy but I thought I would present to try to help you help me and to also help others that may be just getting into this as I am. Thanks again for all of your help!! Terry Thank You, Terry Martin Lockheed Martin - Information Technology z/OS z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
Re: DDR'ing 3390 DASD To Remote Location
I now have running on z/VM 3.1 PIPEDDR, FTPPUT and FTPGET. Thanks Bruce, /Fran --- On Thu, 21 Aug 2008 11:10:27 -0400 Bruce Hayden said: Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Hello, In its current implementation DRPC requires z/Architecture and therefore it will not run under z/VM 3.1. I'll try to look at the code again, see if I can change this, but it will probably require a bit of work. -George z/VM I/O Development IBM Endicott The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/21/2008 01:26:35 PM: I now have running on z/VM 3.1 PIPEDDR, FTPPUT and FTPGET. Thanks Bruce, /Fran --- On Thu, 21 Aug 2008 11:10:27 -0400 Bruce Hayden said: Your PIPEDDR syntax would be: pipeddr dump * 195 (ftp -h xx.sru.edu -u xx -p xxx -f fran.ddr I forgot to put ftp examples in the help when I sent it. They are in there for the next update. A restore could be: pipeddr restore * 195 (ftp(-h xx.sru.edu -u xx -p xxx -f fran.ddr) noprompt The problem you had with ftpget is because you didn't specify the record format to write it out - either -fixed or -var xxx (see the DRPC HELP file for the file formats for variable.) On Thu, Aug 21, 2008 at 10:49 AM, Fran Hensler [EMAIL PROTECTED] wrote: Jiri and Bruce - What is the minimun level of VM required to run DRPC and PIPEDDR? I have been trying unsuccessfully to run both in z/VM 3.1. I have tried with both the CMS Pipelines and the Princeton Runtime Pipes. pipe ddr dump195 ddrin a | 195 dump c DMSABE141T Operation exception occurred at 00020416 in routine DDR CMS pipe session globalv | ftpput ... -f fran.junk works to a UNIX system but I can't FTPGET the file back: pipe ftpget -h xx.sru.edu -p -u xx -f fran.junk | x x a fran.junk INVALID INTERNAL MODE MODE FTPGET FAILED WITH RC=-109 Here's attempts to use PIPEDDR: PIPEDDR DUMP * 195 = = C (PACK Dumping disk FJH 0195 to FJH DISK0195 C Dump completed. pipeddr dump * 195 xx.sru.edu 21 -u xx -p xxx -f fran.ddr Dumping disk FJH 0195 to xx.SRU.EDU Connection not established with the remote side. Dump failed. I'm stuck on z/VM 3.1 because that's the only release IBM will license for a FLEX-ES system. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
DASD Frame s/n
Is there a way to display (query) the serial # of a DASD frame? Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905
Re: z/VM 5.2 and the 2GB Line
On Thu, 21 Aug 2008 09:57:22 -0700, Schuh, Richard [EMAIL PROTECTED] wrot e: I have been unable to come up with the magic search argument to get this list to spit out the answer to the question, What is the total GB of virtual storage, the sum of the VM sizes, can z/VM 5.2 handle without running into the dreaded 2GB line constraint?, so I will ask the list. What is it? Regards, Richard Schuh The answer is, of course, the trademarked it depends. There are severa l different forms of the constraint, and all are dependent on workload. Ev en something as apparently unrelated as how dense or sparse the guests' stor age reference patterns tend to be can greatly influence the degree to which t he constraint will be an issue for a given total virtual storage size. I'm not sure if we even have typical or average numbers, but I can ask around. - Bill Holder, z/VM Development, IBM
Where Do I Go From Here?
I need some advice and hopefully someone on this list serve has already tackled the problem I’m having. We run our IBM systems solely to suppor t the U.S. Air Force Jovial J73 compiler and its assorted toolset. The compiler was originally written to run on MVS but it was tweaked for us t o run on VM in 370 mode back in the mid 1980’s. Needless to say we are running unsupported software, in our case VM/ESA 2.3 so as a result we aren’t running any modern big IBM iron either. My organization is considering re-hosting Jovial on some sort of Windows platform but I’d like to keep this an IBM operation if at all possible. We also heavily use Uni x, Linux and Windows on other platforms. To offset some of the cost of a new system (z9 at a minimum) maybe it could do double or triple duty replacin g some of those other platforms. Of my options, which would be the most efficient? The latest zVM with a VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination? Or, heaven forbid, go with re-hosting to Windows? I’m not worried about putting myself out of a job. I’ve already retired once and am just doin g some contractor work at the place I retired from. ;-) Thanks in advance. Karl Severson IBM VM System Administrator Raytheon Company El Segundo, California
Tell vs. Msg ?
Is there any difference between TELL and MSG ? Is one preferred over the other? thx Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sir Arthur Conan Doyle NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. image/gif
Re: Where Do I Go From Here?
Have you tried CP SET 370ACCOM ON and SET CMS370AC ON while running in an ESA mode machine? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Karl Severson Sent: Thursday, August 21, 2008 2:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Where Do I Go From Here? I need some advice and hopefully someone on this list serve has already = tackled the problem I'm having. We run our IBM systems solely to suppor= t the U.S. Air Force Jovial J73 compiler and its assorted toolset. The compiler was originally written to run on MVS but it was tweaked for us t= o run on VM in 370 mode back in the mid 1980's. Needless to say we are = running unsupported software, in our case VM/ESA 2.3 so as a result we = aren't running any modern big IBM iron either. My organization is considering re-hosting Jovial on some sort of Windows platform but I'd = like to keep this an IBM operation if at all possible. We also heavily use Uni= x, Linux and Windows on other platforms. To offset some of the cost of a new= system (z9 at a minimum) maybe it could do double or triple duty replacin= g some of those other platforms. Of my options, which would be the most efficient? The latest zVM with a = VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination?= Or, heaven forbid, go with re-hosting to Windows? I'm not worried about= putting myself out of a job. I've already retired once and am just doin= g some contractor work at the place I retired from. ;-) Thanks in advance. Karl Severson IBM VM System Administrator Raytheon Company El Segundo, California
Re: Tell vs. Msg ?
For one thing, MSG is a CP command while TELL is CMS. Because it is CMS, TELL can use a NAMES file to determine the recipients. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Lionel B. Dyck Sent: Thursday, August 21, 2008 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Tell vs. Msg ? Is there any difference between TELL and MSG ? Is one preferred over the other? thx Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sir Arthur Conan Doyle NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: Tell vs. Msg ?
also by using a names file and RSCS tell can send messages to remote systems. Although it eventually uses the CP MESSAGE command anyway locally, tell support mixed case messages. David Kreuter From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Thu 8/21/2008 6:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Tell vs. Msg ? For one thing, MSG is a CP command while TELL is CMS. Because it is CMS, TELL can use a NAMES file to determine the recipients. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Lionel B. Dyck Sent: Thursday, August 21, 2008 2:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Tell vs. Msg ? Is there any difference between TELL and MSG ? Is one preferred over the other? thx Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sir Arthur Conan Doyle NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: Tell vs. Msg ?
CP MSG always delivers the message in upper case. An exception is using a pipe in an EXEC PIPE CP MSG user 'Hello World!' Tell is a CMS EXEC that uses CP MSG under the covers. It always delivers the message in the case in which it was invoked. So you can use CP MSG in machines that aren't running CMS like RSCS, GCS, VSE and I suppose z/OS. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- On Thu, 21 Aug 2008 14:11:36 -0700 Lionel B. Dyck said: Is there any difference between TELL and MSG ? Is one preferred over the other?
Re: Where Do I Go From Here?
If you could get the source code for the compiler, then you should update it to be z-exploitative. And then update it to run under linux on z hardware (LPAR or under z/VM). That will let you not just move to current supported hardware, but be able to move forward with IBM hardware. If you need to move to non-370 related hardware (x86, AMD, Sun) then rewrite it in C on a linux operating system. From there you can recompile, update for any of the other hardware platforms and even for Windows. /Tom Kern Karl Severson wrote: I need some advice and hopefully someone on this list serve has already tackled the problem I’m having. We run our IBM systems solely to support the U.S. Air Force Jovial J73 compiler and its assorted toolset. The compiler was originally written to run on MVS but it was tweaked for us to run on VM in 370 mode back in the mid 1980’s. Needless to say we are running unsupported software, in our case VM/ESA 2.3 so as a result we aren’t running any modern big IBM iron either. My organization is considering re-hosting Jovial on some sort of Windows platform but I’d like to keep this an IBM operation if at all possible. We also heavily use Unix, Linux and Windows on other platforms. To offset some of the cost of a new system (z9 at a minimum) maybe it could do double or triple duty replacing some of those other platforms. Of my options, which would be the most efficient? The latest zVM with a VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination? Or, heaven forbid, go with re-hosting to Windows? I’m not worried about putting myself out of a job. I’ve already retired once and am just doing some contractor work at the place I retired from. ;-) Thanks in advance. Karl Severson IBM VM System Administrator Raytheon Company El Segundo, California
Re: Where Do I Go From Here?
On 8/21/08 5:49 PM, Karl Severson [EMAIL PROTECTED] wrote: The compiler was originally written to run on MVS but it was tweaked for us t o run on VM in 370 mode back in the mid 1980¹s. If you truly still need 370 mode, you're going to be hard pressed to find a system that will still run true 370 mode. Most (if not all) the modern systems no longer have true 370 mode microcode. My organization is considering re-hosting Jovial on some sort of Windows platform Considering the amount of work on not just the applications but all the surrounding environment and data management, this would be a REALLY bad idea. You might be better off talking to HP about a VMS-based solution (they offered, and AFAIK, still offer a fairly decent Jovial compiler, and at least VMS understands labeled tapes and batch natively. It'd probably be less work to update the compiler you have for a modern CMS, or port it to Linux (either on Z or on some Intelish thing), and cost the Army less to run it as well. to keep this an IBM operation if at all possible. We also heavily use Unix, Linux and Windows on other platforms. To offset some of the cost of a new system (z9 at a minimum) maybe it could do double or triple duty replacing some of those other platforms. Good thought. A combination of Linux, CMS and OpenSolaris virtual machines would be a very compelling case. Of my options, which would be the most efficient? The latest zVM with a VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination? Or, heaven forbid, go with re-hosting to Windows? If you have source for the Jovial compiler and runtime, go to the latest z/VM and the latest CMS and ditch the VM/ESA system, or at least limit its use to a migration system. Z/OS is very unlikely to be cost-effective (and can't run VM/ESA as a guest anyway). Windows will be the most expensive option if you incorporate all the porting costs and the surrounding environment necessary to make this work. A Linux port would be very cost effective, especially if you can pick up some additional virtual workload in the process (and IFLs would make the new machine LOADS cheaper). Check out the OpenVMS solution as well. Since you're being systematic about it, the HP Integrity boxes are a lot of bang for the buck for VMS. -- db
Re: Where Do I Go From Here?
Jovial! Lord I miss working with that, and CMS-2Q too. :) Anyways, have you looked at the used market? You can pick up a used z800 o a z890 for a sweet deal these days, often well under $100K. z/ VM is available to license for those machines at a pretty good cost, and you can always negotiate a discount. Since you don't need to run z/OS, z9's are available with a couple IFL's for the sub $500K mark, with DASD. (You definitely have to negotiate that...) Or if you can run under MVS, look at hosting it on Hercules under Intel Linux. Very cheap! -Paul On Aug 21, 2008, at 4:49 PM, Karl Severson wrote: I need some advice and hopefully someone on this list serve has already = tackled the problem I’m having. We run our IBM systems solely to suppor= t the U.S. Air Force Jovial J73 compiler and its assorted toolset. The compiler was originally written to run on MVS but it was tweaked for us t= o run on VM in 370 mode back in the mid 1980’s. Needless to say we are = running unsupported software, in our case VM/ESA 2.3 so as a result we = aren’t running any modern big IBM iron either. My organization is considering re-hosting Jovial on some sort of Windows platform but I’d = like to keep this an IBM operation if at all possible. We also heavily use Uni= x, Linux and Windows on other platforms. To offset some of the cost of a new= system (z9 at a minimum) maybe it could do double or triple duty replacin= g some of those other platforms. Of my options, which would be the most efficient? The latest zVM with a = VM/ESA guest? The latest zOS with a VM/ESA guest? Some other combination?= Or, heaven forbid, go with re-hosting to Windows? I’m not worried about= putting myself out of a job. I’ve already retired once and am just doin= g some contractor work at the place I retired from. ;-) Thanks in advance. Karl Severson IBM VM System Administrator Raytheon Company El Segundo, California
Re: Where Do I Go From Here?
Richard:We have 370 mode in V2.3 so that's no problem. My concern is it's lack of availability in the more recent versions of zVM/CMS. That's why we would need to run a guest VM/ESA or maybe zVM 3.1 partition under the latest zVM so we could keep 370 mode. At least that's my understanding. Karl SeversonIBM VM Systems AdministratorRaytheon CompanyEl Segundo, California-The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote: -To: IBMVM@LISTSERV.UARK.EDUFrom: "Schuh, Richard" [EMAIL PROTECTED]Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDUDate: 08/21/2008 03:12PMSubject: Re: Where Do I Go >From Here?Have you tried CP SET 370ACCOM ON and SET CMS370AC ON while running inan ESA mode machine?Regards, Richard Schuh
Re: Tell vs. Msg ?
CP MSG is faster... TELL is an EXEC, and it always performs a lookup in userid NAMES In EXECs where I know where the message needs to go (to a single person), I never use TELL: address command 'IDENTIFY (LIFO parse pull myself . here . rscs . if targetnode=here | targetnode='' then 'CP MSG' targetuser 'This is a mixed case msg' else 'CP SMSG' rscs targetNode targetUser 'This is a mixed case msg' Not too long to code, and I'm sure the message goes to targetuser even if that name would be an entry in userid NAMES 2008/8/22 Fran Hensler [EMAIL PROTECTED] CP MSG always delivers the message in upper case. An exception is using a pipe in an EXEC PIPE CP MSG user 'Hello World!' Tell is a CMS EXEC that uses CP MSG under the covers. It always delivers the message in the case in which it was invoked. So you can use CP MSG in machines that aren't running CMS like RSCS, GCS, VSE and I suppose z/OS. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock -- On Thu, 21 Aug 2008 14:11:36 -0700 Lionel B. Dyck said: Is there any difference between TELL and MSG ? Is one preferred over the other? -- Kris Buelens, IBM Belgium, VM customer support
