THE CORE MEMORY FORUM
February 26, 2018, 05:07:05 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: One day in the TOX project, I have been and also still I'm in mind.  (Read 17604 times)
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« on: June 25, 2011, 02:59:18 pm »

Hi! All,
I am going to remember the story of the TOX development project as follows:

1. The B1 executive had begun to emerge through the list edited by Mr. Ikuo Akiyama in 1969;
    1.1 A base world under the boundary address '0E00Hex'.
    1.2 Another extended world above the software overlay area 'PSOA, SSOA, TSOA and QSOA'.
    1.3 Studying volume documents of the Century software functional specification.
2. Case studies of the overhead of the task switching by Mr. Ikuo Akiyama in 1970;
    2.1 The B2 executive performance estimation through the object procedure in a base world.
    2.2 The heavy load to save and restore the contents of 63 index registers to the task table.
    2.3 Former prototyping to eliminate too many save & restore operations on the NCR 315 RMC during mid-1960s.
3. RSX-200 executive programmed by Mr. Hiromichi Ishikawa to implement an idea of Mr. Ikuo Akiyama in 1970;
    3.1 Eliminating the necessity to copy 63 index registers by applying special registers that are BAR/LAR.
    3.2 Allocating the partitioned individual memory to each task like the B3 executive handling.
    3.3 Communicating between the different thread.
    3.4 Dispatching without the task management under different transactions through ordering prioritized queue.
4. RSX-300 executive designed by Mr. Hiromichi Ishikawa and Mr. Kazunobu Nezaki and the theory of Mr. Ikuo Akiyama in 1971;
    4.1 The interface architecture between tasks.
    4.2 The B1 executive interface emulation for the batch type application programs.
    4.3 Extending the function of RSX-300 to the RSX-350 executive.
    4.4 Rename RSX-350 to TOX executive.

I will be back soon,
Best regards,
Katsuhiko
« Last Edit: July 16, 2011, 03:03:38 pm by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #1 on: June 27, 2011, 05:17:10 pm »

1. The B1 executive had begun to emerge through the list edited by Mr. Ikuo Akiyama in 1969;
    1.1 A base world under the boundary address '0E00Hex'.

      It was very busy days in 1969.
    I had started my job at NCR Japan in April 1st, 1969. All fresh persons tried to check whether their understanding was right or not,
    through compiling their programs on the NCR Century 100 computer with dual spindles of C-655 Disk unit and an integrated printer
    of C-640-102. As all programs written by the NEAT/3 level-1 language were allocated from the address '0E00Hex', I had a curiosity
    what software was resident there. One day, a hand-made paper that described the machine command binaries and the level-2
    mnemonic instructions line by line was distributed to all of staffs in the division of Sales Support. This paper was prepared by
    Mr. Ikuo Akiyama. The paper introduced and analyzed miracle algorisms of the B1 executive. It's a right paper for us to ensure the
    successful big-burn installations of the NCR Century computer for customers in 1970. Because we the system analyst had to support
    the trouble shooting at the site of installation. There was no time need for his paper to be recognized as our bible. The B1 executive
    configured many valuable functionalities made by the table-driven architecture to issue versatile handling for the application program.
    I had studied the concept of the architecture engineering. I appreciate the project member of the B-series executive development.
    Some day, I would like to meet them in Dayton OH for sharing our NCR software era.
    I heard that NCR Japan put the requirement that has kept the availability for user programs to use 32 index registers of  NCR 315.
    Thus the NCR Century computer had been designed to give us 31 index registers for the table-driven operating software and provide
    32 index registers for user application programs, even though almost computers of other venders like IBM and mosquitoes provided
    less numbers of index registers. Generally, the more index registers for programs used to be the less performance to handle the task
    management in the real-time systems computer, although the application programmer can implement the efficient procedure of programs.
    Concerning the above merits and demerits of index registers, the TOX idea had been incubated by Mr. Ikuo Akiyama, I suppose.
    
Best regards,
Katsuhiko
« Last Edit: July 04, 2011, 04:11:41 pm by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #2 on: June 29, 2011, 05:18:31 pm »

1. The B1 executive had begun to emerge through the list edited by Mr. Ikuo Akiyama in 1969;
    1.2 Another extended world above the software overlay area 'PSOA, SSOA, TSOA and QSOA'.
 
      There were so many software overlay subroutines that provided us, fresh persons, challenging similar to the adventure by
    Huckleberry Finn written by Mark Twain. Firstly, I remember the COT boot to initiate to load the DISK boot from the system disk.
    The COT boot was edited by machine commands into the hollerith card with 80 columns, as follows:
           1)         Branch to $01
           2)$01   Initialize the control word of the system disk unit with pointing an appropriate buffer address, like 2200Hex to 2400Hex.
           3)$02   Issue the INOUT command.
           4)$03   Checking the S2 status reply from the common trunk.
           5)$04   If the replied status indicates 'Ready to I/O, 40Hex', branch to $05 to wait for any S3 replies.
                       If the replied status indicates 'Busy to I/O, 80Hex' or else, issue the WAITI command with displaying
                       the status to the system console and branch to $02 for retry through pressing the COMPUTE button.
           6)$05   Checking the arrival of any S3/S4 status from the disk controller.
           7)         If the S3 status indicates 'Complete I/O, 00Hex', branch to the entry address of the DISK boot.
                       Else, branch to $04.
    The DISK boot was programmed for initialization of the B1 executive after checking any memory failure of the main memory.
    Continuously, the DISK boot used to read a next card or tape for getting the DATE $spec command. If the command is read,
    the DISK boot calls the software overlay into the PSOA (Primary Software Overlay Area) in order to check the DATE specification
    and initialize the computing date, and so on. Thus, the person who understood the operating mechanism of the software overlay
    could predominate the NCR Century operating procedure. Yes, Mr. Kazunobu Nezaki, one of our fresh members had approached
    to analyze the functional procedure of the software overlays by making a program to describe the NEAT/3 level-II mnemonic
    instructions of the software overlay through the reverse-engineering method. I heard that he had found the calendar generator in
    the specific software overlay he told us the originated year to calculate and the '2000 years' problem in the end of 1999.
    He had contributed to advance our skills to analyze the trouble of the NCR Century computer. Then, he had enhanced this program
    to describe the flowchart of the software overlay similar to the NCR Flow-Write function. These trials by himself caused him to be
    invited to the team to develop the TOX, I suppose.
    Through these research experiences to analyze the software overlay mechanism, he had designed almost system tasks of the TOX
    in 1971, to build up the base line to feature the B4-like JCL based flexible operation in future around 1974. The key words of his
    success were 'Compatibility' and 'Emulation', I suppose.

Best regards,
Katsuhiko
    
« Last Edit: July 03, 2011, 02:47:51 pm by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #3 on: July 01, 2011, 02:50:03 pm »

1. The B1 executive had begun to emerge through the list edited by Mr. Ikuo Akiyama in 1969;
    1.3 Studying volume documents of the Century software functional specification.

      I had gotten the culture shock to operate the NCR Century computer comparing with the Fujitsu FACOM computer
    that was the second generation architecture in mid 1960s. The 1st reason why I was surprised was to operate the
    versatile operating functionality on the NCR third generation computer, the Century. The 2nd reason was the volume
    documents of the software functional specification comparing with the NEAT/3 reference manual. The 3rd reason was
    that almost system engineers were very quiet in the office, although they were very good speaker for the customer.
    Because they had to read the volume documents of the just released B-series software to be installed or updated.
    As the fresh software analyst, firstly I had a curiosity of the file handling of the NCR Century operating systems.
    Through the compiling list, I found the IOSET '20Hex' command which specified the file as the NEAT/3 level-2 instruction
    in the inline coding of the OPEN instruction. After tracing the B1 executive through the software interrupt, I noticed that
    the IOSET command routine allocated the appropriate index register (might be X615F ?) to the memory address of the file.
    Then, as I found the existence of the file table around the B1 executive resident algorism, I had started to check the
    volume documents of the Century software functional specification. Yes, there were many keywords and figures regarding
    to the file management subsystem, like the file table, the buffer table, the extremity table, the verify-1 routine and the
    verify-2 routine, etc. Again, I tracked the ISR of the B1 executive to the class-1 subroutine through the verify-1 entry of
    the file table and follow the verify-1 processing into the verify-2 entry. Finally the verify-2 processing called the software
    overlay algorism. I had gotten the help by the structure chart to describe the relation between software overlay modules.
    The structure chart description had been very convenient and helpful to trace the linkage. Recently I heard that the
    structure chart technology had been imported into the software design when the software development team in the IBM
    System/360 wished to resolve the trouble of the complex software modularity.
    And also the NCR microfiche filing and scanning system was very useful for me to read the software volume documents
    in the microfiche rapidly like the internet exploring tools. We the fresh persons in the division of Sales Support, NCR Japan,
    were trying to select the gear position with stepping on the accelerator like car racing, in order to satisfy our curious target
    of the NCR Century operating system in 1969-1970.

Best regards,
Katsuhiko
« Last Edit: July 03, 2011, 02:56:31 pm by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
uglytuna
Newbie
*
Posts: 29


« Reply #4 on: July 01, 2011, 10:34:49 pm »

Your memory is outstanding Katsuhiko.  Reading your history narative brings back a flood of memories for me.

I was hired in 1964 and spent the '60s as a hardware serviceman for the 315.  Then, in February of 1970 I accepted a position in Systems Services in Dayton to support the B3 Executive.  At that time I had NO Century training whatsoever, not in hardware or software.  So like you, I was "fresh."  I spent the first few months reading the same documentation that you described, spent a whole LOT of time in the computer room observing first hand what I was reading, and spent many, many hours in question and answer sessions with my peers.

I look forward to reading the rest of your narative.

Warm regards,

Herb Fish
Logged
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #5 on: July 02, 2011, 04:26:30 am »

Hi! Herb and All,

  Good evening and good morning from Ikoma city, Nara, Japan.

I am very happy to have shared our spiritual energies to work for the NCR total systems during 1970s mainly.
Yes, we could not have a specific teacher. Because all of members in the devision had been trainees over the year old.
Only the machine and functional documents replyed to our desires and misunderstanding.
Every things of programming artifacts, troubled computers and peers' reviewing were supportable for us.
It looks like the story, 'Stand-by-Me' and the music.

Have a nice weekend,
Katsuhiko
Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #6 on: July 02, 2011, 03:05:02 pm »

2. Case studies of the overhead of the task switching by Mr. Ikuo Akiyama in 1970;
    2.1 The B2 executive performance estimation through the object procedure in a base world.

      Why the B2 executive was not helpful for the transaction processing? This asking was my first theme to get the customer satisfaction.
    The real problem was originated by the number of index registers and the frequent interrupt of communication texts for the terminal.
    1) The number of index registers:
          The NCR Century computer had 63 index registers which supported 32 index registers for the application programming and
          manipulated 31 index registers for the operating software handling. If we focus to the example in other venders' computers,
          the IBM System/360 had 16 index registers and the UNIVAC 1107 had only 15 index registers. I suppose that the architecture
          analysts of NCR computer R&D would make the marketing strategy into the small computer business with 63 index registers.
          Because the more index registers would reduce heavy push/ pop handlings to access the main memory, if the computer worked
          for a single job under the B1 executive. Really, the NCR Century 100 computer had performed higher cost/ performance advantage
          in the small computing market. On the other hand, the multi-programming processing of the NCR Century 200 computer looked
          so power-less machine against the other vender computer around 1970.
          Yes, you know that the B2 executive on the NCR Century 200 had to work 63 index register save/restore operation when the task
          switching procedure had be done and the memory read/ write load might be increased in 4 times against the IBM System 360.
          I suspect that all of top level management of NCR might had known this fact and of course they wished to approach the different way
          from the IBM elephant strategy to the total serviceability business marketing into the small office customers. However, this decision
          making caused us to be in difficult sales approaches to the larger customer office.
    2) The frequent interrupt for communicating with terminals:
          I remember the terminal devices strategy of NCR during late 1960s. It was completely based on the machinery unit itself, although
          the control line interface was the electronics circuits, like the Tellers machine C-42 with C-428 terminal interface unit and C-438
          controller. These are similar architectures to the console unit of the NCR Century 100/200 that was the ASR-33-like terminal imported
          from the Teletype Corp. As these terminal used to have a small sized buffer for communicating with the host computer, the host computer
          had to accept the frequent interrupt that caused the host to handle the heavy load of processing with terminals. However, NCR R&D
          had released several vocational terminals during 1970-1972. For example, the NCR C-280 was for the retail market and the NCR C-270
          was for the financial market. In April 1972, I had gotten a nice chance to use the early production model of C-270 instead of C-42 tellers
          machine. The C-270 tellers terminal was an intelligent micro-computer based unit that included the programmable firmware. As this early
          production model has been very sensitive to heat in the running condition, I assume that the micro-computer would be Intel 4004 micro
          controller. Because the Intel had just released the 4004 chip in late 1971 and it was very difficult to manage the heat-sink on the PCB.
          The strong reason is that, through NCR E&M Oiso, NCR Dayton had contracted with the Busi-Com Japan that had invented and developed
          the micro computer 4004 family with the Intel during late 1960s. To tell the truth, I am not sure which organization has supplied for
          C-270, the Intel or the NCR micro-electronics division in Miamisburg.
          Well, on the view of the designer of the OCD (Online Communication Driver) software, the frequent interrupt for the OCD used to make
          heavy load to save / unsave the associated index registers, approximately 40 % CPU utilizing during the peak time in the online job of
          NCR Century 200 computer. Because the OCD verify routine was located as one of the verify-1 software.

    Thus, the B2 executive based system would not be convenient for the transaction processing that needs to configure multi-data segments in
    the both texts of incoming and outgoing, you could imagine so easily.

Best regards,
Katsuhiko
« Last Edit: July 12, 2011, 02:47:38 pm by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
uglytuna
Newbie
*
Posts: 29


« Reply #7 on: July 06, 2011, 05:35:24 am »

Good evening and good morning to you Katsuhiko from the wine country of northern California.

How right you are!  In 1972 I was sent to the United Bank of Denver to perform a Dynaprobe study of their large B2 on-line partition running under B3 on a Century 200.  The processor seemed to be maxed out and the customer demanded answers as to why.  The objective was to determine the efficiency of their big teller application, the B2 executive, and the B3 operating system while under a heavy transaction load.

I connected the Dynaprobe to the L (memory address) registers and recorded their addresses over several days.  And guess what, the heaviest usage of computer time by far was the B2 OCD!  Needless to say Dayton R&D was shocked upon reading my analysis report.  There was no denying the hard evidence that I presented, and the B2 developers instigated a major tuning effort for the OCD.

Keep up the good work,

Herb
Logged
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #8 on: July 06, 2011, 09:51:24 am »

Dear sir, Herb,

  Good evening to you.
Let me take a short break into the OCD concerning.

  As you had done through the Dynaprobe tester, we the software architects and sytem analysts had mesured the performance of
the NCR Century 200, 300 and 350 in Japan, too. It was the best method to analyze the procedure timing between each software,
like the logic analyzer for the digital circuit or the spectrum analyzer for the analog cirduit.
  In mid 1970, I had started to modify the original OCD by Hilcy (I am not sure whether his name is correct or not, I am very sorry.
Because I respect his design theory), in order to expand the OCD availability to another OEM terminals in Japan, coached by
Mr. Naohisa Taga who had been a member of the COFS-I (Century On-line Financial System) project of Mr. David Chen in Dayton OH,
during late 1960s. I could include the Hilcy OCDWM42 source code by specifying the USEIF conditional SPUR instruction card for the
NEAT/3 compiler. This OCD had been designed by the Table-driven method with the linkage architecture like the menu of the C-270
operational windows. I suspect that this architecture would be very convenient for the tiny NCR Century 100 computer with 32 Kbytes
memory system controlled by the S2 executive, reduced version of the B2. Because the COFS-I project was to target for the user of
NCR Century 100 system with the C-621-101 multiplexer unit.
 His design was based on the structure of configuring the state transferring table to store the terminal operational mode and managed
the inter-mode handling like transferring from the input accept mode to the acknowledge send mode, and so on. Each mode-based module
was independent of other modules. It was a nice way to be easy to maintain the modular software to expand the functionality of the OCD.
However, I suppose, as his design was prior to the higher commonality of modules with dividing into the primitive function, the rate to go
through the table handler module bacame to increase and the table handler mudule consumed the CPU power too much.
 Thus, the enhanced version of the OCD had been released in early 1972, as the OCD for C-270 terminal which had not included any table-
driven mudules. I impressed to be easy to read and understand the OCD program procedure. I found this enhanced OCD at the NCR Dayton
sales branch office in April 1972, when I visited firstly Dayton with our leader, Mr. Jimmy Hagishima, in order to introduce the availability of
the C-270 tellers terminal to Japanese major city banking customer. I was very surprised of the Building 10 of NCR WHQ with the vintage
elevators and the mechanical production lines of the factory connected by the tunnels pipe between buildings of the WHQ. The scale of
the property of NCR WHQ was quite different from the small factory of E&M Oiso Japan, although every things had been gone.

Best regards,
Katsuhiko
« Last Edit: July 06, 2011, 09:55:39 am by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
uglytuna
Newbie
*
Posts: 29


« Reply #9 on: July 06, 2011, 11:40:17 pm »

Greetings Katsuhiko,

The tunnels between the buildings at the NCR factory complex were truly amazing.  In the mid-sixties I received 340 printer training in the basement of building 26 at the corner of Patterson and K street.  At the time I rented an apartment off Brown Street not far from the NCR Credit Union.  It was winter and bitter cold outside.  I would enter the building across the street from the Credit Union and take the tunnels all the way across the complex coming out at building 26, staying nice and warm for the whole trip.  These two buildings were diagonally opposite from each other and as far as you could go and still be on NCR property.  It was always an adventure to make that trip each morning and then return each evening.  We would also take the tunnels to the auditorium of building 10 to watch 45 minutes of a movie during our lunch hour every day.  A whistle would blow and the screen would go black telling us it was time to go back to work.  Fond memories.

I also had the opportunity to work with David Chen.  He was one very smart person and exciting to be around.  While working at the Los Angeles Sales Office in 1976 we wrote a food accounting system for a restaurant chain called Hamburger Hamlets.  It was written in IMOS Cobol and ran on an NCR-8200.  David wrote an on-line program that ran on the 8200 to poll the Class 250 ECRs used at the restaurants.  Our applications then processed the polled data telling the customer what was sold and what ingredients needed to be ordered for each restaurant.  I remember the 250 data was encoded in what David called “Ass Backwards Binary.”  The bits in each bite were reversed and we had to write a front-end decode routine to translate the ass backwards binary data into standard binary data.  As I said, working with David was a pleasure that I’ll never forget.

Best regards,

Herb
Logged
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #10 on: July 08, 2011, 03:38:05 am »

Dear my elder engineer, Herb,

  Good evening to you.
When I had been there in 1972, I remember your mentioned apartment house. It was the third floored building near the building 23 that was a factory for the financial terminal product lines, I suspect. Because the apartment was a modern house with a wall painted by very beautiful white color. My friend who was a representative of the liaison office for NCR Japan had been living there. I was very surprised of the light blue sky during our short dinner party at the rooftop of the apartment. Because the sunset time is around 7PM in April, Japan. we the project member were staying in the motel Capri (now, Budget Inn) near the Hills and Dales shopping store in which there had been the financial terminal project at the B1 floor. I used to walk along the South Dixie Drive and find rabbits there during my walk to the Dayton sales branch office (now, Humana) through the Kettering Boulevard. The problem was a shop of Kentucky fried chicken. Because I became not to be good at the smell after eating at noons and evenings during several weeks when I developed our demonstration program for Century 200 and C-270 transaction procedure, even though I had liked very much Kentucky fried chicken in Tokyo. Hi, hi!) Now, I like it again. During my walk, I found a number plate of car that was 'W8HHX', it means Ham Radio Call sign, as a scrap at the corner Used-car shop in the intersection of the Hills and Dales. I am keeping the plate now in my ham hobby room. It's my core memory in 1972.

I will be back soon to the TOX story again,
Best regards,
Katsuhiko
« Last Edit: July 08, 2011, 11:48:52 am by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #11 on: July 12, 2011, 12:45:49 am »

2. Case studies of the overhead of the task switching by Mr. Ikuo Akiyama in 1970;
    2.2 The heavy load to save and restore the contents of 63 index registers to the task table.

      In the NCR Century 200 computer, the data bus was 16 bits wide. Each interrupt would cause the verify-1 routine to save and restore the
    32 index registers associated to the ISR routine basically for 2 x (31 x 2 x 760 nanoseconds) time consumption which is equal to the load of
    95 microseconds. If the verify-1 routine executes 1 K steps for checking the result of I/O, the verify-1 routine would consume 300 x 2
    microseconds for each interrupt which means the load of 600 microseconds approximately.
      Well, through my NCR experience to plan, will you please let’s try to estimate the load of the typical transaction processing in the NCR
    Century 200 computer?
    1) Premise
        a. The application is a banking online system in which the NCR Century 200 computer serves the transaction processing for
           the saving account services.
        b. The host computer has several NCR Class 655 twin spindle disk units, several NCR Class 635 magnetic tape units and NCR
           Class 621-103 communication multiplexer unit which includes many NCR Class 692-200 asynchronous communication adapters in
           the auxiliary bays.
        c. The branch offices are configured by NCR Class 42 teller machines through the NCR Class 428 terminal adapter and the NCR
           Class 438 terminal controller which is connected by the asynchronous communication line with two wires of the 1200 bps
           transfer rate by the polling and selecting communication protocol.
        d. The incoming transaction includes two segments and each incoming segments are served by four interrupt service handlings
           through the BCT (Between Command Testing) feature in the central processor unit.
        e. The outgoing transaction includes four segments and each outgoing segments are served by five interrupt service handlings.
        f. The system tasks are configured by three kinds of tasks which are the magnetic tape input task, the magnetic tape output task
           and the disk I/O task.
        g. The application tasks are configured by three kinds of tasks, like the normalizing task for incoming transactions, the common
           application for deploying the transaction data and the account proper task for handling the requested transaction.
    2) Estimation
        a. The number of ISR for a transaction would be 36 issues which include 8 for incoming segments, 20 for outgoing segments,
           2 for incoming logs to two magnetic tape reels, 2 for retrieving the customer information file (CIF) record, 2 for updating the
           CIF record and 2 for outgoing logs to two magnetic tape reels.
        b. The average ISR computing process would be 300 instruction steps in minimum with 2 microsecond execution of instruction
           in average that means 600 microseconds. Each ISR procedure would call a system call macro of the B2 executive that needs
           another 600 microseconds. Totally each ISR routine utilizes 1200 microseconds.
        c. The load of ISR computing process for a transaction would consume 36 x 1200 microseconds in itself and needs another
           36 x 95 microseconds in each handling for saving & restoring of 31 index registers. Totally the ISR computing process consumes
           47 milliseconds per each transaction.
        d. On the other hand, during a transaction process the number of dispatching tasks by the B2 executive would be 24 totally, like
           1 for the normalizing task, 4 for the MT output tasks to log the incoming transaction, 3 for the common application task,
           2 for the disk I/O task to retrieve the CIF record, 10 for the account proper task to update the CIF with logging the
           completed transaction and 4 for the MT output tasks to log the outgoing transaction.
        e. The task switching for a transaction process would configures the procedure to save and restore the index registers around
           24 x {2 x (63 x 2 x 760)} nanoseconds and the B2 executive process with (24 x 150) instructions sequence of 2 microsecond
           execution in average. Totally the load of the task switching process would be 12 milliseconds per transaction.
        f. The average application computing process would be 20 K instruction steps per transaction in minimum with 2 microsecond
           execution of instruction in average that means 40 milliseconds per transaction.
        g. Each task would call 4 system call macros of the B2 executive that need 4 x 600 microseconds and 4 x 2 x 95 microseconds for
           saving & restoring of 31 index registers. Totally the application task computing process consumes 24 x 3160 microseconds that
           means 76 milliseconds per transaction.
        h. Thus, the total computing process would consume (47 + 12 + 40 + 76) milliseconds that mean 175 milliseconds per transaction.
         i. Then, the NCR Century 200 computer system can provide 4 transaction services per seconds under 70 percent utilizing of CPU
           in maximum.
    3) Analysis
        Although the above estimation might not be accurate because I have considered the best case of procedure, I used to analyze
        the following overhead.
        a. The overhead to save and restore index registers is 16 percent in the transaction processing.
        b. The overhead to segmentalize a transaction message between the host and the terminal is 20 percent in the transaction processing.
    4) Approach to enhance
        NCR Japan had made decision to take the way into the following approach, through tough negotiation with NCR Dayton during early
        1970s.
        a. Eliminating the overhead to save and restore index registers in the B2 executive by developing NCR TOX (Transaction Oriented
           Executive).
        b. Eliminating the overhead to segmentalize a transaction message in the host computer by developing NCR Class 272 tellers
           terminal with NCR Class 721.
        Although I was a fresh person to study the software procedure, several elder engineers seemed to be very busy to study and test
        the performance of the NCR Century 200 through the benchmark on the B1 executive and the B2 executive with multi-programming.
        The resposible key person of Sales Support Division in NCR Japan had been very busy to make a focast of the performance by the
        TOX development and the business proposal, I suppose. I appreciate the artifact of our super boss through his trial to get a win.

Best regards,
Katsuhiko
« Last Edit: July 12, 2011, 01:32:25 am by n8eyh with OCD-WM42 of Hilcy » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
n8eyh with OCD-WM42 of Hilse
Jr. Member
**
Posts: 60


WWW
« Reply #12 on: September 23, 2011, 05:56:38 pm »

2. Case studies of the overhead of the task switching by Mr. Ikuo Akiyama in 1970;
    2.3 Former prototyping to eliminate too many save & restore operations on the NCR 315 RMC during late 1960s.

      Although I believe that Mr. Ikuo Akiyama is a right person to write this section, will you please, however, let me study his idea because
    I can not confirm his original document today. Thus, remembering his lecture and suggestion for us, I would like to deduce his trial to
    inspect the feasibility of ideas for improving the operational efficiency of the transaction processing on the NCR315 RMC.
      Mr. Ikuo Akiyama might have been focusing the reason why the task management makes the task switching so often. I suspect that
    there are several reasons, as following examples:
           i. The vacancy of resources for processing income transactions (request to be received, storage for transactions, or
              time to be expired).
           ii. The preemption for the higher priority task during the run of a lower priority task.
    I assume that he would test two features that are (1) the bundling of queues for incoming transactions and (2) the sending of job
    between tasks.
    a. Bundling of queues for incoming transactions.
       Mr. Ikuo Akiyama might focus to the benefit to manage the redundancy of the resource ‘Queue’ for the incoming transaction, as the
      operating system could not manage together independent resources like the DSA (Dynamic Storage Area) or the trigger of an expired
      time through separated queues. But, the old computer architecture did not accept such an idea to implement the multiple incoming
      queues structure for each task. Because such ideas used to require the manipulation of many index registers and consume much
      computing power.
       As you know well, the VRX operating system had released the feature of the Message Control System (MCS) to build the structure of
      the multi-queues on the Criterion computer system in late 1970s. The prototype of the MCS feature had been already studied by Mr.
      Ikuo Akiyama on the NCR 315 RMC originally during late 1960s. Although I have no exact information regarding the conceptual trigger for
      the VRX implementing the MCS, the rapid ITB (Internal Transferring Bus subsystem) architecture of Criterion would have caused the VRX
      design team easily to implement an idea to bundle queues for each task processing like the TOX development team had done in early
      1970s.
    b. Sending of job between tasks.
       Generally, the program has to be based on the scenario of the general processing purpose with initiating the extremity procedure for
      files to access, initializing data structures in the data section before getting any records in an input file and setting up the appropriate
      information into the proper data fields in each time getting a record. On the other hand, the transaction process has to be based on the
      scenario of the object oriented program that manages the life cycle of the processing independently by itself and does not require any
      premises like an input data structure that the receiving program can accept.
       Mr. Ikuo Akiyama might focus to the benefit to reduce any processing overheads of initialization and setup for the program. He made an
      idea to implement the task interface architecture like calling interface between subroutine modules that have their own index registers
      and data resources in each module. That is, the task interface has to be based on the connection of the control sequence. This idea is
      quite different from the data transfer interface or the event transfer interface between tasks. When I got his presentation of this idea in
      July, 1970, I was very surprised. Because I had believed that the task had to be independent from another task processing with the
      closed loop algorism internally. But his idea introduced the hopping procedure between tasks and the completed reentrant coding
      technology. I felt something new in the software architecture. This idea caused me to become happy to study the necessity of break-
      through as an engineer.

Best regards,
Katsuhiko
« Last Edit: September 23, 2011, 06:02:54 pm by n8eyh with OCD-WM42 of Hilse » Logged

Katsuhiko Hirai
Fan of the Century architecture under 63 index registers.
JJW
Newbie
*
Posts: 7


« Reply #13 on: October 31, 2016, 06:32:05 pm »

At NCR in Hawthorne CA, I was responsible for providing support for the 321 communications controller in the 315 On-Line Banking Executive. Then later I designed and built the B2 operating system for the NCR Century and was also involved in hardware designs for multi-processor systems. Because of that I had several chances to interact with the NCR Japan team regarding Sumitomo Bank and especially with Akiyama-san. In some ways we were friendly rivals with his focus being on Sumitomo Bank and mine on general purpose operating system capabilities.

There is no doubt that the numerous indexing registers provided a performance challenge for any multi-tasking system. The choices wer basically to 1. save and restore all of them, 2. save and restore only some and limit applications to those. or 3. to share the registers among all tasks and require programmers to use only certain registers in certain tasks. In providing a general purpose system I chose #1 (the least performance effective). Akiyama-san with his focus on Sumitomo Bank and with a known programming staff capable of managing their register use chose #2 (and I believe some use of #3 with the registers which were not saved and restored.

With the introduction of the Centurion computers and virtual memeory this problem could be resolved by the virtual memory system since the indexing "registers" were actually in the first 256  bytes of the program memory. That allowed register switches to be performed simply by changing the first virtual memory page.
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC
Page created in 0.069 seconds with 17 queries.