Oh... I'm a few months late... Hopefully my reply will still be useful to you, or to somebody else.
I know two ways in which you can manage to change the master environment variables. One is not exactly the "right way" of doing it, but ends up being safer and relatively easier. I'll start with the other one, which one could say is the "right way", though it involves some risks:
Whenever a DOS program is run, memory for the code is allocated at a segment start. Another memory block is allocated too for the program environment and it is inside that memory block that you will find the variables. You don't want your currently running program variables, though. You want the ones that belong to the command interpreter when it first loaded. So what you should do is probe the whole DOS memory block by block and see who owns each block. Once you find one owned by COMMAND.COM that looks like an environment block, that's the one. Because FBC compiles 32 bit DPMI based programs, you can't just access DOS memory directly. You have to use DPMI functions to do it. I honestly don't know what DPMI functions you have to use to be able to modify already-allocated DOS memory. You can read the DPMI docs to find out or you may want to write a small real-mode program (in QB, for example) to do the dirty work and call it from your main FB program if you want to do something bigger. Once you are able to modify the first 640K of memory freely, look for the first MCB (Memory Control Block) and go one by one. See here:
http://helppc.netcore2k.net/table/mcb. The blocks that contain a program will typically start with the bytes CDh 20h (int 20h instruction). Environment blocks will begin with text and you'll recognise the variables. The idea is that you'll write on top of the contents. You can't write past the end of the memory block!! So you can't give a variable a value longer than it had before unless you drop another variable. There is a chance you just won't find the block because some DOS's may erase the COMMAND.COM name from the block by filling it with zeroes (for security?), in which case, you'll have to guess.
Now, my recommendation and easy trick, but still requiring some DOS hocus pocus is that you instead modify the keyboard buffer. Sounds like nothing to do with it, but here's the thing: your program was likely invoked from the command line. The keyboard buffer is located at 0040:001A. The first two words are the head and tail offsets of the buffer, which is circular. Next, at 0040:003E, there's the actuale keys pending (32 bytes, that is 16 keys. Each key has a scancode and ASCII code). If you play with this a little, you'll see how it works. Try in real mode with QB and read the memory while you type and then when InKey is called and the buffer is flushed. If you fill the buffer with something like "x.bat" + Chr(13) (I believe you can leave the scancodes at zero) and properly set the head and tail, when your program exits, COMMAND.COM will read the keys from standard input and will believe this command was typed. If before exit, you creat a file called "x.bat" and write something like "set myvar=myvalue" in it, this variable will be assigned by COMMAND.COM and therefore, will remain in memory. It's dirty, but works. This same trick is useful when calling other programs without keeping your code in precious conventional memory.