Thanks Paul ..

of magnitude in the next message number upward!

[ ...trim... ]

What did I do?

Have you started using a different editor? Like, I
had to change MsgEd's setting for the 'LastRead'
pointer file's _name_ default, in order to get it
working properly.

No different editor at all. I'm using the same one. No, there were no changes
made in it. I have two different Max systems on the same box in OS/2, but their message base and the entire operation there are completely separated, while running in native OS/2 in two different sessions on the same box.

The IE operation is a totally separate affair, using a completely different partition arrangement operating in a DOS-VDM session on that same box with totally different hardware.

Up until this thing started, nothing line this ever happened.

I really do not know the editor in use for that IM application. It came with the HUB when I took it over by default and ported it to my OS/2 system. It ran just fine for a year when WHAM!

Do have another program, or user, using the same
netmail area? Any recent changes or additions to your
system?

No other program uses the same netmail area. The other systems use totally separate paritions even!

The BATCH file that runs this deal has not changed either!

This started when I added the LINUX echos. Two of them are reflectors from the
Internet side of life. Non-the-less, they are still SQUISH format message bases. They use EXACTLY the same message base definitions in FASTECHO as does everything else. Same editor, same everything. You can go through the FESETUP
game and can't tell any of this appart from any other echo of about 200 that are carried on the HUB.

I've looked at the SQUISH.CFG file for clues toward where you are pointing me.
I can't find any.

I wish you would expand on something you said above! MSGED is what came to me with the HUB. It is in use.

Like, I had to change MsgEd's setting for the 'LastRead'
pointer file's _name_ default, in order to get it
working properly.

I notice that in the MSGED.CFG file there are two references to 'lastread' in it. The first calls for a lastread lastread, which implies to me that there should be a file "lastread..something" in the MSGED directory. There is no file that has been created there by that name.

This HUB system isn'y my original setup. In that SQUISH is used in various places for different runs at things, there are the following SQUISH.CFG files, which, I think I'm being told are the things that MSGED uses for its indexing for caps!


These are in my OS/2 related efforts and I use AREAS.BBS for them:

SQUISH .CFG 36736 27-Apr-01 21:27:02 ---- D:\SQUISH
SQUISH .CFG 36736 23-May-00 05:41:38 ---- D:\SQUISHI

These all relate to the IM/FE setup I was dosed with:

SQUISH .CFG 16067 29-Jun-01 07:52:42 A--- E:\IM
SQUISH .CFG 16256 25-Jun-01 22:23:48 A--- E:\MAIL
SQUISH .CFG 19584 17-Mar-01 11:30:36 A--- E:\MAIL\TMP
SQUISH .CFG 16384 26-Mar-01 01:13:12 A--- E:\MAILER
SQUISH .CFG 649 15-Feb-96 15:57:18 A--- E:\MAILER\160
SQUISH .CFG 17792 26-Mar-01 01:11:46 A--- E:\MSGED

About the 25th or June or so is sure about where this mess was created! I notice that the MSGED and MAILER directory are frozen in time at 26-Mar. MAILER\TMP is a slush directory implanted by the former sysop.

SQUISH.CFG in E:\IM has the new stuff in it as of 29-Jun-2001, as does the one in E:\MAIL which has the real SQUISH in it! The others do not. Neither does the file "SQUISH" in E:\MSGED which I assume is the "ASCI" listing of what the export of FE did there:

SQUISH 24,934 14-02-96 18:10

Years ago before my time!

Thus, from your perspective, is the fact that this thing was laid out with all this stuff scattered all over heck and back, resposible? Before I just go copying again, you would advise that I simply conform all this to what is in the E:\MAIL directory for the MAILER ??

As you can tell, in my setup, by gar if it's going to drive something the silly
file will be in "ONE" place if I have anything to do with it!

Thanks for your time!

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

Mike @ 1:117/3001

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

Hi! Mike,

On 22 Jul 01 00:59, Mike Luther wrote to All:

Somehow, my InterMail / Fastecho combination has picked up a bad
habit it never had before!
When it gpes to send out mail packets via NETMAIL, it jumps an order
of magnitude in the next message number upward!

[ ...trim... ]

What did I do?

Have you started using a different editor? Like, I had to change MsgEd's setting for the 'LastRead' pointer file's _name_ default, in order to get it working properly.

Do have another program, or user, using the same netmail area? Any recent changes or additions to your system?

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.4
* Origin: 7 Days without pizza makes one week... (ZMH only) (3:640/384)

Somehow, my InterMail / Fastecho combination has picked up a bad habit it never
had before!

When it gpes to send out mail packets via NETMAIL, it jumps an order of magnitude in the next message number upward!

For example.

I there are four net mail messages below the number 10, such as message 4,5,6 and 7 that are still unsent, it will choose the number 10 for the next available message for a new round of traffic!

Then, it will ghost export messages 8 and 9 as useless empty messages on the way to 10.

If this insanity starts above 10, say at message 12 and 13 .. it will export new ghost 'messages' all the way up to message number 99 .. to reach the magic next available message 100!

Of course above that it goes to 1000 and then to 10000 and then .. disaster!

Of course 9999 messages never go anywhere and take forever to spiritually toss!
But the queue is apparently coded with a short integer variable and when it hits 32767 or whatever .. it rolls around to message number ONE and starts in all over there ... which corrupts things. As well, the cap counter in it isn't
a short integer! Thus it things that it may have 32769 as the next message, when it really was message number THREE by that time!

To plow around this insanity, I've temporarily put a MAX MR renumber on my NETMAIL area after every re-load of the batch file. That keeps the system from
fooling with more than 99 messages all the time!

But I'd like to fix this mess!

What did I do?

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

Mike @ 1:117/3001

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

Hi! Mike,

On 24 Jul 01 15:49, Mike Luther wrote to Paul Quinn:

Thanks Paul ..

Oh thanks for the headaches, Mike. ;)

I really do not know the editor in use for that IM application. It
came with the HUB when I took it over by default and ported it to my
OS/2 system. It ran just fine for a year when WHAM!

Intermail? It's the same sort of beastie as FrontDoor (FroDo), isn't it? So, you have a minimum of three progrms potentially screwing with your netmail (*.msg type?) area: IM's editor; FE; and, MsgEd. (FroDo's editor was/is called
FM.exe, so IM's editor will probably be a similar, separate, *.exe file.)

If that's the hub setup, then what mailer are you using for your regular node(s)?

No other program uses the same netmail area. The other systems use totally separate paritions even!

[ ...trim... ]

I wish you would expand on something you said above! MSGED is what
came to me with the HUB. It is in use.

Let's talk about lastread pointer files...

* In *.msg netmail areas the lastread is a file called "lastread<dot>",
in the netmail directory.

* In Squish areas it's a file called "<filename>.SQL", in the same
directory as the other <filename>.* files that make a Squish area.

* For a JAM area it's called "<filename>.JLR", in the same directory
as the other <filename>.* files that make a JAM area.

* For Hudson areas it's called "lastread.BBS", in the Hudson directory.

I have at least one of each messagebase type all looked after by FastEcho (with
some help with Squish 1.11 itself to update reply-links in the Squish areas). :-)

I notice that in the MSGED.CFG file there are two references to 'lastread' in it. The first calls for a lastread lastread, which
implies to me that there should be a file "lastread..something" in
the MSGED directory. There is no file that has been created there by that name.

Not in MsgEd's directory; it's in the *.msg netmail area (directory).

In the MsgEd.Cfg file, there should be two references to MsgEd's lastread netmail pointer, and I quote from my config file:

1. Name "%SYSOP%" LASTREAD 0
2. LastRead lastread

The first sets the *name* of the lastread file to use for _you_, the sysop. I had to set that for my config to work correctly. The second "should always be lastread"; author's statement, not mine. (I really wonder at the utility of providing the option for changing the value, when it should never be changed.<shrug>)

Groping back through the grey matter, back about a year, I think the *.msg netmail lastread pointer file was called "0<dot>", until I included the 'LASTREAD' info at line 1 (above). Of course, prior to the change, it was out of synch with FE and Binkley which were using another file called "lastread<dot>".

Sound familiar?

This HUB system isn'y my original setup. In that SQUISH is used in various places for different runs at things, there are the following SQUISH.CFG files, which, I think I'm being told are the things that
MSGED uses for its indexing for caps!

Such is the nature of the beast; it was a culture shock for me when I switched from FroDo to Binkley-style outbound mail, where the system events use the filenames of the outbound mail as 'flag' files, to drive the routing. It still
gives me tingles down the spine, two & half years later.

Depending on how MsgEd's config file is set, then yes, it might be told to use the Squisg.Cfg file for its indexing/lastread (*.SQLs) information. I've just got my config pointed to FE's config file and it's happy to use it (for the netmail/Squish areas; I use TimEd for the JAM/Hudson areas - yes! I'm on the lookout for a [Win/32] editor that'll do all four messagebase types, in the same way as does MsgEd).

These are in my OS/2 related efforts and I use AREAS.BBS for them:

Oooh! I thought I was the only one in Fido still using an Areas.BBS file! :)

SQUISH .CFG 36736 27-Apr-01 21:27:02 ---- D:\SQUISH
SQUISH .CFG 36736 23-May-00 05:41:38 ---- D:\SQUISHI

I guess you know what's happening with those.

These all relate to the IM/FE setup I was dosed with:
SQUISH .CFG 16067 29-Jun-01 07:52:42 A--- E:\IM
SQUISH .CFG 16256 25-Jun-01 22:23:48 A--- E:\MAIL
SQUISH .CFG 19584 17-Mar-01 11:30:36 A--- E:\MAIL\TMP
SQUISH .CFG 16384 26-Mar-01 01:13:12 A--- E:\MAILER
SQUISH .CFG 649 15-Feb-96 15:57:18 A--- E:\MAILER\160
SQUISH .CFG 17792 26-Mar-01 01:11:46 A--- E:\MSGED
About the 25th or June or so is sure about where this mess was
created! I notice that the MSGED and MAILER directory are frozen in
time at 26-Mar. MAILER\TMP is a slush directory implanted by the
former sysop.
SQUISH.CFG in E:\IM has the new stuff in it as of 29-Jun-2001, as
does the one in E:\MAIL which has the real SQUISH in it! The others
do not. Neither does the file "SQUISH" in E:\MSGED which I assume is
the "ASCI" listing of what the export of FE did there:
SQUISH 24,934 14-02-96 18:10
Years ago before my time!

:) Have a look at the batch file(s) for the IM/FE system and see where (the directory) the Squish *.exe files are, or, if the previous sysop used a "-c<pathname>\Squish.Cfg" parameter on the command-lines. That's where the one
& only Squish.cfg file should be. Dump the rest. (I can make brave statements
like that from this distance. :-)

Did he auto-generate a fresh Areas.BBs/Squish.Cfg pair of files during his BATch operation? (Gee, I thought I was the only sysop in Fido to do that.)

Did any of the above help, Mike?

Thus, from your perspective, is the fact that this thing was laid out with all this stuff scattered all over heck and back, resposible?
Before I just go copying again, you would advise that I simply
conform all this to what is in the E:\MAIL directory for the MAILER
??

I'd say to slip the previous sysop a couple of six-packs of Bud and employ him as a 'consultant' to sort the crap out, to suit your needs. :-) But, that's just what I would do...

Pity you aren't running BinkD. I could have blown a couple of hours running through a zipped-up copy of the hub config.<sfx: finger-down-throat> ;-)

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.4
* Origin: Road Kill on the Information Super Dirt Road (ZMH only) (3:640/384)

You sir .. chortle,

next time they jump
to 1000 and 1001 and to 10000 and 10001!!
Wierd ..

Damned right. There must be something else at play
there, if the prob shows only after a toss. Maybe a
*.msg renumbering util with a 'powers of 10' bug of
some sort.<shrug>

get to shrug.

Mikey gets poked with the sharp stick. ;)

In THEORY, the only message renumbering gizmo is the MAX utility MR, or it also
may be getting pranged with FASTECHO during that pass.

At the moment, the only way I have of solving it is to force MR to do a renumber of only the NETMAIL directory after every TOSS operation and before the system has finished calling each and every soul.

That keeps the whole insane thing at the bottom of the pit! But it ain't very sanitary living in a sewer like that... grin.

It makes now difference whether I run MSGED or not. Still there.

Crazy, one day just erupted! Can't get rid of it no matter what!

Since it is not a SQUISH format area, but a *.MSG area, I don't thing SQFIX can
handle it. I just, for the heck of it tried SQPACK, but dunno yet what,if anything it put to sleep.

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

Mike @ 1:117/3001






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

Ok, we're finally seeing this on 1:117/100, Mark ..

gloom. I dunno why I'm not seeing this on 1:117/3001 and it isn't there. It looks like I have something not right.

sounds like your copy of fastecho.exe (or whatever you are using) is buggered up... rename the one you have and extract
another copy from the original archive... remember to
run any necessary patches... then try this again... it
really really sounds like some program code has been
corrupted on the drive...

I've tried that. No change.

looking at the fastecho docs, and searching for
renumber, shows the HMB autorenumber option and the
feutil pack -renumber option...

please pull out another copy of the binary for the
flavor of FE that you are running and see if you still
have the same problem(s)...

But while this message was hidden it's suddenly fixed itself!

And get this!

What I did that provoked it, now that I know how it 'Fixed' itself, was to clean out all the old messages for Skeet from NetMail. I cleaned out the entire directory simply by marking them all as read or doing a DELETE and confirm with a "y" until NETMAIL was empty.

Problem started!

I get no NETMAIL inbound into 1:117/100 virtually at all. And the couple I did
I just read and deleted!

Suddenly I got a NETMAIL into 1:117/100 and didn't realize it! Surprise! As soon as it had ONE mail message INBOUND read or unread, it suddenly stopped doing this! So, I read the NetMail and left the inbound traffic to me in the NETMAIL diretory as MSG #1.

No more problem!

Explain that?

Mike @ 1:117/100


---
* Origin: BV HUB CLL(409)696-3600 (1:117/100)

And notwithstanding my previous post Mark ..

I took three messages in the NETMAIL directory and using a
command line session in a window in native OS/2, simply
renamed the messages from lower case to upper case as in:

ren *.msg *.MSG

Poof! No more run-away message counter!

somehow i don't see it... it's never done this on my
box over here... what OS are you running, again? yeah,
OS/2 but what 'flavor and fixpaks?? disk drivers and
such...

That too, still may be a part of the solution!

Here is why. This box is a complete SCSI box on Warp 4.0 FixPack 15. It has the IBM authorized kernel patch of WR0508.ZIP on it. Has the complete MPTN 8423, 8424 and 8425 fixes, as well as UN980 for TCPIP 4.1 which is still on it,
together with the PEER fix 8413, IIRC. There may be a later PEER fix on it.

I have discovered that CERTAIN DOS applications, when running under a DOS-VDM in OS/2 are actually leaving LOWER CASE letters in the file names! Not only that, but under DOS-VDM's in OS/2, if the application was written in some compilers and they compiler was actually writting the lower case name to the disk, you've got it! The file name is actually being accepted and handled in lower case by OS/2, even though a conventional pure command line DIR *.*, for example, in DOS, translates it to UPPER case as always!

Now, if you take the OS/2 command line session, and do that DIR *.*, you and see both the UPPER and LOWER CASE file names there! Of course, WIN-95 and OS/2
native code would and could and do that! But those programs which were written
by DOS programmers a while back which did not earlier have any problem with this because DOS gave you back, or mostly did, all UPPER case,would forgive you
of your sins come some other open or close attempt!

Early on we who used the MicroSoft PD7 BASCOM compiler had to watch for this in
certain DOS operating systems, including, it seems, OS/2 16 bit early stuff! There was a caution in the handbook about being sure to use all UPPER CASE file
names in your work, because PD7 could actually create and open and close a file
like, "MyFiLe.TxT" and, if you did it, only, at that time, PD7 could see it and
handle it. DOS itself, and most other programs,could not handle that at all.

Of course the advent of WIN-95 changed all this.

I think what is happening in the bug I've seen, is partly related to this,and as well partly related to the other portion of the 'fix', I noted in the previous message.

As long as there is ONE message, MSG #1, on the system in NetMail, which was in
INBOUND message to the system, and stays there, read or un-read, this error never seems to show up on this box again!

As far as I think I recall, FASTECHO is written in Borlund
Turbo Pascal,

flavor
====================
DOS Borland C++ - Copyright 1991 Borland Intl.
OS/2 Borland C++ - Copyright 1994 Borland Intl.
16bit Borland C++ - Copyright 1993 Borland Intl.
NT Borland C++ - Copyright 1993 Borland Intl.

OK .. still very much in vogue for non-GUI work with those who know the language well, I think.

all that i have on my system are currently dated 03
APR 1997 except for the NT version which is 01 JAN
1997...

again, i still think that it's due to corruption of
the program code in the EXE... at least look in that
direction and maybe do a binary compare out of
curiousity... tell ya what, send me a copy of that exe
file and i'll take a look at what i can see...

Does my explanation make any sense?

I know that I'm hitting all kinds of problems in FILE and MESSAGE area .CTL files in MAX with this. I have to be very careful. The HUB was an old DOS implementation with all UPPER CASE path names! I've been a lower case guy in describing them for years.

In mixing and integrating the two systems, I've discovered that by golly some of the programs in the DOS camp are making irregular errors with the paths which are in LOWER case which were created by the SILTP command for MAX. If you used SILT, the DOS version, they are UPPER CASE, even though your description was a lower case one! If you use SILTP, it even makes them LOWER CASE and .. to some progams, the program cannot handle that!

I'm almost of the opinion after working carefully with the beta code on these upgraded kernels for OS/2 from Austin here, that we are starting to see more problems in this post original FP 15 kernel code. I don't think anyone has seen this yet and reported it. I suspect that's because so few people in the for-real business world of OS/2 are still using DOS.

The bad part of this is that I don't have any actual way of proving it up,since
I don't have the source for these programs that are hitting it. Therefore, it never got reported or asked of Austin during the massive work that was recently
done on the Warp 4.5 kernel for MCP and ACP and FP 15 as well. I'f I'd seen it
or know it, I'd have asked about it. By now Austin has moved forward on other things and I've not seen a later kernel than about August 8th or so. That one had no mention of anything like this in it at all....

gloom.

Mike @ 1:117/100

---
* Origin: BV HUB CLL(409)696-3600 (1:117/100)

This is nuts, Paul.

I've got this echo enabled on both 1:117/100 and 1:117/3001 and I never even saw the below on 1:117/3001 which is the unit I use all the time for correspondence and not the HUB.

Sorry.

Thump to forehead! What version of FE do you have
there, Mike? (Are you running patch level #1 to FE
1.46? I.e., does FE's TOSS or SCAN logs report
version "1.46.1"?)

It's 1.46.1 here ..

Mike @ 1:117/100

---
* Origin: BV HUB CLL(409)696-3600 (1:117/100)

Interesting note!

Thump to forehead! What version of FE do you have
there, Mike? (Are you running patch level #1 to FE
1.46? I.e., does FE's TOSS or SCAN logs report
version "1.46.1"?)

I have a solution of sorts!

This system gets very few NetMail INBOUND items! I'd decided to try to operate
in on none. So if I got one, read it, I just killed it. Suddenly,I got one I needed to leave on it for a few days.

Suddenly, the whole grunged message deal stopped!

Seems like, for whatever reason, FE absolutely now has to have at least ONE read or unread NetMail message that is *TO* the system as 1.MSG in the NetMail directory!

As long as it is there, fine.

If you don't have it there, disaster!

I elaborated on how some of this might be happening in this latest incantation of OS/2 DOS-VDM sessions. However it's conjecture and I cannot prove it at this point ...

Mike @ 1:117/100



---
* Origin: BV HUB CLL(409)696-3600 (1:117/100)

Hi! Mike,

On 05 Sep 01 23:03, Mike Luther wrote to Paul Quinn:

I've got this echo enabled on both 1:117/100 and 1:117/3001 and I
never even saw the below on 1:117/3001 which is the unit I use all
the time for correspondence and not the HUB.

:) Understood, Mike.

Thump to forehead! What version of FE do you have
there, Mike? (Are you running patch level #1 to FE
1.46? I.e., does FE's TOSS or SCAN logs report
version "1.46.1"?)

It's 1.46.1 here ..

Seen! This is the first message of yours that I've seen your tear ID kludge as
well (no doubt from the hub)...

@TID: FastEcho 1.46.1 8490

It's cool. I had thought for a short while that the reason behind the #1 patch
to FE 1.46 might have been the answer (if you weren't running that patch), but I had forgotten at the time I wrote the above that you use Intermail and not Binkley for the hub's mailer.<blast>

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.5
* Origin: ..then, suddenly, my swash came unbuckled.. (ZMH only) (3:640/384)

Hi! Mike,

On 05 Sep 01 23:05, Mike Luther wrote to Paul Quinn:

I have a solution of sorts!

Excellent!

This system gets very few NetMail INBOUND items! I'd decided to try
to operate in on none. So if I got one, read it, I just killed it. Suddenly,I got one I needed to leave on it for a few days.
Suddenly, the whole grunged message deal stopped!
Seems like, for whatever reason, FE absolutely now has to have at
least ONE read or unread NetMail message that is *TO* the system as
1.MSG in the NetMail directory!
As long as it is there, fine.

Cool. Don't fix it any more.<nudge, nudge>

Ermm... just between you, me & that aardvark over there... my system never has anything in the primary netmail area, unless it's in transit or outbound (in which case it'll get packed-up by FE to an outbound bundle), or unless it is inbound to me (in which case FE imports it to a secondary netmail area, and, subsequently deletes it from the primary area). Nutin' dere but the lastread file. :)

If you don't have it there, disaster!
I elaborated on how some of this might be happening in this latest incantation of OS/2 DOS-VDM sessions. However it's conjecture and I cannot prove it at this point ...

Yes, and from what you have written to Mark Lewis... I would tend to agree. You have a (perhaps?) unique combination of system, & application software, there, producing a quite curious side-effect.<giggle>

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.5
* Origin: [this space intentionally left blank] (ZMH only) (3:640/384)

Seems like, for whatever reason, FE absolutely now has to have
at least ONE read or unread NetMail message that is *TO* the
system as 1.MSG in the NetMail directory!

you should have seen my reply to you "WRT highwater marks" by now...

this requirement is similar to the hudson messagebase format area path having to be defined, as well... FE must have those HMB files available even if they aren't used at all... similar situation...

)\/(ark


* Origin: (1:3634/12)

Suddenly I got a NETMAIL into 1:117/100 and didn't realize it!
Surprise! As soon as it had ONE mail message INBOUND read or
unread, it suddenly stopped doing this! So, I read the
NetMail and left the inbound traffic to me in the NETMAIL
diretory as MSG #1.

No more problem!

yeah, i read that... interesting, eh? OB-)

Explain that?

as i understand it, 1.MSG was the highwater marker or some such... i remember systems that 1.msg usually contained something in it's body to the effect of

"highwadda mark. please ignore."

FWIW: here's all the info located in FASTECHO.DOC that contains the word "water" in it...

=== snip ===

6.3.4 - FastEcho Scan -I

FastEcho, in order to increase its high speed while scanning
JAM, Squish and *.MSG messagebases, can make use, and update
too, the so called HighWaterMarks. When FastEcho performs the
"SCAN" operation upon JAM, SQUISH and *.MSG messagebases, in
fact, thanks to the HighWaterMarks system, it can keep track of
the last message which has been processed in a previous
scanning, so, if not otherwise specified, it will check only the
newer messages (having higher message numbers) starting the scan
operation directly from the address pointed by the
HighWaterMarks, instead of scanning the whole message base,
saving, in this way, a lot of precious time that could be spent
otherwise. Nevertheless, it could happen that, some old
messagebase editors don't set these "marks" correctly. in this
case the -I switch could be helpful. If you specify the "-I",
infact, FastEcho will ignore the HighWaterMarks index
completely, so, the whole messagebase will be scanned from the
beginning to end.

=== snip ===

)\/(ark


* Origin: (1:3634/12)

Suprised at this Long Delayed Echo Paul?

Yes, and from what you have written to Mark Lewis... I would tend to agree. You have a (perhaps?) unique combination of
system, & application software, there, producing a
quite curious side-effect.<giggle>

I think I know more about this curious side-effect!

Lookie here at what seems to have, maybe, 'solved' it!

The commented out line at the top below from my batch file which calls the utility MOVEMAIL has a -t command line parameter in it. In theory, that is a valid and goodie! But on *VERY* close inspection I discovered that an error flag comment was popping at this call line! It said "Illegal parameter -t", but apparently was moving this stuff somewhere.. In theory,this was only, in the call below, stuff in outbound destined for the HUB,Steve Loupe in Houston at 1:106/1, but .. And there is another one of these for one other instance of
MOVEMAIL elsewhere!

:: loadhigh movemail -se:\outbound -de:\fnos\ftpout -fdcf36924 -e -t
loadhigh movemail -se:\outbound -de:\fnos\ftpout -fdcf36924 -e

As well you may be curious about the LOADHIGH DOS command! Well, in OS/2 DOS-VDM sessions, I found out that MOVEMAIL pops a SYS3175 error all the time if I don't try to use that! Now I *THINK* I might be able to bust that error on MOVEMAIL by careful manipulation of a DOS-VDM session setting parameter list
for the OS/2 DOS-VDM, but that isn't possible when you are running these things
out of a batch file, unless you use ORUN or DHANG to force the thread. So the simplest fix for it was just to load it high and forget about the bug!

I was trying to isolate a curious hard lock hang with the AIC154X.ADD OS/2 Adaptec SCSI disk driver and 1542C cards. It suddenly popped up when we moved from the Kernel that was distributed with Fixpack 15 to the IBM official later one in W40508.ZIP in May this year! It got better in the one that was just released as W41026.ZIP in October. But in tracing this pest which only is popped by DOS-VDM sessions, and is so nasty it locks the whole box hard lock red light on, and only power down to break it, I tried something.

I coded every single one of the .BAT and .CMD file for the three BBS systems which run on this box. Using a completely separate flag file and screen pop display file for each step, I was FINALLY able to trace exactly what step all three systems were at when the lock fired. In doing that, this curious little error message above flipped by.

So .. I commented out the -t, just to see what would happen.

The error we discussed seems to have vanished! At least what was left of it after I discovered that I could leave a single message in my NetMail area all the time and that broke most of it!

Wierd!

For anyone reading along on the curious DOS lock deal for Adaptec 1542C cards and Warp 4.5 with FP-15, I have another suggestion! There are SOME dos utilities out there which can use DMPI memory which are *NOT* Windows code! For example, PKZIP and PKUNZIP .. and .. also .. There are SOME BBS programs which seem to be DMPI aware, even if they do not, perhaps USE this memory. I think they may be looking at somehow sniffing if they are maybe running under a
WIN 3.x system!

At any rate, I have discovered that if this *IS* a problem, you can seemingly break or near fix it! You must *NOT* use the DOS-VDM session setting command in OS/2 to let a program have Interrupts before the disk action is finished. As well, you need to also set the DOS-VDM session parameter for DMPI enablement
to ALWAYS on, even if you technically use no DMPI memory applications and this curious lockup is astraddle your pony!

As well, a prime DOS-VDM batch file using the old AIC154X.ADD and an old 1542C card can also, it seems, be induced into stability by adding the option to the DOS-VDM session settings to let the session have direct access to the HARDWARE for the box.

This also includes things that have FASTECHO in them, so all this should be on topic here!

Happy turkey day!





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

Hi! Mike,

On 21 Nov 01 19:13, Mike Luther wrote to Paul Quinn:

This also includes things that have FASTECHO in them, so all this
should be on topic here!

:)

Happy turkey day!

And to you & yours, too, Mike!

Cheers,
Paul.

--- BT-W32 2.60XEg6/BinkD-W32 0.9.5
* Origin: WARNING! Don't Press THE BIG RED BUTTON! (ZMH only) (3:640/384)