I've created a Keyed Import to bring in shipment information from our
D3 database. It works great, however, after a few days I've noticed
that the user associated with worldship is logged on 3+ ports. A
wheres on the user shows that the last command executed was exit for
all the lines.

Does worldship normally take so many lines or am is worldship not
closing the connections properly?

It seems worldship connections issue an exit command and then
physically disconnect before D3 has time to execute the wrapup. To
fix this:

In the User item where worldship logs-in, add this to the list of
macro's executed:

dcd (n

(If you already have "dcd-on" or "dcd (n" then you don't need to add
that.)

Now in your user-coldstart in dm,md, add:

trap dcd exit

Now execute the trap command at tcl to avoid a reboot.

That should fix the problem immediately for any new logins. Let us
know how it goes.

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno



Specific wrote:

On Jan 25, 12:51*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
When I added DCD (N to the user macro, I started out with 12 lines.
Today it has grown to 16 lines, and it doesn't seem to have worked.
I've logged of the ports and I should have a for sure answer to that
this week. Let me know if you have any more ideas that I should look
into in the meantime.

Thanks.

On 1/25/2011 11:31 AM, Specific wrote:
How are you feeding the D3 data into WorldShip? I do so via a VB
(actually VB6) program using RPC that feeds the data into my own .mdb
which is then imported into WorldShip.

Tony's answer is necessary, but I have also found that D3 doesn't always
logoff the first time you issue a Logoff command. So I do it twice, and
that seems to work. I do the following:

Private Sub Logoff()
Call D3VME.brLogoff
On Error Resume Next
Call D3VME.brLogoff
Call D3Domain.brCloseVirtualMachine(D3VME)
Call D3Env.brCloseDomain(D3Domain)
Set D3VME = Nothing
Set D3Domain = Nothing
Set D3Env = Nothing
End Sub

Hope this helps.

Sholom

On Jan 27, 10:01*am, sh <sham... (AT) prupipe (DOT) com> wrote:
We created a view table for orders in d3 and use Worldship's key
mapping to import via ODBC. The tigerlogic C27 ODBC driver was
installed on the worldship computer, and we created a system odbc data
source that connects to the server. The person running shipments
simply types in the invoice number and it will grab all the shipment
information for them.

On Jan 27, 11:55*am, Specific <domp... (AT) gmail (DOT) com> wrote:
I tired to turn DCD-ON manually (although its already in the user
item) for the port and this is what I get back:
:dcd-on 256
dcd: Cannot reprogram '00030100'. [-001] Undetermined error

On 1/27/2011 1:55 PM, Specific wrote:
I'm not sure the D3 ODBC driver was/is totally reliable. IIRC, there
were lots of problems with it. Has it been "refreshed" lately by TL?

On Jan 27, 2:57*pm, sh <sham... (AT) prupipe (DOT) com> wrote:
I use the same driver on a web server to pull information from the
database (thousands of requests per day), and I never see it holding
up lines. You're lucky if you can even catch a glimpse of it on at
all.

Looking at the lines in "wheres" shows px.resume and tcl1, does that
mean that it could be stuck in shell?

Something is fishy. DCD should always work in conjunction with trap
to logoff ports ... unless you're on some old release where it's
broke.

I could be wrong but ODBC with px.resume with tcl1 tells me you have a
dict item calling a BASIC program that's doing an Execute, and yes,
that could mean "stuck in shell".

On the other hand, if you're coming in via ODBC I'm surprised that
px.resume is at the top of the stack.

Recommendations:
1) Get your VAR involved. If you don't have a VAR, you should.
2) If you are paying a VAR for Support but you are beyond their
ability to help, then get TL involved, and/or get a new VAR.

Seriously, I don't like to bail from a good challenge but this smells
like a situation where people like us in the field can guess at a
hundred things and probably never hit on the right answer. There are
too many unknowns and too many possibilities. (For example we still
don't know the OS, release, SQL monitor version if this is *nix, etc.)
The only real way to diagnose this is to get hands-on with the details
and work it through. Personally I don't get that deep into issues in
a forum. Someone else may take it further with you.

T