Pointer question

[dcutaia]

In a RPG program if I have a physical file that is my primary read and have a logical file over that physical file. If the logical file is read will I lose my main pointer to my physical file?

DAC

[jamief]

Re: Pointer question

no you wont.......

[Mercury]

Re: Pointer question

Actually as Jamie said, if you read the LF after the PF, you do not lose the pointer to the PF but you jeopardize the previously data read.

[BenThurley]

Re: Pointer question

Won't the field names be the same for the logical and physical? This means the pointer will still be there but the data would not. (As Mercury pointed out)

There's a couple of solutions.
1.
You could perform the read into a datastructure so they would be writing to different variables

D filerec         ds                  likerec(filer:*input)     
 /free
 read file filerec;
 if filerec.field =' '; 

2.
You could prefix the field names in the F specs

FFILE      UF A E           K DISK             
FFILE01    UF A E           K DISK    RENAME(FILER:FILE01R) PREFIX(l) 

[tomholden]

Re: Pointer question

Won't the field names be the same for the logical and physical? This means the pointer will still be there but the data would not. (As Mercury pointed out)

There's a couple of solutions.
1.
You could perform the read into a datastructure so they would be writing to different variables

D filerec         ds                  likerec(filer:*input)     
 /free
 read file filerec;
 if filerec.field =' '; 

2.
You could prefix the field names in the F specs

FFILE      UF A E           K DISK             
FFILE01    UF A E           K DISK    RENAME(FILER:FILE01R) PREFIX(l) 

FWIW i use both techniques depending on the purpose/intent of the application. i recommend trying both and then you can decide which is better suited for your program/application. more and more i'm leaning toward the data structure method so i can use eval-corr, etc.

[MichaelCatalani]

Re: Pointer question

FWIW i use both techniques depending on the purpose/intent of the application. i recommend trying both and then you can decide which is better suited for your program/application. more and more i'm leaning toward the data structure method so i can use eval-corr, etc.

Also, you have to use data structures in order to use files within subprocedures, so its basically the wave of the future.

And since IBM has added support for data structures on the EXFMT statement, it makes it really easy to move fields from a file to display file or to work fields while only using a single line of code via the eval-corr statement.

[BenThurley]

Re: Pointer question

Also, you have to use data structures in order to use files within subprocedures, so its basically the wave of the future.

How is this the case? I agree it's better to use data structures but I didn't think it was a necessity.

[tomholden]

Re: Pointer question

How is this the case? I agree it's better to use data structures but I didn't think it was a necessity.

it's not a necessity, heck if you want you can pass the entire record as a single field and parse it out adhoc but DS is much better in v6.1 you can simply pass file handles/pointers rather than using a DS but unless you are using files local to the subproc i really don't see much sense in going that route.

[MichaelCatalani]

Re: Pointer question

Files defined in a subprocedure do not have an input / output buffer included automatically by the program. You must describe a data structure for the file and then include that data structure on subsequent reads or writes for the file. While that may sound a bit cumbersome, it actually saves a lot of coding, especially if you have work fields involved.

[MichaelCatalani]

Re: Pointer question

After re-reading my initial post, it may not be clear that I was referring to files defined on F-specs within a subprocedure. Those files need to have data structures defined for them, as they have no input / output buffers automatically created by the compiler.

[BenThurley]

Re: Pointer question

Ahh I see. I wasn't aware you could define F specs within a sub-procedure. Unless perhaps you are talking specifically of the new 6.1 feature? Our service programs define them at the top.