Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker!bloom-beacon!eru!hagbard!sunic!eric
From: eric@sunic.sunet.se (Eric Thomas SUNET)
Newsgroups: comp.lang.asm370
Subject: Re: Testing to see if screen is in MORE status
Message-ID: <2185@sunic.sunet.se>
Date: 2 Oct 90 20:06:12 GMT
References: <9010021416.AA24712@ucbvax.Berkeley.EDU>
Distribution: inet
Organization: Royal Institute of Technology, Sweden
Lines: 43

In article <9010021416.AA24712@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes:
>Since the screen write instruction keeps testing until the screen is clear,
>it won't receive any more data from the CTC, tying the other end up.

That is where the problem is, it shouldn't do that. Your write-line-to-screen
routine should first check if the terminal is ready, if so do the SIO now,
otherwise copy the message to a buffer (ideally a chained list from dynamically
allocated storage with some self-imposed limit on the number of entries to
avoid running out of memory if the program goes crazy). When you get the device
end from the console, send the next message, and so on. A more "practical"
description of the algorithm would be:

Write-a-line routine:

1. If you have more than N messages waiting, ignore request.

2. If you have exactly N messages waiting, alter address/length registers
   to point to a hardcoded message saying additional lines had to be
   discarded.

3. Increment the number-of-messages counter, get a chunk of storage to hold
   the message, copy it over, add to bottom of chained list.

4. If the chained list was not empty when you added, return.

5. See if the terminal is ready; if so, start the I/O for the first message
   in the chain (that's a subroutine you will call from the interrupt
   level as well).

Interrupt level:

A. On a channel end, dispose of the first message in the chained list and
   decrement N.

B. On a device end, call the subroutine mentioned in (5) if the chained list
   is not empty.

This should all take place with interrupts disabled of course; the logic I
quoted assumes you are the only one doing I/O to the console, if you mix up
CMS I/O with your I/O you need another routine to wait until you're done
printing your stuff before calling CMS.

  Eric