|
Steve, These are good ideas... I suggested you consider a re-engineering approach a while back... But I don't think I explained properly. >From what I've seen of your posts, I would assume the system has a tight modular design. What I was suggesting was re-engineering ***the modules responsible for the bottleneck***... These seem to be the I/O (which is typically the bottleneck in all apps...) >From everything I've seen on this list: ODBC & DDM = *ELSTINKO; Sockets = *ELPRIMO... Re-engineering a small number of modules could save you a ton of troubleshooting... Can't help with specifics, however, but think a lot of Nathan's suggestions. jt | -----Original Message----- | From: midrange-l-admin@midrange.com | [mailto:midrange-l-admin@midrange.com]On Behalf Of Nathan M. Andelin | Sent: Friday, November 30, 2001 1:26 PM | To: midrange-l@midrange.com | Subject: Re: ddm and odbc problems | | | Steve, | | You may be too far along in your implementation to consider a | design change. | Your best option may be to tune the network, or add bandwidth. If this is | the case, then feel free to politely ignore my remarks. After several | unsuccessful attempts at using ODBC over a WAN, I have finally given up. | DDM seems to be a close cousin to ODBC. | | One design alternative I would have considered, is to store the | image files | in GIF or JPEG formats, on an optical device attached to your AS400A | (Canada) system , and referenced by your AS400A database. Then | build a Web | application and deploy it on that same box. Let users in NJ, and | NY access | the application from their browsers, over an Intranet or the Internet. | | Nathan M. Andelin | www.relational-data.com | | | | | From: "Steve Richter" <srichter@AutoCoder.com> | We just completed phase 1 of a W2K based image system install. 3 physical | locations: Canada, NY, NJ. Image xref index file is stored on AS400A in | canada, Green screens on AS400B in NJ can initiate image print and fax | functions. AS400A and the W2K image server are in Canada, AS400B is in NJ, | the W2K image client and green screens to AS400B are in NY. All IP | connected, cisco routers everywhere, all ethernet, frame cloud, 56kb | between NJ and Canada, 56kb between NJ and NY. Both AS400's are | 720's. 500+ | CPW. All AS400 are V4R4. | | Here are the problems. | | ODBC and DDM performance stinks. Green screen from NY to AS400B in NJ is | fine. Many users, sub second resp time. A simple odbc trans from the NY | image client to AS400B in NJ takes 3-5 seconds. A slightly more | complex odbc | tran to AS400A in canada from the same image client in NY takes 30-40 | seconds. | | DDM performance between AS400A in Canada and AS400B in NJ ( 56kb link) is | embarrassing. DDM *IP file is on AS400B and points to a file on AS400A. A | sfl pgm on AS400B displays 10 rcds per page. For each rcd, we SETLL to the | ddm file to see if a rcd exists in the file on AS400A. Takes 70 to 80 | seconds to dsply the sfl page. Without the SETLL to the DDM file, | rolling is | sub-second. BRWPFM on the DDM file takes 20 seconds per page. | | ADDSVRAUTE issues. | | We have a lot of users that will run pgms that use the DDM file. Must run | ADDSVRAUTE for each user. Allowing a group profile in | ADDSVRAUTE, where all | the mbrs of the group pick up the USRID and PASSWORD of the group profile | would be better. | | No WRKSVRAUTE cmd. Is there an api that will list the SVRAUTE ? | | Need a tgt ip addr and/or DDM file name to be added to the SVRAUTE table. | All the *IP DDM transactions of a user have to run with the same USRID and | PASSWORD. This effectively limits a user profile to *IP DDM'ing to only 1 | remote system. | | DDM error msgs should be better stated. When the remote systems | *DDM server | is not started, a "route to target not found" msg is reported. When your | SVRAUTE USRID is not authorized to the remote logical file, a "cannot add | mbr to ddm file" msg is received. When troubleshooting, I was switching to | another AS400 to simulate the errors I was getting, did not | always remember | to CHGSVRAUTE and sometimes got a "library not found" msg even though the | lib did exist. A signoff/signon then reported the correct error msg. | | Troubleshooting the performance problems is where I need help. The Canada | AS400A is the bottleneck and we dont have much access to that system. As a | comm line benchmark, 400KB of image file data was ftp'd from the image | client in NY to the image server in Canada. Took 8 minutes to run. 56kb | line. | | I assume I cant run the *IP DDM in some sort of trace mode. Similar to | TRCICF in SNA/APPC. | | Will a STRSST trace show me when the DDM transaction leaves the NJ AS400B, | when it arrives at Canada AS400A, then leaves Canada AS400A and | arrives back | in NJ AS400B? Does STRSST show IP packets, with the ip addr and port nbr | visible ? Similar to how SNA STRSST trace shows the controller name and | device address before each SNA packet? | | Do the cisco routers we use ( model 2600 ) have a service port | trace option | similar to that of the IBM 2210 routers that we used to use? Where trace | data is written to the service port of the router for each packet that is | routed, and a pc ( or as400 ) that is attached to the service port can | record the trace data to a text file. | | Is there network software that helps to troubleshoot network performance | problems like ours? Show when packets arrived and departed each | node in the | network ? FIltered by IP addr and port nbr? | | | Thank you MidrangeL list, | | Steve Richter | | | _______________________________________________ | This is the Midrange Systems Technical Discussion (MIDRANGE-L) | mailing list | To post a message email: MIDRANGE-L@midrange.com | To subscribe, unsubscribe, or change list options, | visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l | or email: MIDRANGE-L-request@midrange.com | Before posting, please take a moment to review the archives | at http://archive.midrange.com/midrange-l. |
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.