The button caused a Unit Exception on the last read; BSAM and QSAM called EODAD
at that point. There is no need for /*EOF in that scenario.
HASP added the /*EOF in support of the internal reader, but it was also useful
for a card reader. Consider
//MYJOB JOB ...
...
//FOO DD *
...
/*EOF
./BAD JOB ...
However, a // would work just as well for that purpose.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [0000000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 25, 2021 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Edit: Introduce New SUBMIT Module
On Thu, 24 Jun 2021 21:21:31 +0000, Gibney, Dave wrote:
>In the days of cards, when your //SYSIN DD * might be the last file in the
>current deck on the reader
>
The lore communicated to me was:
When the reader's hopper is empty, the reader hangs on a read.
Three's a button the operator can press to simulate EOF in the channel status.
So, does /*EOF allow unattended operation of the reader?
I believe that //name JOB ... likewise serves to terminate the previous job.
How does //SYSIN DD *,DLM=XX interact with /*EOF or //name JOB ...?
In a CDC 6400 OS, a job was terminated by a 6-7-8-9 punch in column 1,
invalid in either text or binary encoding.
I heard legends of another OS (UNISYS?) which simply stacked SYSINs
on a batch input tape. If any job opened either too many SYSINs or
too few, subsequent jobs read the wrong data sets.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
