On 29-Nov-2011 13:09 , rob@xxxxxxxxx wrote:
Many product IBM i commands supplied by IBM have a product library.
<<SNIP>>
However when I use a BRMS command <<SNIP>>
Notice that QBRM is both a PRD and a USR library?
When I hit F3 QBRM remains a user library <<SNIP>>
My joblog shows this:
CPC2196-Library QBRM added to library list.
From program . . . . . . . . . : QLICUSRL
From library . . . . . . . . : QSYS
Instruction . . . . . . . . : 0114
To program . . . . . . . . . . : Q1AQS
To library . . . . . . . . . : QBRM
To module . . . . . . . . . : Q1AQS
To procedure . . . . . . . . : q1aQCAPCMD
To statement . . . . . . . . : 1
Tried opening a PMR and was basically told so what.
IMO that is a defect, or at least a poor design [since the LPP code
should be able to do whatever is required without that modification
persisting in the job]. But with few exceptions, the effect should rate
as nothing more than a "nit".?
The product origin was such that, well... a few aspects were [and
remain] a bit "sloppy". The modified *LIBL effect could be either a
carry-over or a new idea that is IMO just as sloppy.
The effect may be new according to V6 APAR [there may be V5 and V7
too] SE30981 title "BRM-MAINT-INCORROUT FIXES" and text "Problem #6:
QBRM library needs to be added to the library list for some functions to
work correctly. BRMS will now add it as the last library in the user
portion of the library list."
They do that for performance reasons.
That is pretty open\vague.
I fail to see how having something both as a product library and as a
user library entry enhances performance.
Perhaps they meant to "degrade" performance; i.e. the "reasons" are
to perform more slowly ;-) ? Presumably the entry would have been made
as POSITION(*FIRST) instead of POSITION(*LAST) to achieve the quickest
resolution of the product objects.?
Besides, I think the aforementioned APAR describes a "functional"
versus "performance" issue being "corrected" [in that strange manner of
an ADDLIBLE which is then tied to the activation group].
And, it's not like we run BRMS programs outside of commands.
Though there may be supported invocations that do just that; the APAR
implies as much.? In such cases the invoked function could have the
expectation that the invoked feature performs as expected, without
either the *CMD [by PRDLIB()] having added the Product Library entry
prior or the user having added the library to their library list prior;
e.g. a "CALL QBRM/SomePGM" might be supported [Q1AOLD is one I have seen
documented], but have no command definition object to depend on for
adding a PRD library entry.
I was given a suggestion, that if I am sure I have no immediate
plans to go back into BRMS with that job then I could RCLACTGRP
ACTGRP(Q1ABRMS) and that will remove QBRM from the library list.
I tested it. It does.
FWiW, that would occur as part of a CEERAGE\activation-exit which was
registered to the activation. That is, the removal of previously added
library list entries using ADDLIBLE while running in a particular
activation group is not a generic feature of activation groups being
reclaimed.
Granted, this may seem minor.
Unless there are object names in QBRM which conflict with other
objects later in the library list, non-BRM processing depending on name
resolution via the library list should be unaffected. Other than *CMD
names however, presumably all of the BRMS object names have the "Q"
prefix to prevent conflict with true "user object" names. Given the
Q-prefixed names were formed according to convention, conflicts between
"system object" names should not occur.
Am I missing something on why this should be in the user portion of
the library list?
Apparently some features invoked using that activation group name
assume that the library list will include QBRM.
After the library gets added, issue the RMVLIBLE QBRM, and see if
anything fails or if the condition is recoverable by the product ;-)
That the request is not prevented, and if the LPP fails even after the
PTF is applied, could give greater supporting evidence that the effect
is defect.?
If the assumption the dev established is that, since the creation of
the activation group, the QBRM will be in the *LIBL, then that precludes
having the code omit the ADDLIBLE QBRM for any case where QBRM were
detected already to be a PRD entry :-( Something which might at first
glance, seem acceptable, when reviewing the effects originally described
[for when using only *CMD interfaces].
I did submit a DCR.
Maybe the origin(s) for the "need" to add the library list entry [per
the APAR] will be "corrected" in a manner that appears less like having
applied a bandage ;-)
Regards, Chuck
midrange.com
