JFS failing in a disastrous way - without the user knowing

[Lars]

Hi

I quickly installed "CPUTemp_wdgt_1-1-0.zip" with Warpin 1.0.24 (ArcaOS 5.0.6) and I confirm it removed UNICODE.SYS from my config.sys.

Reverted everything, upgraded to WarpIn 1.0.26 and I got the same thing. UNICODE.SYS gets removed.

I also don't see anything strange on the CPUTEMP WarpIn script, just the "CONFIGSYS="DEVICE=?:\OS2\rdmsr.sys | UNIQUE" which should not remove UNICODE.SYS.

Should it be reported as WarpIn bug?

Regards

Warpin is working as it should based on discussion on the testers list. What happens is if rdmsr.sys is not installed, it matches up with the first *.sys in config.sys and replaces that with rdmsr.sys. Usually it is unicode.sys at the top of config.sys.

That is a very unfortunate side effect of specifying UNIQUE when "DEVICE" is the key string to look for because "DEVICE" will typically occur multiple times in config.sys. WarpIn should better be changed to do nothing if UNIQUE is specified and the key string is found multiple times. That is at least safe behaviour.
And if UNIQUE(xxxx) is specified, it should be changed to create the target string if no matching source string statement is found.

[Andi B.]

If you fear that something changes your config.xxx and you overlook to check the changes before reboot you can also start a rexx script from your startup.cmd which parses your current config.xxx. Though I don't know how to find out which config.xxx file is used by osinit.... But maybe simpler than changing jfs.ifs. Moreover chances are high that the output text from jfs.ifs while booting will be overlooked pretty easy. 

[Dariusz Piatkowski]

If you fear that something changes your config.xxx and you overlook to check the changes before reboot you can also start a rexx script from your startup.cmd which parses your current config.xxx...

You bring up a reason for why for every install I actually save a copy of CONFIG.SYS first and then afterwards compare the new copy to that backup.

This of course could be automated just as you say with a little REXX script very easily.

[Lars]

Sorry, but this is ridiculous.
If JFS.IFS can easily fail in a catastrophic way, then it is necessary to prevent that or at least to mediate the risk.
A new user would have no clue of what is going on. But maybe everyone has already accepted that there will be no new users...

Anyway, after thinking about it a bit more:
JFS.IFS can attempt to attach to UNICODE.SYS via a dehelp call and that can already be done on FS_INIT (call for initializing JFS.IFS) which is executed already on bootup.
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.
That takes around 10 lines of code in JFS.IFS.
But I am not the master of disaster. That is AN. They have the source code. And of course, it's closed source

[Andi B.]

I wouldn't call it ridiculous. I would say this is another shortcoming/bug/problem/nuisance of one part/program of our platform. Of course it may be easy to improve this situation with Lars proposed changes. No clue if David will implement it when Lars creates a ticket.

It's good that Lars shares his experience here to tell others about some problems and how to circumvent it. That's what a forum is good for.

But I also see a lot of other shortcomings. And when I were in the position to give priorities, this one would have a low priority. We only can wait and see what David says about this. Or is there any chance to get access to the latest JFS sources?

display a warning message and even force the user to hit Return to continue boot process

I fear this can be a problem with USB keyboards. The systems I have do not serve USB keyboards (with OS/2) until the end of the boot process. Every such "hit return to continue" condition while booting (while loading all the drivers from config.sys) needs the old PS/2 keyboard which luckily is also attached to step over. Here there is no chance to respond to such messages with the USB keyboard.

[OS4User]

It may have a sense to convert UNICODE.SYS from "DEVICE" to "BASEDEV".

[Lars]

I wouldn't call it ridiculous. I would say this is another shortcoming/bug/problem/nuisance of one part/program of our platform. Of course it may be easy to improve this situation with Lars proposed changes. No clue if David will implement it when Lars creates a ticket.

It's good that Lars shares his experience here to tell others about some problems and how to circumvent it. That's what a forum is good for.

But I also see a lot of other shortcomings. And when I were in the position to give priorities, this one would have a low priority. We only can wait and see what David says about this. Or is there any chance to get access to the latest JFS sources?

display a warning message and even force the user to hit Return to continue boot process

I fear this can be a problem with USB keyboards. The systems I have do not serve USB keyboards (with OS/2) until the end of the boot process. Every such "hit return to continue" condition while booting (while loading all the drivers from config.sys) needs the old PS/2 keyboard which luckily is also attached to step over. Here there is no chance to respond to such messages with the USB keyboard.

There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...

By the way: I cannot create a ticket as I am no paying AN customer. Somebody with an AN license would need to do that.

[Lars]

It may have a sense to convert UNICODE.SYS from "DEVICE" to "BASEDEV".

That is only going to remove the ordering dependency (UNICODE.SYS has to come before JFS.IFS). I can live with that ordering dependency but I cannot live with data loss because a vital driver wasn't loaded.

[Andi B.]

There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.

Yes it is a problem with other drivers too. That's why I'm think about. Specifically with ethernet drivers I often observed this when f.i. they do not find the correct chip. But other drivers too. I think PAUSEONERROR (or similar) can prevent stop the boot process. But using this is no good solution too because you probably wouldn't recognize the error message then as it flies away much to fast on current (< 10 years :-) ) hardware.

Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...

It does as long as something (ACPI, USB, ...?) very early in the boot process takes over control until the time when all the USB stuff, including usbhid is initialized (very late). In any case there is a big window during boot where USB keyboards do not work. From all what I understand and all the discussions about that (testers list, AN tickets) this window (non working usb keyboard) can not be eliminated. I never figured out how to sort config.sys to make this window as small a possible. But I got the impression it's impossible to cover all these places where device drivers may fire up this "hit return" message. We have to life with this when we want (or have) to use USB keyboards instead PS/2.

[Martin Iturbide]

...
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.
...

Hi

I agree that it should be very useful for JFS.IFS to display a warning message if UNICODE.SYS is not loaded. For what I know UNICODE is very important for JFS. But I'm not complete sure about if had to pause the boot process forcing the user to hit "return".

But I think I can open the ticket and let the implementation decisions to Arca Noae, since it is their product.

By the way, as far as it was discussed AN JFS.IFS is closed source and they treat the IBM source code base of it as the IBM DDK license.

Regards

[Dariusz Piatkowski]

Lars, everyone...

Sorry, but this is ridiculous.
...
But I am not the master of disaster. That is AN. They have the source code. And of course, it's closed source

Ahh, you see, and therein lies part of the challenge that causes majority of us to take a more pragmatic approach to dealing with these issues.

Yes, you are absolutely right about this being ridiculous, however, what other choice do we really have? There certainly isn't much ability for any of us to action it, even folks like yourself who have the technical know-how are finding themselves having their hands tied.

Sooo...instead of continuing the risk exposure I will do the best I can, with the tools/controls available to me today, to avoid that risk.

[Lars]

There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.

Yes it is a problem with other drivers too. That's why I'm think about. Specifically with ethernet drivers I often observed this when f.i. they do not find the correct chip. But other drivers too. I think PAUSEONERROR (or similar) can prevent stop the boot process. But using this is no good solution too because you probably wouldn't recognize the error message then as it flies away much to fast on current (< 10 years :-) ) hardware.

Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...

It does as long as something (ACPI, USB, ...?) very early in the boot process takes over control until the time when all the USB stuff, including usbhid is initialized (very late). In any case there is a big window during boot where USB keyboards do not work. From all what I understand and all the discussions about that (testers list, AN tickets) this window (non working usb keyboard) can not be eliminated. I never figured out how to sort config.sys to make this window as small a possible. But I got the impression it's impossible to cover all these places where device drivers may fire up this "hit return" message. We have to life with this when we want (or have) to use USB keyboards instead PS/2.

1) it's not PAUSEONERROR that influences the driver behaviour. It is what error code a driver returns from its INIT routine. It can report either "OK" or "NON_CRITICAL_ERROR" or "SOME_ERROR" (various different errors). "OK" and "NON_CRITICAL_ERROR" means to continue without interruption, "SOME_ERROR" means to stop and wait for keypress.
Obviously, the idea is that a severe error should prevent booting from continuing without the user noticing.

2) I don' t have a long time window of USB not working. I have a short time window of USB not working where the OS/2 HC drivers are loading and turning off legacy USB (start of time window) and finally have taken over the HC HW and the relevant USB devices mouse/keyboard have been enumerated (end of time window). On my system, that time window is about 5 seconds, keyboard works before and after that time window (that is, in particular during the bootup process where the video is in text mode). But I am using my USB drivers and I don't know if the AN drivers have a different behaviour.

[Lars]

...
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.
...

Hi

I agree that it should be very useful for JFS.IFS to display a warning message if UNICODE.SYS is not loaded. For what I know UNICODE is very important for JFS. But I'm not complete sure about if had to pause the boot process forcing the user to hit "return".

But I think I can open the ticket and let the implementation decisions to Arca Noae, since it is their product.

By the way, as far as it was discussed AN JFS.IFS is closed source and they treat the IBM source code base of it as the IBM DDK license.

Regards

Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

[Andi B.]

Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

That would be a very good work around. (Solution would be putting back unicode.sys into config.sys when it's not before jfs.ifs). Such 30s delay would be also very useful for ACPI or USB test versions when they outdate. A problem testers are bitten every now and then. F.i. even Keith at his presentation in Colonge...

[Martin Iturbide]

Hi

I had added the suggestion on the Arca Noae Ticketing System.
- https://mantis.arcanoae.com/view.php?id=3364

If it is not clear enough, I will appreciate if someone (with access) can add more information to the ticket.

Regards