text character based diagrams in technical documentation
Larry__Weiss
that employed simple text characters. Even flowcharts were produced using just
the character set of available character-only printers. Does anyone else here
remember this sort of documentation? Has anyone preserved some samples?
Bill Leary
news:3F2C8086...@airmail.net...
> I have a memory of seeing very sophisticated technical diagrams in old
documents
> that employed simple text characters. Even flowcharts were produced using
just
> the character set of available character-only printers. Does anyone else
here
> remember this sort of documentation?
Yes.
> Has anyone preserved some samples?
Yes. I'll see if I can dig up an example over the weekend.
- Bill
arargh3...@now.at.arargh.com
wrote:
>I have a memory of seeing very sophisticated technical diagrams in old documents
>that employed simple text characters. Even flowcharts were produced using just
>the character set of available character-only printers. Does anyone else here
>remember this sort of documentation?
Sure.
>Has anyone preserved some samples?
I have a whole bunch of IBM manuals dating from the early 70's that
were all created that way.
--
Arargh307 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Russ Holsclaw
The logic diagrams that IBM used in 2nd and 3rd generation
computers (1400 and 7000-series computers, and the 360's and
370's, were all printed on 1403 printers. For the 350's, IBM
produced an internal-use-only type-train that printed small
characters sideways. These were used on specially equipped 1403
printers that could be set to print 15 lines per inch. Since it
was printing sideways, this translated into 15 characters per
inch horizontal and 10 lpi vertically. The typeset included a
full set of alphanumeric characters and special characters
(pretty much the whole upper-case EBCDIC set) plus a full set of
line-drawing characters, similar.
IBM's software for producing logic diagrams was designed to print
using this character set, onto paper that was something like 15
by 22 inches in size ... the same size used in IBM's big logic
diagram binders. The location where I worked in Raleigh, NC had
one of these typetrains and the special printer to use it on,
since logics were occasionally produced by the Tools and Test
Equipment department where I worked.
There was a flowcharting program produced by the old Applied
Data Research company, one of the earliest ISV's, called
Autoflow. It produced flowcharts using normal EBCDIC characters.
When making boxes, it just used hyphens for horizontal lines,
OR-bars for vertical lines, and plus-signs for all corners. Each
flowchart "page" was printed onto two consecutive pages of
standard printer paper, so they came out 22 inches long. I wrote
a program to reformat the output from Autoflow using the special
sideways type-train for logics. This saved paper, and made the
flowcharts more compact. It even selected the "corner" graphic
characters to substitute for the plus-signs based on the
horizontally- and vertically-adjacent characters.
Alas, I have no sample printouts from this, I'm afraid.
IBM had its own flowcharting program, too, but not nearly as
"smart" as ADR's Autoflow, which could flowchart programs written
in a variety of languages, including Assembler. An IBM program
that was supposed to do this was not very good. It just drew the
right shape box around the text of each line of code, and made
extensive use of on- and off-page "baloon" connectors to tie the
flowchart together. Autoflow, on the other hand, used sophistical
algorithms to detect the true structure of a program, and then
diagrammed it in a way much like what you'd expect a human
fiagrammer to do, with minimal cross-page connections. I was able
to use it to help me figure out a lot of uncommented assembler
code I had inherited. It was quite brilliant. I gather it was one
of the first programs ever to receive a patent. That was quite
rare in those days.
Al Kossow
wrote:
IBM 360 software documentation is full of those.
www.spies.com/aek/pdf/ibm/360/Y28-6614-4_utilitiesPLM.pdf
for example.
arargh3...@now.at.arargh.com
<ru...@holsclaw.nyet> wrote:
<snip>
> There was a flowcharting program produced by the old Applied
>Data Research company, one of the earliest ISV's, called
>Autoflow. It produced flowcharts using normal EBCDIC characters.
>When making boxes, it just used hyphens for horizontal lines,
>OR-bars for vertical lines, and plus-signs for all corners. Each
>flowchart "page" was printed onto two consecutive pages of
>standard printer paper, so they came out 22 inches long. I wrote
>a program to reformat the output from Autoflow using the special
>sideways type-train for logics. This saved paper, and made the
>flowcharts more compact. It even selected the "corner" graphic
>characters to substitute for the plus-signs based on the
>horizontally- and vertically-adjacent characters.
>
>Alas, I have no sample printouts from this, I'm afraid.
If I can find it, I do have a sample of one. IIRC, the chart was of a
program called 'TEXT360'.
>
<snip>
stanislav shalunov
Are you talking about something like the diagrams in the RFC series?
(A fairly complicated---and important--example is Figure 6 on page 23
of RFC 793, <URL:http://www.rfc-editor.org/rfc/rfc793.txt>.) RFCs are
still produced, and much used by Internet protocol implementors,
today.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
Letters in this message are closer than they appear.
Geoff Lane
Compiler Construction
David Gries
Wiley, 1971
ISBN 0-471-32771-9
Was printed from camera read copy printed on a chain printer attached to an
IBM 360/65. Almost all of the text, tables and diagrams use only the text
and graphics characters available on the printer chain.
--
Geoff Lane
Chris Hedley
You make it sound like a thing of the past! I still use that method
to do my family tree diagrams. I've frequently thought about using
alternatives for better æsthetics or automatic generation, but so far
none have offered the same amount of flexibility.
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
Currently playing: random early '80s radio stuff
http://www.chrishedley.com - assorted stuff, inc my genealogy. Gan canny!
Andrew McLaren
documentation continue to use ASCII-art diagrams (or should I say EBCDIC
art) to this day. One sample picked at random:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DSNAG0F5/1.2.3.1?
SHELF=&DT=19990716185412
Okay that's not a very elaborate diagram, but there are many many more in
the 1,000s of pages of mainframe doco online.
Cheers
Andrew
Joe Morris
>In article <3F2C8086...@airmail.net>, Larry__Weiss <l...@airmail.net>
>wrote:
>> I have a memory of seeing very sophisticated technical diagrams in old
>> documents that employed simple text characters. Even flowcharts were
>> produced using just the character set of available character-only
>> printers. Does anyone else here remember this sort of documentation?
>> Has anyone preserved some samples?
>IBM 360 software documentation is full of those.
So were the hardware documentation kits for IBM mainframes. All of us
here who inhabited the computer rooms in the mainframe era are (all too)
familiar with the herds of wheeled carts carrying the oversized binders
containing the printouts (collectively called "logics") with the
information used by the CE in installing and maintaining the system.
Line-printer graphics were used to produce logic charts (data and/or
control flow), but they also were used for other purposes such as
giving the physical layout of the SLT and SMS cards to locate the
various jumpers that had to be set.
Well into the S/360 era graphic hardcopy output was either unavailable
or expensive, so line-printer flowcharts were commonly used to document
program flow.
For a more current usage:
The RFC documents are published in flat ASCII, including the graphics
showing the layout of data areas. See, for example:
http://www.isi.edu/in-notes/rfc1972.txt
Joe Morris
Larry__Weiss
> According to Larry__Weiss <l...@airmail.net>:
> > I have a memory of seeing very sophisticated technical diagrams in old documents
> > that employed simple text characters. Even flowcharts were produced using just
> > the character set of available character-only printers. Does anyone else here
> > remember this sort of documentation? Has anyone preserved some samples?
>
> You make it sound like a thing of the past! I still use that method
> to do my family tree diagrams. I've frequently thought about using
> alternatives for better æsthetics or automatic generation, but so far
> none have offered the same amount of flexibility.
>
I wouldn't be surprised if this technique was becoming extremely rare
for large documents. It's very labor intensive when done manually (takes
lots of attention and time to get everything lined up exactly, especially
when extensive edits are required involving insertions), and I'm not aware
of any automated way to generate them that is available on the current
desktop machines in use today.
The flexibility aspect is a strength and also the portability. If there
were, say, VISIO diagram --> text-only diagram convertors that did a good
job, then we could have the best of both.
Chris Hedley
> I wouldn't be surprised if this technique was becoming extremely rare
> for large documents. It's very labor intensive when done manually (takes
> lots of attention and time to get everything lined up exactly, especially
> when extensive edits are required involving insertions), and I'm not aware
> of any automated way to generate them that is available on the current
> desktop machines in use today.
It is quite labour intensive; in fact it's nothing short of a complete
bastard to get things lined up when there's embedded HTML tags all over
the bloody place!! But that's all part of the fun.
> The flexibility aspect is a strength and also the portability. If there
> were, say, VISIO diagram --> text-only diagram convertors that did a good
> job, then we could have the best of both.
True. You never know, it might happen (maybe it already has), I think
that plain ASCII is one of those things that'll never quite go away.
jsa...@ecn.ab.ca
: In article <3F2C8086...@airmail.net>, Larry__Weiss <l...@airmail.net>
: wrote:
: www.spies.com/aek/pdf/ibm/360/Y28-6614-4_utilitiesPLM.pdf
: for example.
The book "Microprogramming: Principles and Practices" by Samir S. Husson
(Prentice-Hall, 1970) has some examples in it as well; that book might be
found in some college libraries.
John Savard
Anne & Lynn Wheeler
> If I can find it, I do have a sample of one. IIRC, the chart was of a
> program called 'TEXT360'.
a map of the internal network was produced in a similar manner (until
it got too cumbersome). it wasn't geographic representative ... just
each node and connections. I have hardcopy of one dated april 15,
1977.
I fied search engine on HIPO and flowcharts .... but the references I
ran across were done with graphics. all the autoflow references seem
to be current. searching autoflow and 1403 (mainframe printer used to
produce the charts) didn't come up with example.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Anne & Lynn Wheeler
> Are you talking about something like the diagrams in the RFC series?
> (A fairly complicated---and important--example is Figure 6 on page 23
> of RFC 793, <URL:http://www.rfc-editor.org/rfc/rfc793.txt>.) RFCs are
> still produced, and much used by Internet protocol implementors,
> today.
not text ... all html ... my rfc cross-index page ... also pointed to
by the rfc-editor's resources page
http://www.garlic.com/~lynn/rfcietff.htm
produced by a knowledge based application that has things recorded
in patterns .... including patterns representing the stnadards
process. STD1 used to include the following in section 6.10:
file:///d:/users/http/rfcietf.htm#obsol
... aka RFCs that were still listed as standards but had been obsoleted.
RFC summary example:
3576 I
Dynamic Authorization Extensions to Remote Authentication Dial In
User Service (RADIUS), Aboba B., Chiba M., Dommety G., Eklund M.,
Mitton D., 2003/07/30 (30pp) (.txt=70027) (was
draft-chiba-radius-dynamic-authorization-21.txt)
clicking on the ".txt" field retrieves that actualy RFC. clicking on
the RFC number brings up the keywords for that RFC. Clicking on any of
the keywords, brigns up a "keyword->RFC#" list for that keyword.
An example of text-based diagram extracted from ien-166 and used in
posting for thread "Difference between NCP and TCP/IP protocols":
http://www.garlic.com/~lynn/internet.htm#27
http://www.garlic.com/~lynn/2000.html#72
the technology is similar to what I used for managing the merged
glossar & taxonomy
http://www.garlic.com/~lynn/index.html#glossary
Anne & Lynn Wheeler
> produced by a knowledge based application that has things recorded
> in patterns .... including patterns representing the stnadards
> process. STD1 used to include the following in section 6.10:
> file:///d:/users/http/rfcietf.htm#obsol
oops, thots strayed for a minute and clicked the wrong thing
http://www.garlic.com/~lynn/rfcietf.htm#obsol
Neil Franklin
> According to Larry__Weiss <l...@airmail.net>:
> > remember this sort of documentation? Has anyone preserved some samples?
>
> You make it sound like a thing of the past! I still use that method
> to do my family tree diagrams.
Yup. Still in use. Such as in this technical lecture on programmable
logic, that I made a few monts ago:
http://neil.franklin.ch/Articles/20030530_LUGcamp_Open_Hardware.html
Note: Text is in german, so you most likely will not understand it, so
just go looking at the graphics.
One example graph from there, the internal structure of an PROM chip:
------
(P)ROM Ausschnitt, 3 Adressleitungen, 2^3=8 Adressen, 4bit breit
I = Inverter, ergeben ~A0, ~A1, ~A2, ...
o = verbunden, - = keine Verbindung
U = UND um Adresse zu dekodieren, pro Adresse eine Zeile
... A2 A1 A0
|__ |__ |__
| | | | | |
| I | I | I Produktterm:
| | | | | | | | | |
..-----o-----o-----o--U - 0 ---..--x--x--x--x- alle ~An UND = 0
| | | | | | | | | |
..-----o-----o--o-----U - 1 ---..--x--x--x--x- nur A0 rest ~ UND = 1
| | | | | | | | | |
..-----o--o--------o--U - 2 ---..--x--x--x--x- nur A1 rest ~ UND = 2
| | | | | | | | | |
..-----o--o-----o-----U - 3 ---..--x--x--x--x- A1 UND A0 rest ~ = 3
| | | | | | | | | |
..--o--------o-----o--U - 4 ---..--x--x--x--x- nur A2 rest ~ UND = 4
| | | | | | | | | |
..--o--------o--o-----U - 5 ---..--x--x--x--x-
| | | | | | | | | |
..--o-----o--------o--U - 6 ---..--x--x--x--x-
| | | | | | | | | |
..--o-----o-----o-----U - 7 ---..--x--x--x--x- x = Datenbits
| | | | | | | | | | = o oder -
: : : : : : : : : :
| | | |
O O O O ODER der Bits
| | | |
.. D3 D2 D1 D0 Daten Ausgang
------
This also shows embedding ASCII graphs into HTML webpages. Which
ensures that the method will stay alive.
You may also want to look at the alt.ascii-art group, to see many
youngsters taking this up, although mostly for visual art, not for
diagrams.
> I've frequently thought about using
> alternatives for better æsthetics or automatic generation, but so far
> none have offered the same amount of flexibility.
Yes. I find I can ASCII sketch in my tried and trusted editor a lot
faster than starting up some paint program and pushing around pixels.
I suppose some vector graphics program would be better, but I have
none, and dislike the closed cinary file such programs make.
--
Neil Franklin, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Blacksmith
- hardware runs the world, software controls the hardware
code generates the software, have you coded today?
Geoffrey G. Rochat
I've got the Rhode Island Computer Museum's collection of IBM Series/1
documentation in my dining room where I'm sorting through it, and it's full
of that stuff. Even schematics - printed by a chain printer so nothing
quite lines up. It's not on line yet, but I will eventually be making
copies of all of it to send off to Al Kossow (Why, thank you Al! <grin>) so
that he can put it up on his site.
Anne & Lynn Wheeler
> I've got the Rhode Island Computer Museum's collection of IBM
> Series/1 documentation in my dining room where I'm sorting through
> it, and it's full of that stuff. Even schematics - printed by a
> chain printer so nothing quite lines up. It's not on line yet, but
> I will eventually be making copies of all of it to send off to Al
> Kossow (Why, thank you Al! <grin>) so that he can put it up on his
> site.
the early 360 principle of operations manual was printed using
standard processes and the instruction syntax diagrams had solid lines
in the boxes.
architecture moved the "red book" into script (on cp/67/cms
... initially supported run-off-like "dot" commands but circa 1970 or
so, gml was added to script ... aka precursor to sgml, html, xml,
etc). The "red book" came from it being distributed in red 3-ring
binders ... and standard cms script was used to print it on 1403
printers where the use of standard ("TN") characters no longer
resulted in solid lines for boxes, etc.
The red book had all the really interesting engineering, background,
compatibility and justification details .... interspersed with the
principle of operations "text". specification on the script command
would either print the full red book .... or just the pinciple of
operations subset ... for publication.
as more and more documentation was converted to the cms script-based
infrastructure, there were more manuals and publications that lost the
solid connected lines in boxes and other diagrams.
this continued pretty much up until the introduction of the 3800
printer where script got the ability to specify characters that would
produce solid connected lines for boxes. in some respects, script/gml
font specification feature originated for support of 2741/selectric
typeballs (i.e. possible to switch typeballs on 2741 terminal to get
different character sets .... like apl (I actually still have 2741 apl
typeball in top drawer of my desk).
cp/67, cms, script, gml, internal network, virtual machines, lots of
text editoring, compare&swap instruction, port of apl\360 to cms and
support for virtual memory, etc ... all originally the product of the
cambridge scient center, 4th floor, 545 tech sq. misc. refs:
http://www.garlic.com/~lynn/subtoptic.html#545tech
Russ Holsclaw
>
> So were the hardware documentation kits for IBM mainframes.
All of us
> here who inhabited the computer rooms in the mainframe era are
(all too)
> familiar with the herds of wheeled carts carrying the oversized
binders
> containing the printouts (collectively called "logics") with
the
> information used by the CE in installing and maintaining the
system.
> Line-printer graphics were used to produce logic charts (data
and/or
> control flow), but they also were used for other purposes such
as
> giving the physical layout of the SLT and SMS cards to locate
the
> various jumpers that had to be set.
Right, these logic diagrams were called "ALDs" for Automated
Logic Diagram. The diagrams were produced by software that
inputted a full set of "logic rules" that dictated the design.
Of most importance was the fact that the ALDs used by CE's in the
field were slightly simplified, in that they mostly showed logic
blocks that resided on the same card as a unit, rather than
dragging the CE through the circuitry of each individual card.
In other words, they were intended to help the CE isolate cards,
not individual logic circuits. So, the cards that did high-level
functions were reduced down to a small number of rectangles, and
internal card connections were rarely shown. Still, a CPU often
had dozens of logic binders even at that level of abstraction.
When we installed Engineering Changes on the machines, the change
materials included updated ALD pages, so the logics were kept in
sync with the hardware.
Charles Richmond
schematics made up entirely of ASCII characters. They use things
like:
----/\/\/\/\----
for a resistor and
----()()()()-----
for a coil, or some such. I need to Google for a page that
descibes this...I am sure it is still going on.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Charles Richmond
it is hard to read...why did *no* one ever re-do the book using
more modern tools???
Charles Richmond
>
> Larry__Weiss wrote:
> >
> > I have a memory of seeing very sophisticated technical diagrams in old documents
> > that employed simple text characters. Even flowcharts were produced using just
> > the character set of available character-only printers. Does anyone else here
> > remember this sort of documentation? Has anyone preserved some samples?
> >
> ISTR that over in <comp.sci.electronics>, they sometimes post
> schematics made up entirely of ASCII characters. They use things
> like:
>
> ----/\/\/\/\----
>
> for a resistor and
>
> ----()()()()-----
>
> for a coil, or some such. I need to Google for a page that
> descibes this...I am sure it is still going on.
>
newsgroup starts with "comp"... Anyway, these ASCII schematics
are *very* useful so that schematics can be posted in a "text
only" newsgroup.
Larry__Weiss
> cp/67, cms, script, gml, internal network, virtual machines, lots of
> text editoring, compare&swap instruction, port of apl\360 to cms and
> support for virtual memory, etc ... all originally the product of the
> cambridge scient center, 4th floor, 545 tech sq. misc. refs:
> http://www.garlic.com/~lynn/subtoptic.html#545tech
\____ t?
Brian Inglis
Still produce them when I need simple diagrams, as they're faster
to draw and more portable than the output of any graphic drawing
product, until PNG gets more widespread support.
These were at the low end of the totem pole, line printer
pictures were at the high end: google rec.arts.ascii for current
variations and pointers.
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
Lon Stowell
> I have a memory of seeing very sophisticated technical diagrams in old documents
> that employed simple text characters. Even flowcharts were produced using just
> the character set of available character-only printers. Does anyone else here
> remember this sort of documentation? Has anyone preserved some samples?
IBM used this for several machines from electronic to relay logic.
We wuz told it was so the books could be printed on a normal line
printer. Not that hard to get used to.
Can't remember if an output had an "X" to indicate inversion or
if it was just physically placed on the lower part of the logic
box.
There wuz several different strategies even for graphic
descriptions of logic, circles, circles with small circles,
etc. until mil std came out.
Larry__Weiss
> Are you talking about something like the diagrams in the RFC series?
> (A fairly complicated---and important--example is Figure 6 on page 23
> of RFC 793, <URL:http://www.rfc-editor.org/rfc/rfc793.txt>.)
>
Yes, thanks! I've copied some examples from that RFC here
(including that Fig 6).
RFC: 793
TRANSMISSION CONTROL PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
September 1981
==================================================================
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Application Level
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
Protocol Relationships
Figure 2.
==================================================================
TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
Note that one tick mark represents one bit position.
Figure 3.
==================================================================
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
==================================================================
Heinz W. Wiggeshoff
"Charles Richmond" <rich...@ev1.net> wrote in message
news:3F2D7A0D...@ev1.net...
> Yes, I have a copy of the book. The type is perhaps clever, but
> it is hard to read...why did *no* one ever re-do the book using
> more modern tools???
Amen. (I would have posted this, but you beat me to the punch. B-)
jmfb...@aol.com
Larry__Weiss <l...@airmail.net> wrote:
>stanislav shalunov wrote:
>> Are you talking about something like the diagrams in the RFC series?
>> (A fairly complicated---and important--example is Figure 6 on page 23
>> of RFC 793, <URL:http://www.rfc-editor.org/rfc/rfc793.txt>.)
>>
>
>Yes, thanks! I've copied some examples from that RFC here
>(including that Fig 6).
Oh, is that what you're talking about. TOPS-10 stuff was full
of it. The monitor tables were done that way; all of our specs
were done that way. Anything that we documented but couldn't
justify using the art group was done that way.
What I can't remember is what form of output Dick Helliwell's stuff
had. I think the thingie was called SUDS and it may have run on
System #525, later converted to KL1025. Serial number may be off
by one. It was hardware's computer system on MR1-2, down the hall
from us and they used the system to develop hardware designs.
At a guess, I suspect that SUDS would take EE flavored commands
and convert them into printable ASCII.
/BAH
Subtract a hundred and four for e-mail.
Tony Lima
<l...@airmail.net> wrote:
>I have a memory of seeing very sophisticated technical diagrams in old documents
>that employed simple text characters. Even flowcharts were produced using just
>the character set of available character-only printers. Does anyone else here
>remember this sort of documentation? Has anyone preserved some samples?
If memory serves, there was a product called Clear that
produced flow charts for xBase programs. I believe the
first version or two did them in text (although they may
have used the PBM PC extended ASCII character set). - Tony
(who is quite sure that if his memory is faulty a few folks
here will let him know)
--
Tony Lima /"\ ASCII ribbon campaign
\ / against HTML mail
X and postings
/ \