On 2020 Apr 10 16:11:36, you wrote to me:
VC>>> For DESCription and rules text the width limit is 75 characters
VC>>> with a maximum of 15 lines for DESCription.
>> does this mean 75 characters after the required "DESC " on each line
>> making 80 characters per line max?
VC> Yes 75 after the keyword and space.
ok so 80 characters max per line all total... gotcha...
VC>>> The rules and be any length from 5 to even 500 although the
VC>>> longer they are the more ignored by posters will occur !
>> here, when you say "any length" are you meaning "any number of lines"?
VC> Any number of lines for rules.
ok...
VC> DESC can have only a maximum of 15 lines as that is the space
VC> availble in the data base. This is a limit that has been in place for
VC> what 20+ years.
yeah, i was asking specifically about the rules part and also subtly offering
an edit to the wording there ;)
>> and lastly, i'm confused about a few things regarding the .ECO files:
>> 1. your system cannot process netmails for entry updates?
VC> Correct I have not yet found anything that allows me to read JAM netmails
VC> and there fore gives me an option to create a file for processing. I will
VC> carry on looking same as for email in/out processing. For the moment all
VC> submissions must be as files that are dropped off at 2:2521 or 2:250/1.
can't you use something in mbse or some of its existing code? reading JAM
netmails should be no different than reading JAM echomail... there's only a
couple of slight differences between the two and JAM is only a storage
format...
>> 2. does the filename and extension /have/ to be UPPERCASE?
VC> No, they can be lower case as elist will search for files with extensions
VC> of .eco, .ECO, .rul and .RUL.
ok... i was asking because everything had them in uppercase and i know that
some systems are case sensitive at the file level...
>> 3. do the ECO files have to be attached to a message or just the raw
>> file dropped in your inbound?
VC> Just the files but if your system requires that they be attached to a
VC> netmail that is fine. Just make sure the netmail goes to 2:25/21 (or
VC> 2:250/1).
ok... binkd outboxes will work fine for this, then... my new system works a lot
differently than my old RA/FD/FE setup did... doing a filebox for this
particular task will be the easiest method and not involve the message base
code at all...
>> 4. if we send ECO files, there /must/ be a SUBJ line in them?
>> 4a. with only valid values of MOD-ADD, MOD-UPD, MOD-DEL, or HELP?
>> 4b. when your system starts processing netmails, will that SUBJ
>> line cause problems if it is in the netmail update/addition?
VC> There are a few keywords that are mandatory - they MUST be supplied.
when using ECO and RUL files... ok...
VC> SUBJ With MOD-ADD or MOD-UPD or MOD-DEL
VC> TAG Echo tag name
VC> FROM Your contact details in the format first last name, netmail address
VC> {, email address} where {} is optional.
ok, so you want FROM instead of REPLY and i only need to add SUBJ to my
existing files... gotcha...
>> i'm looking for clarification on all of the above before i dump a load
>> of ~40 updates on you... i don't want to post them as netmails and
>> cause you to have to manually export, edit, and submit them to your
>> processor...
VC> No problem glad to clarify but are you saying that the help file is not
VC> being help full ?
i was saying that some of the wording was slightly confusing... mainly
because... i dunno... i guess i was not seeing a clear delineation between
using netmail and using ECO/RUL files...
VC> If so I will have to look at re writing it but most came from Dana
VC> with updates from Ben.
i understand...
VC> When you are ready send one with what you now think is correct and see
VC> what happens when elist processes it and this occurs every 30 minutes
VC> past the hour.
i'll be pumping them out "shortly... -ish" ;)
thanks for the clarifications!
)\/(ark
"The soul of a small kitten in the body of a mighty dragon. Look on my majesty,
ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... There's a difference between criticism & abuse but most don't know it.
---
* Origin: (1:3634/12.73)
|