RE: [U2] THE variable names
FAR R15,0 ; ** out JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Baldridge Sent: 24 July 2005 16:50 To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Could we not just avoid confusing the old(er) timers by just using assembler and PROC? Mark A. Baldridge Principal Consultant North American Lab Services DB2 Information Management, IBM Software Group (607) 351-5666 --- 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] THE variable names
I know a assembler (not mcd but BAL) and PROC. Don't miss them though. - Original Message - From: Mark Baldridge [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, July 24, 2005 11:50 AM Subject: Re: [U2] THE variable names Could we not just avoid confusing the old(er) timers by just using assembler and PROC? Mark A. Baldridge Principal Consultant North American Lab Services DB2 Information Management, IBM Software Group (607) 351-5666 --- 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] THE variable names
Could we not just avoid confusing the old(er) timers by just using assembler and PROC? Mark A. Baldridge Principal Consultant North American Lab Services DB2 Information Management, IBM Software Group (607) 351-5666 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/21/2005 11:59:28 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: If you are unwilling to open your eyes and mind to new things (although REMOVE is not new), there is not much any of us can do. And I thought I was resistant to change. ;^) I don't think you've been paying attention at all :) I did not say I was resistent to change. I asked for a good example of why you'd use REMOVE in place of READNEXT. If you're going to advocate a position so strongly you should be willing to back it up Will --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes In a message dated 7/21/2005 11:59:28 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: If you are unwilling to open your eyes and mind to new things (although REMOVE is not new), there is not much any of us can do. And I thought I was resistant to change. ;^) I don't think you've been paying attention at all :) I did not say I was resistent to change. I asked for a good example of why you'd use REMOVE in place of READNEXT. If you're going to advocate a position so strongly you should be willing to back it up I can't give an example, but I can certainly give a situation ... As somebody else pointed out, if you have a COMPLEX dynamic array, REMOVE and READNEXT give completely different results. If one works, the other will corrupt your data. And as I said, I'd use REMOVE in place of READNEXT for clarity - I've never known anybody use READNEXT :-) 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] THE variable names
One last comment. It has been said There is none so blind as he who will not see. If you are unwilling to open your eyes and mind to new things (although REMOVE is not new), there is not much any of us can do. And I thought I was resistant to change. ;^) Regards, Charlie Noah [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) writes: In a message dated 7/20/2005 6:40:38 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: You could select the IDs and READNEXT or REMOVE to process. Either is far faster than FOR/NEXT and extract. I've seen a 40 minute process reduced to 6 seconds (thanks Louis Nardozi) by changing to this method. To everything there is a season, and to each instruction there is a task. But I never advocated a For/Next loop. I have yet to hear of a good, legitimate, use for REMOVE. Even after 30 or so posts on this topic ;) Will --- 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] THE variable names
Will, There is a very good use for REMOVE. Consider a cross-reference item (inherited, not built by current programmer) which has many thousands of keys and IDs. You could select the IDs and READNEXT or REMOVE to process. Either is far faster than FOR/NEXT and extract. I've seen a 40 minute process reduced to 6 seconds (thanks Louis Nardozi) by changing to this method. To everything there is a season, and to each instruction there is a task. Regards, Charlie Noah Inland Truck Parts [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) writes: Then you are mistaken. Remove does not confuse me. Remove unnecessarily confuses other people. Why use a structure when another one, less confusing, more known, more used is readily available? And I think you missed my point, even if it did confuse me, the main thrust is to write code that is easily maintained by others, not by yourself. So whether or not it confused me should not be one of the criteria imho. READNEXT works just find for processing a multi-item list just as REMOVE does and it's much more widely used and understood. So I see no point to the Remove command at all. If you imagined that I have not opened a manual in 25 years, you are mistaken. I routinely review manuals for training other programmers. Not just Universe manuals, but other Pick manuals as well. And I have used Remove on occasion, but was never very satisfied with it. Will Johnson --- 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] THE variable names
Aaah! REMOVE or not to REMOVE. REMOVE has three other associated statements that make the set a very powerful and distinct statement set indeed. REMOVE has REVREMOVE and GETREM and SETREM. The only gotcha I fell into many years ago was upon seeing a statement that read... VAR = VAR I promptly deleted it thinking it had become redundant code after some sort of global editor change. To my cost it was in fact a very important statement as it resets the REMOVE pointer to the beginning thus ensuring any subsequent REMOVE upon this variable would start at the beginning. I put it back with a nice big comment to that effect. So Will please be open minded as to the need and merits of all statements as they are only unreadable to the uninitiated. My 2 cents Trevor Ockenden e: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 20 July 2005 11:33 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Will, There is a very good use for REMOVE. Consider a cross-reference item (inherited, not built by current programmer) which has many thousands of keys and IDs. You could select the IDs and READNEXT or REMOVE to process. Either is far faster than FOR/NEXT and extract. I've seen a 40 minute process reduced to 6 seconds (thanks Louis Nardozi) by changing to this method. To everything there is a season, and to each instruction there is a task. Regards, Charlie Noah Inland Truck Parts [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) writes: Then you are mistaken. Remove does not confuse me. Remove unnecessarily confuses other people. Why use a structure when another one, less confusing, more known, more used is readily available? And I think you missed my point, even if it did confuse me, the main thrust is to write code that is easily maintained by others, not by yourself. So whether or not it confused me should not be one of the criteria imho. READNEXT works just find for processing a multi-item list just as REMOVE does and it's much more widely used and understood. So I see no point to the Remove command at all. If you imagined that I have not opened a manual in 25 years, you are mistaken. I routinely review manuals for training other programmers. Not just Universe manuals, but other Pick manuals as well. And I have used Remove on occasion, but was never very satisfied with it. Will Johnson --- 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/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 19/07/2005 __ ella for Spam Control has removed Spam messages and set aside Newsletters for me You can use it too - and it's FREE! http://www.ellaforspam.com -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 19/07/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/20/2005 6:40:38 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: You could select the IDs and READNEXT or REMOVE to process. Either is far faster than FOR/NEXT and extract. I've seen a 40 minute process reduced to 6 seconds (thanks Louis Nardozi) by changing to this method. To everything there is a season, and to each instruction there is a task. But I never advocated a For/Next loop. I have yet to hear of a good, legitimate, use for REMOVE. Even after 30 or so posts on this topic ;) Will --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
From: [EMAIL PROTECTED] I have yet to hear of a good, legitimate, use for REMOVE. Even after 30 or so posts on this topic ;) Consider associated multi-value arrays, perhaps for automobiles, shall we say? And for some reason, you need to look at each and every car. So, (coding from memory here, not on a U2 machine), you might want to do this. MV.MAKE = MV.MAKE ;* reset internal pointer MV.MODEL = MV.MODEL ;* reset internal pointer MV.YEAR = MV.YEAR ;* reset internal pointer * REM.MAKE = 999 WHILE REM.MAKE NE 0 LOOP REMOVE MAKE FROM MV.MAKE SETTING REM.MAKE REMOVE MODEL FROM MV.MODEL SETTING REM.MODEL REMOVE YEAR FROM MV.YEAR SETTING REM.YEAR * do something with the three associated values MAKE, MODEL YEAR... REPEAT --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
REMOVE - post 31 (was: RE: [U2] THE variable names)
I'll jump in with a good, legitimate REMOVE usage. Most of what we hear about is something like: IF (LONG.DELIMITED.STRING[1,1] NE ) THEN LOOP REMOVE ELEMENT FROM LONG.DELIMITED.STRING SETTING MORE.DATA * Take Element-specific action WHILE MORE.DATA DO REPEAT END However, I've had a couple of situations where I was parsing a string with multiple levels of delimiter where nested loops would have been ugly. This is cleaner and clearer: IF (ODDLY.DELIMITED.STRING[1,1] NE ) THEN LOOP REMOVE ELEMENT FROM ODDLY.DELIMITED.STRING SETTING DELIM * Take Delimiter-specific action BEGIN CASE CASE (DELIM EQ 2) ;* AM-Specific Code CASE (DELIM EQ 3) ;* VM-Specific Code END CASE WHILE DELIM DO REPEAT END That being said, I'm glad we have REMOVE available for both uses. Thanks, Ross. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 8:28 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names ... I have yet to hear of a good, legitimate, use for REMOVE. Even after 30 or so posts on this topic ;) Will --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
As long as you keep an open mind so that when the perfect situation for REMOVE comes up you will use it. :-) And if that perfect situation comes up, and if you allow yourself to code it, let us know. Bruce Bruce M Neylon Health Care Management Group [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/20/2005 11:27 AM Please respond to u2-users To: u2-users@listserver.u2ug.org cc: Subject:Re: [U2] THE variable names I have yet to hear of a good, legitimate, use for REMOVE. Even after 30 or so posts on this topic ;) Will --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In message [EMAIL PROTECTED], Trevor Ockenden [EMAIL PROTECTED] writes So Will please be open minded as to the need and merits of all statements as they are only unreadable to the uninitiated. Like, for example, Will's stating that REMOVE is obscure and WHILE READNEXT is clear ... I've been programming MV for 20 years and I can't *EVER* remember seeing a WHILE READNEXT in code I've read ... it certainly wouldn't have been clear to me before I started seeing it on the Oliver lists ... 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] THE variable names
All, Let's move this to u2-community. If you aren't subscribed to U2-Community, please visit http://listserver.u2ug.org/, enter your e-mail address, and 'browse all' lists to maintain your access. Post all future messages on this topic there. - Charles Barouch Moderator --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
Will wrote... I have yet to hear of a good, legitimate, use for REMOVE. OK! Good point Will. Try coding a routine like sdiff that you can find in some flavours of Unix in UVBasic with and without the REMOVE set of statements and see the difference it makes to the speed. This task was greatly simplified with the ability to REVREMOVE and the speed difference was enormous. Also, when I first wrote that routine sequential dynamic array extracts were not particularly efficient as each extract had to search from the beginning of the dynamic array string. Therefore on long strings the performance would degrade notably as it progressed. The ability to save a position in a dynamic array so you can reset the pointer to that point at a later stage is invaluable. Performance is greatly enhanced also. Will, don't balk at new and unusual statements - they help create the mystique that surrounds our otherwise mundane careers - don't you think? Cheers Trevor Ockenden e: [EMAIL PROTECTED] __ ella for Spam Control has removed Spam messages and set aside Newsletters for me You can use it too - and it's FREE! http://www.ellaforspam.com -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 19/07/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/18/2005 2:21:26 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: lol - ok - not confusing ? I don't have the direct quote but i beleive you stated that remove still confuses you. Then you are mistaken. Remove does not confuse me. Remove unnecessarily confuses other people. Why use a structure when another one, less confusing, more known, more used is readily available? And I think you missed my point, even if it did confuse me, the main thrust is to write code that is easily maintained by others, not by yourself. So whether or not it confused me should not be one of the criteria imho. READNEXT works just find for processing a multi-item list just as REMOVE does and it's much more widely used and understood. So I see no point to the Remove command at all. If you imagined that I have not opened a manual in 25 years, you are mistaken. I routinely review manuals for training other programmers. Not just Universe manuals, but other Pick manuals as well. And I have used Remove on occasion, but was never very satisfied with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Will Johnson wrote on Tue, 19 Jul 2005 01:55:51 EDT Remove does not confuse me. Remove unnecessarily confuses other people. ... READNEXT works just find for processing a multi-item list just as REMOVE does and it's much more widely used and understood. So I see no point to the Remove command at all. The important difference between using READNEXT and REMOVE is that READNEXT will return the entire next item, while REMOVE only returns up to the next system delimiter. If you have value marks or sub-value marks in your attributes, REMOVE will break them up into their individual components, whereas READNEXT will not. To my mind, the READNEXT structure is more straightfoward if you need to process each attribute separately. The REMOVE command requires setting a variable, which usually should be checked to ensure that the correct delimiter was encountered. It is useful when you need to process each individual value separately. As is often the case, we have a variety of specialized tools, and we need to use the appropriate tool for each task. For example, one could use a torque wrench to tighten every single nut and bolt in the world, but for most applications, this isn't necessary, and in some cases, is more difficult to use. REMOVE has its uses (there is a point to it), but the original post (if anyone recalls that! :-) was concerned with using DCOUNT followed by a FOR loop, and I believe the LOOP WHILE READNEXT ITEM FROM ITEM.LIST syntax is a more straightforward alternative than the REMOVE syntax. --Tom Pellitieri Toledo, Ohio --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes Not directed at you Mark, but someone mentioned that Remove has been around a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. And I still find it much more confusing that simply SELECTing a variable to another variable. That to me is more intuitive. And DCOUNT was added to INFORMATION at about the same time. It certainly wasn't there when I started using it in 85. I suspect this was due to the SPECTRUM standardisation attempts. 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] THE variable names
It is not surprising that the pick market has a bit of a dinosaur-esqe
image, as it would seem that many of us are still coding around bugs
that were fixed 20 or more years ago. I can't speak for others, but it
seems to me that 1985 was ONE HELL OF A LONG TIME AGO as regards to the
computer industry. New functions and syntax get added to the language
for good reasons. (Speed, standardization, simplicity, etc.) Use them!
I still see new code using:
CNT = COUNT(REC,CHAR(254))+(REC NE )
or even worse
LOCATE('[EMAIL PROTECTED]',REC;CNT) ELSE CNT = CNT - 1
I guess old habits die hard.
Not wanting to start a flame war, but come on guys...
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anthony W.
Youngman
Sent: Tuesday, July 19, 2005 4:30 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] THE variable names
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
Not directed at you Mark, but someone mentioned that Remove has been
around a long time. Not so. REMOVE was not added to the ADDS
environment until perhaps around the mid 80s or so. And I still find
it much more confusing that simply SELECTing a variable to another
variable. That to me is more intuitive.
And DCOUNT was added to INFORMATION at about the same time. It certainly
wasn't there when I started using it in 85. I suspect this was due to
the SPECTRUM standardisation attempts.
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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
lol - ok - not confusing ? I don't have the direct quote but i beleive you stated that remove still confuses you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Sunday, July 17, 2005 12:03 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/16/2005 11:51:40 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: after 20 years its still that confusing to you ? maybe I was wrong and you do fall into the group that i was bashing. i'd hate to have to deal with an auto mechanic, or any other 'professional' for that matter, with that kind of mind set. No it is not confusing in the slightest. It's just unnecessary and READNEXT is a dozen times more obvious in what it's going-on about. Unlike yourself. Bye now. Will Johnson --- 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] THE variable names
to a point. but using grade school grammar just so the language illiterati can understand it - I have to disagree. just because something has been in the language less than 25 years doesn't mean it is either difficult or obscure in any way, it just means one hasn't invested the minimal time and effort required to keep up to date. I believe complacency is the word. I have yet to see any reference to anything in this 'new' feature debate about anything being obscured. the only gripe seems to be that these items didn't exist in the 1st run system manuals. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Sunday, July 17, 2005 12:01 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/16/2005 11:47:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: on another note - when I see some of these new functions like REMOVE - 'new' ? but that is really irrelevent, if one chooses not to use 'new' language features, that's his/her choice. but to advise others not to use them because it might confuse the oldtimers is ludicrous. I disconcur. An intelligent programmer writes code so that other programmers have the easiest time modifying it. Not the hardest. Deliberately obfuscating code is a sign of pedantic obscuration. Will Johnson --- 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] THE variable names
i would agree that the uv docs have been pretty horrendous as far as organization goes. but the lastest document set available for download has been cleaned up very nicely - each manual in its own .pdf, all linked to a master index .pdf and searchable within a specific .pdf or across the entire documentation set. my only suggestion would be that the actual root document be made a little more obvious - index.pdx in the root docs directory is nothing, the index directory contains nothing useful, if you go through the doc structure you eventually find it under bkShelf/bkShelf.pdf on another note - when I see some of these new functions like REMOVE - 'new' ? but that is really irrelevent, if one chooses not to use 'new' language features, that's his/her choice. but to advise others not to use them because it might confuse the oldtimers is ludicrous. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Baakkonen, Rodney Sent: Friday, July 15, 2005 11:08 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] THE variable names The Acrobat PDF search of the online manuals works great. I use it about once a day for Unidata 6.0. - Rod -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, July 15, 2005 9:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names This may explain my reaction. As I travel to my many clients, virtually every one of them has an IT department where those current hot-shot (typically under age 35) administrators piss on the MV environments. It could be UD, UV, MvBase or even Microdata. It all looks the same to them. There was an ad campaign touting 'This isn't your father's Oldsmobile. Well, MV isn't your father's DOS either. But to the uninformed, it sure looks like DOS and as such will always be looked down upon by these admins. I have to defend the MV environment at least twice a week. I also have to annually face at least one of my clients having a current IT admin guy try to talk the ownership of the company to throw away the MV environment for a newer GUI environment that certainly is built for the future. I, like many, will endorse MV to the bitter end. There are a lot of contemporary topics on this forum that I don't understand, ie sockets etc. I reference my own modest success in MV as proof that I am doing a good job for my clients. If I use DCOUNT instead of REMOVE on one of my UD clients, that can't relegate me to one who doesn't RTFM. Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. There are a lot of OS dependent features that I don't bother learning until, on that platform, I need that function. I reacted to the implication that my age, my expertise in things Jurrasic, and my non-use of things like REMOVE indicates that I am not up to speed. Maybe I don't use REMOVE and use DCOUNT for the reasons stated earlier. Platform specific commands that are a slight substitute for a universal (all platforms) command don't interest me because I have to stop and think of the platform instead of the project at hand. I see a lot of coding techniques in my travels and on this forum that don't interest me. But, when I see a technique that clearly improves my productivity, I'm the first to implement it and give credit where it is due (Chandru Murthi, Joe Golubov, John Spicer to name a few). But by now in my career, I'm not seeing anything that i want to add to my arsenal. Oddly enough when I see some of these new functions like REMOVE, they're buried in code that I've long since relegated to being taught wrong. MV allows for so many choices when solving a single problem that despite all working, some work better than the others. Then it's a personal preference. My 3 cents. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, July 15, 2005 12:46 AM Subject: RE: [U2] THE variable names wow. I can't believe how touchy people get about the simplest comments. I am also surprised at the assumptions that get made in order to flame back at some perceived insult. Why do you assume anything about how long I've been at this game, my abilities or the size of my bank account ? And how is any of that even relevant ? For the record, I wasn't slandering old pros. I was slandering old 'pros' that haven't picked up a manual in 20 years - big difference. The comment was made in response to the statement that 'newer' ( ie. post 1970's ) language features shouldn't be used as they would confuse the 'old timers'. If you are current in the profession then what I said was in no way directed at you - so why the indignation ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, July 14, 2005 11:16 PM To: u2-users
RE: [U2] THE variable names
after 20 years its still that confusing to you ? maybe I was wrong and you do fall into the group that i was bashing. i'd hate to have to deal with an auto mechanic, or any other 'professional' for that matter, with that kind of mind set. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, July 15, 2005 05:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/15/05 7:19:42 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. Not directed at you Mark, but someone mentioned that Remove has been around a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. And I still find it much more confusing that simply SELECTing a variable to another variable. That to me is more intuitive. REMOVE was definitely not a part of the '79 Microdata environment. Anyone who says so will have to post a scan of that page from the manual to convince me :) It certainly was not in the Ultimate Honeywell/Bull and was not a part of the Fujitsu or C.Itoh environment. Will Johnson --- 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] THE variable names
In a message dated 7/16/2005 11:51:40 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: after 20 years its still that confusing to you ? maybe I was wrong and you do fall into the group that i was bashing. i'd hate to have to deal with an auto mechanic, or any other 'professional' for that matter, with that kind of mind set. No it is not confusing in the slightest. It's just unnecessary and READNEXT is a dozen times more obvious in what it's going-on about. Unlike yourself. Bye now. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/16/2005 11:47:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: on another note - when I see some of these new functions like REMOVE - 'new' ? but that is really irrelevent, if one chooses not to use 'new' language features, that's his/her choice. but to advise others not to use them because it might confuse the oldtimers is ludicrous. I disconcur. An intelligent programmer writes code so that other programmers have the easiest time modifying it. Not the hardest. Deliberately obfuscating code is a sign of pedantic obscuration. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
This may explain my reaction. As I travel to my many clients, virtually every one of them has an IT department where those current hot-shot (typically under age 35) administrators piss on the MV environments. It could be UD, UV, MvBase or even Microdata. It all looks the same to them. There was an ad campaign touting 'This isn't your father's Oldsmobile. Well, MV isn't your father's DOS either. But to the uninformed, it sure looks like DOS and as such will always be looked down upon by these admins. I have to defend the MV environment at least twice a week. I also have to annually face at least one of my clients having a current IT admin guy try to talk the ownership of the company to throw away the MV environment for a newer GUI environment that certainly is built for the future. I, like many, will endorse MV to the bitter end. There are a lot of contemporary topics on this forum that I don't understand, ie sockets etc. I reference my own modest success in MV as proof that I am doing a good job for my clients. If I use DCOUNT instead of REMOVE on one of my UD clients, that can't relegate me to one who doesn't RTFM. Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. There are a lot of OS dependent features that I don't bother learning until, on that platform, I need that function. I reacted to the implication that my age, my expertise in things Jurrasic, and my non-use of things like REMOVE indicates that I am not up to speed. Maybe I don't use REMOVE and use DCOUNT for the reasons stated earlier. Platform specific commands that are a slight substitute for a universal (all platforms) command don't interest me because I have to stop and think of the platform instead of the project at hand. I see a lot of coding techniques in my travels and on this forum that don't interest me. But, when I see a technique that clearly improves my productivity, I'm the first to implement it and give credit where it is due (Chandru Murthi, Joe Golubov, John Spicer to name a few). But by now in my career, I'm not seeing anything that i want to add to my arsenal. Oddly enough when I see some of these new functions like REMOVE, they're buried in code that I've long since relegated to being taught wrong. MV allows for so many choices when solving a single problem that despite all working, some work better than the others. Then it's a personal preference. My 3 cents. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, July 15, 2005 12:46 AM Subject: RE: [U2] THE variable names wow. I can't believe how touchy people get about the simplest comments. I am also surprised at the assumptions that get made in order to flame back at some perceived insult. Why do you assume anything about how long I've been at this game, my abilities or the size of my bank account ? And how is any of that even relevant ? For the record, I wasn't slandering old pros. I was slandering old 'pros' that haven't picked up a manual in 20 years - big difference. The comment was made in response to the statement that 'newer' ( ie. post 1970's ) language features shouldn't be used as they would confuse the 'old timers'. If you are current in the profession then what I said was in no way directed at you - so why the indignation ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, July 14, 2005 11:16 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Don't cast such stones on us 'old pro's. Many of us have spent more time with these older systems prior to the current system than many have with their only systems. There is an evolution with these MV systems that allows us to be a little cautious of new, platform specific 'features'. At present I have active accounts in Microdata, UV, UD, AP-Pro, D3, MvBase and R90. All support DCOUNT etc and it gets a little hard to remember which system supports REMOVE or SELECT TO. I for one got a little tired with the LOCATE differences and the EXECUTE/PERFORM syntaxes. So I go with the trusted, comprehensive methods. My productivity isn't hampered by using DCOUNT instead of REMOVE. I won't yield to a cpu cycle argument either. Given the tremendous amount of poor programming that I have inherited these last 27 years, I feel pretty good about my abilities (and bank account) in MV programming. I just removed 680 lines from a 900 line program that needed a repair. Since I'm the current cook in the kitchen at my clients, I have to take responsibility for any problems that creep up when I change a program. I may be tweaking lines 100-115 and when the fresh compile produces a new error at line 580, it's now my problem. As with other debatable elements, there will always be 2 solutions to every
RE: [U2] THE variable names
The Acrobat PDF search of the online manuals works great. I use it about once a day for Unidata 6.0. - Rod -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Friday, July 15, 2005 9:07 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names This may explain my reaction. As I travel to my many clients, virtually every one of them has an IT department where those current hot-shot (typically under age 35) administrators piss on the MV environments. It could be UD, UV, MvBase or even Microdata. It all looks the same to them. There was an ad campaign touting 'This isn't your father's Oldsmobile. Well, MV isn't your father's DOS either. But to the uninformed, it sure looks like DOS and as such will always be looked down upon by these admins. I have to defend the MV environment at least twice a week. I also have to annually face at least one of my clients having a current IT admin guy try to talk the ownership of the company to throw away the MV environment for a newer GUI environment that certainly is built for the future. I, like many, will endorse MV to the bitter end. There are a lot of contemporary topics on this forum that I don't understand, ie sockets etc. I reference my own modest success in MV as proof that I am doing a good job for my clients. If I use DCOUNT instead of REMOVE on one of my UD clients, that can't relegate me to one who doesn't RTFM. Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. There are a lot of OS dependent features that I don't bother learning until, on that platform, I need that function. I reacted to the implication that my age, my expertise in things Jurrasic, and my non-use of things like REMOVE indicates that I am not up to speed. Maybe I don't use REMOVE and use DCOUNT for the reasons stated earlier. Platform specific commands that are a slight substitute for a universal (all platforms) command don't interest me because I have to stop and think of the platform instead of the project at hand. I see a lot of coding techniques in my travels and on this forum that don't interest me. But, when I see a technique that clearly improves my productivity, I'm the first to implement it and give credit where it is due (Chandru Murthi, Joe Golubov, John Spicer to name a few). But by now in my career, I'm not seeing anything that i want to add to my arsenal. Oddly enough when I see some of these new functions like REMOVE, they're buried in code that I've long since relegated to being taught wrong. MV allows for so many choices when solving a single problem that despite all working, some work better than the others. Then it's a personal preference. My 3 cents. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, July 15, 2005 12:46 AM Subject: RE: [U2] THE variable names wow. I can't believe how touchy people get about the simplest comments. I am also surprised at the assumptions that get made in order to flame back at some perceived insult. Why do you assume anything about how long I've been at this game, my abilities or the size of my bank account ? And how is any of that even relevant ? For the record, I wasn't slandering old pros. I was slandering old 'pros' that haven't picked up a manual in 20 years - big difference. The comment was made in response to the statement that 'newer' ( ie. post 1970's ) language features shouldn't be used as they would confuse the 'old timers'. If you are current in the profession then what I said was in no way directed at you - so why the indignation ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, July 14, 2005 11:16 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Don't cast such stones on us 'old pro's. Many of us have spent more time with these older systems prior to the current system than many have with their only systems. There is an evolution with these MV systems that allows us to be a little cautious of new, platform specific 'features'. At present I have active accounts in Microdata, UV, UD, AP-Pro, D3, MvBase and R90. All support DCOUNT etc and it gets a little hard to remember which system supports REMOVE or SELECT TO. I for one got a little tired with the LOCATE differences and the EXECUTE/PERFORM syntaxes. So I go with the trusted, comprehensive methods. My productivity isn't hampered by using DCOUNT instead of REMOVE. I won't yield to a cpu cycle argument either. Given the tremendous amount of poor programming that I have inherited these last 27 years, I feel pretty good about my abilities (and bank account) in MV programming. I just removed 680 lines from a 900 line program that needed a repair. Since I'm the current cook in the kitchen at my
Re: [U2] THE variable names
In a message dated 7/15/05 7:19:42 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. Not directed at you Mark, but someone mentioned that Remove has been around a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. And I still find it much more confusing that simply SELECTing a variable to another variable. That to me is more intuitive. REMOVE was definitely not a part of the '79 Microdata environment. Anyone who says so will have to post a scan of that page from the manual to convince me :) It certainly was not in the Ultimate Honeywell/Bull and was not a part of the Fujitsu or C.Itoh environment. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Thanks for your support. I don't recall REMOVE in the late 70's circa MCD either, nor in any of the code that MSL/DCT created. I've only heard of it on this forum. My present UD/UV clients have code converted from Jurrasic environments so that's why it doesn't show up there either. I am not in a forward-writing environment with UD/UV, just maintenance and some tweaks. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, July 15, 2005 5:47 PM Subject: Re: [U2] THE variable names In a message dated 7/15/05 7:19:42 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Not to throw a punch, but the UD/UV manuals are harder to read than the D3 ones are, especially without an overall index. So perhaps this influences me to not look for REMOVE. Not directed at you Mark, but someone mentioned that Remove has been around a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. And I still find it much more confusing that simply SELECTing a variable to another variable. That to me is more intuitive. REMOVE was definitely not a part of the '79 Microdata environment. Anyone who says so will have to post a scan of that page from the manual to convince me :) It certainly was not in the Ultimate Honeywell/Bull and was not a part of the Fujitsu or C.Itoh environment. Will Johnson --- 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] THE variable names
Will Johnson wrote on 07/15/2005 05:47:27 PM: someone mentioned that Remove has beenaround a long time. Not so. REMOVE was not added to the ADDS environment until perhaps around the mid 80s or so. That's only twenty years ago - a mere two decades. The paint isn't even dry on it yet. How are we supposed to keep up with this rate of change? ;-) 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] THE variable names
Don't cast such stones on us 'old pro's. Many of us have spent more time with these older systems prior to the current system than many have with their only systems. There is an evolution with these MV systems that allows us to be a little cautious of new, platform specific 'features'. At present I have active accounts in Microdata, UV, UD, AP-Pro, D3, MvBase and R90. All support DCOUNT etc and it gets a little hard to remember which system supports REMOVE or SELECT TO. I for one got a little tired with the LOCATE differences and the EXECUTE/PERFORM syntaxes. So I go with the trusted, comprehensive methods. My productivity isn't hampered by using DCOUNT instead of REMOVE. I won't yield to a cpu cycle argument either. Given the tremendous amount of poor programming that I have inherited these last 27 years, I feel pretty good about my abilities (and bank account) in MV programming. I just removed 680 lines from a 900 line program that needed a repair. Since I'm the current cook in the kitchen at my clients, I have to take responsibility for any problems that creep up when I change a program. I may be tweaking lines 100-115 and when the fresh compile produces a new error at line 580, it's now my problem. As with other debatable elements, there will always be 2 solutions to every program. What started out as a curiosity with the THE prefixes, ended up with slandering against the senior members of this forum. Not read the manual in 20 years? We've probably written the one you're reading now. My 1 cent. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 12, 2005 9:53 AM Subject: RE: [U2] THE variable names not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 03:59 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/10/2005 6:18:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE :) Will Johnson --- 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] THE variable names
wow. I can't believe how touchy people get about the simplest comments. I am also surprised at the assumptions that get made in order to flame back at some perceived insult. Why do you assume anything about how long I've been at this game, my abilities or the size of my bank account ? And how is any of that even relevant ? For the record, I wasn't slandering old pros. I was slandering old 'pros' that haven't picked up a manual in 20 years - big difference. The comment was made in response to the statement that 'newer' ( ie. post 1970's ) language features shouldn't be used as they would confuse the 'old timers'. If you are current in the profession then what I said was in no way directed at you - so why the indignation ? Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, July 14, 2005 11:16 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Don't cast such stones on us 'old pro's. Many of us have spent more time with these older systems prior to the current system than many have with their only systems. There is an evolution with these MV systems that allows us to be a little cautious of new, platform specific 'features'. At present I have active accounts in Microdata, UV, UD, AP-Pro, D3, MvBase and R90. All support DCOUNT etc and it gets a little hard to remember which system supports REMOVE or SELECT TO. I for one got a little tired with the LOCATE differences and the EXECUTE/PERFORM syntaxes. So I go with the trusted, comprehensive methods. My productivity isn't hampered by using DCOUNT instead of REMOVE. I won't yield to a cpu cycle argument either. Given the tremendous amount of poor programming that I have inherited these last 27 years, I feel pretty good about my abilities (and bank account) in MV programming. I just removed 680 lines from a 900 line program that needed a repair. Since I'm the current cook in the kitchen at my clients, I have to take responsibility for any problems that creep up when I change a program. I may be tweaking lines 100-115 and when the fresh compile produces a new error at line 580, it's now my problem. As with other debatable elements, there will always be 2 solutions to every program. What started out as a curiosity with the THE prefixes, ended up with slandering against the senior members of this forum. Not read the manual in 20 years? We've probably written the one you're reading now. My 1 cent. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 12, 2005 9:53 AM Subject: RE: [U2] THE variable names not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 03:59 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/10/2005 6:18:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE :) Will Johnson --- 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] THE variable names
What systems DON'T support REMOVE? I cut my teeth in the MV world back in 1979 on Microdata Reality, and it had REMOVE. Since then I've worked on a variety of other MV systems, including Ultimate, Prime Information, UniVerse and UniData, among others that I've probably forgotten. I can't recall any of them that didn't support REMOVE. Larry Hiscock Western Computer Services -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Thursday, July 14, 2005 8:16 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names Don't cast such stones on us 'old pro's. Many of us have spent more time with these older systems prior to the current system than many have with their only systems. There is an evolution with these MV systems that allows us to be a little cautious of new, platform specific 'features'. At present I have active accounts in Microdata, UV, UD, AP-Pro, D3, MvBase and R90. All support DCOUNT etc and it gets a little hard to remember which system supports REMOVE or SELECT TO. I for one got a little tired with the LOCATE differences and the EXECUTE/PERFORM syntaxes. So I go with the trusted, comprehensive methods. My productivity isn't hampered by using DCOUNT instead of REMOVE. I won't yield to a cpu cycle argument either. Given the tremendous amount of poor programming that I have inherited these last 27 years, I feel pretty good about my abilities (and bank account) in MV programming. I just removed 680 lines from a 900 line program that needed a repair. Since I'm the current cook in the kitchen at my clients, I have to take responsibility for any problems that creep up when I change a program. I may be tweaking lines 100-115 and when the fresh compile produces a new error at line 580, it's now my problem. As with other debatable elements, there will always be 2 solutions to every program. What started out as a curiosity with the THE prefixes, ended up with slandering against the senior members of this forum. Not read the manual in 20 years? We've probably written the one you're reading now. My 1 cent. Mark Johnson - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 12, 2005 9:53 AM Subject: RE: [U2] THE variable names not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 03:59 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/10/2005 6:18:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE :) Will Johnson --- 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] THE variable names
The oldest universe manual I have is dated from Spring1983 and is actually for upix, universes' original name. There is no INFORMATION flavor documented and REMOVE does not exist. Ancient? :-) _ I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/12/2005 07:58 PM Please respond to u2-users To u2-users@listserver.u2ug.org cc Subject Re: [U2] THE variable names In a message dated 7/12/05 4:51:27 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: ( REMOVE() function ) is a feature that has been around for how many years ? the oldest universe manuals I have are 17 years old and there it is. ditto for DCOUNT(). 17 years? You're a beginner :) Will Johnson --- 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] THE variable names
The oldest universe manual I have is dated from Spring1983 and is Yeah yeah, SOMEBODY had to go look ... grin Can we throw the inevitable my manuals are older/wiser/more dog-eared/obsolete than yours discussions over to the community list? Brian Walking on hind legs? That'll never catch on --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
snip The oldest universe manual I have is dated from Spring1983 and is actually for upix, /snip Glenn, I really think it's time for you to clean your cubicle... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/10/2005 6:18:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE :) Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Warning ! In this thread we've seen three looping mechanisms been presented as equivalent ( pairwise, first i and ii then ii and iii): i) N = DCOUNT( PRODS,@VM) FOR II=1 TO N X = PRODS1,II ... NEXT II ii) LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT iii) SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE They are not! i) extracts full values regardless of the presence of lower level marks in them. ii) extracts the smallest items between marks of any level iii) extracts fields ( attibutes ) . except in the common case that there is only one level of marks (and that the first and third are adjusted to that level of course ) -- mats --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
snip (Why else is COUNT(VAR,@FM)+(VAR NE ) syntax so popular?) \snip Because there is a real difference between COUNT and DCOUNT. COUNT counts the number of delimiters and DCOUNT counts the number of elements being delimited. Sort of backwards but accurate. Thus A=mark would have COUNT(A,@VM) have a value of 0 while DCOUNT(A,@VM) would be 1. DCOUNT on null string returns 0. Nice. The addition of the +(VAR NE ) adds the needed '1' to whatever COUNT produced. my 1 cent. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Does that work. PRODS was not a File handle. Is there some magic that turns a mv'd variable into a file handle. Besides, if it did work, you would lose the included MV variable for use with associated fields or would have to manage by hand. Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
[EMAIL PROTECTED] wrote: snip (Why else is COUNT(VAR,@FM)+(VAR NE ) syntax so popular?) snip Because there is a real difference between COUNT and DCOUNT. COUNT counts the number of delimiters and DCOUNT counts the number of elements being delimited. Sort of backwards but accurate. Thus A=mark would have COUNT(A,@VM) have a value of 0 while DCOUNT(A,@VM) would be 1. DCOUNT on null string returns 0. Nice. The addition of the +(VAR NE ) adds the needed '1' to whatever COUNT produced. You seem to have missed the point ... to quote a previous post of yours REMOVE is not universally available on all MV platforms. DCOUNT is. Read my earlier post. All I was asking was why was the COUNT version popular if DCOUNT was available? That's the point - it WASN'T available. Cheers, Wol --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
I'm just wondering who comes up with this stuff. Those who use the language to it's most interpretable form. I have seen general BASIC programming instructors focus on the use of non-cryptic, non-abbreviated variables, instead of compact code. Afterall, the pcode generated is the same for THE.CUSTOMER.CITY as it is for CCITY or CUST_CITY. Which can you comprehend the quickest at a glance? You can also parse your own code, if you have a delimited variable structure that is consistent throughout the entire project. All good things, unless you're main focus is keeping the code short and cryptic. I have to agree, though, that THE is not really a useful variable keyword. It does help with programmatic variable identification, though. To each his own. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= I use the else null clause religiously under D3. I have seen numerous accounts of read failures not resetting the target variable. The program chugs along happily with data from a previous read and it eventually blows up for a seemingly unknown reason. The extra null assignment is overkill, unless it exists once at the start of the program to prevent variable not assigned run-time notices. Glen --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
I'll second Mats, and move to add an amendment: iii) SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE iii) extracts fields ( attributes ) . READNEXT PROD ELSE ... extracts the ENTIRE 1st VALUE of each field (i.e., including ALL SUBvalues of that 1st value) but ignores any other values. Notice A|a and B|b disappear from being the scene: RDNXTTST 01 ARRAY = CONVERT( ' ;.', @SM:@VM:@AM, '1 one;A a.2 two;B b' ) 02 CRT ARRAY 03 SELECT ARRAY 04 LOOP WHILE READNEXT X 05CRT X 06 REPEAT RUN CDS.BP RDNXTTST 1|one}A|a~2|two}B|b 1|one 2|two That said, I'll concede it can be a useful technique. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 03:59 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/10/2005 6:18:39 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT Why use Remove? It's unfamiliar to more oldtimers and requires use of SETTING. Just SELECT PRODS and then READNEXT PROD ELSE DONE = TRUE :) Will Johnson --- 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] THE variable names
In a message dated 7/12/2005 5:35:07 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: Does that work. PRODS was not a File handle. Is there some magic that turns a mv'd variable into a file handle. Besides, if it did work, you would lose the included MV variable for use with associated fields or would have to manage by hand. Yes it works. Yes there is magic. And no you don't lose the variable its there just find the way it was, never knowing what malicious thing you've done to it's shadow. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
In a message dated 7/12/2005 7:06:38 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? You're write. Code to the most obtuse style. That way you ensure job security :) Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
i may be correct - though i'm fairly sure i'm not 'write'. actually i don't see where obtuse comes into it. its simply a matter of keeping current in your profession. especially when the specific case in point ( REMOVE() function ) is a feature that has been around for how many years ? the oldest universe manuals I have are 17 years old and there it is. ditto for DCOUNT(). Gerry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 01:21 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] THE variable names In a message dated 7/12/2005 7:06:38 AM Pacific Daylight Time, [EMAIL PROTECTED] writes: not trying to start anything - but was this intended as a joke ? I read this as : don't use current language features because the old 'pros' who haven't picked up a manual in 20 years won't understand it ? You're write. Code to the most obtuse style. That way you ensure job security :) Will Johnson --- 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] THE variable names
In a message dated 7/12/05 4:51:27 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: ( REMOVE() function ) is a feature that has been around for how many years ? the oldest universe manuals I have are 17 years old and there it is. ditto for DCOUNT(). 17 years? You're a beginner :) Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
At 08:29 -0400 2005/07/12, Mark Johnson wrote: Why use Remove? It's unfamiliar to more oldtimers For a number of systems, it's faster if you're just pulling off fields or values.* Also it's the same form if the list is @FM, @VM, @SM or @TM separated, so there's no need to do one ore more RAISE()s. And for folks that started with uv or udt, instead of one of the more Pick-like flavors, using SELECT on a non-file variable is very unfamiliar and counter intuitive. Ray *If you're really trying to save clock cycles, do a benchmark, sometimes the REMOVE statement is slower than the REMOVE() function. -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
Mark Johnson wrote on Sun, 10 Jul 2005 23:12:25 -0400 I'll yield to the REMOVE for this U2 forum. ... - Original Message - From: Womack, Adrian [EMAIL PROTECTED] Mark, I don't like your example... snip REMOVE example I've never understood this need some programmers have for COUNTing the elements in an array - who cares who many there are? Usually the program just needs to process *all* of them. The problem I have with REMOVE is that it only returns up to the next delimiter. If you have subvalue marks, you only get the first subvalue, rather than the list. Of course you can check the delimiter after each REMOVE, but in a case like this, I prefer to SELECT to a list variable and READNEXT each item. So, instead of: PRODS=ORD15 C.PRODS=DCOUNT(PRODS,CHAR(253)) FOR I=1 TO C.PRODS PROD=PRODS1,I NEXT I I prefer: PROD.LIST = PRODS = RAISE(ORD15) SELECT PRODS TO PROD.LIST LOOP WHILE READNEXT PROD FROM PROD.LIST DO ... REPEAT (And in this case, the PROD.LIST = prevents a compiler warning about unitialized variables...) --Tom Pellitieri Century Equipment Toledo, Ohio --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
I also use the THE. Or A Is just something I do in order to assure the variable is unique and not used in commons. Likely due to my background from as a var employee, working on various clients systems and never being quite sure of what is used in commons and want is not, and knowing the client doesn't want to pay me to do the research to find out. Thanks, Marilyn A. Hilb Value Part, Inc Direct: 847-918-6099 Fax: 847-367-1892 [EMAIL PROTECTED] www.valuepart.com -Original Message- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Sunday, July 10, 2005 8:54 AM To: u2-users@listserver.u2ug.org Subject:[U2] THE variable names This ain't rocket science but it piques my curiosity. I've just acquired another client who's system contains an extrodinary use of the prefix THE in front of extracted values within a FOR/NEXT or LOOP and labels. READ CUST FROM blah, blah C=DCOUNT(CUST15,@VM) FOR I=1 TO C THE.SALESMAN=CUST15,I NEXT I I've seen this before but not to the extent on this client. The application appears older (mid 1980's) and certainly homegrown. I'm just wondering who comes up with this stuff. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= Again, not rocket science. Thanks --- 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] THE variable names
In message [EMAIL PROTECTED], Mark Johnson [EMAIL PROTECTED] writes REMOVE is not universally available on all MV platforms. DCOUNT is. Read my earlier post. Okay, I'm going back a bit, but if you've got any old INFORMATION systems you might well find DCOUNT isn't available ... Like a lot of things, they added it shortly before they disappeared :-( Cheers, Wol (Why else is COUNT(VAR,@FM)+(VAR NE ) syntax so popular?) -- 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] THE variable names
Mark, I've used CURR (current) in the same way in many programs. I'm a 1983 vintage programmer who learned mostly from guys who had five years seniority over me. I've never done the untrusted READ thing, though. - Chuck Older Than I Look, But Starting to Look My Age Barouch Mark Johnson wrote: This ain't rocket science but it piques my curiosity. I've just acquired another client who's system contains an extrodinary use of the prefix THE in front of extracted values within a FOR/NEXT or LOOP and labels. READ CUST FROM blah, blah C=DCOUNT(CUST15,@VM) FOR I=1 TO C THE.SALESMAN=CUST15,I NEXT I I've seen this before but not to the extent on this client. The application appears older (mid 1980's) and certainly homegrown. I'm just wondering who comes up with this stuff. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= -- Charles Barouch CTO Key Ally, Inc. http://www.KeyAlly.com P. O. Box 540957 Queens, NY 11354 USA Work: (718) 762-3884x1 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Professional Profile https://www.linkedin.com/e/fps/1501071/ Mount Olympus Systems http://www.MtOlympus.us See who we know in common https://www.linkedin.com/e/wwk/1501071/ Want a signature like this? https://www.linkedin.com/e/sig/1501071/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] THE variable names
Well, if you remember that pick includes throwaway connectives to allow users to make their LIST and SORTs as verbose as desirable, having a variable like THE.SALESMAN doesn't seem so strange. I don't know about that paranoid read. My guess is that someone had a variable not assigned error, and just panicked when they couldn't resolve it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Sunday, July 10, 2005 9:54 AM To: u2-users@listserver.u2ug.org Subject: [U2] THE variable names This ain't rocket science but it piques my curiosity. I've just acquired another client who's system contains an extrodinary use of the prefix THE in front of extracted values within a FOR/NEXT or LOOP and labels. READ CUST FROM blah, blah C=DCOUNT(CUST15,@VM) FOR I=1 TO C THE.SALESMAN=CUST15,I NEXT I I've seen this before but not to the extent on this client. The application appears older (mid 1980's) and certainly homegrown. I'm just wondering who comes up with this stuff. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= Again, not rocket science. Thanks --- 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] THE variable names {Unclassified}
Mark, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Sunday, July 10, 2005 9:54 AM To: u2-users@listserver.u2ug.org Subject: [U2] THE variable names [snip] REC= ; READ REC FROM FILE, ID ELSE REC= Maybe this system was converted from a platform where the ELSE automatically set the REC to (PI, for example IIRC) to one where it didn't (UV for instance), and the 'REC= ; ' was inserted by a conversion program before every 'READ ...' statement? [For what it's worth, if I was looking at that code, I'd quietly re-factor out all the redundant 'REC= ; ' statements.] Mike The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
I guess it's a preference. I often load in the MVable fields into plural variables and use their single form. PRODS=ORD15 C.PRODS=DCOUNT(PRODS,CHAR(253)) FOR I=1 TO C.PRODS PROD=PRODS1,I NEXT I I had just noticed the THE for around the 4th time. Another use was the labeling of a REPEAT prior to the implementation (or knowledge of) CONTINUE. LOOP READNEXT ID ELSE EOF=1 READ CUST FROM F.CUST, ID ELSE GOTO THE.REPEAT blah, blah THE.REPEAT:* REPEAT mark - Original Message - From: Key Ally [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, July 10, 2005 2:56 PM Subject: Re: [U2] THE variable names Mark, I've used CURR (current) in the same way in many programs. I'm a 1983 vintage programmer who learned mostly from guys who had five years seniority over me. I've never done the untrusted READ thing, though. - Chuck Older Than I Look, But Starting to Look My Age Barouch Mark Johnson wrote: This ain't rocket science but it piques my curiosity. I've just acquired another client who's system contains an extrodinary use of the prefix THE in front of extracted values within a FOR/NEXT or LOOP and labels. READ CUST FROM blah, blah C=DCOUNT(CUST15,@VM) FOR I=1 TO C THE.SALESMAN=CUST15,I NEXT I I've seen this before but not to the extent on this client. The application appears older (mid 1980's) and certainly homegrown. I'm just wondering who comes up with this stuff. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= -- Charles Barouch CTO Key Ally, Inc. http://www.KeyAlly.com P. O. Box 540957 Queens, NY 11354 USA Work: (718) 762-3884x1 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Professional Profile https://www.linkedin.com/e/fps/1501071/ Mount Olympus Systems http://www.MtOlympus.us See who we know in common https://www.linkedin.com/e/wwk/1501071/ Want a signature like this? https://www.linkedin.com/e/sig/1501071/ --- 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] THE variable names {Unclassified}
The majority of my business is acquiring new clients with existing long-term
MV systems. Thus I inherit a lot of stuff as opposed to working with a
single company or a VAR with more continuous programming.
Since I'm the current cook in the kitchen and I'm asked to investigate a
problem or enhance an existing program, I inherit whatever mess there was
(is).
Since I'm now responsible for whatever changes are made, I take the
opportunity to tighten up the code when possible. Not re-write, but replace
any obviously awkward methods. I have had more than a few instances where
the source code wasn't in sync with the object code and when I recompile for
a simple change, I get new errors in another part of the program.
I can illustrate many horrors over the years with these code examples. What
doesn't kill me can only make me stronger. What's that phrase...It isn't
completely useless. It can always serve as a bad example.
Mark
- Original Message -
From: HENDERSON MIKE, MR [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Sunday, July 10, 2005 6:12 PM
Subject: RE: [U2] THE variable names {Unclassified}
Mark,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson
Sent: Sunday, July 10, 2005 9:54 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] THE variable names
[snip]
REC= ; READ REC FROM FILE, ID ELSE REC=
Maybe this system was converted from a platform where the ELSE
automatically set the REC to (PI, for example IIRC) to one where it
didn't (UV for instance), and the 'REC= ; ' was inserted by a
conversion program before every 'READ ...' statement?
[For what it's worth, if I was looking at that code, I'd quietly
re-factor out all the redundant 'REC= ; ' statements.]
Mike
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence
Force.
If you are not the intended recipient you must not use, disclose, copy or
distribute this message or the information in it.
If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
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] THE variable names
Mark, I don't like your example... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson PRODS=ORD15 C.PRODS=DCOUNT(PRODS,CHAR(253)) FOR I=1 TO C.PRODS PROD=PRODS1,I NEXT I I'd *much* prefer that written as... LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT I've never understood this need some programmers have for COUNTing the elements in an array - who cares who many there are? Usually the program just needs to process *all* of them. DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
On Sun, 10 Jul 2005 09:54:12 -0400, you wrote: This ain't rocket science but it piques my curiosity. I've just acquired another client who's system contains an extrodinary use of the prefix THE in front of extracted values within a FOR/NEXT or LOOP and labels. READ CUST FROM blah, blah C=DCOUNT(CUST15,@VM) FOR I=1 TO C THE.SALESMAN=CUST15,I NEXT I I've seen this before but not to the extent on this client. The application appears older (mid 1980's) and certainly homegrown. I'm just wondering who comes up with this stuff. That's possibly written by someone who learned to code in COBOL, IE, totally self-documenting code. Also, was there ever any lack of faith in the READ statement when assigning the variable REC. I'm now seeing some of this: REC= ; READ REC FROM FILE, ID ELSE REC= If coded like this, then you can do operations on REC without it failing with a variable unassigned error. So, instead of branching on the READ ELSE, you branch later based on the value of RECn. -- Allen Egerton [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] THE variable names
REMOVE is not universally available on all MV platforms. DCOUNT is. Read my earlier post. I'll yield to the REMOVE for this U2 forum. But I will provide a reason for using DCOUNT for another purpose. I don't trust the X5,-1=VAL when applied to an associated set of fields. Somehow, somewhere one of the appended values will contain a null and the set will shift. Thus MV=DCOUNT(X5@VM) MV=MV+1 X5,MV=VAL X6,MV=ANOTHER VAL X7,MV=VAL.THATS.NULL X8,MV=MORE.VAL will always keep the mv'd set intact. Glad to tickle a response. Mark Johnson - Original Message - From: Womack, Adrian [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, July 10, 2005 9:09 PM Subject: RE: [U2] THE variable names Mark, I don't like your example... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson PRODS=ORD15 C.PRODS=DCOUNT(PRODS,CHAR(253)) FOR I=1 TO C.PRODS PROD=PRODS1,I NEXT I I'd *much* prefer that written as... LOOP REMOVE PROD FROM PRODS SETTING MORE.PRODS ...do stuff... WHILE MORE.PRODS REPEAT I've never understood this need some programmers have for COUNTing the elements in an array - who cares who many there are? Usually the program just needs to process *all* of them. DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- 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/
