Interconnect Controller micro-programmed to H1-OS
I always thought my peripherals have to be smart but not based on microcontroller (LSI) but in discrete logic such as Heritage / 1. There conceived, then, the idea of \u200b\u200bbuilding a "generic controller" based on simple FSM whose state tables would be stored in an array of diodes. Today
finally got ready to develop the idea and, surprisingly, the development led me to understand the meaning of "stored program machine." I did not get to a particular design but my driver, a satisfying intimate with the concept, which try to explain in what follows.
A MACHINE WITH PROGRAM STORED
The first time I read a computer manual legendary something like this: "This is a sequential, stored-program, digital parallel computer", I wondered if it is possible to construct a computer that is not all that, because a parallel sequential machine stored-program is the de facto structure of every computer from the time before my birth.
was not always so. The first-generation computers (1940s and early 50s) were serious, that is, the data inside is processed bit by bit. Ramington and Rand and IBM had established their respective markets (with this type of equipment) where he built a CRAY supercomputer whose power was amazing, among other factors, the fact of processing data in parallel ... as we do today.
What's "stored program", however, was established early. Even before the ENIAC manufactured in the United States the Colossus in England, Alan Turing had already captured the concept in theory and had introduced in his model of "universal machine." Later, Von Neuman EDVAC built its U.S. based on this principle. However, by that same date were built machines where the program and relapse data in separate reports, the most notable one that IBM built for Univercidad Harvard in 1944, based on relays. Today often speak of "Von Neuman" versus "Harvard" to refer to a given computer architecture. The first has dominated for decades but in this century we are breaking that pattern to move quickly toward concurrent processing.
VISTA COMPUTER AS A FINITE STATE MACHINE (FSM)
Imagine a Finite State Machine (FSM) whose state table is stored in a memory. The technology used (RAM, diode array, etc.) is not important now, the important thing is to imagine how it is structured the data it contains and how the WSF will use it.
The purpose of the machine is to use the WSF to assemble sequences. Each memory location is a step sequence. For each location, each bit represents an output signal. Most departures are "control signals" of the machine a few output bits representing the next state of the FSM, ie, the "address" the next step.
This arrangement would not get much further if there was no need to make decisions based on input data. What makes a computer, anyway? Running sequences ... and nothing else! The greatness of such sequences are not fixed but take different paths depending on the input data and intermediate results. And great is the fact that much of these "facts" are used to route the FSM, ie, are "instructions", the program itself: Software. That
is precisely the essence of the concept of "program track history": the program itself is an input element, as well as data, and based on them, it generates one or the other sequence, hence the need for storage with data in the same medium.
Another key concept in which I had not noticed until today: the decision making process (the next state of FSM) also depends Term Of established much earlier by intermediate results. This is the case of a negative number after a short, for example. In computers, this is usually noted in the "flag register (Register Flags.)
back to my FSM, let's split the state table (For better organization) as "sub-sequences" of 4 steps each. This has implications for addressing the table: the N bits of address, will feed the 2 less significant from a 2-bit counter whose input is fed, in turn, by a pulse train (clock). The N-2 bits used to address other subsequences.
I said before, for each location, a few bits of output represent the "next step" in the sequence. Say you are M bits, and connect them to address not only subsequences sequences, so that our FSM can contain up to 2 ^ M subsequences.
Returning to the comparison of my FSM with a computer, the "subsequences" can be seen as "instructions." The difference is that these are not in the same memory where data recycle but in separate memory, in a computer "microprogrammed" (as is common from IBM/360 to this day), this would be "micro-code" the machine and its memory call "micro-code storage."
But that's not all, in fact, the machine we have so far still does not work because it is not able to make decisions based on the input data (real data who reside in main memory).
For this to happen, we just have to add the outputs of which involved Flags Register in addressing the state table. We have already taken the first two bits for the subsequence, now take the following 4 and food from the Flags Register (assuming this is 4 bits).
The machine will, of course, records, and means for processing data (eg an ALU). The Flags tickets come from these circuits, ie, the flags are set or removed depending on intermediate results, as intended. MY PROPOSAL
My proposal consite in that with such little means, you can build a computing machine where the software resides "as data" in the same memory where data true, but as states of the FSM table in separate memory. In other words, the "software" of the machine would direct its "micro-code."
A machine that's capable of making decisions based on interim results due to the Flags Register and can, in principle, perform tasks as complicated as possible to "program" in a state table that is, in turn, likely to be built.
My intention, however, is not theoretical but practical. The work to be done by this machine is assumed to be simple enough to be programmed directly as "micro-code."
intend to take this technique to provide some (limited) Device Controllers intelegencia the Heritage / 1. These would be printed circuit boards housed in the control unit of each peripheral and mission consitiría to read / write a buffer from the media in question (tape, serial port, printer, etc.) as well as negotiate the attention of the CPU in accordance with interrupt architecture Heritage / 1. Being
Sunday, December 13, 2009
Wednesday, December 9, 2009
Does Structure Chloroplast Enable
Peripherals: Multi-Use Storage
Heritage / 1 a sequential machine, operating system (H1-OS, which OS will simply call in this article) will implement multiprocessing with "slices of time", as shown in the figure below.
In the figure, P1 and P2 are two processes "Multiprocessor", ie, multiplexed in time in such a way that P1 and P2 are simultaneously in the eyes of the user, OS is the operating system or, more specifically, a routine responsible for producing the switching between processes. Each process runs continuously until the arrival of a TIMER interrupt (every 1 ms) which passes control to the OS.
We have seen in previous articles that a program can only exist as such in Storage, when loaded into memory, it creates an "instance" consists of two areas: one for code and other data for your area (Stack). We also saw that same program can be multi-instantiated, in which case it keeps in memory a single copy the code, but Stacks are created separately, one for each instance. By "process" we mean just that: an instance of a given program, in particular, P1 and P2 may be instances of the same program.
STATE OF EXECUTION
When a process is interrupted (the Timer), its "status of implementation" must be stored somewhere so that when the OS returns control, it can continue the exact ejecutación point where you left off.
At Heritage / 1, the interrupt mechanism itself provides the means to save the "state of execution." Indeed, when an interrupt occurs, the Program Counter (PC) and flags (F) are automatically saved in the Stack. But we saw that each process has its own stack so that at any given time there are several, one for each process in multiprocessing. However, for the interrupt mechanism, "Stack" is that the log structure pointed to by SP (Stack Pointer), and at the time of the interruption Stack SP is pointing to the interrupted program so that is where save (automatically ) PC and F.
Moral: The status of implementation of a given process is saved in their stack.
Disruption leads to OS, the first task is to save the state complete the process execution interrupted that is, save the rest of the records in their own Stack. At baseline, SP still points to the stack of the process, so the OS complete with successive saves PUSH instructions. Finally, the OS saves SP to a data structure itself.
OS The second task is to pass control to the next process in turn. It is sufficient to find out what that process and retrieve the corresponding Stack Pointer (ie, load SP with that value). Once done, Stack SP is pointing to the process in question where, as has been said, is saving his "state of execution." The OS is responsible for executing successive instructions then POP to retrieve the records he saved at the time, after which a RET instruction executed on the master (interrupt return). This statement automatically takes care of recovering PC, F, and pass control to the process in question, which completes the switching.
DATA STRUCTURE
To conduct its work in arbitration, the OS uses its own data structures. The following is only a first approximation as the structures as such have not been designed. PGM
In an arrangement (call PGM) is stored information about each program available. Remember to recycle programs in Storage, not in memory. To make the OS aware of its existence, is needed a configuration file where such programs are enrolled. The OS reads this file during loading and creates from it, the PGM which specify under what programs are available and where to find them in Storage. PROC
In an arrangement (call PROC) is stored information about the processes involved multiprocessing. Initially, the array will be empty or may contain information about operating system processes automatically launched (as Shell). Each array element specifies, among other things, the address in memory of the Code and the Stack of the process in question.
Whenever a process instance, creates a new element in the array PROC. If this is the first instance, the corresponding program is loaded from storage. The OS switching mechanism is guided by this arrangement for arbitration. SESSION
Assuming that the system can be accessed from several terminals at once, the concept of session is a "working day" from the perspective of the visitor. However, the session is not a concept inherent in multiprocessing. Talk about it later in an article devoted to "Multi-User."
OPERATING SYSTEM SERVICES
Apart from the arbitration rutuna multiprocessing we just saw, the OS offers other services, especially for applications such as access to perifiéricos, accommodation etc memory.
applications requesting these services through software interrupts (INT instruction), which we call "calls to the OS" or (in English) "System Calls".
When an application makes a System Call, the CPU passes control to the specified interrupt routine, which is part of the OS. The first thing this routine is to disable the timer interrupt to avoid being disturbed during their work. And this is important: an OS interrupt routine stops multiprocessing, that is, it paralyzes the system to concentrate entirely on the task of the OS.
These routines must therefore be short and concise. Their duties are such as memory allocation, etc peripheral initiation. Once he finished his brief work, the routine passes control to the heart of the OS who will take care then move to the next process in turn.
But the OS also offers FULL SUPPORT "long" that can not be written as short interrupt routines. Such is the case, for example, data processing routines such as: Management, búqueda, or perhaps a floating point arithmetic. These services are implemented as software operating system (to which we call services) and makes them participate in such processes multiprocessing ordinary. To make use of them, an application makes a system routine calls interrumpción which merely provides the bridge between the application and service.
RELATIONS RELATIONSHIP BETWEEN PROCESSES
As a process can request a service from the OS (which is, as we saw, another process), a process can also start another process not covered by the operating system. This applies, for example, run-time library "of language (on this particular issue back on other items).
Suppose there is a service to sort lists, call it QUICK-SORT. To use, a process must make a system call passing as argument the address of the list in question as well as its size. Surely, the process is not interested in further execution until QUICK-SORT has completed its work and that nothing can be done with a half-order list.
Remember that a service is involved multiprocessing, so that their work takes place "simultaneously" with the process that called it. So most likely the OS returns control to the process before the QUICK-SORT has completed its work, contrary to what is wanted.
The way around this is to build relationships of kinship between processes. In this case, the process in question is "father" of the instance (process) QUICK-SORT that the OS created upon request. And the rule is that the father stops until the child has finished executing.
"Stop a process" in multiprocessing means that their turn, the OS will not control him but the next process in turn. This is achieved through the use of "traffic lights" which in this case, puden located in the same array PROC.
Another advantage of parent-child relationships between processes refers to cleaning and maintenance: When a parent process dies, all his children should die, preventing imnecesariamente occupy the spectrum of multiprocessing.
PROCESSING MULTI-WIRE
The rule set out in section above (the father if the child stops running) is not strict but just an option. It may happen that a process need not wait for the results of the requested service. For example, printing a document as I continue with other calculations related to printing.
In this case, the application would make the system call specifying that you want to be stopped. As a result, a process would be "simultaneously" with their children, which is nothing but "multi-thread (multithreading).
MULTI-USER does not directly involve multiprocessing
Multi-User. On this theme abound in separate article due to its extension. 
In the figure, P1 and P2 are two processes "Multiprocessor", ie, multiplexed in time in such a way that P1 and P2 are simultaneously in the eyes of the user, OS is the operating system or, more specifically, a routine responsible for producing the switching between processes. Each process runs continuously until the arrival of a TIMER interrupt (every 1 ms) which passes control to the OS.
We have seen in previous articles that a program can only exist as such in Storage, when loaded into memory, it creates an "instance" consists of two areas: one for code and other data for your area (Stack). We also saw that same program can be multi-instantiated, in which case it keeps in memory a single copy the code, but Stacks are created separately, one for each instance. By "process" we mean just that: an instance of a given program, in particular, P1 and P2 may be instances of the same program.
STATE OF EXECUTION
When a process is interrupted (the Timer), its "status of implementation" must be stored somewhere so that when the OS returns control, it can continue the exact ejecutación point where you left off.
At Heritage / 1, the interrupt mechanism itself provides the means to save the "state of execution." Indeed, when an interrupt occurs, the Program Counter (PC) and flags (F) are automatically saved in the Stack. But we saw that each process has its own stack so that at any given time there are several, one for each process in multiprocessing. However, for the interrupt mechanism, "Stack" is that the log structure pointed to by SP (Stack Pointer), and at the time of the interruption Stack SP is pointing to the interrupted program so that is where save (automatically ) PC and F.
Moral: The status of implementation of a given process is saved in their stack.
Disruption leads to OS, the first task is to save the state complete the process execution interrupted that is, save the rest of the records in their own Stack. At baseline, SP still points to the stack of the process, so the OS complete with successive saves PUSH instructions. Finally, the OS saves SP to a data structure itself.
OS The second task is to pass control to the next process in turn. It is sufficient to find out what that process and retrieve the corresponding Stack Pointer (ie, load SP with that value). Once done, Stack SP is pointing to the process in question where, as has been said, is saving his "state of execution." The OS is responsible for executing successive instructions then POP to retrieve the records he saved at the time, after which a RET instruction executed on the master (interrupt return). This statement automatically takes care of recovering PC, F, and pass control to the process in question, which completes the switching.
DATA STRUCTURE
To conduct its work in arbitration, the OS uses its own data structures. The following is only a first approximation as the structures as such have not been designed. PGM
In an arrangement (call PGM) is stored information about each program available. Remember to recycle programs in Storage, not in memory. To make the OS aware of its existence, is needed a configuration file where such programs are enrolled. The OS reads this file during loading and creates from it, the PGM which specify under what programs are available and where to find them in Storage. PROC
In an arrangement (call PROC) is stored information about the processes involved multiprocessing. Initially, the array will be empty or may contain information about operating system processes automatically launched (as Shell). Each array element specifies, among other things, the address in memory of the Code and the Stack of the process in question.
Whenever a process instance, creates a new element in the array PROC. If this is the first instance, the corresponding program is loaded from storage. The OS switching mechanism is guided by this arrangement for arbitration. SESSION
Assuming that the system can be accessed from several terminals at once, the concept of session is a "working day" from the perspective of the visitor. However, the session is not a concept inherent in multiprocessing. Talk about it later in an article devoted to "Multi-User."
OPERATING SYSTEM SERVICES
Apart from the arbitration rutuna multiprocessing we just saw, the OS offers other services, especially for applications such as access to perifiéricos, accommodation etc memory.
applications requesting these services through software interrupts (INT instruction), which we call "calls to the OS" or (in English) "System Calls".
When an application makes a System Call, the CPU passes control to the specified interrupt routine, which is part of the OS. The first thing this routine is to disable the timer interrupt to avoid being disturbed during their work. And this is important: an OS interrupt routine stops multiprocessing, that is, it paralyzes the system to concentrate entirely on the task of the OS.
These routines must therefore be short and concise. Their duties are such as memory allocation, etc peripheral initiation. Once he finished his brief work, the routine passes control to the heart of the OS who will take care then move to the next process in turn.
But the OS also offers FULL SUPPORT "long" that can not be written as short interrupt routines. Such is the case, for example, data processing routines such as: Management, búqueda, or perhaps a floating point arithmetic. These services are implemented as software operating system (to which we call services) and makes them participate in such processes multiprocessing ordinary. To make use of them, an application makes a system routine calls interrumpción which merely provides the bridge between the application and service.
RELATIONS RELATIONSHIP BETWEEN PROCESSES
As a process can request a service from the OS (which is, as we saw, another process), a process can also start another process not covered by the operating system. This applies, for example, run-time library "of language (on this particular issue back on other items).
Suppose there is a service to sort lists, call it QUICK-SORT. To use, a process must make a system call passing as argument the address of the list in question as well as its size. Surely, the process is not interested in further execution until QUICK-SORT has completed its work and that nothing can be done with a half-order list.
Remember that a service is involved multiprocessing, so that their work takes place "simultaneously" with the process that called it. So most likely the OS returns control to the process before the QUICK-SORT has completed its work, contrary to what is wanted.
The way around this is to build relationships of kinship between processes. In this case, the process in question is "father" of the instance (process) QUICK-SORT that the OS created upon request. And the rule is that the father stops until the child has finished executing.
"Stop a process" in multiprocessing means that their turn, the OS will not control him but the next process in turn. This is achieved through the use of "traffic lights" which in this case, puden located in the same array PROC.
Another advantage of parent-child relationships between processes refers to cleaning and maintenance: When a parent process dies, all his children should die, preventing imnecesariamente occupy the spectrum of multiprocessing.
PROCESSING MULTI-WIRE
The rule set out in section above (the father if the child stops running) is not strict but just an option. It may happen that a process need not wait for the results of the requested service. For example, printing a document as I continue with other calculations related to printing.
In this case, the application would make the system call specifying that you want to be stopped. As a result, a process would be "simultaneously" with their children, which is nothing but "multi-thread (multithreading).
MULTI-USER does not directly involve multiprocessing
Multi-User. On this theme abound in separate article due to its extension.
Tuesday, December 8, 2009
Why Is The Bottom Of My Foot Numb
Processing in Heritage / 1
Before a hard drive, Heritage / 1 will be V-tapes for storage. I mentioned that a V-TAPE is (or will be) a 3.5-inch diskette with a file system (owner) designed to simulate a magnetic tape.
So far, I imagined that a V-TAPE only hosts to a file, but this is a waste of space, obviously it is quite possible, therefore, to design the file system so as to allow more than one file for V -TAPE. Suppose that is the case, then my choice will host one or more of a V-TAPE. I think in the case of databases (or data files in general) prefer a single file by V-TAPE and these files will grow over time, while for several files preferred programs by V-TAPE and that they are fixed length so I can make better use of disk space.
The reader will wonder what is problem if the diskette is a random access medium. The answer is that a V-TAPE is no such thing as its file system forces you to behave like a tape and is as such qie no-brainer. The tape is a sequential access medium, can personally do not but only inserts data at the end to add or replace the file in its entirety. From there to host several files on one tape impossible to update them. I am aware that these procedures look archaic in the ear of a modern man, but this is it: to savor the past problems.
DATABASES
will adevertido the curious reader of history that the old computer centers employing a large number of tape drives. I think not so much to increase the total capacity of the system but, rather, to allow operation with a large number of files simultaneously.
Take the case of an application of typical database. Today we are used to design databases in line with the relational model, we think of "stalemate" divided into "columns", we set vínclulos between them, and we worry about the "plumbing" underlying it as the employee DBMS (MySQL, MS SQL Server, etc) is responsible for those underage. The truth is that almost all modern DBMS creates a disk file for each "table" in our database, so an application, which typically employs a large number of tables, use a large number of files on disk.
We will not use disk, but V-tapes, and we have seen that each file uses a V-TAPE for themselves, so that a large number of files means a large number of V-TAPES, which is the same as saying: a large number of readers of diskettes. This imposes a serious constraint to the design of our databases, you must use the least amount of "Tables."
Incidentally, we will not use the Relational Model, but as this is the hierarchical role in times of Heritage / 1.
PERMANENT FILES AND FILES MOTION
Here is a concept lost in time because today, updating a file on disk is no problem. But this was not the case at the time of the tapes.
We have seen that the only way to update a tape that contains multiple files is to replace all their new versions, ie the tape in its entirety. In practice, this means, rather, read the old tape while creating a new one with the new data (Using two tape drives) ... remember that in those days, memory was limited and quite possibly not enough to accommodate a file in its entirety.
intersante The moral of this story is that the updating of files on tape is something to be avoided. One way to minimize it is by the use of "permanent files."
Consider the case of a Personal Monitoring System. There are a lot of information about each employee, but does not recruit or lay off workers on a daily basis, so that information is not very amenable to change. These files are called "permanent."
In contrast, there is frequently changing information such as hours worked per day, holidays, etc.. This information is saved in "files of movement." The daily task is to update system files and then generate outputs motion based on these, with reference to the permanent. For example, the output "Pedro Perez has 4 hours of exta time these days" is generated on the basis of continuous information on Pedro Perez (including their normal working hours) and hours worked which were recorded daily (motion).
The advantage of using permanent files is that we can store more than one file on the same tape, saving readers. In case you need to update (recruitment of new employees, for example), there to produce a new tape (permanent) which is an updated version of the old.
The moral is this: The system must be designed movements trying to concentrate on the smallest possible amount of files, maximizing the use of permanent files.
PROGRAM FILES
We are made to the idea that our PC is a "solve it all" and therefore must accommodate a vast number of programs but only a few we use in daily practice. This follows from the fact of being, our PC, (and as its name suggests) a "Personal Computer."
In the industrial world is more common to find computers (even PCs) dedicated to a single function, but even in such cases their operating systems (Windows, Linux, etc.) come with a huge amount of pre-installed programs to provide various services and even applications platform.
This is not (permanently) for Heritage / 1, as it was not that of their counterparts back in the early 70s. If
Heritage / 1 service with a public library, for example, would be devoted entirely to keep the library catalog, ie one and only one application for the rest of your life.
recidirían data files in various V-TAPES perennial mounted in their respective readers. Two V-tapes would be earmarked for additional programs: one for the OS (H1-OS) and one for the application itself. Whenever
had to start the system, the operator would enter the "Loader" in memory using the console for it and this little program is responsible for H1-OS loaded into memory from V-TAPE. Surely H1-OS consists of several files of programs, all of them city residents in the same V-TAPE ... or maybe take a few and then the operator has to do juggling changing V-Tapes in various readers over the load.
with the OS already running, the ride operator V-TAPE of the application, and hit command, instruct H1-OS to load in memory. By then the V-TAPES data would be mounted in their respective readers and clients of the library could then make use of the system from terminals installed in the lounge.
How many readers?
I thought about a initial SUPPLIES 8-V-TAPE readers. This magic number comes from a very simple consideration: that is what fits comfortably in 19 inch rack. Surely one will be reserved for the OS, so I have 7 to my database applications, whatever they are.
Interestingly, I am designing a simple database to solve a particular problem persornal and so far, I'm just taking up 5 files ... so the restriction has not proved to be too severe ... so far.
Before a hard drive, Heritage / 1 will be V-tapes for storage. I mentioned that a V-TAPE is (or will be) a 3.5-inch diskette with a file system (owner) designed to simulate a magnetic tape.
So far, I imagined that a V-TAPE only hosts to a file, but this is a waste of space, obviously it is quite possible, therefore, to design the file system so as to allow more than one file for V -TAPE. Suppose that is the case, then my choice will host one or more of a V-TAPE. I think in the case of databases (or data files in general) prefer a single file by V-TAPE and these files will grow over time, while for several files preferred programs by V-TAPE and that they are fixed length so I can make better use of disk space.
The reader will wonder what is problem if the diskette is a random access medium. The answer is that a V-TAPE is no such thing as its file system forces you to behave like a tape and is as such qie no-brainer. The tape is a sequential access medium, can personally do not but only inserts data at the end to add or replace the file in its entirety. From there to host several files on one tape impossible to update them. I am aware that these procedures look archaic in the ear of a modern man, but this is it: to savor the past problems.
DATABASES
will adevertido the curious reader of history that the old computer centers employing a large number of tape drives. I think not so much to increase the total capacity of the system but, rather, to allow operation with a large number of files simultaneously.
Take the case of an application of typical database. Today we are used to design databases in line with the relational model, we think of "stalemate" divided into "columns", we set vínclulos between them, and we worry about the "plumbing" underlying it as the employee DBMS (MySQL, MS SQL Server, etc) is responsible for those underage. The truth is that almost all modern DBMS creates a disk file for each "table" in our database, so an application, which typically employs a large number of tables, use a large number of files on disk.
We will not use disk, but V-tapes, and we have seen that each file uses a V-TAPE for themselves, so that a large number of files means a large number of V-TAPES, which is the same as saying: a large number of readers of diskettes. This imposes a serious constraint to the design of our databases, you must use the least amount of "Tables."
Incidentally, we will not use the Relational Model, but as this is the hierarchical role in times of Heritage / 1.
PERMANENT FILES AND FILES MOTION
Here is a concept lost in time because today, updating a file on disk is no problem. But this was not the case at the time of the tapes.
We have seen that the only way to update a tape that contains multiple files is to replace all their new versions, ie the tape in its entirety. In practice, this means, rather, read the old tape while creating a new one with the new data (Using two tape drives) ... remember that in those days, memory was limited and quite possibly not enough to accommodate a file in its entirety.
intersante The moral of this story is that the updating of files on tape is something to be avoided. One way to minimize it is by the use of "permanent files."
Consider the case of a Personal Monitoring System. There are a lot of information about each employee, but does not recruit or lay off workers on a daily basis, so that information is not very amenable to change. These files are called "permanent."
In contrast, there is frequently changing information such as hours worked per day, holidays, etc.. This information is saved in "files of movement." The daily task is to update system files and then generate outputs motion based on these, with reference to the permanent. For example, the output "Pedro Perez has 4 hours of exta time these days" is generated on the basis of continuous information on Pedro Perez (including their normal working hours) and hours worked which were recorded daily (motion).
The advantage of using permanent files is that we can store more than one file on the same tape, saving readers. In case you need to update (recruitment of new employees, for example), there to produce a new tape (permanent) which is an updated version of the old.
The moral is this: The system must be designed movements trying to concentrate on the smallest possible amount of files, maximizing the use of permanent files.
PROGRAM FILES
We are made to the idea that our PC is a "solve it all" and therefore must accommodate a vast number of programs but only a few we use in daily practice. This follows from the fact of being, our PC, (and as its name suggests) a "Personal Computer."
In the industrial world is more common to find computers (even PCs) dedicated to a single function, but even in such cases their operating systems (Windows, Linux, etc.) come with a huge amount of pre-installed programs to provide various services and even applications platform.
This is not (permanently) for Heritage / 1, as it was not that of their counterparts back in the early 70s. If
Heritage / 1 service with a public library, for example, would be devoted entirely to keep the library catalog, ie one and only one application for the rest of your life.
recidirían data files in various V-TAPES perennial mounted in their respective readers. Two V-tapes would be earmarked for additional programs: one for the OS (H1-OS) and one for the application itself. Whenever
had to start the system, the operator would enter the "Loader" in memory using the console for it and this little program is responsible for H1-OS loaded into memory from V-TAPE. Surely H1-OS consists of several files of programs, all of them city residents in the same V-TAPE ... or maybe take a few and then the operator has to do juggling changing V-Tapes in various readers over the load.
with the OS already running, the ride operator V-TAPE of the application, and hit command, instruct H1-OS to load in memory. By then the V-TAPES data would be mounted in their respective readers and clients of the library could then make use of the system from terminals installed in the lounge.
How many readers?
I thought about a initial SUPPLIES 8-V-TAPE readers. This magic number comes from a very simple consideration: that is what fits comfortably in 19 inch rack. Surely one will be reserved for the OS, so I have 7 to my database applications, whatever they are.
Interestingly, I am designing a simple database to solve a particular problem persornal and so far, I'm just taking up 5 files ... so the restriction has not proved to be too severe ... so far.
Subscribe to:
Posts (Atom)