On 23 May 2005 05:42:21 -0700,
[EMAIL PROTECTED] (Joe Zitzelberger) wrote:
>What is the purpose of moving the parm to an internal field?
Suppose I want to insure that the PARM field contains nothing but
upper-case characters? A TR instruction could handle that requirement
fairly well, but what if my program was invoked via LINK, and the caller's
PARM field lives in read-only storage?
Or my application is written in C. I'm expecting a PARM field containing a
comma-delimited set of values. I decide to use strtok() to process the
PARM field. But strtok(), like the TR instruction, modifies the data
that's being processed.
>That just strikes me as broken as designed (BAD). You cannot
>change the value, it is truly input only. It also strikes me
>as more effort than just using the parm inplace in this age of
>reentrent and reusable code styles.
As suggested above, there could be legitimate reasons for an application
to modify a PARM string. To me, it seems foolish to blithely assume that I
can do whatever I want with the PARM string, processing the data in-place.
That's why I have written applications that copy the PARM string to
working storage controlled by my program.
Eric
--
Eric Chevalier E-mail: [EMAIL PROTECTED]
Web: www.tulsagrammer.com
Is that call really worth your child's life? HANG UP AND DRIVE!
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
