AdHoc msgs rejected by GetAscii (sometimes)

[Brian.Turner]

I'm using PGServer 5 and having a problem with adhoc paging via GetAscii; GetAscii is rejecting messages to some adhoc recips outright, and i cannot figure out why.

This started last week; we had pages failing for the adhoc recip for us_mobility_snpp. Noone bothered to look at the log so my people assumed the carrier was having trouble, and they started changing our users from the us_mobility_snpp to the us_mo_wctp (still adhoc).

This worked fine for a day, then suddenly the us_mo_wctp started failing too. I'm quite sure noone edited the adhoc user itself or the carrier in question. I'm also sure the ASC files being generated are consistent, as i've tested creating text files by hand and dropping them into the polling directory.

Now they've started changing our users to a metrocall_wctp adhoc recip, and so far it's working. However i looked at the log and found that the carrier was never being attempted for those failures, it appeared rather that GetAscii was failing to parse those ASC files correctly. So i'm concerned that it will continue to happen.

Normally in the GetAscii log when an adhoc message is accepted it looks like this:
8/4/2010 10:05:46 AM Message accepted. Recipient: adhoc_metrocall_wctp-1234567890 from: sender@mydomain.com
with adhoc_metrocall_wctp of course being the adhoc user assigned to the Metrocall_WCTP carrier, and 1234657890 being the ID/PIN.

Now with some adhoc users, i'm getting this instead:
8/4/2010 10:05:56 AM Message rejected. Recipient: adhoc_usmobwctp from: sender@mydomain.com. Source: C:\PageGatePolling\bad\315331.754
8/4/2010 10:05:56 AM Not a valid recipient
8/4/2010 10:05:56 AM Message rejected. Recipient: 1234567890 from: sender@mydomain.com. Source: C:\PageGatePolling\bad\315331.754
8/4/2010 10:05:56 AM Not a valid recipient
8/4/2010 10:05:56 AM No valid recipients in message. From: tsender@mydomain.com. Source: C:\PageGatePolling\bad\315331.754
8/4/2010 10:05:56 AM No valid recipients in message

So the two parts needed for adhoc are there, but seemingly parsed as if they were from two messages?

The ASC files that generated both of these were consistently formatted like this:
adhoc_carrier_name{space}1234567980
sender@mydomain.com
message text here

[Brian.Turner]

The problem was that we had exceeded our licensed number of users (10,000).

The adhoc recips are the last in our list, so the ones in excess of our license were unable to have GetAscii interface enabled. This is why some of them worked (the ones below the 10k limit) and some failed.

So, i just need to delete some of our many unused non-adhoc recips, and then enable GetAscii for all adhoc recips.

Thanks much to Aaron Osgood and Jeremy at Notepage Tech Support for the assist!

-Brian