× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Coding for the dumbest programmers, was Text on report
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Mon, 26 Jun 2000 9:43:29 -0500

User spaces, arrays, API's, (even pointers) are not that tricky 
and should be in every programmers bag of tricks.  I knew a programmer 
that wouldn't touch an RPG program because they 'W'ouldn't figure 
out what QCMDEXC does.  Be willing to learn.  And if it might be 
tricky then do two things.  Modularize it with either CALL or better 
a service program subprocedure.  Second, document the subprocedure 
in a manual to the point that they do not have to look at the code.  
Perhaps NOT using user spaces, arrays, API's or pointers might be 
more difficult to understand.  Sort of like "Let's stick to MULT 10000.01 
instead of this new date field stuff."  Honestly I cringe when I have
to maintain an RPG III program that some spazoid won't let me convert.







StoneJ@GourmetAward.com on 06/23/2000 03:22:31 PM
Please respond to RPG400-L@midrange.com@Internet
To:     RPG400-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        RE: Text on report

You received a lot of interesting ideas for your question, but IMO there
were lots of suggestions that were really bad.  It bugs me when programmers
design a solution using user spaces, arrays, API's, etc, that no one will
ever be able to figure out down the road when a simple solution (like a
physical file) will do the job just fine!

At our company we have lots of tricky solutions which could have been set up
more simply, but instead cause everyone lots of headaches.  I'm sure with
your msg question any method would work OK, so you can't go too far wrong.
Its just that I see so much complexity on a larger scale when often times
things could be much simpler!

As far as using an AS/400 message file, it might work OK for what you are
trying to do today, but can you:

        Add more switches to the msg records to control processing (such as
a public/private flag)

        Join msgs to other records using OPNQRYF?

        Join msgs to display using Query/400?

        Read records directly using RPG / Cobol / SQL / etc?

        Download the msgs to a PC file?


I dont know too much about the AS/400 msg files, but I dont think you can do
any of the above directly using msg files.  You would probably have to copy
the msg records to a physical file first, if you could do them at all.

Plus the msg text is very long.  I usually limit the amount of text to
smaller sizes.  How would you control the msg length?  For example for a
department name, you might want to limit the length to 20 or 25 characters.

What advantages would a msg file provide?



I have a file like this with messages, invoice msgs, credit reason codes and
descriptions, department codes and descriptions, etc, etc.  Each group of
msgs has a different Msg_Group name.

One mistake I made in my first post:  Dont make the sequence # numeric !!
Use alphanumeric, then you can use it for credit reason codes such as
SP=spoiled, DM=damaged, etc.  This error goes against my first rule of
database design: 

Rule #1: Never build keys as numeric fields!  (always use alphanumeric)

Rule #2: If you must build a key as numeric, see rule #1 !



-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Friday, June 23, 2000 12:55 AM
To: RPG400-L@midrange.com
Subject: Re: Text on report


This brings up a good point, Joel.

How about if I put the text in a message file?

That seems like a logical place for it, after all.  I didnt' think about
this, but you brought
up a very good point, and looking at your key data, this is almost the exact
same information
in the key info for a message file.

Any thoughts?

Regards,

Jim Langston

"Stone, Joel" wrote:

>
>
> In addition to the good advice you received about placing the data in a
file (and the bad advice about using eval / arrays), I will add my 2 cents.
>
> There will probably be other reports with other text messages.  Pretty
soon you will have a dozen files, all for the same purpose.
>
> If you create a file now with a key prefix, you can use the same file for
all reports, and write only one maintenance program for them all.
>
> Fields could be something like:
>
> field-name    length
> Msg_Group       10
> Msg_seq         3 numeric
> Msg_data        78
>
> For the application you are working on today, the Msg_Group name could be
"PURCH01", Msg_Seq would be 1 thru 12 for twelve lines of text, and the data
is 78 long so it can fit on one line of a green screen.
>
> As you add more apps, you can simply add more Msg_Group records.  For
example if you need text on an invoice next month, add records where
Msg_Group = "INVOICE".
>
> You can add more flags onto the end of the file above too.  For example,
maybe you want a flag such as Msg_Public  (Y/N)  so you can have some msgs
for internal reports, and other msgs for public (customer) reports.
>
> Also maybe you want a change date and used-id field, so you know who
changed the msg and when.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: Text on report</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>You received a lot of interesting ideas for your question, but 
IMO there were lots of suggestions that were really bad.&nbsp; It bugs me when 
programmers design a solution using user spaces, arrays, API's, etc, that no 
one will ever be able to figure out down the road when a simple solution (like 
a physical file) will do the job just fine!</FONT></P>

<P><FONT SIZE=2>At our company we have lots of tricky solutions which could 
have been set up more simply, but instead cause everyone lots of 
headaches.&nbsp; I'm sure with your msg question any method would work OK, so 
you can't go too far wrong.&nbsp; Its just that I see so much complexity on a 
larger scale when often times things could be much simpler!</FONT></P>

<P><FONT SIZE=2>As far as using an AS/400 message file, it might work OK for 
what you are trying to do today, but can you:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Add more switches to 
the msg records to control processing (such as a public/private flag)</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Join msgs to other 
records using OPNQRYF?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Join msgs to display 
using Query/400?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Read records 
directly using RPG / Cobol / SQL / etc?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Download the msgs to 
a PC file?</FONT>
</P>
<BR>

<P><FONT SIZE=2>I dont know too much about the AS/400 msg files, but I dont 
think you can do any of the above directly using msg files.&nbsp; You would 
probably have to copy the msg records to a physical file first, if you could do 
them at all.</FONT></P>

<P><FONT SIZE=2>Plus the msg text is very long.&nbsp; I usually limit the 
amount of text to smaller sizes.&nbsp; How would you control the msg 
length?&nbsp; For example for a department name, you might want to limit the 
length to 20 or 25 characters.</FONT></P>

<P><FONT SIZE=2>What advantages would a msg file provide?</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>I have a file like this with messages, invoice msgs, credit 
reason codes and descriptions, department codes and descriptions, etc, 
etc.&nbsp; Each group of msgs has a different Msg_Group name.</FONT></P>

<P><FONT SIZE=2>One mistake I made in my first post:&nbsp; Dont make the 
sequence # numeric !!&nbsp; Use alphanumeric, then you can use it for credit 
reason codes such as SP=spoiled, DM=damaged, etc.&nbsp; This error goes against 
my first rule of database design: </FONT></P>

<P><FONT SIZE=2>Rule #1: Never build keys as numeric fields!&nbsp; (always use 
alphanumeric)</FONT>
</P>

<P><FONT SIZE=2>Rule #2: If you must build a key as numeric, see rule #1 
!</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jim Langston [<A 
HREF="mailto:jlangston@conexfreight.com">mailto:jlangston@conexfreight.com</A>]</FONT>>
<BR><FONT SIZE=2>Sent: Friday, June 23, 2000 12:55 AM</FONT>
<BR><FONT SIZE=2>To: RPG400-L@midrange.com</FONT>
<BR><FONT SIZE=2>Subject: Re: Text on report</FONT>
</P>
<BR>

<P><FONT SIZE=2>This brings up a good point, Joel.</FONT>
</P>

<P><FONT SIZE=2>How about if I put the text in a message file?</FONT>
</P>

<P><FONT SIZE=2>That seems like a logical place for it, after all.&nbsp; I 
didnt' think about this, but you brought</FONT>
<BR><FONT SIZE=2>up a very good point, and looking at your key data, this is 
almost the exact same information</FONT>
<BR><FONT SIZE=2>in the key info for a message file.</FONT>
</P>

<P><FONT SIZE=2>Any thoughts?</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Jim Langston</FONT>
</P>

<P><FONT SIZE=2>&quot;Stone, Joel&quot; wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; In addition to the good advice you received about placing 
the data in a file (and the bad advice about using eval / arrays), I will add 
my 2 cents.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; There will probably be other reports with other text 
messages.&nbsp; Pretty soon you will have a dozen files, all for the same 
purpose.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; If you create a file now with a key prefix, you can use 
the same file for all reports, and write only one maintenance program for them 
all.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Fields could be something like:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; field-name&nbsp;&nbsp;&nbsp; length</FONT>
<BR><FONT SIZE=2>&gt; Msg_Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10</FONT>
<BR><FONT SIZE=2>&gt; Msg_seq&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 
numeric</FONT>
<BR><FONT SIZE=2>&gt; Msg_data&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
78</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; For the application you are working on today, the 
Msg_Group name could be &quot;PURCH01&quot;, Msg_Seq would be 1 thru 12 for 
twelve lines of text, and the data is 78 long so it can fit on one line of a 
green screen.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; As you add more apps, you can simply add more Msg_Group 
records.&nbsp; For example if you need text on an invoice next month, add 
records where Msg_Group = &quot;INVOICE&quot;.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; You can add more flags onto the end of the file above 
too.&nbsp; For example, maybe you want a flag such as Msg_Public&nbsp; 
(Y/N)&nbsp; so you can have some msgs for internal reports, and other msgs for 
public (customer) reports.</FONT></P>

<P><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Also maybe you want a change date and used-id field, so 
you know who changed the msg and when.</FONT>
</P>

<P><FONT SIZE=2>+---</FONT>
<BR><FONT SIZE=2>| This is the RPG/400 Mailing List!</FONT>
<BR><FONT SIZE=2>| To submit a new message, send your mail to 
RPG400-L@midrange.com.</FONT>
<BR><FONT SIZE=2>| To subscribe to this list send email to 
RPG400-L-SUB@midrange.com.</FONT>
<BR><FONT SIZE=2>| To unsubscribe from this list send email to 
RPG400-L-UNSUB@midrange.com.</FONT>
<BR><FONT SIZE=2>| Questions should be directed to the list owner/operator: 
david@midrange.com</FONT>
<BR><FONT SIZE=2>+---</FONT>
</P>

</BODY>
</HTML>

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.