On 03-Apr-2012 15:04 , Rory Hewitt wrote:
On Tue, Apr 3, 2012 at 2:35 PM, Kurt Anderson wrote:

<<SNIP>> the file is defined as Update/Add. This causes a couple

1. File needs to be copied into a test library. <<SNIP>>

<<SNIP>> I see that the UPDPROD keyword to the STRDBG command
specifies this:

"...The exception to this is starting debug mode after a production
library is already opened..."

Not sure whether it's possible to bypass this problem by 'opening'
the production library (or whether this would simply potentially
open you up to other problems. <<SNIP>>

That quotation is an error in the help text. A more accurate wording for that quoted sentence could have suggested that "The exception to this is starting debug mode after *the database file member in* a production library is already opened." A [production] library is not "opened" per se, thus making no sense in the context of that message, which intends to refer only to the opening of database file [members].

Thus if the program(s) being debugged have already opened the file member(s), either while no debug was active or UPDPROD(*YES) for debug was in effect during the open processing, then I\O activity other than read-only against those file.members [opened and remaining open within that scope] will be unaffected; i.e. could possibly "bypass" the difficulty. However there is other [effectively] non-I\O activity that is also impacted\restricted by the UPDPROD(*NO), so other restrictions could still be encountered; i.e. other reasons for which the claim that "files must be copied into a test library before trying to run a program that uses the files" may still ring true.

FWiW, some additional commentary about that help text:

The entirety of the help text for the Update Production Files parameter of STRDBG is poorly written. Minimally, for the value *NO, the word "this" is overused [or at least insufficiently qualified], although no matter to what "this" applies, surely intending to imply only with regard to the "Database files in a production library" as noted in the opening sentence of help text. Additionally, the word "update" has [or potentially has] dual meaning; i.e. both for changing attributes and changing data, but any distinction is not made clear.

The use of UPDPROD(*NO) for the debug means that "A Database File [Member] can not be opened using any open-options other than input [i.e. can be opened as read-only], nor can attributes of a database file or a member be changed, if the library of that database file has the production attribute [i.e. the library has the TYPE(*PROD), per CRTLIB or CHGLIB], thus protecting production database file data and production database file\member attributes from unwanted changes while a program is being debugged". Stated that way, though long-winded, there is no need to refine prior comments with any "exception"; having stated clearly, that the protection of the production data from updates, is activated only during and thus preventing, the "open" processing.

The help text could also be more helpful by adding references to each of the following:
≥ the Inhibit Write feature of the OVRDBF command; INHWRT parameter
≥ the actual message identifier CPF4203 used by the database open feature to diagnose the open failure when UPDPROD(*NO) is in effect
≥ the TYPE() parameter of both CRTLIB and CHGLIB; *TEST vs *PROD
≥ perhaps also the other messages CPF3273 and CPF3144 which diagnose other prevented "update" activities to the database file [and member] objects and\or data when UPDPROD(*NO) is in effect

While the more extensive [but poorly written] text is for STRDBG, the Update Production Files attribute can be changed using CHGDBG, so the timing of the "starting debug" is not directly at issue; e.g. debug may have been active with UpdProd(*YES) when a file was "already opened" for update, so the data in that file [member] would not be protected from changes even though later debug was changed to have UpdProd(*NO). The help text for the special value *NO for the same UPDPROD() parameter on CHGDBG is not shared with STRDBG, and although very succinct, the general parameter help text for CHGDBG does better to explain; if only for the vagueness for its use of the term "change".

A request to open a production database file member with any update capabilities [i.e. open for any of output\write, update, or delete] would fail with error CPF4203 while the UPDPROD(*NO) for debug is in effect:
Member &4 cannot be opened while UPDPROD(*NO).
Cause . . . . . : Member &4 file &2 in library &3 could not be opened because either file &2 or a based-on file of file &2 is in a production library and the file is being opened for either an update, delete or output operation; however, the job that is opening the file is in debug mode with the UPDPROD(*NO) parameter specified.
Recovery . . . : Either specify the INHWRT(*YES) parameter on the OVRDBF command, or specify the UPDPROD(*YES) parameter on the CHGDBG command. Then try your request again.

Regards, Chuck

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].