| Eddie,
>1. Can the customer continue to use VB and SQLWindows with ACMS
> Desktop on NT Client to talk to ACMS Server on OpenVMS ?
>
I am not familiar with SQLWindows, how it interfaces to ACMS Desktop in
16 bit mode or how that might differ for 32 bit DLLs. It is listed in the
SPD for 16 bit Windows, which is probably an indication that customers
are using it successfully with Windows 3.n. I do not recall anything
being done here in-house as far as testing goes. Perhaps some one else
has experience with a 32 bit version of SQLWindows working with ACMS
Desktop and could comment. If not, it will be a matter of a customer
trying it, or for us to schedule the activity here to locate and aquire
the product in order to develop a sample application and test against it.
If you are able to run SQLWindows under Window 95 in 16 bit mode I
would expect that would also work under NT V4.0.
If you want us to schedule work to test here against SQLWindows, you
should contact the product manager Jerry Hershey (tpsys::hershey) with
the request.
Regarding VB4. The few 16 bit VB applications I am aware of appear to work
fine in 16 bit mode under Windows 95 or Windows NT using VB4. So I
would expect that they will be able to run their 16 bit applications as
they migrate to a 32 bit version. The easiest way seems to be to do a
pilot, just install NT 4.0 and try out the application to prove the
point.
We did a work around in V2.2 for Windows 95 and VB4 in 32 bit mode. The
workaround is posted on ucrow:: in ACMS_DESKTOP$ROOT:[PUBLIC.V22.VB4].
There is a write up in there of what was needed to move to VB4 in 32
bits. We did not do anything equivalent for NT, so in order to use the
workaround on NT with V2.2 we would need to do something similar, and
build a new acmsdi.dll and a vb helper DLL for NT. The V2.3 kit that
goes to SSB this quarter will have the same workaround in it for
Windows 95 and NT. Unfortunately we did not do the work needed to provide
a more suitable interface for VB programmers.
> In the SPD, VB (and SQLWindows) support on NT is not included in "ACMS
> for OpenVMS VAX or Alpha Systems". However, they are included in "ACMSxp
> for Digital UNIX Alpha Systems using the ACMS Desktop for Digital UNIX
> kit".
The SPD I have a copy of (34.81.10, from June '96) does not show VB or
SQLWindows as being supported under NT. Windows NT is not a supported
client with the ACMS Desktop unix kit. Both servers look the same on
my copy as far as supported client under Windows 3.1.
I think a summary of the above is, that you can migrate the application
to NT 4.0 native mode, but:
- Digital or the customer need to experiment with SQLWindows in 32
bit mode to make sure no supprises live there.
- We need to provide a NT version of the V2.2 workaround, or the
customer will need to upgrade to V2.3 when it ships.
- The ACMS Desktop interface with the helper DLL (for VB4 32 bit) is
ugly and awkward. It will hopefully be replaced with something more
usable when future work is considered for ACMS Desktop.
> 2. If yes, can 16-bit and 32-bit applications co-exist ?
Lets take it to be a yes. The applications will be using different
DLLs, one 16 bit and one 32 bit. If the customer wants to run both
kinds on the same machine at the same time, something will probably
need to be done to avoid a DLL naming clash but it would seem
managable. If co-exist means that they could both operate on different
machines going against the same backend, that would seem
straightforward. It should not cause problems providing the 32 bit port
is done in such a way as to not require changes to the ACMS
backend application.
> 3. I assume that the customer can use the same ACMS Desktop licence
> regardless of whether it's Win95 or NT client. Is this correct?
Yes licencing is server based and it does not try to tell one kind of client
from another.
Hope this helps, please follow up if you need additional information.
/Tom
|