Firstly, the only way to disable the "save" button is via action security on the application, which is an all transactions or none by role/user. So without modification to the P0911 application, I don't think that is practical for you.
Secondly, I agree with Luke (AllOut Security), row security would be your best option, but you may need to include/set up roles as well as application (run or not run) and possibly action (view/add/change/delete by application) security depending on the complications of your user required access (see points 3 and 4 below).
Thirdly, you haven't provided the details of the security you have set up to resolve the problem so diagnoses of the commit fail is not possible (at least for me). I would recommend creating a debug log to capture what is/not happening.
There are a number of things of which you need to be aware and probably already are:
1) Whenever a batch is entered - even if it is for viewing only and no changes are being made, the batch table (F0011) is updated on batch entry (the batch status is changed to "U" - in use) and exit (the batch status is returned to what it was). Therefor any row security should not include the F0011.
2) GL documents need to balance. Some documents (created by other JDE modules/applications - e.g. AP, AR, FA) have the balancing entries automatically created when posting. These automatically created entries have a document type of "AE" and thus care should be taken with security involving the document type. However you said in your opening post when creating this thread that you basically want view access of all GL entries, and add/change/delete access to GL entries created in the P0911. This being the case, I don't think there will be any problem relating to the "AE" document type unless the user posts batches that create them. I would assume that a separate user id is used to run the post program (P09801) on the Scheduler.
3) Without detailed (Auditors Utopia) segregation of duties, the situation may occur when the same user will create documents in other JDE modules/applications (e.g. AP, AR, FA) as well as using the P0911. To handle this situation a combination of multiple roles, application and action security.
4) The solution to your problem will have to fit in with existing security so that existing security is not compromised and so that existing security does not compromise your solution.
5) Beware of unintended consequences to (apparently) unrelated situations - test thoroughly
In view of the foregoing, where points 3 and 4 above do not apply, I would suggest document type row security restricting add/change/delete access set up on only the GL table (F0911) for users who have access to the P0911 application. HOWEVER, any complications caused by the situations mentioned in points 3 and 4 above will probably mean a more extensive solution is required.