Subj : Re: Calling OS/2 CMD from DOS BAT To : Sean Dennis From : Mike Luther Date : Mon Apr 11 2005 02:05 pm Sean .. and others working at this.. SD> *** Quoting Mike Powell from a message to All *** MP> Is it possible to call an OS/2 CMD file from a DOS batch file? SD> You need HSTART. You can email freq it from here with SD> the filename of HSTART05.ZIP. You need to really be careful at doing this, even with HSTART or ORUN or whatever. The reason is that when you nest these OS/2 items as command run instances like this, per what I've long ago run afoul of, you inherit at least part or all of the environment which was the involved parent of the 'child'. Particularly with the use of SIO/SIO2K, things may not be what you think in relation to COMM port issues. For example,when you run a DOS-VDM, there are a whole collection of DOS SESSION parameters which you can individualize for each different DOS-VDM you create, together with a separate 'AUTOEXEC.BAT' for each one. That's part of the beauty of OS/2. But it can trip you upwhen you instance an OS/2 .CMD file as a child process via a DOS-VDM .BAT file. This whole parcel of pitfalls can be particularly troublemsome when you are using TSR's as part of your DOS-VDM batch file applications. Memory, how high memory is set up, blocked in, loaded where, the number of file handles, all that sort of stuff which part of the environment you have and try to pass to a child of the parent, must carefully be examined to see how it cascades, and then collapses back into the parent when the child process is finished. When you use a DOS-VDM and TSR's you need to be very careful to also watch what happens when you finish one DOS application, such as in a BBS maintenace batch file, and start more, one after another. That together with the use of HSTART or ORUN. The problem that the OS/2 operation you call from inside the DOS .BAT file doesn't necessarily terminate the same way you might expect in DOS. Passing exit error message data may not be what you expect in the parent calling file. Nor may the child spawned OS/2 process even terminate when you 'expect' it to. One of the collateral damage issues in DOS-VDM's that call subsequent .BAT or ..CMD files with HSTART or ORUN, is that if you are using .TSR's in the DOS applications, where you wind up at back in memory in a collapsed DOS executable may not be at all where you think. This can lead to huge corruption problems which can be horribly difficult to diagnose. Here is a way to fix these DOS-VDM issues under OS/2: TSR Utilities Version 3.5 Kim Kokkonen TurboPower Software Table of Contents -------------------------------------------------------------------- 1. Introduction 2. MARK, FMARK, and RELEASE 3. MARKNET and RELNET 4. WATCH and DISABLE 5. MAPMEM, RAMFREE, and DEVICE 6. EATMEM 7. Known Limitations 8. Version History 9. Copyright and License Information 1. Introduction --------------------------------------------------------------------- The TSR Utilities are a collection of programs useful for managing DOS memory, particularly for managing memory-resident programs, also known as TSR's. TSR stands for "Terminate and Stay Resident". The most popular use of these utilities is for removing TSR's from memory without rebooting the PC. There are many other uses, however, especially if you are a software developer. The TSR Utilities have grown to include 11 programs. Here's a quick overview of each one: MARK marks a position in memory above which TSR's can be released. RELEASE removes TSR's from memory. FMARK performs the same function as MARK but uses less memory. MARKNET like MARK, but saves a more complete picture of system status. RELNET removes TSR's marked with MARKNET. WATCH a TSR itself, it keeps records of other TSR's. DISABLE disables or reactivates TSR's, leaving them in memory. RAMFREE shows how much RAM memory is available. MAPMEM shows what memory resident programs are loaded. DEVICE shows what device drivers are loaded. EATMEM uses up memory for controlled program testing. The two self extracting files with this wealth of information on all this are on my BBS in the GENERAL FILES area as: 10-21-93 11:19a 78643 0 TSRCOM.EXE 10-21-93 11:20a 76592 0 TSRSRC.EXE Collapsing the old ZyXel voice utilies back to the start of the BBS system after a voice inbound and modem recorded voice call to the BBS with these utilities was the only way I ever got voice/fax/data all on one BBS line at one time years ago. As has been noted here, one way you can 'solve' this problem is to create a FLAG file and use a separate .CMD file for the OS/2 application. You first create a tiny flag file just before you make the .CMD file child call from the ..BAT file. Then, while that flag file is still on the disk, you loop with a seconds timer such as WAIT2 or SLEEP or SNOOZE or whatever in OS/2 and the child process remains active while the flag file is on the disk. However, if needed, the .BAT file can either remove the flag file later, collapsing the ..CMD file OS/2 operation. Or, the reverse technique may also be used to prevent the .BAT file from 'running away with the bit', since after striking up the child process, it will happily go on to the next part of the .BAT file and can have no awareness of what is going on in the .CMD file at all. To circumvent this problem, there are a few scheduling utility tools that can help you play this DOS - vs. - OS/2 native parade of operations. You also need to be aware of a MAJOR corruption issue in TCP/IP 4.3 versions here that was uncovered and fixed by IBM some time ago. A bug in the DHCP operations exists in at least the later versions of the IBM OS/2 TCP/IP releases and fixpacks. Each instance of a DHCPCD connection attempt takes up a separate file handle for the services which you can see and verify with Theseus 4 if you like. Over hours, days, weeks,whatever, you'll run out of file handles and the system will smasho. A public patch to fix this in the later version(s?) of TCP/IP 4.3 was released by IBM that cures this serious system killer. It's on my BBS in the IBMINFO area as: 2-26-04 11:24p 104945 0 dhcpfix.zip Inside it is the following: APAR:PJ29555 ABSTRACT: If two DHCP clients are rebooting at the same time, they are generating exactly the same xid in the process of requesting an IP address. The DHCP server is sending the offer of IPaddress to this xid. Now, both the clients are trying to claim it which results in generation of duplicate IP address. FILES PROVIDED: dhcpcd.exe Curiously, the file AUTOEXEC.BAT in DOS-VDM files was also, per my memory, involved. As the error started the environment for the .BAT and related nested ..CMD files that needed the correct inheritence to function, became corrupted! This fix stopped months of misery on my BBS system box when it was finally whacked into view and fixed by IBM. --> Sleep well; OS/2's still awake! ;) Mike @ 1:117/3001 --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .