The restrictions covered here are those that are not covered elsewhere in
the documentation, or that are of a temporary nature and may be removed in a
later product. Permanent limits are generally covered in the main Help.
The notes below describe some known errors and restrictions in your
installation.
If you have installed a WrapPack containing updates and fixes to your
installation, the fixes and any last-minute issues are documented in the
WrapPack readme, which is downloadable with the WrapPack from the SupportLine
Web site. For details of how to get the latest information see
Updates and
SupportLine
- An Enterprise Server that is configured to use a Security Manager
that uses the mldap_esm module (that is, using LDAP for security) cannot be
started using a file repository, either by using the -m option to casstart and
specifying a file path, or by running casstart when MFDS is not available.
-542314
- A new facility called passtokens can be configured to let
administrators move back and forth between MFDS and ESMAC without signing in
each time they switch from one to the other. (This requires that MFDS and
Enterprise Server use the same security configuration, and that the user has
appropriate privileges.) However, the passtoken is created when the HTML page
with the link to the other facility (for example, the MFDS "server details"
page with the ESMAC link) is generated, and passtokens expire after a short
time. If you wait too long before clicking the link to go from MFDS to ESMAC or
from ESMAC to MFDS, you will be forced to sign on again.
- 543176
- If you configure an LDAP security manager for MFDS, you can view the
resource access control rules it holds for Enterprise Server resources through
the "Properties" pages in the MFDS administration interface. The access level
(read, update, and so on) displayed for MTO resources (transactions, datasets,
and so on) is correct. However, the access level shown for MFDS resources in
the "ESA" and "Servers" sections of the display is misleading, because MFDS
uses a finer-grained permissions scheme. For MFDS permissions, you should view
and edit the Access Control List (ACL) directly.
-543265
- Customers who use the audit feature of Enterprise Server security
should be aware that we cannot enforce auditing for administrative changes to
the security configuration (adding or removing users, changing permissions,
etc). A user with sufficient privilege (an administrator) can disable auditing
before performing other administrative changes, or use third-party tools to
update the configuration in the ESM without using any Micro Focus tooling at
all.
-543360
- The mldap_esm ESM (security) module supports a
password expiration date and a password-must-be-changed flag. However, these
are not usable in practice, because the module does not reset them when a user
changes their password. (Note this applies only if passwords are being handled
by mldap_esm, and not by another ESM module.)
-543613
- Only one mldap_esm ESM module may be used in a
given security configuration list, which means that administrators cannot use
one LDAP server for user information and another for resource definitions, for
example.
-543622
- When external security is enabled for Enterprise Server, user
credentials (username and password) have to be supplied to casstart in order to
start the region. casstart uses those to do an ESF Verify and Auth to ensure
that the user has authority to start the region. casstart also uses those
credentials to bind to MFDS.
A problem can arise because MFDS is a different security domain from
Enterprise Server and may have a different security configuration, particularly
if Enterprise Server is using an ESM (such as the eTrust one) that doesn't
support MFDS. Consequently, administrators may have to define user accounts
twice, once in the ESM used by Enterprise Server, and once in MFDS internal
security (or a different ESM used by MFDS), in order to let those users start a
region.
-543472
- If the Access Control Lists (ACLs) change for users who are already
logged onto Enterprise Server through ESMAC, TN3270, and so on, the ESMAC ACL
changes are not reflected until the user logs off or on.
-543547
- If you have clients using the ECI interface with the CICS Transaction
Gateway to communicate with a CICS application running in Mainframe Transaction
Option (MTO), a client program might receive an ECI_ERR_TRANSACTION_ABEND
return code with an abend code of AZTY, indicating that several clients tried
to communicate with the system at the same time but not all requests could be
satisfied by MTO. The workaround for this issue is to set the environment
variable TX_UNICLI_SESSIONS to the required number of sessions in the
Configuration Information for the enterprise server as follows:
[ES-Environment]
TX_UNICLI_SESSIONS=<required-number-of-sessions>
The default is 4.
You should set "Maximum requests" in the Client Section of the CICS
Transaction Gateway configuration to the same value.
If you do this you will also probably need to change the client
program to ignore the ECI-ERROR_MAX_SESSIONS return code and retry the call.
For example
do
{
Rc = CICS_ExternalCall (&EciParms);
} while (Rc == ECI_ERR_MAX_SESSIONS);
If you do not make this modification, the client program might still
receive the ECI_ERR_TRANSACTION_ABEND return code.