Skybuck's Universal Code 5 (The Native Version)

Yes, that was the name I was trying to remember. "Index Sequential" files were handy whne you needed to refer to entries more or less but not quite at random based on some "key". The cute thing on the IBM360 was that the channel controller could do all the work of finding the records thus taking it out of the CPU time consumed.

You could even write a complete program to run on the channel controller. This way, you could use the bogo-sort to sort the database but only use 1 second of CPU time. It was a very nice feature.

The RS232 ports also had channel controllers. You could make your terminal interface run mostly in it. This way a complete program with user interface would be able to do stuff to disk files with very little CPU time. You could get a lot more done per second on the machine that way.

Which is harder on a drive, and increases the odds of a failure simply due to extreme, unnecessary overuse.

Hell, the drive is less taxed if you simply leave it fragged and use it.

Actually, it doesn't put anymore strain on it than normal operation. Reorganisation consisted of copying the file from one drive (the primary) to another (the secondary) which had to occur for backup anyway. Copying the file rebuilds the index because it contains absolute disk addresses of the record. Depending on the design of the application, and the willingness of the client department to pay for redundant drives (or removable platters), sometimes the primary was backed up to tape, then rebuilt from the tape.

The ISAM index was built with free space in each data block for record inserts. If the block filled up, then it had to allocate a new block, and split the keys between the new and old block. Because the new block was not strictly sequential on the device, it is slower to access. Too many splits could bring your online processing system (either CICS or IMS) to its knees pretty quickly.

Online inserts were relatively rare, so splits rarely occured due to online processing. Overnight 'batch' runs were the killers. It was an operational neccessity to ensure the indeces were in a good state when the CICS systems came up in the morning.

So after copying, the secondary then becomes the new primary and the old primary is the backup (or the primary is rebuilt from tape). Transaction logs kept during the weekly processing can then be deleted (or more correctly, backed off to tape). This backup had to happen anyway, so this method just ensured that the ISAM index file started the week with optimum freespace.

Todays workstation drives get much more abuse than mainframe DASD devices did 35 years ago. Much more.

I did not mean "more strain" as in the operation is more strenuous. I mean more strain as in more is more, period.

If a sector is going to yield 1 million read write operations, and you defrag constantly, you are going to arrive at that number far sooner than if you only use the drive for normal r/w operations.

So what ends up making it less strenuous is the mere fact that less is less. 1000 operations is a smaller number than 10,000 operations.

Disk crashes were a rare, but feared, phenomenon. It was important to back things up in such a way that recovery time was minimal for online applications - just as it is today. The reorg was a byproduct of the backup, but it was no less as important for the reliable operation of the application.

Reliable operation of the application is more important than getting an extra week or two of operation out of the disk drive - much more important - yes, even in the ye olden days when disk drives were ordered months in advance and took the entire weekend to install.

Sure, a disk will last longer if you don't use it. But what a silly argument to justify a dead application.

Actually if harddisks really could fail because of repeated reads/writes from the same sectors then the following inventions could be considered dangerous:

1. Partioning.

1. FileDisk Images.

Maybe even ISO's when mounted.

Bye, Skybuck.

You're an idiot.

All hard disk failures that are magnetic platter surface related are due to lost sectors. If you had any brains at all, you would understand how sectors which can no longer be written to or read from come about.

You too funny.

Here I am having used OS-es for years, with page files on the same location.

Other files on the same locations as well.

And my harddisk have never failed.

Only harddisk which has failed so far was a harddisk I kicked around.

So I am pretty much convinced your theory that reading/writing from/to the same sectors causes damage is nonsense.

:P****

Bye, Skybuck.

Skybuck Flying ?????:

According to

GMP uses continuous memory block. It is still the most efficient way dealing with big numbers. In order for linked list to be more efficient the stored numbers by itself must be so damn big (or so damn precise) that it is not an issue any soon.

However I find your theory intriguing but cannot find any evidence for it.

You have any evidence ? ;)

Bye, Skybuck.

Also if there is any thruth in what you wrote I ask you to clearify yourself.

Because it wasn't completely clear to me.

What did you mean with formatted list ?

The list of clusters that resulted from a format ?

It would make little sense, since the file system needs to keep track of delete clusters etc.

Bye, Skybuck.

"clearify" is not a word, you retarded f*ck.

Well, we expect nothing more from a dope like you. You're a goddamned retard and cannot be expected to understand. Hell, you cannot even understand BASIC Usenet principles, like quoting what you are responding to, idiot.

You need to start over if you do not understand what a formatted list is, idiot.

You're an idiot.

As if a retarded f*ck like you even has the qualifications to make such an assessment, and have anyone here heed it as being valid.

You're an idiot. Bad clusters are mapped out by the hard drive itself, at the firmware level, 100% transparent to ANY file system, you retarded f*****ad!

Ok, thank you for clearing that up.

Your posts were most amusing.

Meanwhile I have asked others on other newsgroups what they thought about this theory.

All have said "myth".

And you didn't even understand what you wrote yourself it seems ;)

Bye, Skybuck.

Addition:

The subject of self-healing harddisks has nothing to do with your original theory.

Your original theory was file systems use least used clusters to prevent failure in the first place by often re-use.

At least that's how I interpreted your theory. Maybe you were a dumb f*ck tard which wasn't able to explain himself properly.

I am fully aware of harddisks trying to heal itself, by avoiding/marking bad clusters.

Maybe that's what you ment. Harddisk repairing itself... well big woopie.

Lol you a f*ck tard lol.

Bye, Skybuck.

You're an idiot, and I notice that none of your "experts" are responding in the thread. So much for your, and their credibility.

I always assumed he was an MIT graduate student's AI project. Or else lives next door to the old dope peddler. Remember Kibo? I mean, he often almost makes sense.