This is a typical way of presenting a choice among several mutually exclusive options, and can be implemented using either of the techniques described above for checkboxes. (If using INFLD, use ||r rather than ||c to create a radio button field.) However, despite the obvious parallel to checkboxes, radio buttons do not correspond neatly to any legacy data entry INFLD construct, because it breaks the normal one data field to one input field correspondence.
For example, consider a payroll application that needs to know the marital status, with the choices being single, married filing together and married filing separately. Since this information is going to be stored as a single data item (probably coded as a number), it would be easiest to just prompt for the code number (1-3) while displaying a menu. To present this as a series of radio buttons, we need more screen real estate and logic to check each of the fields to see which one was selected. So, while they may look neat, they may not be that practical to implement, especially when migrating from, or trying to preserve compatibility with a text implementation of the same application. A much more natural, and legacy-friendly way to present such a choice is via a combo box.