In my example, I'm trying to ignore the first three blank-delimited strings and
parse the character string preceding the embedded period in the fourth. That's
what surprised me - Parse considers the third value to be "9" and not the blank
delimited string "9.12". Subword, on the other hand, hews to the definition of
blank delimited word with no regard to the embedded period in the character
string "9.12".
That's where the surprise came in, I was not aware that Parse would break the
string at any delimiter other than a blank when I coded it as this:
myVar = 'word1 word2 9.12 word3.ext'
Parse Var myVar . . . myVal '.' .
Thomas Ambros
zEnterprise Operating Systems
zEnterprise Systems Management
518-436-6433
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Wayne Bickerdike
Sent: Monday, February 24, 2020 23:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx parse using period as placeholder
*** Warning: External message - exercise caution. Think before you click. ***
Interesting. Seymours example came back with a blank.
I used PARSE VALUE MYVAR WITH . . . '.' . WORD3 '.' EXT .
On Tue, Feb 25, 2020 at 10:46 AM Paul Gilmartin <
0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 24 Feb 2020 18:08:48 -0500, Tony Thigpen wrote:
>
> >You have "passed" your first period before your "'.'" in the parse
> >statement is actually interpreted.
> >
> >For your data example:
> >myVar = 'word1 word2 9.12 word3.ext'
> >The correct parse is:
> >Parse Value myVar with . . myVal2 '.' .
> >
> >Each period, or var name, in the parse "eats" one blank delimited word.
> >For example:
> >myvar = 'a b c d e f g'
> >parse var myvar . . 'e' next .
> >will yield next = 'f', but
> >
> >parse var myvar . . . . . 'e' next .
> >will yield next = ''
> >
> Ummm. No. I believe next = 'f':
> parse value 'a b c d e f g' with . . . . . 'e' next .; say next"
> >.> "a"
> >.> "b"
> >.> "c"
> >.> "d"
> >.> ""
> >>> "f"
> >.> "g"
> >V> "f"
> f
>
> -- gil
>
>
>
>
> >For your data, I would first parse the words, then parse each var for '.'.
> >
> >Now, if there is really a special character (or string) that you need
> >to identify, it is best to parse the before and after data, then
> >parse each section. This is how you should handle finding options in
> >a parm string passed to a REXX script:
> >
> >parse value arg with parms '(' options ')' localopts parse var parms
> >parm1 parm2 parm3 parm4 parm5 .
> >parse var options opt1 opt2 opt3 opt4 opt5 opt6 .
> >parse var localopts lopt1 lopt2 lopt3 lopt4 lopt5 .
> >
> >For the above to work, the use of ')' *requires* a previous '('.
> >
> >example: arg = aaa bbb ccc ')' ddd eee
> > parse value arg with parms '(' options ')' localopts
> >
> >will yield:
> >parms = "aaa bbb ccc ) ddd eee"
> >options = ''
> >localopts = ''
> >
> >If this might happen, you would need:
> >parse value arg with part1 ')' localopts parse var part1 parms ')'
> >options parse var parms parm1 parm2 parm3 parm4 parm5 .
> >parse var options opt1 opt2 opt3 opt4 opt5 opt6 .
> >parse var localopts lopt1 lopt2 lopt3 lopt4 lopt5 .
> >
> >
> >
> >Tony Thigpen
> >
> >Seymour J Metz wrote on 2/24/20 5:50 PM:
> >> Isn't that the same, except for the choice of variable names?
> >>
> >> For the type of source string that you're parsing, I'd probably
> >> break
> it into words with a simple parse and then use a parse var foo bar '.'
> baz
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-
> >> 7Esmetz3&d=DwIFaQ&c=Y1KkN7JyAPjrAJTUCirS0fy9vQY8xn4_Oh4EEEpbXx4&r=7
> >> ds2LAJ99_WyGG6a4BwzaJ7R0vee6JgTc4Txes6yEew&m=NpaUBaXFEzfPLAebMs9B1G
> >> aKHWOUHAwXKgRJtkaT1o8&s=TtG3xhRqfA6YTnsgOYLWh64rPyd9IJCBiSKWMRHbQBI
> >> &e=
> >>
> >> ________________________________________
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Ambros, Thomas
> [0000010f77c934b1-dmarc-requ...@listserv.ua.edu]
> >> Sent: Monday, February 24, 2020 4:26 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Rexx parse using period as placeholder
> >>
> >> You mean like this?
> >>
> >> *-* Parse Value myVar with . . . myVal2 '.' .
> >>>>> "word1 word2 9.12 word3.ext"
> >>> .> "word1"
> >>> .> "word2"
> >>> .> "9"
> >>>>> ""
> >>> .> "12 word3.ext"
> >>
> >> But you're correct, variables result in the same behavior:
> >>
> >> *-* Parse Value myVar with t1 t2 t3 myVal2 '.' .
> >>>>> "word1 word2 9.12 word3.ext"
> >>>>> "word1"
> >>>>> "word2"
> >>>>> "9"
> >>>>> ""
> >>> .> "12 word3.ext"
> >>
> >> So it is the definition of a blank delimited word that escaped me.
> I'll look for a precise definition of one of those in the context of Rexx.
> >>
> >> Thomas Ambros
> >> zEnterprise Operating Systems
> >> zEnterprise Systems Management
> >> 518-436-6433
> >>
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
> Behalf Of Seymour J Metz
> >> Sent: Monday, February 24, 2020 16:17
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Rexx parse using period as placeholder
> >>
> >>
> >>
> >> *** Warning: External message - exercise caution. Think before you
> click. ***
> >>
> >>
> >> Why did it surprise you, and what does it have to do with the
> placeholders? You'd get the same thing if you used three variable
> names instead of three periods. The parse with works because it's
> using a different template on a different value: try
> >>
> >> parse Value myVar with . . . myVal '.' .
> >>
> >>
> >> --
> >> Shmuel (Seymour J.) Metz
> >>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es
> metz3&d=DwIFAg&c=Y1KkN7JyAPjrAJTUCirS0fy9vQY8xn4_Oh4EEEpbXx4&r=7ds2LAJ
> 99_WyGG6a4BwzaJ7R0vee6JgTc4Txes6yEew&m=RwHovw9Jb8ZzPnV0Fb8JtuHSrWfHboK
> 75HB0QKXv7Dw&s=7RT-emP8kpFQ1NAQn6MxdRyt8N1z8blOyGY0-o_XwNw&e=
> >>
> >> ________________________________________
> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Ambros, Thomas
> [0000010f77c934b1-dmarc-requ...@listserv.ua.edu]
> >> Sent: Monday, February 24, 2020 3:43 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Rexx parse using period as placeholder
> >>
> >> A trivial item, but this surprised me.
> >>
> >> I wanted to parse out the string 'word3' using the period as a
> >> place
> holder. The input could have a blank delimited string containing an
> embedded period before the one I wanted to parse out. The Parse Var
> as coded didn't work. Using the Parse Value as coded there does work.
> I didn't know it would behave like that. I can't seem to find this
> documented but I might have overlooked something.
> >>
> >> myVar = 'word1 word2 9.12 word3.ext'
> >> Parse Var myVar . . . myVal '.' .
> >> Parse Value Subword(myVar,4) with myVal2 '.' .
> >> Say 'myVal=' myVal
> >> Say 'myVal2=' myVal2
> >> Exit
> >>
> >> Trace R of that code:
> >>
> >> 3 *-* myVar = 'word1 word2 9.12 word3.ext'
> >> >>> "word1 word2 9.12 word3.ext"
> >> 4 *-* Parse Var myVar . . . myVal '.' .
> >> >.> "word1" -
> >> >.> "word2"
> >> >.> "9"
> >> >>> ""
> >> >.> "12 word3.ext"
> >> 5 *-* Parse Value Subword(myVar,4) with myVal2 '.' .
> >> >>> "word3.ext"
> >> >>> "word3"
> >> >.> "ext"
> >> 6 *-* Say 'myVal=' myVal
> >> >>> "myVal= "
> >> myVal=
> >> 7 *-* Say 'myVal2=' myVal2
> >> >>> "myVal2= word3"
> >> myVal2= word3
> >> 8 *-* Exit
> >>
> >> Thomas Ambros
> >> zEnterprise Operating Systems
> >> zEnterprise Systems Management
> >> 518-436-6433
> >>
> >>
> >> This communication may contain privileged and/or confidential
> information. It is intended solely for the use of the addressee. If
> you are not the intended recipient, you are strictly prohibited from
> disclosing, copying, distributing or using any of this information. If
> you received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether
> electronic or hard copy. This communication may contain nonpublic
> personal information about consumers subject to the restrictions of
> the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse
> or redisclose such information for any purpose other than to provide
> the services for which you are receiving the information.
> >>
> >> 127 Public Square, Cleveland, OH 44114
> >>
> >> If you prefer not to receive future e-mail offers for products or
> services from Key, send an email to mailto:dnereque...@key.com with
> 'No Promotional E-mails' in the SUBJECT line.
> >>
> >> -------------------------------------------------------------------
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >> -------------------------------------------------------------------
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >> -------------------------------------------------------------------
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO
> >> IBM-MAIN
> >>
> >> -------------------------------------------------------------------
> >> --- For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO
> >> IBM-MAIN
> >>
> >>
> >
> >---------------------------------------------------------------------
> >- For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO
> >IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Wayne V. Bickerdike
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This communication may contain privileged and/or confidential information. It
is intended solely for the use of the addressee. If you are not the intended
recipient, you are strictly prohibited from disclosing, copying, distributing
or using any of this information. If you received this communication in error,
please contact the sender immediately and destroy the material in its entirety,
whether electronic or hard copy. This communication may contain nonpublic
personal information about consumers subject to the restrictions of the
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose
such information for any purpose other than to provide the services for which
you are receiving the information.
127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from
Key, send an email to mailto:dnereque...@key.com with 'No Promotional E-mails'
in the SUBJECT line.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
