The only real problem with delimiters is when the delimiter can occur in the data. Often a good reason for avoiding commas. Tab can be good, as long as the data cannot contain tab (unlikely for Mainframe data).
Delimiters in the data can be "protected" by enclosing the data of that field in double-quotes. This is only a genuine problem when the the "other end" can only process text-and-control-codes and when "any value is possible in the data". However, it can also be an issue due to "diktat" - "this delimiter must be used, otherwise the world will stop revolving". That's bad when the delimiter can appear in the data. If you parse incoming delimited files that contain delimiter-protected fields, using UNSTRING can become tricky. Otherwise, UNSTRING is fine, the only drawback is having to name all the receiving fields, checking for complete records (all have same number of fields) afterwards (there's a "thing" in UNSTRING which is useful for that). Forming the delimited record, you have to again be aware of the possibility of the delimiter being in the data. STRING is useful, because it handles the variablility of position for you. Using STRING is a rare case where you have to set the output to an initial value (like SPACE/SPACES) because STRING does not pad to the end of the target field (which is great when you don't want to do padding, but, since you usually do, one of those little things). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
