RE: Ready to scrap an AS/400

re: SQL - I agree that it depends on how SQL is used.  But the applications
choose the method, not the other way around.  Single record access is the
essense of most applications.  The SQL ability to perform set updates is
only useful if one has a set to update.  SQL fetch through a cursor is about
the same cost as an RPG read but fetch via cursor only works after one
executes open cursor - probably with where and order by clauses.  Open
cursor, fetch, close cursor, costs more than a select into host variables.
It requires more than redesign to change an application from single record
updates to set updates, it requires complete reconceptualization and not all
applications survive the trip.  I stand by my original statement.

re: pointers - are you saying that the tag bit maintenance, object
validation, offset validation, and authority checking are done by NT and
Unix?  I don't think so.  They don't have tag bits or authority bits on
their pointers.  Perhaps I can put you in touch with the vendor who can
demonstrate that identical C programs run at non-identical speeds and has
been successfully doing so since 1996?  As I pointed out, I don't know how
to measure this except by running jobs side by side so I know that I am
speculating.  I will listen to another potential explanation ...

re: WRKOBJLCK - Yep.  Now suppose that all the SQL is run by the same
userID.  Every one of those five or ten thousand jobs servicing SQL via ODBC
are named QZDASOINIT/QUSER/xxxxxx - the user is the same on every job.  Each
QZDASOINIT jobs corresponds with an ODBC data source running on some client.
It took me more than  a year to get Rochester to create a patch to the
QZDASOINIT jobs so that they would write that workstation name into their
job log.  Now if we could come up with something to help people on terminal
server ...

Also, every one of those jobs usually has between 50 and 250 open files.
Every job uses between 30 and 150 megabytes of temporary storage as measured
by the temporary storage value in option 3 of DSPJOB and those bytes are
backed to disk.  If you run 300 users with heavy SQL via ODBC, by late in
the day after they have done a lot of connects and disconnects, those users
will have consumed between 40 and 80 gigabytes of disk space.  When I ran
for a few days then IPL'd or end host servers, I have gotten back more than
a 100 gig.  If AS/400 had a lightweight database open and close, it might be
less necessary to maintain all of these open files and all of their parsed
statements laying around.

I see your email address.  Contact me offline, I have a few people that you
can talk to.  I am speculating about the pointer issue (and I said so when I
wrote it) but I have hard data that I personally collected for the other
stuff.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 303 808 8058

> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of pytel@us.ibm.com
> Sent: Monday, July 24, 2000 11:17 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: Ready to scrap an AS/400
>
>
>
> > 1. SQL database IO requires about 10 times more memory than an RPG
> program
> > and between 5 and 100 times more CPU cycles.
>
> I would not say that SQL is much less efficient then native DB.
> It depends (as is often) on how SQL is used.
> SQL tends to be less efficient for single-record access.
> But it also tends to be much more efficient to operate on sets of records.
> Switching to SQL requires somes change in application design, a step which
> is often overlooked.
>
>
> > 5. Most client server applications are written in C.  C
> programmers use a
> > lot of pointers.  On Unix and NT machines, C pointers are very efficient
> -
> > modifying a pointer is a very light-weight operation.  On the AS/400,
> > pointer manipulation requires considerably more CPU cycles.  The obvious
> > throughput difference makes the AS/400 look bad compared to Unix and NT.
>
> AS/400 pointer manipulation is no less efficient than on other platforms.
>
>
> > 6. Performance monitoring has not kept up with client server
> applications.
> > For example, have any of you ever used SQL over ODBC (Client Access
> Express)
> > and tried to figure out which QZDASOINIT job belonged to you?
>
> WRKOBJLCK xxx *USRPRF will show you all active jobs, associated with user
> profile xxx.
>
>
>
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---