On Thu, 4 Oct 2012 10:53:05 -0400, John Gilmore wrote:
>[Someone] wrote:
>
><begin extract>
>Why would a rational programmer cause an "empty" record to be written
>in the first place?
><end extract>
>
>Imaginative failures about what someone else may reasonably wish to do
>with a facility are common. Boundary values are thus the problem.
>They must be handled correctly and appropriately, and systems and
>subroutines must be tested to ensure that they are.
>
Or, the OS can prohibit the occurrence of boundary values, and the
programmer need never be concerned with them. VM/CMS MDFS
prohibits empty files and empty records within nonempty files
thus sparing the programmer the need to deal with them. Empty
transaction file? Simply supply a null transaction.
I once encountered a sort routine that misbehaved when presented
an input data set consisting of only a single item. (If I wrote it,
I've conveniently forgotten the fact.) Of course the conscientious
("rational") programmer should pretest for the single item case
and simply copy the input data set to the output, bypassing the
considerable overhead of a needless sort.
SMP/E prohibits in SMPPTFIN "++ sysmod FILES(0) ..."; instead I
must treat this as a special case and omit the FILES option when
the condition arises. The argument that FILES(0) might be
inadvertent and the programmer should be alerted to correct it
is refuted in my perception in that the programmer is more likely
to notice and correct an inadvertent value of zero than to notice
an inadvertent omission of the entire FILES operand.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
