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



*NEW means you open the file with Truncate bits on. If the file exists, it is 
truncated and returned to zero length. If it did not exist, it would create a 
new zero byte file. 

*APPEND would open with the Truncate bits off. Any writes would just add more 
bytes to file. 

I would personally just prefer to have the OPEN work that way instead of having 
a separate function to delete the file but I will think some more on that. 

As to your zen question, I did consider that but I just decided I like it 
better when you have positive control over something. I would rather see the 
code say OPEN, do something, CLOSE then just do something although it did just 
occur to me that I am not thinking clearly. I am thinking in terms of a loop 
with a program reading a record and then writing but in this case we are 
talking writing a single command that does everything so what you are saying 
makes perfect sense. 

Exec SQL DECLARE GLOBAL TEMPORARY TABLE Temp_Table (DummyField Char(1))

SQL_String = 'INSERT INTO Temp_Table SELECT DISTINCT WRITEIFS(' + 
BuildStringHere + ') FROM ' + Tables + ',' + FileName + ',''*NEW'')

/Exec SQL EXECUTE IMMEDIATE :SQL_String
 
But you know when I think about, I think I prefer the first. I guess it goes 
back to structured principles. 

"A Function should do one thing and only one thing and you should be able to 
describe what the function does without the use of conjunctive verbs (AND OR)." 

So WRITEIFS would end up being Write to IFS and Open the file on the first 
write and Close the file at the end.  

Also, by using separate UDF's, I can do an OPEN, WRITE, WRITE, WRITE, CLOSE so 
the file stays open rather than opening and closing each time. Time would 
probably make little if any difference but I still prefer that a function do 
one thing. 

Anyway, I really appreciate all the input. Think I might be there. 

-----Original Message-----
From: Paul Morgan [mailto:pmorgan@xxxxxxxxxxxxxx]
Sent: Thursday, May 26, 2005 9:50 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Help improve performance of RPG program - Long Post


Alan,

What's being done differently between an OPENIFS with *NEW or *APPEND?  I
don't see the reason for the option.  If I open a file and it already exists
then it should automatically *APPEND.  If it doesn't already exist it should
be *NEW.  If *NEW would truncate/clear the file if it already existed don't
do that using OPENIFS but provide another procedure that could be called
beforehand to clear an IFS file.

How about a zen question -  why do you need OPENIFS & CLOSEIFS functions?
SQL doesn't open and close tables so why should your functions OPEN/CLOSE
the IFS files.  Why not just pass a required file name along on the WRITEIFS
function?  If it's the first reference to that file you open it up and
process it.  Your WRITEIFS function could store a table of files so
subsequent calls could use the same file handle from the first call.  If you
passed a file name to the WRITEIFS function you could work with more than
one IFS file at the same time.  Also, do the files really need to be closed?
Could you just automatically close the IFS files whenever a SQL statement
completes?  Is it possible to hook into SQL to know when to a statement
completes?  Or is the overhead for a open/close to an IFS file low enough
you could afford to open/write/close on every call to WRITEIFS?

Paul


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.