I personally would prefer a stage option rather than a configuration option.
If a new module expected one behavior and a legacy, reused module, especially a user stage, expected the other, there might be an unresolvable conflict between the two approaches. On Mon, Jan 4, 2016 at 11:47 AM, John P. Hartmann <jphartm...@gmail.com> wrote: > Looking back, I think I made the wrong call 25 years ago. If case 3 > were to produce a null record, the output would always contain at least > as many records as the input. > > Stripping to create a null input record to subvert split dropping the > record when nothing is left is a cop-out. And it is more difficult to > anticipate in the general case of split. > > Too late to change, I suppose, though a configuration variable might be > a way out. > > On 01/04/2016 04:06 PM, Rob Van der Heij wrote: > >> >> I can answer this one - >>> >> >> I am impressed if you could without trying it. But indeed it is working as >> documented. Reading the usage notes, it looks like I was confused in the >> past to make The Piper clarify things ;-) >> >> #1 - LITERAL puts a null record in, split does nothing (no blanks) >>> resulting in 1 null record to count >>> #2 - same as #1 (LITERAL expects one blank before the intended string; no >>> string so null record) >>> #3 - One blank added as literal, split strips it off, resulting in zero >>> records >>> >> >> The STRLITERAL now helps to take away doubts about #1 and #2. Much of this >> is driven by the need to remain compatible with things that were done 30 >> years ago. With null records, some of the concepts get a bit hard to >> explain. Quite often, it does not really matter. >> >> Rob >> >> --- >> Rob van der Heij >> z/VM Development, CMS Pipelines >> Tenzij hierboven anders aangegeven: / Unless stated otherwise above: >> IBM Nederland B.V. >> Gevestigd te Amsterdam >> Inschrijving Handelsregister Amsterdam Nr. 33054214 >> >> -- OREXXMan
