Have you (or anyone else you know about) written up the pros, cons,
pitfalls, tips, etc of making this move?  I've been toying with the idea
myself, but I'm not sure if it is worth the effort on legacy files.  Are you
converting everything or just "new" databases?  Has it been worth the
effort?

> -----Original Message-----
> From: John Bussert [SMTP:jbussert@stecnet.com]
> Sent: Thursday, December 20, 2001 3:03 PM
> To:   'midrange-l@midrange.com'
> Subject:      RE: UDB question
>
> We have gone through a slow process of doing all new development using
> SQL DDL instead of DDS because of tools and the ability to map it so an
> NT DB2 database for testing, etc.  Especially now that stored procedures
> and triggers can be SQL based (5.1 with the built in C compiler), it
> makes the code more "portable".
>
> But you already have UDB on the 400 - opps iSeries.  Now you can go back
> to management (after the holidays) and tell them you spent the whole
> time off working on implementing it, and did it without spending any
> money on your own time!
>
> jb
>
> John Bussert
> Swift Technologies, Inc.
> www.swiftorder.com
> 847-289-8339
> 847-289-8939 (fax)
> jbussert@swiftorder.com
>
>
> -----Original Message-----
> From: R. Bruce Hoffman, Jr. [mailto:rbruceh@attglobal.net]
> Sent: Thursday, December 20, 2001 9:01 AM
> To: midrange-l@midrange.com
> Subject: Re: UDB question
>
> ----- Original Message -----
> From: "Dan Rasch" <drasch@mail.win.org>
> To: <midrange-l@midrange.com>
> Sent: Wednesday, December 19, 2001 1:37 PM
> Subject: UDB question
>
>
> > I was just told there is a directive from management to look into
> > UDB for the 400's DB2.  Apparently the claim is that if we replace
> > our DDS with SQL definitions, we can change file defs (like adding
> > fields to the end of the record) without the level checks.
>
> Level checks are not caused by the definition (DDL of SQL) but the
> access
> and manipulation of data (DAL of SQL) through programs that refer
> directly
> to the file and it's external definition.
>
> SQL _access_ (select, delete, insert, update) if done _without_  the *
> (ie.
> select * from a into bstruct) will ignore level differences on the
> record
> because it looks at the field level, not the record level for its data.
>
> As for UDB, on the 400 it's just a name. If you have an AS400 or
> iSeries,
> then you have "DB2 UDB for OS/400". There are three flavors (and
> producers)
> of DB2 UDB. One runs on the 400, one runs on 390 architecture and (IMO
> the
> true UDB) the last runs on just about everything else with a common code
> base and comes from Toronto.
>
> The 400's version of DB2, in many cases, lags behind the facilities of
> the
> "all platform" version of UDB and the 390's version. The glaring
> exception
> was EVIs which made it to the 400 first. But the 400 still does not
> support
> grouping sets, rollup and cube operations, although it finally has
> declaritive triggers, and more than 6 allowed.
>
> Also IMO, switching the definition to SQL allows you to use tools for
> database design, modelling, creation, maintenance and documentation. All
> well worth the effort.
>
> ===========================================================
> R. Bruce Hoffman, Jr.
>  -- IBM Certified Specialist - iSeries Administrator
>  -- IBM Certified Specialist - RPG IV Developer
>
> "I want to be different, just like everybody else!"
>   - Ceili Rain
>
>
>
> _______________________________________________
> 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.


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.