Quoting Marceline Jones to Rob Swindell <=-

No one has ever asked for that. What would the rep files be named -
.re0, .re1, etc.? Assuming you'd want them imported in order, would
.rep come first or last? --
digital man

Well, I want to match QWK filenames with their corresponding REPs (eg. "VERT0001.QWK" and "VERT0001.REP"). That way, I know which replies
came from which packet.

Your intention is save your replies? Don't need this. Only select
this option ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
QWK Settings: (Synchronet) ³
³
[A] Ctrl-A Color Codes : Strip ³
[T] Archive Type : ZIP ³
[E] Include E-mail Messages : Un-read Only ³
[I] Include File Attachments : Yes ³
[D] Delete E-mail Automatically : Yes ³
[F] Include New Files List : Yes ³
[N] Include Index Files : Yes ³
[C] Include Control Files : Yes ³
[V] Include VOTING.DAT File : No ³
[H] Include HEADERS.DAT File : Yes ³
[Y] Include Messages from You : Yes <ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
[Z] Include Time Zone (@TZ) : No
[P] Include Message Path (@VIA) : No
[M] Include Message/Reply IDs : No
[X] Extended (QWKE) Packet Format: Yes


Wildcat! has the same ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
[10] Download mail from you : YES <ÄÄÄÄÙ


... "Don't underestimate the POWER of the Blue Wave" - Darth Vader
___ Blue Wave/DOS v2.30
--- SBBSecho 3.06-Win32
* Origin: Ninho do Abutre 2 - Rio de Janeiro - Brasil * (4:801/194)

Well, I want to match QWK filenames with their corresponding REPs (eg. "VERT0001.QWK" and "VERT0001.REP"). That way, I know which replies
came from which packet.

Your intention is save your replies? Don't need this. Only
select this option ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³
QWK Settings: (Synchronet) ³
³
[A] Ctrl-A Color Codes : Strip ³
[T] Archive Type : ZIP ³
[E] Include E-mail Messages : Un-read Only ³
[I] Include File Attachments : Yes ³
[D] Delete E-mail Automatically : Yes ³
[F] Include New Files List : Yes ³
[N] Include Index Files : Yes ³
[C] Include Control Files : Yes ³
[V] Include VOTING.DAT File : No ³
[H] Include HEADERS.DAT File : Yes ³
[Y] Include Messages from You : Yes <ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
[Z] Include Time Zone (@TZ) : No
[P] Include Message Path (@VIA) : No
[M] Include Message/Reply IDs : No
[X] Extended (QWKE) Packet Format: Yes

It is not about the replies. It is about knowing which REP packet belongs to which QWK packet on disk so that I can trace a message thread.

Only one QWK packet can be open for reading at any time, therefore I can only see a part of a thread at any time (depending on which QWK packet I have open). By keeping the REP packets in sync whith their corresponding QWK packets, locating and viewing the original messages is easier.

For example I archive all my QWK downloads (eg. VERT0001.QWK, VERT002.QWK etc). I also archive all my REP packets (eg. VERT0001.REP, VERT0002.REP etc). So if I am viewing "VERT0002.REP", I know the originating messages must be in "VERT0002.QWK" and vice versa.

When uploading REP packets to Synchronet, I have to do it one file at a time. I see no reason why it cannot be done by batch upload.

___ Blue Wave/386 v2.30
--- SBBSecho 3.13-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Quoting Marceline Jones to Mauro Veiga <=-

For example I archive all my QWK downloads (eg. VERT0001.QWK,
VERT002.QWK etc). I also archive all my REP packets (eg. VERT0001.REP, VERT0002.REP etc). So if I am viewing "VERT0002.REP", I know the originating messages must be in "VERT0002.QWK" and vice versa.

When uploading REP packets to Synchronet, I have to do it one file at
a time. I see no reason why it cannot be done by batch upload.

Understood. I think you want a very particular way of working with
QWK packages. It seems to me something that would need to be
developed together with the door and the offline mail reader.

It is not what you want but here I work with the packages as
follows: every 30th of the month I retract the message pointers
until the 30th of the previous month and download a package of
messages. I delete the packages read during the month and keep
monthly backups of the messages and my replies.
It works well for me.

(sorry by google translation)



,_o_,
=======
_____----(_o_)----_____
/ `-------------' \ Mauro R. Veiga abutrebbs@yahoo.com.br
[' `]

MeSSaGe SiTTeR 1.00 - Full Version
Live Long and Prosper

... Mister Worf, show these children the airlock. - Picard
___ Blue Wave/DOS v2.30
--- SBBSecho 3.06-Win32
* Origin: Ninho do Abutre 2 - Rio de Janeiro - Brasil * (4:801/194)

Understood. I think you want a very particular way of working
with QWK packages. It seems to me something that would need to be developed together with the door and the offline mail reader.

A QWK and REP merging tool would be the answer.

That way, new packets can just be appended to the same file.

It is not what you want but here I work with the packages as
follows: every 30th of the month I retract the message pointers
until the 30th of the previous month and download a package of
messages. I delete the packages read during the month and keep
monthly backups of the messages and my replies.
It works well for me.

What you are doing would still require keeping separate REP packets. What if I decided to reply to a message, then upload the REP packet ? -- I would end up with 30 REP packets each month.

___ Blue Wave/386 v2.30
--- SBBSecho 3.13-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Quoting Marceline Jones to Mauro Veiga <=-

It is not what you want but here I work with the packages as
follows: every 30th of the month I retract the message pointers
until the 30th of the previous month and download a package of
messages. I delete the packages read during the month and keep
monthly backups of the messages and my replies.
It works well for me.

What you are doing would still require keeping separate REP packets.
What if I decided to reply to a message, then upload the REP packet ?
-- I would end up with 30 REP packets each month.

I still don't understand the reason for saving REP packets. All
messages and my replies are in the QWK packets. If i need to reply
a old messages simply i make the replies and upload the REP. Don't
need to use the original REP from the old packet.

Seems like you want a very personalized (and complicated) way to
organize a packets collection. A personal arrange.

On my historical packets from 90's i only used merge programs to
have few packets to save and simplify data searches.


[]'s
³
ÄÄÄÄÄÄÄÄÄÄÄ Mauro R. Veiga Ä abutre.no-ip.org:2323 ÄÄÄÄÄÄÄÄ * ÄÄÄÄÄÄ
³

MeSSaGe SiTTeR 1.00 - Full Version
Live Long and Prosper

... BlueWave - More than a program, it's a lifestyle.
___ Blue Wave/DOS v2.30
--- SBBSecho 3.06-Win32
* Origin: Ninho do Abutre 2 - Rio de Janeiro - Brasil * (4:801/194)

I still don't understand the reason for saving REP packets. All
messages and my replies are in the QWK packets. If i need to
reply a old messages simply i make the replies and upload the REP.
Don't need to use the original REP from the old packet.

REP packets should be backed up because they are the original source reply data. If messages need to be re-uploaded for whatever reason, then they can be retrieved from the REP. For example something can go wrong with an upload, or only a partial import occurred. It might take you a week before realising messages got lost. Also if you lose the REP packet then you cannot perform a reconciliation between what was sent and received.

Seems like you want a very personalized (and complicated) way to
organize a packets collection. A personal arrange.

REP packets should be retained because a lot of work goes into replying to messages. I would prefer to correlate REP and QWK packets.

On my historical packets from 90's i only used merge programs to
have few packets to save and simplify data searches.

Can you provide details of the merge programs you used ?

___ Blue Wave/386 v2.30
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Quoting Marceline Jones to Mauro Veiga <=-

REP packets should be backed up because they are the original source
reply data. If messages need to be re-uploaded for whatever reason,
then they can be retrieved from the REP. For example something can go wrong with an upload, or only a partial import occurred. It might take you a week before realising messages got lost. Also if you lose the
REP packet then you cannot perform a reconciliation between what was
sent and received.

Understood. I usually wait to see if all my replies have been
echoed before deleting REP. It really boring to rewrite the replies.

Seems like you want a very personalized (and complicated) way to
organize a packets collection. A personal arrange.

REP packets should be retained because a lot of work goes into
replying to messages. I would prefer to correlate REP and QWK packets.

I take your point.

On my historical packets from 90's i only used merge programs to
have few packets to save and simplify data searches.

Can you provide details of the merge programs you used ?

Have many old programs to do it.

ADDQWK10.ZIP
ADDREP10.ZIP (merge REP packets)
CATQWK22.ZIP -> worked very fine for me
QWKM105.ZIP
QWKX151.ZIP
And more...

Some programs has bugs with specific packets. Is good to test
several.

But merge of Bluewave packets are more complicated. Has few
programs with many bugs and limitations. I know:

BWS_13.ZIP
BWCOMB12a.ZIP
BWM33-16.ZIP (windows 16bits)
BWM33-32.ZIP (windows 32bits)

Usually I was able to merge packets generated by a Bluewave door.
But when they were generated by OLMS, there were several errors and
crashes when using merge softwares. Today, I rarely use these
programs because it is easy to use the QWK door pointer backward
feature. I used it a lot with old packages of extinct systems.

And Multimail has an excellent multi packages search engine that
partially eliminates the need for merge to searches.


[]s ³
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ * ÄÄÄÄÄÄÄÄÄÄÄÄÄ
³ Mauro R. Veiga - abutre.no-ip.org:2323 ³
ÄÄÄÄijÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ


MeSSaGe SiTTeR 1.00 - Full Version
Live Long and Prosper

... DOS=HIGH? I knew it was on something...
___ Blue Wave/DOS v2.30
--- SBBSecho 3.06-Win32
* Origin: Ninho do Abutre 2 - Rio de Janeiro - Brasil * (4:801/194)