- Dec
- 51
- 2
Colleagues:
I'm hoping for a design critique before I take too steep a leap down the rabbit hole....
I run TCmd off of a portable USB3 hard drive that gets moved between my work PC, my personal laptop, and my family's home PC.
That way, I always have the same suite of .BTM files and other familiar tools, and I don't have to wonder which machine has the latest version of some script.
The problem is, things are located in different places on all three machines.
I am designing a mechanism that lets me swap in the correct JPSTREE.IDX during TcStart.btm, based on the %_HOST variable.
Right now, I have a VERY simple mechanism that works, but it's brittle!
For example, suppose I am on \\WORKPC for a couple of days. JPSTREE.IDX gets updated and when I exit, it gets saved to something like JPSTREE.WORKPC.IDX. When I start up TCmd again, it notes %_HOST == "WORKPC", copies JPSTREE.WORKPC.IDX back to JPSTREE.IDX, and turns on extended directory searching. All fine and well. Then my work PC crashes at quitting time one day. I pull the external drive and put it in my briefcase... I'll solve the BSOD the next morning. But TcExit didn't run and the files are in an inconsistent state! I plug my external drive into \\HOMEPC and start up TCmd. It copies JPSTREE.HOMEPC.IDX over to the working file, and the updates for WORKPC are lost.
Anyone have any great ideas for how to bulletproof this? Or a different way to accommodate the multiple hosts?
The best I've come up with so far is to maintain every copy of the JPSTREE file so that the first line is a directory path that identifies which host the data set is for.
For example, F:\MyUtils\JpSoft\HOMEPC, and so forth. Then each data set actually identifies itself regardless of the file or file location.
The problem is that this line isn't guaranteed to "stay put." If TCmd modifies the file during a normal work session, the line can end up getting sorted into it's more "logical" place in the file. The possibility of this "host-id" line being "missing" (not in line 1) makes the save/restore logic in TcStart / TcExit a LOT more complicated! Which, of course, is evidence of a bad design.
I can post the pseudo-code for my solution, but before I do that...
I am certain I'm missing a much simpler idea for how to manage this. Basically, I want TCmd to use the file that's appropriate for the current HOSTNAME, and update only that file, and leave the others alone. Then when being used on another machine, treat the other data set in the same fashion. Never clobber one set with a wrong one, or lose updates because something happened that the design didn't plan for.
Ideas? Comments?
-- forbin, aka johnb-in-atlanta
I'm hoping for a design critique before I take too steep a leap down the rabbit hole....
I run TCmd off of a portable USB3 hard drive that gets moved between my work PC, my personal laptop, and my family's home PC.
That way, I always have the same suite of .BTM files and other familiar tools, and I don't have to wonder which machine has the latest version of some script.
The problem is, things are located in different places on all three machines.
I am designing a mechanism that lets me swap in the correct JPSTREE.IDX during TcStart.btm, based on the %_HOST variable.
Right now, I have a VERY simple mechanism that works, but it's brittle!
For example, suppose I am on \\WORKPC for a couple of days. JPSTREE.IDX gets updated and when I exit, it gets saved to something like JPSTREE.WORKPC.IDX. When I start up TCmd again, it notes %_HOST == "WORKPC", copies JPSTREE.WORKPC.IDX back to JPSTREE.IDX, and turns on extended directory searching. All fine and well. Then my work PC crashes at quitting time one day. I pull the external drive and put it in my briefcase... I'll solve the BSOD the next morning. But TcExit didn't run and the files are in an inconsistent state! I plug my external drive into \\HOMEPC and start up TCmd. It copies JPSTREE.HOMEPC.IDX over to the working file, and the updates for WORKPC are lost.
Anyone have any great ideas for how to bulletproof this? Or a different way to accommodate the multiple hosts?
The best I've come up with so far is to maintain every copy of the JPSTREE file so that the first line is a directory path that identifies which host the data set is for.
For example, F:\MyUtils\JpSoft\HOMEPC, and so forth. Then each data set actually identifies itself regardless of the file or file location.
The problem is that this line isn't guaranteed to "stay put." If TCmd modifies the file during a normal work session, the line can end up getting sorted into it's more "logical" place in the file. The possibility of this "host-id" line being "missing" (not in line 1) makes the save/restore logic in TcStart / TcExit a LOT more complicated! Which, of course, is evidence of a bad design.
I can post the pseudo-code for my solution, but before I do that...
I am certain I'm missing a much simpler idea for how to manage this. Basically, I want TCmd to use the file that's appropriate for the current HOSTNAME, and update only that file, and leave the others alone. Then when being used on another machine, treat the other data set in the same fashion. Never clobber one set with a wrong one, or lose updates because something happened that the design didn't plan for.
Ideas? Comments?
-- forbin, aka johnb-in-atlanta