Absent Member.
Absent Member.

Using wrunnet.dll with password protected AcuConnect

[Migrated content. Thread originally posted on 19 May 2011]


In the Interoperability documentation, it says the following in section 5.4.2:

Note that you can call COBOL from .NET locally or remotely. You can even
have the runtime execute remotely without a COBOL object executing on the
client. All you need on the client is a .NET program and a runtime. For this
to work, you set CODE_PREFIX in the configuration file that you provide
with the runtime initialization to point to a remote server hosting your
COBOL application. The remote server must also be running AcuConnect.
AcuConnect is able to execute a COBOL object remotely and share data with
the local runtime. For more information on executing remote COBOL
programs with AcuConnect, please refer to the AcuConnect User’s Guide.

When AcuConnect is setup to require a password, the first time I try to call a program using AcuConnect, a dialog pops up prompting for the AcuConnect password.

The AcuConnect documentation section 2.7.1 says the following about the password:

Option 1: Program Variable

The requesting application may include code that checks for the program variable acu_client_password. If defined, its value is considered an unencrypted password, which is then encrypted and sent to AcuConnect for verification. If the value does not match the value in the access record, the connection is refused. Using acu_client_password, the COBOL programmer has a great deal of flexibility in setting and acquiring the password. The programmer can supply a password to AcuConnect without requiring any user interaction (the user may remain unaware that a password is required).

To use acu_client_password, declare an external pic x variable named acu_client_password in Working-Storage:


Assign a value to the variable before the program's first access to a remote file (or better, before the program's first access to any file). Note that the value of acu_client_password should be terminated by LOW-VALUES.
Option 2: User-entered Password

If acu_client_password is not defined, the client runtime opens a dialog window requesting that the user enter a password.

A password is required to connect to host hostname.
Please enter a password:

The user must enter a password. The characters do not echo on the screen.

The password is then encrypted and sent to the server for verification. If the password matches, a connection is established. If the password doesn't match, or the user enters a blank password (for example, Enter or OK), the user is prompted again to enter a password:

Invalid password
Please enter a password:

The password verification cycle is repeated until a valid password is entered, or the value of the server configuration variable PASSWORD_ATTEMPTS is exceeded (the default value is "3"). The text displayed by the runtime to prompt for a password and report a failed verification can be modified with the TEXT runtime configuration variable. See section 3.3, "Creating a Server Configuration File," for more information about these configuration variables.

Our issue is that we do not want to have the dialog pop up prompting for a password, and we also do not want to have to call a client cobol program to do the first call to AcuConnect using the ACU_CLIENT_PASSWORD working storage item.

Is there a way we can set the AcuConnect password within .Net before calling the first program? I tried looking at the CVM object, and didn't see a property for this.

Thanks for your help,

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.