Re: Command Parameter Grief.

Thanks to all that chimed in. It was indeed the command line string
argument issue. I thought it was something else because of the messages I
was receiving in the log, but that wasn't the case.

I used Occam's razor today...nice clean shave.

Thanks for the help!

On Mon, Aug 8, 2016 at 7:59 AM, Michael Ryan <michaelrtr@xxxxxxxxx> wrote:

Thanks Chuck!

On Sun, Aug 7, 2016 at 3:17 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 06-Aug-2016 14:46 -0500, Michael Ryan wrote:

Support call placed Friday.

Perhaps I was not sufficiently clear in alluding to the cause of the
problem being a usage issue; i.e. the origin for the corruption to the data
passed on the parameter, arose even before the command [under that
/support/] is ever getting invoked.
[http://archive.midrange.com/midrange-l/201608/msg00150.html]

Quite likely the /identical effect/ would be achieved using the same
failing CALL [seen in the above archived message], but having used the
following alternative source to define the parameters and failing-request
[OVPRTF instead of IFMASM command] for the program TEM028C:

pgm parm( &p1 &p2 &p3 &p4 &p5 )
dclprcopt LOG(*YES)
dcl &p1 *char 3
dcl &p2 *char 7
dcl &p3 *char 74
dcl &p4 *char 1
dcl &p5 *dec ( 15 5)
ovrprtf *prtf tostmf(&p3)
monmsg cpf0001 exec()
dspjoblog


Compare the [lack of any difference for the] data from the third
argument of the CALL when used in the TOSTMF() parameter of the failing
OVRPRTF request using the above CLP, to what presumably is the same
argument used in the ASMFLE() parameter of the failing ISFMASM command
request as seen in the above archived message [and included further below,
for easier reference]; directly below, is the actual output seen from a
test:

• CALL PGM(TEM028C) PARM('031' '0000462' '/sigpdf/0310000462.PDF' ' ' 0)
2000 - OVRPRTF FILE(*PRTF) TOSTMF(
X'61A2898797848661F0F3F1F0F0F0F0F4F6F24BD7C4C640404040404040404040404040
404040404040404040404040404040404040404040404040404040404040400000000000
00000F')


• CALL PGM(TEM028C) PARM('031' '0000462' '/sigpdf/0310000462.PDF' ' ' 0)
[…]
4825 - IFMASM ASMFLE((*IFS X'61A2898797848661F0F3F1F0F0F0
F0F4F6F24BD7C4C640404040404040404040404040 404040404040404040404040404040
404040404040404040404040404040400000000000
00000F')) […]


Because the third parameter is declared [in my alternate\contrived CLP
example] as a 74-byte character, thus is "declared with a length greater
than 32", the CALL needs to pass a string-literal "including every byte for
the entire length of the as-declared *char data-type argument as PARM() in
the called program"; e.g. again with the alternate\contrived CLP source,
the following revised CALL coded in a CLP would succeed [irrespective the
chosen, but consistent, alignment of the comment lines together with the
lines betwixt; the coding ensures all 74 bytes, or several extra, are
specified\included]:

CALL PGM(TEM028C) PARM('031' '0000462' +
/* ....+....1....+....2....+....3....+....4....+....5 */+
'/sigpdf/0310000462.PDF -
' +
/* ....+....6....+....7.... */ +
' ' 0)

Or if instead invoked from a command-line\command-entry, then perhaps
the following [with comment included, as above, to assist formatting to
ensure all bytes are provided]:

===> CALL PGM(TEM028C) PARM('031' '0000462'
/*....+....1....+....2....+....3....+....4....+....5....+...
.6....+....7....*/
'/sigpdf/0310000462.PDF
'
' ' 0 )

--
Regards, Chuck


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.