I’ve already plowed through the source for 3 different programs, trying to follow the flow of data for a single process. I’m not even sure where the trail ends. All of these things are dependent on each other, and before I run any of them, I have to be sure there won’t be any adverse side effects. Is this what I face for the next year?!
{ 2005 12 19 }
jdredd5150 | 19-Dec-05 at 1:49 pm | Permalink
is it a constant running cycle, or like a nightly batch thing?
nephariuz | 19-Dec-05 at 3:11 pm | Permalink
It’s a monthly batch thing. One “job script” kicks off at least 4 others. I don’t think any of the items I inherited runs as a daemon/service.
The guy who did this before me was here for 20 years, and he was the only one who maintained any of this. You can imagine how gnarly these processes were allowed to become. Some of them haven’t been touched since they were auto-converted to 4GL from the original COBOL.
jdredd5150 | 19-Dec-05 at 3:19 pm | Permalink
haha! sweet. so how much development room do you have? can you pull the whole thing down into a development side, make your changes, run some test cycles through it all, and install it if no glitches show?
nephariuz | 19-Dec-05 at 7:57 pm | Permalink
That’s the scary part - these scripts have hard-coded settings that point to production servers even when they’re in the development environment. If I run them with the wrong settings… Bam, I’ve annihilated customers’ data. So I have to be really careful about *everything* I do.
There are going to be major rewrites to most of this stuff before I’m done, make no mistake.
jdredd5150 | 20-Dec-05 at 6:09 am | Permalink
whoah.. who the heck… that just seemes totally fucked up that there isn’t SOME sort of development deal. can’t you just pull everything over and just do a search for “ASSIGN” (i’m still assuming this is set up like COBOL) or whatever to find all of the file assignments and then just switch them over?
dude, i totally feel horrid for you. i can’t imagine not being able to simply test data. it’s great to know that your predecessor apparently never tested shit, or everything that he tested was in the production environment.
nephariuz | 20-Dec-05 at 11:27 am | Permalink
> whoah.. who the heck… that just seemes totally fucked up
> that there isn’t SOME sort of development deal.
Well, there is - most of the job (shell) scripts start off something like this:
$SYS = “prod”
#$SYS = “test”
case $SYS in
“test”)
export DBINSTANCE=dev
#etc…
;;
“prod”)
export DBINSTANCE=prod
#etc…
But Jeebus save me if I forget to comment out $SYS = “prod”… And that mechanism isn’t even consistent across all the scripts.
Actually, the 4GL itself doesn’t contain a single hard-coded database reference - all that’s taken from the command line. So if I didn’t need to run the job scripts, I’d probably be safe. I guess by my predecessor’s logic, as long as he encapsulated all the ugliness and hard coding in a shell script, it was fine. The effect is a regular minefield for me, though.
jdredd5150 | 20-Dec-05 at 7:35 pm | Permalink
yeah.
the need for some programmers, mentally, to program in their job security is just a nightmare for whoever has to do maintenance on it after they’ve split.