Also see Pick.pdf in the Rocket U2 UV11.1 document set. It documents the differences between D3/PICK and UniVerse.
-----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Thursday, 7 April 2011 7:42 PM To: 'U2 Users List' Subject: Re: [U2] Databasic conversion Thanks Bill and Mecki. As ever some fantastic information from this group. From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: 06 April 2011 23:31 To: U2 Users List Subject: Re: [U2] Databasic conversion Symeon: I converted our application from D3 to UniData. There was quite a bit of work. I believe I started in Dec 2005 and finished at the end of March 2006 (I had to work a lot of overtime), and beta tested through Aug 2006. We went live with one our clients in Sep 2006 and then 10 more moved over in Nov and Dec 2006. I spent the next six months moving most of the rest of our clients to UniData. I'd say I spent about a thousand man hours on this. It could have been half that, but I had no help from anyone (including IBM/RS) except Colin Alfke in Canada. I have a lot of emails on this, but the following is one in particular. HTH, Bill ------------------------------------------------------------------------ ----- Original Message ----- *From:* Bill Haskett *To:* 'Bob Little' *Date:* 2/28/2006 6:29 AM *Subject:* Re: [U2] Changes to mail list configurations We're mostly done but have spent about 140 man-days. We spent a fair amount of our time grinding away with the line editor. We were constantly editing data, dictionaries, VOC entries, and BASIC programs. We were able to port a few utilities to UD to help (a TCL shell, a file listing program, a dictionary listing program, and a screen-scroll program). We feel that we could have saved about 30% of our time if there was a decent screen editor, as the productivity was extremely low with the "stone age" line editor (AE). This would have saved us about 40 man-days! We spent about 20% of our time messing around with moving D3 to UV to UD and all subsequent data moves. This would have saved us around 30 man-days. There weren't too many surprises but there were some. Here are the major ones: 1) There was absolutely no interest by IBM in helping us, 2) There were absolutely no utilities to assist in the conversion. When I consulted at a large UD user they had converted from Sequoia several years before and they said there were numerous utilities that converted their dictionaries and BASIC programs. These were unavailable to us. 3) We had to convert to UV first then to UD...well, not actually. We had to move our data to UV, convert the dictionaries, then move to UD. However, we eventually found a utility to restore a D3 account to UniData, which helped tremendously during our client upgrades. 4) There is no (or virtually no) security in U2. It's handled by the O/S. 5) There are no "users" in U2. They're managed by the O/S. 6) UD requires a lot more interaction with the O/S. For instance, since UD has no 'Q' pointers you have to create file pointers using environment variables. In Windows, this requires the creation of the environment variables on the server...very strange. 7) There is no backup facility in UD. 8) I-Descriptors don't apply to each value in a multi-valued field. One has to mange the multi-values as though the dbms was never designed to have multi-values. There are separate functions for multi-values and if one uses a called subroutine, the subroutine has to manage the multi-values and return an MV array back. There are also some peculiarities to UD (things you wouldn't believe). For instance: 1) COPY MYFILE '1''2''3' TO:(ANOTHERFILE ...sometimes doesn't work at all. COPY, BASIC, CATALOG, DELETE-LIST, and numerous other VERBS can't handle multiple items in the command line. You have to SELECT the items first before executing these verbs. 2) You can't create an account from within UD. You have to open a DOS window, create a directory, and execute a DOS command from within this new directory. 3) A new UD account has all kinds of new UD files created within the account. Not really a big deal but surprising. 4) Managing your TERM settings is difficult. 5) Some default settings are weird. For instance, when compiling a BASIC program it gets globally compiled and cataloged...like a new MV user wants this by default?! :-) 6) Items in the SAVEDLISTS file have a number appended to the end so one won't be able to manage these without using the ...LIST commands. For instance "SAVE-LIST BILL" ends up in the SAVEDLISTS file as "BILL000". Some other things to expect: + SAVED LISTS - In D3 you can "SELECT-LIST ME YOU" and you get a list of both lists. In UD you need to "SELECT WHATEVER TO 1" then "SELECT WHATEVER TO 2" then "MERGE.LIST 1 UNION 2 TO 3" and hope it works. :-) - In other MV you can "DELETE-LIST ME YOU" and have them both deleted. - The lists have different keys than the list name. For instance if I do a "SELECT VOC" then "SAVE-LIST BILL" the item in the SAVEDLIST file will be named "BILL000". So don't expect to be able to "SELECT SAVEDLIST 'BILL'" and get the list. - Be careful about using "DIR" files. They often have restrictions in what characters are allowed in the key. So, if you create some items in SAVEDLISTS that might look like "special*bill*1*0" then this will have to be changed to something like "special_bill_1_0". - When we do some things with a select list we're informed we need to verify our next command before we can continue. For instance, :SELECT DTABP = "[LIST]" 83 records selected to list 0. >COPY DTABP TO: (TEMP get id's from select list:B.LIST(Y/N)? well duhhh! :-) I haven't figured out what all does this nor how to fix it. + BASIC syntax .Selecting to a list "SELECT FILEVAR TO MYLIST" requires the list variable "MYLIST" to be initialized first. Others have noted this. .You can't use a KEYWORD as a variable (probably shouldn't anyway). .On subroutines used by dictionaries you need a dummy passed variable 001 SUBROUTINE (OutVal, InVal) then call it from a dictionary by 002 SUBR("MySub", @ID) so if you have a subroutine called by both BASIC and dictionaries, one should expect some re-engineering. .Be careful about compiling and cataloging. Make sure you know where the object is stored and where the catalog entry is made. It is not always true that verbs will be in your VOC. .Be careful about using "NOT(ASSIGNED)" to figure out if a file has been opened. First, UD doesn't use "ASSIGNED" it uses "UNASSIGNED". Second, if a file variable is declared as a named common variable it is assigned a value (zero or null). In this case you'll have to use "FILEINFO()" to determine if the file is opened, but you can't use this function if the file variable hasn't been assigned a variable yet because it's not in named common. .There's no "FOLD()" function (you have to create a subroutine). .When using a BASIC call from a dictionary one should pass in @FILE.NAME, @RECORD, and @ID, since the program has no way to get this information, unlike UV and D3 (not sure about jBase, etc). .The labels for named common cannot be longer than "7" bytes. In Pick mode, the program won't compile while in "U" mode only the first 7 bytes are used. + CASING .Be very careful on casing. Fortunately I didn't have too much trouble with this, but KEYWORDS should be upper-cased (although I think there's a UDT.OPTION for this. + UNIQUERY .Be careful about the Prime syntax. ECLTYPE U uses PRIME so if you think "LIST MYFILE = "KEY]" or "LIST MYFILE WITH @ID = "12]" works, think again. .As you've guessed, there's no way to restrict paging the 1st page of any query (except UDT.OPTIONS 7 ON). So, you can't list three different queries on the. same screen like "LIST CUSTOMERS TOTAL DUE" then "LIST INVOICES TOTAL DUE" then "LIST POSTINGS WITH SOURCE = "A/R" TOTAL AMOUNT" and have the totals show up on the same screen. .Phrases cannot be used in "P" type but work in "U" type. If in "P" type one has to use the lower-case version of the verb (list or sort). + GENERAL .Setting term types requires setting terminal types or width/depth but not both in the same command (or ASSIGN TermType TO SYSTEM(7) in BASIC). .Virtual dictionaries can't access "@RECORD<1>" in Pick mode but have to use the deprecated syntax "EXTRACT(RECORD, 1, 0, 0)". Still have a some work on dictionaries though. .I haven't quite got the hang of when I can change to BASICTYPE "U" and and not crash other stuff. .I haven't been able to use a T-DUMP/T-LOAD to move data because I can't use a local O/S file as the target/source for these tape commands. So I have to do this by filtering keys so they don't contain prohibited characters (like an astrix '*'), copy them to a local O/S directory, copy them over into UD, then un-filter the the keys. Huge pain! . "WHO" doesn't give you the account you're logged onto. "WHERE" does. .'Q' pointers don't exist in UD so one has to create something like: DTAPATCHES 001: LD 002: @UDTHOME\DTA\PATCHES 003: @UDTHOME\DTA\D_PATCHES This requires the "DTA" account be under the UDTHOME directory (not really a big deal) though. If 'Q' pointer(s) point to itself, 001 Q 002 003 DTA however, they will all have to be altered if the name of the account ever changes; a probability for production accounts. There's more, but I forget, off the top of my head. As to some recommendations for what IBM can and should do: 1) Create some utilities to convert other MVs to U2. This would have saved us at least 50 man-days. 2) Create a "screen editor" that can edit everything within (and without) the UD environment. Productivity increases are dramatic moving from a line to a screen editor. 3) Create option to remove case sensitivity. This is standard in the Microsoft world and in most databases, but not U2! This should be true at both the database level and the command level. 4) Create a command line that manages a history (the stack), allows searching through, and modifing a history line selected. 5) Create a GUI dbms admin tool and a GUI dbms development tool. 6) Create an admin account from within U2 (UV has it but UD does not) and document all the admin commands in a single location so an application can use whatever. 7) Create a lot of the standard Pick verbs in the VOC as synonyms. Some are there, like "CREATE-FILE", while others are not, like "OFF". :-) 8) Remove the differences between BASIC functions and I-Descriptor functions. For instance, Item<1,1> works in BASIC but you must use EXTRACT(@RECORD, 1, 1, 0) in an I-Descriptor. 9) Activate the extended functions of UniQuery to Pick mode (EVAL, FMT, etc). Make sure keywords like "CNV" are also "CONV". 10) Set up default compiling and cataloging to be local (direct actually). 11) Create backups to be created and restored using other mvDbms formats (at least T-LOADS). 12) Create 'Q' pointer capability. Additional requests: 1) Allow security to be set up within the dbms 2) Allow users to be maintained within the dbms 3) Create a backup utility within the dbms 4) Create "pseudo" dictionary items that can reference any direct attribute and are build at runtime. For instance, if F12 wasn't in the VOC or DICT.DICT or anywhere else, one could say "LIST VOC F12" and get the 12th attribute of each VOC item. These "pseudo" items would be created at runtime and cleaned up immediately after. This way any raw attribute could be referenced. 5) Do the same thing with 'Q' pointers where one could reference any file in any account from both BASIC and TCL. Let's say I have an account named AR with a CUSTOMERS file in it. I happen to be logged onto the INVENTORY account and at TCL execute: ":LIST AR:CUSTOMERS" ...and would get the appropriate listing of data. 6) Create a dynamic width dictionary code so when used it consumes the remaining unused width of the current output device. For example, the CUSTOMERS file has a field definition (dictionary) NAME that is set to 20 columns wide then do the following: :TERM 40,25 :LIST CUSTOMERS NAME CUSTOMERS. NAME......................... 12345 ELDRICK TIGER WOODS :TERM 55,25 :LIST CUSTOMERS NAME CUSTOMERS. NAME........................................ 12345 ELDRICK TIGER WOODS I'm sure I can think of more but I've run out of gas. :-) _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3555 - Release Date: 04/06/11 _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
