Gabriel: According to a previous posting by Brian Leach:
**----------------------------------------------------------------------** -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Friday, January 20, 2006 1:42 AM To: [email protected] Subject: RE: [U2] Difference between IBM Universe and IBM UniData That's a huge subject. The fundamental database handling is broadly the same, based on the same original model. You will find yourself at home there. Most of the differences are on the periphery and to do with emulations. You will find the same thing whenever you change platform: those useful little commands you use all the time just aren't there or don't work the same - but most do have equivalents. In terms of functional coverage (rather than implementation) the two databases are broadly equal - though they may take different routes to get there. Here are a few pointers covering some of the more standard areas. This is by no means exhaustive, but should give you some idea of the scope of the differences: 1. Account structure UniData has no equivalent to the UV.ACCOUNT file, or account flavors. Emulation is set at run time using a combination of the ECLTYPE (changes TCL commands), BASICTYPE (changes compiler) and a series of UDT.OPTIONS that change everything else. To exit an account use BYE (not OFF). LOGTO is supported using paths. 2. The editor is named AE (there is an ED, but that's different). It is fundamentally the same as the UniVerse ED editor. 3. Basic is generally in upper case only (no nice Open, Read, ReadNext etc): though there is now a compiler option to make keywords case insensitive (at last). Fundamental syntax is the same, though look out for the emulations of statements such as LOCATE and EXECUTE. Many little extended syntax elements are not supported: for example the standard substring delimiter formats Variable[2,3] is supported but not Variable[3] and Variable[",",2,1]. Lots of other subtle differences. The debugger is in some cases more powerful, but you need to explicitly enable it when you compile (see the help for BASIC). Which reminds me: the online help is generally better. Cataloging is different, and for local catalog you must supply the LOCAL keyword. Globally cataloged items do not have the prefixes (*,$,-). 4. Basic emulation can be forced using the command $BASICTYPE P|U, similar to $OPTIONS PICK etc. This must be the first line in the code, before the heading. 5. Sequential file handling is different: for OpenSeq etc look at the OSOPEN command. I'm just writing a simple article on this for the knowledge base. 6. File pointers and most VOC items are the same: UniData supports paragraphs, sentences, inline prompts etc. Dictionary items should come over, though some conversion codes are not supported, TRANS() is different, and you can't use dynamic array operators e.g. @RECORD<2> must be EXTRACT(@RECORD,2,0,0). AFAIR it doesn't support Remotes in the same way. 7. The query language is broadly the same, except where it isn't! In particular it is a lot more literal than RetrieVe, which will take a 'best guess' at what you want (and, to be honest, sometimes gets that wrong). Much of this can be customized using the UDT.OPTIONS, especially around break point handling. UniData is traditionally stronger at handling sub-values than UniVerse, though you need to define them in your dictionaries. UniQuery supports the overrides such as EVAL, FMT etc. in LIST and SORT commands. The CONV keyword is CNV (why, why, why - what was the point of making it different <sigh>). Some of the more obscure or combination conversion codes are not supported. It does have the ability to create delimited output, which is something I wish was in RetrieVe. 8. The file structure is logically the same though the internal organization is different and you don't have the range of hash types (not necessarily a bad thing as you can't go as badly wrong!). Dynamic files are supported, but are different. And naturally the syntax of CREATE.FILE is different - but then it is everywhere. To create a directory file use CREATE.FILE DIR filename. Secondary indices are supported though again the physical structure is different. Object code is not placed into .O files and there is the ability to include environment variables in file pointer paths - potentially very useful and makes up for the lack of an accounts file. 9. There is some SQL support, but it isn't as intimately coupled as in UniVerse. I've never used it in anger, and from what I hear it isn't up to much. 10. Spooler is different, but largely supports the same commands. If anything it is closer to that used by UniVerse on Windows. 11. UniData is excellent at handling unitary operations: standard business transactional applications. It does seems to squawk if pushed too hard: too large strings, too complex dictionaries etc. without appropriate tuning of dictionary sizes and memory blocks. That said, (before I get flamed) there are lots of large and very capable UniData sites out there and it is an excellent tool for business applications. 12. The middleware is broadly the same. UniObjects in particular is equivalent on both platforms. External gateways (GCI and UCI) have different equivalents. 13. UniData has a different transaction model and supports a recoverable file system. From what I hear these are definite advantages over UniVerse. 14. I've never tried to use PROC on UniData. Perhaps someone else can answer whether it supports the full PQN range (F-OPEN, MV etc) That's a very brief list for now. **-------------------------------------------------------------------------* * I'd make a few minor additions. 1) UniData does have a UD.ACCOUNT file but I'm not sure how it's used. Personally, I use it for multi account upgrades where I need to know the directory where each account resides. However, I'm required to maintain the file by hand (or via UniAdmin). 2) When I converted an application from D3 to UniData I found the query language worked pretty much the same in UniVerse but not the BREAK functionality in UniData. Secondly, the enhanced query functionality only works in UniData mode. For instance, if I have a @UQ phrase in UniData and I had ECLTYPE "P" set, then: :LIST MYFILE WITH @ID = "1]" ...would only produce a list of IDs while :list MYFILE WITH @ID = "1]" ...would produce output defined by the @UQ phrase 3) The syntax within UniData ECL seems to be a bit inconsistent. For instance, in all PICK single quotes identify item ids while double quotes identify values. e.g. :COPY MYFILE '1''2''3' ...should select the three items identified from MYFILE and return the "TO:" prompt. It doesn't in UniData. It requires the following: :COPY MYFILE 1 2 3 (an enhanced PICK format) :COPY MYFILE "1""2""3" (a unique syntax) The main problem with the syntax is it's not consistent (sometimes it works sometimes it doesn't). 4) There's a pretty large difference in INDEXES between the two products. The BASIC statements to traverse the index are significantly different. UniData uses B-Tree structures while UniVerse uses a sort-of linked list format. So, if you have 25 SMITH entries in the UniData index you can traverse these entries one at a time (forward and backward) using the UniData BASIC statements. You have to build an application API to do the same thing in UniVerse, as the BASIC statement will simply return all 25 items at once. 5) UniVerse has 'Q' pointers while UniData does not. This is probably because UniData doesn't maintain a "context" of its accounts. i.e. UniData doesn't really know where the accounts are located, except via either a complete path or a shortened path using an environment variable. 6) There is no backup utility in UniData. You must solely rely on the O/S to backup the UniData account directories. 7) UniData cannot utilize the Pick style "A" and "S" dictionary types. Consequently, dictionaries in UniData have to be "D" and "I/V" types. 8) UniData is not inherently multi-value aware. If you want to output multi-values like: :LIST CLIENTS PHONE_NUM CLIENTS... Phone Number.. 9999 3342425544 3342664857 10034 3342482815 3342481924 ...the "PHONE_NUM" dictionary needs to be defined as multi-value like: Top of "PHONE_NUM" i *--: P 001: D 002: 9 003: 004: Phone Number 005: 14R 006: MV 007: PHONE_ITEMS Bottom. ...otherwise output looks like: LIST CLIENTS F9 FMT "40L" CLIENTS... F9..................... 9999 3342425544 3342664857 10034 3342482815 3342481924 9) UniData has numerous annoying prompts that occur even in BASIC programs. Say I want to select some records in a file then copy them to another file you get the annoying prompt: :SELECT CLIENTS 130 records selected to list 0. >COPY CLIENTS TO: (TEMP get id's from select list:9999(Y/N)? During any conversions, one must be very careful about these idiosyncrasies. 10) UniVerse now has triggers on hashed files (non-SQL'ized). UniData has had them for awhile and they're probably more stable. There are more but this should be a decent list to work from. Hope this helps. Bill >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Green >Sent: Saturday, April 28, 2007 2:28 PM >To: [email protected] >Subject: [U2] Differences between UV and UD > >I feel a little dumb asking this but IBM's site isn't exactly >informative with my question--- > >What are the principle differences between UV and UD anyway? > >Thanks, >Gabe >------- >u2-users mailing list >[email protected] >To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
