This function is designed to allow one to look at "odd" record structures. I first developed this function to try and look at the records in a NOTES file. Wouldn't it be nice if one could make themselves the owner of all the notes ? I was not entirely successful but here are my attempts. The normal RMS files that Datatrieves handles so well look like: | Smith | John | 23 | | Roseberry | Elroy | 53 | | Hunt | Mark | 21 | Now let us look at "odd" RMS files that do not line up right: | 5 | Smith | 4 | John | | 9 | Roseberry | 5 | Elroy | | 4 | Hunt | 4 | Mark | It is tough to develop a "regular" record definition for these type of files in that the fields do not show up at the same offset in each record. There is, however, a number that shows the length of the field preceeding each field. So you can develop a record definition that looks like: 01 THE_RECORD. 03 FIELD_1_LEN usage long. 03 REST_OF_RECORD pic X(80). 03 FIELD_1 computed by fn$str_extract(REST_OF_RECORD,1,FIELD_1_LEN) Now how can you come up with a record definition for the second field ? You know the starting position of the second field is "length of field 1" plus four (for the four bytes that make up the long word that holds the length of the second field). You know the length of the second field shows up in a long word (4 bytes) after the first field. The problem comes in getting that long word. Now it is easy enough to get the next four bytes after FIELD_1 with something like: 03 FIELD_2_LEN_STR computed by fn$str_extract(REST_OF_RECORD,FIELD_1_LEN + 1, 4) But the result is a character string four bytes long (PIC X(4)) and not a long word (USAGE LONG). So this function does the conversion from: One Character to USAGE BYTE Two Characters to USAGE WORD Four Characters to USAGE LONG Still this involves a lot of looking to try to find out how MAIL, NOTES, and other utilities manage their data files. Sure wish Digital would publish something -- even if it is subject to change! - Bert Roseberry U.S. Coast Guard "The Lifesavers"