Jihad needs scientists

[Ken Smith]

In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines. With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esrgdi$8ss_002@s842.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esp7m9$hni$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esothi$8ss_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esmj7c$bj2$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esm9f6$8ss_002@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esju3h$1a4$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
Having multiple disks connected to a single disk drive controller
electronics gives absolutely no advantage and a few disadvantages.

I know that one can have multiple structures on one drive. Has
the need of having one structure on multiple drives gone away?

No, it hasn't gone away completely. There is a lot less need for logical
volumes to span multiple disks today.

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

This may happen some time in the slightly distant future. Modern OSes
allow what the user sees as a directory to be a different disk drive.

MS-DOS did this with the "join" command. When Windows 95 was brought out,
the "join" command went away. On Linux and OS-X, the command is "mount".

It isn't much of a stretch of the imagination to see some OS automatically
assigning an entier drive to things like videos.

These used to be called private packs. The concept has existed since
the 60s.

They weren't assigned automatically though. The operator allocated them
after you paid large amounts of money.

[....]

The last reason was valid in the olden days. JMF visited an insurance
company site and saw a disk farm of [can't remember the number]
hundreds, I think. He was awed because it was all one file.
There was no way our products could deal with
that kind of a data base. IBM knew how to handle those.

IBM's design of the logical structure was very good from this point of
view. The Volume Table Of Contents told you where the Data Extent Blocks
were. The DEBs formed a chain. Extending this chain to include which
physical drive the next things were on wouldn't be hard to do.

IBM evolved based on data base usage. We didn't. Our trade offs
were guided by delivering computing to people who did science and
engineering.

Where you evolve to depends a lot on where you start. In this case, there
is a large factor from the seemingly unimportant choices made in the early
days.
--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esrgkf$8ss_004@s842.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
[.... me .....]

..... and it includes its own checksum. This checksum can be made to be
correct by the method I suggested.

Only by fakery.

No "fakery" was needed if you know beforehand the names of the files that
will be written.

To fake it would open up many opportunities
for Murphy's Law to strike.

Nothing I suggested leaves any extra room for Murphy and provides a
correct checksum which closes one door he may use.

It was more important to have
a physical list of what we put on the tape than to have
the checksum of TAPE.DIR be correct and as the first file
on the tape. Your approach would open the TAPE.DIR for writing.
This was an unacceptable risk.

You have to write to TAPE.DIR if you want it to exist. In the case where
the names going into TAPE.DIR is known, the method I suggested did not
require any other write actions than the method you suggested. It only
required that you think about what you intend to write before you wrote
it. This I assume you would already have to do some amount of because you
need to conpose the contents of that file based on what you intend to
write.


You just missed something that is all.

--
--
kensmith@rahul.net forging knowledge

 

[krw]

In article <irg1v2lu3uks9ekle3gf1qdipd9acbnkbf@4ax.com>,
MassiveProng@thebarattheendoftheuniverse.org says...

On Thu, 8 Mar 2007 20:56:15 -0500, krw <krw@att.bizzzz> Gave us:

Can't even put a sentence together, eh Dimbulb? "Us" is not
singular.


It is a song title, retard boy.

Doesn't change the fact that there is only *one* Dimbulb, Dimmie.

Try to keep up, dumbfucktard.

With you? Don't make me laugh (harder).

--
Keith

 

[Ken Smith]

In article <esrhir$8qk_001@s842.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esp89d$hni$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

Suddenly you are changing the subject.

I am still talking about the same procedure and constraints that
I had to solve.

The question is: would the
checksum before and after match? The answer is yes, so the method works.

No. It cannot match. Your method provides a list of we intended
to put on the tape. My method describes what was really put on the
tape because the TAPE.DIR file was generated by examining the tape.

In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum still
works. If you wrote the TAPE.DIR before the other files and never changed
it, my method still works.


[....]

Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?
I don't think so. You objected to opening it for writing. This means
that you only could have put it onto the tape before the others. You must
therefor have known what you intended to write. You also would have
checked when you were done that you really had written what you intended.
If what you actually wrote did not match what you intened to write, you
would have taken some action. Most likely you would make a new tape.

If the checksum at step (3) doesn't match the checksum at step (1), you
haven't written what you intended onto the tape. I am really surprised
that you can't see this.

I'm at a loss to try to explain what we were doing. YOu seem
to be determined not to understand.

You were making a mistake, is what you were doing.

You just gotta love this illogic. Your method is not a solution
and creates havoc.

No, what I suggested solves the problem you had cleanly and without adding
any problems. You just seem not to be able to grasp what it does.

It can also be extremely expensive if it
results in customers sending in problem reports when they could
have done preliminary checking at the time they first examine
the tape.

Nothing I suggested would result in that. The net result of what I have
suggested is one line of text in the TAPE.DIR file if it is an ASCII text
file and an extra byte if it is binary.

[....]

Yes it does. I have shown how you can make the checksum on this file
correct. This file that contains the list is the very file we have been
talking about.

It is a faked listing. It was not generated by looking at the
files that were really put on the tape. Not only did my method
provide an invoice of what got packed, my method kept us from
making blank or incomplete masters.

Once again what you are saying contradicts what you suggested earlier.
You had to check that you really did put onto the tape what you intended
to put onto the tape. My method makes no change to that requirement.

You are squirming. Just admit that the extra line of text in the file
solves the whole problem.


[....]

My simple case solves a problem that you said can't be solved. You said
it was imposible. It is not.

It is impossible. Everytime you take a new directory of the tape,
the checksum of TAPE.DIR changes. If you do another save with the
new TAPE.DIR, another directory of the physical tape will produce
a different checksum of TAPE.DIR.

(1)
Is TAPE.DIR a file?

(2)
Do you write this file onto the tape?

(3)
Do you go never back and change this file after it is written?

(4)
Do you put this file at the beginning of the tape?

If the answer to these four questions is yes, then my method as discussed
earlier works just fine. If the answer to any combination of these is no,
then my method still works. I don't want to have to try to explain to you
all posible combinations.

You can't edit a tape. That would open such a can of Murphy's
worms, even if it were possible.

This would be a very strange drive if you really couldn't.

You have never been able to edit magtape. You need two
drives to do an edit.

WRONG! You have always been able to edit magnetic tape. You can't cause
the lengths of things to change but you can overwrite a file with one of
the same size.

[.....]

The reason tapes have an IRG (Inter Record Gap) is to allow the data on
the tape to be edited. You may decide not to do this but the drives knew
how.

Now that's a new one.

Hardly new. Reel to reel tape isn't used much anymore. Even very stone
aged reel-to-reel drives like the Kennedy 9700 could do it. You being
unaware of this contradicts statements you made earlier.

This file lists the names of the files on the tape.

You method does not list the files on the tape. Your method
lists the files you intend to put on the tape. These are
two very different lists.

Do you write your list after you have written all the files?

If yes, then my method works. If no then your method isn't any more a
list of files actually on the tape than mine is. In either case, my
method will make a correct checksum. You were needlessly shipping tapes
with an error on them.

There is absolutely nothing in what I suggested that changes this. I will
suggest you go back over the subject again.

I don't have to; my methods worked and provided enough data
for sanity checks on both ends of the distribution system.

You said the checksum was published as wrong

Only the checksum of the file TAPE.DIR was incorrect. The first
save of the tape had the checksum as 0.

I have proven that it didn't need to be. No matter what order you did
things, the checksum could have been right. You have made claims that
contradict each other about what you did.

--
--
kensmith@rahul.net forging knowledge

 

[MassiveProng]

On Fri, 9 Mar 2007 14:29:11 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) Gave us:

In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines. With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

Funny... I said NETWORKING, NOT ROUTING.

Do you two have reading comprehension issues or what?

Sheesh!

 

[MassiveProng]

On Thu, 8 Mar 2007 14:47:37 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) Gave us:

MS-DOS did this with the "join" command. When Windows 95 was brought out,
the "join" command went away. On Linux and OS-X, the command is "mount".

No. It was the SUBST command.

Also... it is STILL in use.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/subst.mspx?mfr=true

JOIN was for taking multiple drives and creating one drive letter to
hit them with.

JOIN was for assigned drive letter redirects, and SUBST was a
redirect which could be used for ANY path to be assigned a drive
letter.

 

[MassiveProng]

On Fri, 09 Mar 07 11:29:43 GMT, jmfbahciv@aol.com Gave us:

In article <n7a1v29gv894uc76qtgn35j56hl2fflu5e@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv@aol.com Gave us:

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?


TeraByte drives are looming on the horizon as we speak.

And those are in 2.5" form factor.

Keep up much?

And will they survive being set next to TV or a vacuum cleaner?

What? That is just plain retarded.

They are no different than any other hard drive for their shielding
from external influence. Do you always ask such utterly stupid
questions? Were hard drives EVER subject to being affected by nearby
TV or vacuum cleaner? None that I am aware of.

Sheesh!

If anything the data stored on them is MORE resilient.

They are perpendicular recording technology, and THAT has a BETTER
retention factor than the current horizontal method.

 

In article <esrqvn$n5i$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines.

Why? Most user machines are used essentially as end nodes, especially
the systems used as a TTY hosted into an ISP. These should never
be doing routing. Contention and pathway changes are too high
and would be a waste of overall routing CPU time to deal with.

With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

It's easier to fire wall also.

/BAH

 

In article <oo04v2d5ubfqmd07mgaqe6fssbav3g66th@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Fri, 9 Mar 2007 14:29:11 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) Gave us:

In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines. With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

Funny... I said NETWORKING, NOT ROUTING.

Do you two have reading comprehension issues or what?

Which layer of the NETWORKING were you talking about?

/BAH

 

In article <esrr8b$n5i$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esrgdi$8ss_002@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esp7m9$hni$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esothi$8ss_002@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esmj7c$bj2$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esm9f6$8ss_002@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esju3h$1a4$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
Having multiple disks connected to a single disk drive controller
electronics gives absolutely no advantage and a few disadvantages.

I know that one can have multiple structures on one drive. Has
the need of having one structure on multiple drives gone away?

No, it hasn't gone away completely. There is a lot less need for logical
volumes to span multiple disks today.

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?

This may happen some time in the slightly distant future. Modern OSes
allow what the user sees as a directory to be a different disk drive.

MS-DOS did this with the "join" command. When Windows 95 was brought out,
the "join" command went away. On Linux and OS-X, the command is "mount".

It isn't much of a stretch of the imagination to see some OS automatically
assigning an entier drive to things like videos.

These used to be called private packs. The concept has existed since
the 60s.

They weren't assigned automatically though.

That is all a small matter of organization sometimes coupled
with some programming.

The operator allocated them
after you paid large amounts of money.

That depended on the site. You seem to be talking from an IBM
operational POV. Ours was designed differently. It was easy
to redirect any spooling to a pack reserved for that purpose.
Video downloads, etc. could be in a similar category.

[....]
The last reason was valid in the olden days. JMF visited an insurance
company site and saw a disk farm of [can't remember the number]
hundreds, I think. He was awed because it was all one file.
There was no way our products could deal with
that kind of a data base. IBM knew how to handle those.

IBM's design of the logical structure was very good from this point of
view. The Volume Table Of Contents told you where the Data Extent Blocks
were. The DEBs formed a chain. Extending this chain to include which
physical drive the next things were on wouldn't be hard to do.

IBM evolved based on data base usage. We didn't. Our trade offs
were guided by delivering computing to people who did science and
engineering.

Where you evolve to depends a lot on where you start. In this case, there
is a large factor from the seemingly unimportant choices made in the early
days.

Those weren't unimportant choices. They were deliberately made with
certain goals and non-goals in mind. No development was an
accident.

/BAH

 

In article <1914v2lqcetq8c7nh97qcv2otk94iu9ovi@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:

On Fri, 09 Mar 07 11:29:43 GMT, jmfbahciv@aol.com Gave us:

In article <n7a1v29gv894uc76qtgn35j56hl2fflu5e@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:54:26 GMT, jmfbahciv@aol.com Gave us:

Is this because disk capacities are larger than most needs? With
the habits of downloading music and videos, etc. won't there be
another capacity problem fairly soon?


TeraByte drives are looming on the horizon as we speak.

And those are in 2.5" form factor.

Keep up much?

And will they survive being set next to TV or a vacuum cleaner?



What? That is just plain retarded.

I don't allow a vacuum in my TTY room. It tended to wipe out
modems.

They are no different than any other hard drive for their shielding
from external influence. Do you always ask such utterly stupid
questions?

I was paid very well to ask those stupid questions. It was my
job and a requirement to be in any OS developement group.

Were hard drives EVER subject to being affected by nearby
TV or vacuum cleaner? None that I am aware of.

JMF bought his sons a PC one Christmas. Their first action
was to set the drive on top of the PC. Wipe out. And the
first DO NOT instruction was to not set the drive on the TTY.

Sheesh!

If anything the data stored on them is MORE resilient.

They are perpendicular recording technology, and THAT has a BETTER
retention factor than the current horizontal method.

I guess you can never lay down with one in your pocket then.
Credit cards magnetic strips of the males were always getting wiped out
whenever they leaned against a disk drive.

/BAH

 

In article <esrrjh$n5i$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esrgkf$8ss_004@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[.... me .....]
..... and it includes its own checksum. This checksum can be made to be
correct by the method I suggested.

Only by fakery.

No "fakery" was needed if you know beforehand the names of the files that
will be written.

Your method is still not a physical directory of the tape that is
going to be sent out.

To fake it would open up many opportunities
for Murphy's Law to strike.

Nothing I suggested leaves any extra room for Murphy and provides a
correct checksum which closes one door he may use.

Editing a number into the middle of a magtape is not asking
for major Murphy events? You are definitely not thinking well.

It was more important to have
a physical list of what we put on the tape than to have
the checksum of TAPE.DIR be correct and as the first file
on the tape. Your approach would open the TAPE.DIR for writing.
This was an unacceptable risk.

You have to write to TAPE.DIR if you want it to exist. In the case where
the names going into TAPE.DIR is known, the method I suggested did not
require any other write actions than the method you suggested. It only
required that you think about what you intend to write before you wrote
it. This I assume you would already have to do some amount of because you
need to conpose the contents of that file based on what you intend to
write.


You just missed something that is all.

You still are missing the requirement of having a directory of the
tape on the tape.

/BAH

 

In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <esrhir$8qk_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esp89d$hni$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esou80$8qk_001@s1016.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esml4r$bj2$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esmalk$8qk_001@s1012.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esjvn9$1a4$4@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
If you know what you intend to write onto the tape, figure out what the
checksum will be and then write the tape as you intend there is no
extra
effort needed.

That does not give you a checksummed directory of the physical
tape you just made. All the handwaving and blustering you
are doing still does not satisfy the requirement.

Yes it does. Imagine it step by step.

(1)
You calculate the checksum of what you intend to put on the tape.

(2)
You put exactly what you intend onto the tape

(3)
You calculate the checksum of what you have put on the tape.

The checksum of the contents of the tape is not interesting.
That is a summary and doesn't help. A bit by bit verify
is done instead of your checksum summary.

Suddenly you are changing the subject.

I am still talking about the same procedure and constraints that
I had to solve.

The question is: would the
checksum before and after match? The answer is yes, so the method works.

No. It cannot match. Your method provides a list of we intended
to put on the tape. My method describes what was really put on the
tape because the TAPE.DIR file was generated by examining the tape.

In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum still
works. If you wrote the TAPE.DIR before the other files and never changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

I don't think so. You objected to opening it for writing. This means
that you only could have put it onto the tape before the others. You must
therefor have known what you intended to write. You also would have
checked when you were done that you really had written what you intended.
If what you actually wrote did not match what you intened to write, you
would have taken some action. Most likely you would make a new tape.

A second save exercise had to be done. Howver, the checksum of
the file TAPE.DIR in the file TAPE.DIR would never be correct.
We could live with that. It would not generate any SPRs nor
create problems in the field.

If the checksum at step (3) doesn't match the checksum at step (1), you
haven't written what you intended onto the tape. I am really surprised
that you can't see this.

I'm at a loss to try to explain what we were doing. YOu seem
to be determined not to understand.

You were making a mistake, is what you were doing.

You just gotta love this illogic. Your method is not a solution
and creates havoc.

No, what I suggested solves the problem you had cleanly and without adding
any problems. You just seem not to be able to grasp what it does.

I know what it does. And the solution would cause more problems than
it fixed. If your solution was the only one, I'd punt the idea.

It can also be extremely expensive if it
results in customers sending in problem reports when they could
have done preliminary checking at the time they first examine
the tape.

Nothing I suggested would result in that. The net result of what I have
suggested is one line of text in the TAPE.DIR file if it is an ASCII text
file and an extra byte if it is binary.

Since the medium is a magtape, inserting one tiny bit would make a
mess of the save set and cause it to not be restorable. This
was the master cut of the tapes that would soon be made to ship
to all customers. It had to be perfect and copyable.

Another trick that had to done was to save files to tapes that
had been physically logically "shortened". That was done by
moving the silver strip to make a "short tape".

[....]
Yes it does. I have shown how you can make the checksum on this file
correct. This file that contains the list is the very file we have been
talking about.

It is a faked listing. It was not generated by looking at the
files that were really put on the tape. Not only did my method
provide an invoice of what got packed, my method kept us from
making blank or incomplete masters.

Once again what you are saying contradicts what you suggested earlier.
You had to check that you really did put onto the tape what you intended
to put onto the tape. My method makes no change to that requirement.

Your method does not put a director _OF_ the tape onto the tape.

You are squirming. Just admit that the extra line of text in the file
solves the whole problem.

It solves nothing and creates many, many messes.

[....]
My simple case solves a problem that you said can't be solved. You said
it was imposible. It is not.

It is impossible. Everytime you take a new directory of the tape,
the checksum of TAPE.DIR changes. If you do another save with the
new TAPE.DIR, another directory of the physical tape will produce
a different checksum of TAPE.DIR.

(1)
Is TAPE.DIR a file?

Yes.

(2)
Do you write this file onto the tape?

Yes. It is the first file.

(3)
Do you go never back and change this file after it is written?

Not the one on the tape. The first save had a zero checksum
TAPE.DIR file on it.

(4)
Do you put this file at the beginning of the tape?

Yes. Putting it at the end make it's purpose useless.

If the answer to these four questions is yes, then my method as discussed
earlier works just fine. If the answer to any combination of these is no,
then my method still works. I don't want to have to try to explain to you
all posible combinations.


You can't edit a tape. That would open such a can of Murphy's
worms, even if it were possible.

This would be a very strange drive if you really couldn't.

You have never been able to edit magtape. You need two
drives to do an edit.

WRONG! You have always been able to edit magnetic tape. You can't cause
the lengths of things to change but you can overwrite a file with one of
the same size.

But it isn't the same size. You cannot predict the size of any
record on a magtape. TW was correct when he said that God never
meant for there to be magtapes. He said this every time he wrote
code for a new controller or device.

[.....]
The reason tapes have an IRG (Inter Record Gap) is to allow the data on
the tape to be edited. You may decide not to do this but the drives knew
how.

Now that's a new one.

Hardly new. Reel to reel tape isn't used much anymore. Even very stone
aged reel-to-reel drives like the Kennedy 9700 could do it. You being
unaware of this contradicts statements you made earlier.

I was never aware that the purpose of IRGs was so a human could
edit directly to the tape.

This file lists the names of the files on the tape.

You method does not list the files on the tape. Your method
lists the files you intend to put on the tape. These are
two very different lists.

Do you write your list after you have written all the files?

Yes! THat is the only way to get a directory of the tape.


I give up. Your brain's PDL IOWD list is 2 words long.

/BAH

 

[MassiveProng]

On Sat, 10 Mar 07 11:40:07 GMT, jmfbahciv@aol.com Gave us:

In article <oo04v2d5ubfqmd07mgaqe6fssbav3g66th@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Fri, 9 Mar 2007 14:29:11 +0000 (UTC), kensmith@green.rahul.net (Ken
Smith) Gave us:

In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines. With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

Funny... I said NETWORKING, NOT ROUTING.

Do you two have reading comprehension issues or what?

Which layer of the NETWORKING were you talking about?

From your stupid posts, I was unaware that you knew anything about
layers.

And, it is a COMPUTING model they refer to, not a networking model.

 

[MassiveProng]

On Sat, 10 Mar 07 11:49:59 GMT, jmfbahciv@aol.com Gave us:

I don't allow a vacuum in my TTY room. It tended to wipe out
modems.

You're an idiot. You tend to attribute failure modes to unrelated
events a lot?

 

[MassiveProng]

On Sat, 10 Mar 07 11:49:59 GMT, jmfbahciv@aol.com Gave us:

I guess you can never lay down with one in your pocket then.
Credit cards magnetic strips of the males were always getting wiped out
whenever they leaned against a disk drive.

Bullshit. Credit card mag stripes are VERY resilient, and abrasive
scratches are about the only thing that fucks them up.

Your brain got wiped out when you refused to move beyond TTY access
to the world.

 

[Ken Smith]

In article <esu5ct$8ss_001@s861.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esrqvn$n5i$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esrg7f$8ss_001@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <2v91v2pjpp3qdcn8mv70t5rk21t7g1oeem@4ax.com>,
MassiveProng <MassiveProng@thebarattheendoftheuniverse.org> wrote:
On Thu, 08 Mar 07 11:48:40 GMT, jmfbahciv@aol.com Gave us:

As I said above, our OS philosophy was to provide multiple pathways.
Multiple pathways...do you understand what that means? So why
are you demeaning the OS philosophy with an argument about networks?


Networking is a MAJOR part of a modern OS, dingledorf.

It shouldn't be. Routing should be kept off user machines.

If more effective ways of breaking up the routing problem were found,
routing could be spread across the user machines.

Why? Most user machines are used essentially as end nodes, especially
the systems used as a TTY hosted into an ISP. These should never
be doing routing. Contention and pathway changes are too high
and would be a waste of overall routing CPU time to deal with.

You have only stated the current situation and not what it could be in the
future.

In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world. When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

With the current
situation, I agree with you that it needs to be kept on a special box just
for that purpose.

It's easier to fire wall also.

The way things are evolving, the server/router/firewall will be just a
Linux box running software.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esu5o4$8ss_003@s861.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esrr8b$n5i$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
These used to be called private packs. The concept has existed since
the 60s.

[....]
The operator allocated them
after you paid large amounts of money.

That depended on the site. You seem to be talking from an IBM
operational POV.

Yes, an IBM environment

Ours was designed differently. It was easy
to redirect any spooling to a pack reserved for that purpose.
Video downloads, etc. could be in a similar category.

Who did the "reserved for that purpose"? That would be the point where
money would be needed.

[....]

Where you evolve to depends a lot on where you start. In this case, there
is a large factor from the seemingly unimportant choices made in the early
days.

Those weren't unimportant choices. They were deliberately made with
certain goals and non-goals in mind. No development was an
accident.

Sure it was. In both hardware and software design there are often choices
that look identical today but won't in the future. For a long time logic
has run on 5V. The selection of 5V can be traced in part to the heater
voltage on tubes.




--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <esu670$8ss_005@s861.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <esrrjh$n5i$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esrgkf$8ss_004@s842.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[.... me .....]
..... and it includes its own checksum. This checksum can be made to be
correct by the method I suggested.

Only by fakery.

No "fakery" was needed if you know beforehand the names of the files that
will be written.

Your method is still not a physical directory of the tape that is
going to be sent out.

Yes it is! Yes it is! Yes it is! Stop thinking that and you may start
to see your mistake. I have tried repeatedly to simplify the question and
re-explain the issue. You keep coming back to this mistake. I have
explained how the checksum of the TAPE.DIR file can be correct in several
different ways but you seem to be unable to grasp what I've said.

To fake it would open up many opportunities
for Murphy's Law to strike.

Nothing I suggested leaves any extra room for Murphy and provides a
correct checksum which closes one door he may use.

Editing a number into the middle of a magtape is not asking
for major Murphy events? You are definitely not thinking well.

No, you are making the same mistake over and over. As I stated before, if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the method.


[.....]

You have to write to TAPE.DIR if you want it to exist. In the case where
the names going into TAPE.DIR is known, the method I suggested did not
require any other write actions than the method you suggested. It only
required that you think about what you intend to write before you wrote
it. This I assume you would already have to do some amount of because you
need to conpose the contents of that file based on what you intend to
write.


You just missed something that is all.

You still are missing the requirement of having a directory of the
tape on the tape.

TAPE.DIR is the first file on the tape
TAPE.DIR lists the checksums of all the files on the tape.

TAPE.DIR's checksum in this list can be correct when written.

I have tried to explain how but you just don't seem to be able to
understand the issue.

--
--
kensmith@rahul.net forging knowledge