THE CORE MEMORY FORUM
August 20, 2018, 01:27:07 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 2 3 [4] 5 6 ... 10
 31 
 on: October 31, 2016, 06:32:05 pm 
Started by n8eyh with OCD-WM42 of Hilse - Last post by JJW
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.

 32 
 on: October 31, 2016, 06:14:48 pm 
Started by fred - Last post by JJW
I'm sorry I didn't discover this web site much earlier. I had done some searches for old NCR information but for some reason this site never popped up until now. An introduction:

I worked at the NCR Electronics Division in Hawthorn, CA and later in Rancho Bernardo, CA from 1964 until 1984 where the 315, Century and Centurion computers were designed and built. I was a programmer on several projects. Most notably, I designed and built the B2 operating system (with one other programmer). worked closely with the designers of the B3 and B4 operating systems. I was also the chief technical architect for the VRX operating system.

-- JJ Whelan

 33 
 on: October 08, 2016, 07:58:56 pm 
Started by fred - Last post by heikobuss
Hello Fred,

>> It seems like all the messages on the forum are quite old.

You are right - unfortunately .....

>> Is everybody dying off or what?

No, not all - I'm still alive - Thank God!

I was a Field Engineer for the Century series in Germany.

After 5 years of work I switched to the other side of the desk - from Hard- to Software and from a NCR-employee to a NCR-customer-employee.

There I hat to write a whole lot of software - mostly in NEAT/3 and NEAT/VS.

And you are right - in the pre-Terminal-ages the changes to all the files where made in sequential acces - via the "Father-Son-technique" (I hope, this is the correct english word for that).

Of course I wrote my own indexed-access-routines - I guess, everybody does this. But with the restricted space on a 655-Disk (4,5 MB!) one had not too much of possibilities!

Then came the Terminal-Dialog-Ages. In germany whe had  from NCR Augsburg a software package named "TECOS" - you could write dialog programs with "Send/Reveice"-Commands. And a package named "MIDAS" - this was a small clone of the well known Database-Package "TOTAL" from Cincom Systems. With "MIDAS" you had a set of random commands to retrieve/change/insert data - very comfortable for that times.

Later on on the Criterion Mainframe there were indexed acces via the "CAM"-Method of access.

Good memories - yes, times have changed ....


All the best
Heiko

 34 
 on: October 06, 2016, 01:18:21 am 
Started by fred - Last post by fred
Is anybody listening in here or contributing? It seems like all the messages on the forum are quite old. Is everybody dying off or what?

I just found the site but had no way to get in on it because registration had been locked. An email to the webmaster gave me access.

My interest to look came about because my daughter asked me to write a little history of our business. I was one of the founders of SBUG which stood for Service Bureau Users Group where all of us used NCR computers. Of course I threw just about everything out from those days in the early 70s but she wanted a picture of our mainframe. Who keeps such things. Luckily this site has quite a bit of memorabilia available thanks to people who saved stuff.

I have one question that has been bugging me. When I was a Sr. Analyst I had several customer sites under my wing. Most folks were using or trying to use existing NCR software packages but my main client expected me to write most of their software custom and being that NCR included about a year of support, I was the lucky guy to do it. Problem was there was no way to get to data except for random and sequential access. I had to write my own indexed sequential access system and always wondered how did other programmers handle access. Any thoughts?

Fred
 

 35 
 on: September 05, 2016, 07:54:57 pm 
Started by lapham - Last post by lapham
I am new here so I hope you will forgive me if I'm not in the right directory Grin
I started with NCR in 1962 in Chicago. I was an service apprentice working on the 390 systems. Most of my training as an apprentice was at Spiegel's where they had 5 390's - Tracer numbers 1, 2, and 5 were 3 of them. I graduated from CTEC and spent the next 12 years servicing 390 and 500 systems in Chicago. We had about 50 systems and 6 servicemen. I remember a lot more about the 390 and 500 than I really want to Grin
In 1976 I went to Cambridge as a specialist on the Retail Systems - 725, 8250, 8270 and 9020 just to name a few. This group later became the Retail Global Support Center in Atlanta in 1990. I retired from there in 2000 but I am still friends with many of my coworkers. Over the 39 years with NCR I also serviced many other machines - too numerous to mention like 315, CRAM, on-line communications on and on.
When I figure out how to post pictures I will. I tried to attach a picture of the Chicago EDP office and Data Center as a test.
Any questions about 390 or 500 fire away. Or 725, 8250, 8270, 9020.
Richard Lapham

 36 
 on: September 01, 2016, 11:39:00 am 
Started by Shafe - Last post by Grondak
So Zedy, can you tell me anything else about them like who wrote them (someone @ NCR, or a user)? I know the source code might be impossible to find anymore, if it exists at all, but did you ever see the source code for those particular games?

I wrote Star Trek when I worked for NCR in Adelaide, South Australia, in the 1970s.  I have no idea what happened to the source code, but I believe it's still floating around somewhere.

The way I wrote it was by taking an inferior text-based version that ran on Data General and rewrote it all in COBOL on the 8250 we had in our office.  (After I left NCR to work for Wang in 1979, I took the code with me and modified it to run on Wang VS COBOL.)

 37 
 on: November 26, 2015, 08:08:40 pm 
Started by Somebody - Last post by donowens
My memory indeed failed me again! The 308 I mentioned before is actually a 310!

 38 
 on: November 26, 2015, 05:35:09 pm 
Started by Somebody - Last post by donowens
I started working on the 315 as an apprentice in Indianapolis. In January, I was sent to service the 315 at the Indiana National Bank, reporting to Frank Murphy. He had me working on the CRAM units from day one, but I also assisted with service on the rest of the system before long. In addition to the Indiana National, we also had Merchants National Bank. Between the two site, there were seven Cram units, all my responsibility to service.

In September, I was sent to Dayton for training on the 315, finishing in May 1964. During this time, I received a transfer offer as a Technical Writer for the 353 family and was sent to Hawthorne. It was there I met Jim Taylor, better known to this forum as JimT. I wrote the service and parts manuals for the 353-2 unit. I also wrote manuals for the 420-2.

A side note about the 315 photos in the Gallery - the fourth picture from the end is not related to the 315, it is a 308 (if my memory is right), which NCR oem'ed from either 3M or CDC. It was an octal base machine rather than hexadecimal, and only had paper tape, at least the one I worked on. For some reason, I remember I received a routine to be used for debug and had to key the whole thing in as octal characters - big pain.

 39 
 on: November 17, 2015, 03:12:49 pm 
Started by Chris - Last post by Russ_Bartlett
  The reply to aptitude question #7  is incorrect.  Let me break this question down:
1.   None of the boxes contain numbers therefore the contents are irrelevant to a point however,  content of box 6 being the exception!
2.   Box 7 is a distraction.
 
3.   The process steps are about iteration - 
a.   At step number 5 the box number is increased by 1 (stop after 4 iterations)
b.   At step 6 the box number is decreased by 1 (stop after 3 iterations)
4.   The decision test to stop iterations is at step 3 therefore we can immediately jump to this step with the pointer for box number set at 5 (we have done 4 iterations up and 3 down to 9)
5.   So the question now is the second box number mentioned in instruction 2 (now 5) less than the number in box 6.  If we make the number in box 6 = a value of 5 we   will go to “END” which is exactly what we want to do as we don’t want another iteration!
6.   Box 6 could in fact contain any value greater than 5 to cause the process to terminate but as the question states “in order to accomplish this no more no less”  I’m saying 5 is the correct answer.

 40 
 on: October 11, 2015, 01:10:22 am 
Started by heikobuss - Last post by heikobuss
Hello,

a collegue from NCR Hamburg (Germany) had to fix a funny fault on a Century-100.

Everytime when a Program selects the Magtape, the ME-Light (Memory-Error) on the Console turns on, and the System stops.

You remember: When executing an INOUT-Command, the A-Adress of the Command points to the PAF-Characters needed.

The Trunk/IO-Logic then sends all the needed PAF-Characters (Trunk/Position, Function, etc.) to the Peripheral. When all necessary Characters are send, the Peripheral (or, in this case, the Magtape-Controller) raises the "End-of-Control-Information"-Line on the trunk, and the IO-Function starts.

But the Controller failed to raise this line, and so many PAF-Characters where send to the Controller until the "end of memory" in the processor was reached, and the "LGM"-Term ("L-Register greater memory") was raised, and the ME-Light on the Console  turns on ....

The reason was a faulty NCR80-Chip in the Magtape-Controller. My collegue hat to replace this chip, and everybody was happy .....

Fascinating memorys - that was the time you had to know what to do!

All the best
Heiko

Pages: 1 2 3 [4] 5 6 ... 10
Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC
Page created in 0.054 seconds with 14 queries.