home *** CD-ROM | disk | FTP | other *** search
/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / RAMSV131.ZIP / WHATSNEW.TXT < prev   
Encoding:
Text File  |  1996-06-08  |  16.3 KB  |  348 lines
  1. *****************************************************************
  2.    What's new in RemoteAccess Automated Message System v1.31
  3. *****************************************************************
  4.  
  5. If you are using v1.2x please run the UPDATE.EXE file BEFORE attempting
  6. to use Rams or RamsCfg. Failure to do so WILL result in runtime errors!
  7. If you are using an earlier version of Rams than v1.2x you will have to
  8. manually reconfigure it by first DELETING your RAMS.CFG and RAMS.DAT
  9. files, then running the NEW RamsCfg and resetting everything to suit
  10. your system. Please refer to the documents for more info.
  11.  
  12. PLEASE NOTE:
  13. You DO NOT have to run the Update.Exe program if you are already using
  14. v1.30 of Rams!
  15.  
  16. Fixed a bug in RamsCfg that would not allow a user to enter high ascii
  17. characters in subject lines etc. Not much good for those countries such
  18. as Sweden, France, Russia etc etc that use them as part of their normal
  19. character set! :-( Reported by Lars Wigrell.
  20.  
  21. Fixed a bug that would cause Rams to abort with a runtime error 102 if
  22. there were no users in the RA logfile. Rams will now correctly continue
  23. and do any daily events etc as necessary. Reported by Lars Wigrell.
  24.  
  25. Changed some of the logging routines to make it a little clearer why
  26. Rams has not posted a message in the event of a user not meeting a
  27. condition that was assigned to the message.
  28.  
  29.  
  30.  
  31.  
  32. *****************************************************************
  33.    What's new in RemoteAccess Automated Message System v1.30
  34. *****************************************************************
  35.  
  36. If you are using v1.2x please run the UPDATE.EXE file BEFORE attempting
  37. to use Rams or RamsCfg. Failure to do so WILL result in runtime errors!
  38. If you are using an earlier version of Rams than v1.2x you will have to
  39. manually reconfigure it by first DELETING your RAMS.CFG and RAMS.DAT
  40. files, then running the NEW RamsCfg and resetting everything to suit
  41. your system. Please refer to the documents for more info.
  42.  
  43. Fixed a bug with the Co-Sysop messages. Rams wasn't translating the
  44. %SYSOPNAME% and %SYSOPFIRST% metastrings correctly, it was still
  45. inserting the 'Sysops' name instead of the 'Co-Sysops' name when
  46. sending 'Co-Sysop' reports etc.
  47.  
  48. Started to optimise the midnight procedures so they run quicker... In
  49. general Rams should now run it's midnight procedures in HALF the time
  50. taken by v1.2x
  51.  
  52. Added a new metastring, %USERLAST% which will be translated into the
  53. users LAST name, ie his/her surname.
  54.  
  55. Added new metastring %LINE#% which can be used in any message, and will
  56. be translated into the Line/Node that the user was on. Obviously this
  57. will ALWAYS be 1 for a single line system.
  58.  
  59. Fixed a bug in the 'Watchdog' messages. If the user left the Sysop a
  60. message before RA terminated the call after the number of password
  61. attempts was exceeded, Rams would incorrectly read the previous callers
  62. log entries as RA doesn't put a log entry saying that the call had
  63. terminated.
  64.  
  65. Fixed the bug in RamsCfg that would cause it to overwrite the reports
  66. it created.
  67.  
  68. Fixed a bug that would cause Rams to continually post 'Regular' msgs
  69. EVERY day on some systems, even though the msg was not setup to be
  70. posted every day. It will now correctly post them every X days.
  71.  
  72. Added File Attach support for 'Local' and 'Netmail' messages. Rams will
  73. NOT allow a file attach to an 'Echo' message. For Netmail messages,
  74. Rams will simply attach the file you specify to the message it generates.
  75. But for Local messages, Rams will create a UNIQUE directory off your RA
  76. 'File Attach' directory and copy the file for EVERY message it sends so
  77. BE CAREFUL if you are using the @ALL macro to post 'File Attach'
  78. messages as it WILL take a lot of time and WILL quickly fill up your
  79. hard drive as EVERY message needs a seperate copy of the file because
  80. of the way RA handles things.
  81.  
  82. Please note: Local file attaches will ONLY work properly if your copy
  83. of RA is REGISTERED, as this is a REGISTERED ONLY feature in RA. Even
  84. on an UNREG copy of RA, Rams will still generate all the file attaches,
  85. but your users will be unable to download the files as RA will not
  86. allow them to do so.
  87.  
  88. Added the ability for Rams to run external programs in it's midnight
  89. event. These can be 'Regular' (every X days), 'Monthly' (once per month),
  90. or 'Yearly' (Once per year). You should specify the FULL path AND
  91. program name to run. If the program requires Command.Com to be loaded
  92. (ie a batch file), you MUST ensure that you have set the 'COMSPEC'
  93. environment variable. Please refer to your Dos manuals for more info on
  94. 'COMSPEC'. Attempting to run a batch file without defining the COMSPEC
  95. environment variable MAY cause an error as Rams will NOT be able to
  96. call Command.Com to process the batch commands. If you specify a program
  97. WITHOUT an extension Rams will search for .Com, .Exe, and .Bat in that
  98. order. Because Rams is a DOS based program it does NOT support .Cmd
  99. files as used in OS/2 etc. If you try to run a .Cmd file you are asking
  100. for trouble! You have been warned!
  101.  
  102. The new 'External' menu in RamsCfg will allow you to configure Rams to
  103. run the programs you want. Rams will attempt to intelligently report
  104. any problems if they occur with the external programs execution ie.File
  105. not found, Not enough memory etc etc. Don't forget Rams is still active
  106. in memory, so there are limits to what it can handle.
  107.  
  108. Fixed a bug in the Config program that would cause some garbage to be
  109. written to the report files it created.
  110.  
  111. Added the ability to specify who to post user messages FROM... By
  112. default Rams will post all messages to users FROM the Sysop, but you can
  113. now alter that from the 'Co-Sysop' feature in each message type. If you
  114. want to have the user messages posted by one of your Co-Sysops you MUST
  115. tell Rams which one to use... You can specify a different Co-Sysop for
  116. EVERY message Rams can post to your users, or as explained above, Rams
  117. will default to using the Sysops name if you don't tell it otherwise.
  118.  
  119. Fixed a bug that caused Rams to post 'report' messages to the Co-Sysops
  120. even if the Report messages were disabled.
  121.  
  122. Tidied up some of the menu entries in the config program, and moved the
  123. 'Report' menu to the end of the main menu bar. Also added the 'External'
  124. programs to the reports generated by RamsCfg.
  125.  
  126. Fixed a minor bug that would cause Rams to say a message had been saved
  127. even when it had not been unable to open the message base correctly. It
  128. will now report an error in it's log instead.
  129.  
  130. Fixed a minor bug with the 'Subs' messages that would cause RAMS to only
  131. post the Sysop message (and not send the user message) in certain
  132. circumstances.
  133.  
  134. Fixed a bug that caused Rams not to execute it's midnight procedures if
  135. no users were found in RA's logfile.
  136.  
  137.  
  138.  
  139.  
  140. *****************************************************************
  141.    What's new in RemoteAccess Automated Message System v1.21
  142. *****************************************************************
  143.  
  144. Since v1.20 is only a very minor bugfix.. Please read the rest of
  145. this document to see all the changes made since version 1.0
  146.  
  147. Fixed a minor bug that would sometimes cause RamsCfg to give a
  148. runtime error when exporting a configuration report under some
  149. conditions.
  150.  
  151. *****************************************************************
  152.    What's new in RemoteAccess Automated Message System v1.20
  153. *****************************************************************
  154.  
  155. If you are upgrading from a previous version of Rams, PLEASE read
  156. the section of the docs on upgrading. If this is a first time
  157. install, please read the section of the docs on configuring and
  158. setting up Rams.
  159.  
  160. Now, what's new in this the third release of Rams?
  161.  
  162. Added a new metastring %MSGSPOSTED% which will be translated to the
  163. TOTAL number of messages posted by the user on your system. This is
  164. read from the users record so *may* not contain messages posted using
  165. a mail door as *some* of them do not update the users messages posted
  166. counter :-(.
  167.  
  168. Fixed a minor bug that would cause Rams to generate a runtime error
  169. 002 if no logfile was specified in the config program. Rams will now
  170. by default create a logfile called RAMS.LOG in the directory it was
  171. run from if nothing is setup in the config program.
  172.  
  173. Changed the 'Welcome', 'Upload', 'Watchdog', and 'Birthday' messages
  174. to multi-style msgs.
  175.  
  176. Added Netmail support to the 'Regular', 'Monthly', and 'Yearly' msgs.
  177. This is ONLY available for the USERS messages, and can be used to send
  178. any regular Netmail messages you may need to post.   Things such as
  179. Areafix msgs etc etc. The Netmail ONLY supports Hudson and JAM netmail
  180. areas, it does NOT support the *.MSG format.
  181.  
  182. Changed the screen output so it now shows which user record Rams is
  183. reading. That should satisfy those using slower machines that Rams is
  184. actually doing something, particularly in it's midnight event. Don't
  185. forget the more users you have in your userbase, the longer Rams will
  186. take to run... That's a good enough reason to purge your userbase
  187. files once in a while!
  188.  
  189. Added code to handle Co-Sysop messages. Rams can now post to upto 3
  190. Co-Sysops as well as the normal Sysop msg. The Sysop msg MUST be
  191. active for Rams to post the messages to your Co-Sysops, and you MUST
  192. activate the 'Co-Sysop Feature' in RamsCfg and enter the names of the
  193. users you wish to post to. Rams will then duplicate the Sysops message
  194. and post it to the users you have specified in the config program.
  195.  
  196. Added the ability to reset upload/download counters when sending a
  197. subscription message. You can toggle wether Rams should alter them in
  198. the 'Actions' menu for the subs msgs. If active, RAMS will reset the
  199. users D/Load counters to zero, and reset the U/Load counters to the
  200. 'New user' defaults specified in RAConfig.
  201.  
  202. Corrected a bug in the 'Regular' messages that caused Rams NOT to
  203. post the message because the counters weren't being correctly reset.
  204.  
  205. Added the ability to create Ascii textfile reports from within the
  206. config prog.
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213. *****************************************************************
  214.    What's new in RemoteAccess Automated Message System v1.11
  215. *****************************************************************
  216.  
  217. Now onto the new bits/bug fixes since the first release:
  218.  
  219. Since v1.11 is only a very minor bugfix.. Please read the rest of
  220. this document to see all the changes made since version 1.0
  221.  
  222. Fixed a minor bug that would sometimes cause RamsCfg not to save
  223. any changes made in the config file.
  224.  
  225. All registrations are now being handled by Minerva Online, with
  226. the exception of upgrades from Mom. All details are included in
  227. the REGISTER.NFO and MOMUPGRD.REG files.    So now you have the
  228. choice of paying by cheque, postal order, cash, credit card  or
  229. whatever... There is no excuse for not registering anymore! :-)
  230.  
  231.  
  232. *****************************************************************
  233.    What's new in RemoteAccess Automated Message System v1.10
  234. *****************************************************************
  235.  
  236. Added the Rams version number to the Rams log when it is created.
  237. No real reason for this  except that it will help us to see what
  238. version of Rams is being used if we get any logs sent by users who
  239. have a problem.
  240.  
  241. Added support for the users 'Sex' as a message condition.. So you
  242. can  now  setup  Rams so  it  will post to 'Both',  'Male'  only,
  243. or 'Female' only... The default is for Rams to post to BOTH sexes.
  244.  
  245. Added support for the users 'Language' as a condition.. So you can
  246. now setup Rams so it will post to any valid language in the range
  247. 0-255.. If it is set to langauge 'ALL' (the  default  setting) it
  248. will post to  ALL  users irrespective  of which language they have
  249. chosen.
  250.  
  251. Added support for the users 'Group' as a condition AND action. By
  252. default Rams will post to 'ALL' groups, and will have the action
  253. set as 'N/C' (No  Change).  You can enter  any valid group  as a
  254. condition or action (0-255) and Rams will ONLY post the message if
  255. the user is in the group you have defined. Rams can optionally
  256. change the  users  group if you specify an action... Leaving it at
  257. 'N/C' means Rams will 'Not Change' the users group.
  258.  
  259. Added support for checking the user Flags as a 'Condition'. you
  260. can select a flag Condition of 'X', 'O', or '-'. 'X' means that
  261. the selected users flag MUST be ON, 'O' means that the users flag
  262. MUST be OFF, and '-' means that Rams will IGNORE that particular
  263. user flag. The default is for ALL flags to be set to '-' so that
  264. Rams will IGNORE ALL the user flags and send the message to ALL
  265. users provided they also match any other conditions you may have
  266. specified.
  267.  
  268. Added the code to set the user Flags. You can now specify an 'Action'
  269. for all messages which will tell Rams to alter the user flags when
  270. it posts a message to your users. You have the following options:
  271. T = Toggle userflag ie. if it's ON turn it OFF, or if OFF turn it ON
  272. O = Clear userflag. ie. turn it OFF
  273. X = Set userflag. ie. turn it ON
  274. - = Leave flag setting alone. ie. Don't change it
  275.  
  276. Added a built in message template editor into the config program.
  277. this can be called up in any message menu by pressing F5. If you
  278. are in the Sysop part of the menu, the editor will automatically
  279. load the Sysop message template, if you are in the User part of
  280. the menu it will load the User message template. Not only will it
  281. allow you to edit the message, it will also allow you to select
  282. metastrings from a list.. You choose the one you want, and the
  283. editor will automatically insert it at the current cursor position
  284. in the message template.
  285.  
  286. Added some more error checking into the config program. Now you
  287. MUST  setup the System  menu BEFORE you  can activate ANY of  the
  288. messages.  If you have  not setup the  system menu, RamsCfg  will
  289. display an onscreen message asking you to configure the various
  290. paths first.
  291.  
  292. Changed the order that some of the messages are posted in so that
  293. 'Keyword',  'Times On',  and  'Nth Call' will now be posted AFTER a
  294. 'Welcome' message. If the user is a NEW user, and you have Welcome
  295. msgs active it will ALWAYS be the FIRST message posted to the user.
  296.  
  297. You can now hit F3 from anywhere in each menu and RamsCfg will pop
  298. up  the  users 'Conditions/Actions' menu  so  you  can  setup  any
  299. conditions or actions for that particular message.   You no longer
  300. have to have the option highlighted before you can use the F3 key.
  301.  
  302. Fixed a bug with Weekly messages and the msg counters it uses. If
  303. Daily messages were disabled, but weekly msgs were active, Rams
  304. would show zero for ALL msg counters.
  305.  
  306. Fixed  a problem  with the midnight  messages that would cause a
  307. runtime error 102 or 105 under certain conditions.
  308.  
  309. Fixed a bug with the subscription messages in Rams... This meant
  310. Rams would NOT post any 'Subs' messages.
  311.  
  312. Fixed a bug with the subscription messages that caused Rams to
  313. attempt to post them to the last user that had been online before
  314. midnight, even if they were not supposed to be sent a subs message.
  315.  
  316. Fixed a bug that caused Unregistered versions of Rams to show the
  317. 'Registered' tear line at  the bottom  of any messages that  were
  318. created.
  319.  
  320. Fixed a bug that caused Rams NOT to post *some* user messages if
  321. the  accompanying  Sysop  reports  were  disabled.  The messages
  322. concerned were:
  323. Welcome, Watchdog, Upload, and carrier Drop.  The  USER messages
  324. would NOT be posted IF the Sysop reports were inactive.
  325.  
  326. Fixed a bug that caused Sysop subscription reports to show the name
  327. of the last user online when translating the %USERNAME% metastring
  328. instead of the name of the Subscriber that was posted a message.
  329.  
  330. Fixed a minor problem with user D.O.B. if the users Birthdate was
  331. blank in the users record Rams would display '--19' OR '--' as the
  332. users DOB in messages when it translated the metastrings. Either
  333. '??-??-19?? <Birthdate Unknown>' OR '??-??-?? <Birthdate Unknown>'
  334. will now be shown.
  335.  
  336. Fixed  a bug in the  subscription  messages that caused the Sysop
  337. 'Report' message to be posted even when the user was outside the
  338. conditions specified for the message. The user message wasn't sent,
  339. but the Sysop report was...
  340.  
  341. Fixed a bug in the birthday messages that would cause Rams to alter
  342. the wrong user record if any 'Actions' were defined for the message.
  343. If the user  was at record 505 for example, Rams  would alter record
  344. 504... This ONLY affected birthday messages.
  345.  
  346. Fixed a bug  that caused the %WHOTO% metastring not to be translated
  347. correctly.
  348.