Re: [U2] Error in report generation.
In message [EMAIL PROTECTED], Norman Morgan [EMAIL PROTECTED] writes I'm with you on the CAPS issue. I do find the code in caps easier to read. Perhaps I'm just used to it from the first 20 years of my career spent writing COBOL. I think the layout of the code and choice of variable and paragraph names has more to do with readability that whether it is upper or lower case. When I started programming (FORTRAN IV) I was using Newbury terminals (iirc). They didn't have lower case! We got a couple of newer ones that did, that went to the secretaries for wordprocessing, and finally I ended up with a brand new PT45 beehive terminal. That was nice :-) 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] Error in report generation.
On 14/03/07, MAJ Programming [EMAIL PROTECTED] wrote: How does using upper case make a programmer primitive? Considering that beaucoups of prior source code is in pure upper case, it would be hard to cost justify changing the case for its own sake. Accuterm's WED program editor allows you to assign different colors to comments, variables, statements, labels and text. Thus, the readability of a pure upper case system is enhanced through color. shameless AD Everyone should give WED a try. Besides the colors, it's indentable, you can double click on a label, CALL reference or an INCLUDE and it jumps to those code sections. All the standard Notepad MS feel. Multiple screens. /shameless AD Most people on here will have unidebugger or wintegrates editor which do exactly the same, if not better than WED. I really dont think many people use ED anymore, not for 10 years or so ! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
On 14/03/07, MAJ Programming [EMAIL PROTECTED] wrote: I'm gonna throw my 4 cents in to hopefully stop this excessive coding. or this doozy of a mess OPEN FILE1 TO F.FILE1 THEN OPEN FILE2 TO F.FILE2 THEN OPEN FILE3 TO F.FILE3 THEN 500 LINES OF PROCESSING AS PER APPLICATION END ELSE PRINT CAN'T OPEN FILE3 END END ELSE PRINT CAN'T OPEN FILE2 END END ELSE PRINT CAN'T OPEN FILE1 END Please, lets not spend so much effort on this simple task. OPEN them and get on with it. However the above is essential if you have to return a message to a controlling program or web service say and not just stop execution !! Thats why i prefer a function for file operations rather than a sub then you can do IF fileOpenFunc(filename,options,filevar,etc) THEN blah END ELSE Err = blah END --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Error in report generation.
Sorry Brian, but I can read the second one a lot better then the firstbut that's because I am looking for uppercase words, mixed case never looks neat to me. Les Sherlock Hewkin Project Manager - Financial Systems 01604 592289 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 14 March 2007 09:16 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Error in report generation. Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ html head meta http-equiv=Content-type content=text/html; charset=UTF-8 /head body P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. /SPAN/P /BODY /HTML --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
I use ED (or EDIT) every single day. I don't use WED for data or dictionaries as I can create dict items blindly in my sleep and with data, there is the accidental chance of a stray enter shifting the fields down. For a simple program change, I use ED. If I'm spending any significant time playing with a program, then WED is great. I promote WED whenever I can. The support is beyond 100% great. Mark Johnson - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, March 14, 2007 4:05 AM Subject: Re: [U2] Error in report generation. On 14/03/07, MAJ Programming [EMAIL PROTECTED] wrote: How does using upper case make a programmer primitive? Considering that beaucoups of prior source code is in pure upper case, it would be hard to cost justify changing the case for its own sake. Accuterm's WED program editor allows you to assign different colors to comments, variables, statements, labels and text. Thus, the readability of a pure upper case system is enhanced through color. shameless AD Everyone should give WED a try. Besides the colors, it's indentable, you can double click on a label, CALL reference or an INCLUDE and it jumps to those code sections. All the standard Notepad MS feel. Multiple screens. /shameless AD Most people on here will have unidebugger or wintegrates editor which do exactly the same, if not better than WED. I really dont think many people use ED anymore, not for 10 years or so ! --- 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] Error in report generation.
I am with Brian in this one - everything i do inlife is mixed case, different programming languages, emails, letters etc. All upercase looks a mess to me. Rgds Symeon. On 14/03/07, Les Hewkin [EMAIL PROTECTED] wrote: Sorry Brian, but I can read the second one a lot better then the firstbut that's because I am looking for uppercase words, mixed case never looks neat to me. Les Sherlock Hewkin Project Manager - Financial Systems 01604 592289 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 14 March 2007 09:16 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Error in report generation. Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ html head meta http-equiv=Content-type content=text/html; charset=UTF-8 /head body P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'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. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. /SPAN/P /BODY /HTML --- 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] Error in report generation.
I never indicated that one should not have the Can't Open message. I just laugh at the prior programmer's methods. My OPENER subroutine is as follows: SUBROUTINE OPENER(FILENAME, FILEHANDLE) OPEN FILENAME TO FILEHANDLE ELSE PRINT CANNOT OPEN :FILENAME:. PRESS ENTER :;INPUT ANS CHAIN M END RETURN I also have a blind version that I've used for a Redback Project. SUBROUTINE RB.OPENER(FILENAME, FILEHANDLE, ERRMSG) OPEN FILENAME TO FILEHANDLE ELSE ERRMSG-1= CANNOT OPEN :FILENAME END RETURN One thing that I will stand by is to not be afraid of posting my code samples and wait for the flames to come. Don't attack my CHAIN M because another app may have another bail out for the failed OPEN. Just appreciate the simplicity of having thousands of OPEN statements use the same singular Can't Open routine. It does take someone with some cajones to show their cards for everyone else to critique. I'm the first person to be interested in a better way of coding as it makes my life easier. In fact, one of my Mvbase client's systems was written by a programmer who clearly didn't know enough functions. It's a terrible mess of disconnected thoughts but, at the end of the day, it compiles and one plus one equals two. While I critique that code, I did manage to find a nice snippet that I've added to my mental library of snippets. Yes, one can teach an old dog new tricks. The issue is that many programmers don't want to learn another (perhaps better) method for the same objective. Thus poor techniques are perpetuated and the newbies see the old guys doing them so they buy into it. Unless there becomes an overall MV standard (never happen), MV programming will continue to be the blank sheet of paper with a box of crayons that, if it compiles, it's a program. I'm not condoning or promoting poor habits. I'm just throwing up my 2 cents on what I think is poor and what I think is good. If someone wants to type the tired EOF=FALSE;LOOP;READNEXT ID ELSE;EOF=TRUE;END;UNTIL EOF DO mess for the rest of their lives as that's what they learned first (and once), then that's their decision. I just don't think that it should be endorsed as THE 'standard' method as our MV environment is incredibly absent of standards. Styles, yes. Local standards, sure, Overall standards, hardly. Respectfully Mark Johnson - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, March 14, 2007 4:10 AM Subject: Re: [U2] Error in report generation. On 14/03/07, MAJ Programming [EMAIL PROTECTED] wrote: I'm gonna throw my 4 cents in to hopefully stop this excessive coding. or this doozy of a mess OPEN FILE1 TO F.FILE1 THEN OPEN FILE2 TO F.FILE2 THEN OPEN FILE3 TO F.FILE3 THEN 500 LINES OF PROCESSING AS PER APPLICATION END ELSE PRINT CAN'T OPEN FILE3 END END ELSE PRINT CAN'T OPEN FILE2 END END ELSE PRINT CAN'T OPEN FILE1 END Please, lets not spend so much effort on this simple task. OPEN them and get on with it. However the above is essential if you have to return a message to a controlling program or web service say and not just stop execution !! Thats why i prefer a function for file operations rather than a sub then you can do IF fileOpenFunc(filename,options,filevar,etc) THEN blah END ELSE Err = blah END --- 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] Error in report generation.
I just knew that I was going to get a reply in all uppercase. One of my non-mv functions is of desktop publishing which requires font selection for purpose and appeal. I've since learned a whole bunch about casing that I will share now. First, you are right. Getting a human communication like your reply in all uppercase is hard to read. Here's why. Humans don't read by assembling the letters into a word, we read by recognizing the overall image of the printed word and converting it into its meaning. Thus, the incredibly random nature of regular conversation supports this theory. We're used to reading textbooks, letters, magazines with mixed casing and as such, can develop those recognition habits. Headlines are done in all uppercase to disrupt the natural tendancy to read them too quickly, thus you dwell on the headline a little longer. Mission accomplished. We sometimes wonder how the Chinese can have thousands of 'pictures' representing their words but it becomes word (not letter) recognition. Thus the word Fred is actually a symbol in out reading recognition. FRED is the same word but not read that often and therefore causes a slight delay. Here's the programming analogy. We programmers have a limited library of commands that we can type in a basic program. Thus, we have accidentally gotten used to reading CALL instead of call over the years and CALL is more recognizable in our brains in that context. If there are 15,000 words in our conversational language to 'recognize', there may only be 100 words that we need to recognize as commands and/or variable names. Did you ever see a poster or bumper sticker written in a font that wasn't easy to read, like Olde English or one of the more cursive fonts. Notice that it's harder to read. It's still English but it takes more time. I critique the overuse of excessive fonts as they slow down the message. Note that most traffic signs are in all uppercase and a simple font like helvetica. They need our attention (upper case) and can't be in Olde English. STOP is a whole lot more effective than Stop. (I tried to change the fonts but that would get me in more trouble). Thus, while contemporary MV languages support mixed casing, it's actually harder for me as 90% of what I work on is inherited. The other 10% of my MV stuff is also upper case BTW. VB promotes mixed casing for the absense of using the dot in a variable name so it makes sense there. Plus, it has its own brain converting vbtrue to vbTrue. I'm not an old dog refusing to abandon upper case just for its own sake. I've made a conscious decision to use what works best and most effecient given the environment. As this old dog, I actually read the second example better. You are right when it comes from the influence of other environments. As my professional world is 95% MV, 2% VB and 2% Access, my brain processes accordingly. Question: Is ReadNext the same as readnext, readNext, Readnext, rEaDnExT and READNEXT? I'm guessing that it is as the compiler may have a casing flag set. I will admit that I have a personal issue with the D3 lower case version of Basic and have been stung with ITEM-ID's getting screwed up if using mixed case. I'll ask one more thing to Brian. Would you consider retiring your time-honored 5 line READNEXT scenario in favor or using Loop While Readnext Id From MYLIST Do My 4 cents Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, March 14, 2007 4:16 AM Subject: Re: [U2] Error in report generation. Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id
Re: [U2] Error in report generation.
I must be backwards because I actually find the second one easier to read and cleaner. And faster to type! Of course, I guess I'm one of the old-timers, having been in multi-value for 25 years now. -Dianne [EMAIL PROTECTED] wrote: Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
All, For my two cents, I *rarely* code in mixed case when I'm in an MV environment. I use upper/lower in comments to make them stand out - a trick I adopted from my friend Scott Lustig. Having said that, I believe that the future is, as Brian suggests, in making our code look more like everyone else's code. I don't go there eagerly, but I will continue to move in that direction. The alternative to my mind, is to build a time machine, go back and kill off Charlemane - who popularized this lower case business - and have done with the whole conflict. Failing that, we need to accept that language (computer or human) is designed to communicate. If we expect our code to work for a wider audience, we need to dress it appropriately. That means mixed case, comments, code-coding editors, and all sorts of other things that have nothing to do with the compilation but have everything to do with publishable examples and readable code. My big complaint about all programmers in all environments, including myself, is that it is close to *evil* to do anything simply because it let's you write code faster. This is what I mean: given that we read and modify code much more often than we write fresh code, it is short sighted to do anything to speed writing when detracts from readability or maintainability. If a single letter variable is easy to type, but hard to find when debugging, it is evil. If a GOTO is faster when writing but makes the program harder to trace, it is evil. Note: I don't think GOTO is evil, in and of itself. I think that sprinkling it like fairy dust all over programs, so that I have to read a thousand lines of code to see if a particular block is used (and when it is used), should be banned universally across all programing languages. Having a set GOTO that unifies all exit conditions on every program (GOTO CLEANUP) is a great idea. having thirty or forth GOTOs, many of the unique to a given program, that's a recipe for sucking up my time to little purpose. I'd rather have someone, whom I pay by the hour, double the time it takes to write new code if they can halve the time it takes to research, modify, and the maintain code. A program which takes an hour to write and a day to debug each time it has a problem is a bad trade. Give me meaningful variable names, ever for loop variables, any day. -- Charles Barouch ([EMAIL PROTECTED]) www.KeyAlly.com (718) 762-3884 x 1 P. O. Box 540957, Queens, NY 11354 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Error in report generation.
snip
... all uppercase is hard to read. Here's why.
Humans don't read by assembling the letters into a word, we read by
recognizing the overall image of the printed word and converting it into
its meaning. Thus, the incredibly random nature of regular conversation
supports this theory. We're used to reading textbooks, letters,
magazines with mixed casing and as such, can develop those recognition
habits.
/snip
The other thing that makes lower case easier to read than upper case is
that lower case letters have more variability amongst themselves than do
upper case, due to ascenders and descenders (e.g. bdfghijklpqrty). The
more variation between letters, the quicker one's brain can identify
them. (This is obviously a personal preference, perhaps based on how
your brain was imprinted when you first learned to read {code}.) Maybe
this is why some people find proportional fonts easier to read - those
characters vary in width as well as height.
Just a thought,
/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Error in report generation.
I'm with you on the CAPS issue. I do find the code in caps easier to read. Perhaps I'm just used to it from the first 20 years of my career spent writing COBOL. I think the layout of the code and choice of variable and paragraph names has more to do with readability that whether it is upper or lower case. My own convention is CAPS FOR KEYWORDS AND VARIABLES, MixedCase for paragraph names, and lower case for comment lines. I find that plus using AccuTerm's WED editor with syntax highlighting, makes for very readable code. I was skeptical about the syntax highlighting at first...thought it was frivolous. Now I feel cramped when using an editor that does not have it. I hate line editors...always have, even though I have used them in the past, notably MS-DOS's EDLIN and one that was part of the Honeywell Level-62 IPS software. But I have never used them with MV, as I was introduced to Pick/D3 and SB+ at the same time and have always used SE until I got AccuTerm. I don't even like vi, as I am so used to modeless editors. Seems to me that a fondness for line editors is just a teeny bit masochistic. === Norman Morgan [EMAIL PROTECTED] http://www.brake.com === Last 2 words of the national anthem - PLAY BALL! === -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dianne Ackerman Sent: Wednesday, March 14, 2007 8:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Error in report generation. I must be backwards because I actually find the second one easier to read and cleaner. And faster to type! Of course, I guess I'm one of the old-timers, having been in multi-value for 25 years now. -Dianne [EMAIL PROTECTED] wrote: Mark I WAS WAITING FOR YOU TO RESPOND THERE! SO YOU PREFER CODE THAT SHOUTS BACK AT YOU? THERE ARE GOOD REASONS WHY THE REST OF THE WORLD HAS SWITCHED TO MIXED CASE CODING - IT IS GENUINELY QUICKER TO SCAN AND READ. FORTUNATELY I'VE ONLY BEEN WITH MULTIVALUE FOR TWENTY YEARS SO I WAS ABLE TO DITCH UPPER CASE AS SOON AS UNIVERSE CAME ALONG. PROVING WHAT YOU SAID IN YOUR EMAIL ABOUT NOT FOLLOWING 'BUT THAT'S HOW I WAS TAUGHT' :) I'm not being frivolous (or personal - you obviously *read* these emails!) here. Whether we like it or not, perception is important. Whilst we are trying to position/encourage UniVerse, UniData et al as modern and up to date systems with a strong history, it makes sense to write in ways that match the expectations of new developers who are brought up with current conventions: that includes mixed case coding, legible styles and formats that can be genuinely expressive - like not using field numbers for example (a REAL bugbear of mine). Not using ED helps, of course. Before anyone jumps in - no I don't advocate rewriting existing code in this way. But quickly scan the following two sections and see which one reads faster. If you've been brought up around Delphi, Java, C#, VB, ASP or any of the 'modern' languages I'm willing to bet the first will be considerably quicker. Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT --- 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] Error in report generation.
An interesting test would be for those who love to upper-casing everything to try typing in their favorite word processor (where mixed casing is the norm) without looking at the screen and have one of their children keep pressing the Caps Lock key. If you manage to get frustrated, then you can begin to imagine how others, who know how to type, feel about this U2 style casing situation; which manifests itself in upper-case BASIC code. Remember, case-sensitivity precludes mixed-casing while case-insensitivity precludes nothing! With case-insensitivity we can both have what we want. I don't mind anyone living with case-sensitivity, I just mind others insisting, or demanding, I live with it too! Have a heart, will ya? :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dianne Ackerman Sent: Wednesday, March 14, 2007 6:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Error in report generation. I must be backwards because I actually find the second one easier to read and cleaner. And faster to type! Of course, I guess I'm one of the old-timers, having been in multi-value for 25 years now. -Dianne [EMAIL PROTECTED] wrote: [snipped] Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
Bill: I don't grasp which side of this fence you're on with this post. - Original Message - From: Bill H [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, March 14, 2007 3:45 PM Subject: RE: [U2] Error in report generation. An interesting test would be for those who love to upper-casing everything to try typing in their favorite word processor (where mixed casing is the norm) without looking at the screen and have one of their children keep pressing the Caps Lock key. If you manage to get frustrated, then you can begin to imagine how others, who know how to type, feel about this U2 style casing situation; which manifests itself in upper-case BASIC code. Remember, case-sensitivity precludes mixed-casing while case-insensitivity precludes nothing! With case-insensitivity we can both have what we want. I don't mind anyone living with case-sensitivity, I just mind others insisting, or demanding, I live with it too! Have a heart, will ya? :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dianne Ackerman Sent: Wednesday, March 14, 2007 6:27 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Error in report generation. I must be backwards because I actually find the second one easier to read and cleaner. And faster to type! Of course, I guess I'm one of the old-timers, having been in multi-value for 25 years now. -Dianne [EMAIL PROTECTED] wrote: [snipped] Loop ReadNext Id From MYLIST Else Fin = @True End Until Fin Do ReadU CustomerRec From CUSTOMERS, Id Then GoSub ProcessRecord End Repeat LOOP READNEXT ID FROM MYLIST ELSE FIN = @TRUE END UNTIL FIN DO READU CUSTOMERREC FROM CUSTOMERS, ID THEN GOSUB PROCESS.RECORD END REPEAT --- 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] Error in report generation.
Shouldn't SUB have SUBROUTINE and arguments (REC) on line 1? Vance Alspach J L Industrial Supply An MSC Company -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanjeebkumar Sarangi Sent: Tuesday, March 13, 2007 7:40 AM To: u2-users@listserver.u2ug.org Subject: [U2] Error in report generation. Hi I tried to generate a report by writing a small program. But I got an error as below. ERROR: RUN TEST.BP MAIN MAIN 45 record(s) selected to SELECT list #0. Program SUB: Line 3, Variable REC previously undefined. Empty string used. Program SUB: Line 3, Printer name UVDEFAULT is not recognized by the system. CODE: ED TEST.BP Record name = MAIN 15 lines long. : P 0001: CRT 'MAIN' 0002: OPEN 'INVENTORY.T' TO INEVNTORY ELSE STOP 0003: SENT = 'SSELECT INVENTORY.T BY ITEM_CODE' 0004: EXECUTE SENT 0005: EOF = 0 0006: LOOP 0007: READNEXT ITEM_CODE ELSE 0008: EOF = 1 0009: END 0010: UNTIL EOF DO 0011: READ REC FROM INEVNTORY ,ITEM_CODE THEN 0012: CALL SUB 0013: END 0014: REPEAT 0015: STOP Bottom at line 15. : Q File name= TEST.BP Record name = SUB 6 lines long. : P 0001:CRT 'SUB' 0002: PRINTER ON 0003: PRINT ITEM_CODE L#16:REC1 0004: PRINT DESCRIPTION L#16: REC2 0005: PRINT TYPE L#16:REC3 0006: PRINTER OFF 0007: RETURN Bottom at line 7. : How do I resolve this? Thanks Sanjeeb This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by replying to the e-mail. Please then delete the e-mail and destroy any copies of it. Thank you. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
Perhaps a little explanation is in order here. There are no global variables in u2. Thus the need to pass the variables to the subroutine. If you have truly global variables - used in many subroutines - you could put them in a common block. ( add a line COMMON /name/ REC, VAR in every program that use them ) If the program stays as simple (small) as it is now a gosub is neater than an external routine: ... read x from y else null gosub sub ... sub: print ... return ... end hth -- mats Hi You need to pass REC as a parameter to the subroutine see below: -- mats --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
Hi You need to pass REC as a parameter to the subroutine see below: -- mats Sanjeebkumar Sarangi skrev: Hi I tried to generate a report by writing a small program. But I got an error as below. ERROR: RUN TEST.BP MAIN MAIN 45 record(s) selected to SELECT list #0. Program SUB: Line 3, Variable REC previously undefined. Empty string used. Program SUB: Line 3, Printer name UVDEFAULT is not recognized by the system. CODE: ED TEST.BP Record name = MAIN 15 lines long. : P 0001: CRT 'MAIN' 0002: OPEN 'INVENTORY.T' TO INEVNTORY ELSE STOP 0003: SENT = 'SSELECT INVENTORY.T BY ITEM_CODE' 0004: EXECUTE SENT 0005: EOF = 0 0006: LOOP 0007: READNEXT ITEM_CODE ELSE 0008: EOF = 1 0009: END 0010: UNTIL EOF DO 0011: READ REC FROM INEVNTORY ,ITEM_CODE THEN 0012: CALL SUB(REC);!! 0013: END 0014: REPEAT 0015: STOP Bottom at line 15. : Q File name= TEST.BP Record name = SUB 6 lines long. : P SUBROUTINE SUB(REC) ;!!! 0001:CRT 'SUB' 0002: PRINTER ON 0003: PRINT ITEM_CODE L#16:REC1 0004: PRINT DESCRIPTION L#16: REC2 0005: PRINT TYPE L#16:REC3 0006: PRINTER OFF 0007: RETURN Bottom at line 7. : How do I resolve this? Thanks Sanjeeb =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --- 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] Error in report generation.
Charles Barouch wrote: Sanjeeb, There are several problems with this and I strongly suggest you get some training. [AD] My company, Key Ally, does training[/AD]. However, in brief: Variables are only global within a program. Once you CALL SUB, you are in a new program and all variables in it are inherently unrelated to the variables in the calling program. To connect them you either need to use COMMON or to pass them. For example: if line 12 of MAIN said CALL SUB(REC) *and* SUB started with SUBROUTINE SUB(REC), then REC in MAIN and REC in SUB would be linked. All of the above is correct, but there is another approach, (yeah, this is pick/u2/multi-value, there's *always* another approach. See modified line 12, and then lines 16 through 27. If you embed the code, you don't have to pass the variables, plus you don't have the overhead of calling another external routine. If you're going to re-use the code, then you probably want to code it as an external, in which case you need to pass it arguments as Charles said, if it's only for this routine, then you probably want to code it internally. 0001: CRT 'MAIN' 0002: OPEN 'INVENTORY.T' TO INEVNTORY ELSE STOP 0003: SENT = 'SSELECT INVENTORY.T BY ITEM_CODE' 0004: EXECUTE SENT 0005: EOF = 0 0006: LOOP 0007: READNEXT ITEM_CODE ELSE 0008: EOF = 1 0009: END 0010: UNTIL EOF DO 0011: READ REC FROM INEVNTORY ,ITEM_CODE THEN 0012: GOSUB PRINT.LINE: 0013: END 0014: REPEAT 0015: STOP 0016: * 0017: PRINT.LINE: ;* Internal subroutine. 0018: CRT 'SUB' 0019: PRINTER ON 0020: PRINT ITEM_CODE L#16:REC1 0021: PRINT DESCRIPTION L#16: REC2 0022: PRINT TYPE L#16:REC3 0023: PRINTER OFF 0024: RETURN 0025: * End of PRINT.LINE internal subroutine. 0026: 0027: END;* For compiler. -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
This wont work either: L#16:REC1 Try this: REC1 L#16 Sanjeebkumar Sarangi wrote: Hi I tried to generate a report by writing a small program. But I got an error as below. ERROR: --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
And the pretty version: Brian * define some field locations. Normally these would be placed in * a separate include file and shared. EQU INVENTORY.CODE To 1 EQU INVENTORY.DESCRIPTION To 2 EQU INVENTORY.TYPE To 3 * only primitive programmers still use upper case! Crt Main Ct = 0 Open INVENTORY.T To INVENTORY Else STOP End Sent = SSELECT INVENTORY.T BY ITEM_CODE Execute SENT EOF = @False Loop ReadNext ItemCode Else EOF = @True End Until EOF Do Read InventoryRec From INVENTORY, ItemCode Then GoSub PrintLine End Repeat Crt Printer Close ;* terminate nicely STOP PrintLine: Ct += 1 If Not(Mod(Ct,10)) Then Crt .: Printer On Print (ITEM CODE L#16):InventoryRecINVENTORY.CODE Print (DESCRIPTION L#16):InventoryRecINVENTORY.DESCRIPTION Print (TYPEL#16):InventoryRecINVENTORY.TYPE Printer Off Return --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: *** GMX Spamverdacht *** Re: [U2] Error in report generation.
Is this going to become a pissing-contest? [EMAIL PROTECTED] schrieb: And the pretty version: Brian * define some field locations. Normally these would be placed in * a separate include file and shared. EQU INVENTORY.CODE To 1 EQU INVENTORY.DESCRIPTION To 2 EQU INVENTORY.TYPE To 3 * only primitive programmers still use upper case! Crt Main Ct = 0 Open INVENTORY.T To INVENTORY Else STOP End Sent = SSELECT INVENTORY.T BY ITEM_CODE Execute SENT EOF = @False Loop ReadNext ItemCode Else EOF = @True End Until EOF Do Read InventoryRec From INVENTORY, ItemCode Then GoSub PrintLine End Repeat Crt Printer Close ;* terminate nicely STOP PrintLine: Ct += 1 If Not(Mod(Ct,10)) Then Crt .: Printer On Print (ITEM CODE L#16):InventoryRecINVENTORY.CODE Print (DESCRIPTION L#16):InventoryRecINVENTORY.DESCRIPTION Print (TYPEL#16):InventoryRecINVENTORY.TYPE Printer Off Return --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: *** GMX Spamverdacht *** Re: [U2] Error in report generation.
No :) But he is just learning BASIC, so he might as well start with some good conventions - like using EQUATEs for field numbers. Brian Is this going to become a pissing-contest? [EMAIL PROTECTED] schrieb: And the pretty version: Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: *** GMX Spamverdacht *** Re: [U2] Error in report generation.
Mecki FC6rthmann wrote: Is this going to become a pissing-contest? snip Actually it's a fairly interesting thread, presenting a couple options for the original poster, along with various styles of coding for him/her to look at and think about. Not a bad thing. -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Error in report generation.
Instead - why not use the Retrieve language from the command line without bothering with a basic program? Type the following at the command line will give you the result your program is trying to acheive: SORT INVENTORY BY ITEM_CODE ITEM_CODE CONV T16 DESCRIPTION CONV T16 TYPE CONV T16 VERTICALLY Also, noting that you are outputting vertically, are you trying to print labels? There is a LIST.LABEL verb designed specifically for that task. Stuart -Original Message- I tried to generate a report by writing a small program. But I got an error as below. ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Error in report generation.
How does using upper case make a programmer primitive? Considering that beaucoups of prior source code is in pure upper case, it would be hard to cost justify changing the case for its own sake. Accuterm's WED program editor allows you to assign different colors to comments, variables, statements, labels and text. Thus, the readability of a pure upper case system is enhanced through color. shameless AD Everyone should give WED a try. Besides the colors, it's indentable, you can double click on a label, CALL reference or an INCLUDE and it jumps to those code sections. All the standard Notepad MS feel. Multiple screens. /shameless AD D3 has a lower case version of Data/Basic that's not interchangable with the upper case version. IMHO, the mixed casing programming comes from other languages like VB that doesn't allow a period as a variable character, rather as an object-method/property separator. Zillions of MV programs are written with CUST.NAME instead of CustName. I continue to use pure upper case for programming and keep mixed casing for the user screens and prompts. If that causes me to drag my knuckles, then so be it. My 1 cent. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, March 13, 2007 11:00 AM Subject: Re: [U2] Error in report generation. And the pretty version: Brian * define some field locations. Normally these would be placed in * a separate include file and shared. EQU INVENTORY.CODE To 1 EQU INVENTORY.DESCRIPTION To 2 EQU INVENTORY.TYPE To 3 * only primitive programmers still use upper case! Crt Main Ct = 0 Open INVENTORY.T To INVENTORY Else STOP End Sent = SSELECT INVENTORY.T BY ITEM_CODE Execute SENT EOF = @False Loop ReadNext ItemCode Else EOF = @True End Until EOF Do Read InventoryRec From INVENTORY, ItemCode Then GoSub PrintLine End Repeat Crt Printer Close ;* terminate nicely STOP PrintLine: Ct += 1 If Not(Mod(Ct,10)) Then Crt .: Printer On Print (ITEM CODE L#16):InventoryRecINVENTORY.CODE Print (DESCRIPTION L#16):InventoryRecINVENTORY.DESCRIPTION Print (TYPEL#16):InventoryRecINVENTORY.TYPE Printer Off Return --- 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] Error in report generation.
I'm gonna throw my 4 cents in to hopefully stop this excessive coding. snip 0005: EOF = 0 0006: LOOP 0007: READNEXT ITEM_CODE ELSE 0008: EOF = 1 0009: END 0010: UNTIL EOF DO /snip Can be replaced with one line that's pretty readable: ud/uv version: LOOP WHILE READNEXT ID DO or the D3 version LOOP READNEXT ID ELSE EXIT UNTIL 0 DO or even the Mvbase or Microdata version LOOP READNEXT ID ELSE ID=@@@ UNTIL ID=@@@ DO ( use @@@ or whatever is not a likely item-id) I have read these EOF=FALSE blah, blah, blah ways of avoiding the GOTO statements for almost 30 years. It's pretty tiring and does not need to be perpetuated. While anyone can argue that we have an infinite amount of resources (disc space, RAM etc), we are still human programmers reading source code. Condensing the code isn't for the system's sake, it's for the programmer's sake. Please, anyone who's new to MV should consider more than one style of programming examples. From what I continue to view, It's perpetuating the technique first learned with no opportunity for learning a better or shorter way. Another pet peeve of mine is the habit of using the null DICT portion when OPENing a file. I recall in the late 1970's when I accidentally forgot to include it on a Microdata and it compiled and worked anyway. Haven't looked back on that useless parameter. Old School: OPEN ,ABC TO F.ABC ELSE xxx Works on all Platforms: OPEN ABC TO F.ABC ELSE xxx also OPEN DICT ABC TO D.ABC ELSE xxx I forego the entire OPEN mess with a subroutine that does not cause the bother of the wide variety of Can't Open scenarios. 99% of the time, the OPENing of a file is a must-do, ie if you can't don't continue. There is the less than 1% of the time where opening a file is a logical THEN/ELSE. Most of the time it's a requirement for the rest of the program to continue. Therefore, I use a sub called OPENER that I published in an issue of Spectrum. It's use is: CALL OPENER(ABC, F.ABC) or CALL OPENER(DICT ABC, D.ABC) and in that subroutine, you can write War Peace if you want to get that verbose about a file not opening. My point is, I have seen some pretty stupid methods of handling these 99% OPEN scenarios. It's a 'housekeeping' section of the program that should be blown past without too much fanfare in the source code. Thus you can have this: CALL OPENER(FILE1, F.FILE1) CALL OPENER(FILE2, F.FILE2) CALL OPENER(FILE3, F.FILE3) instead of these 3 ridiculous methods OPEN FILE1 TO F.FILE1 ELSE PRINT CANNOT OPEN FILE1. PLEASE CALL TECH SUPPORT. PROGRAM TERMINATING ; STOP OPEN FILE2 TO F.FILE2 ELSE PRINT CANNOT OPEN FILE2. PLEASE CALL TECH SUPPORT. PROGRAM TERMINATING ; STOP OPEN FILE3 TO F.FILE3 ELSE PRINT CANNOT OPEN FILE3. PLEASE CALL TECH SUPPORT. PROGRAM TERMINATING ; STOP or OPEN FILE1 TO F.FILE1 ELSE PRINT CANNOT OPEN FILE1. PLEASE CALL TECH SUPPORT ERR.SW=1 END OPEN FILE2 TO F.FILE2 ELSE PRINT CANNOT OPEN FILE2. PLEASE CALL TECH SUPPORT ERR.SW=1 END OPEN FILE3 TO F.FILE3 ELSE PRINT CANNOT OPEN FILE2. PLEASE CALL TECH SUPPORT ERR.SW=1 END or this doozy of a mess OPEN FILE1 TO F.FILE1 THEN OPEN FILE2 TO F.FILE2 THEN OPEN FILE3 TO F.FILE3 THEN 500 LINES OF PROCESSING AS PER APPLICATION END ELSE PRINT CAN'T OPEN FILE3 END END ELSE PRINT CAN'T OPEN FILE2 END END ELSE PRINT CAN'T OPEN FILE1 END Please, lets not spend so much effort on this simple task. OPEN them and get on with it. I work with a guy who sometimes uses method 2 above and sometimes uses method 3 above. I try to show him the simplicity of OPENER (it's already on that system) but he continues to respond But that's how I was taught. Pretty stupid. I even have a program called MAKE.OPENER that will go through source code and replace whatever open statements exist with OPENER. I don't know the approval or voting process on what methods are useful to show the newbies so they start off on the right foot. Respectfully submitted Mark Johnson - Original Message - From: Sanjeebkumar Sarangi [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, March 13, 2007 6:40 AM Subject: [U2] Error in report generation. Hi I tried to generate a report by writing a small program. But I got an error as below. ERROR: RUN TEST.BP MAIN MAIN 45 record(s) selected to SELECT list #0. Program SUB: Line 3, Variable REC previously undefined. Empty string used. Program SUB: Line 3, Printer name UVDEFAULT is not recognized by the system. CODE: ED TEST.BP Record name = MAIN 15 lines long. 0005: EOF = 0 0006: LOOP 0007: READNEXT ITEM_CODE ELSE 0008: EOF = 1 0009: END 0010: UNTIL EOF DO : P 0001: CRT 'MAIN' 0002: OPEN 'INVENTORY.T' TO INEVNTORY ELSE STOP 0003: SENT = 'SSELECT INVENTORY.T BY ITEM_CODE' 0004: EXECUTE SENT 0011: READ REC FROM INEVNTORY ,ITEM_CODE THEN 0012: CALL SUB 0013: END 0014: REPEAT 0015: STOP Bottom at line 15. : Q File
