Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified)
Most often we don't really know if customers rely on a particular behavior in the product. When UniData has behaved in a particular manner for many years, we hesitate to just change the behavior in some cases. We have been surprised more than once when we did change behavior without providing an option and found that customers had coded around the product behavior and had their application 'break' upon upgrading to a new UniData release. Wally Terhune Technical Support Engineer Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR Sent: Thursday, October 04, 2012 8:45 PM To: U2 Users List Subject: Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified) At a guess, an important customer relies on the behaviour that the option turns off and lost the argument about whether this was a feature-not-a-bug rather than a bug-not-a-feature Regards Mike -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, 5 October 2012 3:19 p.m. To: U2 Users List Subject: [U2] [UD] Odd question re: 7.1 docs I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 16:43 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
Will and Brian, I had a similar experience. I indexed a file that had over a million records with the same code. All was ok for a couple of hours and then Universe crashed with something like out of string space. It was ugly! Had this worked, it would have been a great benefit but . I expermented with combining 3 attributes to reduce the max count to around 100,000 but the boss isn't willing to try again. Don Robinson --- From: Brian Leach br...@brianleach.co.uk To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Friday, October 5, 2012 8:59 AM Subject: Re: [U2] Consuming Web Services Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 16:43 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services
The first part is relatively trivial for a person of my level of genius :) The second part is so utterly Byzantine and unfathomable (and redundant apparently) that I would never even make the attempt. What Rocket adopts and also what they discard, has never been comprehendable. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. -Original Message- From: Brian Leach br...@brianleach.co.uk To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Fri, Oct 5, 2012 5:59 am Subject: Re: [U2] Consuming Web Services Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: 04 October 2012 16:43 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Consuming Web Services ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming web services
Hi, If I understand correctly, you're asking how the data embedded in the xml gets parsed out and written to a uv file, correct? If so, we use a uv function called XMLTODB, it's in the bp of the uv account. We accept orders from college book stores and we do that by consuming their web services. We use XMLTODB and the XMAP api to parse out the data that writes to our uv file. Works great. We've been using it for a few years now. I know we all hate documentation, but it is well documented in the BasicExt pdf. HTH, rudy Message: 2 Date: Wed, 03 Oct 2012 14:56:05 -0600 From: Jeff Schasny jscha...@gmail.commailto:jscha...@gmail.com To: U2-Users@listserver.u2ug.orgmailto:U2-Users@listserver.u2ug.org Subject: [U2] Consuming web services Message-ID: 506ca665.5020...@gmail.commailto:506ca665.5020...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed I know we have both the SOAP and RESTful web services development for publishing web services from Universe but how are folks consuming other peoples web services into the database? Are there tools for this or am I going to just open a socket, read, and parse 'till I'm blue in the face? Are you a fan of SAGE? Show us at www.facebook.com/SAGEPublicationshttp://www.facebook.com/SAGEPublications. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services (U2 Indexing)
Brian: I was under the impression that UniData uses a real B-Tree indexing system while UniVerse uses some kind of linked list. e.g. UV has a single item for, say, male/female and the item would look like ID: male 001 1]2]3]4]5]6]...]999 ...which would perform exactly as you say. I don't think UniData performs that way at all. Bill - Original Message - *From:* br...@brianleach.co.uk *To:* 'U2 Users List' u2-users@listserver.u2ug.org *Date:* 10/5/2012 5:59 AM *Subject:* Re: [U2] Consuming Web Services Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services (U2 Indexing)
Bill I *did* say UniVerse specific :) Yes, it uses a really nice and well-designed B+Tree for the index keys but once you're down to the data (the primary keys) they are stored in a regular record format with @FM between each key. You can see that easily enough as you can create a pointer to the INDEX.nnn record and just read/write it like any other type 25 file. Which is lots of luurrvvelley out of line record blocks to fill up when you do an insertion into the middle of a huge index list. Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: 05 October 2012 17:15 To: U2 Users List Subject: Re: [U2] Consuming Web Services (U2 Indexing) Brian: I was under the impression that UniData uses a real B-Tree indexing system while UniVerse uses some kind of linked list. e.g. UV has a single item for, say, male/female and the item would look like ID: male 001 1]2]3]4]5]6]...]999 ...which would perform exactly as you say. I don't think UniData performs that way at all. Bill - Original Message - *From:* br...@brianleach.co.uk *To:* 'U2 Users List' u2-users@listserver.u2ug.org *Date:* 10/5/2012 5:59 AM *Subject:* Re: [U2] Consuming Web Services Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Consuming Web Services (U2 Indexing)
Gives you a sort of Dilbert like impression that at the end of the project, once all the B tree bugs were worked out, they were shouting Just make it work, we'll make it better next version! Only next version never came. Yes Brian a B-tree on a B-tree probably makes the most sense from a beautiful standpoint. You could also put a B-tree on top of a dynamic file or even a B-tree on top of a Pascal-like-linked-list (not a UV multi-valued list as it is presently). No reason why you couldn't code true linked lists into uv, and they don't have issues with insertion-in-the-middle, you just break the chain, insert, and reset the forward and backward pointers. The most you're rewriting, is your item or group if you use a block concept, not the entire list as your example here. So yeah it could be done. It's conceptually not hard. Now get Rocket to put some money into the budget for that. -Original Message- From: Brian Leach br...@brianleach.co.uk To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Fri, Oct 5, 2012 9:25 am Subject: Re: [U2] Consuming Web Services (U2 Indexing) Bill I *did* say UniVerse specific :) Yes, it uses a really nice and well-designed B+Tree for the index keys but once you're down to the data (the primary keys) they are stored in a regular record format with @FM between each key. You can see that easily enough as you can create a pointer to the INDEX.nnn record and just read/write it like any other type 25 file. Which is lots of luurrvvelley out of line record blocks to fill up when you do an insertion into the middle of a huge index list. Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: 05 October 2012 17:15 To: U2 Users List Subject: Re: [U2] Consuming Web Services (U2 Indexing) Brian: I was under the impression that UniData uses a real B-Tree indexing system while UniVerse uses some kind of linked list. e.g. UV has a single item for, say, male/female and the item would look like ID: male 001 1]2]3]4]5]6]...]999 ...which would perform exactly as you say. I don't think UniData performs that way at all. Bill - Original Message - *From:* br...@brianleach.co.uk *To:* 'U2 Users List' u2-users@listserver.u2ug.org *Date:* 10/5/2012 5:59 AM *Subject:* Re: [U2] Consuming Web Services Will I don't understand what's wrong with indexing, can you clarify this point, and I'll wipe out a fix in three days :) Well for a start I didn't say there's anything wrong, I said it could be improved - not the same thing! But as to specifics, take the following scenario (UniVerse specific): - Grab a transaction file for say, 10 million records. - Assume a reasonable key length say 10 chars. - Add a field with two states (open/closed, male/female, that kind of thing). - Index it, and watch what happens to the performance on that file. - Better still, don't use an existing file! Create a new file and a program to copy or build the content in basic and show a counter every 1000 records. At the start it will be quick. After about 500,000 you can grab a beer in between the counters. The problem is, that a UniVerse index is very good at establishing the index key: it has a nice B+tree format with a decent level of fan-out. But when it comes to the list of primary keys being indexed against each index key, that's really just treated as a block of data. If you have a good ratio with a lot of index keys (date*type*something_else) each of which gives a relatively short list of primary keys you can get very good indexing performance. But it isn't very clever when you have a small number of index keys to a large list of primary keys. So every time you changed the flag value in the file above it would have to load up the two lists (one for old value, one for new), locate and delete from the old and locate/fail/append to the new, each list averaging 11 byte * 5 million entries. And then write it back to a succession of oversize blocks in the index file. Now you might say - well, you wouldn't index a transaction file like that. And you would be right - because of the design of the index. But it's a perfectly legitimate and reasonable thing to want to do. How to better manage a large index list is, of course, the question. Since it is a large list into which elements are potentially inserted/deleted in order, the list itself could be made into a set of B+Tree pages over a certain threshold, reducing the cost of location/insertion and location/deletion. Other databases use techniques such as key deltas and compression to alleviate this. And I'm sure there are better options if I could be bothered to research them. So there you go, Will. Your job for the weekend. Redesign the UniVerse indexing so it works for large lists, and get Rocket to adopt it. :) Brian
Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified)
Ah, makes sense. Thanks! On Fri, Oct 5, 2012 at 6:20 AM, Wally Terhune wterh...@rocketsoftware.comwrote: Most often we don't really know if customers rely on a particular behavior in the product. When UniData has behaved in a particular manner for many years, we hesitate to just change the behavior in some cases. We have been surprised more than once when we did change behavior without providing an option and found that customers had coded around the product behavior and had their application 'break' upon upgrading to a new UniData release. Wally Terhune Technical Support Engineer Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA t: +1 720 475 8055 **e: wterh...@rocketsoftware.com **w: rocketsoftware.com/u2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of HENDERSON MIKE, MR Sent: Thursday, October 04, 2012 8:45 PM To: U2 Users List Subject: Re: [U2] [UD] Odd question re: 7.1 docs (Unclassified) At a guess, an important customer relies on the behaviour that the option turns off and lost the argument about whether this was a feature-not-a-bug rather than a bug-not-a-feature Regards Mike -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, 5 October 2012 3:19 p.m. To: U2 Users List Subject: [U2] [UD] Odd question re: 7.1 docs I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Odd question re: 7.1 docs
I have talked to programmers at conferences and places like that, and some of them have utilitized techniques like that to ensure that their bills are paid on time...(smile)... Robert Norman On 10/4/2012 7:18 PM, Kevin King wrote: I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] Odd question re: 7.1 docs
I have talked to programmers at conferences and places like that, and some of them have utilized techniques like that to ensure that their bills are paid on time...(smile)... Robert Norman On 10/4/2012 7:18 PM, Kevin King wrote: I just found this in the UDT.OPTIONS manual... If UDT.OPTIONS 107 is off, UniData returns incorrect multivalues from the target file. Here's my question. With that description in mind, why would anyone want this to be off? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
