KXH105@PSUVM.BITNET ("Ken Hornstein 862-7007", 814) (10/02/90)
Thanks to Rainer Koch, Orhan, and Rodolfo, I have gotten my silly interrupt message handler to work, but I have run into a small problem: I am using CTC's to transmit messages, and I can display them with no problems. But, if the screen fills up, I get in MORE/HOLDING status, and then I am stuck. 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. Now is there a way to test for when the screen is in MORE/HOLDING (one of the bits in the CSW maybe) ? I tried testing some of the bits in the CSW, but with little success. --- I have decided to devote my entire career to looking for a career. Ken Hornstein kxh105@psuvm.psu.edu Phone: 814/862-7007
eric@sunic.sunet.se (Eric Thomas SUNET) (10/03/90)
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
eric@BLOOM-BEACON.MIT.EDU (Eric Thomas SUNET) (10/03/90)
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