Hey Wayne,

03 Jul 04 12:01, you wrote to All:

Hi All,

I've done further investigations into this EleBBS/WEB 1 day message problem and found that if I have a hudson or a Squish message base
the DATE is correct so it is only in a JAM message area... As far as
I can tell EleBBS uses Mark May's Source code... So would this narrow
it down to maybe a MKMSGJAM.PAS problem?

Sorry for not replying to anyones message but been working heaps of
late work/sleep is my day 2 days off now...

Likely place to start. If you do find the issue and fix it, mind Netmailing or E-mailing the updated PAS file to me so I can include it in the next EleBBS release (whenever that is)?

-- Dan

--- FMail/Win32 1.60
* Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)

I've done further investigations into this EleBBS/WEB
1 day message problem and found that if I have a hudson
or a Squish message base the DATE is correct so it is
only in a JAM message area... As far as I can tell
EleBBS uses Mark May's Source code... So would this
narrow it down to maybe a MKMSGJAM.PAS problem?

that is interesting... i wasn't aware that they were using mark may's stuff... it does make sense, though...

i found and patched numerous bugs in mark's stuff over the years... i don't recall what those fixes were nor did i mark them down anywhere or comment them with IDs in the code... however, i'm willing to make what i have available for others to look at...

FWIW: i have several tools that create messages in JAM bases and they all use mark's code... none of them exhibit this problem...

)\/(ark


* Origin: (1:3634/12)

FWIW: i have several tools that create messages in JAM bases
and they all use mark's code... none of them exhibit this
problem...

this got out before i had a chance to add this...

i just looked at the MKMSGJAM that i have and i do see these two notes at the top...

{
changed MSGTIME from 5 characters to 8 characters to get real seconds
instead of forcing them to zero.
MFL - 13 June 96

added SETATTR procedure to allow specific access to attributes
MFL - 9 June 96
}


it is possible that i may have fixed something else, too...

i note that the date stuff is also run thru several conversions... the date is run thru DTToUnixDate which converts the borland DT (datetime) format to unixtime format... unixtime format is the number of seconds since 1970, IIRC...
part of that process is to convert the days past from gregorian to julian...

here are those routines and the few variables... check that you find them as so
in your code...

[from MKMISC.PAS]

Const
C1970 = 2440588;
D0 = 1461;
D1 = 146097;
D2 = 1721119;

[...]

{$IFDEF WINDOWS}
Function GregorianToJulian(DT: TDateTime): LongInt;
{$ELSE}
Function GregorianToJulian(DT: DateTime): LongInt;
{$ENDIF}
Var
Century: LongInt;
XYear: LongInt;
Temp: LongInt;
Month: LongInt;

Begin
Month := DT.Month;
If Month <= 2 Then
Begin
Dec(DT.Year);
Inc(Month,12);
End;
Dec(Month,3);
Century := DT.Year Div 100;
XYear := DT.Year Mod 100;
Century := (Century * D1) shr 2;
XYear := (XYear * D0) shr 2;
GregorianToJulian := ((((Month * 153) + 2) div 5) + DT.Day) + D2
+ XYear + Century;
End;

[...]

{$IFDEF WINDOWS}
Function DTToUnixDate(DT: TDateTime): LongInt;
{$ELSE}
Function DTToUnixDate(DT: DateTime): LongInt;
{$ENDIF}
Var
SecsPast, DaysPast: LongInt;

Begin
DaysPast := GregorianToJulian(DT) - c1970;
SecsPast := DaysPast * 86400;
SecsPast := SecsPast + (LongInt(DT.Hour) * 3600) + (DT.Min * 60) + (DT.Sec);
DTToUnixDate := SecsPast;
End;

[... and then back to the routine in MKMSGJAM.PAS ...]

Function JamMsgObj.WriteMsg: Word;
Var
{$IFDEF WINDOWS}
DT: TDateTime;
{$ELSE}
DT: DateTime;
{$ENDIF}
WriteError: Word;
i: Word;
TmpIdx: JamIdxType;

Begin
WriteError := 0;
If LastSoft Then
Begin
DoChar(#13);
DoChar(#10);
End;
If WriteError = 0 Then
Begin
MsgHdr^.JamHdr.Signature[1] := 'J';{Set signature}
MsgHdr^.JamHdr.Signature[2] := 'A';
MsgHdr^.JamHdr.Signature[3] := 'M';
MsgHdr^.JamHdr.Signature[4] := #0;
Case JM^.MailType of
mmtNormal: SetAttr1(Jam_TypeLocal, True);
mmtEchoMail: SetAttr1(Jam_TypeEcho, True);
mmtNetMail: SetAttr1(Jam_TypeNet, True);
End;
MsgHdr^.JamHdr.Rev := 1;
MsgHdr^.JamHdr.DateArrived := ToUnixDate(GetDosDate); {Get date processed}
DT.Year := Str2Long(Copy(JM^.MsgDate, 7, 2)); {Convert date written}
DT.Month := Str2Long(Copy(JM^.MsgDate, 1, 2));
DT.Day := Str2Long(Copy(JM^.MsgDate, 4, 2));
If DT.Year < 80 Then
Inc(DT.Year, 2000)
Else
Inc(DT.Year, 1900);
{ DT.Sec := 0; }
DT.Sec := Str2Long(Copy(JM^.MsgTime, 7, 2));
DT.Hour := Str2Long(Copy(JM^.MsgTime, 1, 2));
DT.Min := Str2Long(Copy(JM^.MsgTime, 4, 2));
MsgHdr^.JamHdr.DateWritten := DTToUnixDate(DT);
End;

there is more code in this routine but this is the code leading up to the setting of the date written... do you have the same problem with the setting of
the date arrived? they should be the same for locally (on the bbs) written messages... you can see my alteration as noted for setting actual seconds in the time field instead of forcing them to zero... i did this alteration in an effort to get around buggy code that thinks that numerous messages written in the same second are duplicates... i have tested my stuff from this blackbox library at generating several hundred messages per minutes without then being caught as dupes ;)


tracing a bit "further on", we find this code...

Procedure JamMsgObj.StartNewMsg;
Begin
JM^.TxtBufStart := 0;
JM^.TxtPos := 0;
FillChar(MsgHdr^, SizeOf(MsgHdr^), #0);
MsgHdr^.JamHdr.SubFieldLen := 0;
MsgHdr^.JamHdr.MsgIdCrc := -1;
MsgHdr^.JamHdr.ReplyCrc := -1;
MsgHdr^.JamHdr.PwdCrc := -1;
JM^.MsgTo := '';
JM^.MsgFrom := '';
JM^.MsgSubj := '';
FillChar(JM^.Orig, SizeOf(JM^.Orig), #0);
FillChar(JM^.Dest, SizeOf(JM^.Dest), #0);
JM^.MsgDate := DateStr(GetDosDate);
JM^.MsgTime := TimeStr(GetDosDate);
End;

this indicates that the date the message is written comes from the GetDosDate routine... that's a simple routine that gets the date and time from the system clock and packs it into the longint that GetDosDate returns...

from what i can tell, StartNewMsg is the first place in the code that the date of the message is set and its done automatically by the above which just reads the system clock...

[time passes]

i see in my code that i do the following...

init the message == StartNewMsg
set the addresses to/from == SetDest and SetOrig
set the attributes == many Set* routines
put the control lines == DoStringLn and/or DoKludgeLn
load the message text body == DoString and DoStringLn
write the message to the message base == WriteMsg

i note that when i set the attributes, that i also set the date in the same basic way that was already done... i don't remember why i set the date again...
possibly because it wasn't being done when i first started using the msg kit and then after some updates, it was... no matter, really, both use the same DateStr(GetDosDate)... i do mine with the SetDate routine whereas the other is
done directly into the same JM^.MsgDate variable... i could do this also via msgout^.JM^.MsgDate IIRC but the SetDate routine is easier since it is supposed
to be used in a blackbox fashion ;)

DateStr formats the date to MM-DD-YY format with leading zeros where needed...

am i going to have to go digging thru the Elebbs code? OB-)

)\/(ark


* Origin: (1:3634/12)

Hey mark,

07 Jul 04 00:49, you wrote to Wayne Steele:

FWIW: i have several tools that create messages in JAM bases
and they all use mark's code... none of them exhibit this
problem...

this got out before i had a chance to add this...

i just looked at the MKMSGJAM that i have and i do see these two notes
at the top...

{
changed MSGTIME from 5 characters to 8 characters to get real
seconds instead of forcing them to zero. MFL - 13 June 96

added SETATTR procedure to allow specific access to attributes
MFL - 9 June 96
}

Nice. Mark, would you netmail that unit to me? Since I am writing message base utils for EleBBS that might be handy to have. I wonder if Maarten is even still
around anymore. Haven't heard from him in the echo for over a year I think.


-- Dan

--- FMail/Win32 1.60
* Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)

i just looked at the MKMSGJAM that i have and i do see these
two notes at the top...

{
changed MSGTIME from 5 characters to 8 characters to get real
seconds instead of forcing them to zero. MFL - 13 June 96

added SETATTR procedure to allow specific access to attributes
MFL - 9 June 96
}

Nice. Mark, would you netmail that unit to me?

i can get it together and make it available but first i'd like to see if i can get hold of mark may and get approval for releasing my mods... note that i've only worked with this under TP6... i believe that i did do some experimenting with BP6... i've not tried to use it at all under delphi or any windows or os/2
native pascal compilers...

Since I am writing message base utils for EleBBS that might
be handy to have. I wonder if Maarten is even still around
anymore. Haven't heard from him in the echo for over a year
I think.

i don't know if he is still around or not...

further on my mods, i remember fixing one bug that would cause control lines to
be skipped... the fix was to add a simple DEC() call since the routine was one character too far ahead to see the start of the next control line... the result
was that every other control line was missed...

i know there were other things, too... just kinda wish i had documented them more... one thing that i've been wanting to do was to incorporate the filebuffering stuff into those other message base formats that don't have it...
MSG and JAM are the only two that use it and mark never got around to putting it in all of them before releasing his bbs source code with mkmsg in it...

)\/(ark


* Origin: (1:3634/12)

[ 03 Jul 04 12:01, Wayne Steele wrote to All ]

I've done further investigations into this EleBBS/WEB 1 day message problem and found that if I have a hudson or a Squish message base
the DATE is correct so it is only in a JAM message area... As far as
I can tell EleBBS uses Mark May's Source code... So would this narrow
it down to maybe a MKMSGJAM.PAS problem?

Gawd DAY-EM! What a rats' nest.

First, you should have your TZ environment variable set. TZ=EST-10 if you're in Sydney/Melb/etc.

Second, it looks like unix2norm() is FUBAR. Which is really odd since a simple
unix2norm(norm2unix()) would tell you it's broken, and this is a piece of code that's been floating around for ages (and obviously used by many people). The fix eludes me (at 5am), so I rewrote it. This isn't well tested, but it Works For Me. I can compile Win32 and Linux binaries, if you're running OS/2 or something you'll have to compile it yourself. Just replace unix2norm with the following in elebbs/src/unixdate.pas.



Procedure Unix2Norm(Date: LongInt; var Year, Month, Day, Hour, Min, Sec: Word);

(* Scott Little, 2004-07-04
"Day" was always one day late, except for the first day of the month.
Couldn't fix. Rewrote. Untested.
*)

var
Done : Boolean;
X : ShortInt;
TotDays : Integer;
begin
Year := 1970;
Month := 01;
Day := 01;
Hour := 00;
Min := 00;
Sec := 00;

Date := Date + (GetTimeZone * SecsPerHour); { Local time/date }

while Date >= SecsPerYear do
begin
if IsLeapYear(Year) and (Date < SecsPerLeapYear) then
break;

if IsLeapYear(Year) and (Date >= SecsPerLeapYear) then
begin
Inc(Year, 1);
Dec(Date, SecsPerLeapYear);
end
else
begin
Inc(Year, 1);
Dec(Date, SecsPerYear);
end;
end;

TotDays := Date DIV SecsPerDay;

for X := 12 downto 1 do
begin
if X = 1 then
break;

if isLeapYear(Year) and (TotDays >= DaysPerLeapYear[X - 1]) then
begin
Dec(Date, DaysPerLeapYear[X - 1] * SecsPerDay);
Dec(Totdays, DaysPerLeapYear[X - 1]);
break;
end
else if (not isLeapYear(Year)) and (TotDays >= DaysPerYear[X - 1]) then
begin
Dec(Date, DaysPerYear[X - 1] * SecsPerDay);
Dec(Totdays, DaysPerYear[X - 1]);
break;
end;
end;

Month := X;

Day := TotDays + 1;
Dec(Date, (Day - 1) * SecsPerDay);

Hour := Date DIV SecsPerHour;
Dec(Date, Hour * SecsPerHour);

Min := Date DIV SecsPerMinute;
Dec(Date, Min * SecsPerMinute);

Sec := Date;

end; { proc. Unix2Norm }



-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

Hey mark,

08 Jul 04 15:58, you wrote to me:

i can get it together and make it available but first i'd like to see
if i can get hold of mark may and get approval for releasing my
mods... note that i've only worked with this under TP6... i believe
that i did do some experimenting with BP6... i've not tried to use it
at all under delphi or any windows or os/2 native pascal compilers...

Should be compatable. But if not either I'll enlist your help in fixing it or just hack at it myself.

Since I am writing message base utils for EleBBS that might
be handy to have. I wonder if Maarten is even still around
anymore. Haven't heard from him in the echo for over a year
I think.

i don't know if he is still around or not...

Netiher do I. Which is why I adopted EleBBS sorta. I've had three BBS software's I use abandoned, I don't want to make it #4. Teleard, TAG, and RemoteAccess all were abandoned by their author. Yes Telegard and RA were picked up again, but they also seem to have been dropped again. I'm determined to not let that happen to EleBBS untill no one is using it, or till I just cann't do it anymore.

-- Dan

--- FMail/Win32 1.60
* Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)

I've done further investigations into this EleBBS/WEB
1 day message problem and found that if I have a
hudson or a Squish message base the DATE is correct
so it is only in a JAM message area... As far as I
can tell EleBBS uses Mark May's Source code... So
would this narrow it down to maybe a MKMSGJAM.PAS
problem?

Gawd DAY-EM! What a rats' nest.

where? in ele or the mk library?

First, you should have your TZ environment variable set.
TZ=EST-10 if you're in Sydney/Melb/etc.

Second, it looks like unix2norm() is FUBAR. Which is really

i don't see unix2norm in the mkmsg stuff... it must be something in the ele code...

odd since a simple unix2norm(norm2unix()) would tell you it's
broken,

hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses UnixToDT
and DTToUnix to convert the datetime record format back and forth...

and this is a piece of code that's been floating around for
ages (and obviously used by many people).

makes me even more curious, now...

The fix eludes me (at 5am), so I rewrote it. This isn't
well tested, but it Works For Me.

did you test leapyears ;)

I can compile Win32 and Linux binaries, if you're running
OS/2 or something you'll have to compile it yourself.
Just replace unix2norm with the following in
elebbs/src/unixdate.pas.

ahhh... thought it would have to have been some ele code and not the mkmsg code...

Procedure Unix2Norm(Date: LongInt; var Year, Month, Day, Hour,
Min, Sec: Word);

hummm... very similar to the datetime record format... just all in pieces instead of in one record...

)\/(ark


* Origin: (1:3634/12)

[ 09 Jul 04 13:44, mark lewis wrote to Scott Little ]

Gawd DAY-EM! What a rats' nest.

where? in ele or the mk library?

Ele. The ifdefs.... awmigawd the ifdefs... *cries*

odd since a simple unix2norm(norm2unix()) would tell you it's
broken,

hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses UnixToDT and DTToUnix to convert the datetime record format back and forth...

The mkmsgjam.pas in the Ele source tree has been modified to use unixdate.pas and jdates.pas from the parent (elebbs) directory. In fact, the whole mkmsg source included with Ele has been drastically pruned.

The original mkmsg source (v1.04 is what I have) uses a different algorithm. I'll have a look at it later and see if it's accurate, if so I'll massage it into unix2norm() form, since it's no doubt much more tested than my code.

and this is a piece of code that's been floating around for
ages (and obviously used by many people).

makes me even more curious, now...

It's from SWAG, BTW. And the first whole page of hits off Google for any searches mentioning unix, dates, and Pascal.

The fix eludes me (at 5am), so I rewrote it. This isn't
well tested, but it Works For Me.

did you test leapyears ;)

Of course :)

It doesn't take into consideration leapseconds or any of that other stuff though. But a few seconds here and there over a couple of decades is accurate enough for our purposes.


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

Netiher do I. Which is why I adopted EleBBS sorta. I've had
three BBS software's I use abandoned, I don't want to make it
#4. Teleard, TAG, and RemoteAccess all were abandoned by their
author. Yes Telegard and RA were picked up again, but they
also seem to have been dropped again. I'm determined to not
let that happen to EleBBS untill no one is using it, or till I
just cann't do it anymore.

understand that... what compiler are you using? what OS' are you compiling for?
where is the project based?

)\/(ark


* Origin: (1:3634/12)

Gawd DAY-EM! What a rats' nest.

where? in ele or the mk library?

Ele. The ifdefs.... awmigawd the ifdefs... *cries*

i can imagine... i've thought about taking a look and seeing what i can see... maybe not, now ;)

odd since a simple unix2norm(norm2unix()) would tell you it's
broken,

hummm... wonder what that compares with in the mkmsg stuff? mkmsg uses
UnixToDT and DTToUnix to convert the datetime record format back and
forth...

The mkmsgjam.pas in the Ele source tree has been modified to
use unixdate.pas and jdates.pas from the parent (elebbs)
directory. In fact, the whole mkmsg source included with Ele
has been drastically pruned.

ouch... that may not be a good thing...

The original mkmsg source (v1.04 is what I have) uses a
different algorithm. I'll have a look at it later and see if
it's accurate, if so I'll massage it into unix2norm() form,
since it's no doubt much more tested than my code.

ahh, yes, v1.06 made several fixes and implemented filebuffering for large message capablity... JAM and MSG are now limited only to available drive space or max message base size, IIRC... can you imagine a 4terabyte message O%-)

and this is a piece of code that's been floating around for
ages (and obviously used by many people).

makes me even more curious, now...

It's from SWAG, BTW. And the first whole page of hits off
Google for any searches mentioning unix, dates, and Pascal.

hummm... hey, i've got SWAG installed on my machine, IIRC... the last one released, anyway...

[time passes]

whoa! that brings back some memories... i've got 10 snippets in there... should
be more but there are 10 with just my name on them...

i found the unix2norm routine... its not anything like the stuff i use...

The fix eludes me (at 5am), so I rewrote it. This isn't
well tested, but it Works For Me.

did you test leapyears ;)

Of course :)

It doesn't take into consideration leapseconds or any of that
other stuff though. But a few seconds here and there over a
couple of decades is accurate enough for our purposes.

yup, my feelings, too...

)\/(ark


* Origin: (1:3634/12)

[ 09 Jul 04 22:30, mark lewis wrote to Scott Little ]

hummm... hey, i've got SWAG installed on my machine, IIRC... the last
one released, anyway...

What version? I have.. umm.. reader v3.13, and the most recent files are 1997-10-07.


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

[ 09 Jul 04 22:30, mark lewis wrote to Scott Little ]

ahh, yes, v1.06 made several fixes and implemented filebuffering for

Hmm... it looks like v1.06 has the:

BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
to
BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

fix, but what about the:

If JM^.TxtSubChars <= TxtSubBufSize Then
to
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

one? Did that turn out not to be needed?


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

i found the unix2norm routine... its not anything like
the stuff i use...

Here's one that I (and several others) have used for more than ten years now. Take it or leave it. :)

- = * = -

unit UnixUtil;

{ By Björn Felten @ 2:203/208. No rights reserved what so ever... :) }

INTERFACE
uses dos;

function GetTimeZone: shortint;
function IsLeapYear(Source: word): boolean;
function Norm2Unix(var DT: datetime): longint;
procedure Unix2Norm(Date: longint; var DT: datetime);
function D1970(var DT: datetime): longint;

IMPLEMENTATION

const
DaysPerMonth : array[1..12] of shortint
= (31,28,31,30,31,30,31,31,30,31,30,31);
SecsPerMinute : longint = 60;
SecsPerHour : longint = 60 * 60;
SecsPerDay : longint = 60 * 60 * 24;
SecsPerYear : longint = 60 * 60 * 24 * 365;
SecsPerLeapYear : longint = 60 * 60 * 24 * 366;


function GetTimeZone;
var Environment : string;
I, E : integer;
begin
I := 0; {Assume UTC}
Environment := getenv('TZ'); {Grab TZ string}
if Environment<>'' then begin
delete(Environment,1,3);
val(Environment,I,E);
if E>0 then begin
delete(Environment,1,E);
for E := 1 to length(Environment) do
Environment[E] := Upcase(Environment[E]);
if pos('DT',Environment)>0 then inc(I)
end
end;
GetTimeZone := I
end;

function IsLeapYear;
begin
IsLeapYear := (Source and 3 = 0)
end;

function D1970; { Thanks to Paul Schlyter... }
begin
with DT do
D1970 := longint(367) * Year
- 7 * (Year + (Month + 9) div 12) div 4
+ 275 * Month div 9
+ Day
- 719574
end;

function Norm2Unix;
var UnixDate : longint;
begin
UnixDate := D1970(DT) * SecsPerDay; {days since 1970}
with DT do begin
inc(UnixDate,(SecsPerHour * Hour)); {add hours}
inc(UnixDate,(SecsPerMinute * Min)); {add minutes}
inc(UnixDate,Sec); {add seconds}
UnixDate := UnixDate + (GetTimeZone * SecsPerHour) {add UTC offset}
end; { with Date do }
Norm2Unix := UnixDate
end;

procedure Unix2Norm;
var SecsToLose, LocalDate: longint;

procedure Split(var A: word; B: longint);
begin
A := LocalDate div B;
LocalDate := LocalDate mod B
end;

begin
with DT do begin
Year := 1970;
Month := 1;
LocalDate := Date - (GetTimeZone * SecsPerHour); {Local time date}

{ sweep out the years }
SecsToLose := SecsPerYear;
while LocalDate >= SecsToLose do begin
inc(Year,1);
dec(LocalDate,SecsToLose);
if IsLeapYear(Year)
then SecsToLose := SecsPerLeapYear
else SecsToLose := SecsPerYear
end;

{ and now the months }
Split(Day,SecsPerDay);
if IsLeapYear(Year)
then DaysPerMonth[02] := 29
else DaysPerMonth[02] := 28; {Check for Feb. 29th}
while Day >= DaysPerMonth[Month] do begin
dec(Day,DaysPerMonth[Month]);
inc(Month,1)
end;

{ the rest is a piece of cake }
inc(Day);
Split(Hour,SecsPerHour);
Split(Min,SecsPerMinute);
Sec := LocalDate
end { with DT do }
end; { procedure UnixToNorm }

end. { unit UnixTime }

---
* Origin: -=P=I=X=- / Psion Info Xchange (+46-31-960447) (2:203/208)

hummm... hey, i've got SWAG installed on my machine,
IIRC... the last one released, anyway...

What version? I have.. umm.. reader v3.13, and the most
recent files are 1997-10-07.

yup, that's the latest/last version...

)\/(ark


* Origin: (1:3634/12)

ahh, yes, v1.06 made several fixes and implemented filebuffering for

Hmm... it looks like v1.06 has the:

BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
to
BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

fix,

ok... i can see the change but am not fully aware of it being done... i had a list of fixes i thought... gotta go looking some more...

[time passes]

that looks like the

v1.04 01/09/94

[trim]

- Fixed JAM writeidx to only write the amount that
had been read

fix...

but what about the:

If JM^.TxtSubChars <= TxtSubBufSize Then
to
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

one?

where? in here??

Procedure JamMsgObj.AddTxtSub(St: String);
Var
i: Word;

Begin
For i := 1 to Length(St) Do
Begin
If JM^.TxtSubChars <= TxtSubBufSize Then
Begin
JM^.TxtSubBuf[JM^.TxtSubChars] := St[i];
Inc(JM^.TxtSubChars);
End;
End;
If JM^.TxtSubChars <= TxtSubBufSize Then
Begin
JM^.TxtSubBuf[JM^.TxtSubChars] := #13;
Inc(JM^.TxtSubChars);
End;
End;

if so, which one? i'm not aware of needing that change... all my stuff posted with my PostIt util uses this code all the time and i've not seen any problems with it... then again, my stuff only posts text files to message bases... i've not gone so far as to try to write a tosser or OLR with it...

Did that turn out not to be needed?

i really don't know... what were the problems without it? i don't see anything in CHANGES.MKS that would indicate that there was a fix in that area, either...
what was that fix supposed to do??

)\/(ark


* Origin: (1:3634/12)

[ 10 Jul 04 13:23, mark lewis wrote to Scott Little ]

If JM^.TxtSubChars <= TxtSubBufSize Then
to
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

if so, which one? i'm not aware of needing that change... all my stuff

Stick "mkmsg bugs" into Google and hit "I'm Feeling Lucky":

--\/--
Contributor: FRANK VAN DER HAM

{
For all who work with the MkMsg toolbox and it's JAM unit, I share my experience with the deleting of messages.

Despite a bugfix on this very subject from 1.02 to 1.03, I still cannot
delete messages properly. I found out that the basis of the problem is the handling of the IDX file. First of all, the number of bytes written to the
IDX file was invalid and, secondly, a real bug was in the handling of the
"sub text" where an array is declared as "array [1..xx]" and used as "array [0..xx], causing a field in a record to be overriden to an invalid value.

These are the changes I made to my MKMSGJAM.PAS file.

Line 150:
Change
TxtSubBuf: Array[1..TxtSubBufSize] of Char; {temp storage ... }
Into
TxtSubBuf: Array[0..TxtSubBufSize-1] of Char; {temp storage ... }

Line 831:
Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

Line 838:
Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

Line 1490:
Change
BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
Into
BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

Keep on jammin' !
--/\--


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

[ 10 Jul 04 18:12, Björn Felten wrote to mark lewis ]

function IsLeapYear;
begin
IsLeapYear := (Source and 3 = 0)
end;

Urm.. just to be a pedant,

((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

:)


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

If JM^.TxtSubChars <= TxtSubBufSize Then
to
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

if so, which one? i'm not aware of needing that change... all my stuff

Stick "mkmsg bugs" into Google and hit "I'm Feeling Lucky":

hummm...

--\/--
Contributor: FRANK VAN DER HAM

i recognize that name from the fixes file... he found several, it seems... my name is in there once or twice, too... but i sent more fixes than acknowledged...

Line 150:
Change
TxtSubBuf: Array[1..TxtSubBufSize] of Char; {temp storage
... }
Into
TxtSubBuf: Array[0..TxtSubBufSize-1] of Char; {temp storage
... }

yes, that's in my copy...

Line 831:
Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

Line 838:
Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

neither of these is in my copy of 1.06...

Line 1490:
Change
BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
Into
BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

this is on line 1439 in my copy in the

Function JamMsgObj.WriteIdx: Word;

routine... looks like readidx and writeidx were moved out into seperate routines... i know that i added at least 9 lines at the top of the file as well
as several others where i commented out a line i was changing to keep the original just in case... evidently there was a bit of movement in other areas, too... wonder what version of mkmsg that page covers??

)\/(ark


* Origin: (1:3634/12)

Line 150:

this line is +2 from 150 in the unmodified v1.06 i have...
this line is +2 from 150 in the unmodified mkbbs code i have...

Line 831:

this line is -6 from 831 in the unmodified v1.06 i have...
this line is -5 from 831 in the unmodified mkbbs code i have...
neither has the -1 on the line...

Line 838:

this line is -7 from 838 in the unmodified v1.06 i have...
this line is -6 from 838 in the unmodified mkbbs code i have...
neither has the -1 on the line...

Line 1490:

this line is -65 from 1490 in the unmodified v1.06 i have...
this line is -62 from 1490 in the unmodified mkbbs code i have...


the MKMSGJAM.PAS in the mksm106 archive is dated dec 10 1994 01:06

the MKMSGJAM.PAS in the mkbbs archive is dated mar 21 1995 17:06

the mkbbs archive is called MKSRC001.ZIP dated aug 9 1995

it wasn't long after this that mark pretty much disappeared from sight...

)\/(ark


* Origin: (1:3634/12)

Despite a bugfix on this very subject from 1.02 to 1.03,

Those all seems to be fixed in the 1.05 version I have. I also have 1.06, but that one is always 'unable to open messagebase' for some reason that I haven't bothered to look for.

Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

Hmmm... Why not just delete the '=' sign? :)

There are some bugs in MkMsgCvt, that I've tracked down to the JAM part, since all works fine to and fro any combination of msg-bases, just not from MSG
to JAM. After a couple of hundred msgs (different on different "folders", but always on the same msg (usually, but not always, some big msg) in the same folder, the program crashes with a run-time error 216. Going MSG->Squish->JAM works. Really strange bug. Plus of course the S-B lines are added to the msg-text -- might be a correlated bug, but since it seems to be impossible to do any serious debugging on the package, it's hard to find the bug.

---
* Origin: news://felten.dyndns.org (2:203/2)

((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

Why? Will you be around Mars 1st 2100 and listen to the complaints? :)

And unixtime will be broken long before that anyway. 2038 for those that use
unsigned longint.

---
* Origin: news://felten.dyndns.org (2:203/2)

Despite a bugfix on this very subject from 1.02 to 1.03,

Those all seems to be fixed in the 1.05 version I have. I
also have 1.06, but that one is always 'unable to open
messagebase' for some reason that I haven't bothered to look
for.

its not anything in the 1.06 code as i use it here as designed... in fact, my stuff even goes so far as to create the necessary directories and files if they
don't exist ;)

Change
If JM^.TxtSubChars <= TxtSubBufSize Then
Into
If JM^.TxtSubChars <= TxtSubBufSize-1 Then

Hmmm... Why not just delete the '=' sign? :)

haha... that would have worked, too... but its not necessary that i've been able to tell...

There are some bugs in MkMsgCvt, that I've tracked down to
the JAM part, since all works fine to and fro any combination

msgcvt was just something tossed together to show using the message libraries as a blackbox... the problem isn't in mkmsgcvt but in the library or the compiler...

of msg-bases, just not from MSG to JAM. After a couple of
hundred msgs (different on different "folders", but always on
the same msg (usually, but not always, some big msg) in the
same folder, the program crashes with a run-time error 216.

216? that's not even listed in my TP6 reference stuff... are you sure about that? i just looked...

[time passes]

ahh... just looked in BP7 and see that that's a GPF... hummm... sounds like an errant pointer trying to access memory outside its allocation...

Going MSG->Squish->JAM works. Really strange bug. Plus of
course the S-B lines are added to the msg-text -- might be a
correlated bug, but since it seems to be impossible to do any
serious debugging on the package, it's hard to find the bug.

paths should done be using the dokludgeln when writting them to the base... seenbys should be done using dokludgeln, too, but they are not...

ie: hacked together, untested... possibly add to dokludgeln section...

Else If Copy(Str,1,7) = 'SEEN-BY' Then
Begin
TmpStr := StripLead(Copy(Str,8,255),':');
TmpStr := StripBoth(TmpStr,' ');
AddSubField(2001, TmpStr);
End

and i see what appears to be an error in MsgStartUp (for reading JAM bases) in that seenbys are prefixed with a ^A when they shouldn't be... at least, not if they are going into PKT files... in any case, in JAM bases, seenbys are code 2001 as shown in the above modified snippet from dokludgeln... doing the seenbys properly needs to be built in the same manner as doing the path line except without the leading ^A character...


hummm... guess i'll have to dig in and write some JAM reading code...

what's wierd is that JAM is apparently the only message base format that takes special care with control lines... to all the others, its simply a string of text...

its been a long while since i've dug into this stuff ;)

)\/(ark


* Origin: (1:3634/12)

((source and 3 = 0) and not (source mod 100 = 0)) or (source mod 400 = 0)

Why? Will you be around Mars 1st 2100 and listen to the
complaints? :)

why leave buggy legacy code laying around for others to use?

And unixtime will be broken long before that anyway. 2038
for those that use unsigned longint.

that depends on how big a longint is in the compilers being used at the time ;)

)\/(ark


* Origin: (1:3634/12)

*** Quoting Dan Egli from a message to mark lewis ***

if Maarten is even still around anymore. Haven't heard from him in
the echo for over a year I think.

He is around, but he is working full-time and doesn't develop EleBBS much anymore. Maarten is hard to get hold of unless you email him.

--Sean

--- Telegard/2 v3.09.g2-sp4/mL
* Origin: Outpost BBS - outpostbbs.us (1:11/200)

*** Quoting Dan Egli from a message to mark lewis ***

and RemoteAccess allwere abandoned by their author. Yes Telegard and
RA were picked up again, but they also seem to have been dropped
again. I'm determined to not let that happen to EleBBS untill no one

Tim Strike is still around, however, he has a real life and things to attend to, so TG got put to the side. We're hoping that he either releases the source
code or fixes a few things in TG before he disappears again. ;)

On a side node, Roland de Graff, the author of VBBS/VADV, has suddenly resurfaced. There's discussion going on about VADV's further development, but I don't know anything else about that.

Anyhow, I'll quit being OT now. ;)

--Sean

--- Telegard/2 v3.09.g2-sp4/mL
* Origin: Outpost BBS - outpostbbs.us (1:11/200)

function IsLeapYear;
begin
IsLeapYear := (Source and 3 = 0)
end;

This cannot be exactly correct, can it?

Cheers,
Roelof Beverdam

--- Dutchie V3.10.11
* Origin: The Beaver's Nest (2:280/5218)

function IsLeapYear;
begin
IsLeapYear := (Source and 3 = 0)
end;

This cannot be exactly correct, can it?

For the entire, expected lifespan of any Pascal program, with a huge margin and then some, yes I think it is. :)

---
* Origin: news://felten.dyndns.org (2:203/2)

Hi Scott,

Line 1490: Change BlockWrite(JM^.IdxFile, JamIdx^, JamIdxBufSize);
Into BlockWrite(JM^.IdxFile, JamIdx^, JM^.IdxRead);

The EleBBS /mkmsg/mkmsgjam.pas has no record of blockwrite :(

Any ideas?

Lata,
zomorf badnewsbbs@westnet.com.au ICQ: 12489905
http ftp telnet://badnews.bbs.us & badnewsbbs.darktech.org


---
* Origin: Come & Visit for a Kick@ss EleBBS & EleWEB BBS (3:633/690)

[ 17 Jul 04 18:25, Wayne Steele wrote to Scott Little ]

Line 1490: Change BlockWrite(JM^.IdxFile, JamIdx^,
JamIdxBufSize); Into BlockWrite(JM^.IdxFile, JamIdx^,
JM^.IdxRead);

The EleBBS /mkmsg/mkmsgjam.pas has no record of blockwrite :(

Looks like Maarten replaced it with his FileOBJ unit.


-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]

--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)

Hey mark,

09 Jul 04 17:00, you wrote to me:

Netiher do I. Which is why I adopted EleBBS sorta. I've had
three BBS software's I use abandoned, I don't want to make it
#4. Teleard, TAG, and RemoteAccess all were abandoned by their
author. Yes Telegard and RA were picked up again, but they
also seem to have been dropped again. I'm determined to not
let that happen to EleBBS untill no one is using it, or till I
just cann't do it anymore.

understand that... what compiler are you using? what OS' are you
compiling for? where is the project based?

Using FreePascal because with it I can compile natively for Win32, DOS16, OS/2 and Linux. I intend to support one of each. I personally don't see the point of
the DOS/386 port because if you're running a 386 O/S, then you can use the native port for that O/S (i.e. if you're running DOS/386 under Windows, just use the Win32 model).

-- Dan

--- FMail/Win32 1.60
* Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)

Hey Björn,

10 Jul 04 18:12, you wrote to mark lewis:

i found the unix2norm routine... its not anything like
the stuff i use...

Here's one that I (and several others) have used for more than ten years now. Take it or leave it. :)

- = * = -

unit UnixUtil;

I will (and did!) take it! Thanks!

-- Dan

--- FMail/Win32 1.60
* Origin: * Coming Soon! Telnet://thedungeon.dnsalias.net! (1:311/6)

[[ major apologies... this should have left here back in July but was inadvertently left locked in my base... better late than never, eh? ]]

in JAM bases, seenbys are code 2001

reference the JAM specs for this...

CONST
JAMSFLD_OADDRESS = 0;
JAMSFLD_DADDRESS = 1;
JAMSFLD_SENDERNAME = 2;
JAMSFLD_RECVRNAME = 3;
JAMSFLD_MSGID = 4;
JAMSFLD_REPLYID = 5;
JAMSFLD_SUBJECT = 6;
JAMSFLD_PID = 7;
JAMSFLD_TRACE = 8;
JAMSFLD_ENCLFILE = 9;
JAMSFLD_ENCLFWALIAS = 10;
JAMSFLD_ENCLFREQ = 11;
JAMSFLD_ENCLFILEWC = 12;
JAMSFLD_ENCLINDFILE = 13;
JAMSFLD_EMBINDAT = 1000;
JAMSFLD_FTSKLUDGE = 2000;
JAMSFLD_SEENBY2D = 2001;
JAMSFLD_PATH2D = 2002;
JAMSFLD_FLAGS = 2003;
JAMSFLD_TZUTCINFO = 2004;
JAMSFLD_UNKNOWN = $ffff;

an additional note that i see that the mkjam stuff also doesn't do anything with the TZUTC stuff, either... that's a 2004 in the above... i see some mods coming to the stuff that i do here, ;)

)\/(ark


* Origin: (1:3634/12)

an additional note that i see that the mkjam stuff also
doesn't do anything with the TZUTC stuff, either... that's a
2004 in the above... i see some mods coming to the stuff that
i do here, ;)

following up to that message that was locked and just released... i made those mods back then and everything seems to work properly... the only problems i've seen are that some programs don't recognise those codes or don't display the data in them... nevertheless, i've implemented them in my version of the mkmsgsrc jam code and am have been using them since July of '04 with no ill effects...

)\/(ark


* Origin: (1:3634/12)