03 November, 2006

yet another work rant

can you sense a trend?

okay...so you want to have your name and address fields to be variable length. fine. that's nice, and thanks for putting a delimiter in there for me. however, you stupid fuckwits, if you then put the data into a fixed length table, you have done NOTHING but make coding more complex.

look at this shit:

* THE FOLLOWING IS THE NAME AND ADDRESS FIELD. IT IS VARIABLE
* LENGTH, WITH A MAXIMUM OF 25 CHARACTERS FOR THE NAME AND
* A MAXIMUM OF 5 LINES OF ADDRESS AND A 5-DIGIT ZIP CODE
* THE FIRST 4 LINES OF ADDRESS MAY HAVE A MAXIMUM OF 25 CHARACTER
* EACH, AND THE FIFTH A MAXIMUM OF 20 CHARACTERS. THE LAST
* CHARACTER OF THE NAME AND EACH ADDRESS LINE IS FOLLOWED BY AN
* ASTERISK. THE LAST NAME IS FIRST AND IS
* ITSELF FOLLOWED BY AN ASTERISK.
10 NAME-ADDR-AREA.
20 NAME-ADDRESS-X PIC X OCCURS 156 TIMES.
fine, fine. but, you see, if you want a variable length table in cobol, you need to write: OCCURS 1 TO 156 TIMES DEPENDING ON NAME-ADDR-AREA-LEN. or somthing akin to that. otherwise, you have a fixed length table. such as above. in which case, you'd have been better off just defining the fucking field names so i could do simple moves, instead of having to write a routine to unstring the fucking name from the address. more over, if you and moving variable length data into fixed fields, there is no point. a variable table takes up the maximum defined size in memory when you run the program. you aren't saving any space in working memory. you certainly aren't saving space in the database. the only time variable length tables are useful in cobol is when you have a variable length OUTPUT. otherwise, it's just a pain in the ass.

i hate these morons.

No comments: