How to increase # of characters??

[arfjay]

We are using Procomm Plus 2.01 in a Call Centre environment on megaherz 266 to 400 speed Operator Terminal PCs. We type email addresses and messages to Customers at these PCs which then route these outgoing messages to an NTserver to queue and send via cable modem.

It seems that any email addresses in excess of 25 to 26 characters do not get sent correctly to the NTserver as the 'undeliverable' message back advising the name is wrong and reports we tried to send it to *******@***.co instead of ...com. The email addresses are correct as we can succesfully send them directly from the NTserver as well as other non-callcentre PCs.

I have checked the Setup Utility - Kermit Options and all PCs are set as follows:

[a] control character quote .. 45 [ascii value]
{b} max packet sixe .......1024
[c] Pad character ..... 0 [ascii value]
[d] # of pad characters ......... 0
[e] 8th bit quote character 38 [ascii value]
[f] handshake character ... 0 [ascii value]
[g] end of line character .. 13 [ascii value]
[h] file type ...... binary
{i} Block check type ...... 1 byte checksum
[j] block start character .. 1 [ascii value]

I don't know whether the problem is caused by too many total characters or too many characters before and\or after the '@' or if this program simply cannot take long email addresses.

One email address that does not work has 11 characters before the '@' and 16 character after [including the .com ].

If anybody knows what do to hopefully expand the capability to take longer email addresses I would really appreciate hearing about it.

Thank you

Ron

 

[knob]

Are you using a script, or are the email addresses contained in the file you are transferring? If you're using a script, post the relevant parts and I'll look it over.
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[arfjay]

I don't really know what a script is ... what we have is Procomm emulating a screen setup on the operator terminal monitors - the actual screen setup software is on another Computer linked to all the terminals.

What happens is the operator types a message in the 'message window' and can then either page it or fax it or save it to voicemail or email it. An example of what exactly is being sent is as follows:

***********
** Account: 1234 Page: 007 Mess: 0011
** IN: TER 09\01 8:40 am
** OUT: Ter 09\01 8:40 am to>FILE
**

To: [7:jbc.......@jar.......com]
From: test page from message window Ph#[--#]
Company:
Re:

**
************

************
**ACCT:1234 COMPLETE
************

You will note the email address is complete here however is incomplete '....... .co' as mentioned before in the 'undeliverable' message.

I am thinking it is either a Procomm' issue in which case I need to know what configuration to tweak .... or it is a problem with the software [not procomm] ... it is old software and the vendor isn't much help. I trried sending the same message from 4 different places on the screen and the result was always the same so I do not think it is the 'field' not being big enough.

I know this is a specialized situation and appreciate your time and suggestions.

Ron

 

[knob]

Are you running this under Windows or DOS? If Windows 95 or newer, you can use the Hyperterminal program that came with Windows (it will usually be under the Accessories program folder, or in the Communications folder in Accessories) to determine if the problem lies in Procomm or in the application that you are connecting to. Bring up HyperTerminal, configure it for the same connection and parameters as Procomm, and then run the test. My hunch is that you'll find the application itself is limiting the number of characters in the email address, possibly by ignoring any characters after a set number has been received.
aspect@aspectscripting.com

http://www.aspectscripting.com

 

[arfjay]

We're running this under DOS .... the software is contained in firmware in Eprom chips in a separate Computer called the Linemaster [all telephone trunks come into it as well as the operator terminal connecting cables]. Any time an unfamiliar packet shows up the system freezes so I don't think Hyperterminal will work although we are running other Windows application on the operator terminals.

I think you may be right that the restriction is in the software .. I'll see if I can change anything in that ..

Thanks for your suggestions.