Re: VTAM R.I.P.
On the z/OS side, yes. Not on the z/VM side. Perfkit is the z/VM tool and it feeds Omegamon XE which is already collecting from all our distributed boxes. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Melissa Curry Sent: Friday, April 04, 2008 3:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Does it include the cost of Omegamon on zOS? Melissa Curry Sales Representative Velocity Software, Inc. 196-D Castro Street Mountain View, CA 94041-1202 Office: (650) 964-8867 Cell: (415) 994-4579 fax: (650) 964-9012 [EMAIL PROTECTED] www.velocitysoftware.com - Original Message - From: "Said, Nick" <[EMAIL PROTECTED]> To: Sent: Thursday, April 03, 2008 2:45 PM Subject: Re: VTAM R.I.P. Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS $7,300 $1,980 z/Linux $447 $61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: > Rob van der Heij <[EMAIL PROTECTED]> wrote :- > > >>Z NET,QUICK > > > Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by > the middle of last year. We went back to using basic mode CTC connections > to z/OS until they got themselves up to 1.7 with the ability to use > TCPNJE. > > The interesting thing was that it was the huge cost of VTAM that was the > main motivation for us. Given that the product was functionally stabilised > and needed virtually zero support for a number of years we were struggling > to see why. > > Once we looked at VTAM, and eliminated it, this led us to look at a number > of other relatively high cost products that we have ways to eliminate, > replace or reduce. I am not saying that we would not have looked at these > anyway but the high cost of VTAM was the catalyst to start looking. > > > Colin Allinson > > Amadeus Data Processing GmbH > > This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose. This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
Re: DDR MVS Volumes
Great. That's the answer I was looking for. Mike - This email and any attachments contain information from Blackwell which may be confidential, privileged and/or protected by other legal rules. If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or use of the contents of this email is prohibited. If you have received the email in error, please notify us by reply email immediately and then delete the email and your reply from your email system. NOTE: Blackwell accepts no liability for the contents of this email.
Re: DDR MVS Volumes
Yes. On Fri, Apr 4, 2008 at 1:34 PM, Mike Spaniol <[EMAIL PROTECTED]> wrote: > Hello, > > I need to move all my data from a STK V960 controller to an IBM Shark. > Last weekend I moved all my VM volumes using DDR. This weekend I'd like > to start moving my MVS volumes. We have FDR from Innovation and I plan to > use it to move most of the MVS volumes once I can get them de-allocated on > MVS. But, I have several volumes, like the MVS sysres volume, the MVS > spool volumes, and some volumes with catalogs on them that I'll never get > de-allocated. So, what I think I'd like to do is shutdown my MVS virtual > machine. Then use DDR to copy the data to the Shark volumes. My question > is: will a DDR COPY ALL operation copy all the data from MVS formatted > volumes? Will they be exact copies of he target disk? > > Thanks for your help. > > > Mike Spaniol > Blackwell Book Services > (503) 684-1140 ext. 1397 > -- Mark Pace Mainline Information Systems
Re: DDR MVS Volumes
YES, I have used multiple DDR service machine to move MVS data from real 3380s to and EMC and then 3390s from the EMC to and HDS and then from HDS to a Sha rk. As long as you can have MVS down, DDR makes great image copies. /Tom Kern /301-903-2211 On Fri, 4 Apr 2008 10:34:38 PDT, Mike Spaniol <[EMAIL PROTECTED]> wr ote: >Hello, > >I need to move all my data from a STK V960 controller to an IBM Shark. >Last weekend I moved all my VM volumes using DDR. This weekend I'd like >to start moving my MVS volumes. We have FDR from Innovation and I plan to >use it to move most of the MVS volumes once I can get them de-allocated on >MVS. But, I have several volumes, like the MVS sysres volume, the MVS >spool volumes, and some volumes with catalogs on them that I'll never ge t >de-allocated. So, what I think I'd like to do is shutdown my MVS virtua l >machine. Then use DDR to copy the data to the Shark volumes. My questi on >is: will a DDR COPY ALL operation copy all the data from MVS formatted >volumes? Will they be exact copies of he target disk? > >Thanks for your help. > > >Mike Spaniol >Blackwell Book Services >(503) 684-1140 ext. 1397 > =
Re: VTAM R.I.P.
Does it include the cost of Omegamon on zOS? Melissa Curry Sales Representative Velocity Software, Inc. 196-D Castro Street Mountain View, CA 94041-1202 Office: (650) 964-8867 Cell: (415) 994-4579 fax: (650) 964-9012 [EMAIL PROTECTED] www.velocitysoftware.com - Original Message - From: "Said, Nick" <[EMAIL PROTECTED]> To: Sent: Thursday, April 03, 2008 2:45 PM Subject: Re: VTAM R.I.P. Our management came up with: Per MIP Cost Analysis Environment Onetime Ongoing z/OS $7,300 $1,980 z/Linux $447 $61 Of course, this does not include the cost of any Velocity Software products on z/VM :) -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Barton Robinson Sent: Thursday, April 03, 2008 12:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VTAM R.I.P. Gee, next it will be the high cost of z/OS that you will be looking at. How much do you save if you move an application from z/OS to z/Linux? Colin Allinson wrote: Rob van der Heij <[EMAIL PROTECTED]> wrote :- Z NET,QUICK Couldn't be 'QUICK' enough for us. We managed to eliminate it from VM by the middle of last year. We went back to using basic mode CTC connections to z/OS until they got themselves up to 1.7 with the ability to use TCPNJE. The interesting thing was that it was the huge cost of VTAM that was the main motivation for us. Given that the product was functionally stabilised and needed virtually zero support for a number of years we were struggling to see why. Once we looked at VTAM, and eliminated it, this led us to look at a number of other relatively high cost products that we have ways to eliminate, replace or reduce. I am not saying that we would not have looked at these anyway but the high cost of VTAM was the catalyst to start looking. Colin Allinson Amadeus Data Processing GmbH This email is intended for the recipient only. If you are not the intended recipient please disregard, and do not use the information for any purpose.
DDR MVS Volumes
Hello, I need to move all my data from a STK V960 controller to an IBM Shark. Last weekend I moved all my VM volumes using DDR. This weekend I'd like to start moving my MVS volumes. We have FDR from Innovation and I plan to use it to move most of the MVS volumes once I can get them de-allocated on MVS. But, I have several volumes, like the MVS sysres volume, the MVS spool volumes, and some volumes with catalogs on them that I'll never get de-allocated. So, what I think I'd like to do is shutdown my MVS virtual machine. Then use DDR to copy the data to the Shark volumes. My question is: will a DDR COPY ALL operation copy all the data from MVS formatted volumes? Will they be exact copies of he target disk? Thanks for your help. Mike Spaniol Blackwell Book Services (503) 684-1140 ext. 1397
Re: Question about virtual tape in a zVM environment
Les, As soon as the 3494 HW folks (once again) permitted the specification of TARGETCAT VOLSPECIFIC on a p2p MOUNT command, I had to revoke/reverse the fix that separated the single MOUNT request into a SET VOLCAT VOLSPECIFIC followed by a MOUNT for the volser. The SET VOLCAT VOLSPECIFIC had to be done first to ensure no one else could select the tape before the MOUNT completed ... to prevent "tape stealing". That ended up completely defeating "fast scratch" ... so VTS mounts were taking 3 to 5 minutes due to the back-end data being recalled because the tape was not in a Scratch Category when the MOUNT request was issued. That PTF was reversed in September 2003 ... JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) > Sent: Friday, April 04, 2008 01:55 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Question about virtual tape in a zVM environment > > A word of caution here, I realize it appears the problem is resolved > going from z/VM 4.4 and 5.3. However, I can not tell you any change > that has been made to Diag X'254' nor RMS that would have magically > allowed a target category of VOLSPECIFIC to be honored by the ATL on a > mount command. > I can tell you, hardware has identified situations where > VOLSPECIFIC is > not honored as a target category on a mount command. And I > am not aware > the fix has been released. > Make sure you consider this carefully before going into production. > > JR, didn't you make a change at one time where the set > category was done > separate from the mount? Could it be in one of the environments this > code was being executed? > > > Best Regards, > Les Geer > IBM z/VM and Linux Development > > >Hi Alain, > > > >Actually, in this case, I really don't really feel like going back in > >time :-) > > > >In reality, it would need to be a real crisis for me to get > >authorization to use a LPAR to IPL z/VM 4.4.0. > > > >I'm just happy for you that you should finally have this problem > >resolved when you are up and running z/VM 5.3 in production! > > > >JR > > > >JR (Steven) Imler > >CA > >Senior Software Engineer > >Tel: +1 703 708 3479 > >Fax: +1 703 708 3267 > >[EMAIL PROTECTED] > > > > > > > >> -Original Message- > >> From: The IBM z/VM Operating System > >> [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste > >> Sent: Friday, April 04, 2008 12:12 PM > >> To: IBMVM@LISTSERV.UARK.EDU > >> Subject: Re: Question about virtual tape in a zVM environment > >> > >> Jr, > >> > >> If you are interested in, I can send you a copy of our z/VM440. > >> > >> Regards > >> Alain > >> > >> > >> Le 4/04/08 3:26, =AB=A0Imler, Steven J=A0=BB > <[EMAIL PROTECTED]> a > >=E9crit=A0: > >> > >> > Hmmm ... Les, Alain did say z/VM FOUR.FOUR ... it's for > >> sure there are > >> > likely CP changes (DIAG 254 "things" come to mind) that > might effect > >> > this behavior in some way ... again keeping in mind his > >> HOST is running > >> > z/VM 4.4.0 (except for the test when everything WORKED! > [when he had > >> > z/VM 5.3 running 1st level in addition to his test guest > system]). > >> > > >> > In any case, I have no way to go back to prove this ... all > >> our hosts > >> > are z/VM 5.3 and we generally are running the GA release of > >> z/VM at GA > >> > for all our hosts. So it's been a LONG time since we've had z/VM > >> > 4.anything as "top dog". > >> > > >> > JR > >> > > >> > JR (Steven) Imler > >> > CA > >> > Senior Software Engineer > >> > Tel: +1 703 708 3479 > >> > Fax: +1 703 708 3267 > >> > [EMAIL PROTECTED] > >> > > >> > > >> >> -Original Message- > >> >> From: The IBM z/VM Operating System > >> >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer > >> (607-429-3580) > >> >> Sent: Thursday, April 03, 2008 08:42 PM > >> >> To: IBMVM@LISTSERV.UARK.EDU > >> >> Subject: Re: Question about virtual tape in a zVM environment > >> >> > >> >>> Les and JR, > >> >>> > >> >>> Firstly : > >> >>> Thanks to gave me the info 'PMH 84921,004,000'. I asked our > >> >> hardware to l > >> >>> > >> >>> ook > >> >>> at this. I don't have a feedback yet. > >> >>> > >> >>> Secondly : > >> >>> I was able to IPL our z/VM530 today and ... > >> >>> - from z/VM440, I ipled z/VM530 2nd lvl and did a test about > >> >> the target : > >> >>> > >> >>> > >> >>> nothing changed. Problem still alive :( > >> >>> > >> >>> - I ipled z/VM530 1st lvl and did a test, then did it again > >> >> and again to > >> >>> > >> >>> be > >> >>> absolutely sure. I washed my glasses and yes our problem > >> >> disappeared. NO > >> >>> MORE PROBLEM !!! > >> >>> > >> >>> So it was not a hardware problem. Glad to see this has been > >> >> corrected in > >> >>> > >> >>> the > >> >>> z/VM version. > >> >>> > >> >> > >> >> There isn't anything in a newer release of z/VM that would > >> change the > >> >>
Re: Question about virtual tape in a zVM environment
A word of caution here, I realize it appears the problem is resolved going from z/VM 4.4 and 5.3. However, I can not tell you any change that has been made to Diag X'254' nor RMS that would have magically allowed a target category of VOLSPECIFIC to be honored by the ATL on a mount command. I can tell you, hardware has identified situations where VOLSPECIFIC is not honored as a target category on a mount command. And I am not aware the fix has been released. Make sure you consider this carefully before going into production. JR, didn't you make a change at one time where the set category was done separate from the mount? Could it be in one of the environments this code was being executed? Best Regards, Les Geer IBM z/VM and Linux Development >Hi Alain, > >Actually, in this case, I really don't really feel like going back in >time :-) > >In reality, it would need to be a real crisis for me to get >authorization to use a LPAR to IPL z/VM 4.4.0. > >I'm just happy for you that you should finally have this problem >resolved when you are up and running z/VM 5.3 in production! > >JR > >JR (Steven) Imler >CA >Senior Software Engineer >Tel: +1 703 708 3479 >Fax: +1 703 708 3267 >[EMAIL PROTECTED] > > > >> -Original Message- >> From: The IBM z/VM Operating System >> [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste >> Sent: Friday, April 04, 2008 12:12 PM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: Question about virtual tape in a zVM environment >> >> Jr, >> >> If you are interested in, I can send you a copy of our z/VM440. >> >> Regards >> Alain >> >> >> Le 4/04/08 3:26, =AB=A0Imler, Steven J=A0=BB <[EMAIL PROTECTED]> a >=E9crit=A0: >> >> > Hmmm ... Les, Alain did say z/VM FOUR.FOUR ... it's for >> sure there are >> > likely CP changes (DIAG 254 "things" come to mind) that might effect >> > this behavior in some way ... again keeping in mind his >> HOST is running >> > z/VM 4.4.0 (except for the test when everything WORKED! [when he had >> > z/VM 5.3 running 1st level in addition to his test guest system]). >> > >> > In any case, I have no way to go back to prove this ... all >> our hosts >> > are z/VM 5.3 and we generally are running the GA release of >> z/VM at GA >> > for all our hosts. So it's been a LONG time since we've had z/VM >> > 4.anything as "top dog". >> > >> > JR >> > >> > JR (Steven) Imler >> > CA >> > Senior Software Engineer >> > Tel: +1 703 708 3479 >> > Fax: +1 703 708 3267 >> > [EMAIL PROTECTED] >> > >> > >> >> -Original Message- >> >> From: The IBM z/VM Operating System >> >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer >> (607-429-3580) >> >> Sent: Thursday, April 03, 2008 08:42 PM >> >> To: IBMVM@LISTSERV.UARK.EDU >> >> Subject: Re: Question about virtual tape in a zVM environment >> >> >> >>> Les and JR, >> >>> >> >>> Firstly : >> >>> Thanks to gave me the info 'PMH 84921,004,000'. I asked our >> >> hardware to l >> >>> >> >>> ook >> >>> at this. I don't have a feedback yet. >> >>> >> >>> Secondly : >> >>> I was able to IPL our z/VM530 today and ... >> >>> - from z/VM440, I ipled z/VM530 2nd lvl and did a test about >> >> the target : >> >>> >> >>> >> >>> nothing changed. Problem still alive :( >> >>> >> >>> - I ipled z/VM530 1st lvl and did a test, then did it again >> >> and again to >> >>> >> >>> be >> >>> absolutely sure. I washed my glasses and yes our problem >> >> disappeared. NO >> >>> MORE PROBLEM !!! >> >>> >> >>> So it was not a hardware problem. Glad to see this has been >> >> corrected in >> >>> >> >>> the >> >>> z/VM version. >> >>> >> >> >> >> There isn't anything in a newer release of z/VM that would >> change the >> >> behavior of this problem. It really is a hardware problem. >> >> This problem only occurs when you use VOLSPECIFIC as a target >> >> category on a mount request. >> >> >> >> >> >> Best Regards, >> >> Les Geer >> >> IBM z/VM and Linux Development >> >> >> >> >> > >> >>
Re: VTAM R.I.P.
Those are features that can be entered in the plus column :-) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes > Sent: Friday, April 04, 2008 9:48 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VTAM R.I.P. > > > I am not sure that you were defending VTAM. All of the interesting > > things that you did were done to overcome deficiencies. That seems > quite > > the opposite of a defense. > > Richard Schuh > > On the matter of defense of VTAM, one thing that VTAM (and > SNA networking in general) does do well is lend itself to > predictive modeling of network behavior. The lockstep model > used in SNA is very amenable to standard simulation > techniques, which make it very easy to determine the impact > of a change, or determine the capacity of the network in the > abstract. The "completely define the world" approach makes it > much easier to construct full topology graphs and diagnostics > tools. SNA also has much better engineered instrumentation > for measurement. > > TCP networks are self-similar, which complicates prediction > by a lot, and SNMP is a real hack. It's all we have at the > moment, but it lacks a lot for sampling and performance analysis. >
Re: VTAM R.I.P.
> I am not sure that you were defending VTAM. All of the interesting > things that you did were done to overcome deficiencies. That seems quite > the opposite of a defense. > Richard Schuh On the matter of defense of VTAM, one thing that VTAM (and SNA networking in general) does do well is lend itself to predictive modeling of network behavior. The lockstep model used in SNA is very amenable to standard simulation techniques, which make it very easy to determine the impact of a change, or determine the capacity of the network in the abstract. The "completely define the world" approach makes it much easier to construct full topology graphs and diagnostics tools. SNA also has much better engineered instrumentation for measurement. TCP networks are self-similar, which complicates prediction by a lot, and SNMP is a real hack. It's all we have at the moment, but it lacks a lot for sampling and performance analysis.
Re: Question about virtual tape in a zVM environment
Hi Alain, Actually, in this case, I really don't really feel like going back in time :-) In reality, it would need to be a real crisis for me to get authorization to use a LPAR to IPL z/VM 4.4.0. I'm just happy for you that you should finally have this problem resolved when you are up and running z/VM 5.3 in production! JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alain Benveniste > Sent: Friday, April 04, 2008 12:12 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Question about virtual tape in a zVM environment > > Jr, > > If you are interested in, I can send you a copy of our z/VM440. > > Regards > Alain > > > Le 4/04/08 3:26, « Imler, Steven J » <[EMAIL PROTECTED]> a écrit : > > > Hmmm ... Les, Alain did say z/VM FOUR.FOUR ... it's for > sure there are > > likely CP changes (DIAG 254 "things" come to mind) that might effect > > this behavior in some way ... again keeping in mind his > HOST is running > > z/VM 4.4.0 (except for the test when everything WORKED! [when he had > > z/VM 5.3 running 1st level in addition to his test guest system]). > > > > In any case, I have no way to go back to prove this ... all > our hosts > > are z/VM 5.3 and we generally are running the GA release of > z/VM at GA > > for all our hosts. So it's been a LONG time since we've had z/VM > > 4.anything as "top dog". > > > > JR > > > > JR (Steven) Imler > > CA > > Senior Software Engineer > > Tel: +1 703 708 3479 > > Fax: +1 703 708 3267 > > [EMAIL PROTECTED] > > > > > >> -Original Message- > >> From: The IBM z/VM Operating System > >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer > (607-429-3580) > >> Sent: Thursday, April 03, 2008 08:42 PM > >> To: IBMVM@LISTSERV.UARK.EDU > >> Subject: Re: Question about virtual tape in a zVM environment > >> > >>> Les and JR, > >>> > >>> Firstly : > >>> Thanks to gave me the info 'PMH 84921,004,000'. I asked our > >> hardware to l > >>> > >>> ook > >>> at this. I don't have a feedback yet. > >>> > >>> Secondly : > >>> I was able to IPL our z/VM530 today and ... > >>> - from z/VM440, I ipled z/VM530 2nd lvl and did a test about > >> the target : > >>> > >>> > >>> nothing changed. Problem still alive :( > >>> > >>> - I ipled z/VM530 1st lvl and did a test, then did it again > >> and again to > >>> > >>> be > >>> absolutely sure. I washed my glasses and yes our problem > >> disappeared. NO > >>> MORE PROBLEM !!! > >>> > >>> So it was not a hardware problem. Glad to see this has been > >> corrected in > >>> > >>> the > >>> z/VM version. > >>> > >> > >> There isn't anything in a newer release of z/VM that would > change the > >> behavior of this problem. It really is a hardware problem. > >> This problem only occurs when you use VOLSPECIFIC as a target > >> category on a mount request. > >> > >> > >> Best Regards, > >> Les Geer > >> IBM z/VM and Linux Development > >> > >> > > > >
Re: Question about virtual tape in a zVM environment
Jr, If you are interested in, I can send you a copy of our z/VM440. Regards Alain Le 4/04/08 3:26, « Imler, Steven J » <[EMAIL PROTECTED]> a écrit : > Hmmm ... Les, Alain did say z/VM FOUR.FOUR ... it's for sure there are > likely CP changes (DIAG 254 "things" come to mind) that might effect > this behavior in some way ... again keeping in mind his HOST is running > z/VM 4.4.0 (except for the test when everything WORKED! [when he had > z/VM 5.3 running 1st level in addition to his test guest system]). > > In any case, I have no way to go back to prove this ... all our hosts > are z/VM 5.3 and we generally are running the GA release of z/VM at GA > for all our hosts. So it's been a LONG time since we've had z/VM > 4.anything as "top dog". > > JR > > JR (Steven) Imler > CA > Senior Software Engineer > Tel: +1 703 708 3479 > Fax: +1 703 708 3267 > [EMAIL PROTECTED] > > >> -Original Message- >> From: The IBM z/VM Operating System >> [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) >> Sent: Thursday, April 03, 2008 08:42 PM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: Question about virtual tape in a zVM environment >> >>> Les and JR, >>> >>> Firstly : >>> Thanks to gave me the info 'PMH 84921,004,000'. I asked our >> hardware to l >>> >>> ook >>> at this. I don't have a feedback yet. >>> >>> Secondly : >>> I was able to IPL our z/VM530 today and ... >>> - from z/VM440, I ipled z/VM530 2nd lvl and did a test about >> the target : >>> >>> >>> nothing changed. Problem still alive :( >>> >>> - I ipled z/VM530 1st lvl and did a test, then did it again >> and again to >>> >>> be >>> absolutely sure. I washed my glasses and yes our problem >> disappeared. NO >>> MORE PROBLEM !!! >>> >>> So it was not a hardware problem. Glad to see this has been >> corrected in >>> >>> the >>> z/VM version. >>> >> >> There isn't anything in a newer release of z/VM that would change the >> behavior of this problem. It really is a hardware problem. >> This problem only occurs when you use VOLSPECIFIC as a target >> category on a mount request. >> >> >> Best Regards, >> Les Geer >> IBM z/VM and Linux Development >> >> >
Re: FTP from z/VM to z/OS JES Spool
It seems I can't do what I was hoping for so I've adjusted my code to ftp the file to z/OS and then ftp a batch job to do an IEBGENER. I was hoping to avoid the '2 step' but as that is all I can do right now that is what I'm going to do to move forward. Thanks to all who replied directly or via the listservs 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.
Re: FTP from z/VM to z/OS JES Spool
On Fri, Apr 4, 2008 at 4:56 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote: > > I am attempting to FTP a file from z/VM which I extracted from the z/VM > Spool (PRT) to the z/OS JES Spool. Here are my ftp statements from a code > snippet in my code: But isn't the internal reader by definition 80 byte card format? I suppose you have to make it a job and have a single IEBGENER step to copy the inline data to a longer format. CMS Pipelines comes handy to block the data in some format the MVS likes. In most installations this means you do need a valid userid and password to run the job. Rob -- Rob van der Heij Velocity Software GmbH http://velocitysoftware.com/
FTP from z/VM to z/OS JES Spool
I am attempting to FTP a file from z/VM which I extracted from the z/VM Spool (PRT) to the z/OS JES Spool. Here are my ftp statements from a code snippet in my code: queue id queue "quote site filetype=jes" queue "mode b" queue "type e" queue "quote site lrecl=254" queue "put" temp_file queue "dir" queue "quit" "ftp" host "(exit" My problem is that the "quote site lrecl=254" is being overridden by the put of the file which is setting it to an LRECL=80 thus: >>>site filetype=jes 200 SITE command was accepted Command: >>>MODE b 200 Data transfer mode is Block Command: >>>TYPE e 200 Representation type is Ebcdic NonPrint Command: >>>site lrecl=254 200 SITE command was accepted Command: >>>SITE VARrecfm 200 SITE command was accepted >>>PORT 172,21,246,100,8,186 200 Port request OK. >>>STOR temp.file 125 Sending Job to JES internal reader FIXrecfm 80< 250-It is known to JES as JOB10347 250 Transfer completed (data was truncated) < Does anyone have any suggestions on how to overcome this? 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. <>
Re: VTAM R.I.P.
It is the same with any VTAM. MVS, VSE, or VM VTAM jumps through the same hoops when establishing a SNA connection. Dave Jones wrote: I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Neale Ferguson wrote: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: VTAM R.I.P.
> I haven't heard that one before, Neale (maybe because I never worked in > a VM-VTAM environment, lucky me), but it is laugh out loud funny. Right up there with Ole and Lena. 8-) Worse yet, it's a general SNA issue, not just VM. APPN session setup is even weirder...
Re: VTAM R.I.P.
Actually, the version I saw years ago had many more questions and responses, but the gist of the VTAM binding process is here. :-) -- Robert P. Nix Mayo Foundation.~. RO-OE-5-55 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 4/4/08 7:44 AM, "Dave Jones" <[EMAIL PROTECTED]> wrote: > I haven't heard that one before, Neale (maybe because I never worked in > a VM-VTAM environment, lucky me), but it is laugh out loud funny. > > > Neale Ferguson wrote: > >> >> John Akers answers the phone: Hello >> >> Caller: John Akers? >> >> JA: Yes. >> >> Caller: John Akers of IBM? >> >> JA: Yes. >> >> Caller: John Akers of IBM, White Plains? >> >> JA: Yes! >> >> Caller: John Akers of IBM, White Plains, NY, USA? >> >> JA: Yes, WTF do you want!!! >> >> Caller: Just wanted to let you know how it feels to set up an SNA session.
Re: VTAM R.I.P.
I haven't heard that one before, Neale (maybe because I never worked in a VM-VTAM environment, lucky me), but it is laugh out loud funny. Neale Ferguson wrote: John Akers answers the phone: Hello Caller: John Akers? JA: Yes. Caller: John Akers of IBM? JA: Yes. Caller: John Akers of IBM, White Plains? JA: Yes! Caller: John Akers of IBM, White Plains, NY, USA? JA: Yes, WTF do you want!!! Caller: Just wanted to let you know how it feels to set up an SNA session. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
