FLIPR and I/O

[John McKee]

When I was a student, one of our assignments involved creating a rather massive RPG program.  It did too much since it did payroll calculations as well as printing.  In order to get the thing to fir in memory, quite a few subroutines had to be listed on the *LOCAL supervisor record.

I can only guess, at this point, but believe the RPG compiler generated a wait when it generated the code to read card.  I know CARD0 was on the *LOCAL card.  Can anybody tell me if RPG compiler did include a busy test and loop immediately after the LIBF CARD0 in order to ensure that there would be no interrupt?

My thought is it had to.  If a level 0 interrupt was generated for a column just read, there would not be time for FLIPR to swap in CARD0 to handle the interrupt.  Unless there was some mechanism where the ISS portion of CARD0 remained in core.  But, that leads me to how memory could be managed. 

I wish I had thought of this when I could play with the 1130.  Simple assembler program with CARD0 and PRNT3.  Put both on *LOCAL. 

Program would read a card and print the content.  Now, add the complexity of double buffering, so card reading could be performed on next card while current card is processed and printed.  Would that have worked?  If so, how?

I suggested an assembler program because I can't remember if RPG coud double buffer.  I do remember 1130 COBOL had a clause: RESERVE 1 ALTERNATE AREA.  That makes me think that COBOL could double buffer, thus the potential issue of an interrupt being generated.

I am wondering if the programmer manual had instruction advising that overlapped I/O could not be performed, or should not, if the routine was listed on *LOCAL record.

Been way too long.  I am hoping somebody canshed some light on this.

John McKee

[Richard Stofer]

I would have thought that system code overlays (SOCALs) would be created by the core load builder rather than being included as *LOCALs.  It is acceptable to list the IO routines on *LOCAL cards and this would be the only way for assembly language main programs because SOCALs are never created for these types of programs.  Nevertheless, the FLIPR code looks at $IOCT and waits for all IO to complete before performing an overlay.  See line 115 of u5flipr.lst in Brian’s emulator.

 

FL115 MDX  L  $IOCT,0   WAIT OUT ANY PENDING INTER-

FL120 MDX     *-3       *RUPTS BEFORE OVERLAYING

 

As near as I can tell, there is one LOCAL area and one SOCAL area (if necessary).

 

As a result of my very brief perusal of FLIPR and the Monitor guide, it would seem to me that there would be no need for any of the compilers to get involved with IO issues.  They simply create a CALL or LIBF through the transfer vector and the vector is pointing at FLIPR.  The program code doesn’t know if the IO routines are in core and doesn’t need to know.  Nothing happens regarding card IO until FLIPR has loaded the code.  I didn’t check CARD0 but I imagine is increments $IOCT as soon as it starts to read a card.  The interrupt entry point will point back to code in the CARD0 image in the overlay area.

 

If both CARD0 and PRNT3 are *LOCALs, I don’t see how they could both be in core at the same time.  So, I guess I don’t see how overlapped IO could work if both IO routines are either *LOCALs or SOCALs.  I would think a better approach would be to specify one as *LOCAL and let the core load builder create a SOCAL for the other.

 

The people who created the IBM1130 and its code were geniuses.  But at some point, the machine is just too small.  If it just had an MMU...

 

Richard

--
You received this message because you are subscribed to the Google Groups "IBM1130" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibm1130+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John McKee]

How utterly simple.  Annoying, in that I tended to do the same test
that you found in FLIPR.  Been so long ago.

Result is you can attempt to code double buffered card reading, but FLIPR, by necessity, defeats it.  I was making it too complicated.

Related to that same monster RPG program is this:  When run directly via // XEQ, it was slower than if // DUP and *STORECI was usedand then that stored program was run.  No changes except data file had to be moved to FX.  Only wild guess I have is the disk arm movement was lowered.

John McKee