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



Title: RE: Text on report

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

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!

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.

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.






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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.