Re: [U2] Dymanic vs Dimenssioned
In a message dated 5/13/2005 2:00:51 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: > I believe the > upshot was, bowing to Yogi Berra on his 80th, that the difference ain't what > > it used to be. > True and false. If you are processing, sequentially, elements of a list then it probably makes no difference. However most UPDATE programs actually touch elements in a semi-random fashion. So you might have something like Inventory(3) = price Inventory(10) = onhand Inventory(21) = lastpo This type of update, not being in order, would exhibit much greater speed than the same update using a dynamic array. That being said, it's possible that the majority of an UPDATE type process isn't actually pushing values into cells, but doing lots of other things that changing the type of array would not affect. But simply saying that it makes no difference in any case is not true. Will Johnson Fast Forward Technologies --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandary, any suggestions...
> REC(0) references a dimensioned array and, apparently, in UV holds all > fields that could not fit into the dimension of the array. > UniData does > not work this way, it puts it into the last dimension of the > array which > could result in data loss if you change that array position. We have > confirmed this on our system as we are faced with the same problem. > -- > Here is a question to the group. Is this a behaviour in UD that can be > changed in a configuration setting? Again, as with UV, UD is emulation dependant on this. Basictype 'u' and 'm' use element (0,0) IIRC, while 'p' and 'r' put the data at the end, or simply truncate it - I can't remember. If for some reason you need to operate your account with BASICTYPE 'p', then you can always drop a 'BASICTYPE "u"' statement into the top of a program you want to behave sensibly. HTH, Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Dymanic vs Dimenssioned
On May 13, 2005, at 4:38 PM, Kevin King wrote: From: Clifton Oliver "Always remember that you should never believe any rule containing the words 'always' or 'never'". --- Or as I say in my classes now... "There's a time and place for everything, and it's not always and not never". I would have used yours Clif, but if I follow the rule I can't believe it. ;-) -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com I was always amused to see which ones caught that and which ones just wrote it down in their notes. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Dymanic vs Dimenssioned
From: Clifton Oliver "Always remember that you should never believe any rule containing the words 'always' or 'never'". --- Or as I say in my classes now... "There's a time and place for everything, and it's not always and not never". I would have used yours Clif, but if I follow the rule I can't believe it. ;-) -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 5/12/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Dymanic vs Dimenssioned
That is correct. I think it was at release 7, a "field cache" pointer was introduced. If you walk down a dynamic array thus for i = 1 to n fieldStuff = dynArray next i the run-machine does not re-scan from the beginning of the string. It moves down the string remembering where it was. The performance is almost as good as using REMOVE. So if you have a large record with a lot of fields and you are only going to use the first few fields, a READ and technique is faster than a MATREAD (which is basically a READ followed by a MATPARSE). I think they tweeked this some more at release 8 to include backward referencing and some other tricks. So are dimensioned arrays better than dynamic arrays, or the reverse? It depends on the situation, the data, the statistical likelihood of certain string lengths, whether or not it is an even numbered Tuesday that falls on the 23rd day of the Feast of the Goddess Eris, and who knows what else. Then things change at each release and everything we know, is wrong. It's like I used to tell my students when I was teaching the BASIC programming classes: "Always remember that you should never believe any rule containing the words 'always' or 'never'". -- Regards, Clif ~~~ W. Clifton Oliver, CCP CLIFTON OLIVER & ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com ~~~ On May 13, 2005, at 1:52 PM, Dan Fitzgerald wrote: Do we have archives somewhere? IIRC correctly, Glenn Herbert posted a great description of dynamic array optimization some time ago. I believe the upshot was, bowing to Yogi Berra on his 80th, that the difference ain't what it used to be. "Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them?" - H.H. the Dalai Lama "When buying & selling are controlled by legislation, the first thing to be bought & sold are the legislators" - P.J. O'Rourke Dan Fitzgerald From: "Marilyn Hilb" <[EMAIL PROTECTED]> Reply-To: u2-users@listserver.u2ug.org To: Subject: RE: [U2] Dymanic vs Dimenssioned Date: Fri, 13 May 2005 15:40:17 -0500 I am by far from a 'smart person'. But when I was first learning I was told if you were only going to use values in the first few a/m or if was simply a short item, less than 10 or so a/m then you can use dynamic. Anything more than that use dimensioned. If you are going to use say a/m 50 and you use a dynamic array, every time it actually has to start at <1> and work through to find <50>. Were if you use a dimensioned array it will go straight to (50). I was shown a nifty table when learning this where it showed all the values the program uses being put into buckets. If you use a dynamic read, it all goes into one bucket. If you use Dimensioned it each goes into it's own bucket. This is my 'simple' minded understanding. I am sure many more answers will be posted on this topic. Thanks, Marilyn A. Hilb Value Part, Inc Direct: 847-918-6099 Fax: 847-367-1892 [EMAIL PROTECTED] www.valuepart.com -Original Message- From: Stevenson, Charles [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 2:50 PM To: u2-users@listserver.u2ug.org Subject:RE: [U2] I'm in an Array quandry, any suggestions... Maybe the Smart People on this list can give a good rule of thumb for deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these years, I still don't have one. From: Richard Taylor > > We are faced with this same situation and the thought behind this > truly baffles me. I will admit to some of the same bafflement. > Why take a flexible, dynamic database system The syntax for dynamic arrays is more natural for the language, too (e.g., XYZ(17)<1,5> vs. XYZ<17,5>). Readability makes for maintainability, generally the most important contributor to software quality. > and force it to be fixed length. well, sorta. Each element of the dimensioned array is a variable length dynamic array. ( See my previous post for how to complicate your life by inserting attribute marks. ) > This is what you are doing using dimensioned arrays and MATREADs. The most > common justification I have heard is performance and this simply does not hold > water. Within limits (but I don't know the limits). If you have a program that manipulates many attributes many times, then it makes sense to matread them into a dimensioned array up front, and matwrite them in the end, thereby limiting big string manipulations. People forget or newbies don't know that CUST.REC<117> is really EXTRACT( CUST.REC, 117,0,0) or REPLACE(...,CUST.REC,117,0,0). That can be very expensive when you do that for many attributes many times, with large dynamic arrays. By contrast, each dimensioned array element has its own memory address, so references and assignments can jump straight to it. But I do not have a good appreciation for what "limits", "many", "big" really mean in my previo
RE: [U2] I'm in an Array quandry, any suggestions...
"Scott Ballinger" <[EMAIL PROTECTED]> wrote on 05/13/2005 05:10:49 PM: > In UV at least (not sure about UD) attribute processing has improved > dramatically since "the old days," to the point where it is essentially > instant. When you're going sequentially through a dynamic array, that is true. Change your code to reference the elements randomly, and I predict you'll see a huge difference between dynamic and dimensioned. In most real-life programs, you'll see it pull something from attribute 23, then something from attribute 7, and something else from attribute 97. In my experience, it's rare that you see something neatly step through an array. I do agree with others that "it depends". It depends not only on how many attributes are in the file, but how big those attributes are. Unfortunately, it's pretty common to put name and address information - usually pretty beefy and infrequently accessed stuff - at the beginning of the record, while smaller and more frequently accessed stuff is after it. That means you're parsing through the bytes comprising the names and addresses many times. I recently helped a customer with their performance problems. They had some very large records that were being referenced in a batch process. Whenever this process was run, CPU idle time went to zero and the system ground to a halt. By changing the reference to dimensioned rather than dynamic, the process sped up drastically and CPU became almost completely idle. Changing a few lines of code made a huge difference, not only to this program, but system-wide. This customer was running a recent release of UniVerse, so it had nothing to do with the parsing changes (which were added a long time ago anyway). I have many other real-life stories just like this on UniData and UniVerse. For small records where you're plucking or stuffing a few bits of information, dynamic arrays will do the job. But dimensioned arrays definitely have their place. Hardware delivers much more bang for the buck than just a few years back, but inefficiencies have a way of catching up with you. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Archives (was RE: [U2] Dymanic vs Dimenssioned)
Dan Fitzgerald wrote: > > Do we have archives somewhere? > If it's fairly recent, (since Jan 2005?) mail-archive.com should have it: http://www.mail-archive.com/u2-users%40listserver.u2ug.org/ This one goes back further, but the search doesn't work as well: http://www.indexinfocus.com/ -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Richard Taylor wrote: >> Certainly not enough to justify throwing away one of the >> best features of the Pick database, or having to code >> work-arounds to deal with the short-comings of dimensioned >> arrays. I'm maintaining a system that was originally developed on Prime Information in the mid-80's, when performance between dimensioned and dynamic arrays WAS an issue. It uses dimensioned arrays and matread/matwrite, but the way it was designed, none of the "short-comings" you mention are really an issue. Every file in the system has an abbreviated name. For example, the abbreviation for the customer master file (CUST.MST) is CM. There is a utility program that selects every 'D' item from the dictionary, and builds an $INCLUDE file for all or selected files, named "DIM.(filename)" (eg DIM.CUST.MST). This DIM.xx file is included in every program that needs to access the customer master file, and includes the following statements: DIM D.CM(X) ; MAT D.CM = '';* Where X = number of fields in the file EQU CM.CUST.NAME TO D.CM(1) ... And so forth for every field in the file NOWHERE in any of the code is the customer name referenced as D.CM(1) or CM<1> or anything similar. It is ALWAYS referenced as CM.CUST.NAME. Sub-valued fields are refenced as CM.ADDR<1,x>, for example. As new fields are added to the file, the inserts are re-created. Because "extra" fields are stored as a dynamic array in D.CM(0), programs that don't use the new fields don't need to be recompiled. Yes, I realize that the same thing can be accomplished with dynamic arrays (ie EQU CM.CUST.NAME TO CM<1>), but as I mentioned in the beginning of this post, this software was originally written back when there WAS a performance difference between using dimensioned vs dynamic arrays ... At least that's what the conventional wisdom told us at the time. Larry Hiscock Western Computer Services --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Dymanic vs Dimenssioned
I was also taught the same thing, back in the day. But, I think nowadays, what with the faster processor and disk speeds, it doesn't really matter that much anymore. About 15 years ago, working on a Sequoia, it was proven that by using dimensioned arrays for reads and writes in a OLTP system, a huge speed gain was realized over the use of dynamic arrays. Now on Sun boxen and UV we don't use dimensioned arrays anymore. We've found that for ease of software maintenance, dynamic arrays are the best fit for us. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 05/13/2005 04:40:17 PM: > I am by far from a 'smart person'. But when I was first learning I > was told if you were only going to use values in the first few a/m > or if was simply a short item, less than 10 or so a/m then you can > use dynamic. Anything more than that use dimensioned. > If you are going to use say a/m 50 and you use a dynamic array, > every time it actually has to start at <1> and work through to find > <50>. Were if you use a dimensioned array it will go straight to > (50). I was shown a nifty table when learning this where it showed > all the values the program uses being put into buckets. If you use a > dynamic read, it all goes into one bucket. If you use Dimensioned it > each goes into it's own bucket. > This is my 'simple' minded understanding. I am sure many more > answers will be posted on this topic. > Thanks, > Marilyn A. Hilb > Value Part, Inc > Direct: 847-918-6099 > Fax: 847-367-1892 > [EMAIL PROTECTED] > www.valuepart.com > -Original Message- > From: Stevenson, Charles [mailto:[EMAIL PROTECTED] > Sent: Friday, May 13, 2005 2:50 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] I'm in an Array quandry, any suggestions... > Maybe the Smart People on this list can give a good rule of thumb for > deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these > years, I still don't have one. [snip] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
In UV at least (not sure about UD) attribute processing has improved dramatically since "the old days," to the point where it is essentially instant. Try this: > >CT BP ATTRIBUTE.TEST ATTRIBUTE.TEST 0001 * test attributes vs values in large array 0002 * 05-12-05 asb 0003 0004 DIM DLIST(1) 0005 FOR N = 1 TO 1 0006 DLIST(N) = N 0007 NEXT N 0008 0009 PRINT "COUNTING DIMS.": 0010 T = SYSTEM(9) 0011 FOR N = 9000 TO 1 0012 X = DLIST(N) 0013 NEXT N 0014 PRINT SYSTEM(9)-T 0015 0016 LIST = "" 0017 FOR N = 1 TO 1 0018 LIST = N 0019 NEXT N 0020 0021 PRINT "COUNTING ATTRIBUTES...": 0022 T = SYSTEM(9) 0023 FOR N = 9000 TO 1 0024 X = LIST 0025 NEXT N 0026 PRINT SYSTEM(9)-T 0027 0028 0029 CONVERT @AM TO @VM IN LIST 0030 PRINT "COUNTING VALUES...": 0031 T = SYSTEM(9) 0032 FOR N = 9000 TO 1 0033 X = LIST<1,N> 0034 NEXT N 0035 PRINT SYSTEM(9)-T 0036 > >RUN BP ATTRIBUTE.TEST COUNTING DIMS.0 COUNTING ATTRIBUTES...0 COUNTING VALUES...280 >.X 01 RUN BP ATTRIBUTE.TEST COUNTING DIMS.0 COUNTING ATTRIBUTES...0 COUNTING VALUES...250 >.X 01 RUN BP ATTRIBUTE.TEST COUNTING DIMS.0 COUNTING ATTRIBUTES...0 COUNTING VALUES...240 >.X 01 RUN BP ATTRIBUTE.TEST COUNTING DIMS.0 COUNTING ATTRIBUTES...0 COUNTING VALUES...250 >.L RELLEVEL RELLEVEL 001 X 002 9.6.1.14 003 PICK 004 PICK.FORMAT 005 9.6.1.14 It seems to me that the speed advantages of dimensioned arrays are no longer valid. BTW, converting VMs to AMs in even the largest array (like 100,000 elements) is nearly instant, and the speed benefits of processing attributes vs values is so large that if you have old applications that have VM delimited lists (I used to structure lists that way) you should (if possible) convert to AMs first, then convert back to VMs before putting the data back. Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Glenfield Sent: Friday, May 13, 2005 12:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] I'm in an Array quandry, any suggestions... >Have you ever compared performance between dynamic and dimensioned >arrays, >or are you just saying that you've never notice problems but have never >tried dimensioned arrays? I've seen it make a HUGE difference in Pick, >UniVerse, and UniData. If you reference many elements of a dynamic array >many times, you'll burn a lot of CPU cycles just to locate the data. When >you reference an element of a dimensioned array, it's stored in separate >address space, and is immediately referenced. > >I have a standard way to avoid problems with the last attribute folding >into the highest array element. Just dimension the array one element >larger than the highest attribute you reference in the program. So if the >highest attribute you reference is number 72, dimension the array at 73 or >higher. Where I used to work, we had an automated process that created >file definitions, including standard equates and the code to dimension >arrays. We always created the arrays at one more than the highest >attribute, and never had problems. This won't be necessary in >environments where the extra attributes are placed on element zero, but it >won't hurt anything, either. That way your code will be portable. > > > Payback during 2nd generation Pick was 10-20 attributes. Back then, the problem was to not oversize because it slowed down the read/writing of the blank attributes. Didn't we hear/read recently that the new compiler and/or run time machine is keeping track of individual attribute marks in dynamic arrays, so that a full string search is not necessary every time? Roger --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Yes I have compared the performance. Within the ERP system I worked in we saw little difference. Yes dimensioned arrays MAY have some advantage under certain circumstances, but reading and accessing fields in a record is not one of them. Certainly not enough to justify throwing away one of the best features of the Pick database, or having to code work-arounds to deal with the short-comings of dimensioned arrays. Again I am referring to the use of MATREADS and WRITES primarily here. When you do this the dim'd array only provides any benefits when accessing fields. When you get to dealing with value and sub-value mark separated data you are back to the 'slower' text extraction. I generally don't like using dimensioned arrays at all, but outside of handling actual record structures they do have their uses. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 13, 2005 2:54 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] I'm in an Array quandry, any suggestions... Richard Taylor <[EMAIL PROTECTED]> wrote on 05/13/2005 02:05:51 PM: > ... Why take a flexible, dynamic database system and force it to > be fixed length. This is what you are doing using dimensioned arrays and > MATREADs. The most common justification I have heard is performance and > this simply doe not hold water. Have you ever compared performance between dynamic and dimensioned arrays, or are you just saying that you've never notice problems but have never tried dimensioned arrays? I've seen it make a HUGE difference in Pick, UniVerse, and UniData. If you reference many elements of a dynamic array many times, you'll burn a lot of CPU cycles just to locate the data. When you reference an element of a dimensioned array, it's stored in separate address space, and is immediately referenced. I have a standard way to avoid problems with the last attribute folding into the highest array element. Just dimension the array one element larger than the highest attribute you reference in the program. So if the highest attribute you reference is number 72, dimension the array at 73 or higher. Where I used to work, we had an automated process that created file definitions, including standard equates and the code to dimension arrays. We always created the arrays at one more than the highest attribute, and never had problems. This won't be necessary in environments where the extra attributes are placed on element zero, but it won't hurt anything, either. That way your code will be portable. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Dymanic vs Dimenssioned
Do we have archives somewhere? IIRC correctly, Glenn Herbert posted a great description of dynamic array optimization some time ago. I believe the upshot was, bowing to Yogi Berra on his 80th, that the difference ain't what it used to be. "Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them?" - H.H. the Dalai Lama "When buying & selling are controlled by legislation, the first thing to be bought & sold are the legislators" - P.J. O'Rourke Dan Fitzgerald From: "Marilyn Hilb" <[EMAIL PROTECTED]> Reply-To: u2-users@listserver.u2ug.org To: Subject: RE: [U2] Dymanic vs Dimenssioned Date: Fri, 13 May 2005 15:40:17 -0500 I am by far from a 'smart person'. But when I was first learning I was told if you were only going to use values in the first few a/m or if was simply a short item, less than 10 or so a/m then you can use dynamic. Anything more than that use dimensioned. If you are going to use say a/m 50 and you use a dynamic array, every time it actually has to start at <1> and work through to find <50>. Were if you use a dimensioned array it will go straight to (50). I was shown a nifty table when learning this where it showed all the values the program uses being put into buckets. If you use a dynamic read, it all goes into one bucket. If you use Dimensioned it each goes into it's own bucket. This is my 'simple' minded understanding. I am sure many more answers will be posted on this topic. Thanks, Marilyn A. Hilb Value Part, Inc Direct: 847-918-6099 Fax: 847-367-1892 [EMAIL PROTECTED] www.valuepart.com -Original Message- From: Stevenson, Charles [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 2:50 PM To: u2-users@listserver.u2ug.org Subject:RE: [U2] I'm in an Array quandry, any suggestions... Maybe the Smart People on this list can give a good rule of thumb for deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these years, I still don't have one. From: Richard Taylor > > We are faced with this same situation and the thought behind this > truly baffles me. I will admit to some of the same bafflement. > Why take a flexible, dynamic database system The syntax for dynamic arrays is more natural for the language, too (e.g., XYZ(17)<1,5> vs. XYZ<17,5>). Readability makes for maintainability, generally the most important contributor to software quality. > and force it to be fixed length. well, sorta. Each element of the dimensioned array is a variable length dynamic array. ( See my previous post for how to complicate your life by inserting attribute marks. ) > This is what you are doing using dimensioned arrays and MATREADs. The most > common justification I have heard is performance and this simply does not hold > water. Within limits (but I don't know the limits). If you have a program that manipulates many attributes many times, then it makes sense to matread them into a dimensioned array up front, and matwrite them in the end, thereby limiting big string manipulations. People forget or newbies don't know that CUST.REC<117> is really EXTRACT( CUST.REC, 117,0,0) or REPLACE(...,CUST.REC,117,0,0). That can be very expensive when you do that for many attributes many times, with large dynamic arrays. By contrast, each dimensioned array element has its own memory address, so references and assignments can jump straight to it. But I do not have a good appreciation for what "limits", "many", "big" really mean in my previous paragraph. Does anyone have a good heuristic? > I started in Pick in R83 and have never used a dimensioned array to > hold record structure and I have not seen performance issues. This to the > extent that we ran an MRP run on a 286 Wyse PC that choked the mainframe at > this company. Ah-ha, my dear Watson, then you don't really know how that system would have screamed if you'd used dimensioned arrays instead, do you? > > "The more they complicate the plumbing > the easier it is to stop up the drain" Yeah. What I said about dynamic array syntax being more natural. cds P.S. Why are we limited to 1- or 2-dimensioned arrays? E.g., DIM XYZ( 5,10,2,3,8 ) would be a 5-dimensional array. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Saying that MATREAD/MATWRITE improves performance without any other context is misleading. Yes, MATREAD/MATWRITE _can_ improve performance but it isn't a cure all for performance problems. In programs where there is a lot of dynamic array manipulation (extraction, replacement, insertion, deletion) of later attributes (let's say > 50 as a very rough example) using dimensioned arrays can improve the performance of repeated references to those attributes. Then again, would you consider something like the following to be good code? FOR LINE.LOOP = 1 TO LINE.CNT IF RECORD<50,LINE.LOOP> = 'C' THEN (or alternatively) IF RECORD(50)<1,LOOP.LOOP> = 'C' THEN ...requisite END and NEXT to follow Given this situation specifically, the dimensioned array will perform better than the dynamic due to the repetitive extraction from the 50th attribute. But that doesn't mean the dimensioned array is the best solution! Instead, the code could be written more effectively to use the flexibility (and syntactic simplicity) of dynamic arrays and still perform as well. LINE.STATUS.CDS = RECORD<50> FOR LINE.LOOP = 1 TO LINE.CNT IF LINE.STATUS.CDS<1,LINE.LOOP> = 'C' THEN requisite END and NEXT to follow In fact, it might even perform better. See, the dimensioned arrays work faster because you're never working with more than a single attribute at a time in any dimension position (with the exception of the situation where you're MATREADing into an array that's undersized). That makes access to any specific attribute very, very fast. Extracting an attribute from a dynamic array into a local variable mimics what happens with the MATREAD, but without the overhead of parsing all attributes into individual variables (as there would be with MATREAD) so all other things being equal, this might actually produce faster code with dynamic arrays than with dimensioned. The equalizer will be the number of extractions and replacements w/ the dynamic array. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Friday, May 13, 2005 1:50 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] I'm in an Array quandry, any suggestions... Maybe the Smart People on this list can give a good rule of thumb for deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these years, I still don't have one. From: Richard Taylor > > We are faced with this same situation and the thought behind this > truly baffles me. I will admit to some of the same bafflement. > Why take a flexible, dynamic database system The syntax for dynamic arrays is more natural for the language, too (e.g., XYZ(17)<1,5> vs. XYZ<17,5>). Readability makes for maintainability, generally the most important contributor to software quality. > and force it to be fixed length. well, sorta. Each element of the dimensioned array is a variable length dynamic array. ( See my previous post for how to complicate your life by inserting attribute marks. ) > This is what you are doing using dimensioned arrays and MATREADs. The most > common justification I have heard is performance and this simply does not hold > water. Within limits (but I don't know the limits). If you have a program that manipulates many attributes many times, then it makes sense to matread them into a dimensioned array up front, and matwrite them in the end, thereby limiting big string manipulations. People forget or newbies don't know that CUST.REC<117> is really EXTRACT( CUST.REC, 117,0,0) or REPLACE(...,CUST.REC,117,0,0). That can be very expensive when you do that for many attributes many times, with large dynamic arrays. By contrast, each dimensioned array element has its own memory address, so references and assignments can jump straight to it. But I do not have a good appreciation for what "limits", "many", "big" really mean in my previous paragraph. Does anyone have a good heuristic? > I started in Pick in R83 and have never used a dimensioned array to > hold record structure and I have not seen performance issues. This to the > extent that we ran an MRP run on a 286 Wyse PC that choked the mainframe at > this company. Ah-ha, my dear Watson, then you don't really know how that system would have screamed if you'd used dimensioned arrays instead, do you? > > "The more they complicate the plumbing > the easier it is to stop up the drain" Yeah. What I said about dynamic array syntax being more natural. cds P.S. Why are we limited to 1- or 2-dimensioned arrays? E.g., DIM XYZ( 5,10,2,3,8 ) would be a 5-dimensional array. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 5/12/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Ve
RE: [U2] Dymanic vs Dimenssioned
I am by far from a 'smart person'. But when I was first learning I was told if you were only going to use values in the first few a/m or if was simply a short item, less than 10 or so a/m then you can use dynamic. Anything more than that use dimensioned. If you are going to use say a/m 50 and you use a dynamic array, every time it actually has to start at <1> and work through to find <50>. Were if you use a dimensioned array it will go straight to (50). I was shown a nifty table when learning this where it showed all the values the program uses being put into buckets. If you use a dynamic read, it all goes into one bucket. If you use Dimensioned it each goes into it's own bucket. This is my 'simple' minded understanding. I am sure many more answers will be posted on this topic. Thanks, Marilyn A. Hilb Value Part, Inc Direct: 847-918-6099 Fax: 847-367-1892 [EMAIL PROTECTED] www.valuepart.com -Original Message- From: Stevenson, Charles [mailto:[EMAIL PROTECTED] Sent: Friday, May 13, 2005 2:50 PM To: u2-users@listserver.u2ug.org Subject:RE: [U2] I'm in an Array quandry, any suggestions... Maybe the Smart People on this list can give a good rule of thumb for deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these years, I still don't have one. From: Richard Taylor > > We are faced with this same situation and the thought behind this > truly baffles me. I will admit to some of the same bafflement. > Why take a flexible, dynamic database system The syntax for dynamic arrays is more natural for the language, too (e.g., XYZ(17)<1,5> vs. XYZ<17,5>). Readability makes for maintainability, generally the most important contributor to software quality. > and force it to be fixed length. well, sorta. Each element of the dimensioned array is a variable length dynamic array. ( See my previous post for how to complicate your life by inserting attribute marks. ) > This is what you are doing using dimensioned arrays and MATREADs. The most > common justification I have heard is performance and this simply does not hold > water. Within limits (but I don't know the limits). If you have a program that manipulates many attributes many times, then it makes sense to matread them into a dimensioned array up front, and matwrite them in the end, thereby limiting big string manipulations. People forget or newbies don't know that CUST.REC<117> is really EXTRACT( CUST.REC, 117,0,0) or REPLACE(...,CUST.REC,117,0,0). That can be very expensive when you do that for many attributes many times, with large dynamic arrays. By contrast, each dimensioned array element has its own memory address, so references and assignments can jump straight to it. But I do not have a good appreciation for what "limits", "many", "big" really mean in my previous paragraph. Does anyone have a good heuristic? > I started in Pick in R83 and have never used a dimensioned array to > hold record structure and I have not seen performance issues. This to the > extent that we ran an MRP run on a 286 Wyse PC that choked the mainframe at > this company. Ah-ha, my dear Watson, then you don't really know how that system would have screamed if you'd used dimensioned arrays instead, do you? > > "The more they complicate the plumbing > the easier it is to stop up the drain" Yeah. What I said about dynamic array syntax being more natural. cds P.S. Why are we limited to 1- or 2-dimensioned arrays? E.g., DIM XYZ( 5,10,2,3,8 ) would be a 5-dimensional array. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Maybe the Smart People on this list can give a good rule of thumb for deciding when to READU/WRITE vs. MATREADU/MATWRITE. After all these years, I still don't have one. From: Richard Taylor > > We are faced with this same situation and the thought behind this > truly baffles me. I will admit to some of the same bafflement. > Why take a flexible, dynamic database system The syntax for dynamic arrays is more natural for the language, too (e.g., XYZ(17)<1,5> vs. XYZ<17,5>). Readability makes for maintainability, generally the most important contributor to software quality. > and force it to be fixed length. well, sorta. Each element of the dimensioned array is a variable length dynamic array. ( See my previous post for how to complicate your life by inserting attribute marks. ) > This is what you are doing using dimensioned arrays and MATREADs. The most > common justification I have heard is performance and this simply does not hold > water. Within limits (but I don't know the limits). If you have a program that manipulates many attributes many times, then it makes sense to matread them into a dimensioned array up front, and matwrite them in the end, thereby limiting big string manipulations. People forget or newbies don't know that CUST.REC<117> is really EXTRACT( CUST.REC, 117,0,0) or REPLACE(...,CUST.REC,117,0,0). That can be very expensive when you do that for many attributes many times, with large dynamic arrays. By contrast, each dimensioned array element has its own memory address, so references and assignments can jump straight to it. But I do not have a good appreciation for what "limits", "many", "big" really mean in my previous paragraph. Does anyone have a good heuristic? > I started in Pick in R83 and have never used a dimensioned array to > hold record structure and I have not seen performance issues. This to the > extent that we ran an MRP run on a 286 Wyse PC that choked the mainframe at > this company. Ah-ha, my dear Watson, then you don't really know how that system would have screamed if you'd used dimensioned arrays instead, do you? > > "The more they complicate the plumbing > the easier it is to stop up the drain" Yeah. What I said about dynamic array syntax being more natural. cds P.S. Why are we limited to 1- or 2-dimensioned arrays? E.g., DIM XYZ( 5,10,2,3,8 ) would be a 5-dimensional array. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] I'm in an Array quandry, any suggestions...
Timothy Snyder wrote: Richard Taylor <[EMAIL PROTECTED]> wrote on 05/13/2005 02:05:51 PM: ... Why take a flexible, dynamic database system and force it to be fixed length. This is what you are doing using dimensioned arrays and MATREADs. The most common justification I have heard is performance and this simply doe not hold water. Have you ever compared performance between dynamic and dimensioned arrays, or are you just saying that you've never notice problems but have never tried dimensioned arrays? I've seen it make a HUGE difference in Pick, UniVerse, and UniData. If you reference many elements of a dynamic array many times, you'll burn a lot of CPU cycles just to locate the data. When you reference an element of a dimensioned array, it's stored in separate address space, and is immediately referenced. I have a standard way to avoid problems with the last attribute folding into the highest array element. Just dimension the array one element larger than the highest attribute you reference in the program. So if the highest attribute you reference is number 72, dimension the array at 73 or higher. Where I used to work, we had an automated process that created file definitions, including standard equates and the code to dimension arrays. We always created the arrays at one more than the highest attribute, and never had problems. This won't be necessary in environments where the extra attributes are placed on element zero, but it won't hurt anything, either. That way your code will be portable. Payback during 2nd generation Pick was 10-20 attributes. Back then, the problem was to not oversize because it slowed down the read/writing of the blank attributes. Didn't we hear/read recently that the new compiler and/or run time machine is keeping track of individual attribute marks in dynamic arrays, so that a full string search is not necessary every time? Roger --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Richard Taylor <[EMAIL PROTECTED]> wrote on 05/13/2005 02:05:51 PM: > ... Why take a flexible, dynamic database system and force it to > be fixed length. This is what you are doing using dimensioned arrays and > MATREADs. The most common justification I have heard is performance and > this simply doe not hold water. Have you ever compared performance between dynamic and dimensioned arrays, or are you just saying that you've never notice problems but have never tried dimensioned arrays? I've seen it make a HUGE difference in Pick, UniVerse, and UniData. If you reference many elements of a dynamic array many times, you'll burn a lot of CPU cycles just to locate the data. When you reference an element of a dimensioned array, it's stored in separate address space, and is immediately referenced. I have a standard way to avoid problems with the last attribute folding into the highest array element. Just dimension the array one element larger than the highest attribute you reference in the program. So if the highest attribute you reference is number 72, dimension the array at 73 or higher. Where I used to work, we had an automated process that created file definitions, including standard equates and the code to dimension arrays. We always created the arrays at one more than the highest attribute, and never had problems. This won't be necessary in environments where the extra attributes are placed on element zero, but it won't hurt anything, either. That way your code will be portable. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
>> It really matters what flavor you're running. > >Which nobody has explained :-) Basic Ref for MATREAD says: "If the number of elements in array is greater than the number of fields in the record, the extra elements in array are assigned empty string values. If thenumber of fields in the record is greater than the number of elements in the array, the extra values are stored in the zero element of array for IDEAL or INFORMATION flavor accounts, or in the last element of array for PICK, IN2, or REALITY flavor accounts." For MATWRITE it says: "In IDEAL and INFORMATION flavor accounts, if the zero element of the array has been assigned a value by a MATREAD or MATREADU statement, the zero element value is written to the record as the n+1 field, where n is the number of elements dimensioned in the array. If the zero element is assigned an empty string, only the assigned elements of the array are written to the record; trailing empty fields are ignored. The new record is written to the file (replacing any existing record) without regard for the size of the array." You can force one behavior or the other by using $OPTIONS STATIC.DIM (Pick behavior) $OPTIONS -STATIC.DIM (Ideal behavior) in your program. ( To really screw up the poor programmer who maintans your code, you can switch between those 2 options multiple times through your program, treating some arrays one way, some another. ) And just to nitpick again, "n+1" in the MATWRITE text above is a bit misleading or wrong. Any given array element can be multi-ATTRIBUTEd, and that means that many attributes are inserted in the middle of the record being written. Example (any flavor): >CT CDS.BP M M 0001 OPEN "","VOC" TO F.VOC ELSE STOP 3000,"VOC" 0002 DIM REC(10) 0003 REC(1) = 1 0004 REC(2) = 2 0005 REC(2)<2> = 'B' 0006 REC(2)<3> = 'C' 0007 REC(3) = 'this aint <3>' 0008 MATWRITE REC TO F.VOC, 'CDS' >RUN CDS.BP M >CT VOC CDS CDS 0001 1 0002 2 0003 B 0004 C 0005 this aint <3> > Have we run this to ground yet? I don't even remember the original question. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
We are faced with this same situation and the thought behind this truly baffles me. Why take a flexible, dynamic database system and force it to be fixed length. This is what you are doing using dimensioned arrays and MATREADs. The most common justification I have heard is performance and this simply doe not hold water. I started in Pick in R83 and have never used a dimensioned array to hold record structure and I have not seen performance issues. This to the extent that we ran an MRP run on a 286 Wyse PC that choked the mainframe at this company. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Don't confuse Dimensioned (fixed) arrays with dynamic arrays. REC<0> is a dynamic array reference and would always return the entire record. REC(0) references a dimensioned array and, apparently, in UV holds all fields that could not fit into the dimension of the array. UniData does not work this way, it puts it into the last dimension of the array which could result in data loss if you change that array position. We have confirmed this on our system as we are faced with the same problem. -- Here is a question to the group. Is this a behavior in UD that can be changed in a configuration setting? Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. "The more they complicate the plumbing the easier it is to stop up the drain" - Montgomery Scott NCC-1701 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Clark Sent: Thursday, May 12, 2005 1:46 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] I'm in an Array quandry, any suggestions... Sometimes, REC<0> returns the entire string too. I ran into this once converting a program that actively used the assumption that REC<0> would return nothing. Having REC(0) reserved for overflow seems convenient though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, May 12, 2005 11:51 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] I'm in an Array quandry, any suggestions... I don't think MV participates with the OPTION BASE 0 or 1 that allows the use of REC(0) that VB etc does. MV tends to count things starting with 1 and MS starts with 0. REC<0> etc tends to be confusing as it's not the primary key either. I use OPTION BASE 1 to keep my head on straight when progamming in VB. My 1 cent. - Original Message - From: "George Gallen" <[EMAIL PROTECTED]> To: Sent: Thursday, May 12, 2005 12:04 PM Subject: RE: [U2] I'm in an Array quandry, any suggestions... > OK. ours is being stored in element zero. None of the programming use element > zero > so that is good. > > George > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] Behalf Of Brian Leach > >Sent: Thursday, May 12, 2005 11:36 AM > >To: u2-users@listserver.u2ug.org > >Subject: RE: [U2] I'm in an Array quandry, any suggestions... > > > > > >George, > > > >It really matters what flavor you're running. > > > >If you run a flavor that puts the overspill in element zero, > >you may be ok. > >If you run a flavor that puts the overspill into the last element, that > >might mess up any accesses to that element in the existing code. > > > >Brian > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of > >George Gallen > >> Sent: 12 May 2005 16:01 > >> To: u2-users@listserver.u2ug.org > >> Subject: RE: [U2] I'm in an Array quandry, any suggestions... > >> > >> WOW. I just found an interesting "feature" of UV. > >> > >> You can MATREAD a record that has more fields than are dimensioned, > >>and you can MATWRITE that record back out INTACT without > >> getting an error, > >> > >> It only bombs with an out of bounds error when you try to > >> reference a subscript > >>past the dimension. > >> > >> Soas long as any of those program dont try to mess with > >> data it doesn't know > >> about, we "should" be safe. > >> > >> George > >> > >> >-Original Message- > >> >[mailto:[EMAIL PROTECTED] Behalf Of > >George Gallen > >> > > >> >I'm modifying some programs that were written about 15-20 > >years ago, > >> >there must be 30 or 40 that > >> > interact with each other. > >> > > >> >Here is the problem. > >> >All the programs use dimensioned arrays, and they were > >> dimensioned to > >> >exactly what was needed at the time, now I need to add 4 > >> fields to one > >> >program. But I'm afraid if another program reads this > >newly created > >> >array, it will bomb out with an array out of bounds error. > >> > > >> >What is on my side, is all the programs that reference these > >> files, all > >> >use the same variable name. > >> > > >> >My initial thought was to write a small program that will > >> > 1. open a program > >> > 2. search for a dimension of the suspect variable(s) > >> > 3. increase it's dimension level > >> > 4. write the program back out > >> > 5. recompile the program (I don't believe any are cataloged) > >> > > >> >Any other ideas? > >> --- > >> u2-users mailing list > >> u2-users@listserver.u2ug.org > >> To unsubscribe please visit http://listserver.u2ug.org/ > >--- > >u2-users mailing list > >u2-users@listserver.u2ug.org > >To unsubscribe please visit htt
RE: [U2] Unix copying Universe files {Unclassified}
Question (per Mike Henderson's post on this thread): If a file has been setup for transaction logging, and you make a copy of a file using OS-level tools (cp, rcp, ftp, tar, etc.), how do you remove the TxLg info buried in the file header of the cloned file? Answer: 1. Use filepeek to edit the file header directly. --- or --- 2. - Edit the UV.TRANS record to point to the new cloned file, - then deactivate it using UniAdmin, or the menus in UV home dir, or the method described a few days ago in answer to Jeff Fitsgeralds TxLg/resize question, - then restore the UV.TRANS record to what it should be. This should _probably_ be done with logging disabled for the system, but I don't know that it _must_ be so (at 10.0, anyway). If you leave logging enabled, updates to the original file will continue to be logged while you are doing all this, since the log number remains in that file's header and the file header remains flagged for logging. UV.TRANS is only used during maintenance and rolls-forward. Of course, updates to the cloned file will be logged too, until you do this. Furthermore, if anyone opens the cloned file before you finish this, their process will continue logging the cloned file until they close the file. --- or --- 3. Maybe someone at IBM has a better answer. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
[EMAIL PROTECTED] wrote: > George, > > It really matters what flavor you're running. Which nobody has explained :-) > > If you run a flavor that puts the overspill in element zero, you may be ok. > If you run a flavor that puts the overspill into the last element, that > might mess up any accesses to that element in the existing code. "true" Pick arrays cannot be redimensioned, and put any excess into the last element (this presumably includes UV's "true pick" flavours). INFORMATION arrays can be redimensioned, have an element 0, and put any excess in there. Presumably the PI flavours of UV (and iirc IDEAL) do that. Note that even with a two-dimensional array, there is only one element 0, that has to be accessed as (0,0) (if one index is zero, the other one has to be, too) > > Brian Cheers, Wol > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen > > Sent: 12 May 2005 16:01 > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] I'm in an Array quandry, any suggestions... > > > > WOW. I just found an interesting "feature" of UV. > > > > You can MATREAD a record that has more fields than are dimensioned, > >and you can MATWRITE that record back out INTACT without > > getting an error, > > > > It only bombs with an out of bounds error when you try to > > reference a subscript > >past the dimension. > > > > Soas long as any of those program dont try to mess with > > data it doesn't know > > about, we "should" be safe. > > > > George > > > > >-Original Message- > > >[mailto:[EMAIL PROTECTED] Behalf Of George Gallen > > > > > >I'm modifying some programs that were written about 15-20 years ago, > > >there must be 30 or 40 that > > > interact with each other. > > > > > >Here is the problem. > > >All the programs use dimensioned arrays, and they were > > dimensioned to > > >exactly what was needed at the time, now I need to add 4 > > fields to one > > >program. But I'm afraid if another program reads this newly created > > >array, it will bomb out with an array out of bounds error. > > > > > >What is on my side, is all the programs that reference these > > files, all > > >use the same variable name. > > > > > >My initial thought was to write a small program that will > > > 1. open a program > > > 2. search for a dimension of the suspect variable(s) > > > 3. increase it's dimension level > > > 4. write the program back out > > > 5. recompile the program (I don't believe any are cataloged) > > > > > >Any other ideas? > > --- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
