Fw: LINUX on the MAINFRAME
- From: RWells@xxxxxxxxxxxxx (Ron Wells)
- Date: 14 Apr 2010 06:26:20 -0700
or anyone else that wants to jump in on this..
find it strange the osa gig speed not supported? >> can not find anything
as yet that says I can increase past 1500?
----- Forwarded by Ron Wells/AGFS/AGFin on 04/14/2010 08:22 AM -----
From:
Ron Wells/AGFS/AGFin
To:
IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>
Date:
04/14/2010 08:08 AM
Subject:
Re: Fw: LINUX on the MAINFRAME
Mark
So the MTU size can not be greater than 1500 ??
even when running OSA-Gig ??
From:
Mark Pace <mpace58@xxxxxxxxx>
To:
IBM-MAIN@xxxxxxxxxxx
Date:
04/14/2010 07:03 AM
Subject:
Re: Fw: LINUX on the MAINFRAME
Sent by:
IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>
An equivalent for z/VM TPCPIP
DEVICE DEV@0620 OSD 0620 NONROUTER
LINK OSA1 QDIOETHERNET DEV@0620 MTU 1500 ETHERNET <---- For a Layer 2
transport
or
LINK OSA1 QDIOETHERNET DEV@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 <RWells@xxxxxxxxxxxxx> wrote:
more looking...in z/OS tcpip parms.. I use following to setup Gig OSA...Gig
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@xxxxxxxxxxx>
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
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@xxxxxxxxxxx>
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 foreach
imageseperate
Vswitch set for (1)OSA-E Gig ..
Hypersockets used between the Linux images/VM and z/OS(running in
lpar ).http://www.garlic.com/%7Elynn/subtopic.html#wsclock>
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 <lynn@xxxxxxxxxx>
To:
IBM-MAIN@xxxxxxxxxxx
Date:
04/13/2010 02:40 PM
Subject:
Re: LINUX on the MAINFRAME
Sent by:
IBM Mainframe Discussion List <IBM-MAIN@xxxxxxxxxxx>
mpace58@xxxxxxxxx (Mark Pace) writes:
That is a very good point, John. Memory management on Linux for thelittle
mainframe is counter-intuitive. When running under zVM you want as
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/2010f.html#85>16:32 far pointers in
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<
OpenWatcom
C/C++http://www.garlic.com/%7Elynn/2010g.html#22>Mainframe Executive article on
http://www.garlic.com/~lynn/2010g.html#22<
the death of tapehttp://www.garlic.com/%7Elynn/2010g.html#42>Interesting presentation
http://www.garlic.com/~lynn/2010g.html#42<
http://www.garlic.com/~lynn/2010g.html#68<http://www.garlic.com/%7Elynn/2010g.html#68>What is the protocal for GMT
offset in SMTP (e-mail) headersender,
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 listserv@xxxxxxxxxxx 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
which may be legally privileged information. This information isintended
only for the use of the individual or entity addressed above. If youare
not the intended recipient, or an employee or agent responsiblefor
delivering it to the intended recipient, you are hereby notified thatany
disclosure, copying, distribution, or the taking of any action inreliance
on the contents of the E-mail or attached files is strictly prohibited.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: Fw: LINUX on the MAINFRAME
- From: Mark Post
- Re: Fw: LINUX on the MAINFRAME
- Prev by Date: Re: Fw: LINUX on the MAINFRAME
- Next by Date: Re: Print of members in concatanated PDS'es.
- Previous by thread: Re: LINUX on the MAINFRAME
- Next by thread: Re: Fw: LINUX on the MAINFRAME
- Index(es):
Relevant Pages
|
