HP3000-L Archives

August 2002, 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:
Tom Emerson <[log in to unmask]>
Reply To:
Tom Emerson <[log in to unmask]>
Date:
Mon, 12 Aug 2002 18:40:10 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
> -----Original Message-----
> From: Luna, Tony
>
> Does anyone know the best way to execute a UDC for "hand
> held" terminals.
>
> On our Development HP3000, we just have the USER defined and
> have issued the
> SETCATALOG command to point to the RFUDC.UDCS.SG2TEST (UDC)
> and we don't have to worry about VESOFT.

I'm trying to make sense of your question:

UDC's are "executed" by typing the command at a prompt and pressing <enter>.
I take it from this question, however, that perhaps these "hand held"
terminals don't exactly have qwerty keyboards, correct?  (in other words,
you pre-program the keyboard to somehow "attach" to the host and issue some
form of logon sequence -- from there, the terminal expects to be talking to
a hosted "application" and perhaps each "key" on the terminal actually sends
a string of data rather than a single character?)

So, I take it you mean you want to execute an OPTION LOGON UDC which
(presumably) starts the application on the 3000 that "talks" to the
terminal, and you are getting "hung up" by the additional security
restrictions placed by your system manager [which may be you].  If that is
the case, you have a couple of options:

  1) disable the additional security completely -- this would be bad, so I'm
not going to discuss it further, however there are other "levels" of
disablement that I'll suggest...

  2) edit the VEsoft supplied UDC to check the account before running
MAIN.PUB.VESOFT,logon.  In a sense, you are disabling the use of
Security/3000 for "just that account" -- this is also pretty bad in that you
have no tracking of the use of this account; updates from VEsoft will likely
re-set the UDC; etc. however the rest of your system remains (relatively)
secure.

  3) edit the SECURCON.DATA.VESOFT file to allow access to that account (or
specific user) without the need for a profile or password.  This is
logically equivalent to the above, but doesn't require changes when VEsoft
updates their software.

  4) create a "profile" for this user that either (a) doesn't have a
password, and (b) isn't required to have one [see #3]  "profiles" are
essentially the same as the USER.ACCOUNT you use to log on with, but can
also include the SESSION name as  a specific part of the logon.  In
addition, you can further control this by what TERMINAL they log on with --
with some creativity, you can say that logons from an RF terminal are not
required to pass the security test IF the session,user.account information
matches exactly... [so a logon from a "real" terminal would be prompted for
a password, or better still, forbidden outright...]

   5) finally, you can create a LOGON-EXECUTE rule for the above
[terminal]-sessin,user.account sequence that runs your application, so you
don't even NEED the "user level" UDC file in the first place.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2