(synchronous operation)
(asynchronous operation)
To launch the UMD or ASV,
you must have a Windows NT User
Group set up with the users and permissions. This group defines
network and machine resource priviledges for required process
execution. The UNIFACE Server Users group is created during
installation for ASV execution. Below are the priviledges required
and steps to manually create a similiar group modified for UMD
execution:
- Go to Start->Programs->Administrative
Tools->User Manager
for Domains. - In the User menu, choose New Local Group.
- Enter the Group Name: ‘UMD
Users’
(No restrictions for the name). Note that this group must be a
member of the Administrator Group. - Assign the following rights
to this Group:
- Act as part of the operating system
- Create a token object
- Replace a process-level token
- By default, the UMD runs
in the background. If you want to
make it run on the current desktop add the appropriate entries
to the initialization file (see below). Click the Show Advanced
User Rights check box to add the following rights:- Access this computer from network
- Bypass traverse checking
- Increase quotas
- Increase scheduling priority
- Log on locally
- Log on as Batch
- Log on as a Service
- Modify firmware environment variable
- Profile single process
- Take ownership of files or other objects
- Create the users (for
example, unif7205) who start the UMD and
assign them to the ‘UMD Users’ group. When you have created
the users, you must perform an interactive logon for each of
them, because Windows NT creates a profile directory (one per
user) in the Winnt directory. - Create a working directory
(for example C:\AsvUsers). If you
want to log all the users actions, you can also create a
directory for each user. For example: C:\AsvUsers\unif7205 - Configure the permissions
on these directories to allow full
access for all members of the ‘UMD Users’ group.
UNIFACE TCP Superserver
PTCPWNT.EXE
On Windows NT, this process
is represented by the executable
named 'ptcpwnt.exe'. This executable is automatically installed as a
service during normal installation with the prerequisites mentioned
above. Configuration of the TCP Superserver is obtained by default
through the initialization file named PSYS.INI located in the /bin
directory of the UNIFACE installation. A subset of commandline
arguments used with ptcpwnt.exe include:
- ptcpwnt.exe /rem
- Remove TCP Superserver service
- ptcpwnt.exe /ins
- Install TCP Superserver
service with default configuration
(PSYS.INI and windows socket port 12000)
- Install TCP Superserver
service with default configuration
- ptcpwnt.exe /ins /ini=file
- Install TCP Superserver
service with configuration located
in file and default windows socket port 12000
- Install TCP Superserver
service with configuration located
- ptcpwnt.exe /ins /lis=portnumber
- Install TCP Superserver
service with default configuration
(PSYS.INI) and custom windows socket port selection
*Note: Non-default UNIFACE windows socket ports MUST be
specified in %SYSTEMROOT%/system32/drivers/etc/services - Install TCP Superserver
service with default configuration
PSYS.INI Overview and Synchronous Operation
Windows initialization
files are used to direct user authentication,
working directory, and interpret UNIFACE Server Types (UST's).
UNIFACE Server Types depend on correct path and demand-load
library(DLL) information for the intended session. The [uniface_dlls]
section provides the correct search path and required security,
database and network drivers for the session.
The [DEFAULT] section
will be used for users who do not have their
own section defined. UNIFACE requires that a subdirectory named
like that of the user exist under the default workdir (working directory)
specified in the [DEFAULT] section. A sample user named
"UUSR_Compuware Corp." is created during installation. This user
has a corresponding section defined in the PSYS.INI with its own
workdir defined. This corresponding section overrides the requirement
for a like-named subdirectory. The resultant working directory is the
first place UNIFACE will look for an assignment file, typically named
"asv.asn" for application server or "psv.asn" for polyserver.
User authentication is
performed based on section value
"DomainName". It is important to note that this is the users'
authentication domain and not necessarily the hostname of the
machine. Your client may connect to "MYSRV" as "MYUSR" in
which "MYUSR" only belongs to DomainName "MYPDC". Therefore,
DomainName=MYPDC would be the correct section assignment for
[DEFAULT] or [MYUSR], not DomainName=MYSRV.
UNIFACE Server Type definition
is the environment variable passed
by the client to the UNIFACE server. The default variables defined
map to internal names and executable names used by the UNIFACE
product. The general syntax of this variable is:UST=usys/bin/server
where usys is the install base of UNIFACE and server is the
UNIFACE executable required. Available executables are "psv.exe"
for Polyserver, "csv.exe" for 3gl components, and "asv.exe" for
UNIFACE components. These variables are mapped to the
WindowsNT services file located at:
%SYSTEMROOT%/system32/drivers/etc/services.
Exceptions are made when default variables are used (ASV, PSV)
on default UNIFACE port 12000. A carry-over from UNIX services
declarations is a requirement that "Polyserver=usys/bin/psv.exe"
be defined in the [DEFAULT] section.
UMD.EXE
The UNIFACE Message Daemon
(UMD.EXE) is a program used to
administer the Application Servers running in asynchronous mode.
As with the UNIFACE SuperServer (P[Protocol]WNT.EXE) used to
start UNIFACE PolyServer and synchronous application server, the
Message Daemon is a permanently running process that must be
started before using the asynchronous Application Server. The UMD
program will start and manage multiple application servers as required
and re-use dormant sessions. UMD session information can be
obtained using the PDMON utility provided. Default execution of
PDMON will give status to the current machines' UMD. An
application with the UST= assignment or PDMON itself will 'hang' if
the UMD is not running.
The Message Daemon is
started by an administrator or by a user
who has the necessary rights. However, when the user logs off, the
Message Daemon is stopped. The workaround is to install the UMD
as a Windows NT service. This solution requires specific Microsoft
software which is not part of the normal operating system and
therefore is not fully UNIFACE supportable, but you can find the
workaround in the following MyUniface article:
http://myuniface.com/frontline/ntk/howto/umd_nt4.htm
Additional requirements
to executing the UMD as a service are
1) change the service startup parameters to log in as the network
user executing the asynchronous application server and
2) create 'umd.asn' and include it as part of the umd service
execution. The asynchronous application server runs as subtask(s)
of the UMD. TCP Superserver is not required for asynchronous-only
UNIFACE application servers but does require the location of the
application server startup shell (asv.aps).
In the service configuration
file %systemroot%\system32\autoexnt.bat:
c:\usys72\bin\umd.exe /lsn=13000 /asn=c:\usys72\usys\umd.asn /ini=c:\usys72\bin\psys.ini
tcp:
For more information about
the UMD command line options, see
chapter 6 of the UNIFACE Configuration Guide.
The Message Daemon requires
configuration via a Windows
initialization file. This configuration follows the same semantics as
the synchronous application server for user authentication and
working directory. The fundamental difference is the UNIFACE Server
Type syntax. By default UMD will read USYS.INI. It is recommended
that you assign umd execution using the /ini switch to read the
PSYS.INI. An example of a valid asynchronous application server
UST in the PSYS.INI:
AASV=c:\usys72\bin\asv.exe /ust=AASV async:
This syntax assigns the
application server a unique name, matching
that of the UST, via the /ust switch. It also instructs the asv
executable to run in asynchronous mode. Refer to the PSYS.INI
section earlier in this document and the UNIFACE Configuration
Guide for further configuration details.
UMD.ASN
The required entry in
the UMD assignment file:
[FILES]
*.aps usys:*.aps
Configuration involves specifying
the port address to be used by a
service. By default the UMD uses the port 13013, ASV 12000, and
Polyserver 12000. Commandline switches of UNIFACE complement
non-default port assignments. If you want to use a different one, you
can specify it in the services file, located in
C:\winnt\System32\Drivers\etc\services text file:
 |
Click image for enlarged view.
Note: If the line concerning UMD is the last one, add a blank line
at the end of the file before saving it.
Some useful notes on using Windows NT Services from commandline.
NET START service
NET STOP service
When typed at the command
prompt, service names of two words or
more must be enclosed in quotation marks. For example,
NET START "COMPUTER BROWSER" starts the computer browser
service. NET START can also start network services not provided with
Windows NT. NET HELP command | MORE displays Help one
screen at a time. NET ? displays available commands.
UNIFACE Example:
NET START "UNIFACE TCP Superserver" 7204/7205
NET START "TCP Superserver" 7206
User Authentication of Services
Start->Settings->Control Panel->Services contains
a "Startup" option
button. The option setting controls usermode authentication of the
service selected. For most cases the Startup Type will be Automatic
when the machine is started.
The Log On As option is
important to the operation of the UMD. This
option may also be configured for advanced user auditing. The UMD
process configured in this document requires that the account used
to start the asynchronous application server be the same as the user
who starts the AutoExNT service. The AutoExNT service is a
Microsoft Resource Kit option available ONLY on the distribution CD.
Some network configurations
may require that the server host name
be known by your client, so the server IP address must be specified
in the hosts file located in the Windows directory (Microsoft
Windows 95) or in C:\winnt\System32\Drivers\etc (Microsoft
Windows NT) of your client.
ASV.EXE
The synchronous application
server will execute as a subtask of the
TCP Superserver. It will use the UNIFACE assignment file specified
in the PSYS.INI file as specified by the /asn switch, or read the
asv.asn file located in the users working directory. The application
server runs as a seperate network and database process from the
client login therefore it is possible to create a dead-lock situation
between application server data access and client data access. It is
also important that the application server user have priviledge to
read/write to the directories specified by the assignment file in order
to read component definitions or write to log files. In the following
example, UNIFACE Application Server is started automatically, so
no special qualifiers are used in the psys.ini. When you
use an
automatic start-up, the protocol (tcp:) and synchronicity (async:)
are not needed. In the default generated PSYS.INI file, synchronous
application server is represented as:
ASV=c:\usys72\bin\asv.exe
The Application Server
in asynchronous mode is started by the UMD.
The UMD receives the requests for the different Application Servers
that are identified by their UNIFACE Server Type (UST). It looks in the
specified initialization file (ini) and searches the corresponding UST,
retrieves the command line, and starts the relevant Application Server.
You must specify these USTs in the psys.ini for synchronous,
usys.ini for asynchronous, or specify an ini file during service
configuration. By default, asynchronous application server is not
configured at installation time. UNIFACE applications using
asynchronous communication require UST commandline assignment
and started UMD process prior to execution.
ASV.ASN
Note: Database access
for the application server user under
SOLID 3.0 requires that SOLID ODBC be installed and configured as
an ODBC Data Source to Windows NT. SOLID ODBC can be found
in the SOLID 3.0 installation directory.
$SRU is the default path
for UNIFACE application services. USYS
path is an essential UNIFACE Runtime path defined by the [PATHS]
usys=c:\usys72\usys declaration of the USYS.INI file. Assigning
$SRU on the client to a TCP path will define all services remote.
Assigning $SRU on the server to a TCP path is referred to as
chaining of application servers. Essentially ASV.ASN requires
UNIFACE service and descriptor file locations, and required database
declarations.
Sample Configuration
ASV.ASN
[SETTINGS]
$putmess_logfile=asv%p.log
[FILES]
usys:udesc.urr udesc.urr ; files are in asv user's working directory
*.svc *.svc
[PATHS]
$DEF sol:tcp hostname 1313:dbname|?|?
$SRU SRU: ; assign services a local path
[SERVICES_EXEC]
* $SRU:*
PSYS.INI
[uniface_dlls]
demandload=lat1010c.dll,wsk1110c.dll,zsecintc.dll,sol3031c.dll
path=c:\usys72\bin
[DEFAULT]
DomainName=DOMAIN
Polyserver=c:\usys72\bin\psv.exe
UserDir=c:\usys72\user
ASV=c:\usys72\bin\asv.exe
PSV=c:\usys72\bin\psv.exe
[UUSR_Compuware Corp.]
DomainName=DOMAIN
UserDir=c:\usys72\wasv\UUSR_Compuware Corp.
RunInConsoleAccount=No
UMDVisibleDesktop=0
ASV=c:\usys72\bin\asv.exe
PSV=c:\usys72\bin\psv.exe
AASV=c:\usys72\bin\asv.exe /ust=AASV async:
Note: The switch UMDVisibleDesktop=0
means that UMD will run as a
background process. If you want to run it on the active desktop, change
the value to 1 (see the additional users rights).
UMD.ASN
[FILES]
*.aps usys:*.aps
CLIENT.ASN
[PATHS]
$DEF sol:tcp hostname 1313:dbname|?|?
$SYNC TCP:hostname+12000|UUSR_Compuware Corp.|?|ASV
$ASYNC TCP:hostname+13013|UUSR_Compuware Corp.|?|AASV
[SERVICES_EXEC]
ssvc $SYNC:ssvc ; synchronous service component name
asvc $ASYNC:asvc ; asynchronous
service component name
Starting the Application Server
The proc functions $instancepath
and $msgid provide code examples.
In case of automatic start-up, the synchronicity is determined by the
client with the new_instance statement:
new_instance/async "asvc" "asvc"
new_instance/sync "ssvc" "ssvc"
*Note: Asynchronous services cannot contain any
parameters of type OUT or INOUT.