Please excuse the previous truncated reply.
> I'm talking about only Rexx here.
I misread his comment the same way. Then I realized that he was referring to
the difference between these:
call rtn foo, bar, baz
call rtn foo bar baz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf of
Charles Mills [[email protected]]
Sent: Tuesday, April 14, 2020 12:51 PM
To: [email protected]
Subject: Re: Apparent bug in CBT 617 SMFREPT
Yeah, the INTERPRET is gratuitous. Not my code.
It's not a matter of CAPS ON or not. The input to the routine is a binary SMF
timestamp.
The effect of PARSE UPPER is subtle. It does not simply OR on X'40' like an
assembler programmer in the eighties. It only happens about one-tenth of the
time (26/256). X'80' is unchanged; X'81' becomes X'C1', and so forth. (I spent
a LOT of time shooting this bug.) An extra 40 in byte 3 of an SMF time adds .64
seconds and is mostly unnoticeable. An extra 40 in byte 2 adds a little under 3
minutes and easily escapes attention. An extra 40 in byte 1 adds about 12 hours
and jumps right out at you. (35 o'clock!) But it does not happen until about
11:30 PM, which is X'00810000' in SMF timestamp format. So the bug is very
subtle.
> That works only for Rexx
I'm talking about only Rexx here. These are internal subroutines in a larger
Rexx program. If the arguments are from a command or the like then either you
want upper case or immediately notice that you got what you did not want.
But yes, I guess PARSE ARG FOO BAR SOJACK is a better match to ARG FOO BAR
SOJACJ and does fix the problem.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Paul Gilmartin
Sent: Tuesday, April 14, 2020 9:08 AM
To: [email protected]
Subject: Re: Apparent bug in CBT 617 SMFREPT
On Tue, 14 Apr 2020 08:50:27 -0700, Charles Mills wrote:
>
>I got an off-list note from Sam Golob asking me to submit an actual fix, so
>I downloaded CBT 617 to have a clean copy to start from and it is *not* the
>source of the program I am using (and complaining about here).
>
>It *does* however have the same bug:
>
>BINTDECR:
>NUMERIC DIGITS 20
>ARG LITERAL
>INTZ = "LITERAL = C2X(''LITERAL'')"
>INTERPRET INTZ
>...
Ouch! INTERPRET is unnecessary, and perhaps dangerous
because of the possibility of code injection via the value of ARG.
"A little learning is a dangerous thing."
>Not sure exactly where to go from here. This misuse of ARG for binary fields
>seems to be pervasive! I don't have the time to be "Mr. Fix all the CBT Rexx
>misuses of ARG."
>
They probably expect you to prepare your input with CAPS ON.
>If you are using any Rexx code that processes binary data (such as SMF
>records) you might want to do a quick FIND on ARG and see if it has the same
>problem. Easy to fix:
>
>ARG FOO becomes FOO = ARG(1)
>
OK.
>ARG FOO BAR SOJACK becomes
>
>FOO = ARG(1)
>BAR = ARG(2)
>SOJACK = ARG(3)
>Etc.
>
No. That works only for Rexx:
CALL BINTDECR FOO, BAR, SOJACK
Use PARSE ARG FOO BAR SOJACK, which preserves case.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
