Subj : JAM versus Squish? To : Sean Dennis From : mark lewis Date : Sun Nov 15 2015 09:12 am 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) .