Forem: Peter + AI

Uniface 10.4: Understanding the $ALLOW_NOBREAK_SPACE Configuration Parameter

Peter + AI — Sun, 30 Nov 2025 13:59:53 +0000

Introduction

When working with Uniface ProcScript, you might encounter mysterious syntax errors that seem to point at perfectly valid code. The culprit could be invisible non-breaking space characters (0xA0) lurking in your source files. This article explains the $ALLOW_NOBREAK_SPACE configuration parameter and how it can help you deal with this common issue.

What is $ALLOW_NOBREAK_SPACE?

$ALLOW_NOBREAK_SPACE is a configuration parameter in Uniface 10.4 that controls whether non-breaking spaces (hexadecimal value 0xA0) are allowed in ProcScript code. By default, these characters cause syntax errors when the Uniface compiler encounters them.

Syntax:

$ALLOW_NOBREAK_SPACE = 1 | 0

Values:

1 - Non-breaking spaces (0xA0) are allowed in ProcScript
0 - Non-breaking spaces cause syntax errors
Default: None (not set, behaves like 0)

Configuration

The parameter is configured in the client assignment file under the [SETTINGS] section:

[SETTINGS]
$ALLOW_NOBREAK_SPACE = 1

Understanding Non-Breaking Spaces

Non-breaking spaces (Unicode U+00A0, hex 0xA0) differ from regular spaces (0x20). They're designed to prevent line breaks between words, commonly used in word processors and web content. However, in source code, they're usually unintentional and problematic.

How Do They Get Into Your Code?

Non-breaking spaces typically sneak into ProcScript through:

Copy-pasting from documents - Word documents, PDFs, or web pages often contain 0xA0 characters
Text editors - Some editors insert non-breaking spaces automatically
Legacy code migration - Older systems or documentation may include these characters
International keyboards - Certain keyboard layouts can insert them accidentally

Common Problems Without This Parameter

When $ALLOW_NOBREAK_SPACE is not enabled, you may experience:

1. Invisible Syntax Errors

Error: Syntax error at line 42

Your code looks perfect, but the compiler disagrees. The 0xA0 character is visually identical to a regular space, making debugging extremely difficult.

2. Environment-Specific Issues

Code that compiles fine on one developer's machine fails on another, depending on their configuration settings.

3. Migration Headaches

When importing legacy code or documentation examples, you might face compilation failures that are hard to trace.

Best Practices

When to Enable It

Set $ALLOW_NOBREAK_SPACE = 1 when:

Working with legacy codebases that may contain these characters
Your team frequently copies code from external sources
Experiencing unexplained syntax errors in seemingly correct code

Long-Term Solution

While enabling this parameter is a practical workaround, the ideal approach is to clean your codebase:

Use a hex editor or specialized tool to find and replace 0xA0 with 0x20
Configure your IDE to highlight non-breaking spaces
Establish coding standards to prevent these characters from entering your codebase
Use version control pre-commit hooks to detect and warn about 0xA0 characters

Detection and Cleanup

Here's a simple approach to find non-breaking spaces in your code:

Visual Studio Code: Use the find and replace feature with regex enabled and search for \xA0
Command-line tools: Use grep or similar tools to scan files
Uniface IDE: Check compiler error messages carefully for unexpected character warnings

Conclusion

The $ALLOW_NOBREAK_SPACE parameter is a useful configuration option for managing non-breaking spaces in Uniface ProcScript. While it provides a quick fix for syntax errors caused by 0xA0 characters, the best practice is to maintain clean source code that only contains standard spaces (0x20).

Understanding this parameter can save hours of debugging time and prevent frustration when working with ProcScript code from various sources.

References:

Uniface 10.4 Official Documentation - Configuration Reference

Have you encountered non-breaking space issues in your Uniface projects? Share your experiences in the comments!

Unlocking Multi-Threading in Uniface: Mastering $ALLOW_FOREIGN_THREADS for COM Integration

Peter + AI — Sun, 30 Nov 2025 13:48:34 +0000

Legacy enterprise systems meet modern demands. Uniface, the powerhouse for complex backend applications, isn't natively multi-threaded. But when integrating with COM components from external systems, $ALLOW_FOREIGN_THREADS becomes your gateway to safe thread handling. This setting serializes foreign thread calls, preventing crashes in high-load environments like healthcare or finance systems.

Why Uniface Needs Thread Control

Uniface excels in single-threaded operations but struggles with "foreign threads" – those spawned outside Uniface by calling applications via COM (Component Object Model). Without proper handling, concurrent access leads to race conditions, deadlocks, or instability.

Classic Problem: External C#/.NET apps or Windows services invoke Uniface COM objects simultaneously.
Impact: Data corruption, application hangs, or silent failures in production.
Real-World Context: Common in hybrid legacy-modern stacks where Uniface APIs serve multi-threaded clients.

Configuration: Step-by-Step Setup

Add this to your client assignment file under the [SETTINGS] section:

[SETTINGS]
$ALLOW_FOREIGN_THREADS = 1

Values:

1: Enables serialization of COM invocations from foreign threads.
0: Disables (default: none/unset).

Critical Prerequisite: Run the Uniface COM Configuration Utility (ucomcfg.exe) from the Windows Start menu > Uniface group. This sets up thread synchronization – skipping it risks undefined behavior.

How It Works Under the Hood

When enabled, Uniface queues incoming COM calls from external threads and processes them sequentially. This mimics a thread-safe singleton pattern:

External Thread 1 → Queue → Uniface processes → Response
External Thread 2 → Queue (waits) → Uniface processes → Response

Performance Trade-off: No true parallelism, but stability first. Ideal for throughput <100 concurrent calls/sec.

Common Pitfalls & Troubleshooting

Uniface devs often hit these in practice:

Issue	Symptoms	Fix
Deadlocks	App freezes on COM invoke	Verify COM Utility sync settings; test with single thread first.
Performance Drop	High latency under load	Profile with $PROC_TRACING; consider async alternatives like Uniface Router.\
Crashes	AV on multi-thread access	Ensure $ALLOW_FOREIGN_THREADS=1 + COM config; check Windows Event Logs.\
Silent Fails	No errors, wrong data	Enable logging ($PROC_LOG_FILE); validate serialization order.

Pro Tip: Test in isolated env – spawn threads via C# Task.Run() calling your Uniface COM object.

Example: C# Client Calling Uniface COM

Here's a practical integration demo:

// C# Client (Multi-threaded)
public class UnifaceInvoker
{
    private readonly UnifaceCOMObject _unifaceObj;

    public async Task<string> ProcessAsync(string data)
    {
        return await Task.Run(() => _unifaceObj.InvokeMethod(data)); // Foreign thread
    }
}

// Usage: Multiple tasks hit Uniface simultaneously
var tasks = Enumerable.Range(1, 5).Select(i => invoker.ProcessAsync($"Data-{i}"));
await Task.WhenAll(tasks);

With $ALLOW_FOREIGN_THREADS=1, all calls serialize safely. Without? Expect chaos.

When to Use (and Avoid) It

Use Cases:

COM bridges to .NET/C# services.
Legacy Uniface APIs exposed to IIS-hosted apps.
Enterprise integrations (e.g., ERP + Uniface).

Avoid If:

Pure Uniface-to-Uniface comms (use messages instead).
High-throughput needs (>500 TPS) – explore Uniface Router multi-threading.

Modern Alternatives & Future-Proofing

Rocket Software's Uniface 10.4+ pushes cloud-native patterns. Consider:

Uniface Router: Built-in multi-threaded load balancer.
REST/JSON APIs: Bypass COM entirely.
Migration Path: Containerize with Docker/K8s for true parallelism.

$ALLOW_FOREIGN_THREADS bridges the gap – use it wisely to extend legacy Uniface lifespans.

Disclosure: _This article was generated with assistance from an AI language model, based on official Uniface 10.4 documentation and verified sources. Code examples are illustrative and should be tested in your environment.

Questions for you: Integrating with specific C# frameworks? Share your stack for tailored advice!

Understanding $ACTIVE_FIELD in Uniface 10.4

Peter + AI — Sun, 30 Nov 2025 13:27:09 +0000

*This article was created with the assistance of AI and is based on the official Rocket Software Uniface 10.4 documentation.*

The $ACTIVE_FIELD setting allows developers to control the visual appearance of the field that currently holds focus in a Uniface desktop application. This immediate visual feedback helps users track their cursor position, improving usability in data-heavy forms.

How to Configure $ACTIVE_FIELD

This setting is defined in the [SETTINGS] section of your assignment file (e.g., usys.asn or your application-specific .asn file).

Syntax

$ACTIVE_FIELD {=} Attribute {, Attribute, ...}

Available Video Attributes

The following attributes can be combined to style the active field:

HLT: Highlights the field using the system's default highlight color. Note: This attribute takes precedence over other color settings if combined.
BOR: Draws a border around the active field.
UND: Underlines the text in the field.
INV: Inverts the foreground and background colors.
BRI: Displays text in a bright or bold weight (device-dependent).
COL=n: Applies a specific color combination (see calculation below).

Calculating Custom Colors (COL=n)

If you need a specific color combination instead of the system default (HLT), you must calculate the color code n. Uniface uses a standard formula based on an 8-color palette (indices 0-7).

The Formula

Code = (Foreground × 8) + Background

Color Indices

Index	Color
0	Black
1	Blue
2	Green
3	Cyan
4	Red
5	Magenta
6	Brown/Yellow
7	White

Example Calculation

To display White text on a Blue background:

Foreground (White): 7
Background (Blue): 1
Calculation: (7 × 8) + 1 = 56 + 1 = 57
Result: $ACTIVE_FIELD = COL=57

Important Prerequisites & Precedence

Two critical factors determine whether your $ACTIVE_FIELD setting will actually work.

1. The "Cursor Video" Property

The $ACTIVE_FIELD setting is ignored unless the field itself allows it. You must enable the Cursor Video property for the specific field (or model) in the Uniface IDE (Property Inspector > Interface).

2. Precedence Rules (Who Wins?)

When multiple settings try to control the field's appearance, Uniface follows a strict hierarchy. By default, the order of precedence (highest to lowest) is:

ProcScript ($fieldvideo): Code executed in triggers usually overrides assignment settings.
$ACTIVE_FIELD: Your global assignment setting.
$DEF_CUROCC_VIDEO: Settings for the current occurrence.

How to Override ProcScript:

If you want your global $ACTIVE_FIELD setting to always take precedence, even over specific ProcScript commands, add this to your assignment file:

[SETTINGS]
$ACTIVE_FIELD_FIRST = T

Common Pitfalls

Web/DSP Limitations: $ACTIVE_FIELD is primarily for Desktop/GUI applications. For Web (DSP) applications, use CSS pseudo-classes like :focus instead.
"HLT" Override: If you define $ACTIVE_FIELD = (HLT, COL=57), the HLT attribute will win, and your custom blue background (COL=57) will be ignored.
System Themes: The HLT attribute respects the OS theme. On Windows 10/11, this might look different depending on whether the user has Dark Mode or High Contrast mode enabled.

Summary Example

Here is a complete snippet for your usys.asn file:

[SETTINGS]
; Sets the active field to White text on Blue background (57) with a Border
$ACTIVE_FIELD = (COL=57, BOR)

; Optional: Ensures this setting overrides local ProcScript
; $ACTIVE_FIELD_FIRST = T

Uniface Deployment 101: Mastering $SEARCH_RESOURCES and Avoiding the "It Works in the IDE" Trap

Peter + AI — Sun, 30 Nov 2025 13:16:25 +0000

Introduction

If you are migrating from older versions of Uniface (like 9.7) to Uniface 10, you might have stumbled upon the .asn (Assignment) file.

One setting in this file causes more confusion during deployment than any other: $SEARCH_RESOURCES.

In this post, we’ll demystify what this setting actually does, why Uniface 10 treats it differently than its predecessors, and how to configure it for a rock-solid deployment pipeline.

What is $SEARCH_RESOURCES?

In simple terms, $SEARCH_RESOURCES tells the Uniface Runtime (the kernel) where to look for the compiled objects (Forms, Services, Reports) it needs to execute.

There are generally two places Uniface can look for code:

The Repository (DB): This is where your source code lives during development.
UAR Files (Uniface Archive) or Directories: These are your compiled, portable application files.

The $SEARCH_RESOURCES setting defines whether the runtime should look at the source code in the database or strictly use the compiled archives.

The Configuration: resources_only

In the [SETTINGS] section of your assignment file, you will typically see this:

\[SETTINGS\]
$SEARCH\_RESOURCES = resources\_only

In Uniface 10, this is the standard for deployment.

In the past (Uniface 9): You might have used resources_first or resources_last, which allowed the application to "fall back" to the database if a compiled file wasn't found.
The Modern Way: resources_only forces the application to look exclusively in the files defined in the [RESOURCES] section. If a component isn't there, the application throws an error (usually -16 Component not found).

Why is this better?

Performance: Accessing a local file (or loading into memory via $MEMORY_ZIP) is significantly faster than querying a database for every component load.
Stability: You guarantee that what you tested is exactly what is running. No accidental "developer versions" sneaking in from a connected database.

The [RESOURCES] Section: First Match Wins

Once $SEARCH_RESOURCES is active, Uniface looks at the [RESOURCES] section to find the actual files. The most important rule here is sequence matters. Uniface scans this list from top to bottom and stops at the first match.

Here is a typical setup for a deployment environment:

[RESOURCES]
; 1. Hotfixes (Highest Priority)
.\\patches\\urgent_fix.uar

; 2. The Main Application
.\\bin\\my_erp_system.uar

; 3. Uniface System Libraries (Required)
usys:usys.uar
usys:usysicon.uar

The Scenario:

You have a bug in FRM_LOGIN.

You fix it and compile it into urgent_fix.uar.
You place this file in the patches folder.
Because urgent_fix.uar is listed before my_erp_system.uar, Uniface loads the new login form from the patch.
For all other components, it continues down the list to the main archive.

Common Pitfalls

Here are the "Gotchas" to watch out for when moving to a strict resources_only environment:

1. The "Shadowing" Problem

If you deploy a new my_erp_system.uar but forget to remove an old test_debug.uar that is listed higher up in the assignment file, Uniface will happily load the old code. It never warns you that duplicate objects exist.

2. Relative vs. Absolute Paths

Be careful with paths in your assignment file.

.\bin\app.uar relies on the startup directory.
If your shortcut starts in a different folder, the runtime won't find your resources.
Tip: Use logical paths defined in [FILES] or absolute paths generated during your build process.

3. The "It Works in the IDE" Syndrome

The Uniface IDE usually connects to the Repository. If you forget to compile a specific Global Proc into your UAR, it will work fine on your machine (because the IDE sees the DB), but it will crash instantly in the Test environment where $SEARCH_RESOURCES = resources_only is active.

Summary

To ensure a smooth migration to Uniface 10:

Set $SEARCH_RESOURCES = resources_only in all non-development environments.
Treat your UAR files as immutable artifacts.
Keep your [RESOURCES] list clean and ordered.

Happy Coding!

Note: This article was created with the assistance of AI based on official Uniface 10.4 documentation to explain core security concepts and provide practical implementation details.

Mastering the [SETTINGS] Section in Uniface Assignment Files

Peter + AI — Sun, 30 Nov 2025 13:02:19 +0000

If you are developing enterprise applications with Uniface, you know that the Assignment File (.asn) is the nervous system of your application's runtime configuration. While sections like [ENTITIES] or [DRIVER_SETTINGS] often get the spotlight during database setup, the [SETTINGS] section is where the battle for a stable, environment-agnostic runtime is won.

In this post, we’ll dive into what the [SETTINGS] section actually does, the correct syntax for resource loading (fixing common misconceptions), and how to architect it for Development vs. Production environments.

What is the [SETTINGS] Section?

The [SETTINGS] section is used to define Uniface Logicals and Kernel settings. These are environment variables specific to the Uniface runtime that are loaded before your application logic starts. They control how Uniface behaves—how it finds code, where it logs errors, and how it handles dates or strings.

The syntax is straightforward:

[SETTINGS]
$VARIABLE_NAME = value

The Core Strategy: Resource Loading

The single most critical setting in modern Uniface (9.7 through 10.4) is $SEARCH_RESOURCES. This logical controls the order in which Uniface looks for compiled components (Forms, Services, DSPs).

⚠️ Common Pitfall: "Filesystem First"

A common mistake is trying to use a value like filesystem_first. This is not a valid keyword. If you want Uniface to look at your local files before checking the UAR archives, you must use resources_last.

Here are the valid strategies:

resources_only (Production Standard) Uniface completely ignores the file system and only looks inside the UAR (Uniface Archive) files defined in the [RESOURCES] section. This is mandatory for high-performance, secure production environments.
resources_last (Development Standard) Uniface checks your local folders (e.g., \uo) first. If it doesn't find the object there, then it checks the UARs. This is ideal for development because you can compile a form and test it immediately without rebuilding a UAR.
resources_excluded (Default) Uniface never looks in UAR files.

Abstracting Environments with Logicals

Never hardcode paths in your ProcScript or C# bridges. Instead, define them in [SETTINGS] and access them via $logical.

In your ASN file:

[SETTINGS]
$EXPORT_DIR = C:\\MyApp\\Exports
$LOG_DIR    = C:\\MyApp\\Logs

In your Uniface Code:

; Instead of "filedump/append field, 'C:\\MyApp\\Logs\\err.log'"
filedump/append vErrorField, "%%$logical("LOG_DIR")%%%\\error.log"

This abstraction makes migrating your app from Windows to Linux (or Docker containers) as simple as swapping the ASN file.

Configuration Templates

Here is how you should structure your assignment files for different stages of your pipeline.

A. The Development Setup

In development, you need flexibility and verbose logging.

[SETTINGS]
; STRATEGY: Check local files (./uo) first, check UARs last.
$SEARCH_RESOURCES = resources_last

; LOGGING: Redirect the output window to a file for analysis
; Note: Use the correct underscore syntax for Uniface 10+
$PUTMESS_LOG_FILE = .\\logs\\uniface_dev.log

; DEBUGGING: Enable extended IO info in the log
$IOPRINT = 255

; Custom App Settings
$APP_ENV = DEV

B. The Production Setup

In production, you need speed, security, and immutability.

[SETTINGS]
; STRATEGY: Only load signed/packaged code from UARs
$SEARCH_RESOURCES = resources_only

; DISABLE DEBUGGING features
$TEST_MODE = 0

; Custom App Settings
$APP_ENV = PROD

Troubleshooting Guide

Problem	Symptom	Solution
Object Not Found	You compiled a form, but the app still runs the old version.	You likely have $SEARCH_RESOURCES = resources_only set locally. Switch to resources_last so your local compilation takes precedence over the usys.uar.
Log File Missing	$PUTMESS_LOGFILE isn't working.	In newer Uniface versions (especially 10.4), ensuring the syntax is $PUTMESS_LOG_FILE (with the extra underscore) resolves ambiguity.
Linux/Docker Issues	Paths work on Windows but fail on Linux.	Uniface logicals in [SETTINGS] are case-sensitive on Linux. Ensure your logical names (e.g., $EXPORT_DIR) match exactly in your code and ASN.

Conclusion

The [SETTINGS] section is your control center for the Uniface runtime. By correctly utilizing $SEARCH_RESOURCES = resources_last for development and resources_only for production, you create a robust workflow that supports both rapid iteration and stable deployment.

Note: This article was created with the assistance of AI based on official Uniface 10.4 documentation to explain core security concepts and provide practical implementation details.

Uniface 10.4: How to Bulletproof Your Apps with Certification (And Why You Must)

Peter + AI — Sun, 30 Nov 2025 07:58:05 +0000

Note: This article was created with the assistance of AI based on official Uniface 10.4 documentation to explain core security concepts and provide practical implementation details.

Hello everyone!

In today's IT landscape, security is no longer a "nice-to-have"—it's an absolute necessity. This is especially true for enterprise applications that process sensitive data. If you are working with Uniface 10.4 (specifically 10.4.03 and later), you have a powerful tool at your disposal to ensure the integrity and security of your applications: Application Certification.

In this article, we'll dive deep into this feature, explaining how it works, why it's critical, and—most importantly—how to implement it correctly in your .asn files.

What is Application Certification in Uniface?

Certifying a deployed Uniface application is effectively digitally signing your software binaries. It protects your data privacy by verifying the validity of your application at runtime. This ensures that your database connection settings cannot be misused by unauthorized applications.

The goal is to verify two things:

Integrity: That your application has not been tampered with.
Authorization: That your database connection is used exclusively by your authorized Uniface applications.

Why is this important?

Protection against tampering: Once a Uniface application is certified, Uniface validates the integrity of every supported resource file. Any malicious attempt to modify the application files is detected and blocked immediately.
Securing sensitive connection data: Your assignment files (.asn) contain critical information such as usernames, passwords, and paths to your databases. By certifying, you bind the database connection to your specific application signature. Unauthorized or tampered applications trying to use your .asn file will be denied access because they lack the matching private key signature.

How does certification work? (Public/Private Key)

The core of certification is a standard cryptographic key pair (RSA 2048-bit).

Generate Key Pair: You create a key pair, e.g., my_private.pem and my_public.pem.
Sign Application: You use the cert.exe utility (introduced in recent 10.4 updates) to sign your application archive (UAR) or resources using the private key.
Configure Database: You explicitly link the public key (my_public.pem) to your database connection in the assignment file.
Runtime Validation: When the application starts, Uniface checks if the running application's signature matches the public key defined in the driver settings. If they don't match, the database connection is refused.

Technical Deep Dive: The Critical .asn Configuration

Many developers understand the concept but stumble on the implementation. The crucial link happens in your assignment file.

The Setup:

You do not just "place" the key; you must reference it in your DBMS connector settings.

Example .asn Snippet:

[DRIVER_SETTINGS]
; Linking the public key to the MSSQL driver
MSS = U1.0, $DBMS_DEF:my_public_key_string

[LOGICALS]
; Ideally, keep the key content out of plain sight or use references if supported

Note: In practice, the public key is often provided as a string or file reference within the driver parameters ($DBMS_DEF) to enforce the check.

Technical Key Limits:

Private Keys: Max 4096 characters (PEM format, RSA PKCS#8).
Public Keys: Max 1024 characters.

Practical Example: The "Rogue App" Scenario

Imagine you have an HR application connecting to an Oracle database. The .asn file has the connection string ORA:HR_DB|user|password.

Scenario A (No Certification): A developer copies your .asn file to their local machine, points it to their own unauthorized Uniface component, and connects. They now have full read/write access to production HR data.
Scenario B (With Certification): You sign your official HR app with your Private Key. In the production .asn, you add the Public Key to the Oracle driver settings.
- When the rogue developer tries to connect using their unsigned component (or a component signed with a different key) and your .asn file, the Uniface driver checks the signature against the public key.
- Result: Mismatch. The connection is rejected instantly. The stolen credentials are useless without the signed application binary.

Common Pitfalls & Best Practices

Key Management is King: If you lose your private key, you cannot release updates. If it's stolen, the security model is broken. Store my_private.pem in a secure vault and only access it during the build pipeline.
Automate with cert.exe: Do not sign manually. Integrate cert.exe into your CI/CD pipeline to sign builds automatically before deployment.
Performance Check: While the overhead is minimal (RSA validation happens at connection time), always test startup times, especially if your app creates frequent new database connections rather than pooling them.

Conclusion

Application certification in Uniface 10.4 is a critical security mechanism that goes far beyond simple access control. It hardens your application against tampering and effectively binds your database credentials to your specific binary.

If you haven't implemented this yet, put it on your roadmap for the next sprint. It's a low-effort, high-impact security upgrade.

Have you tried setting up cert.exe in your pipelines yet? Let me know your experiences in the comments!

Fixing Legacy Dates in Uniface 10: The $NLS\_DISABLE\_NON\_GREGORIAN\_CALENDAR Switch

Peter + AI — Sun, 30 Nov 2025 07:38:57 +0000

This article was generated with the assistance of AI.

Migrating legacy applications is rarely a smooth ride. If you are a developer maintaining a long-standing Uniface application, you might have encountered a peculiar issue when upgrading to Uniface 10.4.03 or higher: suddenly, your date logic breaks on specific client machines.

This usually happens when your application runs in an environment with a non-Gregorian locale (like de>ar-SA for Saudi Arabia or de>th-TH for Thailand). Uniface 10 introduced enhanced NLS (National Language Support) capabilities, which are great for modernization but can be catastrophic for legacy business logic that assumes every year has 365 days and starts with "20".

Here is the quick fix and the technical "why" behind the $NLS_DISABLE_NON_GREGORIAN_CALENDAR switch.

The Problem: When 2025 Becomes 1447

Prior to Uniface 10.4.03, Uniface functions like $date, $datim, and $clock were largely indifferent to the specific calendar type of the operating system's locale. They typically returned the standard Gregorian date regardless of whether the user's PC was set to use the Hijri (Islamic) or Thai Buddhist calendar.

With the update, Uniface improved its internationalization (ticket UNI-31202). Now, if a user's PC is set to an Arabic locale using the Umm al-Qura calendar, $date might return a year like 1447 instead of 2025.

Why is this bad?

Imagine a validation script in your legacy code:

variables
  date v_compDate
endvariables

; Convert the string to a Uniface date and store it in a variable
v_compDate = $date("01-01-2000")

; Check whether the conversion was successful (optional, but recommended)
if ($procerror < 0)
  message "Error: Invalid comparison date format."
else
  if ($date > v_compDate)
      call LP_PROCESS_ORDER
  else
      message "Error: System date is invalid."
  endif
endif

If $date returns 30/06/1447 (Hijri date), this check fails because 1447 is numerically smaller than 2000. Your valid business logic suddenly treats the current date as being in the distant past.

The Solution: The Kill Switch

Rocket Software introduced a configuration switch to force the old behavior without requiring you to rewrite your entire application or force customers to change their OS settings.

How to implement it

You need to add the following line to your assignment file (.asn), typically in the [SETTINGS] section:

[SETTINGS\]
$NLS\_DISABLE\_NON\_GREGORIAN\_CALENDAR = 1

What it does

Value 1: Forces Uniface to ignore the non-Gregorian calendar settings of the locale. $date will return the Gregorian date (e.g., 2025) even if the OS is using the Islamic or Thai calendar.
Value 0 (or undefined): Uniface respects the OS locale's calendar system (default behavior in 10.4.03+).

Should you use it?

Yes, if you need a quick stability fix for an existing application that was never designed to handle multiple calendar systems.

No, if you are building a modern, truly global application. The "correct" way forward is to write code that is calendar-aware or to explicitly format dates for internal logic while displaying them in the user's preferred format. Rocket Software marks this switch as "Strongly Discouraged" for new development because it essentially disables a feature meant to help you reach a global audience.

Have you faced similar issues migrating legacy ERP systems to modern environments? Let me know in the comments!

Leveraging Service Stored Procedures (SSPs) in Uniface 10.4

Peter + AI — Sun, 23 Nov 2025 13:27:59 +0000

In the world of enterprise application development with Uniface, performance is king. One often underutilized but powerful feature in Uniface 10.4 is the concept of Service Stored Procedures (SSPs).

If you are working with heavy data processing or complex SQL logic, moving that logic closer to the data (the DBMS) is usually the best optimization strategy. Here is a deep dive into what SSPs are, why you should use them, and the constraints you need to watch out for.

What are Service Stored Procedures?

In Uniface, a Service Stored Procedure isn't just a raw SQL script. It acts as a bridge. Technically, it uses the Uniface activate statement to address a Stored Procedure Component that you define within the Signature Editor.

Ideally, you use these when you want to execute DBMS-specific stored procedures but maintain a generic ProcScript activation method. This keeps your Uniface code relatively portable even if the underlying database logic is highly specific.

Why Use Them? (The "Why")

The primary driver is performance.

Imagine a scenario where you need to calculate a complex risk assessment value for a client based on thousands of transaction records.

Without SSP: You fetch all thousands of records to the client (or Uniface Server), loop through them in ProcScript, calculate the value, and display it. This creates massive network traffic.
With SSP: You call the stored procedure. The DBMS performs the calculation on the server. Only the single final result is sent back to Uniface.

Typical Use Cases

Complex Calculations: Doing heavy math where the data lives.
Conditional Logic: Selecting data from Table A or Table B depending on a value in Table C (a decision best made on the server side).
Business Rules: Checking inventory levels and triggering re-order flags in one atomic operation.

Note: If your application is simply waiting for user input, SSPs won't help much. They shine when the bottleneck is data processing, not user interaction.

How to Implement

While the developer (you) is responsible for writing the actual SQL Stored Procedure in the DBMS (be it SQL Server, Oracle, or Informix), Uniface handles the connection.

Define the Component: Create a Stored Procedure Component in the Uniface Signature Editor.
Set to Stateless: Since these are global operations, you must define the operations as stateless.
Activate: Use ProcScript to call it.

; Pseudo-code example of activation
variables
    string vResult
endvariables

; parameters: In_Value, Out_Result
activate "MY_STORED_PROC".CALCULATE_STOCK(12345, vResult)

Uniface ensures the DBMS connection is established before the execution.

Important Restrictions (Read This Before Implementing!)

While powerful, SSPs in Uniface 10.4 come with a strict set of limitations. Knowing these saves you from debugging nightmares later:

No Hitlists: You cannot use standard Uniface hitlist functionality (e.g., $hits is not supported). Data is returned in one step.
No BLOBs/Images: Large object data types (Image, Raw) are not supported. Exception: Raw data parameters work on Sybase only.
No Multibyte Support: There is no support for multibyte language character sets within these procedures.
No Overflow Tables: Tables with overflow fields are off-limits.
No Uniface Wildcards: You cannot use Uniface-specific substitution characters or wildcards; you must rely on standard SQL syntax for the specific DBMS.

Summary

Service Stored Procedures are an excellent tool in the Uniface developer's belt for optimizing high-load queries. By offloading logic to the DBMS via the Signature Editor, you reduce network overhead. However, they require careful planning regarding data types and state management.

Happy Coding!

This article was created with the help of AI.

Running Operating System Commands in Uniface 10.4

Peter + AI — Sun, 23 Nov 2025 13:20:23 +0000

Introduction

Uniface 10.4 allows you to execute operating system commands directly from ProcScript using the built‑in COMMAND and COMMANDOUT operations exposed by an OS service signature.

This is useful for tasks like calling shell scripts, batch files, or external tools, while still keeping the main business logic in your Uniface application.

What OS commands in Uniface are

Uniface provides a special service type often called something like OS that exposes two default operations: COMMAND and COMMANDOUT.

These operations are invoked using the activate ProcScript statement and pass a command string to the underlying operating system shell.

Under the hood, Uniface forwards the command to the OS and reports success or failure back to your ProcScript via the usual $status and $procerror variables.

If the OS command itself is invalid, Uniface raises an activation error and sets $status and $procerror to -150.

Maximum command length limits

When passing commands, you must respect the maximum length supported by the target operating system.

Typical limits in the Uniface 10.4 documentation are:

Windows: up to 8K
Unix/Linux: up to 4K
IBM iSeries: up to 512 bytes per command string

If you build a very long command line that exceeds these OS limits, the command execution will fail before it reaches your actual tool or script.

In practice this means you should keep commands short, avoid inlining huge argument lists, and consider using wrapper scripts when you need complex behavior.

Synchronous execution with COMMAND

By default, calling COMMAND is synchronous, which means Uniface waits until the operating system finishes the command before your ProcScript continues.

This is appropriate for short‑running tasks where your business logic depends on the result, for example building a file and then immediately importing it into the application.

A simple pattern looks like this in ProcScript:

variables
   string vCmd
endvariables

vCmd = "dir /B" ; or "ls" on Unix-like systems
activate "OS".COMMAND(vCmd)

if ($status < 0)
   ; handle error, e.g. log $status and $procerror
endif

This code activates the COMMAND operation on the OS service with a single string parameter that contains the OS command to execute.

Error handling should always inspect $status and $procerror to detect both activation issues and OS‑level problems.

Capturing output with COMMANDOUT

While COMMAND is fine when you only care that the command ran, COMMANDOUT is intended for scenarios where you need to capture and process the text output from the OS command.

Typical examples are parsing directory listings, reading the output of a custom tool, or integrating with scripts that return machine‑readable text.

A common pattern uses one parameter for the command and another for the returned output string, similar to the following conceptual example:

variables
   string vCmd
   string vOut
endvariables

vCmd = "mytool --list"
activate "OS".COMMANDOUT(vCmd, vOut)

if ($status >= 0)
   ; process vOut, e.g. parse lines or tokens
else
   ; handle error condition
endif

The exact signature of COMMANDOUT depends on how the OS service signature is defined in your model, but the core idea is that the operation returns the OS output into a ProcScript variable.

From there you can split the string, validate content, or log it as part of your application diagnostics.

Asynchronous execution with /async

Sometimes you want to fire off a command and not wait for completion, for example starting a long‑running batch process or a background script.

Uniface supports this by allowing the /async switch on the activate statement, which makes the OS command execution asynchronous.

A typical example looks like this:

activate/async "OS".COMMAND("at -fm myscript")

Here the activate/async qualifier tells Uniface to start the command and immediately continue ProcScript execution without waiting for the OS command to finish.

This approach is useful when the command does not have to return a result to the current user interaction and will instead log or report success asynchronously.

Non‑interactive nature of OS services

Uniface OS services are not interactive, which means they cannot reliably host applications that expect to read from or write directly to a terminal UI or prompt the user.

Because of that, the documentation explicitly recommends using the spawn ProcScript statement when you need to run truly interactive applications.

Commands executed via COMMAND or COMMANDOUT should therefore be written to run unattended, using arguments and configuration files instead of interactive prompts.

If your current workflow starts interactive tools, consider wrapping them in non‑interactive scripts that read inputs from files or environment variables.

Error handling and diagnostics

Whenever you call COMMAND or COMMANDOUT, it is important to check both $status and $procerror after the activation.

If the OS command is invalid or Uniface cannot activate the operation, $status and $procerror are set to -150, which tells you there was an activation‑level problem rather than a business error in your script.

For production systems, you should log at least the command string, $status, $procerror, and any returned text, so you can troubleshoot failures on the server.

In multi‑platform environments this logging is especially useful, because command length limits and shell behavior can differ significantly between Windows, Unix/Linux, and iSeries.

Best practices and recommendations

Design your OS commands to be short, deterministic, and non‑interactive, delegating complex logic to external scripts that you version‑control alongside your Uniface application.
Prefer COMMANDOUT when you need structured output and integrate the parsing logic into your ProcScript, keeping a clear contract between the shell script and the Uniface component.
Use synchronous calls for user‑critical operations and asynchronous activation for background jobs that do not affect the current transaction or UI flow.
Always validate $status and $procerror and handle the -150 case explicitly so that you can distinguish between OS‑level issues and functional errors in your own ProcScript

This article was created with the help of AI.

Solving C++ Linking Issues in Uniface on Unix using u3gl

Peter + AI — Sun, 23 Nov 2025 13:14:50 +0000

Introduction

If you are working with Uniface on Unix or Linux platforms, you might have encountered a specific challenge when creating call-in executables. Linking a call-in executable can become a headache if you do not have a C++ compiler, or worse, if you do not have the exact version of the C++ compiler used to build the Uniface runtime.

Uniface contains components written in C++. Consequently, some platforms require that you link your executables using the same C++ compiler version to handle runtime initialization correctly. Trying to do this with a standard C compiler often results in unresolved external errors, such as Unresolved symbol: __shlinit.

For scenarios where acquiring the specific C++ compiler is difficult or impossible, Uniface provides a utility called u3gl.

What is u3gl?

The u3gl program is a pre-linked executable provided by Uniface. It acts as a wrapper that loads a shared library (which you create) and calls a specified entry point function.

Because u3gl is already distributed as an executable linked with the correct C++ compiler, it handles the C++ runtime initialization on behalf of your shared library. This means you, as the 3GL developer, only need to link a shared library—executable linking is no longer required.

How to Implement u3gl

Here is a step-by-step guide on how to convert a standard call-in program to use u3gl.

1. Refactor the Entry Point

Consider a standard call-in program callin.c that uses main:

#include <h3gl.h>

void main (int argc, char* argv[])
{
    (void)unifbeg(1);
    (void)urun((unsigned char *)argv[1], 0, 0, 0, 0);
    (void)unifend(-1);
}

To use u3gl, rename the entry point from main to a custom function name, for example, callin:

#include <h3gl.h>

/* Changed from main to callin */
void callin (int argc, char* argv[])
{
    (void)unifbeg(1);
    (void)urun((unsigned char *)argv[1], 0, 0, 0, 0);
    (void)unifend(-1);
}

2. Compile as a Shared Library

Instead of compiling an executable, you must compile and link the code into a shared library (e.g., callin.so).

Example commands (Solaris syntax):

$ cc -c -mt -KPIC -I3gl/include callin.c
$ cc -G -z defs -mt -KPIC -o lib/libcallin.so -lc -L./lib -lucall -lurtl -lulib -lyrtl callin.o

Key Flags used here:

-KPIC: Produces position-independent code (required for shared libraries on Solaris).
-G: Instructs the linker to produce a shared library.
-z defs: Produces an error if symbols cannot be resolved at link time (highly recommended to catch issues early).

3. Run with u3gl

Once the shared library is created (preferably in the Uniface lib directory to avoid LD_LIBRARY_PATH issues), you use u3gl to run it.

Syntax:

$ bin/u3gl --shared=libcallin.so --func=callin ENT

In this example, ENT is a form passed as an argument to the function.

Simplifying the Execution

The full syntax allows for customization via switches:

--shared=SharedObjectName: Defaults to libProgramname.so
--func=FunctionName: Defaults to Programname
--verbose: Useful for troubleshooting

Pro Tip: You can create a symbolic link or copy of u3gl and name it match your program (e.g., callin).

If you rename u3gl to callin, the utility automatically defaults the --shared and --func parameters to match the program name. You can then run it simply as:

$ callin

This runs the code without the user needing to know that u3gl is handling the execution in the background.

Important Considerations

Platform Support: This functionality is available only on Unix and Linux platforms.
Environment: As with standard Uniface applications, ensure insunis is called and LD_LIBRARY_PATH is set correctly.
Arguments: Command line parameters (like form names) are passed at the end of the command line. If a parameter starts with --, use a double-dash separator:
```
bin/u3gl --shared=foo.so --func=bar -- --hello--
```

This article was created with the help of AI.

Simplifying Legacy Integration: Using Call-In Stubs in Uniface 10.4

Peter + AI — Sun, 23 Nov 2025 13:06:28 +0000

Simplifying Legacy Integration: Using Call-In Stubs in Uniface 10.4

Integration between modern 4GL environments and traditional C (3GL) code often feels like a high-wire act. You have to manually juggle memory handles, parameter mappings, and execution states. One slip—like a mismatched data type or a forgotten handle release—and your application crashes.

If you are working with Uniface 10.4, there is a better way. Instead of writing verbose, error-prone C code to activate Uniface services, you can use Call-In Stubs. This feature generates clean C wrappers for your 4GL services, handling the heavy lifting automatically.

Here is how to streamline your C-to-Uniface integration.

The Old Way: Manual & Tedious

Let’s say you need to call a simple operation named CALLIN inside a Uniface service CALLINSRV.

Without stubs, you are forced to write about 20 lines of boilerplate code just to fire a single trigger. You have to manually instantiate the environment, service, and operation, and then painstakingly map every parameter.

#include <h3gl.h>

void main (void)
{
    UHACT hEnv, hIn, hOp;
    long opStat;

    /* 1. Manual Lifecycle Management */
    uecreate(1, 0, 0, "my.asn", 0, 0, &hEnv);
    uinstnew(hEnv, "CALLINSRV", 0, 0, UDEFAULT_COMM_MODE, 0, &hIn, 0);
    uinstopr(hIn, "CALLIN", 0, &hOp);

    /* 2. The actual call */
    uopract(hOp, &opStat, 0);

    /* 3. Manual Cleanup (Order matters!) */
    uinstdel(hIn, 0);
    uedelete(hEnv);
    ufreeh(&hOp); ufreeh(&hIn); ufreeh(&hEnv);
}

The Pain Points:

Verbose: It is hard to see the business logic amidst the infrastructure code.
Fragile: If you add a parameter to your Uniface service later, you have to rewrite the C code to push/pop that parameter manually.

The New Way: Generating Call-In Stubs

Uniface can examine your compiled service and generate a C "stub" file. This file contains wrapper functions that handle all the Uniface plumbing for you.

Step 1: Compile Your Service

Ensure your Uniface service is compiled and the UAR file is up to date. The generator reads from the compiled descriptor, not the source code.

Step 2: Generate the Stub

Run the following command in your terminal:

ide /sti ServiceName

Uniface creates two files:

ui_servicename.h (Header file)
ui_servicename.c (Source file containing the wrapper logic)

For our CALLINSRV example, this generates functions like ui_callin_callinsrv(), which maps directly to your 4GL operation.

Step 3: Refactored C Code

Now your C code becomes drastically simpler:

#include <h3gl.h>
/* In a real project, link the .obj/.o file instead of including .c */
#include <ui_callinsrv.c> 

void main (void)
{
    UHACT hEnv;

    /* Initialize the environment once */
    uecreate(1, 0, 0, "my.asn", 0, 0, &hEnv);

    /* The complex logic is now a single function call */
    ui_callin_callinsrv();

    /* Tear down */
    uedelete(hEnv);
    ufreeh(&hEnv);
}

⚠️ Common Pitfalls & Best Practices

While stubs make life easier, there are still traps for the unwary.

1. Don't Forget the Lifecycle!

A common misconception is that the stub handles everything. It does not. The stub only manages the Service and Operation handles. You are still responsible for creating the Uniface Environment (uecreate) before calling the stub and destroying it (uedelete) afterward.

Symptom: If you forget uecreate, your program will likely crash with a segmentation fault or return an obscure error code immediately upon calling the stub.

2. Linking vs. Including

In the example above, we #include the .c file for simplicity. In a professional build pipeline:

Don't: #include "ui_service.c" in multiple places. This leads to "duplicate symbol" errors during linking.
Do: Compile ui_service.c separately into an object file (.o or .obj) and link it to your main application.

3. Stale Signatures

If you update your Uniface service (e.g., add a new parameter) but forget to run ide /sti again, your C code is now calling a ghost.

Risk: The stub will try to map parameters that don't exist or have changed types, leading to runtime corruption that is very hard to debug.

Fix: Make stub generation a standard step in your build pipeline whenever UARs change.

4. Never Edit the Stub Manually

You might be tempted to add a printf inside the generated ui_servicename.c for debugging.

Don't do it. Any time you regenerate the stub, your changes are wiped out. If you need logging, wrap the stub call in your own wrapper function.

Conclusion

Call-In Stubs in Uniface 10.4 turn a complex, 20-line manual integration task into a robust, 3-line function call. By automating the parameter mapping, you not only save time but also eliminate an entire class of "fat-finger" errors in your C/Uniface bridge.

Happy Coding

A small note on the side. This article was created with the help of AI.

🚀 Deep Dive: The Uniface 3GL Call-In API & C Integration

Peter + AI — Sun, 23 Nov 2025 13:00:45 +0000

Introduction

Integrating modern C/C++ applications with established Uniface systems doesn't have to be a black box.

The Uniface 3GL Call-In API acts as the bridge, mirroring the power of the ProcScript activate command but from within your C code.

This guide breaks down how to instantiate components and effectively manage the environment lifecycle using the ucall library.

The Core Mechanism

The Call-In API allows you to:

Instantiate Uniface components (Forms, Services, Reports).
Execute operations with full parameter support (IN/OUT).
Control the Uniface environment (Start/Stop).

All necessary functions are bundled in the ucall shared library.

This is the single dependency you need to link against.

The Lifecycle: A "Typical" Sequence

The documentation often shows a sequence involving both creation and opening.

Here is what happens under the hood:

#include <uactdef.h>

// 1. Start Uniface (Only if not already running!)
uecreate(...); 

// 2. Get Handle (Optional if you have the handle from step 1)
ueopen(...); 

// 3. Component Lifecycle
uinstnew(...); // Create Instance
uopract(...);  // Activate Operation
uinstdel(...); // Delete Instance

// 4. Cleanup
uedelete(...); // Shutdown Environment

💡 Pro Tip: uecreate vs. ueopen

There is often confusion about when to use which.

Here is the rule of thumb:

Scenario A: You are the "Driver" (Call-In)

Your C program starts the process.

Uniface is not running.

Action: Call uecreate.

This starts the environment.

You can call ueopen afterwards (and generated stubs often do), but the handle from uecreate is already valid.

Cleanup: You must call ufreeh on your handle, and finally uedelete to shut down Uniface.

Scenario B: Uniface Called You (Call-Out)

Uniface is already running and called your C function.

Action: Do NOT call uecreate.

Instead, call ueopen to grab the existing environment handle.

Cleanup: You must still call ufreeh on the handle you got from ueopen when you are done, but do NOT call uedelete (you don't want to kill the parent Uniface process!).

The "Smart" Way: Generated Stubs

Writing the boilerplate above manually is error-prone.

Uniface allows you to generate wrapper code directly from your compiled UAR signatures.

Run the following command in your CLI:

ide /sti <your_component>

This generates C stubs that handle the messy uinstnew/uopract sequence for you, allowing you to call Uniface operations as if they were native C functions.

Conclusion

Whether you are manually managing handles for fine-grained control or using ide /sti for rapid development, the Call-In API is robust.

Just remember: always match your ueopen/uecreate calls with a corresponding ufreeh to prevent memory leaks.

This article was created with the help of AI.