RE: DB2/400 comparisons with other relational databases (specifically Oracle and SQL Server)

>Consider the administration work needed when using db2/400 as a true
server:
>      installing client access on the remote pc
>     creating user profiles on the 400, scheduling password chgs
>     managing client access updates and password changes
>     troubleshooting the ddm over tcp/ip server jobs and connection errors
>    Work and research needed to address performance and compatibility
>issues.

I don't consider these to be DBA tasks, except database performance.  These
aren't differences between DB2/400 and Oracle or SQL Server.  If you had an
Oracle application written with batch and online processes on the same
server as the database you'd take on these types of burdens as you moved the
application to another tier.  What you don't get on the AS/400 is the same
degree of pain chasing down tablespace management, data file configuration,
rollback segments, redo logs, index and database statistics rebuilds, and
layout of "hot" tables and indices.  This is true regardless of whether the
AS/400 is running as a database server or single tier -- a little mainframe.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@dollargeneral.com>





-----Original Message-----
From: Steve Richter [mailto:srichter@AutoCoder.com]
Sent: Friday, September 28, 2001 9:32 AM
To: midrange-l@midrange.com
Subject: Re: DB2/400 comparisons with other relational databases
(specifically Oracle and SQL Server)


Keep in mind that we are comparing a database server ( oracle, sql server )
to, what would you call it, a local database api engine.  db2/400 works best
when it is used to  "serve" applications which are on the same hardware as
it is.

Consider the administration work needed when using db2/400 as a true server:
      installing client access on the remote pc
     creating user profiles on the 400, scheduling password chgs
     managing client access updates and password changes
     troubleshooting the ddm over tcp/ip server jobs and connection errors
    Work and research needed to address performance and compatibility
issues.

If you are using db2/400 as a database server, I think one or more dba's are
needed.


Steve Richter



----- Original Message -----
From: "Alistair Rooney" <AlistairR@tbsa.co.za>
To: <midrange-l@midrange.com>
Sent: Friday, September 28, 2001 9:39 AM
Subject: RE: DB2/400 comparisons with other relational databases
(specifically Oracle and SQL Server)


> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hi Nelson,
>
> I think the phrase where you said: "I do nothing related to
> allocating space for files, maintaining indexes, backing up, etc.  All
> that
> stuff is on auto-pilot." helps bolster my point. Sure we run a weekly
> report to check on disk utilisation, but that takes my Technical Manager
> about 5 secs to look at. We have a fairly mature management team and new
> logicals on gigantic files and the like are discussed amongst us.
>
> In an SAP/Oracle environment you have to ensure (wait for it) that all
> the transactions from the Application Server have actually posted to the
> database. You have a daily report of "corrupt" indexes which must be
> sorted out and so on.
>
> My advice would be not to take the Oracle job. Those poor guys really
> have a hard time.
>
> Alistair
>
> -----Original Message-----
> From: Smith, Nelson [mailto:NSmith@lincare.com]
> Sent: 28 September 2001 15:07
> To: 'midrange-l@midrange.com'
> Subject: RE: DB2/400 comparisons with other relational databases
> (specifically Oracle and SQL Server)
>
>
> Hi Alistair,
>
> I am an AS400 "DBA" here and at my former company, however, as you
> already
> know (but not Server Dave, obviously), none of my duties remotely
> resemble
> the duties of the SQL Server DBA's (yes, multiple) that we also have
> here.
> About the only thing I do that is actually related to the database is to
> enforce programming and nameing standards on the other programmers and
> consult with them on the best way to do things related to triggers,
> constraints, etc. I also perform all database changes on the production
> system, just to keep everyone's hands off them.  I do nothing related to
> allocating space for files, maintaining indexes, backing up, etc.  All
> that
> stuff is on auto-pilot.  On a 720 development machine with about 20
> programmers and a 740 production machine connected to over 500 remote
> sites,
> my "database" duties probably amount to no more than an hour or two a
> week.
>
> I've seen employment ads offering $120M or more for Oracle DBA's.  Are
> those
> systems so bad you have to pay that kind of money just to "maintain" it?
> Sheesh!  Maybe I should switch over......
>
> > -----Original Message-----
> > From: Alistair Rooney [SMTP:AlistairR@tbsa.co.za]
> > Sent: Friday, September 28, 2001 5:00 AM
> > To: midrange-l@midrange.com
> > Subject: RE: DB2/400 comparisons with other relational databases
> > (specifically Oracle and SQL Server)
> >
> > This is a multi-part message in MIME format.
> > --
> > [ Picked text/plain from multipart/alternative ]
> > Just thought I'd stick in my .2c worth. I've never had the need to
> > "administer" our DB2/400 database. I have, however, seen my colleagues
> > having to have downtime on a fairly regular basis with their Oracle
> (on
> > HP-UX) and SQL server machines because of "database" problems. Most
> > medium to large sites will employ a DBA for Oracle or SQL Server.
> > Question: Do any 400 sites employ a DBA and if so then what do you do
> > with him?
> >
> > Alistair
> >
> > -----Original Message-----
> > From: Chris Rehm [mailto:javadisciple@earthlink.net]
> > Sent: 28 September 2001 10:24
> > To: midrange-l@midrange.com
> > Subject: Re: DB2/400 comparisons with other relational databases
> > (specifically Oracle and SQL Server)
> >
> >
> > On Friday 28 September 2001 12:28 am, Server Dave wrote:
> > > Joe,
> > > Without spending a great deal of time-this info is backed up in
> print
> > -two
> > > sources
> > > on Microsofts site.and is common knowlege too people "who know".
> >
> > Now that just gags me. 'common knowlege too [sic] people "who know"'.
> > Ridiculous. Just admit you don't have the answers to the questions and
> > move
> > on. Your opinion is obvious and from your "source" I can see it comes
> > from
> > Microsoft's marketing info.
> >
> > Just say so.
> >
> >
> > --
> > Chris Rehm
> > javadisciple@earthlink.net
> >
> > And thou shalt love the Lord thy God with all thy heart...
> > ...Thou shalt love thy neighbor as thyself. There is none other
> > commandment greater than these. Mark 12:30-31
> > _______________________________________________
> > 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.
> >
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> >
> > This footnote also confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> >
> > www.mimesweeper.com
> > **********************************************************************
> > _______________________________________________
> > 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.
>
>
> ************************************************************************
> ************************************************************************
> ************************************************************
> This message originates from Lincare Holdings Inc. It contains
> information which maybe confidential or privileged and is intended only
> for the individual or entity named above.
> It is prohibited for anyone else to disclose, copy, distribute or use
> the contents of this message.
> All personal messages express views solely of the sender, which are not
> to be attributed to Lincare Holdings Inc., and may not be copied or
> distributed without this disclaimer.
> If you received this message in error, please notify us immediately at
> MailAdmin@lincare.com or (800) 284-2006.
> ************************************************************************
> ************************************************************************
> ************************************************************
> _______________________________________________
> 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.
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
> _______________________________________________
> 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.
>
>

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