Re: [U2] I'm in an Array quandry, any suggestions...
[EMAIL PROTECTED] wrote: In a message dated 5/18/2005 11:50:38 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: OK, sure. But readnext doesn't really work on an array but on a select list. Ah but that's not so. You can SELECT myVAR You can SELECT myVAR to LIST5 You can SELECT myVAR to MyLIST and then you *can* in fact READNEXT your array. Selecting the variable turns a dynamic arry into a list type variable. Will Johnson --- Will, try myVar = 1:@FM:2 SELECT myVar myVar1 = 3 READNEXT X THEN PRINT X the result is 1 thus readnext _doesn't_ read my array.. But of course you may user readnext to step thru an array with this technique -- if you keep in mind that it is an old image of the array that you processing - and mostly it doesn't matter as the array doesn't change. -- mats --- 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 a message dated 5/20/2005 2:47:20 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: myVar = 1:@FM:2 SELECT myVar myVar1 = 3 READNEXT X THEN PRINT X Right but that's easy to fix. Instead of SELECT myVar Use SELECT myVar to myListVar or SELECT myVar to 3 And then instead of READNEXT X you use READNEXT X FROM myListVar or READNEXT X FROM 3 And your problem vanishes. It is always true that if you change an array after the select then its not reading the array. My example way back in this thread was that you can step through an array using Readnext, not that it solves every possible configuration of that :) Will --- 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: In a message dated 5/18/2005 2:16:35 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Well it already needs both variables in the 'sequential' access too ! How would it even know that the access is for the next atrribute if it didn't keep track of the index? -- mats Because READNEXT doesnt specify what cell you want. It just says get the next one whatever number that is. So for Readnext you'd only need a pointer to the last char position of the last delimiter viewed. You wouldn't need to know what cell number that represents. Will --- OK, sure. But readnext doesn't really work on an array but on a select list. -- mats --- 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 a message dated 5/18/2005 11:50:38 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: OK, sure. But readnext doesn't really work on an array but on a select list. Ah but that's not so. You can SELECT myVAR You can SELECT myVAR to LIST5 You can SELECT myVAR to MyLIST and then you *can* in fact READNEXT your array. Selecting the variable turns a dynamic arry into a list type variable. Will Johnson --- 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...
I was told once that was the case in rel 8, but that is unverified. I wonder if there is some way we could write a test to check that out? -- Regards, Clif On May 17, 2005, at 10:18 PM, [EMAIL PROTECTED] wrote: And then I would wonder if the code is optimized to actually try to determine whether it would be faster to scan backward from present, or forward from cell 1 ... --- 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...
I think one of the the things that we are overlooking is the underlying philosophy that machine cycles are cheap, and anything that cuts development or modification time is a Good Thing. You and I may not agree with that philosophy (having been victimized by code that took the idea to it's illogical conclusion), but keeping track of how many elements you need in a dimensioned array is one of the icky programmer type things that, historically, the music majors passing themselves off as Pick programmers were loath to do. But in the Real World, these kind of things usually (note the disclaimer) do not make much difference. I always enjoyed blowing someone's benchmark out of the water by sticking a single READ statement in the middle of their CPU intensive loop. It's all about the disk, mon. Dimensioned vs Dynamic--brain damaged code is still brain damaged code. -- Regards, Clif On May 17, 2005, at 10:18 PM, [EMAIL PROTECTED] wrote: And then by that time, system programmers would be saying Why can't they just all use dimensioned arrays dammit :) I suppose. --- 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: In a message dated 5/16/2005 5:00:45 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Yes. But it only works when stepping through an array in a READNEXT fashion. So if you're accessing fields in random order (as a lot of my code does) you gain nothing. No it does work even when you access the dynamic array in random order. It then provides an alternative starting point for the search to use instead of character 1. I'm not sure this is accurate. This would imply that not only would the run-time engine have to maintain a pointer to the last cell referenced, but also it would have to maintain a register telling it the cell number of this cell (not just its offset). So it needs two variables. I've never heard that it actually uses two variables to accomplish this. Perhaps someone in the internals could answer that question. So again, it would need one variable to tell it the offset (example: my last reference ended at character 96 of the string ... or position 2345 of the frame, or something of that sort); AND another variable to tell it the cell number (example: my last reference was to cell number 4). Otherwise, random access into a dynamic array would not be improved by the method talked about in this thread. Will Johnson --- Well it already needs both variables in the 'sequential' access too ! How would it even know that the access is for the next atrribute if it didn't keep track of the index? -- mats 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...
All, Please watch the overquoting. It is very hard on digest readers and on dial-up connections. - Charles Barouch, Moderator U2UG --- 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...
Dimensioned vs Dynamic--brain damaged code is still brain damaged code. I could not agree more! the music majors passing themselves off as Pick programmers For the record I almost failed music history :) For those keeping track of suggestions for IBM here is one that would help bridge this divide. Allow re-dimensioning of dimensioned arrays at runtime. In VB you have the REDIM command and in C you can re-dimension damn near anything. Having this capability would provide the best of both worlds. 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: Wednesday, May 18, 2005 3:00 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] I'm in an Array quandry, any suggestions... I think one of the the things that we are overlooking is the underlying philosophy that machine cycles are cheap, and anything that cuts development or modification time is a Good Thing. You and I may not agree with that philosophy (having been victimized by code that took the idea to it's illogical conclusion), but keeping track of how many elements you need in a dimensioned array is one of the icky programmer type things that, historically, the music majors passing themselves off as Pick programmers were loath to do. But in the Real World, these kind of things usually (note the disclaimer) do not make much difference. I always enjoyed blowing someone's benchmark out of the water by sticking a single READ statement in the middle of their CPU intensive loop. It's all about the disk, mon. -- Regards, Clif On May 17, 2005, at 10:18 PM, [EMAIL PROTECTED] wrote: And then by that time, system programmers would be saying Why can't they just all use dimensioned arrays dammit :) I suppose. --- 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...
[EMAIL PROTECTED] wrote: Dimensioned vs Dynamic--brain damaged code is still brain damaged code. I could not agree more! the music majors passing themselves off as Pick programmers For the record I almost failed music history :) For those keeping track of suggestions for IBM here is one that would help bridge this divide. Allow re-dimensioning of dimensioned arrays at runtime. In VB you have the REDIM command and in C you can re-dimension damn near anything. Having this capability would provide the best of both worlds. As others have pointed out, YOU CAN. You just need to be using one of PI-derived flavours. And someone said you can actually switch between PI and Pick style behaviour even within one program! provided you sprinkle the magic directives in the correct places. 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 Cheers, Wol --- 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...
Allow re-dimensioning of dimensioned arrays at runtime. In VB you have the REDIM command and in C you can re-dimension damn near anything. Having this capability would provide the best of both worlds. It already can! You either need to use Ideal, Information or PI/open flavour or you need to use the appropriate compiler option to select the Information style matrices. This is needed because of the structural differences of Information and Pick style matrices. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- 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...
...Allow re-dimensioning of dimensioned arrays at runtime... As others have pointed out, YOU CAN $OPTIONS -STATIC.DIM Minus sign means not as in not static dim as in you can redimension this on the fly at runtime. It is necessary in Pick- Reality-flavors. PI- and Ideal-flavors have that feature already. (You could turn it off by $OPTIONS STATIC.DIM. no minus sign.) Put that directive at the top of the program and it remains in effect throughout the program. Arrays defined in common can't be redimensioned. --- 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...
(from memory, so verify via HELP) $OPTIONS -STATIC.DIM On May 18, 2005, at 7:15 AM, [EMAIL PROTECTED] wrote: Allow re-dimensioning of dimensioned arrays at runtime. In VB you have the REDIM command and in C you can re-dimension damn near anything. Having this capability would provide the best of both worlds. As others have pointed out, YOU CAN. You just need to be using one of PI-derived flavours. And someone said you can actually switch between PI and Pick style behaviour even within one program! provided you sprinkle the magic directives in the correct places. --- 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 a message dated 5/18/2005 2:16:35 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Well it already needs both variables in the 'sequential' access too ! How would it even know that the access is for the next atrribute if it didn't keep track of the index? -- mats Because READNEXT doesnt specify what cell you want. It just says get the next one whatever number that is. So for Readnext you'd only need a pointer to the last char position of the last delimiter viewed. You wouldn't need to know what cell number that represents. Will --- 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...
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. Wol, I stand corrected. Guess I missed that earlier point. It would be great if this functionality were generically available. If I read the UD documentation correctly it 'may' be available in the flavors we are using. Guess I will just have to play with it. Not that it would help my situation that much (well using the 0 element for excess would). As I said earlier changing flavors in the program is not an option that would help. The issue is not the programs we are changing, but rather the legacy code we are not changing. 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: Wednesday, May 18, 2005 10:15 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] I'm in an Array quandry, any suggestions... Allow re-dimensioning of dimensioned arrays at runtime. In VB you have the REDIM command and in C you can re-dimension damn near anything. Having this capability would provide the best of both worlds. As others have pointed out, YOU CAN. You just need to be using one of PI-derived flavours. And someone said you can actually switch between PI and Pick style behaviour even within one program! provided you sprinkle the magic directives in the correct places. --- 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...
Larry, Well, if you have to work in dimensioned arrays that would be the way to do it. Unfortunately, the code base I am working off of took this idea and completely messed it up. It is to the point that the dictionaries can not be trusted to truly represent the data. We are spending a great deal of time just dealing with this. As to the original topic, I will still stand by my earlier remarks, but I will qualify it by saying that performance (in ANY system) has a lot to do with how the system is designed in the first place. The code base that I came from previously was also of late 80s vintage and we did not see any benefit in moving to dimensioned arrays. I think that the difference is that we had records of a fairly manageable field count, but we used lots of value and even sub-value marked data. Dimensioned arrays don't really help you too much with that. We also sold systems based on the flexibility of the database and dimensioned arrays, even with tools like you describe, does lessen that flexibility (IMHO) 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 Larry Hiscock Sent: Friday, May 13, 2005 5:57 PM To: u2-users@listserver.u2ug.org Subject: 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 CM1 or anything similar. It is ALWAYS referenced as CM.CUST.NAME. Sub-valued fields are refenced as CM.ADDR1,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 CM1), 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/ --- 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 a message dated 5/16/2005 5:00:45 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Yes. But it only works when stepping through an array in a READNEXT fashion. So if you're accessing fields in random order (as a lot of my code does) you gain nothing. No it does work even when you access the dynamic array in random order. It then provides an alternative starting point for the search to use instead of character 1. I'm not sure this is accurate. This would imply that not only would the run-time engine have to maintain a pointer to the last cell referenced, but also it would have to maintain a register telling it the cell number of this cell (not just its offset). So it needs two variables. I've never heard that it actually uses two variables to accomplish this. Perhaps someone in the internals could answer that question. So again, it would need one variable to tell it the offset (example: my last reference ended at character 96 of the string ... or position 2345 of the frame, or something of that sort); AND another variable to tell it the cell number (example: my last reference was to cell number 4). Otherwise, random access into a dynamic array would not be improved by the method talked about in this thread. Will Johnson --- 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...
Will Johnson postulated:
This would imply that not only would the run-time engine have
to maintain a pointer to the last cell referenced, but also
it would have to maintain a register telling it the cell
number of this cell (not just its offset). So it needs two
variables. I've never heard that it actually uses two
variables to accomplish this.
Yes, Will. There are two variables. The descriptor definition found in
$UVHOME/gcidir/include/DATUM.h states:
struct Dstring
{ /* This are my comments. GI */
STRING str; /* This is the entire dynamic array. */
int lastfield; /* This is the last field accessed. */
uchar *lastfptr; /* This is a pointer into str.text */
/* where the last field field accessed */
/* begins. */
};
Best regards,
Gyle
---
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 a message dated 5/17/2005 7:47:46 PM Pacific Daylight Time,
[EMAIL PROTECTED] writes:
es, Will. There are two variables. The descriptor definition found in
$UVHOME/gcidir/include/DATUM.h states:
structDstring
{ /* This are my comments. GI */
STRING str; /* This is the entire dynamic array. */
int lastfield; /* This is the last field accessed. */
uchar *lastfptr; /* This is a pointer into str.text */
Thanks Gyle for that information.
So it seems like then it might be just as fast to also step *backward*
through an array ? I suppose that would depend on whether there is also an
opcode
for scan backward to delimited like there is for scan forward to delimiter.
And then I would wonder if the code is optimized to actually try to determine
whether it would be faster to scan backward from present, or forward from
cell 1 ...
And then by that time, system programmers would be saying Why can't they
just all use dimensioned arrays dammit :) I suppose.
Will
---
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...
Anthony W. Youngman wrote: In message [EMAIL PROTECTED], Roger Glenfield [EMAIL PROTECTED] writes 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? Yes. But it only works when stepping through an array in a READNEXT fashion. So if you're accessing fields in random order (as a lot of my code does) you gain nothing. No it does work even when you access the dynamic array in random order. It then provides an alternative starting point for the search to use instead of character 1. This will be used in about half of the searches ( when the last access was 'lower' than the new one ) and in that case on the average cut the search in half. Thus I'd expext a 25% performance gain when keeping track of accesses compared to the old brute force method - for the random access case.. I don't know any details of the implemetnation but it is possible that the last access pointer could occassionally be used to search backwards when some rule of tumb says it would be faster - thus making the 'new' approach even better. But the real reason for using dimensioned arrays is - as already pointed out by others - the huge gain when inserting data that makes the array grow. On the other hand - a possible reason to use dynamic arrays for efficiency might be a number of LOCATEs ... -- mats Cheers, Wol --- 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...
Charles Stevenson says: [snipped a bunch of good stuff] 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.REC117 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. Good point! Large dynamic arrays take longer to perform insertions, deletions and replacements. Why? The whole record must be copied to a new memory location with the changes. With dimensioned arrays, only the affected element is manipulated. Another related and fundamental difference exists between the two array types that should not be overlooked. The dynamic array can only store string data. Numeric values convert to a string before being stored in a dynamic array. Subsequent extraction of that just-stored data returns as a string and converts back to numeric as necessary. However, each dimensioned array element has its own unique memory descriptor (variable). A dynamic array element may store any type of data (though only string or numeric is appropriate for records). By using dimensioned arrays, numeric values are stored in the array without conversion. The conversion from numeric to string occurs only once, at the point when writing the record. Using dimensioned arrays can improve throughput when repeatedly performing mathematical operations on record elements. Best regards, Gyle P.S. I designed the URMA run machine to treat dynamic arrays as though they were dimensioned arrays internally, providing direct access any field, value or sub-value. Accessing record1000, 1000, 1000 is nearly as fast as accessing record1, 1, 1. I believe Robert Colquhoun took a similar approach with MaVerick too. Do not expect U2 to do anything like this anytime soon. The descriptor management foundation needs to support this concept and is not easily retrofitted. --- 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 message [EMAIL PROTECTED], Roger Glenfield [EMAIL PROTECTED] writes 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? Yes. But it only works when stepping through an array in a READNEXT fashion. So if you're accessing fields in random order (as a lot of my code does) you gain nothing. Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- 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 message [EMAIL PROTECTED], Richard Taylor [EMAIL PROTECTED] writes 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. Using PI on a 750 or 2750 - we had arrays that were up to a thousand elements long. And the performance impact was VERY noticeable when switching from dynamic to dimensioned. And then later, programming UV on an EXL7330, many's the time I've taken a slow program that heavily manipulated dynamic arrays, converted it to dimensioned, and watched it fly. One particular case, I think I reduced run-time from 20 to 5 minutes. Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- 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 message [EMAIL PROTECTED], Richard Taylor [EMAIL PROTECTED] writes 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. Go to PickWiki and look at the sort routines there. They're actually an EXCELLENT example of where dimensioned arrays shine ... Along with the various sort routines there, I wrote a tape sort. Now a tape sort is OPTIMISED for merging two already-sorted lists. But I wrote it (because I couldn't see any other sensible way) to use dynamic arrays. So if DIM'd arrays aren't better at that sort of thing, how come a general-purpose sort like SHELL (using dim'd arrays) just blew TAPE out of the water, in a situation where tape was absolutely perfect for the scenario? Cheers, Wol -- Anthony W. Youngman [EMAIL PROTECTED] 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick --- 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/
RE: [U2] I'm in an Array quandry, any suggestions...
Don't confuse Dimensioned (fixed) arrays with dynamic arrays. REC0 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, REC0 returns the entire string too. I ran into this once converting a program that actively used the assumption that REC0 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. REC0 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: u2-users@listserver.u2ug.org 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 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
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...
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...
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...
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...
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. XYZ17,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.REC117 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...
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 RECORD50,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 = RECORD50 FOR LINE.LOOP = 1 TO LINE.CNT IF LINE.STATUS.CDS1,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. XYZ17,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.REC117 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. Version: 7.0.308 / Virus Database
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] 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 LISTN = N 0019 NEXT N 0020 0021 PRINT COUNTING ATTRIBUTES...: 0022 T = SYSTEM(9) 0023 FOR N = 9000 TO 1 0024 X = LISTN 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 = LIST1,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...
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 CM1 or anything similar. It is ALWAYS referenced as CM.CUST.NAME. Sub-valued fields are refenced as CM.ADDR1,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 CM1), 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] 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/
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/
RE: [U2] I'm in an Array quandry, any suggestions...
While you're at it, move the DIM to a file to be included in all the programs that use it. Then when you need to change it again in the future, it's in 1 place. Also create a compile list program that includes all of the programs that use it as well. After you change the include file to resize the dimensioned array, you run that 1 program to recompile everything. And lastly, pad the file with unused fields when you resize it. Say if you are using 100 fields right now, and adding 4, add another 6 for future use. This saves you from have to recompile when you want to change it next time. Unless of course you need more than 6 more fields next time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: Thursday, May 12, 2005 10:46 AM To: Ardent List Subject: [U2] I'm in an Array quandry, any suggestions... 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? George Gallen Senior Programmer/Analyst Accounting/Data Division [EMAIL PROTECTED] ph:856.848.1000 Ext 220 SLACK Incorporated - An innovative information, education and management company http://www.slackinc.com --- 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...
I found that problem in the RESULTS or older application where most data records were dim'd to (100). The original file sizes were around 50-70 attributes and it appeared to have some room for growth. Since it was written in 1980-82, there has been some opportunity for growth. Some of my Microdata clients truncate if the data record is 105 atts. The last 5 atts are unavailable on the READ and lost on the WRITE. Other implementations put the balance of the fields in the last dim'd element. Thus there's an offset. PRINT REC(100)3 maybe the same as PRINT REC(103). Since each dim'd element is a variable, each element can be a whole dynamic array, char(254)'s included. This Jurrasic Pick code was popular then due to the burden of typing EXTRACT and REPLACE instead of . Regarding a universal approach, you may be lucky with consistently named variables. RESULTS was not that consistent and it required more manual work. Often times these new fields may not be for all the records in the data file. Thus, the creation of a new field that only a handful of records may need seems like a waste of a field. Thus my SPARE fields concept. This required the addition of a SPARE file per regular data file. Since the application runs pretty well with everything as it is, these new fields may be just for a single purpose and not application-wise. So you still have CUSTOMER and then you have CUSTOMER.SPARE. My 2 programs, SPARE01 and SPARE02 are the field defining program (01) and the data entry (02). An administrator uses SPARE01 to define the fields which includes creating the cross-file dict items. Thus you can say LIST CUSTOMER SPARE.EMAIL and it appears that the EMAIL field is part of the original data record. SPARE02 is added to each file-maintenance program to have a new screen with the maintenance of the fields as defined earlier. Pretty simple and not intended to be that sophisticated, application-wise. Also include to DELETE the SPARE record when the primary record is DELETED. Many of my clients enjoy these subs as they are constantly adding new fields, ie EMAIL, Web sites, more phone numbers, cell numbers, etc. None of these fields are required and no SPARE records are created unless that CUSTOMER needs a spare field. My 3 cents. Mark Johnson - Original Message - From: George Gallen [EMAIL PROTECTED] To: Ardent List u2-users@listserver.u2ug.org Sent: Thursday, May 12, 2005 10:45 AM Subject: [U2] I'm in an Array quandry, any suggestions... 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? George Gallen Senior Programmer/Analyst Accounting/Data Division [EMAIL PROTECTED] ph:856.848.1000 Ext 220 SLACK Incorporated - An innovative information, education and management company http://www.slackinc.com --- 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...
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 http://listserver.u2ug.org/
RE: [U2] I'm in an Array quandry, any suggestions...
Watch Out!!! If your program changes the last dimensioned field, you will lose the extra data!!! IIRC, the extra fields are being appended to the last dimensioned element. If you change that element, the extra fields can disappear. You'd have to do something like: MYARRAY(5)1 = newvalue And not MYARRAY(5) = newvalue -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: Thursday, May 12, 2005 11:01 AM 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/
Re: [U2] I'm in an Array quandry, any suggestions...
Shouldn't be a problem as long as you aren't passing the arrays back and forth between the programs, then they would all need to be dimensioned the same. -Dianne George Gallen wrote: 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/
RE: [U2] I'm in an Array quandry, any suggestions...
When I tested it, the last dimensioned element was not multivalued, and writing to it did not cause loss of data. That may be a flavor issue. Thanks for the warning. George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 11:44 AM To: u2-users@listserver.u2ug.org Cc: George Gallen Subject: RE: [U2] I'm in an Array quandry, any suggestions... Watch Out!!! If your program changes the last dimensioned field, you will lose the extra data!!! IIRC, the extra fields are being appended to the last dimensioned element. If you change that element, the extra fields can disappear. You'd have to do something like: MYARRAY(5)1 = newvalue And not MYARRAY(5) = newvalue -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: Thursday, May 12, 2005 11:01 AM 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/
RE: [U2] I'm in an Array quandry, any suggestions...
Any attributes outside the range of the dim are added to the last dim(?). So what you want to do is ok as long as you are aware of how the data is being held. Ok if you and only you are ever going to work on the system! We use an include to hold the dim statement along with an equate table. It makes these changes easy. One include to amend and a list of programs to compile. Les -Original Message- From: George Gallen [mailto:[EMAIL PROTECTED] 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/ This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- 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...
I seem to remember that the matread will take the extra attributes and multi-value them into the last element of the dimensioned array. When it writes them back out, the attribute marks go into the item so you don't lose anything. So you're ok, as long as nothing ever uses that last dimensioned element. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of George Gallen Sent: Thursday, May 12, 2005 10:01 AM 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/
Re: [U2] I'm in an Array quandry, any suggestions...
The extra fields get put into element (0) of the array as a dynamic array, should you want to access them. -- Regards, Clif ~~~ W. Clifton Oliver, CCP CLIFTON OLIVER ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com ~~~ On May 12, 2005, at 8:01 AM, George Gallen wrote: 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/
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. REC0 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: u2-users@listserver.u2ug.org 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 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...
You may want to think about this again if you think you will ever move to .NET as OPTION BASE 1 is gone. Everything starts at '0' now. Regards, Jim [snip] I use OPTION BASE 1 to keep my head on straight when progamming in VB. --- 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...
That's nice to know. I've inherited some VB code written with OPTION BASE 0 and it keeps me honest. Thanks. - Original Message - From: James Canale, Jr. [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, May 12, 2005 1:16 PM Subject: RE: [U2] I'm in an Array quandry, any suggestions... You may want to think about this again if you think you will ever move to .NET as OPTION BASE 1 is gone. Everything starts at '0' now. Regards, Jim [snip] I use OPTION BASE 1 to keep my head on straight when progamming in VB. --- 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/
