Text 701, 92 rader
Skriven 2007-05-14 06:01:04 av Mike Luther (1:117/3001.0)
    Kommentar till text 700 av Marc Lewis (1:396/45.0)
Ärende: re: System peculiarities...
===================================
Well, Marc

 ML> I sure hope these discussions aren't a bother; I
 ML> simply don't know QUITE a bit about the OS that I use 
 ML> and mostly enjoy...

I really don't know much about it either.

 ML> Well, looks like I've found something broken in the 14.103 kernal...  
 ML> The "SUPPRESSPOPUPS=C:" directive in CONFIG.SYS no 
 ML> longer works.  For example:  I made a couple changes 
 ML> to the CONFIG.SYS on the BBS machine and did the 
 ML> obligatory shutdown/reboot.  During the boot up time 
 ML> the BinkP server wanted to write a file to the toss 
 ML> directory on the BBS machine. The .cmd file that does 
 ML> that looks first to see "if exist d:\nul copy xxxx.xxx 
 ML> d:\directory". If the mapped d: drive is not 
 ML> available, normally the machine would just go on to 
 ML> the next line in the .cmd file.  NOW it stops and a 
 ML> pop-up appears with the warning that the network 
 ML> resource is no longer available - - instead of logging 
 ML> it and suppressing the pop-up screen.

 ML> I think it's time for me to do that upgrade to the kernal, don't you?

Know what you get when you cross an owl and Pinnochio?  "Whoknows"!

Interesting.  Though I know about the SUPPRESSPOPUS option in CONFIG.SYS I've
not used it on the BBS system here.  One more I have as a comment in the BBS
system file might be helpful.

 REM ** Below suppresses popup errors and logs them to x=c
 REM SUPPRESSPOPUPS=x
 REM ** Forces reboot on trap errors <---- new with Warp. default=off
 REM REIPL=ON
 REM ** Lets computer continue boot on non-fatal boot run errors
 PAUSEONERROR=NO
 REM ** forces computer to deliver system error to the application
 direct.
 SET AUTOFAIL=YES

Notice the two below which are not commented out?

I wonder if the addition of the PAUSEONERROR=NO option would allow the continue
of the boot run even if your above behavior change is also seen in the 14.104a
Kernel?  As well as the AUTOFAIL=YES option.  Also I wonder about the
possibility if the order of appearance in the CONFIG.SYS file sensitivity might
have changed in the kernel you now see this on?  Such that if you placed the
SUPPRESSPOPUPS option higher in the CONFIG.SYS file it might go back to working
the way you had it working before?

Long ago and far away, IBM had a URL where you could go and hit it to see what
the total collage of APAR's were which had been submitted and 'fixed' in the
OS/2 operation on one of their sites for OS/2.  My Seamonkey library of Pig
Trails shows where I think things like this were tracked and logged:

   http:\\www7.software.lbm.com\pspfixpk.nsf

Starting there one can drill into the APAR game and work into what has been
filed and what has been fixed in many things applicable to OS/2 and whatever. 
Problem is, to my fuzzy memory, when it comes to Kernel updates, I don't think
you'll find the list of APAR's that have been submitted which become/became
APAR's that are the subject of Kernel updates there.  Which is why I posted the
README text for the Kernel update file between the 14.103 as released Kernel
and what I had for you to see.

I can tell you that the update process which is available the way I have it
here and was what I looked at in writing the little .CMD file I've used has the
provision to back out the Kernel you chose with witch to update and go back to
the one that was there before you played this game.

But this is as bad as Little Red Riding Hood.  "Grandma what big teeth you
have!"  And when you set off into the woods, the infernal owl is standing over
your shoulder, chanting, "Whoknows!  Whoknows! Whoknows!"

Plus one of the most fascinating things I've ever seen was about 5AM after
another all night session of OS/2 debugging when I heard all this scritch,
scritch outside when I took a step out into the just at dawn darkness.

And was treated to the most beautiful collection of four little baby owls all
pearched side by side on the same branch of a tree, just learning to fly I
guess.

After which I went inside, re-booted, and the system worked fine!


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)