Re: What is this object?

The object subtype x00 is reserved for [if I recall correctly, the so-called] /prototype/ object types, so the 1-byte value x00 is not actually supported for the subtype of a 2-byte object type x19 as effected by the Create Space (CRTS) MI instruction. Rationally then, the LIC should be denying the request with an exception message; i.e. AFaIK, any feature issuing a CRTS to create an x/1900 object should fail, at least if they are associated with a context [i.e. esp. should not be allowed to be inserted into a *LIB]. I seem to recall having stated this same thing in a past message with a similar occurrence of x/1900 *SP objects; I believe that was a scenario consistent with what the KB article [TechNote N1018328; historically Technical Document 12332859] describes with its references to APARs SE42868 and SE45286 for which apparently PTFs were issued to prevent the defect for the Performance Data tooling leaving such object types, but the LIC apparently still allows their creation, and the QPFR features likely still create those /prototype/ object types vs some proper\supported internal object types.
http://www.ibm.com/support/docview.wss?uid=nas8N1018328

The more appropriate symbolic types are one of the *MSCSP [Miscellaneous Permanent Space; x/19EE; if the object needs permanence across an IPL] and the *QTSP [a Temporary Space; x/19EF; if the object need not be persistent across IPLs]. Anyhow, for these reasons, I am not surprised that the save [e.g. SAVOBJ, SAVLIB] feature does not want to save objects of that type. I seem to recall that the save feature does save legitimate internal object types however, but only when OBJ(*ALL) OBJTYPE(*ALL) is specified or implied by the command or API request; though I believe they may not be included in the /objects saved/ count.

FWiW: The DMPOBJ of the *LIB to locate the objects is a bit excessive, esp. if there are many objects in the library. The DMPSYSOBJ is the overall better choice, to get just the objects of interest. There is no requirement to know the full name of the objects, because generic* names are supported, as well generic type\subtypes; besides, the remaining bytes of the name may be non-printable characters, and in that case the name would have to be specified in hex characters if issued on a command-line. For the specific incident, the presumed-appropriate request would be:

DMPSYSOBJ PRESSURELO* The_LibName 19 *ALL /* or 00 */

The TYPE and SUBTYPE parameters must be specified, because the OBJTYPE parameter does not support the *SP object type, nor any internal object type. Because the object is not on /external object type/ there is no capability to review its Object Information Record (OIR), so *SERVICE and *FULL information like what might be available for other objects via DSPOBJD is not available; and again, not being an external object type, its OBJTYPE parameter also has no support for the symbolic type *SP. And also a request such as DSPLIB, the QUSLOBJ API, or the WRKLNK for the same generic object name could present the object(s) in a list, the available information [if even the interface will present any details] is going to be limited to some small number of attributes like the owner, authority, and creation date\time [those also available in the spooled dump data; some of what is available from the MATSOBJ and possibly the MATS MI instructions]; things like the system-created-on, created-by-user, save\restore information, et al, i.e. the details that are stored only in the OIR, will not be available. For lack of an object handler, I am unsure if even there will be auditing. The "what job" information would only exist, if that detail were in the space [i.e. the data; if placed there by whatever application created the object], because that is not an attribute of the object itself; and, refer back to the prior auditing comment. So although the following invocation should list the objects [with apparently duplicate names; see Mark's comments about 30-byte names], what options that are usable [at all functional, or perhaps just missing information] against those *SP objects, is probably limited:
WRKLNK OBJLNK('/qsys.lib/TheLibrary.lib/PRESSURELO*.sp')

Regards, Chuck

On 13 Sep 2013 14:34, Mark S Waterbury wrote:

Any OPM MI program can create space objects -- they might show up
with a type of "*SPC" or "*SP" ... they may or may not have a visible
object "attribute" -- also, the object names at the MI layer are 30
characters long -- OS/400 traditionally only makes available 10
character object names to the users of OS/400 ... but below OS/400,
at the MI layer, the names are in fact 30 characters. So, an OS/400
library name (called a "context" in MI) could be up to 30 characters,
and the object names inserted into the context can each be up to 30
characters. I suspect that if you see more than one of these
"PRESSURELO" names, they are in fact longer than 10 characters, and
if you can see the entire name, you may see that they are different
in positions 11-30. One way to see them is to do a
DMPOBJ xxxxxxxxxx *LIB and then examine the QPSRVDMP spool file.

You can also dump one of these objects, e.g. using DMPSYSOBJ, once
you know the full object type, object subtype, and 30-character
object name (from the above dump of the context.) The resulting spool
file should tell you more about these objects, such as when they were
created, by what job, etc., as well as their size and a "dump" of the
contents of the space.

Note also that these may or may not have been created by IBM -- they
could have been created by any MI program, or even a program written
in an ILE language (C, COBOL or RPG IV) that can invoke MI
instructions "in-line".

I hope this helps you to figure out what they are or where they came
from ...

Let us know what you find out.

On 9/13/2013 4:41 PM, Thomas Garvey wrote:

While backing up a library, we found that several objects won't be
saved. There are multiple occurrences of the same object name
(PRESSURELO), with object type *SP, in the library. Can't find any
references to this object type anywhere. At first I thought they
might be related to stored procedures, but my experience with
these have always been program or service program objects. Any
ideas?