On 10 Feb 2013 18:50, Rory Hewitt wrote:
I believe IBM stopped their unofficial support for QSPDSPFM a
couple of releases back :( The object domain error you're
getting is because of that.
FWiW, as in... I am adding further comments, with the quoted text of
the messages as a lead-in, more than directly responding to either of
the prior replies.
I doubt the program was ever given any "unofficial support" as
callable from user code. Any system program can be called, given the
proper and allowable [by the OS] circumstances. Most likely someone
just figured out how to call the program such that [there was the
appearance that] the request was fully functional. But that alone did
not make that system program into an API [I am clear that the above
quote did not say that]. For how someone might have attempted to infer
how the system program functioned, based on examples of intercepted
invocations to review what the parameters and data that were passed:
# Subject: [MI400] QSPDSPFM parameters
# From: "Beppe Costagliola" <beppecosta@xxxxxxxx>
# Date: Thu, 18 Mar 2004 18:53:23 +0100
http://archive.midrange.com/mi400/200403/msg00035.html
From 30Nov1999 someone noted that "[t]he option to display messages
is still available by calling API QSPDSPFM, but only if your system is
at security level 30." However that is obviously a misstatement,
because an actual system API would not have the requirement that
QSECURITY be less than or equal to 30. An object domain error, MCH6801
IIRC, is the proper error for an attempt to call a system program that
is not an [undocumented or documented] API.
http://www.mcpressonline.com/programming/cl/jwsplf-a-better-wrksplf-utility.html
The following message further explains why the program was never an
API; i.e. the interface changed so the invokers had to change, with no
warning from IBM in the MTU:
# Subject: Re: [MI400] QSPDSPFM parameters
# From: "Beppe Costagliola" <beppecosta@xxxxxxxx>
# Date: Fri, 19 Mar 2004 09:13:53 +0100
http://archive.midrange.com/mi400/200403/msg00041.html
No workaround that I know of.
Presumably changing the Security Level to one that allows User State
programs to call System State programs, or to make the calling program
run in the System State; not to imply in any way that the latter is
supported.
Additional comments further below...
On Sun, Feb 10, 2013 at 5:26 PM, Jorge Merino wrote:
Long history short, for years I've had an utility that works
almost-like WRKSPLF <<SNIP>>
I found that QSPDSPFM has been discussed in the past as an
undocumented, unsupported sort of API and some folks were able
to use it.
As noted above, using a call to a System Program with a Security
Level that did not prevent the action. To better ensure the integrity
of a system, user programs should not be allowed to call System State
programs, and so the QSECURITY should be set to 40 or higher.
I've been trying to make it work with no success: this is what I
got so far:
d QSPDSPFM pr ExtPGM('QSPDSPFM')
d <<SNIP>>
The error message that I'm getting is "Object domain or storage
protection error for offset in object QSPDSPFM"
Any ideas? Does anybody have a working example for V7R1?
The message key and queue name are available since V3R1M0 from API
QSPRWTRI. That information can be used to write a functional equivalent
to what is provided by the System Program QSPDSPFM, and Carsten's
message seems to be a good lead to get some code versus RYO.
midrange.com
