HP3000-L Archives

March 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Dixon <[log in to unmask]>
Reply To:
David Dixon <[log in to unmask]>
Date:
Thu, 7 Mar 1996 15:47:42 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
>  My question is, most broadly, are we heading into totally uncharted
territory?
 
No, I have completed a scanner gun to IMAGE/SQL via MS Access/ODBC project that
seems to have many similar
characteristics to what you have described.  This system has been running in 24
hours a day seven days a week
production mode for several months.
 
>  If anyone has any advice about potential pitfalls or appropriate ways to
>  proceed, please share!
 
The system I worked on is for packout stations at a manufacturing facility.
Individual bar-coded products are
scanned as they are placed in packaging materials just prior to shipment to
customers.  The scanner guns
currently being used batch the information within the scanner gun (a future
project will upgrade to RF
technology).  It is a requirement that the scanners would be able to transfer
their data without the HP3000 being
online.  The MS Access application transfers the data from the scanners to an
access database that acts as a
buffer between the scanners and the IMAGE database.  The MS Access application
will poll an unavailable HP3000,
and automatically recover when the HP3000 comes back online.  We have a
redundant number of PCs and scanner guns
to assure continuos availability.
 
With this system in place the largest pitfall to date seems to be with the ARPA
listener.  The listener will
occasionally abort (about once every couple of weeks).  Also the listener dose
not always behave when asked to go
down.  Sometimes it will tell you it is down, but it will continue to keep the
IMAGE database open.  This
behavior wreaks havoc with our automated back-ups.  We are currently running
MPE/iX 5.0 and I look forward to the
possibility of these problems being fixed in the next release.  This system
needed to work with several "legacy"
systems, so I did some up front investigation into record locking to prevent
deadlocks.  This system did not
require a lot of real interaction so we could get away with buffering the data.
This buffering of data has
helped us from the disaster recovery stand point, and has given us a nice audit
trail of the transactions.  If I
had a chance I would also consider adding some type of system for reporting
prolonged PC to HP3000 communication
outages via e-mail or raising an alert via HP OpenView Manager.
 
I hope this information proves useful.  If you have more detailed questions
please do not hesitate to ask.

ATOM RSS1 RSS2