G’day!

If you ever wondered about the “physics” of S_TCODE authorization ranges, this post is for you.
We’ll take a look at the order of characters (which is essential for correct ranges) and the pitfalls to avoid.
Basics
To keep things easy and since most of us (?) are probably using a keyboard with Latin-1 characters on it, I’ll focus on the ISO-8859-1 character set… though this is not exhaustive, as your system might use UTF-8 or some other charset.
Basically, the character code in the “From” value of a range serves as the start value and is incremented until the “To” code is reached. All characters between the low and high end of the range are covered; so, A … Z* includes AA, AAA, BBBB … ZZZZZ …
Concerning the order of characters, a range from/to Z is treated basically like this:
#!/usr/bin/env perl $from = ord("/"); # Character code 47 $to = ord("Z"); # Character code 90 for ( $from .. $to ) { print $_ . " == " . chr($_) . "\n"; } |
Jump to ideone.com to execute the code online or to Wikipedia for a table of ISO-8859-1 characters.
Btw.: some characters – e.g. backspace – are not printable and thus not usable.
Wildcards
Usually, SAP allows us to use 2 wildcard characters: * (match any number of characters) and + (match a single character), but for authorization values only the asterisk is valid; the plus sign is treated as a normal character (see SAP Note 136647).
At this point, I’d like to stress:
An asterisk at the end of a “From” value of a value range
is never useful and might even be terribly wrong!
The reason for this is that the start value is the first character in the range and all “higher” character (combinations) have a “higher” value (i.e. A < AA < AAA).
Bad example:
The range SU* … SU21 includes SU24 as well, because the “From” value already covers all SU… transactions.
Transaction codes
To be able to create valid (and sensible) ranges for S_TCODE, we’ll next look at the characters allowed in tcodes, because all others are of no interest (at least until we take a look at the tcodes SAP created itself).
In SE93 you’ll get this error, when trying to use a disallowed character:

The function module responsible for this safety-belt is “RS_CHARACTER_CHECK” (called in the include LSEUKFWM), which gives us an idea of the set of allowed characters:
CONCATENATE 'ABCDEFGHIJKLNMOPQRSTUVWXYZ_0123456789/' allowed_special_characters " Set to '+' in LSEUKFWM INTO allowed_characters. |
This should be the full range one has to take into consideration when doing S_TCODE… which is only almost true… because SAP is not bound to the above restriction! When you look into table TSTC you’ll find tcodes which contain characters not allowed by the above check. At least on a number of systems, I found quite some.
Here’s a summary of the order of ASCII characters and corresponding notes (explanation below the table):
ISO-8859-1 | Character | Usable in customer tcodes ? | Used in any tcode ? | First character of any tcode ? | Note on general usage in authorization values |
---|---|---|---|---|---|
0 … 31 | ( control characters ) | No | No | No | Not usable. |
32 | ( space ) | Spaces at the end of authorization values are automatically cut off. | |||
33 | ! | Yes | Cannot be used at the beginning of authorization values. | ||
34 | " | No | |||
35 | # | Yes | |||
36 | $ | ||||
37 | % | ||||
38 | & | ||||
39 | ' | No | |||
40 | ( | Yes | Cannot be used at the beginning of any authorization value. | ||
41 | ) | ||||
42 | * | No | Wildcard character. If used in the middle of a value, all subsequent characters are ignored (see SAP Note 136647). | ||
43 | + | Yes | Yes | Yes | Not a wildcard, but treated as a normal character in authorization values (see SAP Note 136647). |
44 | , | No | Yes | No | |
45 | - | No | |||
46 | . | Yes | |||
47 | / | Yes (namespace delimiter) | Yes (namespace delimiter) | Yes | |
48 … 57 | 0 … 9 | Yes | Yes | ||
58 | : | No | Yes | No | |
59 | ; | No | |||
60 | < | Yes | |||
61 | = | ||||
62 | > | ||||
63 | ? | ||||
64 | @ | No | |||
65 … 90 | A … Z | Yes | Yes | Yes | |
91 | [ | No | No | ||
92 | \ | No | |||
93 | ] | Yes | |||
94 | ^ | No | |||
95 | _ | Yes | Yes | Yes | Cannot be used as the only character in a value. |
96 | ` | No | Yes | No | |
97 … 122 | a … z | No (only uppercase letters) | No (only uppercase letters) | ||
123 | { | No | Yes | ||
124 | | | No | |||
125 | } | Yes | |||
126 | ~ | No | |||
127 | ( delete ) | Not usable. | |||
128 … 166 | € … ¦ | No (extended ASCII) | No | Usable, but won't make sense in the majority of cases. | |
167 | § | Yes | |||
168 … 255 | ¨ … ÿ | No | Usable, but won't make sense in the majority of cases. | ||
ISO-8859-1 | Character | Usable in customer tcodes ? | Used in any tcode ? | First character of any tcode ? | Note on general usage in authorization values |
Explanation:
- ISO-8859-1 … the character code
- Character … self-explanatory
- Usable in customer tcodes? – see above (RS_CHARACTER_CHECK)
- Used in any tcode? – red, if not consistent with 3rd column; green if so
- First character of any tcode? – red, if not consistent with 3rd column; green otherwise
- Note on general usage in authorization values … self-explanatory
Conclusion
If you want to obfuscate an asterisk in S_TCODE, just replace it with: + … _* — hardly anybody will ever notice 😉