Re: [U2] Error in report generation.

[Anthony W. Youngman]

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 -  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.

[MAJ Programming]

Bill: I don't grasp which side of this fence you're on with this post.
- Original Message -
From: "Bill H" <[EMAIL PROTECTED]>
To: 
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.

[Bill H]

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.

[Norman Morgan]

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.

[Scott Ballinger]

... 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.


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.

[Charles Barouch]

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.

[Dianne Ackerman]

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.

[MAJ Programming]

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  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: 
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'

Re: [U2] Error in report generation.

[MAJ Programming]

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  ":;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: 
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
>  
> 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.

[Symeon Breen]

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/
>
> 
> 
> 
> 
> 
>  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. 
>  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. 
>  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. 
>  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. 
> 
> 
> ---
> 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.

[MAJ Programming]

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  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: 
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.
> >
> > 
> > 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.
> > 
> >
> >
> 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.

[Les Hewkin]

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/






This e-mail and any 
attachments are confidential and intended solely for the use of the addressee 
only. If you have received this message in error, you must not copy, distribute 
or disclose the contents; please notify the sender immediately and delete the 
message. 
This message is 
attributed to the sender and may not necessarily reflect the view of Travis 
Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis 
Perkins may not be concluded by means of e-mail communication. 
E-mail transmissions are 
not secure and Travis Perkins accepts no responsibility for changes made to 
this 
message after it was sent. Whilst steps have been taken to ensure that this 
message is virus free, Travis Perkins accepts no liability for infection and 
recommends that you scan this e-mail and any attachments. 
Part of Travis Perkins 
plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, 
Northampton, NN5 7UG. 


---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Error in report generation.

[brian]

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.

[Symeon Breen]

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
 
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.

[Symeon Breen]

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.
>
> 
> 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.
> 
>
>
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.

[MAJ Programming]

I'm gonna throw my 4 cents in to hopefully stop this excessive coding.


> 0005: EOF = 0
> 0006: LOOP
> 0007: READNEXT ITEM_CODE ELSE
> 0008: EOF = 1
> 0009: END
> 0010: UNTIL EOF DO


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: 
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

Re: [U2] Error in report generation.

[MAJ Programming]

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.


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.


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: 
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"):InventoryRec
> Print ("DESCRIPTION" "L#16"):InventoryRec
> Print ("TYPE""L#16"):InventoryRec
>
> 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.

[Boydell, Stuart]

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: *** GMX Spamverdacht *** Re: [U2] Error in report generation.

[Allen Egerton]

Mecki FC6rthmann wrote:

Is this going to become a pissing-contest?




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: *** GMX Spamverdacht *** Re: [U2] Error in report generation.

[brian]

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 Förthmann]

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"):InventoryRec
Print ("DESCRIPTION" "L#16"):InventoryRec
Print ("TYPE""L#16"):InventoryRec

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: [U2] Error in report generation.

[brian]

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"):InventoryRec
Print ("DESCRIPTION" "L#16"):InventoryRec
Print ("TYPE""L#16"):InventoryRec

Printer Off

Return
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Error in report generation.

[Jeff Schasny]

This wont work either:

"L#16":REC<1>

Try this:

REC<1> "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.

[Allen Egerton]

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":REC<1>
0021: PRINT "DESCRIPTION"  "L#16": REC<2>
0022: PRINT "TYPE"  "L#16":REC<3>
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.

[Mats Carlid]

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":REC<1>
> 0004: PRINT "DESCRIPTION"  "L#16": REC<2>
> 0005: PRINT "TYPE"  "L#16":REC<3>
> 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.

[Louie Gouws]

Sanjeeb

In the Subroutine SUB the variable REC was not defined.

You have read the record REC in the main program but the SUB subroutine does
not know it. So you have to send the REC record over to the subroutine.

One talks about calling the subroutine with parameters.

In your program MAIN you must have CALL SUB(REC)-> where REC is the
parameter.

And the SUB must have a the first line SUBROUTINE SUB(REC)

Sanjeeb - let's also please the serious programmers by adding the PRINTER ON
and PRINTER OFF to the main program.

Also - when starting a program like this, first do the output to the screen
first and once it works then send it to the printer - in your example put an
* in front of the PRINTER ON. When you are happy - remove the *

Also - I think you must do a >SP-ASSIGN F0before you run the
program.

Here are the amend programs

0001: CRT 'MAIN'
0002: OPEN 'INVENTORY.T' TO INEVNTORY ELSE STOP
0003: SENT = 'SSELECT INVENTORY.T BY ITEM_CODE'
0004: EXECUTE SENT
- *PRINTER ON  ;!---remove the * when everything is working
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
- CALL SUB(REC)
0013: END
0014: REPEAT
- PRINTER OFF
- PRINTER CLOSE   ;!-- once this is executed the printer will print
0015: STOP


0001: SUBROUTINE SUB(REC)
0002: CRT 'SUB'
0003: PRINT "ITEM_CODE"  "L#16":REC<1>
0004: PRINT "DESCRIPTION"  "L#16": REC<2>
0005: PRINT "TYPE"  "L#16":REC<3>
0007: RETURN


BTW the output for the above program will be something like this:

ITEM CODE   ABC-12
DESCRIPTION THIS WILL BE THE DESCRIPTION OF THE ITEM ABC-12
TYPETYPE A
ITEM CODE   ABC-13
DESCRIPTION THIS WILL BE THE DESCRIPTION OF THE ITEM ABC-13
TYPETYPE A
ITEM CODE   ACC-10
DESCRIPTION THIS WILL BE THE DESCRIPTION OF THE ITEM ACC-10
TYPETYPE C
Etc.

Is this what you want?

Louie

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sanjeebkumar
Sarangi
Sent: 13 March 2007 13:40
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":REC<1>
0004: PRINT "DESCRIPTION"  "L#16": REC<2>
0005: PRINT "TYPE"  "L#16":REC<3>
0006: PRINTER OFF
0007: RETURN
Bottom at line 7.
:
How do I resolve this?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Error in report generation.

[Mats Carlid]

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.

[Vance E Alspach (J&L - SFD)]

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":REC<1>

0004: PRINT "DESCRIPTION"  "L#16": REC<2>

0005: PRINT "TYPE"  "L#16":REC<3>

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.

[Charles Barouch]

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.


   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/