• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

when? install eCS 2.0 -

Started by Dave Palmer, 2007.11.12, 01:26:53

Previous topic - Next topic

Dave Palmer

I'm a long term, happy :) :) user of OS/2.  Started out on 2.1 on a 386 with 16meg, etc. etc.

Now I am thinking about jumping into the future with eComStation Release 2.0 RC3.

BUT -
I've some old DOS apps that aren't going to be converted, ever - the developers have vanished and others I just want to hold on to.

One in particular uses a DOS - not windows - box to control a light controller for X10 devices.  It uses a com port.  It is online only as and when needed. 

Another is a HOBO Boxcar application (remote data collection devices) which is a DOS or can be Windows 3.1 Win98 app. 

I've extensive OS/ 2 DB's in old Alpha4 - and again, I'm happy and have no need to migrate to other DBMS.

Again, showing reluctance to change, I've many, many images/mods which entertain me with Siegfried Hanisch's screensaver.  Can I run it on eCS or am I forced to give it up?

Why go to eCS?  Primarily new devices (USB), new display support (when and if needed) and eventually the newer PMMAIL (which I guess isn't really going to work on my pre-Warp 4.5 system). 

Any info or broad suggestions or comments would be appreciated.

Thanks,
Dave

Blonde Guy

PMMail will too run on a old 16-bit system (OK run slowly) like the one you describe. 16-bit means that the TCP/IP stack is a 16-bit program. We just don't have a reliable tester for an older system, so sometimes things get broken and we don't know.

We intend to keep support for old OS/2, and if we add new features that require a 32-bit stack, then the new feature won't be there on an old system.


But don't use eCS 2.0 RC 3 -- wait for the release of 2.0. Or just stick with what works for you now.

Neil
Expert Consulting for OS/2 and eComStation

Pete

Hi Dave

I agree with Neil (Blond Guy) that you should not jump onto eCS20RC3 but should wait for the GA - unless you really want to work hard to get things working or need the newer hardware support immediately.

No, I am not testing RC3 myself but I am on the mailing list and have seen a lot of posts that suggest there is a lot to fix after an install at the moment. Hopefully RC4 will arrive soon with a lot of fixes for the RC3 errors...

Not seen any problems about DOS support - if you do try RC3 and find problems you could always use an alternative DOS VDM provided by DOSBox http://www.joschs-robotics.de/dosbox/

I do not use any DOS apps myself but do still play the odd DOS game. I use DOSBox as it provides a virtual soundcard thus my games play their sounds - I probably should explain that most modern soundcards use the UniAud driver which lacks DOS support so the standard DOS VDM cannot play sound. I do like DOSBox  :-)

Not seen any problems about Windows3 support but not sure if anyone is looking. I rarely use Win3 apps myself and would not really notice if it was not working until a rare use of failed. I have not tried but suspect that it would be possible to install Win3.1 (a real M$ version) into a DOSBox as an alternative.

You *should* (important word) be able to run most if not all existing OS/2 apps in eCS so your DBs and choice of screensaver should be OK - you may have to check that you do not install a Default screensaver as part of eCS Install though.

I do not really see problems with your proposed "pre-Warp 4.5 system" to eCS2.0 upgrade - just wait for either a better RC or the GA before purchasing  :-)

Regards

Pete

Dave Palmer

Pete and Neil,
Thanks for the info and comments.

I will wait for GA - that makes sense.  I've tried to stick to the 'if it isn't broke, don't fix it' approach - that is why I am a long term OS/2 user.  It works, it works every time and I don't have to put up with inconsistent results - which happen almost every time I boot XP.  And that is another story and not for this forum.

Glad to learn it is pretty much as I expected - however it the compat stuff isn't something easily seen/read when looking at eCS pages.

Another broad question.
I have used HPFS from the first day I installed OS/2.  I sneak a peek at JFS now and then. 

If JFS is a worthwhile target, then it would make sense to migrate with a new OS -

From a data standpoint:  I manage several websites.  One with pages in the thousands.  On a personal level I have a collection of several thousand jpg (personal photos and 35mm slides which I converted to digital).  On the data collection side I've decades of weather related files/records - in fact more data then I ever dreamed of back in 305 and 1311 days (before  2311's even).

Any observations or comments on why or why not JFS?

Thanks again,
Dave



warpcafe

Hi gang,

regarding JFS:
I was a hard-core fan of HPFS (also ~386) ever since and sceptical about JFS...
Back at Warpstock Europe, Peter Koller told me that JFS is definitely worth checking out. So right after I was able to get a copy of RC3 from Joachim Benjamins (from Mensys) I gave it a try...

and I'm overwhelmed by it:
On my T40, the bootup process performs CONSIDERABLY faster and overall performace is just lovely.
About stability on heavy load I can't tell, as I didn't had much time to actually WORK so far... ;-)
But it's definitely worth checking out, especially considering the fact that it's BOOTABLE JFS.
( BTW: One of the reasons for me not to install JFS earlier was the drawback of it being non-bootable. )

Regards,
Thomas
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Saijin_Naib

As a very noob end user, I'd have to say that I like JFS much better than HPFS, especially in the event of improper shut-downs. The JFS log-check is much faster than what HPFS does upon boot, saving upwards of a minute or so on improper shut-downs. With files performance, I have not really noticed too much a difference, but I get the impression that JFS was faster (currently on HPFS just because).

Fahrvenugen

On the HPFS versus JFS question, I think it really depends on what you're doing, also if you have the full HPFS386 from Warp Server Advanced, or standard HPFS.

If standard HPFS (non 386), then JFS is definitely the better way to go.  JFS gives you the large cache size, which provides a lot of performance gain.  I've never been a big fan of the  2MB limitation on  the standard HPFS cache size, and the only way around that is either HPFS386 or to use a different file system such as JFS.

A restart after an improper shutdown is also a lot quicker with a JFS partition then with HPFS.  So that is also very worthwhile considering. 

Another benefit of JFS over HPFS is the maximum partition size.  JFS can use (if I recall correctly) up to a 2 terrabyte partition size.  HPFS is limited to 64 GB (or it may be 63 GB... something like that). 

However...  another thing to consider is bootable JFS is still in what I would call its "infancy".  True, it works well.   But since bootable JFS is still in its beta stage, even with a GA release coming soon it is possible that there may be issues that turn up once it goes GA that are not being seen with the beta testing.   On the other hand HPFS and HPFS386 have been around a long time with the benefit of a lot of resources put into testing, troubleshooting, and making sure they just simply work the way they are meant to.  That isn't to say that bootable JFS won't work the way it is supposed to.  But if you're picking a file system for a critical system, HPFS (or HPFS386 with the larger cache sizes) might still be the way to go.  It has after all been around since 1989.   Of course regardless of file system it is still worthwhile to make backups of your data...

In my own unscientific testing I've found that HPFS386 and JFS  have comparable performance - some tasks are slightly quicker on JFS and some slightly quicker on HPFS386.  When comparing JFS with standard HPFS, JFS is definitely the winner.




RobertM

Fahrvenugen brings up some very valid points... though there is one additional one I would like to address (that in this day and age is becoming more crucial). HPFS and HPFS386 have a 2GB file size limit. Thus, to burn, save or store something like a DVD ISO, you would need JFS (which does not have that 2GB limit).

For certain things, JFS is noticeably faster than HPFS386 (for instance, using it for large contiguous swap/temp files). I have found quite a few scenarios that indicate that, one example being using Ceres Sound Studio to edit large music files: Ceres writes "Undo" copies to disk (in the user specified temp directories). Under JFS, the operation take roughly 10-20 seconds compared to 50-90 seconds on HPFS386 (on my hardware setup... your results may vary but should fit within that factor of 5 difference). HPFS386 seems to vary throughput throughout the write process, while JFS stays consistent. I believe some of the extra overhead HPFS386 has as well as how free space is mapped on the drive, contributes to the issue - as well as contributes to the wildly varying speeds during my tests (for instance, with the second "Undo" write, it's looking to write a second file to the drive, and has to look for new freespace, thus taking a different amount of time). HPFS(386) is more fragment resistant... but speed is the price you pay for that.

Also, there is apparently a balance between how many threads you can run and how large of an HPFS386 cache you can have... there seems to be some memory pointer or memory area that is shared for the two... thus increasing the maximum threads in the OS will decrease the maximum amount of memory HPFS386 can use for cache (or vice-versa - though the thread limit requested will always be granted... it's the cache amount that will not be honored).

Generally, as a rule of thumb, I like having the OS on an HPFS(386) partition, and put most everything else on the JFS partition. During the installation of eCS, you can even move certain components of the OS onto the 2nd (JFS) partition. Also, I prefer having the swap and temp files on another drive - again, preferably JFS (and preferably a separate physical drive - as well as preferably on a separate controller).


-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Dave Palmer

Robert, Fahrvenugen, Thomas and Saijin_Naib -
Thanks all for the snapshot of JFS.  You've all given me a pretty good view of the benefits. 

I'm encouraged to go with it when the time comes to migrate to eCS.

Without going into a closeup of the topic, is there anything in JFS which would preclude using another IFS within a JFS space  (in my case a physical drive).  I use Zipstream (CarbonBased out of Australia).  Originally (way back in the early 90s) to save disk space.  Now  I use it as extremely easy way to have virtual drives within a volume. 

Thanks again for info sharing...
Dave


RobertM

Quote from: Dave Palmer on 2007.11.15, 17:55:49
Without going into a closeup of the topic, is there anything in JFS which would preclude using another IFS within a JFS space  (in my case a physical drive).  I use Zipstream (CarbonBased out of Australia).  Originally (way back in the early 90s) to save disk space.  Now  I use it as extremely easy way to have virtual drives within a volume. 

Hi Dave,

As far as my understanding of how IFS's work under OS/2, there shouldn't be any problem with such a situation.  The only limitation (or possible benefit, depending on how ZipStream is written) is you will either *gain* the ability to create a vfs over 2GB, or (more likely) will still have the 2GB limit imposed on the vfs because it isn't written to handle files larger than 2GB (which means, if it supported greater than 2GB vfs's before - it was through using multiple container files, which it will still successfully do under JFS - but wont know it can simplify the process by just writing one large file instead of a bunch of 2GB chunks).


-Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Terry

Here's a thread started by yours truly, Bootable JFS vs. Bootable HPFS, that will fit in with this discussion...

http://www.os2world.com/component/option,com_smf/Itemid,63/topic,227.0/

Dave Palmer

Terry,
Thanks for the info and link
Dave