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
issues:
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
midrange.com
