At 12:08 AM 5/15/96 GMT, Mike Liening wrote:
 
/SNIP
 
>UDC on the 70:
>start
>option logon
>dsline .....
>remote hello ....     <- control is transfered to the 937's logon udc
>remote bye            <- when control comes back, logoff from the 937
>bye                   <- logoff the 70
>
>UDC on the 937
>start
>option logon
>run app
>:       <- when user exits the app, switch back to the 70
>
>When the user exits the app, and the UDC tries to execute the colon
>command, it fails with:
>THE FIRST CHARACTER IN THE COMMAND NAME MUST BE ALPHABETIC. (CIERR 9090)
>
>Anybody have an elegant way to accomplish this?  (or not too elegant, but
>somewhat transparant to the user)  Or should I go around and install
>another icon pointing to the 937?
 
 
Mike,
 
Perhaps the easiest way to approach this is to have unique logons on each
system that are used for remote access.  The ID used for remote access would
not have a logon UDC.  The local ID then controls the processing on the
remote id:
 
For S/70 user.acct:                    For S/937 remote.acct:
 
   Local ID Command                    NO LOGON UDC
   ----------------
   Start
   option logon
   dsline .....
   remote hello remote/password.acct
   remote run application
   remote bye
   dsline;close
   bye
 
For S/937 user.acct                   For S/70 remote.acct
 
   Local ID Command
   ----------------
   Start                                 NO LOGON UDC
   option logon,NOHELP
   dsline .....
   remote hello !HPUSER,remove/password.acct
   remote run application
   remote bye
   dsline;close
   bye
 
Basically you'll need a different logon ID or intellegence in the logon UDC
to differentiate whether the user is local to the system or remote.  If the
ID is being used remotely, it is important to simply go to a 'colon' as
opposed to automatically running the application.  This is because the
'remote' command on the local system doesn't complete until it receives a
colon from the remote system.  Sure, you can trick it by having the logon
UDC on the remote system issue colons but it needs to determine that the
accessor is indeed from the remote system.  I've found that the easiest
solution is to simply have a single logon ID for remote access which is
bypassed in terms of a logon UDC for the particular account.
 
In the example above for the S/937 access to the S/70 I've included the VAR
HPUSER so when one does a SHOWJOB on the S/70 one can identify who the
remote users are, assuming each has a unique user ID on the S/937.  This
same technique could be done from the S/70 if you have/use an MPEX command
file as MPEX supports most of the standard HP@ VARs on classic systems.
 
I've seen instances whereby the application itself establishes the users
access capabilities based upon the user ID.  In this instance with a common
user ID for remote access, this will require that the application switch to
the job/session name if the user ID is 'REMOTE'.  Attempting to use the same
user ID on both systems won't work if you periodically automatically force
the user to change their passwords as you won't be able to keep the
passwords in sync.  On the other hand, if you user SECURITY/3000 from
Vesoft, they had a technique to resolve the management of passwords.
 
In the example above I included the password with the REMOTE command.  This
would assume that the command file itself is protected (execute only).  It
just so happens that a network logon is the only place MPE will still
permits an embedded password in the logon string.  This was left intact when
pulled from the normal logon process primarily because of HPDesk's
store/forward process if I recall....
 
If you're concerned about the exposure of the password and don't have a
security product to assist you, I contributed a program to the CSL several
years ago called NETACCES which constructed and issued the remote logon with
the embedded password and maintained the password to the remote ID by
keeping it internally encrypted.  It could also change the remote ID
password and update itself if configured to do so by the application owner.
You could also control how the remote ID was constructed to some degree.  If
you can't get it from the CSL, let me know and I'll dig-up a copy.
 
Hope this helps.... :)
 
 
-- Jerry
 
===================================================
 
Democrary is a process by which the people are
free to choose the person who will get the blame.
                       -- Lawrence J. Peter
 
===================================================