Thanks everyone...gather from Router group I can not use the JUMBO size.. Network not setup to handle this ++ $$$
From: "Shumate, Scott" <scshum...@bbandt.com> To: IBM-MAIN@bama.ua.edu Date: 04/14/2010 09:53 AM Subject: Re: Fw: LINUX on the MAINFRAME Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> That is a true statement. -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, April 14, 2010 10:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Fw: LINUX on the MAINFRAME Be careful changing the MTU size. Most routers can handle the 1500, but larger MTUs may be fragmented into small chunks. I believe there was a discussion on this list about MTU size and if I remember correctly someone said(it may have been Chris Mason) that if the router isn't configured correctly that it would reject the larger MTU size packet. You might want to search the archives before you change MTU size. -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Wells Sent: Wednesday, April 14, 2010 8:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Fw: LINUX on the MAINFRAME so>> on the LINK statement--VM/TCPIP config... I can change the MTU to 8992 or does it need to be 9000 ? seeing only the reference of 8992 but want to be sure.... From: Mark Pace <mpac...@gmail.com> To: IBM-MAIN@bama.ua.edu Date: 04/14/2010 08:27 AM Subject: Re: Fw: LINUX on the MAINFRAME Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Yes - you can change the MTU size, make the 1500 what ever size you need. >From the z/VM TCPIP configuration. MTU *mtusize* Specifies the maximum transmission unit (MTU) size in bytes to be used on the interface. To determine the recommended MTU size, refer to the hardware documentation associated with the device. On Wed, Apr 14, 2010 at 9:08 AM, Ron Wells <rwe...@agfinance.com> wrote: > Mark > So the MTU size can not be greater than 1500 ?? > even when running OSA-Gig ?? > > > > From: > Mark Pace <mpac...@gmail.com> > To: > IBM-MAIN@bama.ua.edu > Date: > 04/14/2010 07:03 AM > Subject: > Re: Fw: LINUX on the MAINFRAME > Sent by: > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > > > An equivalent for z/VM TPCPIP > > DEVICE d...@0620 OSD 0620 NONROUTER > LINK OSA1 QDIOETHERNET d...@0620 MTU 1500 ETHERNET <---- For a Layer 2 > transport > or > LINK OSA1 QDIOETHERNET d...@0620 MTU 1500 IP <---- For a Layer 3 > transport > > On VM we do not have VTAM involvement so there is no TRLE. > > On Tue, Apr 13, 2010 at 4:51 PM, Ron Wells <rwe...@agfinance.com> wrote: > > > more looking...in z/OS tcpip parms.. I use following to setup Gig OSA... > > SO >>anyone << what is the equivalent in VM tcpip or Vswitch ?? > > > > DEVICE DEVF800 MPCIPA PRIROUTER AUTORESTART > > LINK LINKF800 IPAQGNET DEVF800 > > > > > > > > > > > > > > > > ----- Forwarded by Ron Wells/AGFS/AGFin on 04/13/2010 03:49 PM ----- > > > > From: > > Ron Wells/AGFS/AGFin > > To: > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > Date: > > 04/13/2010 03:43 PM > > Subject: > > Fw: LINUX on the MAINFRAME > > > > > > just found out Linux>> per Linux guy>> 1492 is the mtu size he sees from > > his image?? > > is there not a specification on Linux or ?? where you specify it as a > Gig > > Ethr ? > > > > ----- Forwarded by Ron Wells/AGFS/AGFin on 04/13/2010 03:39 PM ----- > > > > From: > > Ron Wells/AGFS/AGFin > > To: > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > Date: > > 04/13/2010 03:15 PM > > Subject: > > Re: LINUX on the MAINFRAME > > > > > > does anyone have any base numbers they could share... > > (example) > > We are shaking down z/VM 5.4-rsu0901-own lpar-4gig central/1.5 > > expanded..(1) IFL > > All following Linux images are at SP3/(1) webshhere7(server pack unknow) > / > > (1)DB2Connect Linux and couple others as test/devl images ...2gig for > each > > image > > > > Vswitch set for (1)OSA-E Gig .. > > > > Hypersockets used between the Linux images/VM and z/OS(running in > seperate > > lpar ). > > > > The outbound traffic-OSAGig connect to a AS400(s) test at this point DB2 > > servers.. > > > > Was thinking something in Linux definition that could slow things down>> > > like it's definition for OSAgig.? > > > > > > > > > > From: > > Anne & Lynn Wheeler <l...@garlic.com> > > To: > > IBM-MAIN@bama.ua.edu > > Date: > > 04/13/2010 02:40 PM > > Subject: > > Re: LINUX on the MAINFRAME > > Sent by: > > IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> > > > > > > > > mpac...@gmail.com (Mark Pace) writes: > > > That is a very good point, John. Memory management on Linux for the > > > mainframe is counter-intuitive. When running under zVM you want as > > little > > > memory as you can get away with, not as much as you can get. Most any > > > question you can think of has probably been covered ad-nausea on the > > > Linux-390 list. > > > > this was discovered in the early 70s when apl\360 was ported to cp67/cms > > for cms\apl. The apl\360 storage management and garbage collection > > algorithm allocation a new storage location on every assignment. It very > > quickly cycled thru all available workspace ... until it had exhausted > > storage and then did garbage collection ... and then repeated. This > > wasn't too bad with 16kbyte-32kbyte real storage workspaces that were > > swapped in total every time ... but became disastrous in large virtual > > memory paged environment. The apl\360 storage management and garbage > > collection had to be redone for cms\apl for large virtual memory paged > > environment. > > > > I pointed this out again later in 70s with vs2 (svs & then mvs) ... > > regarding running a "LRU" page replacement algorithm (least recently > > used) in a virtual machine under a "LRU" page replacement algorihtm > > (managing virtual machine memory as virtual paged memory). The scenario > > was that the guest operating system in the virtual machine would be > > trying to use the (virtual machine) page that had least recently been > > used ... while the underlying vm operating system would have been > > removing those very same virtual pages from real storage. There could be > > extremely pathelogical characteristics where the virtual guest operating > > system was always selecting the next virtual machine page to use > > ... that vm370 had just selected to be removed from memory. > > > > misc. past posts mentioning having done page replacement algorithms > > as undergraduate in the 60s. > > http://www.garlic.com/~lynn/subtopic.html#wsclock< http://www.garlic.com/%7Elynn/subtopic.html#wsclock> > < > http://www.garlic.com/%7Elynn/subtopic.html#wsclock> > > > > recent posts mentioning getting pulled into academic dispute > > over page replacement algorithms in the early 80s (involving > > whether or not to give somebody a stanford phd based on thier > > work in the area): > > http://www.garlic.com/~lynn/2010f.html#85< http://www.garlic.com/%7Elynn/2010f.html#85> > < > http://www.garlic.com/%7Elynn/2010f.html#85>16:32 far pointers in > OpenWatcom > > C/C++ > > http://www.garlic.com/~lynn/2010g.html#22< http://www.garlic.com/%7Elynn/2010g.html#22> > < > http://www.garlic.com/%7Elynn/2010g.html#22>Mainframe Executive article on > > the death of tape > > http://www.garlic.com/~lynn/2010g.html#42< http://www.garlic.com/%7Elynn/2010g.html#42> > < > http://www.garlic.com/%7Elynn/2010g.html#42>Interesting presentation > > http://www.garlic.com/~lynn/2010g.html#68< http://www.garlic.com/%7Elynn/2010g.html#68> > < > http://www.garlic.com/%7Elynn/2010g.html#68>What is the protocal for GMT > > offset in SMTP (e-mail) header > > > > the above mentions taking nearly a year to get management approval to > > respond ... even tho it involved work that I had done as an > > undergraduate (probably some petty punishment as opposed to management > > taking sides in the academic dispute ... it was also after having > > brought down the wrath of the MVS organization on my head). > > > > -- > > 42yrs virtualization experience (since Jan68), online at home since > > Mar1970 > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > ---------------------------------------------------------------------- > > Email Disclaimer > > This E-mail contains confidential information belonging to the > sender, > > which may be legally privileged information. This information is > intended > > only for the use of the individual or entity addressed above. If you > are > > not the intended recipient, or an employee or agent responsible > for > > delivering it to the intended recipient, you are hereby notified that > any > > disclosure, copying, distribution, or the taking of any action in > reliance > > on the contents of the E-mail or attached files is strictly prohibited. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > -- > Mark Pace > Mainline Information Systems > 1700 Summit Lake Drive > Tallahassee, FL. 32317 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > Email Disclaimer > This E-mail contains confidential information belonging to the sender, > which may be legally privileged information. This information is intended > only for the use of the individual or entity addressed above. If you are > not the intended recipient, or an employee or agent responsible for > delivering it to the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or the taking of any action in reliance > on the contents of the E-mail or attached files is strictly prohibited. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ========================== This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
