Gah... Inventaire de la mort qui tue!

This week finally was inventory week. Week of hell...

Boss was so stressed out it was just insane, couldn't give orders right anymore.

The inventory firm that came to help was less than helpfull with just about everything, constantly getting annoyed at people who can't remember 40 different keyboard shortcut for operating their handheld terminals. 4-line displays, so no chance of onscreen instructions.

Then the inventory firm people, who are supposed to be professional at this, made tons of mistake. We had to follow behind and redo what they did, in some parts i found that they went by how things look, not the actual product. So about 50 different SKUs of paint, with different finish and different colors, were just counted as one, and they also messed up some counts, just going by how many deep they can see, and ignoring a few more boxes sideway along the others, and stuff like that. Or not looking at the actual barcode of products and assuming that since the description is similar, it must be the same product.

This all got finished at about 2am. The inventory people gave me the files on an USB key, asked me to confirm the file was readable, then left. All i had to do was "simply" run step 7 to 9 in the inventory procedure documentation. Supposedly a 45min job at most. The bosses all left, only one security guy stayed behind to lock after i leave.

This is where my fun starts.

First, the inventory procedure documentation dates from 2003... Actually, was scanned in 2003. Some pages are tagged as "last revision: 06/11/96". The software is at version 13, this is for version 8. So i try to figure out where those options that were there in between 1996 and 2003 went now. After quite a bit of digging around, i find that the menus were relocated, renumbered, but mostly match what i do have on paper.

Now, the next fun step. It turns out that the procedure asks me to put the floppy or tape in the drive, specify the path to the file, then press enter. I have an USB key. Fun... Luckily, the file seems to be precisely 1.38Mb, so i just copy it to a floppy, as it seems to be just the right size for it.

Then i find out that the new server DOESN'T have a floppy drive, or the connector on the motherboard for one. I see that in the manual it says that it will autodetect an USB one. Problem is, i don't have one, and it's now 3h30 AM, so no chance of buying one now.

Oh, also, the store opens at 8am, before any computer store in the area does, and they already flushed the old inventory, so we'd be unable to open if i don't get this fixed.

So i go for plan b. They say you can use a tape. I remove the tape backup from the old server. SCSI. Gah. Luckily, my computer IS an old server, so i do have an onboard SCSI controller. Quick rush to install that, find out that it screws up my SCSI drive the way i installed it, mess with it some more, finally get it to read. Put tape in, tape snaps. Put another tape in, snaps again...

Yep, broken drive.

Plan C. Some people told me i am supposed to just be able to do it over USB. It's never mentionned in the documentation. Put the USB drive into the server. SCO Unix 5.0.6. Doesn't seem to be aware of what USB even is... Look around thru all the documentation, nothing about this. Google. Manage to find a few hacks that look promising, nothing works at all.

Remember that i'm NOT supposed to even have shell access on that system, i just hacked my way into it and rooted it a while back.

Finally, see something in a memo concerning that same problem. Apparently they assumed we'd be using redhat, which is the standard for non-Rona stores with OGC. So the USB thing isn't even in our version of the software, which kills that idea.

Plan D. Plug the USB drive into my computer, load the file, send it to my home dir on the server. Try to run the program, specifiying my home dir as the device path. Fails to find a file. Try with the end /, try with relative path to the software's current folder. Nothing at all.

I see that if i leave the path field blank it tries to load from /u2/ogcplus/sys1/MAGASIN, so i try putting the file there. Nothing. I get pissed, get into the shell script that runs the inventory load menu, finds that it just pokes the database. Go into the database manager, see that it's a stored procedure that runs a shell script. Find the script, FTP to my desktop, start poking at it.

Turns out that the file has to be allcaps, named PORTABLE, and with no extension. NOWHERE does it say that in the documentation, or when running the program. Filename is hardcoded in the database, and thanks to fixed-length strings, it's actually " PORTABLE", with all the whitespace before. Which is why the paths never worked, since it became "/usr/labl/ PORTABLE", since it was just putting the $path then the filename from the DB, without clipping.

So now that i've found that, i rename the file, start the script again. It finds something,.. I get a nice little blinking "Loading /u2/ogcplus/sys1/MAGASIN/PORTABLE into database, please wait." message. Seems alright. I check the process, it is alive and supposedly running. I look at the CPU useage... 100.0% idle. Maybe it's just really stupidly coded as before, or meant to wait a lot due to thinking it's getting the file from a floppy. I give it 10min, then just really see this is going nowhere, it's a 1.38Mb file, can't take that long no matter how crap your code is.

I just kill the process, it gives me a file read error. I noticed it was using CPIO with a bunch of parameters i can't recall here to supposedly copy the file. Params that don't work on files already on the drive. Grrr...

Remember that i "legally" am not supposed to have shell, and kill processes. So anyone else would still have their system locked up at "Loading", with no way to kill it, and every other user locked out.

I try a few different tweaks, try to edit the program's scripts to use just a simple CP instead, try to move the file by hand, bunch of other things. It complains about everything. I manage to make the script go further by removing a bunch of checks, so it skips the copying and unpacking and checking stage, since i've done all those by hand. It seems to run, then just complains about file not found. I notice that it just went and launched a dozen other scripts, can't tell which is glitching.

So i just print them all out, put a bunch of echos in the actual files, try to draw a map on paper as to what it's doing. Got about 200-300 pages of code on my desk and all over the floor right now, and am running on 24h without sleep.

While following that, i find out that it suddently switches to root to do some simple operations with awk for some reason. Which seems to be why it says file not found, 'cause it doesn't have read/write rights on the file. I chmod it to 777 so that everyone should have access to it, re-run the damn thing, which gets a bit further this time. However, it manages to read and copy the file, but then just starts throwing pages and pages of error. I try to follow further along the steps..

Then i find out that there's an undocumented option... The menu gives me "1-Load from TAR on floppy 2- Load from DOS CSV on floppy 3- Load from UNIX CSV on floppy". I have further down in the code a case, where it choses between 1-TAR, 2-DOS, 3-UNIX and 4-FILE, and 15-LOCFILE

Looking at the code, i see that 15 does load the file in the program dir. I try to run that, but it gives an error as it tries to copy the file on itself. I try 4 as an option, the script complains that 4 isn't in the choices, but does run anyway. It asks for the path. I put in my home dir. I get the loading message... But this time CPU useage shoots to 100%. Whee...

And it finally loads. It's now a bit past 5am.

So i continue with the procedure... As expected, the options i need are nowhere to be found. So lots of database poking is involved, i find the shell script names for what i need to do, unable to find where to find them in the menus, so i just run them like that.

For the first time this night, that goes fine, runs right away. Just takes forever.

About 6am now, the new inventory is finally loaded, the reports start printing...

Everything seems fine... Until i hear rain. Which seems a bit odd, considering i don't have any window nearby, and that i can't normally hear anything from outside. I get out of my office, see that it's raining in row 10... Skylight broke, water on the roof leaking in. A lot. I call the security while running to get large trash cans anything else that can collect water. There's already about 10ft square of floor covered in water. Out of all places, it had to be in the electricity departement, which still is powered since they needed the outlets running for the inventory people. Security cuts the power in a rush, we get a scare, thinking he killed the computer's power as well, but it was just the lights in the office.

After a bit, we get the water leak under control... I check my report, it's now at page 1600, and it's getting close to 7am... It's not near done. I just say screw this and head home... Inventory is loaded, the thing is printing, they can take care of putting more paper in and finshing that.

... of course, that couldn't just end there.

Just after getting home, i get a call from work.

The file transferred alright, yeap. But it turns out that there's huge amounts of stock still missing from the database. They want me back there ASAP. So yep, back there.

When at the store, they have the file open in excel, and show me the information that i was supposed to transfer that is missing. They ask what happened and blah... I look at the file.. It's not even the same i had. I poke around a bit, and it turns out that they saved the inventory in 3 parts, two of them at 1.38mb, the other just 800k. But they made a /Rona/inventory folder for the second part, and put the 3rd in "New Folder(1)" Apparently, the guy tried to save on the USB drive as a floppy. It asked three time to insert the next disk. First time he just pressed enter, it worked, second time it said the file already existed, so he entered a path, 3rd time he just created a folder and pressed save. So he thought he just managed to save it after three tries, where it just made 3 parts.

So it turns out, i just loaded the first out of three files. Nobody knew there were three files.

So i try to redo as i did yesterday, rename the file, upload, run the script... It flushes the previous data, then loads the first, then flushes and loads the second, then gives an error...

Gah!

Now it's about 10am, i haven't slept, and i'm trying to figure out what is going on. The file is about 45000 lines long, and it's being parsed by a 200 pages script. It gives no error message beside "Could not load", which is the big stupid else in the main script, that gets run if ANYTHING fails.

So lots of poking around. i find out that they've put the file header a second time in the middle of the second file. Grr... Fix that, rerun the thing.

Then i realise that since it flushes the previous file, it won't work. So i try merging all three files together in one large 4mb one. I try to run it again, it gives me out of range error. I cut the file down to 65535 lines, it works. But i'm still stuck with lines that won't load, and need to be.

I finally realise that i can just run one file, run the rest of the import process, then it moves the data to a separate table, where it's not flushed. So i just re-run the three files separately after making sure the headers and tail are alright.

And it finally works. The entire inventory value seems to show up.

I should mention that since this was daytime, i had the whole administration, all the bosses staring over my shoulder the whole time, since basically until i had that fixed, all the transactions were being dropped due to invalid inventory.

So at about noon, i finally got to head home.

I want to sleep, but i had so much coffee now that i can't.

I seriously home it'll be another 8 years before a full inventory like this. On the good side, out of about 8Mk$ of inventory, we had about 210k$ of difference between what was in the DB before and the new inventory.

Doom...