Re: PDM strange behavior

rick baird wrote:

I'm sure it's a missing ptf or something, but the strangest thing
just happened.

STRPDM option 1, specified *SRC* for list of libraries that
have the letters SRC somewhere in them. press enter.

By convention, option 1 would be referred to by its command. I believe that would be WRKLIBPDM, to denote that was the feature being utilized from the STRPDM menu. In that manner no /navigational/ activity need be described, as it is much easier to just suggest that the following command string was issued:
WRKLIBPDM LIB('*SRC*')

Libraries are listed. many, but not all, of them have the
following behavior:

select option 12. error - File saved with STG(*FREE) specified.
(note two spaces between File and saved - indicating a blank
parameter passed to message)

Again, that is just an indication that WRKOBJPDM LIB(TheLib) was invoked. I do not recall if the same /subset/ is implicit in an option 12, but if the subset were maintained, then simply described by the command string:
WRKOBJPDM LIB(TheLib) OBJ('*SRC*')

Do the direct invocations [vs from the PDM menu] for either OBJ(*ALL) or with a generic name specification exhibit the same problem?

option 5. same thing. pdm option EL (edtlibl). same thing.
run ANY IBM option or PDM option.
always the same: File saved with STG(*FREE) specified.

I always disliked that the object validation phase which precedes the invocation [especially for user defined] of an option specified next to an object name. I really do not care if PDM can access the object for an AJ [wrkactjob] request which has nothing to do with the object; i.e. no association other than chance location of the cursor, when I chose to issue that request. However that validation is done according to design :-(

some libraries in that list work fine, but most don't. If I
don't specify generic name selection in PDM option 1, there is no
problem.

funny strange eh?

Not strange if indeed the objects in the lits are /suspended/.

The PDM#### error condition that is being reported is [in]directly a response to the exception 2203 "Object suspended" error message MCH3403 which indicates that [effectively] the object was previously saved using STG(*FREE) as the message suggests. How the object name replacement text is established by PDM may be dependent on whether the msgMCH3403 is signaled directly to PDM versus a CPF21## message from the list object feature [actually PDM uses its own list object function rather than the /librarian/ feature; probably any indirect message is the same or another PDM#### message]. Presumably a search for that message identifier as token, with an OR condition for that same token prefixed with msg [i.e. msgPDM####], would find an APAR describing the problem if it were known & documented in an APAR.

Is the error condition correct, except its replacement text of blank? That is, does DSPOBJD of any of the objects against which the [user defined] options are issued and for which the error suggests the unnamed object is /freed/ [aka suspended]? FWiW a database *FILE can not truly be /suspended/, only any one or up to all of its members can have their data freed.

Some object types can not actually be suspended. It seems the *LIB either can, or that those objects are incorrectly being interpreted as having been suspended; again, see the DSPOBJD details. If a library can be suspended, the fact that the PDM#### hard codes the word 'File' would suggest that it probably only intends to send that message from WRKOBJPDM and possibly in a poorly worded manner from WRKMBRPDM. That would also explain why the /object/ name would not be set when using the WRKLIBPDM [i.e. list of library objects] since PDM tracks the /object/ and /library/ separately to reflect the hierarchy. You could attempt the following invocation to review if at least the /object name/ appears correct in the message [replacement variable]:
WRKOBJPDM OBJ('*SRC*') LIB(QSYS)

Regards, Chuck