On 13-Nov-2013 11:46 -0800, rob@xxxxxxxxx wrote:
On IBM i the default for the RQSDTA parameter is *CMD, which means go
look at the CMD parameter. On the S/38 it didn't have a CMD parameter
so you really had to use RQSDTA.
SBMJOB RQSDTA('call pgm') or
SBMJOB JOB(DSPJOB) RQSDTA('dspjob output(*print)')
There are a few cases where using RQSDTA makes sense but none
immediately come to mind.
Sometimes, because the Request Data (RQSDTA) parameter is defined by
PARM TYPE(*CHAR) parameter whereas the Command (CMD) parameter is
defined by PARM TYPE(*CMD). The former declarative enables a command
request to be built using a /string expression/ that is received by the
request processor exactly as formed. The latter declarative enables a
command request to be prompted and reformatted, which is very nice, but
that also prevents the use of expressions to define the elements of the
PARM(), and that inhibits the ability to avoid the loss of significant
blanks when a variable declared as more than 32-bytes is passed as a
parameter on the PARM() of the CALL.
http://www.itjungle.com/mgo/mgo121102-readers.html
Midrange Guru Tech Tips
Title: SBMJOB's RQSDTA Parameter
"... parameters that are longer than 32 characters in order to pass them
through the Submit Job (SBMJOB) command without running into the problem
of garbage data replacing trailing blanks. There is another alternative.
The alternative choice is to use the Request Data (RQSDTA) parameter
instead of the Command (CMD) parameter.
..."
But more generically, the Request Data can be used when the /request/
is not a CL command. For that, the Routing Data (RTGDTA) would usually
come from a *JOBD, or would be explicitly specified, or would redirect
to the Request Data itself, to ensure that the non-CL-command request
gets processed by the correct request program; i.e. a program that knows
what to do with the /data/ that composes the effective request; i.e. the
message of type *RQS. Often a Job Queue (JOBQ) specification would be
included as well, to further refine where the work is directed. The
/request/ need not be in a conspicuous form of a directive... as it
could be just some string of data that the request program consumes more
directly, rather than something that is parsed as an effective
directive\command. The data sent could be effectively no-data, i.e. the
special value *NONE, such that the processor must know what to do even
without any specific data being passed to the program as a request
message\data.
I could have a request program that performs an SQL request instead
of a CL command request; e.g. as effected by use of a routing entry for
the data\string "DYNSQL". The QCMD program, as the default CL request
processor, would have no idea how to handle the SQL request. The
user-defined processor could even enable allowing an alternate
delimiter, to ease the specification of the SQL as a CL
apostrophe-delimited string:
sbmjob rqsdta('insert into myfile select "char_const",
current_date, t.* from somelibr/somefile as t') rtgdta('DYNSQL')
Of course that particular request since has the IBM-provided RUNSQL
command, or instead could have been implemented with the DB2 utility
under a QSH command even prior to that Run SQL feature. But the point
is, that *any* processor can be invoked with a string of /data/ rather
than a CL /command/ string. A couple other examples, to be inferred by
the reader what the setup of routing might be, and what the effects of
the request data might be, per the request processor acting on that data:
sbmjob rqsdta('file://...') rtgdta(*rqsdta)
sbmjob rqsdta('http://...') rtgdta(*rqsdta) jobq(url)
sbmjob rqsdta('TARGETLIB UNZIP /dir/ZIPpedSaveFile') jobq(zip)
rtgdta(*rqsdta)
sbmjob rqsdta('mailto:...') rtgdta(*rqsdta) jobq(messaging)
sbmjob rqsdta('sms:...') rtgdta(TEXT) jobq(messaging)
midrange.com
