On 12 Jul 2013 11:52, Eric Lehti wrote:
Have you learned by IBM cloaked system objects with invisibility, so
that we cannot display or browse system objects?
I am unsure what was the point of that post, but I can suggest that
the computing term "implementation" [as in "implementation-specific"
details of the OS code] is apropos. And FWiW:
In general the "system objects" are protected by their designation as
being "system domain" storage, not simply by obscurity. Even many
object that would be considered "user objects" are similarly protected.
The alluded "cloaked" or "invisibility" is less about prevention of
display\browse than it is about accidental or malicious deletion, and
avoids cluttering the system from the perspective of the "users" [mostly
the programmers and administrators].
With regard to clutter, the "external object types" [*FILE, *PGM, et
al] are visible via the normal and typical UI, e.g. WRKOBJ, DSPLIB, et
al will show objects of those types, but many other objects which exist
[perhaps only as transitory] are arguably better maintained as "internal
object types" that are not visible via those standard User Interfaces.
That is because a "User" should not become confounded by the [possibly
ephemeral] existence of some objects that might appear and\or disappear
without some obvious action taken on their part. Thus if a user does
not know such objects are there, because they are not presented, then
they can not get confused by /seeing/ them.
And because there is a distinction in the type\subtype for "external"
vs "internal", there is also the possibility for optimization for
interfaces specific to either separately. For example, a request to
list only external object types would not have to wade through or omit
all of the internal object types, thus making for better performance;
just as with how a user of an external object list-interface would not
have to page past all of the internal objects for which no supported
methods likely even exist for acting on those objects.
<<SNIP>>
Or to print a single user ELEHT, try:
DMPSYSOBJ OBJ(ISQLSTELEHT*) CONTEXT(QRECOVERY) TYPE(19) SUBTYPE(EE)
<<SNIP>>
That would only list "ST" space objects [some "xx" are optional; i.e.
may not exist], and would include *every user with the prefix* of the
un-delimited "ELEHT". To limit the request to only the "ST" naming of
the "ISQL" session objects [i.e. the STatement space objects], for
*only* "a single user ELEHT", issue the request such that the portion of
the object name [OBJ parameter] with the UsrPrf name [positions 7 to 16]
is padded with blanks to the full ten positions:
DMPSYSOBJ 'ISQLSTELEHT *' QRECOVERY TYPE(19) SUBTYPE(EE)
········· '....+....1....+.*' <-- asterisks should align; the
midrange archives will likely lose the spaces, treating them as needless
white-space, but the archived copy on gmane should not.
Note: AFaIK only the "EN" [the ENvironment] space objects
definitively exist for every session. That is, a session could exist
with no statements, and therefore possibly no "ST" space object would
exist. That is why when explaining to locate /sessions/ I alluded only
to the spaces with the "EN" [ISQLEN prefix] naming:
http://archive.midrange.com/midrange-l/200007/msg00699.html
midrange.com
