- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I don't get it.
Admin
WTF? People actually programmed like that?!
Admin
This post is bogus.
Everyone knows that computers where not invented until 1996 along with the Internet.
Admin
engfeh[:^)]
Admin
So this is a program that simulates a user pressing the actual keys to run another program?
Maybe it's a test driver, if thats the case I don't see whats wrong with it.
Admin
Well obviously anyone who doesn't get this is a moron, I mean I get it too because I am so elite, and if you don't get it well tough luck, guess you weren't as elite as you thought you were!
... to be ahead of some Mr. Anonymous :P
Admin
Where's the WTF?
This is how one programmed those days. Luckily, IT has developed since.
-- Daniel
Admin
I don't get it...
Admin
I take it that RS/6000 is some sort of database and that there is already a way to query the RS/6000 directly? Is there an RS/6000 equivalent of OleDb, JDBC or for that matter, SQL ?
So to translate for modern programmers, they are doing the equivalent of the following:
Is this basically what they're doing? If so, how horrifying.
Imagine doing this today using a modern programming language and database (Java/Oracle, C#/Sql Server, etc.) Yes...comprehension...now the pain sets in.
Admin
Thanks! I've added that to the post for some clarification [:D]
Admin
"I take it that RS/6000 is some sort of database and that there is already a way to query the RS/6000 directly?"
RS/6000 is a RISC-based minicomputer that normally runs IBM's AIX flavour of UNIX -- the name has recently been changed to pSeries, and IBM seems to prefer Linux these days.There may or may not be a database present -- if there is, it's probably DB2.
Admin
No, actually the RS/6000 is a type of IBM mainframe.
This type of thing isn't surprising. Often there is a mainframe program that was written so long ago that nobody knows how it works or how to modify it. So, rather than doing anything to the mainframe program, the programmer figures out the minimum amount of work to get the data out of the mainframe. If the pointy haired boss has a choice between hiring a mainframe programmer ($$$) or having a young programmer write a cheap hack, guess what he will choose?
Admin
Sorry, I thought I was signed in.
Admin
You are, of course, on drugs. An RS/6000 is a workstation, and there were tons of them around in the good old days of 1993.
As far as "people used to program like that?", I got news for you: people still do. This has nothing to do with this being "old", I could quite easily see people doing something stupid like this in any programming language. Actually, although it looks nasty, it's really no different than any other method to exec an external program to do something... perhaps the amount of moving parts here make it more brittle (what if the input command changes?), but it's programatically equivalent to doing something like exec'ing ncftp from within a Perl script.
Admin
Admin
FSCKING FORUM! Where'd what I type go? AAAAAAAAAAAAAGH! That's twice I lost it -- once by clicking preview, and once by posting. "telligent systems" can bite my big white hairy ass!
Anyway, back in 1993 I was admin of an RS/6000, and mainframe it wasn't. A box roughly twice as big in all dimensions than a tower PC, ran on some sort of RISC CPU (that's what the R stands for, I believe), used AIX, etc. We shared it with about 60 users (via glass TTYs), and it only went down once -- the PSU blew at 10:30 one night, the IBM engineer was on site with a replacement inside 45 minutes, and we were back in business before midnight...
Admin
I was still half right. It is an IBM!
Yes, that is exactly the point.
Admin
This isn't that far removed from 'fish', which gives you access to remote files by (effectively) behind-the-scenes typing into an ssh shell prompt (which I thought was quite clever).
Admin
Razzie, don't be an imbecile. There's a difference between reading elegant and obvious code, and reading cryptic commands that don't include any indication of what they do.
For example: Someone would be a moron if they didn't understand the command line "LIST FILES ALPHABETICALLY", but not if they didn't understand "ls * | sort". One imparts obvious meaning (assuming the viewer can read English, of course), the other can only be learned through experience.
Admin
I was being sarcastic, read the haskell thread :P
Admin
Actually, MS Integration Server (for example) does similar things with as/400 and mainframe programs even today. That sometimes is the only way to integrate with those, many times single-user too, programs.
Admin
that's not -clever-, that is -practical-. quite a difference...
Admin
This WTF reminds me of something I heard about the Y2K problem. In some cases, it was considered to be too hard to update the mainframe code to be Y2K ready. Instead, the mainframe was "wrapped" with physical boxes that would check the inputs and outputs, and whenever a date was seen, a conversion would be done.
So the non-Y2K compliant code would be able to output 19105 as the year, but everything interfacing with the code would see 2005. Problem solved . . . please pay no attention to the mainframe behind the curtain!
Admin
Oh, now I see the WTF! The keyboard buffer is only 15 characters, so while the first command would work, the second one won't!
Admin
Back in '86, there were two ways to programatically get text onto the screen. You could make interrupt calls, or you could write directly to video memory. Of course, if you wanted any sort of speed, or colours, writing to memory was the way to go.
To facilitate this, you use the following C #define
#define SCR (((*)unsigned[80])0xB80000000)
which defines a pointer SCR to point at segment B800, which is where video memory resides. To put an uppecase white 'A' on a green background at line 1, column 3, one simply
SCR[1][3] = 0x2F00 | 'A';
Of course, because CGI memory was not dual-ported, doing this would produce snow on the screen. To prevent this, one polled a particular hardware port that went nonzero when the CRT was performing a vertical retrace.
And this - mind you - was not my own weird creation. It was the only way to make a PC do anything worthwhile. Everyone did it.
Admin
Does anyone remember something called a FOSSIL driver? Or even a BBS that wasn't on a web page? Get off my lawn, you damn kids!
Admin
Don't laugh. I encountered a UNIX app in 1998 that ran in batch mode by starting up the curses-based front end and sending keystrokes down the pipe. Thankfully, by year's end, the app was upgraded with a batch task facility - stick the parameters in a table (with a task name) and call the app from the command line with the batch task name as an arg.
Of course the 'C' code surrounding that app was an incredible WTF, with hard coded message strings duplicated twice:
printf("The message");
fprintf(LOGFILE, "The message");
ad-infiitem. When it came time to rip out the pipe-writting stuff and replace it with database writes, I ended up re-writing it in Perl, even though I had 11 years of 'C' experience and only 1.5 of Perl, and that was read-only. Why? The 'C' was really wtf. I should see if I can dig up some of that code. Man, did that suck.
Admin
I work for a company that makes a specialised database engine, think XML
database rather than RDBMS and you are on the right lines, just we did it 20
years ago (memex.com).
Until very recently, if for some reason a client app wanted to get the contents of
an entire table (There were reasons for doign this, client side lookup tables/picklists
for example) then the fastest way was not to do select * but to run a remote command
to do a database-dump, then load that onto the client and parse it. This coudl be
100 times faster. This was down to having to make many 'fetch' calls with the overhead for each.
We have a slightly better way now - but thats beside the point.
The WTF I saw (remember we can search) was the person who has seen this code but only needed one record from a database, therefore shelled a dump-db command on the server, then called a shell script to grep out the record he wanted to another file, then read in that file!
Admin
err, expect anyone?
Admin
"ls * | sort" might not be as patently obvious, but if you expand it out it says basically the same thing... "list all files, then sort (alphabetically)"
Admin
Wow, fond memories. Indeed. -- Of a $300 14.4kbps modem going south after a thunderstorm. Heh, I remember when no one had the "coveted" 16550 UART-based serial card.
Going back to the CGA memory direct write thing: I wished I had known about the "wait for retrace" issue. I used to write games in text mode (who wanted 4 color graphics?), and got around the snow problem by not page flipping, like a friend of mine had done. (Of course, this was all done in QuickBASIC) I had no idea the garbage on the screen was caused by memory access issues, Of course, at the time I was only in the 5th or 6th grade.. [:P]
Admin
I don't think this really qualifies as a true wtf. So it's not great programming, but most of the time in the older systems this is all you really had to work with.
Admin
Admin
Stackey stackey! [:D]
Admin
Bullcrap. RS/6000 run AIX, a full-blown Unix.
They could have used any kind of shell script to deal with the file, or ftped it somewhere else.
Admin
Admin
What machine is this running on, a PC or the RS/6000?
If one assumes that the purpose of this was to process some RS/6000 data on the PC, it may be that there wasn't a file transfer or remote DB access API for the PC. And the PC-side file transfer program might have been a stand-alone that didn't accept command-line parameters -- that would have been quite typical of IBM. They were fairly ambivalent about PCs.
If memory serves, ODBC drivers were just beginning to be released in 1993, and they weren't very reliable. At least, the IBM ODBC drivers we had for the AS/400 weren't reliable.
Admin
Sigh .....
I should have included more info to begin with ... everyone has missed what I saw as the WTF point I guess.
The "if/elseif/endif" code was in dBase III+. The program filename was IVR236.PRG. If you typed IVR236 AAA at the C:> prompt, it would start dBase III, which would load IVR236.PRG and run it, making the string "AAA" available to the program as a parameter.
STACKEY, obviously, pushed keystrokes onto the keyboard stack, much like Sendkeys does. (Although it did it by stuffing the keyboard buffer in the BIOS. I believe STACKEY was written for DOS 3.1.)
Two facts made me say WTF when I found it. One, that the best scripting program that anyone could think of was dBase III. Really, guys! What's wrong with a BAT file?
Second, look inside one of the elseif sections. It starts ASTFT11, stuffs in a username, password, command, arguments, etc ... then it RESTARTS IVR236.PRG FROM THE BEGINNING WITH A NEW PARAMETER. WHY ???? If you're already in a script, why start over from the beginning??
Admin
I know you were being sarcastic, but apparently you didn't comprehend my text. I guess the English I used was too obfuscated.
Admin
I'm working on a project at the moment for one of the UK banks, basically the project is to build a new common interface to all their business functions, to simplify support for front end systems (internet banking sites, day traders etc)...
Basically, there are tons of old mainframes, with service wrappers upon service wrappers on top of them… somewhere underneath several service lays and a million lines of code is some old system written in COBOL
Some of the error messages we get back are great... like,
ERROR : xxxsome error messagexxxxxx Press F6 to continue.
And many other variations.
This is because, some of these mainframes have been kicking around since, well... long before i was born, and the only way to get the data is to grab screen text shots and read the values off of the captured text…
There is even an urban legend in the company about a mini-computer kicking around in a dark basement, which needs to do some job every 12 hours... To kick the job of a mechanical device wired to an alarm clock was made to simulate a finger striking the Enter key.. As to it's truth I don't know, but for some reason i find myself believing it.
The reason being, the grand children of the people who wrote the system have long since retired or died, and these machines seem to do some key functions.... like calculate the interest on everyone’s bank accounts, and various other things which if they didn’t do a large amount of the worlds money will stop moving... that kind of stuff... And no one has the balls to re-write it…
So alas, I have found myself looking at many examples of the above code thinking WTF!!!!! HOW!!! WHY!!! ARGHHHHHHHHHHHH, one developer melted when he was reading some screen grabbing code and someone knocked a glass of water over him..
Admin
Batch language is seriously limited, though I can see it should be sufficient for this job.
It needs to let the command interpreter run and receive the keystrokes before it goes on to the next phase. Having said that, it could run the command interpreter as a child process instead of exiting, though that would require a little more memory.
Admin
This fact came to me while driving home Friday. Yes .. shelling to dos to run STACKEY just stuffs the keyboard buffer. The actual command won't run until QUIT is encountered.
Thinking about the environment now, I think that memory was at a real premium. This was used under plain DOS, not Windows. There was only a maximum of 640K to deal with; dbase III+ probably didn't swap itself out, so all that memory was unavailable. I don't think that the ASTFT11 would have functioned as a child process of dBase III+.
Admin
Nope. The IBM RS6K machines were AIX-based, AIX being IBM's take on the UNIX theme. All I have ever come across were meant to be used as workstations.
Apart from the sytem administration, which—compared to other UNIXoids—was one big fat "WTF???????", they were quite pleasant to work with. At the time.