TIP: Click on subject to list as thread! ANSI
echo: bbs_carnival
to: Sean Dennis
from: mark lewis
date: 2015-11-15 09:12:50
subject: JAM versus Squish?

14 Nov 15 21:02, you wrote to Alan Ianson:

 AI>> I asked this question in the husky (a tosser for squish and jam) area
 AI>> recently to see if someone had an answewr for me. I got one reply
 AI>> that said that the squish base can only link 12 (i think it was 12)
 AI>> reply links to the original message). It's a limit of the quish
 AI>> message base format that I never new of and has never been a problem.
 AI>> He told me he had one base with over 100,000 msgs!

 SD> I've had over 20 links to the same message when I was running Max/2.
 SD> I think that may have been a limitation of DOS or something...

looking at the squish message base specs, the number of linked replies is
evidently a limitation of the software design... it appears to be easy
enough to change but perhaps all software being used on one system would
need to be changed at the same time? since it is an array field, everything
must be able to count the same range  ;)


from the Squish Developer's Kit v2... starting at line 423...


     replies    UMSGID[9]  178  If any replies for this message are
                                present,   this  array   lists  the
                                UMSGIDs   of   up  to   nine  reply
                                messages.



and this from the maximus msgapi.h...


[...]
/* Number of reply fields in XMSG.replies */

#define MAX_REPLY 9

[...]
/* The eXtended message structure.  Translation between this structure, and *
 * the structure used by the individual message base formats, is done       *
 * on-the-fly by the API routines.                                          */

struct _xmsg
{
  dword attr;

  byte from[XMSG_FROM_SIZE];
  byte to[XMSG_TO_SIZE];
  byte subj[XMSG_SUBJ_SIZE];

  NETADDR orig;        /* Origination and destination addresses             */
  NETADDR dest;

  union _stampu date_written;   /* When user wrote the msg (UTC)            */
  union _stampu date_arrived;   /* When msg arrived on-line (UTC)           */
  sword utc_ofs;                /* Offset from UTC of message writer, in    *
                                 * minutes.                                 */

  UMSGID replyto;               /* This is a reply to message #x            */
> UMSGID replies[MAX_REPLY];    /* Replies to this message
 */
  dword umsgid;                 /* UMSGID of this message, if (attr&MSGUID) */
                                /* This field is only stored on disk -- it  *
                                 * is not read into memory.                 */

  byte __ftsc_date[20];/* Obsolete date information.  If it weren't for the *
                        * fact that FTSC standards say that one cannot      *
                        * modify an in-transit message, I'd be VERY         *
                        * tempted to axe this field entirely, and recreate  *
                        * an FTSC-compatible date field using               *
                        * the information in 'date_written' upon            *
                        * export.  Nobody should use this field, except     *
                        * possibly for tossers and scanners.  All others    *
                        * should use one of the two binary datestamps,      *
                        * above.                                            */
};



and this from mark may's MKSRCMSG PASCAL library...

[...]
Const
  SqHdrId = $AFAE4453;
  SqLinkNext = 0;
  SqLinkPrev = 1;
  SqNullFrame = 0;
  SqFrameMsg = 0;
  SqFrameFree = 1;
  SqFrameRLE = 2;
  SqFrameLZW = 3;
  SqFromSize = 36;
  SqToSize = 36;
  SqSubjSize = 72;
  SqMaxReply = 10;

[...]

Type SqMsgHdrType = Record
  Attr: LongInt; {Msg attribute}
  MsgFrom: String[SqFromSize - 1]; {Nul Term from name}
  MsgTo: String[SqToSize - 1]; {Nul term to name}
  Subj: String[SqSubjSize - 1]; {Nul term subject}
  Orig: AddrType; {Origin address}
  Dest: AddrType; {Destination address}
  DateWritten: LongInt; {Date/Time msg written}
  DateArrived: LongInt; {Date/Time msg arrived here}
  UtcOffset: Word; {Minutes offset from UTC}
  ReplyTo: LongInt; {Original msg}
> Replies: Array[1..SqMaxReply] of LongInt; {Replies}
  AzDate: String[19]; {AsciiZ "Fido" style date}
  End;



)\/(ark

... BBS busy.  (C)all back later  (T)hrow tantrum?
---
* Origin: (1:3634/12.73)
SEEN-BY: 203/0 633/267 280 640/384 1384 690/682 712/620 848 770/1
@PATH: 3634/12 123/500 154/10 203/0 640/384 712/848 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.