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
