Thank you Chris. god bless you, Shai On Wed, Dec 21, 2011 at 4:45 PM, Chris Mason <[email protected]>wrote:
> Shai > > So the *real* problem is to partition the load between your application > and other applications, an aspect it is rather difficult to discern in your > earlier posts! > > Come back SNA - with its required respect for transmission priority - all > is forgiven! IP and TCP etc. struggle along reinventing the wheel time and > time again in order to cover the ground SNA sorted out 35 years ago!!! > > Is this actually a *real* problem which the customer has noticed or is it > simply *anticipated* because suddenly the use of your application might > turn out to slow down other traffic over the single OSA feature interface > given that your application promises to impose a heavy batch load? > > What speed over Ethernet does the OSA feature support? It became well > appreciated in the early 1990s that, even in the business environment, the > reason IP and its garnishing would triumph over SNA and its careful > architectural provisions was that customers for whom SNA was just too > complicated would simply invest in ever cheaper faster transmission media > resulting in the careful SNA provisions for limited bandwidth becoming > pointless - most of the time - eventually ... > > The bandwidth consideration may well apply here. I assume you are using > TCP. TCP has to stop every so often in order to wait for acknowledgements. > This may provide sufficient "gaps" in the potentially smothering batch > traffic to allow the other traffic to proceed and possibly/probably to > proceed unhindered. > > - > > One "quick and dirty" way to "prioritise" traffic may simply be to reduce > the maximum transmission unit (MTU) value on the route to the PC so that, > in terms of "management overhead", the traffic becomes less efficient but > it gets slowed down and larger "gaps" appear. > > I'm picking on the MTU value because this is a relatively easy parameter > to interpose and it fits your concept of a "simple tweak" to the > specifications in what you - and curiously Michael who I would expect to > know better! - describe as the "TCPIP option file" but which the rest of > the world know as the "z/OS Communications Server IP component PROFILE data > set" - or some abbreviation thereof. > > Note that this is not an exact science. You will have to pick on a low > value for the MTU and increase it until you start to note a reduction in > what you might hope to be acceptable - perhaps response times for > interactive users - or until the MTU value rises to the maximum value > allowed - in which case the whole exercise would be shown to be a complete > waste of time!. It would be easier to adopt precisely the reverse approach > but this runs the risk of very poor response times on the first > experimental run! > > It would be so much easier if you had actually specified that the > configuration is as I had guessed in my previous post and provided the > PROFILE data set statements which I requested - which incidentally > completely avoids all the complications others have offered you - including > now the NETACCESS idea! > > If that configuration applies, the statements you didn't post could well > be something like the following, where I have assumed that the IP address > of the OSA feature interface is 192.168.254.1 and the name of the LINK > statement is "OSA": > > HOME > > ... > 192.168.254.1 OSA > ... > > BEGINROUTES > > ROUTE 192.168.254.0/24 = OSA MTU 8992 > ROUTE DEFAULT 192.168.254.254 OSA MTU 1492 > > ENDROUTES > > You could then insert a specific ROUTE statement for the PC as follows: > > HOME > > ... > 192.168.254.1 OSA > ... > > BEGINROUTES > > ROUTE 192.168.254.200/32 = OSA MTU 576 > ROUTE 192.168.254.0/24 = OSA MTU 8992 > ROUTE DEFAULT 192.168.254.254 OSA MTU 1492 > > ENDROUTES > > I have picked the number 576 as your starting MTU value not quite out of > the air. It is the minimum value which all media should support on the > outbound side of a router. Since we don't have any routers on the route to > the PC, that is not actually a consideration here. > > - > > The above was one possible "quick and dirty" way of achieving your > objective. I decided on it because I had an idea one of the parameters of > the ROUTE statement which are usually left to default, the "retransmission" > parameters, might offer a way and I then noticed the MTU parameter. That is > to say it's just an off-the-cuff idea which is by no means the "official" > way to do what you want. > > However, a bit of research did reveal the "official" way to do what you > want - but, unless your customer has already invested in setting up the > "Policy Agent" environment on top of the IP component of z/OS > Communications Server, sleeves are going to need to be rolled up! > > The starting points for what you really want to do - as far as I can tell > - are the following: > > "Setting Up Priority Queuing" in the "Open Systems Adapter-Express > Customer's Guide and Reference" manual > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ioa2z180/1.7.2.3 > > and > > Chapter 16, "Policy-based networking" in the "z/OS Communications Server > IP Configuration Guide" manual > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.7 > > The "quick and dirty" solution was the "simple" one. Unless the Policy > Agent has already been set up - and, if it had been set up, such an > on-the-ball customer would not be asking the question! - this is not really > a "complicated" matter but a labour-intensive one involving lots of reading > the manuals! > > - > > Given that you are offering a product, it is up to the customer to be able > so to adjust the IP-based software as it applies to the specific > configuration in order to accommodate your product. The customer should be > happy that you can offer a couple of suggestions - free consultancy, no > less! - regarding how this load "prioritisation" could be done. > > - > > Chris Mason > > On Wed, 21 Dec 2011 07:12:45 +0200, shai hess <[email protected]> wrote: > > >Thank you Chris and others, > > > >I will continue if I will need with the proper forum. > >I thought that the answer to my customer can be simple by changing some > >parameters in the TCPIP option file. > > > >Anyway, I thought that changing parameter in TCP can better balance the > OSA > >HW between production load for TCP and MFNetDisk load for consuming the > TCP > >in the same MF. > > > >But I think that the subject is more complicate than I thought. More > >knowledge required. > >I wish I had the time to spent more time and digging into the MF system > >network administrator to support some "simple" questions of users which > >expect me to know more MF network which is component which MFNetDisk uses > a > >lot. > > > >Thanks, > >Shai > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
