Interesting. I never realized that the Q pointer capability on the Manage-2000 system was NOT a part of Unidata.
Here is how they get around it: CT Copy an Item Page 1 File Name VOC Item Name Q.0210 File Resides in account MANAGE-2000.7.0 -- Item 1 "Q.0210" has 3 lines -- 0001: F 0002: ../MMC.MAIN/SOH 0003: ../DICTS.7.0/D_SOH They just create a file pointer! hth, Allen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Taylor Sent: Monday, March 20, 2006 14:47 To: David Wolverton; [email protected] Subject: Re: [U2] [UD] Triggers David, I asked Bill Haskett recently why he chose to move this customer's software from D3 to Unidata rather than to Universe, and he responded to me in considerable detail. Since I thought this might be of interest to you and others on the list, I have reproduced his comments with his permission. <Bill's Comments Start> It was reported to us, at the time, that UniVerse only had SQL triggers, their indexing scheme was sub-standard, and their data input capabilities had no timing functionality. The rest of the issues, we brought to a U2 VAR to review, were reported to be similar between both UniVerse and UniData. So, the analysis indicated there would be less work with UniData than with UniVerse. These were some of the other issues: 1) DBMS security (there is virtually none at the U2 level) 2) Backups (reported that both U2 products had it) 3) O/S integration (UD was supposed to be better) 4) BASIC language differences (both were about the same) 5) Login processing (both have LOGIN/LOGOUT paragraphs) 6) Case insensitivity (neither U2 product functionally has this) 7) terminal management Our client has four critical needs: 1) dictionaries, 2) indexes, 3) data input with timing, and 4) triggers. Their application uses these functionalities extensively. The conversion was very simple with respect to needs 2, 3, and 4. :-) We were under the impression IBM had "conversion" utilities available that would mostly convert D3 style dictionaries to UD style dictionaries; thus mitigating the one advantage UV had over UD. I played with UV for about three months and pretty much validated that D3 doesn't run like D3 on UV. Our application needed a lot of work to make it run. What this means is that any (and I mean ANY) use of newer D3 functionality makes conversion more difficult. The application we're converting does have some of this functionality. Our client's application was very clean; didn't use PROCs, dictionaries were clean, BASIC code was clean, and accounts were clean and properly segregated. I actually used D3RESTORE, which worked fine to UV. I've been told that "ACCOUNT.RESTORE" works fine in UniData. This application has their own spooler functionality. They weren't concerned about this too much because their new application will be using "SQL Reporting Services" and the "spooler" will be unnecessary. But now with things working well enough they want to hire us to (In response to our comment that Universe is not comfortable comparing the numeric value of an alpha string with that of another alpha string - eg. IF "ABC" > "XYZ" THEN etc (I can't understand why :)!).) We've found this not to be of too much significance, but there's a lot more than what you're suggesting: like TCLREAD, casing, ACCESS() vs @ & SYSTEM() functions, Indexes, ASSIGNED (or UNASSIGNED), FOLD, IN vs KEYIN, dimensioned arrays, FILEINFO vs NOT(ASSIGNED), subroutine names inside the program, HEADING options, OCONVs, LIST mgmt, CONVERT, SWAP, CHANGE, COMMON names, etc, etc, etc. This is not to suggest that an basic R83 application can't convert to UniVerse easily, just that a D3 application can, and probably will, have more difficulties. There were some "SURPRISES" we ran into: 1) Backup utility. UD has no backup utility. As a result it could not restore data reliably. We had to jury-rig a transfer between D3 and U2; which worked ok; others have been more successful with the UD "ACCOUNT.RESTORE". We eventually got the data restored. When an mvDbms person speaks of a "backup" that's what they mean. Like a "tar" or an "ntbackup" file. We never thought UD has no internal backup utility. 2) Limited U2 resources. The VAR we worked with has limited technical resources for UniData. We've had to pretty much do this ourselves. IBM has no interest in our conversion from D3 and there seems to be very limited resources available for assistance. 3) Q-File facility. UniData doesn't have a comparable function. Users of UD, and the engineers, don't seem to have a clue of it's benefits and have not incorporated this into UD. 4) Pick compatibility. UniData doesn't seem to have moved forward in 20 years with their Pick syntax. They have, however, incorporated the '-' in the usual verbs (CREATE-FILE works as well as CREATE.FILE). Many commands just fail instead of working in a default state. Hope this is at all interesting. Bill <Bill's Comments End> Bill, thanks again for your review of UD vs. UV. Dave Dave Taylor President Sysmark Information Systems, Inc. 49 Aspen Way Rolling Hills Estates, CA 90274 800-SYSMARK (800-797-6275) (O) 310-544-1974 (C) 310-561-5200 (P) 800-339-1497 (F) 310-377-3550 Your Source for Integrated EDI Translation and DataSync Integration www.sysmarkinfo.com ----- Original Message ----- From: "David Wolverton" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, March 17, 2006 6:13 AM Subject: RE: [U2] [UD] Triggers <snip> ------- 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/
