
                  General OS/2 Discussion          (Fidonet)

                 Saturday, 11-Dec-1999 to Friday, 17-Dec-1999

+----------------------------------------------------------------------------+

From: Peter Knapper                                     10-Dec-99 22:51:14
  To: Eddy Thilleman                                    11-Dec-99 00:18:14
Subj: Power failures

Hi Eddy,

PK> corrupting its Root directory entry or a pointer to the Root directory
PK> entry, if there is a power failure and the system is not shut down
PK> cleanly. If it IS shutdown cleanly, the next boot up is fine and all

 ET> So your real problem are power failures.

You were not really listening were you. The PROBLEM, is not power failures, it 
is ANY situation that prevents the system from shutting down normally, such
that the CHKDSK that runs upon restart fails to recover the errors on ONE
partition only (the other 4 partitons are all recovered fine). 

That power failures are MONTHS apart is irrelevant, there are other reasons
why the system fails to shut down correctly. Regardless of the reason for it,
if the system is NOT shut down "normally", then the HPFS partition ROOT
directory entry cannot be found upon restart!

A UPS will not help to resolve ALL situations that the system does not have a
clean shutdown.

Regards...........pk.

--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
30185/10

+----------------------------------------------------------------------------+

From: Kees Bergwerf                                     09-Dec-99 04:14:09
  To: Will Honea                                        11-Dec-99 06:20:20
Subj: not enough diskspace

Hello Will!

Monday December 06 1999 20:02, Will Honea wrote to Kees Bergwerf:


 WH> Theseus5 is working on multiple machines here with Warp 4, fp9-12, and
 WH> Warp 3, fp38 or 40.  Better be - I rely on it.  I never got os2memu to
 WH> work after fp8 or so and agve it up.

Well.. perhaps it was os20emu. Theseus is working again and so does memsize.
It is hard to tell which program caused the trouble because I removed more
than 1 at the same time.
But I am not using os2emu. I installed it only to have a look at it :-) but I
forgot to remove it.

 WH> For Memsize, just go to the memsize directory and delete the memsize.ini
 WH> file.  It will then restart fine w/o theseus.

Well.. that didn't help at first, but then I didn't know that there were two
theseus0.dll in use.
I was really in a very bad mood when everything went wrong :-( but now it is
running like it have always been. Happy me :-)


Kees

---
 * Origin: Trefpunt BBS Den Haag +31-70-3967407 (2:280/1507)
772/1

+----------------------------------------------------------------------------+

From: Kees Bergwerf                                     09-Dec-99 04:20:01
  To: Eddy Thilleman                                    11-Dec-99 06:20:20
Subj: not enough diskspace

Hello Eddy!

Monday December 06 1999 10:47, Eddy Thilleman wrote to Kees Bergwerf:

 ET> I too tried to install fixpak 12 on my Warp 4, but I got only errors
 ET> and lockups (I didn't got error messages about not enough diskspace to

Dit you use the simplyfix program?
It is really great! :-)
Applying a fixpack is a piece of cake.
Well.. there was something going on here.. I removed the backup from a
previous fixpack, but I installed OS/2 again. But somehow the fix knew that
there was a backup, but it couldn't find it. I think there was a logstart.*
file or something like that, that I removed and then everything was ok.

Kees

---
 * Origin: Trefpunt BBS Den Haag +31-70-3967407 (2:280/1507)
772/1

+----------------------------------------------------------------------------+

From: Herbert Rosenau                                   10-Dec-99 13:26:19
  To: Steve McCrystal                                   11-Dec-99 06:20:20
Subj: cache

 SM> I noticed that, and hadn't seen it before either, so I checked
 SM> the online docs. They say that LAZY takes one of two
 SM> parameters... OFF or ON. 

Read the readmes to your Fixpack. It is declared there. The docu is old.

readahead:[0|1] is the only choice the fixpack tells this parameter as n - but 
all other than 0 (read ahead off) or 1 (on) will not understund by cache.exe.


--- Sqed/32 1.15/development  65:
 * Origin: Schont die Umwelt: Vermeidet DOSen (2:2476/493)
231/992
633/260
2501/209

+----------------------------------------------------------------------------+

From: Stewart Honsberger                                10-Dec-99 11:02:15
  To: Linda Proulx                                      11-Dec-99 06:20:20
Subj: Happy Holidays!

09 Dec 99 12:43, Linda Proulx wrote to All:

 LP> Before everyone gets into the hectic of holiday season,  I thought 
 LP> that I would wish everyone a joyous and safe holiday season and a 
 LP> happy millenium.

Wow.. You really got in there early.

Only 1 year, 21 days until the milenium!

Stewart Honsberger,
  blackdeath@tinys.oix.com

... Women vs. Beer: Changing beers doesn't cause you to pay alimony.
-!- GOPGP/2 v1.23

--- Msged/2 TE 05
 * Origin: Blackdeath BBS - Private (1:229/604)
2320/38

+----------------------------------------------------------------------------+

From: Leonard Erickson                                  09-Dec-99 16:18:01
  To: Peter Knapper                                     11-Dec-99 06:20:20
Subj: fdisk /query

 -=> Quoting Peter Knapper to Stewart Honsberger <=-

 PK> No, a single drive letter is all that is needed. Ok, some further
 PK> explaination is required. In my partition/drive lettering scheme, the
 PK> booted partition containing OS/2 would ALWAYS be Drive C:, and never
 PK> anything else. It would be possible to use such a machine with no
 PK> other drive letter assignment at all, unless the user wanted to
 PK> allocate a drive letter for some reason (probably some old brain dead
 PK> S/W).

Well, I've found good reason to make extensive use of Netware's "map
root <drive>=<path>" command. Mostly for software that maintains a copy
of the directory "tree" for drives. There's a limit to how much *any*
of them will cache and my main netware volume exceeds what most
allocate. So I just map some of the directories to be treated as root
directories of new drives. I get to keep from choking the "directory
tree" cache on the programs, but not have to split up my volume into
smaller drives. 


--- FMailX 1.48a
 * Origin: Shadowshack (1:105/51)
231/992
633/260
2501/209

+----------------------------------------------------------------------------+

From: Peter Knapper                                     11-Dec-99 11:22:08
  To: Will Honea                                        11-Dec-99 06:20:20
Subj: HPFS Directories.

Hi Will,

PK> A simple question.......;-) Where is the FIRST root directory
PK> entry located  on an HPFS volume? I know that HPFS uses a directory 
PK> recording methodology similar to a B-Tree, and it writes  files in
PK> BANDS across the partition, however the very FIRST  directory entry
PK> MUST be located somewhere that can be  calculated as a FIXED
PK> location for that particular  partition. Alternatively there must be
PK> a data structure  within an HPFS partition that contains details of
PK> the  partition "layout". Now how can I find out where that  location
PK> is? 

 WH> I'm sure Mike Ruskai will jump in here, but you should take a long
 WH> look at DFSEE (Hobbes, etc).  

THUNK! That was a brain cell falling into place, thanks Will, I needed that! I 
already have DFSEE here and had forgotten about it! Thats what happens when
you have too many fingers and too many pies......;-) 

Now DFSEE's output is interesting (edited for brevity and to account for line
wrapping in fido messages) -
=======================================================================
DFSee OS2 version : 3.07 14-09-99, executing cmd: cmd fdisk /query

Drive Name  Partition Vtype FStype Status   Start     Size

    1 00000020    C:    1    07      2          0      203
    2 0000003f     :    3    00      0          0      200
    2 00064820    D:    2    07      0        201      299
    2 000fa820    E:    2    07      4        501     1999
    2 004e2820    F:    2    07      0       2501      452

DFS message: 7168 : no additional info available.

Opened object: -- --none--  u=00000000 x=00000000 this=00000000  
  Base=00000000
11/12/99 09:01:22 : Now use our own built-in diagnostic power ...
DFSee OS2 version : 3.07 14-09-99, executing cmd: part
Number of disks   : 2
Geometry for disk : 1  Cyl:  203 H: 64 S:32   Disksize : 00065800 =  
   203 Mb
Geometry for disk : 2  Cyl:  750 H:128 S:63   Disksize : 005C4900 =  
  2953 Mb
Disk 2: No MBR or other bootrecord found
Invalid signature in EBR 00096000
 Id 02=D: WARNING : Device geometry and CHS-beginsector do not match LBA 
  offset.
          Some possible causes are: Change in BIOS level or BIOS settings,
          changed EIDE of SCSI adapter (or firmware) with different LBA 
  mapping
          or an upgrade of DISK/SCSI device-drivers or filters (Fixpack ?).
          Or the partition-table has been corrupted, possibly by a Virus.
 Id 02=D: WARNING : Partition does not start on head-1 (cylinder boundary)
 Id 02=D: WARNING : Partition doesn't end on last head (cylinder boundary)
 Id 02=D: WARNING : Logical partition extends beyond extended-container
 Id 02=D: WARNING : Extended partition extends beyond extended-container
 Id 02=D: WARNING : Extended partition extends beyond end of the disk
+--+--+---+-----------------+--------+--------+-----------+--+--------+
|id|PD|Vol|Type, description|Format  |Creator |Label Info |BM| Size
Mb|+---+-----------------+--------+--------+-----------+----------+------+
|01| 1|>C:|Prim 07 Inst-FSys|HPFS    |OS2 20.0|OS2        |  |   203.0|
+--+--+---+-----------------+--------+--------+-----------+--+--------+
|02| 2|   |N-P/Log FreeSpace|-- -- --|-- -- --|- - - - - -|  |   402.0|
|02| 2| D:|Log  07 Inst-FSys|HPFS    |OS2 20.0|FIDOBASE   |  |   300.0|
|04| 2|   |N-P/Log FreeSpace|-- -- --|-- -- --|- - - - - -|  |  2452.1|
+--+--+---+-----------------+--------+--------+-----------+--+--------+
=======================================================================

FDISK shows the partitions in the layout as I would expect. Note that drive 2
has free space at the beginning of about 200MB, this is so I can place the
OS/2 partition there if the first HD ever fails. The first DISk is 200MB, the
second is 3GB.

DFSEE shows a bit more info, notice the different Geometry info for each DISK. 
BOTH were set up on the Adaptec HA at the same time. The partition layout on
the second HD was changed just after the NEC HA was installed.

DFSEE has a somewhat different picture of the second HD, it is saying that the 
partition marked as free space is double the size (400MB), and that it only
has 1 valid partition (D:) of 300MB (which is actually correct in size),
however its complainaing that the partitions are not cylinder aligned, hence
probably why it sees the remaining drive space as 1 large free area...

I now think I can figure out whats going on. About 5 months ago I changed the
SCSI HA from an Adaptec ISA card to an NEC based PCI card. Within 2 weeks I
also changed the last 2 partitions as far as SIZE were concerned, increasing
E:, and shrinking F:. To do this I copied everything off them, deleted the
last 2 partitions, re-allocated, re-booted and Formatted them, then copied
everything back. Its been running fine since then except for the situations
where the system is not shut down before it restarts (it normally runs 24x7). 

It looks like the drive mapping schemes used by each HA do not exactly match,
and this could be leading to confusion when partitions are changed size
initial set up and certain types of errors occur and CHKDSK has to recover
things.

I guess I will have to remove EVERYTHING off DRIVE 2, remove ALL partitions on 
that drive, Re-boot and then re-allocate them again. Hopefully this will fix
the problem by updating the new controller geometry info for ALL partitions. 

Thanks for the pointer, fortunately my blindness is only partial.......;-)

Cheers...........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: Peter Knapper                                     11-Dec-99 14:58:06
  To: Ron Nicholls                                      11-Dec-99 06:20:20
Subj: Fix_Paks

Hi Ron,

 RN> Are the early fix paks for Warp 4 ( 1 to 8 ) still available anywhere.

I can't say for sure because I havent been there in a while, but have you
tried looking under -

  ftp:\\service.boulder.ibm.com/ps/products/os2/fixes

for starters?

Cheers............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: Peter Knapper                                     11-Dec-99 15:53:04
  To: Will Honea                                        11-Dec-99 06:20:20
Subj: HPFS Directories.

Hi Will,

PK> A simple question.......;-) Where is the FIRST root directory
PK> entry located  on an HPFS volume? I know that HPFS uses a directory 
PK> recording methodology similar to a B-Tree, and it writes  files in
PK> BANDS across the partition, however the very FIRST  directory entry
PK> MUST be located somewhere that can be  calculated as a FIXED
PK> location for that particular  partition. Alternatively there must be
PK> a data structure  within an HPFS partition that contains details of
PK> the  partition "layout". Now how can I find out where that  location
PK> is? 

 WH> I'm sure Mike Ruskai will jump in here, but you should take a long
 WH> look at DFSEE (Hobbes, etc).  

THUNK! That was a brain cell falling into place, thanks Will, I needed that! I 
already have DFSEE here and had forgotten about it! Thats what happens when
you have too many fingers and too many pies......;-) 

Now DFSEE's output is interesting (edited for brevity and to account for line
wrapping in fido messages) -
=======================================================================
DFSee OS2 version : 3.07 14-09-99, executing cmd: cmd fdisk /query

Drive Name  Partition Vtype FStype Status   Start     Size

    1 00000020    C:    1    07      2          0      203
    2 0000003f     :    3    00      0          0      200
    2 00064820    D:    2    07      0        201      299
    2 000fa820    E:    2    07      4        501     1999
    2 004e2820    F:    2    07      0       2501      452

DFS message: 7168 : no additional info available.

Opened object: -- --none--  u=00000000 x=00000000 this=00000000  
  Base=00000000
11/12/99 09:01:22 : Now use our own built-in diagnostic power ...
DFSee OS2 version : 3.07 14-09-99, executing cmd: part
Number of disks   : 2
Geometry for disk : 1  Cyl:  203 H: 64 S:32   Disksize : 00065800 =  
   203 Mb
Geometry for disk : 2  Cyl:  750 H:128 S:63   Disksize : 005C4900 =  
  2953 Mb
Disk 2: No MBR or other bootrecord found
Invalid signature in EBR 00096000
 Id 02=D: WARNING : Device geometry and CHS-beginsector do not match LBA 
  offset.
          Some possible causes are: Change in BIOS level or BIOS settings,
          changed EIDE of SCSI adapter (or firmware) with different LBA 
  mapping
          or an upgrade of DISK/SCSI device-drivers or filters (Fixpack ?).
          Or the partition-table has been corrupted, possibly by a Virus.
 Id 02=D: WARNING : Partition does not start on head-1 (cylinder boundary)
 Id 02=D: WARNING : Partition doesn't end on last head (cylinder boundary)
 Id 02=D: WARNING : Logical partition extends beyond extended-container
 Id 02=D: WARNING : Extended partition extends beyond extended-container
 Id 02=D: WARNING : Extended partition extends beyond end of the disk
+--+--+---+-----------------+--------+--------+-----------+--+--------+
|id|PD|Vol|Type, description|Format  |Creator |Label Info |BM| Size
Mb|+---+-----------------+--------+--------+-----------+----------+------+
|01| 1|>C:|Prim 07 Inst-FSys|HPFS    |OS2 20.0|OS2        |  |   203.0|
+--+--+---+-----------------+--------+--------+-----------+--+--------+
|02| 2|   |N-P/Log FreeSpace|-- -- --|-- -- --|- - - - - -|  |   402.0|
|02| 2| D:|Log  07 Inst-FSys|HPFS    |OS2 20.0|FIDOBASE   |  |   300.0|
|04| 2|   |N-P/Log FreeSpace|-- -- --|-- -- --|- - - - - -|  |  2452.1|
+--+--+---+-----------------+--------+--------+-----------+--+--------+
=======================================================================

FDISK shows the partitions in the layout as I would expect. Note that drive 2
has free space at the beginning of about 200MB, this is so I can place the
OS/2 partition there if the first HD ever fails. The first DISk is 200MB, the
second is 3GB.

DFSEE shows a bit more info, notice the different Geometry info for each DISK. 
BOTH were set up on the Adaptec HA at the same time. The partition layout on
the second HD was changed just after the NEC HA was installed.

DFSEE has a somewhat different picture of the second HD, it is saying that the 
partition marked as free space is double the size (400MB), and that it only
has 1 valid partition (D:) of 300MB (which is actually correct in size),
however its complainaing that the partitions are not cylinder aligned, hence
probably why it sees the remaining drive space as 1 large free area...

I now think I can figure out whats going on. About 5 months ago I changed the
SCSI HA from an Adaptec ISA card to an NEC based PCI card. Within 2 weeks I
also changed the last 2 partitions as far as SIZE were concerned, increasing
E:, and shrinking F:. To do this I copied everything off them, deleted the
last 2 partitions, re-allocated, re-booted and Formatted them, then copied
everything back. Its been running fine since then except for the situations
where the system is not shut down before it restarts (it normally runs 24x7). 

It looks like the drive mapping schemes used by each HA do not exactly match,
and this could be leading to confusion when partitions are changed size AFTER
initial set up and certain types of errors occur and CHKDSK has to recover
things.

I guess I will have to remove EVERYTHING off DRIVE 2, remove ALL partitions on 
that drive, Re-boot and then re-allocate them again. Hopefully this will fix
the problem by updating the new controller geometry info for ALL partitions. 

Thanks for the pointer, fortunately my blindness was only partial.......;-)

Cheers...........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: George White                                      09-Dec-99 07:31:01
  To: Louis Aubree                                      11-Dec-99 06:20:20
Subj: Warp 3 install

Hi Louis,

On 06-Dec-99, Louis Aubree wrote to Gord Hannah:

 LA>>> Install Warp 3 red with Dual Boot on HPFS ? Is it possible ?
 LA>>> With Win apps needed?

 GH>> I don't see why not my first install of Warp3 was a botched deal
 GH>> from the start, but it worked just fine, winapps can reside any
 GH>> where, just use th and if they are good should work, and yes
 GH>> there a few good Win apps out there, the only fault they have is
 GH>> the OS they must run under..:-)

 LA> I understand that Warp 3 _blue_ spine (with WinOS2 inside) can be
 LA> installed on HPFS, but I still don't understand the same for the
 LA> _red_ spine version.

 LA> I think that Warp _red_ spine has to be installed _after_ DOS and
 LA> Win3.1x, on the same primary partition, so this partition has to
 LA> be FAT16 formated. Then, the user could choose to never use Dual
 LA> Boot anymore and run anything (hum!) from OS/2.  Where am I wrong?
 LA> Is it possible to install Win3.1x _after_ Warp 3 red spine on an
 LA> HPFS partition? Or use another trick?

It can, I've done it.

Step 1). Zip up (or archiver of your choice) the Windows directory
         tree retaining paths, and put the zip on a partition that
         wont be touched during the install.

Step 2). Install OS/2 _without_ Windows elements, formatting the
         partition HPFS.

Step 3). Unzip the Windows installation saved in step 1) back un the
         partition it came from.

Step 4). Run selective install and select Windows and point it to the
         Windows installed in step 3).

 LA> Hope this will be clear soon.

I hope that is clear enough :-).

 LA> Louis  P.S. Eddy Thilleman also replied: he also believes Warp 3
 LA> red cannot be installed on HPFS.

A rare event, note it down, Eddy is wrong... :-).


George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)
231/992
633/260
2501/209

+----------------------------------------------------------------------------+

From: George White                                      09-Dec-99 07:42:19
  To: Andy Brown                                        11-Dec-99 06:20:20
Subj: Warp 3 install

Hi Andy,

On 07-Dec-99, Andy Brown wrote to Louis Aubree:

 LA>> I think that Warp _red_ spine has to be installed _after_ DOS and
 LA>> Win3.1x, on the same primary partition, so this partition has to
 LA>> be FAT16 formated. Then, the user could choose to never use Dual
 LA>> Boot anymore and run anything (hum!) from OS/2.  Where am I
 LA>> wrong? Is it possible to install Win3.1x _after_ Warp 3 red spine
 LA>> on an HPFS partition? Or use another trick?

 AB> _If_ you want to have DUAL BOOT or use Win 3.1 then your boot
 AB> drive has to be Fat 16 formated and DOS/WIN3.1 installed..  That
 AB> does not prevent you from booting up under OS/2 you just loose the
 AB> benefits of the HPFS system on that drive..  You can still have
 AB> any other dirves formated HPFS and DOS/WIN3.1 can access them _if_
 AB> you boot up OS/2 and use them from there..  _If_ you do not want
 AB> DUAL BOOT or WIN3.1 installed then all your drives can be HPFS
 AB> format.

You *only* have to have FAT for Dual Boot. It is quite possible to use
an existing version of Win 3.1 on an HPFS primary partition with a
little care. I've done it - see my post to Louis.

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)
231/992
633/260
2501/209

+----------------------------------------------------------------------------+

From: Kenneth Duke                                      10-Dec-99 21:29:26
  To: Fred Springfield                                  11-Dec-99 06:20:20
Subj: Re: SIO and Y2K

*** Quoting Fred Springfield from a message to All ***

FS> Does anyone know if there are any y2k issues with the SIO drivers?

FS> It would be nice to know if there are--because, then we could put the 
FS> IBM drivers back in.

FS> Fred Springfield Plymouth, MN

Fred, personally, I didn't know SIO had anything to do with Time/date stuff
inside OS/2...

What would be effected?


---
 * Origin: telnet://pcnashville.dhs.org (1:116/158)
278/111

+----------------------------------------------------------------------------+

From: Linda Proulx                                      10-Dec-99 21:33:09
  To: Stewart Honsberger                                11-Dec-99 06:20:20
Subj: Re: Happy Holidays!

Greetings and Salutations,

     -=> Stewart Honsberger wrote to Linda Proulx <=-

 LP> happy millenium.

 SH> Wow.. You really got in there early.

 SH> Only 1 year, 21 days until the milenium!

I gave up.  Who am I to change the big party agenda |-).


... "I try to keep an open mind, but not so open that my brains fall out."
--- MultiMail/MS-DOS v0.32
 * Origin: Robin's Universe BBS - Winnipeg MB (1:348/807)
278/111

+----------------------------------------------------------------------------+

From: Stewart Buckingham                                11-Dec-99 12:22:19
  To: Peter French                                      11-Dec-99 10:02:24
Subj: Communicator Fatal Error

Hi Peter,

>> I just learned from Mike that os2pref.js = prefs.js.

> Something quite strange with your setup.  os2pref.dll is the only file of
> that name on my 4.61 install.  prefs.js will not be recreated on startup as
> it is a system file that I was warned should be edited with great care, as
> any corruption will stop NS working.  (p.s. did you ever - edit?)

> I don't have a 4.40 on my system any more as the testing showed 4.61 to
> be far superior from a feature and stability view.  However, I can't
> remember 4.40 asking for multiple user setup - so I suspect that there
> shouldn't be a user directory.  So,

Oh, there is a users directory in 4.04. Anyhow, I solved my problem by
reinstalling 4.04 over my existing copy. It fixed my spurious error msg of
being "unable to parse os2prefs.js", even though it still doesn't exist
anywhere on my system. I really wanted to understand how to fix it without
having to take the big hammer and reinstall. That way I might have had a
chance to understand what caused the error in the first place.  Nope, I never
did edit this file.

> 1) why bother with 4.40 reinstall 4.61

Oh I've just recently done that. I now have 2.02, 4.04 and 4.61 installed :)
How do you overcome the problem 4.61 apparently has when it stops downloading
large files without completing. I haven't tried it personally, which is why I
still have/use 4.04, but a number of people have mentioned it's a problem.

> 2) DON'T EDIT prefs.js with anything other than EPM.  (I added the
> user_pref("toolbar.logo.frames",8); to mine without it complaining.

I won't :)

> 3) if u want to retain your setup, maybe get a new perfs.js from a
> working system - I'll willingly send you mine (4.61)

Thanks. My prefs.js work perfectly now in 4.04 and 4.61.

> 4) retain your user files and reinstall from the download archive, then
> see if perfs.js is recreated - may be a leftover from an aborted 4.61?
> or a previous 4.40 install to different directories (did you move it?)

Thanks. Someone else suggested a 4.61 abort, but I hadn't downloaded it at
that stage. Hadn't moved it either.

> 5) confirm categorically that there is a perfs.js on a working 4.40
> install.  Mine has a bunch of path specific statements so be aware
> that they will not transplant easily.  I assume that the file is
> created at install time using install values.

Well after I reinstalled 4.04 on top of an existing 4.04 everything worked as
expected. I could not find any corruption in my old prefs.js and the new
install accepted all the stuff in my old prefs.js. This was why the error
about "could not parse os2prefs.js" was so mysterious.

> Hope this helps and you don't feel that the suggestions are too trivial

Well, these were all good suggestions as to possible problems and solutions
some of which I've already tried or taken up. Thanks for your time and help.

Stu/2

--- BBBS/2 v3.50 Flag-A
 * Origin: The Chili Channel * OS/2 - Java - Linux * chilies.com * (6:751/222)

+----------------------------------------------------------------------------+

From: Stewart Buckingham                                11-Dec-99 12:42:25
  To: Holger Granholm                                   11-Dec-99 10:02:24
Subj: not enough diskspace

Hi Holger,

> Known problem :-(  I too installed memsize but in my case I never got
> it to work so I deleted it. However, I found an entry in the OS2.INI
> still referring to memsz and the directory it had been installed in.

> So I asked Rick Papo for a proper uninstall program. In the meantime
> I installed memsz again into the same directory as before.

> When I ran the uninstall.cmd that I received from Rick, it told me that
> it couldn't find memsize and that it "probably" wasn't installed !!!!

> Then I deleted the whole shebang again but the reference of course is
> still in the .INI file.  God only knows how many references there are
> to programs that have been installed and then removed again.

There is quite a good program called Service Center 3.0 (which presumably can
be found on Hobbes) which (among other things) has quite a good class/ini
browser/deleter. You might give it a try.

Stu/2

--- BBBS/2 v3.50 Flag-A
 * Origin: The Chili Channel * OS/2 - Java - Linux * chilies.com * (6:751/222)

+----------------------------------------------------------------------------+

From: Leonard Erickson                                  11-Dec-99 02:22:04
  To: Fred Springfield                                  11-Dec-99 10:02:24
Subj: SIO and Y2K

 -=> Quoting Fred Springfield to All <=-

 FS> Does anyone know if there are any y2k issues with the SIO drivers?

It's hard to see *how* serial drivers *could* have y2k issues. 

Think about it. When do they *ever* deal with the date or even the
time?


--- FMailX 1.48a
 * Origin: Shadowshack (1:105/51)
231/992
633/260
2501/209

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    09-Dec-99 11:35:00
  To: Louis Aubree                                      11-Dec-99 13:39:21
Subj: Warp 3 install

Hello Louis,

06 Dec 99 22:32, Louis Aubree wrote to Gord Hannah:

LA> I think that Warp _red_ spine has to be installed _after_ DOS and
LA> Win3.1x, on the same primary partition,

NO!!! Warp 3 red spine can be installed and works fine without DOS and without 
any windows version.

LA> so this partition has to be FAT16 formated.

No, HPFS is fine and is in fact better than FAT.

LA> Then, the user could choose to never use Dual Boot anymore and run
LA> anything (hum!) from OS/2.

yes, almost anything.

LA> Where am I wrong?

You seem to be utterly confused. :)

LA> Is it possible to install Win3.1x _after_ Warp 3 red spine on an HPFS
LA> partition?

hmm, I don't know if it's possible to _install_ win3.1 on HPFS, because that
would have to be done in an VMB under OS/2 (I never tried that), but you can
install win3.1 under plain booted DOS and under OS/2 backup that win3.1
installation, reformat the partition (where win3.1 was installed) to HPFS, and 
put win3.1 back where it was installed.

LA> P.S. Eddy Thilleman also replied: he also believes Warp 3 red cannot
LA> be installed on HPFS.

I never said that!! I am sure about that. You seem to have mixed that up too.
Show me where you believe I've said that. :)

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... OS/2 - 100% FAT free!
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)
772/1

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    09-Dec-99 11:52:15
  To: Craig Ford                                        11-Dec-99 13:39:21
Subj: Help!

Hello Craig,

07 Dec 99 18:46, Craig Ford wrote to All:

CF> installation to Merlin, and tried to install FP12 to it. Alas,
CF> application of the Fixpak failed due to a checksum error in
CF> PMMERGE.DLL.

I've tried to apply fixpak 12, but got tons of errors and even (I think) a
trap, so I returned to FP9.

CF> Would some one be so kind as to tell me the size and timestamp of
CF> PMMERGE.DLL in a virgin Warp4 installation?

My Warp 4 is already at fp9

 8-10-98 12:14      1.238.971      0 a---  PMMERGE.DLL

CF> It would also help if someone could tell me in which immage file on
CF> the distribution CD it is contained.

I don't know that. Maybe someone else?

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... "Laddie, ya think ya might like ta... rephrase that?" -- Scott
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)
772/1

+----------------------------------------------------------------------------+

From: Will Honea                                        11-Dec-99 12:22:01
  To: Peter Knapper                                     11-Dec-99 12:22:01
Subj: HPFS Directories.

Peter Knapper wrote to Will Honea on 12-11-1999

PK> THUNK! That was a brain cell falling into place, thanks 
PK> Will, I needed that! I already have DFSEE here and had 
PK> forgotten about it! Thats what happens when you have too 
PK> many fingers and too many pies......;-) 

I keep a bottle of Windex on the shelf for cleaning the monitor
screen.  Ocassionally, I also apply it to my navel so I can see what
I'm doing...


PK> It looks like the drive mapping schemes used by each HA do 
PK> not exactly match, and this could be leading to confusion 
PK> when partitions are changed size initial set up and certain 
PK> types of errors occur and CHKDSK has to recover things.

Careful - we had a full scale war on this topic a year or so back and
I think the end result was an armed truce <g>.  Were it me, I would
clear off the drive in question  and do a low level format - REALLY
start from scratch.

DFSEE is overkill for most uses but when it's needed it's worth the
effort to figured out what it's telling you.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Stewart Honsberger                                11-Dec-99 10:17:04
  To: Linda Proulx                                      11-Dec-99 17:16:06
Subj: Re: Happy Holidays!

10 Dec 99 21:33, Linda Proulx wrote to Stewart Honsberger:

 SH>> Only 1 year, 21 days until the milenium!

 LP> I gave up.  Who am I to change the big party agenda |-).

The two milenium celebrations are a corporate creation, solely to force
people to buy more "milenium" edition merchandise.

I say buy NOTHING this year! Don't buy a single thing with the word
"milenium" stamped on it! NOTHING! Have your typical new-years party,
but without the milenium baloons and napkins!

Show these corporate schmucks that we're not that stupid!

Stewart Honsberger,
  blackdeath@tinys.oix.com

... REAL SysOps disconnect the speakers.
-!- GOPGP/2 v1.23

--- Msged/2 TE 05
 * Origin: Blackdeath BBS - Private (1:229/604)
2320/38

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    10-Dec-99 10:12:16
  To: Herbert Rosenau                                   11-Dec-99 21:24:18
Subj: cache

Hello Herbert,

08 Dec 99 18:13, Herbert Rosenau wrote to Eddy Thilleman:

ET>> 9 lazy write workers? I haven't seen mentioned that high before.

HR> Why not?

I haven't seen that before.

HR> The optimasion was done at a time this computer was used as
HR> - 3 lines node with mostly ISDN throughput
HR> - developement mashine (edit/compile/debug...) with all lines running
HR> - some other aktive tasks

so that number of lazy write workers maximize the write performance to disk
with a lowest possible CPU usage, so maximizing transfer speed?

HR> The optimasion was at least done with help another node to become the
HR> highest possible transfer rate during an connect on both lines and
HR> running tosser in background.

OK.

HR> I'd found that throwing on the cache parameters has the most
HR> incredible effect on the transfer rates. I'd found values that are
HR> commonly nearst the physical maximum (7950/15500 cps as sender and
HR> 7850/14500 as receiver of *.bmp)

HR> Exchange of large *.bmp can kill the telko's convey station if both
HR> sides can send with maximum speed on direct CAPI. :-)

Don't tell your telco (Deutsche Telekom) that, or they will limit the highest
possible transfer speed to 7000 cps. ;-)

HR> Without the excessive optimasision step my transfer rate where more
HR> than 200 cps less.

HR> Yes. But not this extensive testing to find the best parameters.

OK.

HR> After that playing with the cache parameters can speed up the lines
HR> more.

I am just looking for more information about the number of lazy write workers.

HR> Changes can be made without reboot. call cache.exe with the
HR> propper parameters.

I know. :)

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... "Pieces of Nine! Pieces of Nine!"  Another parroty error!
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    10-Dec-99 10:29:20
  To: Linda Proulx                                      11-Dec-99 21:24:18
Subj: Newer update

Hello Linda,

08 Dec 99 20:41, Linda Proulx wrote to Cyrill Vakhneyev:

CV>> Get latest ibm1s506.add (idedasd.exe at IBM's DriverPack). RTFM

LP> Do you know the address for it?

The URL's to IBM's Online Device Driver Pak:

OS/2 Device Driver Pak On-Line - HOME PAGE
http://service.software.ibm.com/os2ddpak/

OS/2 Device Driver Pak On-Line - Device Categories
http://service.software.ibm.com/os2ddpak/html/index.htm

You can get on the second one via the first, but I go directly to the second
page.
The second page list all device categories, you choose the category and under
that category all makes (brands) are listed, you select the brand.... it's
self-explaining.

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... If God lived on Earth, people would knock out his windows.
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    10-Dec-99 10:43:10
  To: Holger Granholm                                   11-Dec-99 21:24:18
Subj: not enough diskspace

Hello Holger,

07 Dec 99 20:30, Holger Granholm wrote to Kees Bergwerf:

HG> Then I deleted the whole shebang again but the reference of course is
HG> still in the .INI file.  God only knows how many references there are
HG> to programs that have been installed and then removed again.

Don't you use free Henk Kelder's WPTOOLS package to clean up your INI files?
There are also free INI editors.

I use Unimaint (payware) which also has that functionality.

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... *!. <-- Baseball Tribble
--- GoldED/2 3.0.1
 * Origin: Windows95 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    10-Dec-99 10:44:08
  To: Steve Mccrystal                                   11-Dec-99 21:24:18
Subj: cache

Hello Steve,

08 Dec 99 06:40, Steve McCrystal wrote to Eddy Thilleman:

ET>> 9 lazy write workers? I haven't seen mentioned that high before.

SM> I noticed that, and hadn't seen it before either, so I checked the
SM> online docs. They say that LAZY takes one of two parameters... OFF or
SM> ON.

I know, the CMDREF.INF online book is outdated.

SM> I then modified my own cache statement, changing LAZY:3 to LAZY:9
SM> and the resulting display shows there are indeed 9 lazy workers
SM> allocated.  I have no idea what difference it might make, especially
SM> given the obvious inaccuracy of the docs, but I think I'll play with
SM> it a bit! :^)

It optimizes writing to disk, so the system looses less performance with
disk-intensive applications. I don't have any more information.

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... Warp 4, Scotty... and close those damn Windows!
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Peter Knapper                                     12-Dec-99 09:45:28
  To: Will Honea                                        11-Dec-99 21:24:18
Subj: Power failures

Hi Will,

 WH> Peter Knapper wrote to Eddy Thilleman on 12-10-1999

PK> That power failures are MONTHS apart is irrelevant, there 
PK> are other reasons why the system fails to shut down 
PK> correctly. Regardless of the reason for it, if the system 
PK> is NOT shut down "normally", then the HPFS partition ROOT 
PK> directory entry cannot be found upon restart!

 WH> When you put it that way, it caught my eye.  So Murphy lives at you
 WH> house now?

I am trying to persuade him to leave.......;-)

As you have probably seen by now, it looks like its a SCSI controller geometry 
difference problem. I just need to clear everything off the drive,
re-partition the entire volume and things should be back to normal (he says
hopefully)...

 WH> Tell Murph hello as he's a regular here.

Ok, I will send him home then.......;-)

Cheers..........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
30185/10

+----------------------------------------------------------------------------+

From: Andy Brown                                        11-Dec-99 09:00:21
  To: George White                                      11-Dec-99 21:24:18
Subj: Warp 3 install

Hello George.

09 Dec 99 07:42, you wrote to me:


 GW> You *only* have to have FAT for Dual Boot. It is quite possible to use
 GW> an existing version of Win 3.1 on an HPFS primary partition with a
 GW> little care. I've done it - see my post to Louis.

I saw it and saved a copy for reference..  It makes sense just wish I had
thought of it over a year ago when I first installed Warp3..


Andy

--- MyTosser 1.20/Pro
 * Origin: College Area Hub, San Diego,CA (MO)  (1:202/805)
278/111

+----------------------------------------------------------------------------+

From: George White                                      10-Dec-99 07:58:18
  To: Holger Granholm                                   12-Dec-99 03:28:24
Subj: not enough diskspace

Hi Holger,

On 07-Dec-99, Holger Granholm wrote to Kees Bergwerf:

 HG> Then I deleted the whole shebang again but the reference of course
 HG> is still in the .INI file.  God only knows how many references
 HG> there are to programs that have been installed and then removed
 HG> again.

Lots! :-(. That's why I occasionally run the indispensible INI
maintenance tools from Henk Kelder over them occasionally. Cleaning
out all the obsolete references helps keep their size down.

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)
138/2

+----------------------------------------------------------------------------+

From: Linda Proulx                                      11-Dec-99 21:28:20
  To: Eddy Thilleman                                    12-Dec-99 06:13:23
Subj: Re: Newer update

Greetings and Salutations,

     -=> Eddy Thilleman wrote to Linda Proulx <=-

 LP> Do you know the address for it?

 ET> The URL's to IBM's Online Device Driver Pak:

Thanks for the info.  Sent it to my internet connection.

Anon,

Linda

... Happy Holidays to all, and to all a GREAT year!
--- MultiMail/MS-DOS v0.32
 * Origin: Robin's Universe BBS - Winnipeg MB (1:348/807)
278/111

+----------------------------------------------------------------------------+

From: Stewart Buckingham                                12-Dec-99 15:37:18
  To: Murray Lesser                                     12-Dec-99 06:37:17
Subj: not enough diskspace

Hi Murray,

> IMO, every OS/2 user should have a program that cleans up the .INI
> files and all the other "handle" information that is left behind when
> object files are deleted from the system.  I use UniMaint v 5.10.02 (a
> shrink-wrapped program) that also does many other things (such as
> backing up the desktop and essential files).  I run the cleanup portion
> of UniMaint after every object deletion, and the backup portion after
> every desktop change (I keep the most recent five backups).  But, I am
> told that there are many other programs that clean up the two .INI
> files, some of which are freeware.  I suggest that you look into it.

This is maybe not so much directed at you, but maybe more to others who can
suggest any good freeware .INI cleanup programs. I agree they are esscential
in order to run a tight ship.

Stu/2

--- BBBS/2 v3.50 Flag-A
 * Origin: The Chili Channel * OS/2 - Java - Linux * chilies.com * (6:751/222)

+----------------------------------------------------------------------------+

From: James Mckenzie                                    11-Dec-99 21:31:08
  To: All                                               12-Dec-99 07:18:11
Subj: Weird Y2K bug

Hello All!

I just visited a site called www.firstsource.com and received a cookie that
expires in 1970.  This is with Netscape 4.61.  Anyone care to confirm this.

BTW, I'm running Warp 4 with FP10.

James

... It's called Windows cuz that's what you wanna throw 'em outta!
--- GoldED/2 3.0.1
 * Origin:  OS/2 Support * Your place for OS/2 information and Files
(1:15/64)

+----------------------------------------------------------------------------+

From: Herbert Rosenau                                   12-Dec-99 13:53:09
  To: Eddy Thilleman                                    12-Dec-99 13:21:29
Subj: cache

ET>>> 9 lazy write workers? I haven't seen mentioned that high before.

HR>> Why not?

 ET> I haven't seen that before.

No wounder. This parameter exists since FP5 or so and is nearly undocumented.
You have to read the readmes of your fixpacks carefully to find that.

HR>> The optimasion was done at a time this computer was used as - 3
HR>> lines node with mostly ISDN throughput - developement mashine
HR>> (edit/compile/debug...) with all lines running - some other
HR>> aktive tasks

 ET> so that number of lazy write workers maximize the write
 ET> performance to disk with a lowest possible CPU usage, so
 ET> maximizing transfer speed?

Yes.

HR>> I'd found that throwing on the cache parameters has the most
HR>> incredible effect on the transfer rates. I'd found values that are
HR>> commonly nearst the physical maximum (7950/15500 cps as sender and
HR>> 7850/14500 as receiver of *.bmp)

HR>> Exchange of large *.bmp can kill the telko's convey station if
HR>> both sides can send with maximum speed on direct CAPI. :-)

 ET> Don't tell your telco (Deutsche Telekom) that, or they will limit
 ET> the highest possible transfer speed to 7000 cps. ;-)

No. They do often switch off theyr stations fridays at 16.30h (end of work)
for the whole weekend and if you would them running you have to pay an extra
charge for to do so. Because they havend done that and its you fault that you
can't phone. Sometimes (in the evening - end of work by telko) you can call
out - but not called or you can't call out but called.........) Always it's
YOUR fault, never the telko's)

So if you can - you MUST try to reset the station to hold state. Sending a lot 
of constat 0 or 1 (a *.bmp is a file of that kind) is the most perfect way to
do so. :-)

 ET> I am just looking for more information about the number of lazy
 ET> write workers.

Good. You'll see most effect if you have only 16 MB RAM and the maximum cache
size (on HPFS 2MB). 


--- Sqed/32 1.15/development  301:
 * Origin: Diese Werbeflaeche ist zu vermieten (2:2476/493)
138/2

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       11-Dec-99 06:54:00
  To: PETER KNAPPER                                     12-Dec-99 17:15:14
Subj: HPFS Directories.

Some senseless babbling from Peter Knapper to All
on 12-07-99  21:10 about HPFS Directories....

 PK> Hi Folks,

 PK> A simple question.......;-) Where is the FIRST root directory entry
 PK> located on an HPFS volume? I know that HPFS uses a directory recording
 PK> methodology similar to a B-Tree, and it writes files in BANDS across
 PK> the partition, however the very FIRST directory entry MUST be located
 PK> somewhere that can be calculated as a FIXED location for that
 PK> particular partition. Alternatively there must be a data structure
 PK> within an HPFS partition that contains details of the partition
 PK> "layout". Now how can I find out where that location is? 

ftp://hobbes.nmsu.edu/pub/incoming/hpfsut02.zip

or

ftp://hobbes.nmsu.edu/pub/os2/util/disk/hpfsut02.zip

Most of the information I used to write that program can be found at:

http://www.edm2.com/

Meta Index -> OS/2 -> High Performance File System

 PK> My need is thus. I have a 2GB partition located in the middle of a
 PK> drive (other paritions before and after it) that is _SOMETIMES_
 PK> corrupting its Root directory entry or a pointer to the Root directory
 PK> entry, if there is a power failure and the system is not shut down
 PK> cleanly. If it IS shutdown cleanly, the next boot up is fine and all is
 PK> well. If a startup invokes CHKDSK, it compains that it "cannot find the
 PK> Directory \", and it then tries a recovery which locks the machine
 PK> SOLID after 173 files have been found! I have to boot from Floppy and
 PK> run CHKDSK from the commandline. In this case CHKDSK E: /F:2 detects
 PK> the exact same problem, but it succeeds in fixing it and recovers ALL
 PK> the files EVERY TIME! These files are perfect with no errors. I can
 PK> then place them back where they belong, and everything works perfect,
 PK> until the power fails again.......;-( Also interesting is that only
 PK> FILES are lost, never Sub-directories (there are about 15,000 files on
 PK> the volume). 
 PK> My thinking is that if the HD has a faulty track right at the begining
 PK> of the partition I can shrink the partition and leave that Cylinder
 PK> free. With FAT this could work, but with HPFS I am not so sure.
 PK> Ultimately I need a new drive, but I was just wondering if I can work
 PK> around this. 
 PK> Any useful bits of info appreciated.

As you'll find if you look over the program to which I referred to, the
location of the root directory FNode is pointed to by offset 0x0c in the
SuperBlock sector, which is logical sector number 16 (where the boot sector
is LSN 0).  It will inevitably be located at the sector immediately
following the directory band, and the 20 spare directory blocks (towards
seek-center on the drive).

If that sector is flaky, you're likely to run into more problems than just
a missing root directory.  As far as I know, there's no provision to
automatically relocate the SuperBlock, which makes sense given the fact
that its location is fixed, and not pointed to by any other structure.

Shrinking the partition as you say should work, if that's the source of the
problem.  It's not, of course, as simple as modifying the partition table
entry.  You'll need to use something like Partition Magic, or do a
backup/partition/restore.

Mike Ruskai
thannymeister@yahoo.com


... OS/2 users do EVERYTHING while formatting floppy disks.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
138/2

+----------------------------------------------------------------------------+

From: Preston Smith                                     12-Dec-99 08:32:20
  To: All                                               12-Dec-99 17:15:14
Subj: TCPIP Update

Hello All!

Thnaks to Will and James for thaeir helpful hints

I upgraded MPTS to W08424, and applied the UN_0980 fixpack to TCPIP.  Invoking 
'INETVER' now gives me 4.02w.

All went well but I ended up with one problem.  I use a script that drops my
BBS off line and invokes pppdial and Internet rex to pick up and send my Fido
mail via FTP and e-mail.  Since I did the update to TCPIP the script no longer 
kills the link to my ISP when all required action are completed.

Were there changes in any of the components such as pppkill that mayrequire me 
to change my scripts?

Thanks

Preston (prsmith@navnet.net)

---
 * Origin: Canadian Connection, St Margarets Bay NS (902)826-7774 (1:251/11)
138/2

+----------------------------------------------------------------------------+

From: Steve McCrystal                                   11-Dec-99 07:42:28
  To: Herbert Rosenau                                   12-Dec-99 20:14:14
Subj: cache

;
In a msg of <Friday December 10 1999>, Herbert Rosenau writes to Steve
McCrystal:
;
Herbert,

 SM>> I noticed that, and hadn't seen it before either, so I
 SM>> checked the online docs. They say that LAZY takes one of two
 SM>> parameters... OFF or ON.

 HR> Read the readmes to your Fixpack. It is declared there. The docu
 HR> is old.

 HR> readahead:[0|1] is the only choice the fixpack tells this
 HR> parameter as n - but all other than 0 (read ahead off) or 1 (on)
 HR> will not understund by cache.exe.

Thanks!  As I mentioned, I have proven, at least to myself, that your
assessment is correct, but I do wish they would update the online help.  I
have used it infrequently because it is normally too much of a PITA to find
anything, but now even less because much of it is just plain wrong! :^)

-[Steve]-

--- GoldED/2 3.0.1/#
 * Origin: -[Steve's Place]- New Berlin, WI (FidoNet 1:154/731.2)
278/111

+----------------------------------------------------------------------------+

From: Fred Springfield                                  12-Dec-99 11:14:05
  To: Kenneth Duke                                      12-Dec-99 20:14:14
Subj: Re: SIO and Y2K

KD> *** Quoting Fred Springfield from a message to All ***
KD> 
KD> FS> Does anyone know if there are any y2k issues with the SIO drivers?
KD> 
KD> FS> It would be nice to know if there are--because, then we could put the 
KD> FS> IBM drivers back in.
KD> 
KD> FS> Fred Springfield Plymouth, MN
KD> 
KD> Fred, personally, I didn't know SIO had anything to do with
KD> Time/date stuff  inside OS/2...
KD> 
KD> What would be effected?

I don't know--which is why I am asking.

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  Success--that good feeling after winning something.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
278/111

+----------------------------------------------------------------------------+

From: Fred Springfield                                  12-Dec-99 11:14:05
  To: Leonard Erickson                                  12-Dec-99 20:14:14
Subj: SIO and Y2K

LE>  -=> Quoting Fred Springfield to All <=-
LE> 
LE>  FS> Does anyone know if there are any y2k issues with the SIO drivers?
LE> 
LE> It's hard to see *how* serial drivers *could* have y2k issues. 
LE> 
LE> Think about it. When do they *ever* deal with the date or even the
LE> time?
 
I don't know--which is why I am asking.

However, one might make the following observation;

           All your internet stuff goes through the COM port, and all the
           tcpip stuff requires handshaking and date/time confirmation
           as part of the IP protocol.

And ask the following question;

          Does the driver just pass all this stuff through without reading
          it in any way, or does it read part of it for any reason, and
          therefore be vulnerable to failure?

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  Success--that good feeling after winning something.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
278/111

+----------------------------------------------------------------------------+

From: Fred Springfield                                  12-Dec-99 11:26:03
  To: All                                               12-Dec-99 20:14:14
Subj: New Y2K Logic

1)  Old Fixpak Rule-If it ain't broke, don't fix it.
    New Rule--     It's all broke, by definition.

2)  Old Fixpak Rule-Only install a fixpak if it fixes something you
need.
     New Rule--     Install the latest version, because you need the Y2K
                       part of it.

3)  Old Fixpak Rule-YMMV (your mileage may vary, and if it doesn't
work,
                       back it out)
    New Rule--      YMMWV (your millenium mileage will vary--you can't
                       back it out, because you really need it--check closely
                       for undesirable side effects, because undoubtedly
                       there will be some)
     
This, after going through my Warp Connect and Warp 4 systems from 
top-to-bottom to make them Y2K ready.

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  If at first you don't succeed, try again--harder.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
278/111

+----------------------------------------------------------------------------+

From: Jack Stein                                        12-Dec-99 10:08:16
  To: Eddy Thilleman                                    12-Dec-99 20:14:14
Subj: cache

Eddy Thilleman wrote in a message to Steve Mccrystal:

ET>> 9 lazy write workers? I haven't seen mentioned that high before.

SM> I noticed that, and hadn't seen it before either, so I checked the
SM> online docs. They say that LAZY takes one of two parameters... OFF or
SM> ON.

SM> I then modified my own cache statement, changing LAZY:3 to LAZY:9
SM> and the resulting display shows there are indeed 9 lazy workers
SM> allocated.  I have no idea what difference it might make, especially
SM> given the obvious inaccuracy of the docs, but I think I'll play with
SM> it a bit! :^)

 ET> It optimizes writing to disk, so the system looses less
 ET> performance with disk-intensive applications. I don't have
 ET> any more information. 

I, and someone recently in here, had problems with modum overrun errors after
installing newer IBM1S506.add drivers.  I know I messed around a good bit
trying to change paramaters in the driver to fix it, and ended up going back
to the old driver, which works fine.  I wonder if this LAZY cache thing would
fix that?  Sounds like it might.
                                              Jack 
--- timEd/2-B11
 * Origin: Jack's Free Lunch 4OS2 USR 56k Pgh Pa (412)492-0822 (1:129/171)

+----------------------------------------------------------------------------+

From: Jack Stein                                        12-Dec-99 10:14:08
  To: George White                                      12-Dec-99 20:14:14
Subj: Warp 3 install

following up a message from Andy Brown to George White:

 AB> Hello George.

 AB> 09 Dec 99 07:42, you wrote to me:


 GW> You *only* have to have FAT for Dual Boot. It is quite possible to use
 GW> an existing version of Win 3.1 on an HPFS primary partition with a
 GW> little care. I've done it - see my post to Louis.

 AB> I saw it and saved a copy for reference..  It makes sense
 AB> just wish I had thought of it over a year ago when I first
 AB> installed Warp3.. 

I figured the method you listed would work, considering WIN3x is just another
DOS app.  The part I didn't figure was why you would need to run the install
after you installed WIN3.1?   I wouldn't have figured the install would even
be available on the Red Spine version.  What does it do?  

The obvious caveat I guess is that the OS/2 version of WIN is recompiled and
optimised somehow for OS/2.  I never ran anything other than the OS/2 blue
version under OS/2 myself, so I don't know what is so good about the OS/2
version, looks the same as the one  run under MSDOS, which is not so hot.

                                              Jack 
--- timEd/2-B11
 * Origin: Jack's Free Lunch 4OS2 USR 56k Pgh Pa (412)492-0822 (1:129/171)

+----------------------------------------------------------------------------+

From: Will Honea                                        12-Dec-99 18:21:00
  To: Preston Smith                                     12-Dec-99 18:21:00
Subj: TCPIP Update

Preston Smith wrote to All on 12-12-1999

PS> Hello All!
PS> 
PS> Thnaks to Will and James for thaeir helpful hints
PS> 
PS> I upgraded MPTS to W08424, and applied the UN_0980 fixpack 
PS> to TCPIP.  Invoking 'INETVER' now gives me 4.02w.
PS> 
PS> All went well but I ended up with one problem.  I use a 
PS> script that drops my BBS off line and invokes pppdial and 
PS> Internet rex to pick up and send my Fido mail via FTP and e-
PS> mail.  Since I did the update to TCPIP the script no longer 
PS> kills the link to my ISP when all required action are 
PS> completed.
PS> 
PS> Were there changes in any of the components such as pppkill 
PS> that mayrequire me to change my scripts?

I can't think of anything, Preston, unless it's a timing issue.  Try a
long pause between your end action and the pppkill call.  You might
also learn something by removing the pppkill call from your script then
running it manually from a command line but it looks the same to me as
it's always been.

Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         04-Dec-99 10:25:16
  To: Eddy Thilleman                                    13-Dec-99 03:32:20
Subj: cache

 ET> Is there an advantage to have more than one lazy write workers on the
 ET> HPFS cache? Does this help with the performance when writing to disk
 ET> (HPFS partition)?

It certainly helps in the case where one has more than one physical disc unit. 
 It should also in theory help in the case where one has a single physical
disc but that disc is SCSI and supports tagged command queueing.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         09-Dec-99 10:32:20
  To: Murray Lesser                                     13-Dec-99 03:32:21
Subj: Multiple visible primary partitions

 JP>> I, in my turn, (perhaps because I have never used one) don't remember
 >> offhand when the PS/2 came along, but I do happen to know that the
 >> whole idea of an "extended partition" was new to MS-DOS version 3.3. 
 >> MS-DOS 3.2 and earlier didn't know about "primary" partitions.  It
 >> just had "partitions", and there could be a maximum of four of them. 
 >> If they were formatted as FAT, they could be a maximum of 32MeB in
 >> size, meaning that the largest possible "all FAT" hard disc size was
 >> approximately 128MeB .

 ML>     "Possible" from an addressing standpoint doesn't necessarily mean
 ML> "exists."  According to Deitel and Kogan (The Design of OS/2), DOS
 ML> 3.3 was introduced in 1987 to support the PS/2 80386/80387 real mode
 ML> and the 3.5" 1.44 MB diskette.  I bought my PS/2 model 80 (the only
 ML> model in the original PS/2 release with an 80386) in early 1988 (the
 ML> machine died in late 1999).  IIRC, the maximum available hard-drive
 ML> capacity at the time of that first release was two 70 MB ESDI drives.

Which of course still proves my original point.  One could not have made use
of a single 70MeB hard disc drive *without* having multiple visible primary
partitions, given that each individual partition couldn't have been larger
than 32MeB.  Indeed, one would have used three out of a maximum of four.

So, as I said before, it isn't the case that Microsoft has introduced
something *new* here to shift the goalposts and to confound other operating
systems, which is what you implied before and what you obliquely implied again 
at the end of the message that I'm replying to here where you talked about
monopolies ignoring their legacy customers.  The concept of multiple visible
primary partitions has a long pedigree going back to the earliest versions of
MS-DOS/PC-DOS, and the fact that OS2DASD.DMD doesn't support such an
arrangement must be viewed as OS/2 being incompatible with long-standing
existing practice.  And, ironically, it is *Microsoft* that is better
supporting legacy customers (who want to have multiple visible primary
partitions, just like they use to have) here.

One can of course argue, as several here have done, that having multiple
visible primary partitions is a concept that is no longer necessary given the
existence of extended partitions, and that OS/2 is therefore justified in not
supporting such a legacy arrangement.  I don't happen to agree with that
myself.  But one cannot argue, even by implication, that it is Microsoft that
changed the goalposts here.  It is OS/2 that has diverged from common practice 
in PC operating systems, not the other way around.

I suspect that this divergence was unintentional.  But intentional or not, it
is still a bug in OS2DASD.DMD that needs fixing.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         09-Dec-99 11:15:01
  To: MIKE RUSKAI                                       13-Dec-99 03:32:21
Subj: DETACH

 MR> I'm not talking about the foreground boost.  The window boost is
 MR> completely separate from the foreground boost.  It apparently applies
 MR> to any program which has a graphical window, and is applied
 MR> independently of the foreground boost.  

I don't see any mechanism for the kernel to know whether or not a process has
a window.  I can see a mechanism where it can tell whether a process is
started as a PM process.  The type of the process has to be passed to the
kernel internally within DosStartSession(), simply so that the PIB in user
space for the new process can be initialised with that type.  The kernel could 
check, at the point of creation of the process, for SSF_TYPE_PM and set a
"window boost" flag bit in the process control block.  But if this is indeed
the case (Where is Dennis Tonn when we need him? (-:), this is the only case
where the kernel itself is concerned in any way with the process type value. 
(And I find myself siding with Ivan on this.  The kernel should not be doing
this sort of thing.)

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         09-Dec-99 11:21:15
  To: MIKE RUSKAI                                       13-Dec-99 03:32:21
Subj: fdisk /query

 MR>> I'd be inclined to go with physical definition order.  

 JDBP>> You mean to simply enumerate all volumes on a single drive before
 JDBP>> proceeding to the next one ?

 MR> Yes.

This does have some merits.

 MR>> But my primary concern when writing the above was to criticize the 
 MR>> practice of assigning letters to primary partitions on separate 
 MR>> physical drives before assigning letters to any logical drives in 
 MR>> extended partitions.

 JDBP>> One can understand why it is this way, of course.  Choosing to
 JDBP>> enumerate all primary partitions first made MS-DOS 3.3 backwards
 JDBP>> compatible with MS-DOS 3.2 . 

 MR> Backwards compatible?  3.3 is when the extended partition came into
 MR> being, right?  If so, then backwards compatibility isn't the issue,
 MR> since that was broken by adding the extended partition.

The backwards compatibility was that on a system including an extended
partition one could boot either MS-DOS 3.2 or MS-DOS 3.3 and both would assign 
the same drive letters to the primary partitions.  In other words, adding an
extended partition to a disc didn't cause MS-DOS 3.3 to use different drive
letter assignments to the ones that MS-DOS 3.2 would use on the same disc,
even if the extended partition happened to be added in between two primary
partitions.

Put more simply: Microsoft, and the OEMs, didn't receive large numbers of
support calls from people who had added extended partitions to their hard
discs and discovered that they didn't see the same drive letters in MS-DOS 3.3 
as in MS-DOS 3.2.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         09-Dec-99 11:28:29
  To: MIKE RUSKAI                                       13-Dec-99 03:32:21
Subj: We need a new FDISK

 JDBP>> Maybe it's time for us to step boldly into the 1990s and drop this
 JDBP>> rule. 

 MR> I might try testing this out on the drive I recently added to a system
 MR> for testing.  It should be a fairly simple matter to write an FDISK
 MR> to do this type of partitioning.

If you need any help, let me know.  It would be good for such a utility to
exist.

 MR> The test will be when I see if OS/2's FDISK chokes on the
 MR> newly-partitioned drive.

As long as you ensure that the CHS values match the sector offsets, then I
suspect that it won't.  I've used OS/2's FDISK on discs where changes to the
way that the geometry was faked have meant that partitions were no longer
cylinder aligned, and don't remember encountering any such problems.  I don't
think that FDISK cares whether or not the cylinder alignment rule is followed
by existing partitions.  I think that all that it does is ensure that the
partitions that it itself creates are aligned.

From this, I suspect that the designers of OS/2's FDISK (if we knew who they
were) probably couldn't tell us the reason for the existence of this rule,
either.  (-:

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         11-Dec-99 10:18:03
  To: Murray Lesser                                     13-Dec-99 03:32:21
Subj: Multiple visible primary partitions

 ML> Available-space discussions make sense only when one remembers
 ML> that they are purely relative.  You really ought to understand that 8
 ML> MB is only 0.1% of an 8 GB drive (0.2% of a 4 GB drive, in case
 ML> arithmetic is difficult for you), so is in the noise as far as usable 
 ML> space on such drives is concerned.   One tenth of one percent isn't 
 ML> worth worrying about, let alone making a serious(?) suggestion that 
 ML> legacy drive usage be modified to "save" any part of it.

The suggestion that the cylinder alignment restriction in FDISK be limited was 
motivated by many years of seeing many people complain in this and other fora
that "Boot Manager consumes a whole 8MeB!  Utility X only consumes a couple of 
sectors.  Boot Manager is rubbish!".  Obviously, people *are* concerned by
such things -- quite a few people going by the number of times that I have
seen this sentiment expressed.  Indeed, having myself worked for many years
with a machine whose hard disc was continually around the 98% full mark, I can 
assure you that people *do* think that one tenth of one percent matters.

There were other reasons for suggesting it, as well.  As Will Honea pointed
out, this limitation doesn't seem to have any actual reason for existing. 
Unaligned partitions don't appear to cause any problem for PC/MS-DOS in
practice, which is the only operating system where one would expect such
problems to appear.  Removing the limitation would also eliminate the
favourite hiding area used by MBR viruses: the unused sectors between the
primary MBR and the start of the first partition on the next track.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         11-Dec-99 10:58:05
  To: Andrew Belov                                      13-Dec-99 03:32:21
Subj: odin-19991112

 AB>>> PMWINX   DLL   520559   4.12.98  20:35

 JdBP>> Have you checked (with a tool such as EXEHDR or TDUMP) that it
 JdBP>> actually exports something with ordinal number 1022, which is what
 JdBP>> the message is complaining about ?

 AB> This ordinal is reported as "Unused entry" in PMWINX.DLL.

There's your answer, then.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         11-Dec-99 11:01:28
  To: Eddy Thilleman                                    13-Dec-99 03:32:21
Subj: vkbd.sys

 JP>> There are two sorts of VDDs, "base" VDDs and "installable" VDDs.  The
 JP>> "base" VDDs are always loaded, since they are essential to the
 JP>> operation of a VDM.  The "installable" VDDs are the ones listed in
 JP>> CONFIG.SYS .

 ET> I don't know, I never looked into this.

I have, and you do now.  (-:

 JP>> There's a list of the "base" VDDs in the Virtual Device Driver
 JP>> Reference in the OS/2 DDK.

 ET> I don't think I have the OS/2 DDK. Is that available on internet?

http://service.software.ibm.com/ddk/

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         11-Dec-99 15:07:29
  To: Eddy Thilleman                                    13-Dec-99 03:32:21
Subj: fdisk /query

 JP>> [...] as many problems, would be to extend the Universal Naming
Convention
 JP>> to include local volumes.  Volumes would automatically be assigned
 JP>> names such as \\.\HARDDISK0PARTITION2 , [...]

 ET> This prevents the problem where many devices are in use they run out
 ET> of letters to assign to and it prevents the volume names from
 ET> shifting when a new partition is created when no harddisks are
 ET> changed, but that doesn't prevent the problem of shifting drive
 ET> letters or shifting volume names when a new harddisk is added before
 ET> the existing harddisks. For example if a new harddisk is added to
 ET> become the new harddisk 0 instead of an existing one and all the
 ET> existing harddisks are numbered in the order of the existing order
 ET> then all existing harddisks get a new number.

Indeed.  

Actually, it doesn't prevent the problem of partitions being renumbered when
one inserts or deletes a partition.  This is the problem with UNIX and linux
that many people are blind to that I mentioned to Peter Knapper.  UNIX and
linux don't have drive letters, but they do have automatically assigned minor
device numbers which change as partitions are added and deleted, and one thus
still has to spend time reconfiguring one's system.  The only practical
difference is that one is changing configuration files (and "device" files)
that operate in terms of minor device numbers instead of changing
configuration information that operates in terms of drive letters.

The best solution would, of course, be not to number partitions and hard discs 
at all, but to name them, so that one could, say, use a UNC name such as
\\.\DISK\EDDYS-DISK\EDDYS-OS2-PARTITION\CONFIG.SYS .  Unfortunately, the
design of the PC partition table simply doesn't allow for this.  There is no
place on a disc where one can store a name for the disc as a whole, nor is
there any place in a partition within a disc to store a name for a volume. 
One is thus forced to have machine-generated names such as "HARDDISC0" and
"PARTITION3", and this means numbering in some fashion.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 10:49:05
  To: Leonard Erickson                                  13-Dec-99 03:32:21
Subj: SIO and Y2K

 FS>> Does anyone know if there are any y2k issues with the SIO drivers?

 LE> It's hard to see *how* serial drivers *could* have y2k issues. 

 LE> Think about it. When do they *ever* deal with the date or even the
 LE> time?

The unregistered version of SIO creates a hidden file in the root of all
drives that contains date and time information so that it can determine how
many days it has been used for.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 11:00:03
  To: Peter Knapper                                     13-Dec-99 03:32:21
Subj: HPFS Directories.

 PK> WARNING : Device geometry and CHS-beginsector do not match LBA offset.
 PK>           Some possible causes are: Change in BIOS level or BIOS
settings,
 PK>           changed EIDE of SCSI adapter (or firmware) with different LBA
 PK>           mapping or an upgrade of DISK/SCSI device-drivers or filters
 PK>           (Fixpack ?).           
 PK>           Or the partition-table has been corrupted, possibly by a Virus.
 PK>           Id 02=D:
 PK> WARNING : Partition does not start on head-1 (cylinder boundary) Id 02=D: 

 PK> WARNING : Partition doesn't end on last head (cylinder boundary) Id 02=D: 

 PK> WARNING : Logical partition extends beyond extended-container Id 02=D:
 PK> WARNING : Extended partition extends beyond extended-container  Id 02=D:
 PK> WARNING : Extended partition extends beyond end of the disk
 PK>
 PK> [...]
 PK>
 PK> I now think I can figure out whats going on. About 5 months ago I
 PK> changed the SCSI HA from an Adaptec ISA card to an NEC based PCI
 PK> card. [...] It looks like the drive mapping schemes used by each HA 
 PK> do not exactly match, [...]
 PK>
 PK> I guess I will have to remove EVERYTHING off DRIVE 2, remove ALL
 PK> partitions on that drive, Re-boot and then re-allocate them again.
 PK> Hopefully this will fix the problem by updating the new controller
 PK> geometry info for ALL partitions. 

No you won't.  PARTLIST, in the OS/2 Command Line Utilities version 2.0, was
made for this very problem.  If you run it without any options, it will
display the raw partition information and a list of errors that it finds.  If
you run it with the /FIX option it will adjust the CHS start/end information
for each partition to match the logical sector start/offset information,
according to the current reported geometry of the drive.

PARTLIST is non-destructive, inasmuch as it doesn't require you to erase and
re-create partitions.  The only thing that it alters is the contents of the
partition table, specifically the CHS fields.  Nontheless, run PARTLIST
without the /FIX option to see what errors it *would* fix, and have a look at
them, before running it with the /FIX option to actually fix them.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 17:44:07
  To: Herbert Rosenau                                   13-Dec-99 03:32:21
Subj: Clunker update

 HR> Real it is a reverse stack:
 HR> app -> WinInitialise() --- until WinTerminate() PM controls the flow
 HR> of it
 HR> Here it makes the reverse stack ready. The first time an application
 HR> calls WinGetMsg() it losts (for that thread) the flow control to PM.

Replied in OS2PROG.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 17:45:17
  To: Herbert Rosenau                                   13-Dec-99 03:32:21
Subj: DETACH

 HR> But a thread my be a PM thread if the DLL is ready for PM. And you can
 HR> make it one if you declare it as PM in its *.def.

Replied in OS2PROG.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 17:50:22
  To: Lee Aroner                                        13-Dec-99 03:32:21
Subj: Install

 JdBP>> I think that Leonard is trying to make the point that using 
 JdBP>> FCBs for "fast deletions" is pointless in those 
 JdBP>> environments, because it *isn't* actually faster that doing 
 JdBP>> things the more up-to-date way using a simple 
 JdBP>> findfirst/findnext loop.

 LA> I *have* compared it Johnathan, and it's a whole big pile faster    
 LA> than running a loop, which, of course, is the backup routine in    
 LA> case the drive in question is HPFS (since warp intentionally    
 LA> traps if you try this on HPFS with a wildcard spec).

It's only faster on DOS, though.  It *isn't* faster on non-DOS operating
systems, such as OS/2 or Windows NT.  Try measuring it on something other than 
DOS.

This was demonstrated a year or so ago in this very echo, with people using
the 4DOS DEL command with and without the /Q switch (which selects between
using FCBs and using MS-DOS version 2.0 style deletion) and discovering that
the two operate at exactly the same speed.  Unfortunately, I don't remember
who it was who sat down and tested it.

 LA> Think about it...which is faster, looping 500 times to do a 
 LA> findnext/handle delete, or once to nuke the entire directory 
 LA> contents?

It's important to remember, however, that FCB wildcard deletion does *exactly
that* under the covers on operating systems such as OS/2 and Windows NT.  An
OS/2 VDM, for example, implements CP/M style wildcard deletion by internally
running a DosFindFirst/DosFindNext/DosFindClose loop.  This is the reason why
CP/M style file deletion *isn't* faster on non-DOS platforms.  It's doing
exactly the same thing as an application would be doing if it performed the
DosFind{First,Next,Close} loop itself.

The idea that "FCBs are faster" is only true when one uses DOS for one's
operating system.  But operating systems that are *not* based upon DOS but on
which one can run DOS programs, such as OS/2 and Windows NT, have been in
widespread use for 5 to 8 years now.  The generality that "FCBs are faster" is 
no longer true, and hasn't been for many years.  Even on DOS-Windows 3.1 or
DOS-Windows 95/98 with "32-bit file access" enabled it isn't true.  It wasn't
even true on DOS in the 1980s on machines attached to LANs.

So this "little trick" will go away because it is no longer useful to DOS
programmers, which is in turn because the premise that it is based upon is not 
true for the large majority of systems where DOS programs are run these days.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 17:51:21
  To: Peter Knapper                                     13-Dec-99 03:32:21
Subj: fdisk /query

 JdBP>> I'm not convinced that it gains one anything, though. 
 JdBP>> It makes the situation a lot worse, in some respects.
 JdBP>>
 JdBP>> First of all, by introducing an extra layer of 
 JdBP>> indirection into the whole process, it doubles the 
 JdBP>> reconfiguration overhead.  One has to have some  
 JdBP>> naming scheme for the raw volumes and a table of 
 JdBP>> mount directives, so that one can say "mount volume 
 JdBP>> X,Y at this point in the directory tree".
 JdBP>>
 JdBP>> One then has to have *another* table of drive letter 
 JdBP>> assignments to say "drive letter Q: is this point in 
 JdBP>> the directory tree".

 PK> ONLY if it is necessary to HAVE a drive letter there! Remember, in my
 PK> scenario this is for backwards compatibilty only!

The flaw is that the scenario fails to take into account that the system API
is constructed around the paradigm of multiple drives with independent
directory hierarchies.  Not only would you have to rewrite the operating
system with a new API, you'd have to rewrite all of the applications programs
as well.  Try to find a non-trivial application that *doesn't* need to do such 
simple things as querying the current directory (a procedure that requires a
drive number).

So yes, one *does* have to have drive letters.  One *does* have to have two
separate tables that the user has to maintain and configure, doubling the
hassle of configuration.

This is, of course, unless you are classing the supporting of *all* currently
existing OS/2 applications, 16-bit and 32-bit, as mere "backwards
compatibility".  (-:

A far simpler scheme is to provide control over the assignment of drive
letters to volumes using some mechanism such as the DRIVELETTERS directive
that I described to Mike.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         12-Dec-99 17:56:13
  To: Peter Knapper                                     13-Dec-99 03:32:21
Subj: fdisk /query

 PK>> Then the "issue" over the visibility and ordering of
 PK>> primary/logical partitions goes away completely...

 JdBP>> Actually, no it doesn't go away.  It is just renamed in the hope
 JdBP>> that  everyone will overlook it. (Amazingly, this actually seems 
 JdBP>> to happen.  (-:)  What on "PC style" operating systems is an issue 
 JdBP>> of drive letter assignment order is, on PC unices, an issue of the
 JdBP>> assignment order of device numbers.  One still has to change things. 

 PK> Try as I might, I can't see your logic here. 

The fundamental problem being addressed, which I don't want to lose sight of,
is that when one creates or deletes partitions the assignment of drive letters 
changes.  The scheme that you have suggested doesn't actually fix this
problem, it simply renames it.  Instead of having problems where E: becomes
D:, F: becomes E:, and so forth, the user has problems where the "mount table" 
for the system (which, as you described, contains entries that map a
{disc,partition} pair to a subdirectory) suddenly references completely the
wrong partitions, and large chunks of the file hierarchy suddenly start
playing musical chairs.  Essentially this is the *same problem* as the user
had before, just in a different guise.

Yes, the user can go and edit the mount table.  But that, too, is a
disadvantage in a way, compared to the way things are now.  The mount table is 
supplied by the user.  If the user modifies the partition table in any way,
he/she *also* has to add, delete, and renumber all of the entries in the mount 
table to mirror the change.  Compare this to the current scheme where at least 
if one creates a partition one doesn't have to do *further* work to have a
drive letter assigned to it.  When one creates a partition with the scheme
that you describe, however, one has to manually renumber the entries in the
table, because the creation of the partition has shifted the numbers along. 
And one *also* has to manually add a new entry for the new partition.

Worse, there's no way to automate this process.  Consider the case where one
has two operating systems, on separate partitions, that one wants to keep
entirely separate from one another.  With the drive letter assignment scheme
that operating systems employ today, if one alters the partition table to
create a partition *both* operating systems will create a new drive letter for 
it automatically without any further intervention.  There's no need for one
operating system to "tell" the other about the change.  With the "mount table" 
scheme, however, the partition creation utility has to update both mount
tables, lest they become out of synchronisation with the actual partition
table.  But it cannot do so because (a) it doesn't necessarily know of the
existence or location of any but the mount table of the operating system that
is currently running, and (b) it may have no way to access the mount table of
other operating systems even if it did know that they existed and where they
were (The operating systems are deliberately being kept isolated from each
other, remember.  The other operating system's partition may not have been
mounted at all.).

Doing away with drive letters and replacing them with a mount table does not,
in fact, fix the problem that requires fixing, which is minimising the impact
of changing the partition table on system configuration.  It simply renames it 
in the hope that it is overlooked.

Does that make it clearer ?

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
138/2
397/1

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    11-Dec-99 13:06:28
  To: Kees Bergwerf                                     13-Dec-99 03:32:21
Subj: not enough diskspace

Hello Kees,

09 Dec 99 04:20, Kees Bergwerf wrote to Eddy Thilleman:

ET>> I too tried to install fixpak 12 on my Warp 4, but I got only
ET>> errors and lockups

KB> Dit you use the simplyfix program?

I just installed from the fixpak cdrom from Mensys and started the appropriate 
programs via their menu, AFAIK this runs the service.exe file.

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... Windows is great if you can make it work.
--- GoldED/2 3.0.1
 * Origin: Windows95 is a graphic DOS extender (2:280/5143.7)
772/1

+----------------------------------------------------------------------------+

From: Peter Knapper                                     13-Dec-99 19:24:19
  To: Mike Ruskai                                       13-Dec-99 21:26:09
Subj: HPFS Directories.

Hi Mike,


 MR> ftp://hobbes.nmsu.edu/pub/incoming/hpfsut02.zip

 MR> or

 MR> ftp://hobbes.nmsu.edu/pub/os2/util/disk/hpfsut02.zip

Oh darn, I was just there last night. Looks like a return trip.....;-)

As you may have seen, Will has pointed me in the right direction. It looks
like a change of controller is causing the problem so a "tidy up" of the drive 
is being planned to resolve the issue.

Your comments have been saved. Thanks.........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: Peter Knapper                                     13-Dec-99 21:37:21
  To: Jonathan de Boyne Pollard                         13-Dec-99 21:26:09
Subj: fdisk /query

Hi Jonathan,

 JdBP>  JdBP>> One then has to have *another* table of drive letter 
 JdBP>  JdBP>> assignments to say "drive letter Q: is this point in 
 JdBP>  JdBP>> the directory tree".

 PK> ONLY if it is necessary to HAVE a drive letter 
 PK> there! Remember, in my scenario this is for backwards 
 PK> compatibilty only!

 JdBP> The flaw is that the scenario fails to take into account that the 
 JdBP> system API is constructed around the paradigm of 
 JdBP> multiple drives with independent directory 
 JdBP> hierarchies.  Not only would you have to rewrite the 
 JdBP> operating system with a new API, you'd have to 
 JdBP> rewrite all of the applications programs as well.  

If ALL files are referenced somewhere under just the one drive letter C:, or
via just ONE drive number, how does anything have to change? I just can't see
this causing such a problem.

If the user wishes to manually configure "virtual" drive letters/numbers, I
also can't see how this is going to be a massive problem.

Cheers...........pk.

--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: Peter Knapper                                     13-Dec-99 20:45:15
  To: Jonathan de Boyne Pollard                         13-Dec-99 21:26:09
Subj: fdisk /query

Hi Jonathan,

 PK>> Then the "issue" over the visibility and ordering of
 PK>> primary/logical partitions goes away completely...

 JdBP>> Actually, no it doesn't go away.  It is just renamed in the hope
 JdBP>> that  everyone will overlook it. (Amazingly, this actually seems 
 JdBP>> to happen.  (-:)  What on "PC style" operating systems is an issue 
 JdBP>> of drive letter assignment order is, on PC unices, an issue of the
 JdBP>> assignment order of device numbers.  One still has to change things. 

 PK> Try as I might, I can't see your logic here. 

 JdBP> The fundamental problem being addressed, which I don't want to lose 
 JdBP> sight of, is that when one creates or deletes partitions the assignment 

 JdBP> of drive letters changes.  The scheme that you have 
 JdBP> suggested doesn't actually fix this problem, it simply renames it. 

I think I see what you are talking about, but that is because you are taking
MY literal mention of mounting the partitions similar to unix much too close.
Maybe I shouldn't have mentioned unix.......;-) 

My "similar to unix" layout meant that the PHYSICAL partition appears under
the root using a unique partition name to ensure that the dynamic "DEVICE
naming" of the unix environment never plays a part in the partition addressing 
exercise. 

The issue of partition order goes away, completely, and partitions that are
removed or added are done so in a manner which does not affect any other
partition in the system.


 JdBP> Worse, there's no way to automate this process.

Of course it can be automated if you want to. What is preventing it from being 
automated? If the computer can recognise that a partition uses a specific
FORMAT, load the appropriate driver for that, work out the VOLUME LABEL and
assign a drive letter, why can in not recognise WHAT the partition IS and
WHERE it should be mounted?

You have to bring the partition recognition phase back into control, none of
this "automatic" ordering that currently happens. Its the automatic phase that 
is causing all the problems for people.

 JdBP> Doing away with drive letters and replacing them with 
 JdBP> a mount table does not, in fact, fix the problem that 
 JdBP> requires fixing, which is minimising the impact of 
 JdBP> changing the partition table on system configuration. 

Of course it does! Regardless of adding/removing partitions the existing
partitions are ALWAYS mounted at exactly the same place. If a partition that
was configured on a system is "destroyed" by some other event, then upon
system restart that partition is simply found so it is not mounted.


 JdBP> Does that make it clearer ?

Nope...........;-) I must be missing something here because so far I can see
what appear to me to be fairly obvious answers to all the "issues" you
mention. Maybe there is something about partitions that I AM missing and why I 
can't see why you keep returning to "computer assigned" drive letters or
numbers, but I am not sure exactly what that could be at the moment.

Cheers...........pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)
772/1

+----------------------------------------------------------------------------+

From: Sean Dennis                                       12-Dec-99 13:46:26
  To: Fred Springfield                                  13-Dec-99 21:26:09
Subj: SIO and Y2K

RE: SIO and Y2K
BY: Fred Springfield to All on Fri Dec 10 1999 01:00 pm

OTE: DCTEdit v0.04 [2]
 > Does anyone know if there are any y2k issues with the SIO drivers?
 >  
 > It would be nice to know if there are--because, then we could put the
 > IBM drivers back in.

AFAIK, SIO and Vmodem don't need to use dates... all they are are serial 
drivers. :)

The only file that I know of that SIO uses concerning a date is in the 
unregistered version, where it writes the hidden file OS SIODT to keep track 
of when to start displaying the "register me" message.

Later,
Sean

... 24 hours in a day and 24 beers in a case...  Hmmm...
--- Synchronet+SBBSecho v1.25
 * Origin: It's a different party afterhours. (1:395/610)
138/2
397/1

+----------------------------------------------------------------------------+

From: Sean Dennis                                       12-Dec-99 13:48:08
  To: Herbert Rosenau                                   13-Dec-99 21:26:09
Subj: Fix_Paks

RE: Fix_Paks
BY: Herbert Rosenau to Ron Nicholls on Fri Dec 10 1999 09:45 pm

OTE: DCTEdit v0.04 [1]
 > RN> Are the early fix paks for Warp 4 ( 1 to 8 )
 > RN> still available anywhere.
 >  
 > Why?
 >  
 > Use FP 11 to become a most stable system. It hold all older fixacks.
 >  
 > It's not the most recent.... but the most stable since FP9.

And FP11 has a very nasty bug in it that will cause several programs (such as 
Post Road Mailer) to barf because FP11 causes the system to not update 
directories correctly, causing said programs to crash and burn.

I run Post Road Mailer and had that problem.  I upgraded to FP12 last week and 

am very glad I did.

Later,
Sean

... "D'oh!" -- Homer
--- Synchronet+SBBSecho v1.25
 * Origin: It's a different party afterhours. (1:395/610)
138/2
397/1

+----------------------------------------------------------------------------+

From: Leonard Erickson                                  13-Dec-99 02:09:01
  To: Fred Springfield                                  13-Dec-99 21:26:09
Subj: SIO and Y2K

 -=> Quoting Fred Springfield to Leonard Erickson <=-

 LE>  -=> Quoting Fred Springfield to All <=-
 LE> 
 LE>  FS> Does anyone know if there are any y2k issues with the SIO drivers?
 LE> 
 LE> It's hard to see *how* serial drivers *could* have y2k issues. 
 LE> 
 LE> Think about it. When do they *ever* deal with the date or even the
 LE> time?
 FS> 
 FS> I don't know--which is why I am asking.

 FS> However, one might make the following observation;

 FS> All your internet stuff goes through the COM port, and all
 FS> the tcpip stuff requires handshaking and date/time
 FS> confirmation as part of the IP protocol.

 FS> And ask the following question;

 FS> Does the driver just pass all this stuff through without
 FS> reading it in any way, or does it read part of it for any
 FS> reason, and therefore be vulnerable to failure?

The SIO drivers and TCP/IP are *different layers* in the protocol
stack. As such, the SIO drivers would be badly broken if they treated
the TCP/IP packets as anything but a series of bytes to be transferred.

It's sort of like the way a normal phone line doesn't *care* what sort
of sounds it is carrying, voice or modem tones, it's all just varying
voltages to be carried.

--- FMailX 1.48a
 * Origin: Shadowshack (1:105/51)
138/2
397/1

+----------------------------------------------------------------------------+

From: Leonard Erickson                                  13-Dec-99 02:13:01
  To: Jonathan de Boyne Pollard                         13-Dec-99 21:26:09
Subj: SIO and Y2K

 -=> Quoting Jonathan de Boyne Pollard to Leonard Erickson <=-

 FS>> Does anyone know if there are any y2k issues with the SIO drivers?
 
 LE> It's hard to see *how* serial drivers *could* have y2k issues. 
 
 LE> Think about it. When do they *ever* deal with the date or even the
 LE> time?

 JdBP> The unregistered version of SIO creates a hidden file in the root of
 JdBP> all drives that contains date and time information so that it can
 JdBP> determine how many days it has been used for. 

Ok, *that* could mess up. But as long as the OS and hardware return
correct date/time, the worst that SIO could do is miscalculate how long
it's been running. So unless it it crippleware, you'd just get nag
screens at the wrong time.



--- FMailX 1.48a
 * Origin: Shadowshack (1:105/51)
138/2
397/1

+----------------------------------------------------------------------------+

From: Preston Smith                                     13-Dec-99 08:24:21
  To: Will Honea                                        13-Dec-99 21:26:09
Subj: TCPIP Update

Hello Will!

Sunday December 12 1999 18:21, Will Honea wrote to Preston Smith:

 WH> I can't think of anything, Preston, unless it's a timing issue.  Try a
 WH> long pause between your end action and the pppkill call.  You might
 WH> also learn something by removing the pppkill call from your script then
 WH> running it manually from a command line but it looks the same to me as
 WH> it's always been.

I called pppkill from an OS/2 box and it did not kill the session.


I addewd this line to my script and remmed out the line that invioked pppkill
'start /fs /c /b go -ka ppp.exe'.  Bingo all went well - so for some reason
pppkill was not doing the job.

here i the data on the pppkill file on my system

11-Dec-98 12:14     30690        49 pppkill.exe


Preston (prsmith@navnet.net)

---
 * Origin: Canadian Connection, St Margarets Bay NS (902)826-7774 (1:251/11)
138/2
397/1

+----------------------------------------------------------------------------+

From: Stewart Honsberger                                12-Dec-99 22:15:20
  To: Leonard Erickson                                  13-Dec-99 21:26:09
Subj: SIO and Y2K

Hello Leonard!

Dec 11 02:22 99, Leonard Erickson wrote to Fred Springfield:

 FS>> Does anyone know if there are any y2k issues with the SIO drivers?

 LE> It's hard to see *how* serial drivers *could* have y2k issues. 

 LE> Think about it. When do they *ever* deal with the date or even the
 LE> time?

The registration routine checks the date against one stored in "OS SIODT"
(stored in atleast one, usually two root directories).

Yeah yeah.. Register SIO and have no problems.. Well, I don't run a BBS, and
only once in a blue moon boot OS/2 to transfer mail, so I don't figure I use
it enough to warrant it. :>

Other than that - I guess somebody could shoot a message off to Ray Gwinn and
ask him if there are any date references?!?

Stewart Honsberger (AKA Blackdeath)
 blackdeath@softhome.net
  http://sprk.com/blackdeath

--- Msged/LNX TE 06 (pre)
 * Origin: Blackdeath BBS - Private (1:229/604)
2320/38

+----------------------------------------------------------------------------+

From: Herbert Rosenau                                   13-Dec-99 12:07:25
  To: Steve McCrystal                                   13-Dec-99 21:26:09
Subj: cache

 HR>> Read the readmes to your Fixpack. It is declared there. The docu
 HR>> is old.

 HR>> readahead:[0|1] is the only choice the fixpack tells this
 HR>> parameter as n - but all other than 0 (read ahead off) or 1 (on)
 HR>> will not understund by cache.exe.

 SM> Thanks!  As I mentioned, I have proven, at least to myself, that
 SM> your assessment is correct, but I do wish they would update the
 SM> online help.  I have used it infrequently because it is normally
 SM> too much of a PITA to find anything, but now even less because
 SM> much of it is just plain wrong! :^)

It's not on me. :-(

There is another big change in OS/2 nobody noticed of it:

chkdsk!

Since WARP 4 FP5 / WARP3 FP35 chkdsk is changed to 32 bit. The algorytm ti's
working is significantly changed too. With small memory and big disks you have 
to change your config.sys AND to have a startup.cmd to become the drives
unlococked in case of a crash.

The only point you find information - and a lot of it - is the readme of each
fixpack.

--- Sqed/32 1.15/development  93:
 * Origin: Was hat ein Mann ohne Beine? - Erdnuesse! (2:2476/493)
138/2
397/1

+----------------------------------------------------------------------------+

From: Herbert Rosenau                                   13-Dec-99 12:29:08
  To: Jack Stein                                        13-Dec-99 21:26:09
Subj: cache

 JS> I, and someone recently in here, had problems with modum overrun
 JS> errors after installing newer IBM1S506.add drivers.  I know I
 JS> messed around a good bit trying to change paramaters in the
 JS> driver to fix it, and ended up going back to the old driver,
 JS> which works fine.  I wonder if this LAZY cache thing would fix
 JS> that?  Sounds like it might.                                     

It depends on
- your COM port.	MUST have a UART16550 (or other buffered)
			the cheap 16450 is unbufferd and my cause
			problems on transfer rates higher than 9600 cps
- your port settings    you should set the transfer rate com <-> modem
			to the double or higher than modem <-> modem
- PRIORITY_DISK_IO      must be NO to become the modem thread boosting
			over vorground threads for disk access
			(config.sys)

Then you have to play with ALL the cache parameters to find the optimum
settings for your system. The parameters depends on YOUR system usage.

The number of writers should be equal to the number of threads concurrently
writes to disk. This number is significantly lower than the number of
processes you have running! Most of your threads would never write anything
(they may read something),

If you've done all that - and the modem makes probs anyway then you have to
switch from (E)IDE to SCSII disks. Because (E)IDE is more CPU intensive than
SCSII and if the IDE drive eats CPU time the modem can't use it.

--- Sqed/32 1.15/development  352:
 * Origin: Hai nun - oder doch erst morgen ? (2:2476/493)
138/2
397/1

+----------------------------------------------------------------------------+

From: Fred Springfield                                  13-Dec-99 09:40:15
  To: Preston Smith                                     13-Dec-99 21:26:09
Subj: TCPIP Update

Preston Smith said to all:

PS> I upgraded MPTS to W08424, and applied the UN_0980 fixpack to
PS> TCPIP.  Invoking  'INETVER' now gives me 4.02w.
PS> 
PS> All went well but I ended up with one problem.  I use a script
PS> that drops my  BBS off line and invokes pppdial and Internet rex to
PS> pick up and send my Fido  mail via FTP and e-mail.  Since I did the
PS> update to TCPIP the script no longer  kills the link to my ISP when
PS> all required action are completed.
PS> 
PS> Were there changes in any of the components such as pppkill that
PS> mayrequire me  to change my scripts? 

I have the same MPTS and TCPIP upgrades, along with FP #12, and
killppp does not work at all--can't even get it to give me the syntax
with a pppkill -?  call.

Looks like another one of those Y2K side effects we'll have to deal
with.

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  Hope makes a good breakfast, but a poor dinner.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
278/111

+----------------------------------------------------------------------------+

From: Holger Granholm                                   12-Dec-99 13:56:00
  To: Murray Lesser                                     13-Dec-99 21:26:09
Subj: not enough diskspace

In a message dated 12-10-99, Murray Lesser said to Holger Granholm:

Hi Murray,

ML>    IMO, every OS/2 user should have a program that cleans up the
ML>.INI files and all the other "handle" information that is left
ML>behind when object files are deleted from the system.  I use
ML>UniMaint v 5.10.02 (a shrink-wrapped program) ........

I don't mind the cost of useful programs but trying to buy any OS/2
programs here will fail.

ML>  But, I am told that there are many other programs that clean up
ML>the two .INI files, some of which are freeware.  I suggest that you
ML>look into it.

Yes I will. I'll start with an inventory of my BBS ;-)

ML>    "Uninstall" programs are notorious for being short-sighted.  The
ML>one that comes with UniMaint includes special warnings to the user,

So does the programs that come with Hank Kelder's WPTOOL suite.
If I don't find anything else, I might end up using them.

Happy Holidays,

Holger

___
 * MR/2 2.26 * OS/2 VirusScan -- "Windows found: Remove it? [Y,y]"

--- PCBoard (R) v15.22/M 2
 * Origin: Coming to you from the Sunny Aland Islands. (2:20/228)
772/1

+----------------------------------------------------------------------------+

From: Holger Granholm                                   12-Dec-99 13:56:00
  To: Stewart Buckingham                                13-Dec-99 21:26:09
Subj: not enough diskspace

In a message dated 12-11-99, Stewart Buckingham said to Holger Granholm:

Hi Stu,

SB>There is quite a good program called Service Center 3.0 (which
SB>presumably can be found on Hobbes) which (among other things) has
SB>quite a good class/ini browser/deleter. You might give it a try.

Well, if I only new what file name to look for. I wouldn't say Hobbes
is unfriendly but it's very difficult to know where to look for various
programs.

Happy Holidays,

Holger

___
 * MR/2 2.26 * Air conditioned environment - Do not open Windows.


--- PCBoard (R) v15.22/M 2
 * Origin: Coming to you from the Sunny Aland Islands. (2:20/228)
772/1

+----------------------------------------------------------------------------+

From: Holger Granholm                                   12-Dec-99 13:56:00
  To: Craig Ford                                        13-Dec-99 21:26:09
Subj: Help!

In a message dated 12-09-99, Eddy Thilleman said to Craig Ford:

Hello Craig,

ET>07 Dec 99 18:46, Craig Ford wrote to All:

CF> It would also help if someone could tell me in which immage file on
CF> the distribution CD it is contained.

ET>I don't know that. Maybe someone else?

Yeah, in FP12 it's on the disk #1. Without checking, I'd suppose it's on
the same diskette number in all others too.

Happy Holidays,

Holger

___
 * MR/2 2.26 * Windows isn't crippleware: it's "Fuctionally Challenged"

--- PCBoard (R) v15.22/M 2
 * Origin: Coming to you from the Sunny Aland Islands. (2:20/228)
772/1

+----------------------------------------------------------------------------+

From: Holger Granholm                                   12-Dec-99 13:56:00
  To: Eddy Thilleman                                    13-Dec-99 21:26:09
Subj: Help!

In a message dated 12-09-99, Eddy Thilleman said to Craig Ford:

ET>Hello Craig,

ET>07 Dec 99 18:46, Craig Ford wrote to All:

ET>My Warp 4 is already at fp9

ET> 8-10-98 12:14      1.238.971      0 a---  PMMERGE.DLL

And that is supposed to mean Aug. 10th or Oct. 8th?  It all depends upon
how you have set up the date display.

Happy Holidays,

Holger

___
 * MR/2 2.26 * PATH=C:\DOS;C:\DOS\RUN;C:\WIN\CRASH\DOS;C:\ME\DEL\WIN


--- PCBoard (R) v15.22/M 2
 * Origin: Coming to you from the Sunny Aland Islands. (2:20/228)
772/1

+----------------------------------------------------------------------------+

From: SINISA PAVLOVIC                                   13-Dec-99 19:03:00
  To: All                                               13-Dec-99 21:26:10
Subj: Re: Another leaky fixpak?

From: sinip@hamhq.yfnet.org.yu (SINISA PAVLOVIC)
Reply-To: sinip@hamhq.yfnet.org.yu (SINISA PAVLOVIC)
Organization: HAM HQ BBS, Doboj, RS, 074/24-360

 -=> Quoting Jack Pfisterer to All <=-

 SP> But just to be sure that I'm not going to get the same one, PMMERGE
 SP> that I have here is:
 
 SP> PMMERGE.DLL     1238971 bytes   08.Oct.1998 12.14pm

 JP> The one from ivan@protein.bio.msu.su is dated 10 Oct 99 and is 1254973
 JP> bytes.

Thanks, I've already got the answer from Ivan, and dl'ed the file as
well.

 JP> newer keyboard.dcp.
 
 SP> What is that for?

 JP> I really don't know.  It just happens to be included.  Probably just
 JP> some very specialized fixes.

Ok. Thanks again.

Visit: http://www.targetshop.com/users/level1.asp?refId=349351

Regards from Doboj, Republic of Srpska.   mail to: 4n4da@qsl.net


... User aborted by program...
___ Blue Wave/OS2 v2.30


--- FIDOGATE 4.3.5
 * Origin: fido.org.yu domain gateway (2:382/5.0)
397/1

+----------------------------------------------------------------------------+

From: Fred Springfield                                  13-Dec-99 11:06:17
  To: All                                               13-Dec-99 21:26:10
Subj: Object Rexx

In an earlier posting (perhaps in OS2PROG) I mentioned that I was
running Object Rexx here on Warp 4 + FP#12, and found that it made my
system slightly more peppy that running my rexx programs on regular rexx
especially since I do some heavy multitasking all day long.

This view has not changed, but I have had to return to regular rexx as
the platform for my rexx programs because I was getting regular traps in
REXX.DLL (about 1 or 2 per day)--with 2 realtime rexx programs running
all the time. It's been 4 days since I returned to regular rexx, but
have not had any traps since--so I guess I found the cause of the
problem.

Is this another of those undesirable side effects which we get with
the evil, but necessary Y2K updates? Maybe, but FP#12 is here to stay,
so Object Rexx goes out the door--except for debugging new code, for
which it is excellent. 

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  Success--that good feeling after winning something.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)
278/111

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       13-Dec-99 11:08:00
  To: SEAN DENNIS                                       14-Dec-99 01:17:12
Subj: Fix_Paks

Some senseless babbling from Sean Dennis to Herbert Rosenau
on 12-12-99  13:48 about Fix_Paks...

 SD> RE: Fix_Paks
 SD> BY: Herbert Rosenau to Ron Nicholls on Fri Dec 10 1999 09:45 pm

 SD> OTE: DCTEdit v0.04 [1]
 > RN> Are the early fix paks for Warp 4 ( 1 to 8 )
 > RN> still available anywhere.
 >  
 > Why?
 >  
 > Use FP 11 to become a most stable system. It hold all older fixacks.
 >  
 > It's not the most recent.... but the most stable since FP9.

 SD> And FP11 has a very nasty bug in it that will cause several programs
 SD> (such as  Post Road Mailer) to barf because FP11 causes the system to
 SD> not update  directories correctly, causing said programs to crash and
 SD> burn. 
 SD> I run Post Road Mailer and had that problem.  I upgraded to FP12 last
 SD> week and  am very glad I did.

It should be pointed out that your characterization of where the bug is, is
incorrect.  The bug lies with PRM, and any other program that developed
problems with FP11.

Setting the archive bit on a directory is quite correct practice, and one
can make a good argument for OS/2 being buggy up until FP11, with respect
to backup program functionality.

The problem with the programs is that they are assuming a directory has
*only* the directory bit set (and hence the attributes storage area has a
decimal value of 16).  In reality, all other bits are valid for a
directory.  These programs will also be unable to see hidden, system, or
read-only directories (this latter being more potentially problematic than
the others), unless they have special steps to allow for all combinations
*except* for those containing the archive bit (which is quite a silly waste
of typing and execution time).

Mike Ruskai
thannymeister@yahoo.com


... An agreeable person: A person who agrees with me.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
138/2
397/1

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       13-Dec-99 11:18:00
  To: JONATHAN DE BOYNE POLLARD                         14-Dec-99 01:17:12
Subj: Install

Some senseless babbling from Jonathan De Boyne Pollard to Lee Aroner
on 12-12-99  17:50 about Install...

 JdBP>> I think that Leonard is trying to make the point that using 
 JdBP>> FCBs for "fast deletions" is pointless in those 
 JdBP>> environments, because it *isn't* actually faster that doing 
 JdBP>> things the more up-to-date way using a simple 
 JdBP>> findfirst/findnext loop.
 
 LA> I *have* compared it Johnathan, and it's a whole big pile faster    
 LA> than running a loop, which, of course, is the backup routine in    
 LA> case the drive in question is HPFS (since warp intentionally    
 LA> traps if you try this on HPFS with a wildcard spec).

 JDBP> It's only faster on DOS, though.  It *isn't* faster on non-DOS
 JDBP> operating systems, such as OS/2 or Windows NT.  Try measuring it on
 JDBP> something other than DOS.

 JDBP> This was demonstrated a year or so ago in this very echo, with people
 JDBP> using the 4DOS DEL command with and without the /Q switch (which
 JDBP> selects between using FCBs and using MS-DOS version 2.0 style deletion)
 JDBP> and discovering that the two operate at exactly the same speed. 
 JDBP> Unfortunately, I don't remember who it was who sat down and tested it.

I can't say I was the only one, but I did post about running 4DOS's DEL
command with and without the /Q switch.

You were confused at the time about what it is that I was advocating,
because I did in fact report that 4DOS's deletes were substantially faster
with /Q than without.  I was not, of course, trying to say that FCB usage
was the reason, and in fact took some amount of time explaining that 4DOS's
/Q switch has nothing whatsoever to do with FCB's unless you're running
native DOS.

Under DOS, the /Q switch both suppresses output, and utilizes FCB's if the
deletion mask is suitable (not an extended 4DOS mask).  Under OS/2, the /Q
switch merely suppresses output.

When I first ran the test, it was on a 486DX2/66 machine, and the
difference in deletion speed was quite dramatic, between using /Q and not.

This was due entirely to the fact that screen I/O is expensive, and that
expense is readily apparent on a 486 system.

When I shortly thereafter upgraded to a Pentium/200, the difference became
quite negligible.

The discussion, incidentally, took place between two and three years ago.

I still remember writing about the brand new name of Chicago, complaining
that it wasn't even 1995 yet, in OS_DEBATE.

Mike Ruskai
thannymeister@yahoo.com


... Conscience gets a lot of credit that belongs to cold feet.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
138/2
397/1

+----------------------------------------------------------------------------+

From: Will Honea                                        13-Dec-99 23:46:00
  To: Preston Smith                                     13-Dec-99 23:46:00
Subj: TCPIP Update

Preston Smith wrote to Will Honea on 12-13-1999

PS> Hello Will!
PS> 
PS> Sunday December 12 1999 18:21, Will Honea wrote to Preston Smith:
PS> 
PS>  WH> I can't think of anything, Preston, unless it's a timing issue.  Try
a
PS>  WH> long pause between your end action and the pppkill call.  You might
PS>  WH> also learn something by removing the pppkill call from your script
then
PS>  WH> running it manually from a command line but it looks the same to me
as
PS>  WH> it's always been.
PS> 
PS> I called pppkill from an OS/2 box and it did not kill the session.
PS> 
PS> 
PS> I addewd this line to my script and remmed out the line that
PS> invioked pppkill 'start /fs /c /b go -ka ppp.exe'.  Bingo all went
PS> well - so  for some reason pppkill was not doing the job.
PS> 
PS> here i the data on the pppkill file on my system
PS> 
PS> 11-Dec-98 12:14     30690        49 pppkill.exe

Just tried this out and wouldn't you know it, pppkill does NOT see
ppp1 when InJoy has bound it.  Just for fun, try ifconfig ppp<n> and
see what ppp interfaces are really open.  I do have a slightly
different pppkill.exe:

10-01-98  9:11a        48,719      0 a---  pppkill.exe

I am running TCP/IP 4.1 on this machine, so I doubt it will match
yours in detail.

Thinking back, I believe that it was determined at one time that
pppkill.exe would only kill sessions initiated by ppp.exe.  In fact,
writing this and thinking back I'm fairly certain that pppkill got the
pid to kill from a temp file written by ppp.exe which would make it's
usefullness a bit limited. Are you using DOIP to dial out (it uses
ppp.exe) or something else?  I use Injoy which does NOT use ppp.exe, so
that explains some of what I see here.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Will Honea                                        13-Dec-99 23:46:00
  To: Preston Smith                                     13-Dec-99 23:46:00
Subj: TCPIP Update

Preston Smith wrote to Will Honea on 12-13-1999

PS> Hello Will!
PS> 
PS> Sunday December 12 1999 18:21, Will Honea wrote to Preston Smith:
PS> 
PS>  WH> I can't think of anything, Preston, unless it's a timing issue.  Try
a
PS>  WH> long pause between your end action and the pppkill call.  You might
PS>  WH> also learn something by removing the pppkill call from your script
then
PS>  WH> running it manually from a command line but it looks the same to me
as
PS>  WH> it's always been.
PS> 
PS> I called pppkill from an OS/2 box and it did not kill the session.
PS> 
PS> 
PS> I addewd this line to my script and remmed out the line that
PS> invioked pppkill 'start /fs /c /b go -ka ppp.exe'.  Bingo all went
PS> well - so  for some reason pppkill was not doing the job.
PS> 
PS> here i the data on the pppkill file on my system
PS> 
PS> 11-Dec-98 12:14     30690        49 pppkill.exe

Just tried this out and wouldn't you know it, pppkill does NOT see
ppp1 when InJoy has bound it.  Just for fun, try ifconfig ppp<n> and
see what ppp interfaces are really open.  I do have a slightly
different pppkill.exe:

10-01-98  9:11a        48,719      0 a---  pppkill.exe

I am running TCP/IP 4.1 on this machine, so I doubt it will match
yours in detail.

Thinking back, I believe that it was determined at one time that
pppkill.exe would only kill sessions initiated by ppp.exe.  In fact,
writing this and thinking back I'm fairly certain that pppkill got the
pid to kill from a temp file written by ppp.exe which would make it's
usefullness a bit limited. Are you using DOIP to dial out (it uses
ppp.exe) or something else?  I use Injoy which does NOT use ppp.exe, so
that explains some of what I see here.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: John Thompson                                     13-Dec-99 13:29:00
  To: Sanford Shapiro                                   14-Dec-99 05:55:00
Subj: Wordperfect 7

In a message to All, Sanford Shapiro wrote re: Wordperfect 7

SS> I have a copy of Corel Wordperfect 7 for Windows 3.1. It works great
SS> under OS/2 (WinOS2).
SS> 
SS> The question I have is -- it mentions OS/2 integration tools. These
SS> are no longer available from Corel.
SS> 
SS> Does anyone have these OS/2 integration tools that I can get a copy
SS> of? Are they listed on any of the OS/2 BBS's?

I see this at hobbes:

os2tls.zip       273061 1995/01/30  WordPerfect 6.0a for Windows OS/2 WPS
Integration Tools

I don't know if it will complain about being used with WP v7. 
though.

ftp://hobbes.nmsu.edu/pub/os2/system/patches/os2tls.zip



 * KWQ/2 1.2i * Internet: John.Thompson@attglobal.net


--- PCBoard (R) v15.3/M 10
 * Origin: Spare Parts BBS - Appleton WI (920-731-7697) (1:139/0)
278/111

+----------------------------------------------------------------------------+

From: Murray Lesser                                     13-Dec-99 09:37:00
  To: Jonathan de Boyne Pollar                          13-Dec-99 09:37:00
Subj: Install

(Excerpts from a message dated 12-12-99, Jonathan de Boyne Pollard to
Lee Aroner)

JP>The idea that "FCBs are faster" is only true when one uses DOS for
  >one's operating system.  But operating systems that are *not* based
  >upon DOS but on which one can run DOS 
  >programs, such as OS/2 and Windows NT, have been in 
  >widespread use for 5 to 8 years now.  The generality that "FCBs are
  >faster" is no longer true, and hasn't been for many years.  Even on
  >DOS-Windows 3.1 or DOS-Windows 95/98 with "32-bit file access"
  >enabled it isn't true.  It wasn't even true on DOS in the 1980s on
  >machines attached to LANs.

JP>So this "little trick" will go away because it is no longer useful
  >to DOS programmers, which is in turn because the premise that it is
  >based upon is not true for the large majority of systems where DOS
  >programs are run these days.

    "This little trick" may go away, but old DOS programs that used it
won't.  If you are still running "legacy" DOS programs (say, of
mid-1980s vintage) that you didn't write yourself, cutting out the FCB=
line in config.sys (or even cutting the default value from 16 down to 3
as someone recommended) to "save" the negligible amount of memory
involved is foolish.  IIRC, that is where this thread started :-).

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Never get carried away by a flood of logic

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Murray Lesser                                     13-Dec-99 10:35:01
  To: James Mckenzie                                    13-Dec-99 10:35:01
Subj: Weird Y2K bug

(Excerpts from a message dated 12-11-99, James Mckenzie to All)

Hi James--

JM>I just visited a site called www.firstsource.com and 
  >received a cookie that expires in 1970.  This is with 
  >Netscape 4.61.  Anyone care to confirm this.

JM>BTW, I'm running Warp 4 with FP10.

    I am using Netscape/2 (secured) under Warp 4 FixPak 5.  After every
session that gets anywhere near a Web site, I check \cookies.txt and
clean out any added unwanted junk, using one of my text editors (TEDIT
works fine!).  Suggest you keep cookies only from sites you do business
with (such as buying stuff) regularly.  This will save you a lot of
grief in the long run, as well as making a lot of hotshot internet
marketing companies very unhappy :-).

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Happily hitchhiking on the Information Highway

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Murray Lesser                                     13-Dec-99 10:40:02
  To: Fred Springfield                                  13-Dec-99 10:40:02
Subj: New Y2K Logic

(Excerpts from a message dated 12-12-99, Fred Springfield to All)

Hi Fred--

FS>1)  Old Fixpak Rule-If it ain't broke, don't fix it.
  >    New Rule--     It's all broke, by definition.

....many deletions

FS>This, after going through my Warp Connect and Warp 4 systems from
  >top-to-bottom to make them Y2K ready.

    I didn't bother going through the operating systems.  I went through
my application programs (including testing the compilers!).  This is
where most Y2K problems occur, and no OS/2 FixPak will help them.

    AFAIAC, the old rule about FixPaks is still the best rule.  I an
running under Warp 4 FixPak 5.  I had already "fixed" the REXX Y2K
problem that was "fixed" in FixPak 5, with a home-grown
external-function DLL written long before I moved to Warp 4.  It turned
out that my DLL made the additional REXX "fix" in FixPak 6 unnecessary,
so (since FixPak 6 caused other, non-Y2K, ills) I backed out of that
one.  I haven't felt the need to do anything with later FixPaks except
to read the readme!  Of course, YMMV!

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Which direction is forward?

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Coridon Henshaw                                   13-Dec-99 13:39:14
  To: Fred Springfield                                  14-Dec-99 09:19:12
Subj: SIO and Y2K

On Sunday December 12 1999 at 11:14, Fred Springfield wrote to Leonard
Erickson:

 FS> However, one might make the following observation;

 FS> All your internet stuff goes through the COM port, and all the
 FS> tcpip stuff requires handshaking and date/time confirmation as part
 FS> of the IP protocol.

The serial IO driver merely spits bytes through a COM port.  All internet
protocol handshaking functions are performed by a combination of the TCP/IP
stack, MPTS and SLIP.EXE/PPP.EXE.


--- GoldED/2 3.0.1
 * Origin: Life sucks and then you croak. (1:250/820)
138/2
397/1

+----------------------------------------------------------------------------+

From: Ron Nicholls                                      14-Dec-99 19:50:00
  To: All                                               14-Dec-99 19:50:00
Subj: Embelish

For those who have yet to hear, Dadaware
has folded and placed Embelish on their site
 "dadaware.com" for free download.

I have attempted to install it but ran into an
message about a problem DLL.
This was late at night and I haven't  pursued
it.
-
-
Regards RonN
-
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Ron Nicholls                                      14-Dec-99 21:41:01
  To: Eddy Thilleman                                    14-Dec-99 21:41:01
Subj: cache

JP> ET> Is there an advantage to have more than one lazy write workers on the
JP>  ET> HPFS cache? Does this help with the performance when writing to disk
JP>  ET> (HPFS partition)?
JP> 
JP> It certainly helps in the case where one has more than one 
JP> physical disc unit.  It should also in theory help in the 
JP> 

I added "RUN=C:\OS2\CACHE.EXE  /LAZY:3 to config.sys
which halts the boot with " read ahead is disabled-Press enter
to continue" which will be a pain to put up with. Maybe it's
supposed to be in "startup".

Checking later with the cache command gives


[C:\]cache

          DiskIdle:     1000 milliseconds
            MaxAge:     5000 milliseconds
        BufferIdle:      500 milliseconds
        Cache size:     2048 kbytes
3 Lazy write worker(s) are enabled.
1 Read ahead worker(s) are enabled.

Previously  only one lazy write was enabled
so it does work. Now to wait and see if any 
noticable differences surface.
-
-
Regards RonN
-
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Ron Nicholls                                      14-Dec-99 22:03:02
  To: Holger Granholm                                   14-Dec-99 22:03:02
Subj: not enough diskspace

HG> SB>There is quite a good program called Service Center 3.0 (which
HG> SB>presumably can be found on Hobbes) which (among other things) has
HG> SB>quite a good class/ini browser/deleter. You might give it a try.
HG> 
HG> Well, if I only new what file name to look for. I wouldn't say
HG> Hobbes is unfriendly but it's very difficult to know where to look
HG> for various programs. 

Well ! I download the index periodicaly and do word searches
with EPM , amazing what turns up.

-
-
Regards RonN
-
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Murray Lesser                                     14-Dec-99 19:40:00
  To: Jonathan de Boyne Pollar                          14-Dec-99 19:40:00
Subj: Multiple visible primary

(Excerpts from a message dated 12-11-99, Jonathan de Boyne Pollard to
Murray Lesser)

Hi Jonathan--

 ML> Available-space discussions make sense only when one remembers
 ML> that they are purely relative.  You really ought to understand that 8
 ML> MB is only 0.1% of an 8 GB drive (0.2% of a 4 GB drive, in case
 ML> arithmetic is difficult for you), so is in the noise as far as usable 
 ML> space on such drives is concerned.   One tenth of one percent isn't 
 ML> worth worrying about, let alone making a serious(?) suggestion that 
 ML> legacy drive usage be modified to "save" any part of it.

JP>The suggestion that the cylinder alignment restriction in FDISK be
  >limited was motivated by many years of seeing many people complain
  >in this and other fora that "Boot Manager consumes a whole 8MeB! 
  >Utility X only consumes a couple of sectors.  Boot Manager is
  >rubbish!".  Obviously, people *are* concerned by such things --
  >quite a few people going by the number of times that I have seen
  >this sentiment expressed.  Indeed, having myself worked for many
  >years with a machine whose hard disc was continually around the 98%
  >full mark, I can assure you that people *do* think that one tenth of
  >one percent matters.

    The only HPFS partition that I run that is more than 90% full is the
one that contains only compilers.  Thus, it essentially is used as
read-only except during a compiler update, so there is no loss of
performance due to its being so full.  After updating a compiler, I
"defrag" the partition by backing it up, reformatting, and restoring it,
before using it for production.

     But even if you insist on taking the performance beating associated
with a 98%-full HPFS partition used for read/write, 0.1% "unusable"
space is only 5% (1/20th) of the space you are not using anyway, so has
no real effect on your operation.

    I am not surprised that there are a great many people without an
engineering or science background who "think that one tenth of one
percent matters" as far as disk-space usage is concerned.  But I am very
surprised that you indicate that you are one of them :-(.

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Nothing is so uncommon as common sense

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Gene Tucker                                       15-Dec-99 14:12:00
  To: Stewart Honsberger                                15-Dec-99 14:12:00
Subj: Sio And Y2k


SH>Other than that - I guess somebody could shoot a message 
SH>off to Ray Gwinn and ask him if there are any date 
SH>references?!?



It would be a good idea if he would answer. He just doesn't want to be
bothered
it seems. His reputation for support is the pits. I bought the Sio for the 2nd
time to encourage his development of the version 2.0 drivers and there has not
bween a new beta realease since December 1st 1998. In short he took our money
and ran. He would not even reply to me when I emailed him and asked if he ever
did plan to realease these new version. I got no reply at all. this was 3
months
ago. he doesn't even have the decency to tell me he isn't going to release
this
product which is appreent he does not. Oh well at least the beta version works
for me I do have that running rathere smoothly. And has been for a long time
now. I guess with the move to cable modems and DSL Sio com drivers are
irrelevent and getting more so with every month.
___
 X MR/2 2.26 #30 X Why is it that women can't learn to put the seat back up?

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

+============================================================================+
