January 22, 2018, 10:24:46 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
   Home   Help Search Login Register  
Pages: 1 ... 8 9 [10]
 on: November 08, 2011, 10:21:30 pm 
Started by RogerHallett - Last post by RogerHallett
Hello all.

Thank you for this forum. Like many others I have found this forum jogging things from my memory. I like the name CORE - although our own memories need refreshing often and after 25, 20, 30, 40 years, this forum is a good way to do it.

NCR was such a diverse company - and when I was with it in the 1970s and 80s was over 65,000 employees. I think the Topics could be widened to include some of the divisions of the company around the world that individuals may relate to better. Such categories as Regions (USDPG, PACIFIC, LAMEA, MEA, Europe); main product groups of Retail, Financial which played such an important part - and of course, R&D Labs, Engineering & Manufacturing facilities and Field Engineering.  There are many others areas of interest ranging from programming a Class 32 to the introduction and operations of Data Centres (Business Outsourcing??). Encryption, chip design, multi-byte addressing for Asian language computing (how DO you manage 30,000+ Chinese characters) - the list is massive. And NCR people did it.

Individuals relate to geographic regions, products, hardware, software - and other people. Anecdotes abound - and seriously fundamental developments and inventions that changed the world of IT should be remembered and celebrated. Yes, I am sure there are many scratchy memories  Angry - no company can avoid the rough bits; but overall, what a stimulating and rewarding experience being associated with NCR  Smiley  - The Cash as it was known in parts. Part of the BUNCH.

What a rich source of talent, skills and memories that make up the very being of who we are. No one who had spent 20 or more of their most productive years could fail to have been profoundly influenced by the company and individuals that we met - this should not be lost.

So please consider the range of topics. It is a bit like a systems analysis job determining the categories in a database - now let's see, topics and users - definitely Many to Many here. 

 on: October 05, 2011, 07:15:44 am 
Started by Aleksandrs Guba - Last post by Aleksandrs Guba
Hello everybody!

I am seeking a photo or other rendering of the National Cash Register Co building in Washington DC, 1219 K St NW.  it was built in 1938, the architect was E Burton Corning.

Best regards,

 on: September 23, 2011, 05:56:38 pm 
Started by n8eyh with OCD-WM42 of Hilse - Last post by n8eyh with OCD-WM42 of Hilse
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
    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,

 on: August 11, 2011, 05:55:09 pm 
Started by Shafe - Last post by courtois

I'm very intersest by the source code of startrek.
It was a super game.


 on: August 11, 2011, 09:13:53 am 
Started by courtois - Last post by wally
Yes, it was base 40, which was used!!

Here you'll find a tool and info for conversion.

 on: August 11, 2011, 08:17:35 am 
Started by CTM99 - Last post by ron
If you post some hex dumps of the tapes I may can help.  I used that method to read some old century series of tape I had.


 on: August 11, 2011, 08:14:02 am 
Started by Shafe - Last post by ron
I have a Cobol version of startrek if any one is interested.


 on: August 11, 2011, 08:08:09 am 
Started by courtois - Last post by ron
Post a hex dump of the directory entries.

Base 32 i have heard of but not base 40


 on: July 13, 2011, 08:07:21 am 
Started by Sam Morgan - Last post by wally
Here you'll find more info.

And this is an interesting site too.


 on: July 13, 2011, 02:02:42 am 
Started by Sam Morgan - Last post by Sam Morgan
I am looking for any information on CPC 1953. That year they gave out CLOCKS that looked like cash registers. My father was branch manager from 1950 to 1972. Any help would be appreciated!
Sam Morgan

Pages: 1 ... 8 9 [10]
Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC
Page created in 0.053 seconds with 14 queries.