| gabriel rosenkoetter on Wed, 2 Apr 2003 13:06:11 -0500 |
|
On Wed, Apr 02, 2003 at 11:56:14AM -0500, William H. Magill wrote:
> Nominally (hopefully) you would get "card images" on tape (80 char
> records, blocked by some thing useful like 100 or 1000.)
That's humor for those of you not familiar with what blocking
records means. (Blocking 80 to something other than a multiple of 80
is routine incompetence, and it's accepted that you must know the
blocking factor of a given tape if you have any hope of reading it.
Encoding this in a standard way, or just always blocking in a
standard way, seems to be too far-fetched. And this applies to disk
files too, especially when those are virtual tape on, say, an EMC
disk array.)
We still use reel to reel (9 track I think, but I wouldn't swear to
it) to get data from certain clients into our Z80 running Z/OS
(recently transitioned from an S/390 running... well, System 390). I
think we've even got a rack of local reel to reel tapes. I don't
know how often or for what they're used (I'm just the Unix sysadmin).
And I don't work for a government agency, I work for a marketing
database firm. Point is, they're still very much out there.
We've also got an AS/400 for sale if anybody's interested...
> Many of these "tabulating machines" made their way into
> Carnival side show wagons and Boardwalk "fortune tellers"
> booths...(really IBM 083 card sorters).
Heh. I did not know that. Is that urban legend or proven fact?
(It seems like a perfectly reasonable re-use in either case...)
> Of course getting a "card reader" for a PC is not unlike getting a 9
> track tape machine... not cheap. However, "data ... eof" is part and
> parcel of Unix / linux and would read without (too many) "problems."
As has already been pointed out, Istr a project mentioned on /. to
read punch cards by way of a scanner. In principle, it's not too
difficult (remove hanging chads ;^>, throw a sheet of black
construction paper behind the card, process 1s and 0s appropriately).
bcd from the BSD games collection (same binary as morse and ppt,
which spits out to "paper tape") may be of some use, and may be
totally useless. The name scares me a bit ("binary coded decimal?"
You lose if what you're getting is 7-bit ASCII... and ph34r EBCDIC).
The man page references:
ISO 1681:1973: Information processing--Unpunched paper
cards--Specification.
ISO 1682:1973: Information processing--80 columns punched paper
cards--Dimensions and location of rectangular punched holes.
> I don't want to think about what this might mean, but it might turn out
> to be your best bet --- IF they mean that they will put up a "data set"
> someplace that you can dial in and retrieve. (Don't count on FTP
> access, but you might luck out!)
I agree that this is probably dialin, and it probably puts all the
onus of getting a working terminal on your end on YOU. minicom
*might* be able to do this. But you'll probably need to know how to
interact with whatever mainframe's on the other end of the wire
(for example with an IBM mainframe, write JCL jobs to retrieve data
sets, so forth).
> (running mean-green-screens the last time I used it.)
What, no amberchrome? Looks like the public library wins again!
--
gabriel rosenkoetter
gr@eclipsed.net
Attachment:
pgpG9LKQw9g6m.pgp
|
|