test-drb June 2000

test-drb@ccmp.vtda.org

160 participants
580 discussions

Composing on paper, Green-bar, hardcopy output, card decks (L ong)

by mmcfadden＠cmh.edu

>From the Jargon file greenbar: n. A style of fanfolded continuous-feed paper with alternating green and white bars on it, especially used in old-style line printers. This slang almost certainly dates way back to mainframe days. This makes me feel ancient. The green bars were 1 inch wide which was 6 lines normal or 8 lines compressed. About 1979 I remember when I wrote a talk for a microbiology conference on my VT52 terminal. I then printed it out on greenbar which was used to prompt me during the talk. The greenbar proceeded to unfold down the front of the podium all the way to the floor. My boss was kind enough to indicate that the talk was really written by the computer. One problem with greenbar was that you had to turn it over if you wanted to print pictures or banners on the paper. Very long fiber paper, some of the cheap stuff was kind of like newspaper greenbar. I still have several cases of it, the fancy kind with printed line numbers. The nice thing about composing on paper was that once you wrote the same or similar thing several times by hand you decided to create a subroutine/procedure. Paper could be taken to the pool or outside, no electricity required. Composing on terminals was only practical when there were terminals available. Doesn't anyone remember coding sheets? If you are punching cards on an IBM 026 keypunch then any errors and the card was trash. The IBM 029 keypunch didn't actually punch the card until the end of the line, you could correct errors if you noticed them. Trash cards were useful for phone messages and notes. All of the JCL cards were usually a different color to allow the card decks to be split apart. I seem to remember pictures being drawn on the decks to allow the user to peer through the computer room window to see if your deck was due to be run soon. The best card run I ever saw was a 1976 run where the entire music list for the MU radio station was read in and then sorted by music type, performer, and title and then printouts produced. This happened on a Sunday when CPU time was free on the IBM 370 model 158 due to system testing. 12 boxes of data cards were read in and then stored on 9-track tape. Best input output/setup was in 1970 at CMU where the cards were read in and then output printed down a long series of sloped tables, each user got <10 minute response, they had a traffic light set up in the IO room. RED = system down, GREEN = system up, YELLOW = use at your own risk. They had a camera and speaker watching the printer to tell the users to change the paper on the printer. Worst setup was MU Computer Sciences where you turned in the cards and got back output in 24 hours. Many times with message CPU time exceeded and no output. Mike Coder from the dark ages

24 years, 6 months

Free stuff!

by Marion.Bates＠dartmouth.edu

Hey -- Been housecleaning recently. I have several machines and some parts available to anyone who can come pick them up -- I'm living in Jacksonville, FL for the summer. Apple IIc and power adapter (works) Zenith 286 laptop (works) Apple IIGS (powers up, but I seem to remember it having some weird intermittent error message) Magnavox monochrome Computer Monitor 80 (works, small and lightweight, good for a testing bench?) Mac Plus with power supply problem, rest of it works 2 internal SCSI hard drives (230 and 260 MB), both worked last I checked 800k internal Mac floppy drive (dunno if it works) 400k external Mac floppy drive (dunno if it works) ImageWriter II (works, good cosmetic condition) Dead Apple Newton 100 with some accessories, manuals, etc. -- I think I fried something when attempting to resolder the loose audio wire Mac SE/30 (works, but if you take this, you are required to take the rest, too. ;-) And OT: some other electronic thingies, like a dead Sony Bookman and a Sega "simon says" game, if your tastes are that eclectic. Please email off-list for details, directions, etc. Thanks, -- MB

24 years, 6 months

Programming on Paper

by dhquebbeman＠theestopinalgroup.com

> >Having a machine to interact with allows you to test your code on the spot > >and if you are writing in an interpreted language the error-checking the > >interpreter provides is a godsend for the coder. Why anyone would code > >without the interaction of the target machine is beyond me. > > I write perfect code, like Mozart it flows out in its final form to the > paper, and then to the system. I think the immediacy of interactive programming causes the programmer to tend to exit the design loop early, before the design has actually crystallized in the mind. Working with paper provides the slowdown needed to allow this crystallization to occur. And now that I think about it... ISTR a paper by someone at Purdue during the 60s, a paper exploring the value of interactive computing (timesharing), and it specifically referred to hypothetical systems so fast that the benefits of being able to immediately submit a design to test would be lost due to the programmer jumping out of the design loop too quickly. But, to each his own... as long as they're not working for me. -dq

24 years, 6 months

Programming on Paper

by ethan_dicks＠yahoo.com

--- Craig Smith <ip500(a)roanoke.infi.net> wrote: > Now that brings back some memories! 1969-72 at Franklin Pierce College > writing assembly and Fortran IV stuff for a 360/60 that we timeshared > with a bunch of other schools. I/O was a Teletype machine with a > cardpunch and reader hooked up to it. The good old days??? I don't think > so! You've never know true Hell until you drop a huge deck of cards > you've worked on for a week. Craig Didn't you learn the trick of drawing a diagonal line across the deck from front to back and left to right? It's not perfect, but you get most of the cards very close to their original positions the first time. You _were_ using a printing punch, right? -ethan ===== Even though my old e-mail address is no longer going to vanish, please note my new public address: erd(a)iname.com The original webpage address is still going away. The permanent home is: http://penguincentral.com/ See http://ohio.voyager.net/ for details. __________________________________________________ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/

24 years, 6 months

CDC 9" PA5N1F15 drive head locking. How?

by allain＠panix.com

> Can somene kindly tell me how to lock/unlock the heads on a CDC model > PA5N1F15 9" hard drive? Well, mine's a PA5G1M-20 (8.5x10x30", 9" platters) and it has its own auto-solenoid, which is easy to see. Just look on the platter case for a silverish round thing about 1.5". You should see it has a two wire connector and can be unscrewed from the mounting plate w/ a twist. > BTW, according to the label, this is an FSD drive - is this > the type of interface, or do I actually have an SMD drive? I belieeeeve that FSD's are just small SMD's. They seemed to have the same cabling as I recall. I couldn't find info on the PA5G1M anywhere so I found another number on the unit, "97150-340 FSD-340" and that seeked to a Seagate (guess they bought out CDC SMD's), here: http://www.mm.mtu.edu/drives/seagate/smd/st6344j.txt Here it says this FSD is a SMD. Perhaps your drive is there... first get the other model number. And we wonder why we subscribe to this list. John A

24 years, 7 months

Programming on Paper

by dhquebbeman＠theestopinalgroup.com

On June 17, Dave McGuire wrote: > On June 17, Mike Ford wrote: > > >Having a machine to interact with allows you to test your code on the spot > > >and if you are writing in an interpreted language the error-checking the > > >interpreter provides is a godsend for the coder. Why anyone would code > > >without the interaction of the target machine is beyond me. > > > > I write perfect code, like Mozart it flows out in its final form to the > > paper, and then to the system. > > Time for the hip waders, folks...it's getting deep in here. ;) Ok, here's a quote from one of my favorite computer scientists (Tom VanVleck, who might respond to being so identified as "Me? I'm just a programmer!"): : It is possible to write perfect, bug-free code. I've seen : it done, with no tool except a pencil. The essential ingredient : is a decision, by the individual programmer, to make the code : perfect, and not to release it until it is perfect. The quote is from an article of his on the Multicians web site: http://www.multicians.org/thvv/evolution.html I left my last job as a full-time programmer in 1990. A young Russian (who had written some of the software tools used in generating the control programming for Snowflake, the never-used Soviet space shuttle) was assigned to take over my work. In the month we worked together, we became friends, and so stayed in touch after I left. A couple or three years later, Dmitri and I were having lunch, and feeling a mood which had me wondering if I'd done the right thing in giving up programming, I asked him how much trouble he'd had with my code. "None." I probed deeper, knowing he was a good programmer and that he might have misinterpreted the thrust of the question. Right out, I asked him if he would character the severity and frequency of the bugs left in the extensive codebase I'd pushed. He stopped me, saying he'd understood me perfectly the first time, and said "No bugs in your code, Doug; you write best assembly language." If only I could have found an employer who felt that way! I was ultimately fired because the boss cared more about expeditiousness than about quality. That, and I think he tired of some of my behavioral quirks..... ;-) -doug q -doug q

24 years, 7 months

Programming on Paper

by jdarren＠ala.net

Sounds like you have a problem with anal retention. When I first started in programming (1977), we had to create *complete* technical design documents before a single line of code was written. This included technical specs, data diagrams, flowcharts, screen shots, etc... About 6 weeks ago, I was evaluating a fairly complex software project and and asked the engineer to provide a flowchart of how the application worked. He stated that he didn't see the value of a flowchart and that it would slow down the development process. In his opinion, it was much easier to just read the code. I was tempted to kick his ass, but decided the best way to handle this was to prove the value of proper documentation. So, I waded through his code, found the most complex module, and created a comprehensive flowchart of just that module. Now the fun part... I got the engineer, his supervisor, our VP of technology, and another non-technical co-worker (whom had never seen the project) together for a quick quiz. I gave the flowchart to the non-technical person and started asking the group fundimental questions like; "how many parameters are passed to and from the module", "what happens if an out-of-bounds value is passed", "what is the exact sequence of events when..." blah, blah, blah. Almost instantly, the non-technical person was able to answer the questions while the two engineers waded through hundreds of lines of code. Within 30 minutes, I was able to totally embarrass the engineer *and* his supervisor in front of the VP. Shoulda kicked his ass anyway... ;-) Steve Robertson <steverob(a)hotoffice.com>

24 years, 7 months

Programming on Paper

by steverob＠hotoffice.com

> I've met programmers who 'design' like that as well -- they > type in some code, then fiddle with loop limits, ands versus ors, > etc until the program gives the 'right answers' on the test values. Is it > any wonder some programs contain bugs.. When I first started in programming (1977), we had to create *complete* technical design documents before a single line of code was written. This included technical specs, data diagrams, flowcharts, screen shots, etc... About 6 weeks ago, I was evaluating a fairly complex software project and and asked the engineer to provide a flowchart of how the application worked. He stated that he didn't see the value of a flowchart and that it would slow down the development process. In his opinion, it was much easier to just read the code. I was tempted to kick his ass, but decided the best way to handle this was to prove the value of proper documentation. So, I waded through his code, found the most complex module, and created a comprehensive flowchart of just that module. Now the fun part... I got the engineer, his supervisor, our VP of technology, and another non-technical co-worker (whom had never seen the project) together for a quick quiz. I gave the flowchart to the non-technical person and started asking the group fundimental questions like; "how many parameters are passed to and from the module", "what happens if an out-of-bounds value is passed", "what is the exact sequence of events when..." blah, blah, blah. Almost instantly, the non-technical person was able to answer the questions while the two engineers waded through hundreds of lines of code. Within 30 minutes, I was able to totally embarrass the engineer *and* his supervisor in front of the VP. Shoulda kicked his ass anyway... ;-) Steve Robertson <steverob(a)hotoffice.com>

24 years, 7 months

Source for 88k systems?

by ryan＠inc.net

I'm looking for a 88k based system, preferably a Moto MVME. Anyone have one they'd like to sell to an 88k nut? Thanks, Ryan Brooks ryan(a)inc.net

24 years, 7 months

Texas Universites Surplus

by rigdonj＠intellistar.net

At 06:06 PM 6/12/00 -0400, Pat wrote: > >Another snag you might run into is the problem with funding agencies. >When I was at Carnegie-Mellon, I worked on a DoD-sponsored research >project. We never surplussed *anything*, and we never threw anything >away (at least, in the 2.5 years that I was there). The reason was, that >our funding agency (who had paid for all of our hardware) required that, >if we wanted to surplus something, we had to first go through a process to >put it on a list to offer it to other government agencies. Only after the >equipment had been on this list for several months, with no interest from >any other agencies, could we dispose of it. We were told at the time that >the estimated time from deciding to surplus something, until we were >actually permitted to do so (assuming that it was not snapped up by >another agency in the meantime), was at least 12 months. > I'd say that if they can surplus an item in only 12 months then they're doing extremely well. I see lots of surplus computers and test equipment and ALL of it has been in storage for at least 5 five years. Some of them have been in storage for over 10 years. For example, I just picked up two HP 9825s. Both of them have tags stating that they were removed from operation in 1995 and that they must be recalibrated or tested before being returned to service. Joe

24 years, 7 months

← Newer
1
...
27
28
29
30
31
32
33
...
58
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb June 2000