IBM 1401 programming: the 1407 inquiry terminal - R15

[@BobPrewett]

I just spotted your series on the 1401 and it caught my interest as a former IBM 1400 series operator and programmer. Back in about 1964-1969 (in Melbourne Australia) we operated a "big brother" IBM 1410 system (taking up most of the floor of a city skyscraper); we upgraded memory a further 16K BITS (BCD) from 48K to 64K BITS (so for it's time it was a big system globally), plus we upgraded from 4 to 6 tape drives (and later added many more) and we added a second read/write arm on the IBM "RAMAC" 1405 disk drive !!!!! We wrote our own operating system to monitor jobs and automate operations processes. To run some of our larger programs we had to load and unload large overlays from the 1405 into memory and branch to the overlay code. The configuration of our system was somewhat unique so if we had a serious problem we'd occasionally phone the IBM Rochester factory for support. *** You asked for feedback on the IBM 1407 - - - * Our system included an IBM 1407 enquiry terminal. You are correct in stating that as a device the IBM 1407 was not very useful. * The only useful operational task of the IBM 1407 was it recorded the time each job started and finished (i.e. extracted from the operating system we wrote) and we recorded any error messages and sometimes occurrences when we needed to stop a job, if a job was re-run, etc. It was a crosscheck for "internal billing" to the various office departments. We would handover the original print-out at end of shift to the Operations Manager and carbon copy retained for auditing. * We operated with 3 shifts around the clock 24x7. For normal operator tasks we had no use for the 1407 printer (except 1 job) but we did check it if if we heard it's chattering burst into action. The "one exception" was an annual job that ran non-stop 24 hours for about 4-5 days doing a full valuation of insurance premiums, life insurance cover, bonus calculations, etc. About every 20 mins the 1407 printed a short reminder message for that job reminding us of the particular tapes to mount next and whether a checkpoint needed to be made so we had somewhere to restart if we had a crash. * An IBM CE (Customer Engineer) was based on site and he would use the system to run weekly diagnostic tests, and if a fault was found he'd shut the system down, fix a problem, replace faulty logic cards, etc. So, a second useful task of the 1407 printer was to print out messages for the CE, record his testing, and the carbon copy was used by our auditors to know it was non-billable time. (Some individual transistors that performed one AND or NAND instruction were the size of a thumb.) Note: Our operators might do similar if we had a crash and needed to interrogate specific areas of memory and dump diagnostic data to analyse problems. * So all the print-outs from the IBM1407 really only provided an audit trail of jobs, time-stamps for billing and traces used for problem solving

[@Lane42]

Considering that the 1407 has the Request key to ask for attention from the processor, I suppose you could code a long running program to look for that key periodically and allow itself to be interrupted in a controlled way so the user could query data stored on disk. There's an IBM film on KZbin demonstrating a similar operation on a RAMAC system. Edit: This is the film: kzbin.info/www/bejne/paq6pJeJZs1giq8

[@n7275]

The document "IBM 1401 System Summary" says: "The IBM 1407 (Figure 35) provides a fast, direct, manually controlled means of communication between the operator and any model of the IBM 1401 Data Processing System. Using an instruction format, the 1407 can control both reading from, and writing into, storage. It permits the 1401 system user to either examine or alter the status of a particular account, record, or instruction stored in the system. This feature is especially useful in a disk-storage oriented 1401 system, where information such as customers' accounts, stock status data, and payroll details are kept categorically. Through the 1407, the operator can request specific data from any disk record, and have the information automatically typed seconds later. This typed copy also serves as a log of information entered into, or received from, a 1401 via the inquiry station." It sounds like it would be useful in cases where you ran the same sort/search program, but with a lot of variability in the input parameters, especially parameters that you might not know ahead of time. It would need to be a big dataset, and it would need to be more valuable to the user to be able to call up data almost instantly, than it would be to keep the 1401 running other jobs while a new search program was punched.

[@huntabadday2663]

YAY A TERMINAL!

[@wacawschiller1369]

Can you maybe share the fantastic /370 caculator? Would serve as a great entrypoint for programming. And maybe some useful books on the subject (titles would suffice)?

[@rolffsonsIBM1401channel]

no problem, I've just uploaded them to the KICKS-RRPC subfolder, rolffson.de/1401/download/KZbin%20Files/R15%201407%20calculator/KICKS-RRPC/ For CICS map file details I've used Doug Lowe's classic "Cics for the Cobol Programmer". For this example, the first book "Part 1: An Introductory Course" suffices. I own the original books, so I don't know whether they are available on the web. For Cobol, any book or website will do. If you need KICKS info, see links in the readme file.

[@wacawschiller1369]

@@rolffsonsIBM1401channel Thank you very much. I need some time to play with TK4 & hercules I've downloaded, but I've been plagued by lack of time and an entry point.

[@rolffsonsIBM1401channel]

caution when trying this at home: the latest simulator version 0.2.15 has a flaw in the 1401 division command ('%') when the result has trailing zeroes

[@huntabadday2663]

Divide by zero issue?

[@rolffsonsIBM1401channel]

@@huntabadday2663 no, it’s just that in 0.2.15 if the result ends in one or more zeros, the sign bits remain with the last non-zero digit, e.g. 1440 / 12 will result in 1B0 instead of 120. will be corrected in 0.2.16