RE: Assigning the actual length of a variable length field.

[GKern@xxxxxxxxxxxxxxxx]

Bob: "Use %addr(myReturnField) as the buffer parameter"

That worked!

Bob: "If you do have a hex 0 in the field, you can still delete it by 
doing this at
V5.3 or later: myData = %trimR(myData: x'4000');
This trims off both blanks (hex 40) and nulls ( hex 0) from the right-side 
of
the value."

That works too!!

Bob: "If this is true, where you passing the value to the fputs() API 
using %addr()???
When OPTIONS(*STRING) is used for a parameter that is a POINTER and passed 
by
value, %ADDR() cause the system to avoid converting it to a 
null-terminated
string, thus you would have to add the null yourself. Another option is to 
wrap
the address in %STR() or if possible, avoid using %ADDR(data) for that
parameter."

I think that's similar to what I ended up doing. Below is the code that 
works:

     C                   Eval      String_V = *Blanks  
     C                   Eval      String_V = %TrimR(String) + Ifs_RecEnd 
+ x'00' 
      * Open the IFS file for update and write the updated string...    
     C                   Eval      File1 = 
OpenIFS(%TrimR(IFS_Filename):'w') 
     C                   Callp     
WriteIFSRec(%STR(%ADDR(String_V)):File1) 

Thanks for all your input Bob. And thanks for your effort in keeping 
timely articles coming to my inbox.


Scott: "This prototype is wrong, but not in the way I expected it to be!"

Well that's what I get for using code someone else here at my office 
implemented (as working code) before me.

a) do not use %addr() or a pointer for the first parameter!  You should 
code your variable name directly, or if you want to remove blanks, put it 
inside a %trim() or %trimr().  Do not use %addr or a pointer when you have 

options(*string) coded.

I'll revise the above code and test it.

b) The second parameter should be the pointer that was returned by the 
fopen() API.

I think I got that part right :)

c) Consider changing the prototype name from "WriteIFSRec" to "fputs". 
fputs() is an ANSI standard API included in every C runtime library on 
every platform.  Renaming it to something else just confuses people and 
makes it harder to understand what you're talking about.  It also makes it 
harder to find info in the manual.  Just a tip.

Thanks for the tip, but there are other programs/applications using what I 
borrowed as my 'starting code'. Thanks for your IFS tutorial too. I put 
all of your IFSIO_H into a copybook and directed my other programmers to 
acknowledge it. As always, hindsight... (is a fine piece of a$$).

"You could use the IFS APIs (instead of the ILE C runtime APIs) but 
there'd be no advantage to them in this case, in fact, fputs() might even 
be easier to use."

Just to clear up my confusion, which API's did I use. Am I correct in 
saying I used the IFS API's. And your IFSIO_H copybook contains the ILE C 
API's?

"As luck would have it, I just wrote an article about the ILE C runtime 
APIs for the IFS, it's set to be sent in the Thursday edition of my 
newsletter -- however, it doesn't demonstrate writing data, only reading. 
Maybe I'll write a follow-on that explains writing in a future 
newsletter."

Thanks for all you do for our community Scott. It is sincerely 
appreciated.

 

Regards, Jerry

Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential and privileged 
information. Any unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please inform the 
sender by reply e-mail and destroy this and all copies of this message.