RE: ddm and odbc problems

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.
|