× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 27-Oct-2015 15:34 -0500, CRPence wrote:
On 27-Oct-2015 14:30 -0500, gio.cot wrote:

I would from RPGLE run a SBMJOB that call a program passing
numeric parameters .. is it possible ?

The means to do so are possible from any language, and the
requirements remain the same irrespective of language. So despite the
topic seemingly more appropriate on the language-specific forum, my
reply is generically presented for any language.


Example

D Runcmd PR EXTPGM('QCMDEXC')
D Cmdstr 3000A CONST OPTIONS(*VARSIZE)
D Cmdlen 15P 5 CONST
D Cmddbcs 3A CONST OPTIONS(*NOPASS)

D Q C ''''

D Command_String S 3000A Varying

Command_String =
'SBMJOB CMD(CALL PGM('+ q + MyPgm + q +') PARM(' +
Q + DbTrgDs + Q DbTrgLen '))';

Runcmd(Command_String : %LEN(%TRIMR (Command_String)));


Whatever is being done in the above, is probably worth discussion
in a fresh topic, *before* attempting to continue down that path;
depending on requirements, the path possibly of a downward spiral,
into a nightmarish hellhole.

Just adding here, a new comment, merely to add emphasis on the above comment. Whatever led to the above proposed attempt at invoking a dynamically named program with an apparent Trigger Buffer and Trigger Length [mimicking a trigger program invocation], should probably be reevaluated.


The passing of a Data Structure (DS) is almost sure to fail, if not
pervasively and catastrophically, then worse, sometimes and\or only
subtly with unexpected effects. What is alluded by the described [or
should I suggest, what I infer from the described] could be
functional more generally, only *if* the DS were exposed as a
hexadecimal string prefixed by X to denote that the character string
is passed as a hexadecimal character string.


I should have noted here additionally, that the quoting of the program name, as shown, is undesirable; the "+ q" on either side of MyPgm would need to be removed. A "CMD()" portion of the request should appear as "CMD(CALL PGM(THELIB/THEPGM)...)", not as "CMD(CALL PGM('THELIB/THEPGM')...)"


N.B. DBTRGLEN is B(9,0)

The proper designation for the data type\length of the second argument
for a trigger program is INTEGER, or for the RPG, that would be in
fixed-form 10I00 [instead of the 09B00 shown {expressed however, as
B(9,0)}].


I should have additionally expressed that the above applied to DbTrgLen as defined for being passed as an argument. For the argument being passed for a parameter defined as 10I00 or 09B00, like the above mention of passing the data as a hexadecimal string representing the stored INTEGER data would be required here as well; i.e. the later explanation describing having included the numeric value cast as the character string of numeric digits, would be functional for when the called-program had defined the parameter as DECIMAL(15, 5).

The PARM(), to function most generically [to avoid potential pitfalls in passing DS data], would need to be constructed as, to appear as, something like the following [where the D..S represents the DbTrgDs data converted to a string of hexadecimal digits, and the "#..#" represents the DbTrgLen data converted to a string of hexadecimal digits; thus each enclosed within the apostrophes of X'']:

PARM(X'D..S' X'#..#')



How can I do it ?


As a command /string/, a numeric value must appear as the character
representation of the numeric value.

In a concatenation expression to place the numeric value within that
string, requires one of:
• that the numeric variable would be replaced by an expression
that explicitly converts the numeric value into a character-string
value
• a character [string] variable takes the place of the numeric
variable in the concatenation expression, after a conversion casting
the value from the numeric variable into the character variable has
already transpired
• that the language has an implicit casting from numeric to
character [and that the effect meets the requirements] thus allowing
the numeric variable to remain in the character concatenation
expression

For the RPG language, the %EDITC() built-in is one means to convert
the numeric value for the variable DbTrgLen into a character-string,
thus allowing the first of the above; e.g. %editc(DbTrgLen:'L') in
place of DbTrgLen in the currently coded expression. Or that same
Editing expression could assign a variable, perhaps named
CharDbTrgLen, and declared as 11 or more characters; e.g. prior to
the currently coded expression, include a
CharDbTrgLen=%editc(DbTrgLen:'L'), and replace the DbTrgLen in the
concatenation expression with CharDbTrgLen. But for lack [of my
knowing of] any implicit casting in the RPG, I do not believe the
last of those options are possible.

For any other language, the effective equivalent; both the issues
with the scenario [notably an effective DS, expressed as a
character-string, is likely to be problematic at best], and the
requirement to convert the numeric value into a character string
[because the input to the command-interpreter APIs will be a
command-string].


And I will repeat, that although _possible_ to accomplish generally the building of a command-string that effects a CL CALL in a CMD() [or a RQSDTA()] parameter of a Submit Job (SBMJOB), what is likely being attempted should probably not be attempted. Probably best to explain what is the intention\goal [what originated arriving at the attempted invocation], and then inquire how to achieve that goal, but composed in a new topic not burdened by the problematic CALL scenario presented in the OP for this topic.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.