On 04-Mar-2015 13:21 -0600, David Gibbs wrote:
I found something interesting on my 7.1 system the other day.
I was doing some analysis of command objects in QSYS, using the
QCDRCMDI API, and encountered a command that gave an error.
When I ran the QCDRCMDI api on the ADDBLDOPTE command, I got a
CPF9810 indicating that the QBLDSYS library didn't exist.
So I looked in QSYS and there is a *CMD object for ADDBLDOPTE ...
but it appears to be a proxy for a command of the same name in
QBLDSYS. QBLDSYS, however, does not exist on my system.
The library name QBLDSYS is an IBM-internal library that provides the
capability to /build/ the OS and LPPs; there should be an expectation,
barring any radically daft changes, that a library by that name would
never exist on a customer system [except under the purview of IBM dev
and\or support such that the library were scheduled and verified to be
deleted with the understanding that cust was expected never to B&R the
contents].
Any direct reference to that library with implied functionality is
either an /escapee/ from the lab and thus a defect [¿accidentally
shipped with the OS on media, perhaps in a TR or a re-save of the OS
that was built incorrectly before being saved], or was delivered as part
of a[n effective] TestFix or some other support purpose for which IBM
had at one time restored or otherwise /installed/ the library on that
system [e.g. from a save file downloaded from IBM service\support]. The
possibility exists that the library was legitimately installed|restored
on the system and the proxy command was created, and the library was
properly deleted according to instructions, but someone overlooked the
prior Create Proxy Command (CRTPRXCMD) thus failed to account for the
negative effect by failing to delete that *CMD object as well.
A proxy command that refers to the library name is a direct [implied
functional] reference, whereas a source file library name associated
with an object [in the *SERVICE OIR] would be merely a historical
reference and unlikely an indication of a defect. Notably, the "created
by", "restore date", and "creation date" could be very telling.
----------
Target command . . . . . . . . . . . . : ADDBLDOPTE
Library . . . . . . . . . . . . . . : QBLDSYS
Text . . . . . . . . . . . . . . . . . :
Current proxy chain . . . . . . . . . : QSYS/ADDBLDOPTE
QBLDSYS/ADDBLDOPTE
----------
Both the naming using the mnemonic BLD for /build/ as a noun, and the
likely usage of mnemonic OPT for the noun /option/, the command name
appears likely to be an IBM-internal "build command".
Some information about the object, the spooled DETAIL(*FULL) and
DETAIL(*SERVICE) of Display Object Description (DSPOBJD), and possibly
the Dump Object (DMPOBJ) would reveal something more about the
provenance of the Command object with the .
Anyone now why there would be a proxy command but no target command?
Given the object is not likely /installed/ intentionally, if the
object appears incorrectly with the OS, then the effect is due to the
accidental delivery of the *CMD object in QSYS. If the object instead
arrived later, then either the object was restored and\or moved into
QSYS, and the target library also may have existed at one time thus the
DLTLIB gave rise to the condition or the library never existed and the
restored object presumably logged effectively the same CPF9810 at
restore but as a diagnostic [i.e. I am doubtful there is a hard
restriction to restore a proxy without a valid+resolvable chain.
A bit more analysis returned a bunch more commands in a similar
state. Most are pointing to QBLDSYS. Others are pointing to QSSP (we
don't have the S/36 env installed, so that can 'kind of' be
explained).
And those additional commands are? Again, obtain and review the
Display Object Description (DSPOBJD) [perhaps obtain also DMPOBJ] as
means to possibly track-back to the origin; if the history and\or
auditing goes back far enough and the restore-date is the origin, then
the restore history\audit-info would show even more.
The OPTION(5) of the OS delivers the S/36EE, and often rather than
properly effecting Delete Licensed Program (DLTLICPGM) [as often was
offered even here on these fora], many will simply issue Delete Library
(DLTLIB) against products\options and thus the LicPgm install-exit
routines that should remove the associated objects that were created
during Restore Licensed Program (RSTLICPGM) would not be performed thus
leaving stranded those objects from the since-missing product [library] :-(
midrange.com
