Printable View
Chaps,
I am trying to source compatible USB modems which I can use with an
rx2660 running I64 V8.3
Ideally I want to have a bunch of these hanging from a USB hub and
have UCM automagically create TXAn ports.
Therefore I am looking for compatible modem and hub hardware.
Many thanks in advance.
"issinoho" <issinoho@gmail.com> wrote in message
news:1188897843.839785.30480@r34g2000hsd.googlegroups.com...[color=blue]
> Chaps,
>
> I am trying to source compatible USB modems which I can use with an
> rx2660 running I64 V8.3
>
> Ideally I want to have a bunch of these hanging from a USB hub and
> have UCM automagically create TXAn ports.
>
> Therefore I am looking for compatible modem and hub hardware.
>
> Many thanks in advance.
>[/color]
The problem with USB Modems is that they tend to be unique.
We do have (and ship) an *unsupported* modem driver for an old Compaq 56k
fax/modem (p/n: 322050-001 - and a quick Google search shows that they can
be found - even if the picture is a PCI card :-). But we have not written
any new modem drivers and do not currently support one - mostly because
writing new drivers is demand driven.
If you need a fully supported device, contact Leo Demers at HP dot com who
is the business manager that collects requests for device support.
On Sep 4, 1:37 pm, "FredK" <fred.nos...@dec.com> wrote:[color=blue]
> "issinoho" <issin...@gmail.com> wrote in message
>
> news:1188897843.839785.30480@r34g2000hsd.googlegroups.com...
>[color=green]
> > Chaps,[/color]
>[color=green]
> > I am trying to source compatible USB modems which I can use with an
> > rx2660 running I64 V8.3[/color]
>[color=green]
> > Ideally I want to have a bunch of these hanging from a USB hub and
> > have UCM automagically create TXAn ports.[/color]
>[color=green]
> > Therefore I am looking for compatible modem and hub hardware.[/color]
>[color=green]
> > Many thanks in advance.[/color]
>
> The problem with USB Modems is that they tend to be unique.
>
> We do have (and ship) an *unsupported* modem driver for an old Compaq 56k
> fax/modem (p/n: 322050-001 - and a quick Google search shows that they can
> be found - even if the picture is a PCI card :-). But we have not written
> any new modem drivers and do not currently support one - mostly because
> writing new drivers is demand driven.
>
> If you need a fully supported device, contact Leo Demers at HP dot com who
> is the business manager that collects requests for device support.[/color]
Fred,
My local HP supplier has offered this model,
[url]http://www.dynamode.net/details.asp?id=151[/url]
Would you expect it to have any chance of working?
"issinoho" <issinoho@gmail.com> wrote in message
news:1188911901.359863.249870@50g2000hsm.googlegroups.com...[color=blue]
> On Sep 4, 1:37 pm, "FredK" <fred.nos...@dec.com> wrote:[color=green]
>> "issinoho" <issin...@gmail.com> wrote in message
>>
>> news:1188897843.839785.30480@r34g2000hsd.googlegroups.com...
>>[color=darkred]
>> > Chaps,[/color]
>>[color=darkred]
>> > I am trying to source compatible USB modems which I can use with an
>> > rx2660 running I64 V8.3[/color]
>>[color=darkred]
>> > Ideally I want to have a bunch of these hanging from a USB hub and
>> > have UCM automagically create TXAn ports.[/color]
>>[color=darkred]
>> > Therefore I am looking for compatible modem and hub hardware.[/color]
>>[color=darkred]
>> > Many thanks in advance.[/color]
>>
>> The problem with USB Modems is that they tend to be unique.
>>
>> We do have (and ship) an *unsupported* modem driver for an old Compaq 56k
>> fax/modem (p/n: 322050-001 - and a quick Google search shows that they
>> can
>> be found - even if the picture is a PCI card :-). But we have not
>> written
>> any new modem drivers and do not currently support one - mostly because
>> writing new drivers is demand driven.
>>
>> If you need a fully supported device, contact Leo Demers at HP dot com
>> who
>> is the business manager that collects requests for device support.[/color]
>
> Fred,
>
> My local HP supplier has offered this model,
> [url]http://www.dynamode.net/details.asp?id=151[/url]
>
> Would you expect it to have any chance of working?
>[/color]
I looked at the page, and can't tell. I poked around and my "guess" is yes
based on the claim that it is Linux plug&play compatible. Heck, it looks to
be < $40US on the web. So the worst that can happen is it doesn't work.
According to the driver writer, the driver is compliant with the USB
comunications spec for modems. At the time the Compaq modem was one of the
few that complied (USR did as well - I don't have the model number).
In theory, look for a modem that advertises itself as being "CDC ACM"
compliant and also says "AT command set".
For example:
[url]http://www.radi.com/modular55.htm[/url] says both of the right things... but we
have never tried it.
But many devices don't explicitly say anything about one or the other. I
think a clue might be if the device claims Linux plug&play support without
requiring a unique driver download (linux has support for the same thing).
When you plug the device in, you "may" need to create an entry in
SYS$USER_CONFIG.DAT - but it might "just work". If it doesn't configure as
TXA0 then search SYS$CONFIG.DAT for "modem" and you will find the Compaq and
USR examples. UCM SHOW EVENT/PRIOR=ALL will show you the information for
the modem itself.
Note that we do not "officially" support the modem devices, because we have
not done extensive qualification.
FredK wrote:[color=blue]
> [snip]
> Note that we do not "officially" support the modem devices, because we have
> not done extensive qualification.[/color]
O.K. I'll bite - why does a modem need a driver beyond the usual terminal
driver? As long as it appears to be a standards-compliant async. serial device,
what more is needed?
Interacting with "AT" command-set modems is best left to application, is it not?
--
David J Dachtera
dba DJE Systems
[url]http://www.djesys.com/[/url]
Unofficial OpenVMS Marketing Home Page
[url]http://www.djesys.com/vms/market/[/url]
Unofficial Affordable OpenVMS Home Page:
[url]http://www.djesys.com/vms/soho/[/url]
Unofficial OpenVMS-IA32 Home Page:
[url]http://www.djesys.com/vms/ia32/[/url]
Unofficial OpenVMS Hobbyist Support Page:
[url]http://www.djesys.com/vms/support/[/url]
"David J Dachtera" <djesys.no@spam.comcast.net> wrote in message
news:46DE0BE1.9D1AA379@spam.comcast.net...[color=blue]
> FredK wrote:[color=green]
>> [snip]
>> Note that we do not "officially" support the modem devices, because we
>> have
>> not done extensive qualification.[/color]
>
> O.K. I'll bite - why does a modem need a driver beyond the usual terminal
> driver? As long as it appears to be a standards-compliant async. serial
> device,
> what more is needed?
>
> Interacting with "AT" command-set modems is best left to application, is
> it not?
>[/color]
OK. I'll bite. What is a "standards-compliant async serial device"?
Answer: The only "standard" is what it talks out of the serial wires, not
the interface itself.
A "USB Modem" isn't a serial wire connected to an external modem, it is a
device that presents an interface to the system like a serial port, but
talks directly to a modem connection. So, it needs a classic serial port
driver. The CDC-ACM is the "standardized" interface model designed by the
USB folks.
Why do we need to know about "AT command-set" - this has more to do with
configuration and application assumptions than with the actual application
data itself. The magic conditions for the VMS CDC-ACM compliant driver to
be loaded are:
Interface Class: Communications Device (CDC)
Interface Subclass: Abstract Communications Model (ACM)
Interface Protocol: Common AT Command Set
We will also load the driver for Protocol = None and assume the AT command
set is available. So applications that talk to the modem can assume AT
commands. We provide no way to differentiate between modems with some
"other" command set. I don't believe that the driver itself sends any AT
commands (but I didn't write the driver).
FredK wrote:[color=blue]
>
> "David J Dachtera" <djesys.no@spam.comcast.net> wrote in message
> news:46DE0BE1.9D1AA379@spam.comcast.net...[color=green]
> > FredK wrote:[color=darkred]
> >> [snip]
> >> Note that we do not "officially" support the modem devices, because we
> >> have
> >> not done extensive qualification.[/color]
> >
> > O.K. I'll bite - why does a modem need a driver beyond the usual terminal
> > driver? As long as it appears to be a standards-compliant async. serial
> > device,
> > what more is needed?
> >
> > Interacting with "AT" command-set modems is best left to application, is
> > it not?
> >[/color]
>
> OK. I'll bite. What is a "standards-compliant async serial device"?[/color]
See the source code for SYS$TTDRIVER
[color=blue]
> Answer: The only "standard" is what it talks out of the serial wires, not
> the interface itself.[/color]
Well, yes and no. What it looks like to hardware is one thing. What it looks
like to the software layers above that is something else entirely.
[color=blue]
> A "USB Modem" isn't a serial wire connected to an external modem,[/color]
....but for all practical purposes, should appear as such to the application. A
USB to async. serial adapter could just as easily have a USR Speedster modem
connected to it as a VT terminal. That's all it needs to look like.
The fact that my app. needs to converse with it in "AT"-ese is entirely
incidental.
We keep trying to overcomplicate everything, then we wonder why we're starting
to need a 52-hour day.
--
David J Dachtera
dba DJE Systems
[url]http://www.djesys.com/[/url]
Unofficial OpenVMS Marketing Home Page
[url]http://www.djesys.com/vms/market/[/url]
Unofficial Affordable OpenVMS Home Page:
[url]http://www.djesys.com/vms/soho/[/url]
Unofficial OpenVMS-IA32 Home Page:
[url]http://www.djesys.com/vms/ia32/[/url]
Unofficial OpenVMS Hobbyist Support Page:
[url]http://www.djesys.com/vms/support/[/url]
On 09/05/07 20:49, David J Dachtera wrote:
[snip][color=blue]
>
> We keep trying to overcomplicate everything, then we wonder why
> we're starting to need a 52-hour day.[/color]
Amen, brother.
My father (he'd worship Bill Gates if he could) was just commenting
this evening about how fast Win98 shuts down compared to XP. I, of
course, piped up about complexity.
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
"David J Dachtera" <djesys.no@spam.comcast.net> wrote in message
news:46DF5C8D.3A30E892@spam.comcast.net...[color=blue]
> FredK wrote:[/color]
[color=blue][color=green]
>>
>> OK. I'll bite. What is a "standards-compliant async serial device"?[/color]
>
> See the source code for SYS$TTDRIVER
>[/color]
TTDRIVER is just the class driver. A *port* driver for it must support a
small subset of the actual port/class interface. So it is unclear to me
what TTDRIVER has to do with the price of tea in China. The device itself
is handled by the port drivers - and trust me - there is no "standard" for
the interface other than what comes out the connector on the outside of the
box.
[color=blue][color=green]
>> Answer: The only "standard" is what it talks out of the serial wires,
>> not
>> the interface itself.[/color]
>
> Well, yes and no. What it looks like to hardware is one thing. What it
> looks
> like to the software layers above that is something else entirely.
>[/color]
What does this have to do with the need for a USB driver to talk to the USB
modem? Do you think "magic happens"? This entire thread was about the fact
that USB modems need a special driver and that not all USB modems present
the same interface to the system, and that the VMS USB modem driver is
written to a specific standard - and to tell the OP what to look for.
[color=blue][color=green]
>> A "USB Modem" isn't a serial wire connected to an external modem,[/color]
>
> ...but for all practical purposes, should appear as such to the
> application. A
> USB to async. serial adapter could just as easily have a USR Speedster
> modem
> connected to it as a VT terminal. That's all it needs to look like.
>[/color]
Then it isn't a USB modem. Heck, he could just by a Digi serial dongle and
connect it to an external modem. Or someone could build something that
resembles what you suggest. But who cares? We have code for a specific
type of USB modem.
[color=blue]
> The fact that my app. needs to converse with it in "AT"-ese is entirely
> incidental.
>[/color]
So? My only point here is that what the driver writers assumptions were and
are. When YC (TXA*) is configured, your application can assume by default
that the AT command set is available. If you manage to find a CDC-ACM modem
that doesn't use the AT set, and manage to configure it - you and your
application assumptions are on your own.
[color=blue]
> We keep trying to overcomplicate everything, then we wonder why we're
> starting
> to need a 52-hour day.
>[/color]
Seems that you are overcomplicating this.
The OP wanted to find a USB modem that works on VMS. I told him an
(unsupported) driver ships on the system that supports a specific type of
modem, what modem was tested, and what to look for that matches the standard
which we tested.
You want to quibble about the AT command set being needed, and suggest that
serial devices are all standard anyway.
"FredK" <fred.nospam@dec.com> wrote in message
news:fbp04j$ljs$1@usenet01.boi.hp.com...[color=blue]
>
> "David J Dachtera" <djesys.no@spam.comcast.net> wrote in message
> news:46DF5C8D.3A30E892@spam.comcast.net...[color=green]
>> FredK wrote:[/color]
>[color=green][color=darkred]
>>>
>>> OK. I'll bite. What is a "standards-compliant async serial device"?[/color]
>>
>> See the source code for SYS$TTDRIVER
>>[/color][/color]
Let me suggest that we are talking at cross purposes. Here is a (slightly
shortened for clarity) diagram:
Telephone wire ----> Device ----> Modem/Serial Port driver ---->
TTDRIVER ---> Application
These parts are "standard":
Telephone wire ----> Device
TTDRIVER ---> Application
as is the driver software interface between: Modem/Serial Port
driver ----> TTDRIVER (bearing in mind that there is no device that
supports all port/class interfaces - only a small subset is needed or
generally implemented).
THIS connection:
Device ----> Modem/Serial Port driver
Is unique to the device and it's driver.
That is why you need a port driver. There *is* a standard for USB Modems
CDC ACM - not ALL USB modems follow this standard. Further, the USB
specification for this model provided a way to determine the protocol - in
this case - the common AT command set. Our driver and our configuration
record allows a device that uses the AT command set *or* that specifies NO
Protocol (assumed to be AT) to be configured. While we can know the
protocol in the USM modem driver, I do not believe that the port/class
interface or TTDRIVER has a means to pass this information to the
application. If a modem is configured by VMS - it can then be assumed by
the application to support the AT command set - and this is the only
combination we have done any testing of.
Is it *possible* to find a USB Modem that is CDC ACM compatible that does
not support the AT command set? Possibly. But we aren't looking to find
one, and don't really care to figure that out - we don't officially
test/qualify any USB Modem right now. "Might" it work? Sure, but it
probably requires a new configuration record.
Does it matter to the OP? My assumption is he wants to find something that
will "plug&play".