Hi I farther tested the issue in context. \U, \u are consistent and will fail whether I supply any text to match or not.
the \l does not fail as I've already shown and if I provide an input text it will match alright.
the \L behavior changes when I provide an input text to match. Please observe the behavior below where the \L produces an initial, uncalled for 'No Match' and then it happily does match. It seems to be a sort of a bug in the behavior of \l and \L that is triggered by the EBCDIC environment rather than caused by it.
I believe that this is the most serious open issue in my side. Once resolved, I will try to create a standard, composite test file (or files) and once done to contribute it.
Input file >>>>>>>>>>>>>>>>>>
< forbid 8W
/\l/I
/\L/I
/\l/I l/\L/I l
/\N{name}/I
/\u/I
/\U/I
/\u/I L/\U/I L
<<<<<<<<<<<<<<<<< end input file
Output File>>>>>>>>>>>>>>>>>>>>>
< forbid 8W
/\l/ICapturing subpattern count = 0No optionsFirst char = 'l'No need char
/\L/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\l/ICapturing subpattern count = 0No optionsFirst char = 'l'No need char l 0: l/\L/INo match l 0: l
/\N{name}/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\u/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\U/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
/\u/IFailed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 1
<<<<<<<<<<<<<<<<End Output File
Ze'ev Atlas
