Just a sample of the Echomail archive
WILDCAT_:
[ << oldest | < older | list | newer > | newest >> ]
|  Message 51 of 1,697  |
|  mark lewis to Robert Wolfe  |
|  Bad Date  |
|  16 Mar 16 10:12:50  |
 15 Mar 16 21:04, you wrote to All: RW> Hi there. It looks like I am getting a "Bad Date" error when tossing RW> packets created by PX/DOS 1.4 in PX/WINS 3.0pr5. Is there any way that I RW> could fix this (such as maybe a third party utility or something) so that RW> mail from my Wildcat! 4.2 system tosses properly without me having to RW> switch to ViaMail!? is that px/dos thing y2k compliant? how is it mucking up the dates? is it the usual three character year because they forgot to do mod arithmetic on it to keep it confined to 00-99?? in any case, the only tool that i'm aware of is PKTDATE... you should be able to locate it as Y2KTOOLS5.ZIP in the COORDUTL file echo... here's how i use it in my tossing script for both secure and insecure inbound mail... the key steps are that we 1. use SPAZ to unpack all possible mail bundles so we are left only with PKTs 2. we set our pktdate command line into our %pdate% variable so we can log it with each PKT 3. finally we use a for loop to process each PKT with pktdate 4. we check again for mail bundles that may have arrived during our processing and process them right now, too the below is a snippet from our 32K in.bat processing script written in 4DOS... it should be easy enough to read and understand... previous to 7 jul 2014, we corrected the dates on inbound mail... the problem with that is that it allowed regurges to be propogated further but with corrected dates... this processing snippet is for all inbound mail but you can do the exact same thing for your outbound mail to ensure that your system is sending proper dates in the messages... how you do this with your software is unknown but it is much easier to do with raw PKTs than to have to break apart bundles and then to try to repack them... some tossers offer a pre-packing option line where you can call tools like this... in those cases, they are generally working with .qqq files instead of .pkt files... .qqq files are simply .pkts waiting to be renamed to .pkt and maybe bundled into a mo1 or tu4 or similer mail bundle file... ===== snip ===== if '%mail%' == 'yes' goto save1 :asave1 if '%mail%' == 'yes' goto save2 :asave2 goto jump1 :save1 os2title in.bat save1 gosub do_mydate echo %MYDATE% [652] saving "normal" mail bundle(s) | %SLOGS% pushd %fd%\files if exist *.mo? copy /q *.mo? pkt-save if exist *.tu? copy /q *.tu? pkt-save if exist *.we? copy /q *.we? pkt-save if exist *.th? copy /q *.th? pkt-save if exist *.fr? copy /q *.fr? pkt-save if exist *.sa? copy /q *.sa? pkt-save if exist *.su? copy /q *.su? pkt-save if exist *.pkt copy /q *.pkt pkt-save os2title in.bat spaz1 if exist %fdsema%\fdinsess.* ( popd ^ echo :save1 waiting 10... ^ delay 10 ^ goto save1 ) gosub do_mydate echo %MYDATE% [665] processing "normal" mail bundle(s) | %SLOGS% gosub do_mydate echo %MYDATE% [667] spaz -F %fd%\files | %SLOGS% spaz -F %fd%\files os2title in.bat pktd1 rem set pdate=pktdate -k -c -l2 -S -L%fd%\pktd.log rem *** rem *** -c means to correct the pkt... stopped correcting on 7 Jul 2014 rem *** -k means to keep the original pkt if we correct any dates in it rem *** -p means "past" and "9y" means "9+ years" rem *** -f means "future" and "1m" means "1+ month" rem *** -l is the logging level rem *** -S changes seadog dates to standard ftsc dates rem *** -L is the log file name set pdate=pktdate -k -l2 -S -L%fd%\pktd.log gosub do_mydate echo %MYDATE% [679] %pdate% | %SLOGS% for %%i in ( *.pkt) do %pdate% %%i popd if exist %fd%\files\*.mo? goto save1 if exist %fd%\files\*.tu? goto save1 if exist %fd%\files\*.we? goto save1 if exist %fd%\files\*.th? goto save1 if exist %fd%\files\*.fr? goto save1 if exist %fd%\files\*.sa? goto save1 if exist %fd%\files\*.su? goto save1 goto asave1 :save2 REM SNIPPED OUT IDENTICLE SECTION FOR SECURE PROCESSING goto asave2 :jump1 ===== snip ===== )\/(ark Always Mount a Scratch Monkey ... A Smith & Wesson beats four aces. --- * Origin: (1:3634/12.73) |
[ << oldest | < older | list | newer > | newest >> ]
(c) 1994, bbs@darkrealms.ca