Archive for the ‘cobol’ Category

yet another work rant

Friday, November 3rd, 2006

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.

work rant

Tuesday, October 31st, 2006

i hate working on code written by consultants. why? because they don’t always know what the fuck they are doing. nor does anyone else know what the fuck they did.

the problem i face is the necessary assumption that what i was given as a base was functioning correctly. i fear that assumption is, unfortunately, false.

it doesn’t help that the design of these host systems sucks. really, really just sucks. why, for instance, create a spouse segment, and then store the spouse information in the “additional insured” segment? and if you decide to treat a spouse just like a second insured, why not get rid of the obsolete record layouts? fer fuck’s sake, why is deleting so god damn difficult? isn’t that what versioning tools are for? to retrieve stuff that might have been deleted if you find you still need it?

perhaps i’m anal. perhaps it’s because i learned from anal people. but well-structured code is much easier to figure out. consistency. spacing on the lines. neat and tidy. so much easier. and jesus, why is every freaking working storage variable an 01 level? did they just want to make initialization more of a pain?

i hate this. i wish i could have written it from scratch. there are vast swaths of commented out code. why? why? for me to make any sense of what’s going on, i have to clean it up. waste of my time, frankly.

ugh, i sound like one of those sticklers for standards. but, frankly, if you aren’t going to be the only one working on a module, they help.