OS/2 Tips

We scan the Web, Usenet and the OS/2 mail lists looking for these gems. Have you run across an interesting bit of information about OS/2 recently? Please share it with all our readers. Send your tips to editor@os2voice.org. If you are interested in joining a particular OS/2 Mailing List, check out the VOICE Mailing List page for subscribing instructions for a large variety of existing Lists - http://www.os2voice.org/mailinglists.html.

Editor's note: these tips are from OS/2 users and in some cases can not be verified by myself. Please heed this as a warning that if you are not sure about something, don't do it.

August 1, 2000 - Here's a tip from Christian Hennecke posted on the xworkplace-user List in answer to someone looking for a way to select Property Notebook tabs, when there may be more then fit in the viewable window:

Right-click somewhere on the row of tabs and a context menu showing all notebook pages will pop up.

August 6, 2000 - Do you run or plan to run SES - IBM's Security Enabling Services, on OS/2? Here are some tips from posts on the comp.os.os2.misc:

First from Lorne Sunley, for anyone looking for SES for Warp 3:

If you are running Warp 4, SES is an option on the "Selective Install" program.

If you are running Warp 3 you have to download the SES from the IBM FTP site. The URL is: ftp://ftp.software.ibm.com/ps/products/os2/warp.update.kit/warpses/

Read the warpses.txt file - it has the installation instructions for the SES code that is contained in the security.bbs file. This file is compressed using PACK so you have to use UNPACK to decompress it.

Next from Scott E. Garfinkle:

Don't forget to re-apply FP40 or later if you have Warp 3 (or WSSMP) and put on this update. You need to do this to get the SES updates (warpses is about FP17 level). For Warp 4, you have to (re-)apply FP10 or later after doing Warp 4 selective install of SES.

August 6, 2000 - Learn something new everyday. For me it was that two systems can actually share the same SCSI devices on the same SCSI chain. No way I'm trying this, but it's good to know it is possible. here's the scoop from Matt Ion on the OS/2 List:

I have a mixed OS/2 v4 and Win 98 peer to peer network. The OS/2 machine has a scsi adapter with a scsi cd-rom and a scsi scanner attached to it. I can set up sharing on the cd-rom (as a directory) so that the win 98 machine can see and read it. Is there a way to set up sharing on the scanner ?

Sure. Put a SCSI card in the W95 box, set it to a different SCSI ID than
the one in the OS/2 box, and just plug both into the scanner.

No, I'm absolutely serious. I've seen it done! A friend had a SCSI scanner and Zip drive and got tired of swapping the cables back and forth between his PC and his PowerMac... so we just chained out the back of the scanner to the external SCSI drive on the Mac (after setting the Mac's SCSI interface to ID6) and voila! Not only could both machines use the scanner and Zip, but the Mac could see the PC's SCSI drives, and the PC showed two CD-ROMs (when we clicked on the new one, the audio CD in the Mac started playing :)

The above was confirmed by Bill Haybyrne:

A few weeks ago I asked a question about sharing a scsi scanner between an OS/2 box and a W98 box. Matt Ion suggested "Put a SCSI card in the W95 box, set it to a different SCSI ID than the one in the OS/2 box, and just plug both into the scanner." I have to confess that his suggestion caused me to fear that too long in the cold clime of the North had finally slowed down Matt's thought processes.

This weekend, perhaps due to too many hot Washington DC summers, I decided to try Matt's suggestion. Absolutely Amazing!!! It worked...exactly as he described.

Thanks, Matt. I guess you can afford to stay in the cold a little longer.

Though Julien Pierre offered this caution on the above:

I would only use this method to share read-only DASD SCSI devices. But don't try sharing a SCSI hard drive this way if you intend to write to it, since both computers could be writing to it at the same time and data corruption will likely ensue. This will be particularly bad since each system will maintain its own read/write cache for the filesystem. Disabling all disk caches would help reduce this risk but would still not eliminate it, since you do not control the time when each system does its I/O to write and they could still be writing to the same area, particularly on a file system like FAT. I would put the SCSI disk in "write protect" mode physically via a SCSI jumper before I would even try booting the two systems with the SCSI hard drive shared between both buses.

A scanner is still not entirely safe, since potentially both computers can send commands to it that will produce erratic results. For example, if you start scanning simultaneously from your OS/2 and Win95 system, some screwups will occur, and probably both scans will fail, but beyond a retry nothing bad will happen. Sharing a tape drive would be a similar case as long as the tape is write-protected; although you may damage the drive if multiple computers are sending seek/read commands to the drive at once. Again, don't take the risk of backing up to a tape if the drive is shared.

SCSI CD-ROM/DVD drives and other read-only devices are probably the ideal devices to share, since there shouldn't be any restrictions on what you can do with the drive when it's shared as opposed to hooked to a single machine.

August 8, 2000 - Count on Daniela Engert to show me something I always thought was impossible. Here is her cookbook entry, posted in response to a plea on comp.os.os2.misc, on how to copy a system from one drive letter to another.

Rule of thumb: any drive letter found at a proper place in a valid WPS object is adjusted by the WPS if the object in question is targeted to another drive letter. Of course this doesn't include data stored in the OS/2 INIs which are *not* WPS objects (some software stores pointers to themselves there).

So, the basic operation of moving an existing desktop to another drive letter is *move* the "Desktop" tree from the source drives object to the target one. If the target drive letter doesn't yet exist, create it beforehand. Then reboot to a command line window only (no WPS started!) and issue "XCOPY source: target: /H /O /T /S /E /R /V". This moves the rest of your boot drive to the new target; don't forget to adjust CONFIG.SYS. If required run "SYSINSTX target:" to make the new target drive bootable, You may need to add the new target to your favourite bootmanager as well.

If you need to transplant a desktop to another location, save away \OS2\OS2.INI, \OS2\OS2SYS.INI and the full \Desktop tree including *all* extended attributes. This needs to be done without PM active! Restore the mentioned items to the new target and you're done...

Using these operations I migrated several OS/2 2.1, Warp3 and Warp 4 installations to several new drive letters (D: -> E: -> F: -> ...), changed the underlying hardware and disk drives quite often, cloned existing desktops or full installations to new target drive letters (for testing purposes), and on and on... No magic, just basic WPS features are involved. Ciao

Here's some more on the subject from Buddy Donnelly:

Good stuff (as usual, Dani) and here are a couple of other tiny things to add.

1. All versions of OS/2 appear to support (tolerate) "relative" path locations in CONFIG.SYS. You can, therefore, make 1 CONFIG.SYS that will work the same from any boot drive. For instance, this statement: DEVICE=C:\OS2\BOOT\OS2CDROM.DMD can just as easily be DEVICE=\OS2\BOOT\OS2CDROM.DMD

BASEDEVs of course always point to either the boot-root or \OS2\BOOT on the boot drive.

2. There's a lot of danger in having *multiple* \DESKTOP trees visible to OS/2, and you have to take special care if you run CHECKINI /C on a system with multiple visible desktops. Get the most recent version of WPTOOLS and read the CHECKINI docs for details on the startup parameters to use.

INFOZIP works quite well at packaging the pertinent files for transfer, by the way. In fact, this is a side feature of BOOTSET, to do a quick-and-dirty archive of the important Desktop files and structures.

August 9, 2000 - Steven Levine had the following info about problems with Stardock's Object Desktop after FP14 is applied. The post was on comp.os.os2.utilities:

IBM changed the behavior of one the API's. Now, the resource monitoring has to be turned on explicitly. Before, this was not the case. Check on Hobbes. Someone wrote a small app, which you can put in the startup folder, that will turn on the monitor.

FP14 also breaks Object Navigator details view. You must start ON in icon view or it may hang.

August 10, 2000 - Here is a nifty work-around for a new problem that has cropped up in the Odin project with running RealPlayer. Seems for preferences, the tabs no longer display to allow selection of preference pages. Here is how to deal with this until the Odin team fixes the problem, courtesy of Darrell Spice Jr., of OS/2 console game emulator fame - http://home.houston.rr.com/spiceware/

Sure - I have the same preference screen problem. you can get to each tab by doing this:

1) Give focus to cancel button (click on cancel, but don't let go of the mouse button until after you've slide the pointer OFF cancel)
2) hit TAB
3) hit cursor RIGHT
4) you should now see the next preference page
5) repeat from step 1 to see each page

August 10, 2000 - Have a problem with a plugin in Netscape, and need to know how to uninstall it? If it doesn't have a formal uninstall then perhaps the following from Doug Bissett on comp.os.os2.apps may be of help:

Look at Help-> About plugins, and determine the name of the plugin DLL (NPSWF2.DLL, in this case), then go to x:\NETSCAPE\PROGRAM\PLUGINS and remove that file (move it somewhere else, in case you want to use it again, by simply moving it back into the PLUGINS directory). You can do this with almost all of the plugins (I suspect there are a couple that should not be messed with).

So far, I have not seen any problems with the flash plugin (the DLL is dated 6/29/2000, which is the latest that I have heard about, and is supposed to be the last beta release, but that may have changed). I did have some problems with the first beta, but that is long gone.

August 10, 2000 - Here's another Odin related tip from Lewis G Rosenthal on the odinusers list. If you installed Warp using a CID install, rather then the normal install, most likely Open32(called DAX in the original Warp4 install) wasn't installed. If that applies to you, then this should help:

From my earlier post:

CID installs needed to explicitly state the inclusion of the
DAX package
in the install (this keyword was omitted from the sample
response file)
with the following:

Dax Base
DAXCOMP1.Selection=1
DAXCOMP1.TarDrv=C:

You will find references to DXCOMP1 in FIBASE.RSP, in the OS2\INSTALL
directory, where the actions for the installation (and prerequisites)
are detailed.

August 11, 2000 - Where else to find a tip about RSJ CD Writer for OS/2 then on RSJ's own Support News Group - rsj.de.support.cdwriter.os2. Someone asked how to write an CD ISO file image using RSJ, and Martin offered the following:

To do that you need to rename the file to "TRACK01.TRK" and copy it to the directory where your CD-VIEW is pointing in the Hard-Drive, and it will work like a charm

August 12, 2000 - If you ever set a password on the Screen Lockup in OS/2, then forgot the password, all is not lost. According to OS/2 Warp Unleashed page 159, to remove the lockup, you have to boot to a command prompt(either using the install disks, utility disks or Alt-F1 on Boot and selecting the command prompt boot option), go to the \OS2 directory and run

MAKEINI OS2.INI LOCK.RC

I assume this is a non-destructive since it doesn't give any warning, but you may want to backup OS2.INI before you do this.

August 17, 2000 - A number of people have been reporting problems with FDISK in recent fixpacks. Darryl Sperber believes he has found an issue with FAT32 partitions that may be causing the problem. Here is a summary of his findings. Hopefully in October we will have a full article on the problem.

Note that I have not yet personally confirmed all parts of the (2) method below, since I've taken (1) as my recovery method.

The summary is really simple, for environments including FAT32 which have become unusable ("OS/2 is unable to operate your hard drive") and/or OS/2 is no longer installable, by virtue of using FP13+ FDISK:

(1) use the old (pre-FP10) FDISK to re-create Boot Manager, and stick with OS2DASD.DMD, you don't have to reinstall anything, all pre-existing OS/2 partitions will return to operability, and you'll be able to reinstall OS/2 once again if you need to.

Your drives will show low letters only for FAT16 and HPFS.
FAT32.IFS will give high drive letters to FAT32 as it always has.

(2) use the new (FP10+) FDISK to create Boot Manager, and install DaniDASD.DMD to your installation diskettes (it will work on both Warp 4 and Warp Connect), along with SET COPYFROMFLOPPY=1. You'll have to do a complete reinstall of all OS/2 partitions and application software, as all partition drive letters will most likely change.

Your drives will show low letters for FAT32 as well as for FAT16 and HPFS. EVERY partition will be given a letter, and FDISK will show this, and Boot Manager menu partition letters will match this.

I haven't tested (2) for myself yet, as I've taken (1) as my particular recovery method. However in the DaniDASD.DMD environment I believe FAT32.IFS should still assign high letters to FAt32 partitions, which would be for the same FAT32 partitions as are already low lettered by DaniDASD.DMD (through its "virtual volume" method)... but I don't know that for sure.

But if that's what happens, the low lettered drives would still be unusable for read/write, with the high lettered ones from FAT32.IFS being the ones you would use to read/write FAT32.

However again, I haven't confirmed all parts of (2) and its interaction with FAT32.IFS. But it sounds reasonable.

Features
editor@os2voice.org
[Previous Page ] [ Index] [Next Page ]
VOICE Home Page: http://www.os2voice.org