File Locking Considerations

Currently, the FFN() function can be used to return the currently-used file number. If the program/procedure is expecting to be able to write to the file, the new standard of OPEN INPUT on a "not-expecting-to-write-to" file in a calling program/procedure could cause errors.

Q: Will there be any functions, procedures, or objects available to accommodate the OPEN INPUT and/or opt="exclusive" processing on files? Or will we have to create these ourselves?

Find more posts tagged with

Comments

Legacy Contributor

What kind of functions, procedures or objects are you in need of?

As for the consequence of us using open input, what you say is correct. you may have code that is writing to a channel that we have opened with open input. you will have to find and correct those.

sjacquin

I don't know if this will help, but the status flag of the FIN of a file channel will tell you if a file is opened via "OPEN INPUT".

Legacy Contributor

Between the FIN() and OPT() functions, most of the information can be gleaned. It would probably benefit the community to have standardized methodologies to test/return a status or to find or open a file in the desired mode (LOCK, INPUT, exclusive, whatever), as opposed to each company designing their own. This would also facilitate the integration of enhancements in both directions (to and from the channel).

Legacy Contributor

Also, according to the current info, "Any standard OPEN is considered "open for update" and will interfere with an OPEN with opt=exclusive." I just want to verify that the reverse is also true, that a file OPENed with opt=exclusive interfere with a standard OPEN?

Legacy Contributor

I finally moved from theory to practice...
Unless I'm not doing something correctly or misunderstanding the way things are supposed to work, the alpha demo (7.7.3) version doesn't do anything special with opt=exclusive. I'm able to OPEN (without INPUT) a file, and then OPEN with opt=exclusive on a different channel without any errors. I'm able to access both channels completely.
Is this correct?

Legacy Contributor

Does the file have the prog/SM/SMC990 embedded IO program in it?
open(1)"data/AR/AROPEN"
?fin(1,"io_program")

Legacy Contributor

No, it doesn't. I was under the impression that it was a generic option, not something that is applied to certain specific files. That being said, however...
I did test this with both AROPEN and ARCUST, and still was able to do all that I had previously described. And yes, they both have an io_program of "prog/SM/SMC990".
Any insights?

Legacy Contributor

I seem to have completely missed the reasoning/explanation behind switching to this new locking method. Is this documented somewhere?

Copyright © 2025 Infor. All rights reserved.