RE: Text on report

On Fri, 23 Jun 2000, Stone, Joel wrote:

> Interesting ideas, but not his best choice for what he is trying to do!
> (nothing personal of course) :).

Ahem.  WE DONT EVEN KNOW WHAT HE'S TRYING TO DO!   How could we possibly
know the best way to do it?  
 
> You mention speed over-rides the decision.  Who cares about access speed
> when both are sub-millisecond?  To read 12 msg records from a physical file
> or a source file is instantaneous, so that doesn't help with the decision!

I did NOT say "speed over-rides the decision", I said that it eliminated
a keyed access path, which made file access quicker.  I never said that
it overrides anything.   I certainly would never have made speed the
deciding factor, here...  

In fact, if he's using many such messages in his program the keyed method
would actually be faster, since the extra open/close time would come into
effect.

In both messages I've posted on this subject, I've stated very clearly,
and I continue to EMPHASIZE THIS, that the best solution really depends
on HIS PARTICULAR CIRCUMSTANCE, and he didn't give us enough information
to answer the question.

> 
> On the other hand, source files are limited use files.  They cannot be used
> with Query/400, nor with OPNQRYF, nor with lots of other products.
> 

Whats he going to query in his free form text?!  Is someone out there 
saying to themselves "hmmm...  I wonder if I can find a line of text
that doesn't contain the word 'it' in his reports..."?

> When I have created these types of files in the past, I end up using all
> sorts of products to join the text to reports, other files, screens, etc.
> With source files, you always have to convert the file to a PF prior to
> using it.  If there are lots of msgs in a source file, it could take awhile
> to convert to a PF, especially in an interactive job.
> 

A source file is a PF.  I don't know why on earth anyone would want to run
a query on free-form text that is to be added to a report... I'm
absolutely stumped on it.

But... Since we DONT know the absolute details of what he's doing, lets
say it this way:  "If being able to query your text is an issue, or if you
have to read several bits of text in the same program, or if you have to
integrate your text messages into a 3rd-party application that doesn't
work with source physical files, it will be better to put it into a
custom-designed PF"  "If you want your files to be easy to edit with
STRSEU or easy to FTP to a PC to edit in Notepad or some other word
processor, a source PF might be a consideration"   "If you want your
messages to be used as an error messsage, or written to a joblog, or
returned when a program fails, a MSGF might be better..."

All in all, this type of thinking leads us back to my original post where
I suggested many different methods, and said that IT DEPENDS ON YOUR
APPLICATION.

Can we agree that the best way depends on the circumstances, rather than
start our own private war about this?


> -----Original Message-----
> From: Scott Klement [mailto:klemscot@klements.com]
> Sent: Friday, June 23, 2000 10:19 AM
> To: 'RPG400-L@midrange.com'
> Subject: RE: Text on report
> 
> On Wed, 21 Jun 2000, Stone, Joel wrote:
> 
> > 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
> > 
>  
> Or better yet, put each different block of text into a seperate member in
> a source physical file. This eliminates the need for a keyed access path,
> which in turn makes file access quicker.
> 
> Having it in a source file makes it very easy to edit, with STRSEU, or
> other editors.  You can FTP the file to your PC if you prefer that, and
> OS/400 will know how to convert the text, because its being done with a 
> file type that was DESIGNED with text in mind. 
> 
> It seems to me that it'd be better to NOT create your own custom file
> with your own custom record format that only works with programs written
> specifically for it.  (Unless of course, you need to do something
> "custom")
> 
> > 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.
> 
> I disagree with the assessment that "eval / arrays" are "bad advice."
> The original poster did NOT give enough information for any programmer
> to make a good decision about what the "best way" to do this is.  
> 
> Personally, I like the idea of either using a source PF, or a stream file
> (in the IFS) to store the data.  
> 
> 

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