I found this is my drafts folder. Sorry to post it 18 months late, but I think this still has value.
----------- For what it's worth, I think the real issue is with the hex string syntax not allowing the specification of a null string. In order to support any user string, including a null string, I had to write PipStr(), which checked for a null string, and if null, returned "//". Otherwise It returned "x"c2x(Str) . It was used in a lot of places. It was a bit annoying to change a lot of code just for that. Perhaps hex strings could have an optional delimiter, which would also allow embedded blanks (like REXX) for readability and consistancy: x// = null string. x/f1f2f3/ = "123" x/f1 f2 f3/ = same On Sep 24, 2013 6:10 PM, "Glenn Knickerbocker" <[email protected]> wrote: > I tend not to use ALL much and build my own cascades instead, and I > hadn't run into this message before: > > > PIPRIC064E Hexadecimal data missing after /. > > PIPMSG003I ... Issued from stage 1 of pipeline 1. > > PIPMSG001I ... Running "all (/word/ & //)". > > PIPRIC192I ... Scan at position 12; previous data "(/word/ & //". > > "Hexadecimal" was puzzling here and sent me to the syntax diagram > looking for special cases involving hex strings. I finally realized it > really just meant "Data missing"--the string would be converted to hex > in the generated subroutine pipeline, so the null string would have > caused this message if that were run: > > *.input.0: > !locate XA6969984 > !locate X > !*.output.0: > > The doc for ALL doesn't mention that null strings aren't allowed. Sure > would be nice if they were just used as-is instead of failing. Even > nicer if they were skipped--my own execs are full of code like this: > > If word = '' then locate = '' > Else locate = '| locate x' || c2x(word) > > Nicest of all if they caused alternatives to be skipped as well, so that: > > all /word/ & // & (/more/ ! //) > > worked out to just: > > *.input.0: > !locate XA6969984 > !*.output.0: > > ¬R >
