Yes, apparently from this example.
Note I didn’t define Field1, its definition is from the file
Good practice, probably not.
FMyFile if e k disk
C *entry plist
C parm Field1
C Field1 dsply
C eval *inlr = *on</pre>
Additional from Sloopy:
You should note that using the field name from the file means you are also using whatever value is in that field, after a record is retrieved. And, if you receive a value through that parameter, it will be changed if you then read a record from that file.
If you don’t want that, then use a new name (you can use a LIKE() define).
The usefulness of using the field name from the file is only that you don’t have to create a new field and move data to it when all you want is to pass the value from the record.
You can also use the field name as a KFLD name in a key list.
But, if you use the field name as a formal parameter name in a procedure definition, it will NOT be automatically filled with the value from the record. Procedure parameter names are, in essence, just placeholders against which you specify the attributes of a parameter. So, if you had a procedure defined like this:
D CentreText PR 256 Varying
D FLD001 256
D p_Leader 6 Const Options(*NoPass)</pre>
- where FLD001 comes from a file – you must still state the length and other attributes of the field (or LIKE() define), and you would still have to explicitly state the field when you use the procedure:
PrtEnd = CentreText( FLD001 ) ;</pre>
The more complete answer is “Yes and no.”
It depends on whether the PARM is input to the program or is specified on a CALL to another program.
A file field can be used in a parameter list to call another program. That is, it can be used going out.
However, it can’t come into a program as a parm value and be a file field in that same program — that would require a single field name to refer to different memory locations at the same time with two different meanings. If fields could point to two different memory locations, programs would be useless. You could never be sure what values were anywhere.