ChatGPT Programming Preferences for Omnis Classic

Guidelines for AI-Assisted Development

This document defines how ChatGPT must behave when assisting with Omnis Classic programming.
The goal is to prevent Studio concepts from leaking into Classic code and to ensure generated solutions remain compatible with real Classic environments.

These guidelines reflect established, reliable Omnis Classic practice.

1. Default Mode

ChatGPT must assume Omnis Classic unless explicitly told otherwise.

This means:

• procedural execution
• datafile-based storage
• no Studio object model
• no Studio methods, events, or abstractions

2. Prohibited Constructs

ChatGPT must never introduce:

• Begin transaction
• Commit
• Rollback
• $construct, $destruct, $event(), $methods
• Studio SQL classes
• Studio window objects
• any syntax not present in Classic

3. Required Classic Coding Style

3.1 Procedural Flow Only

Classic code must use:

• Calculate
• Set current list
• Single file find
• For / End For
• Loop / Exit loop
• Do
• Call procedure
• Set main file
• Set read/write files

No object dispatch, instance variables, or Studio event model.

3.2 Automatic Formatting

Classic rewrites indentation and spacing on save.
Generated code must not rely on custom whitespace for meaning.

4. Expected Classic Behaviours

4.1 Behaviour of pick()

When used without a third argument:

pick(list, match)

it returns 0 if no match is found.
This must be preserved exactly, without attempts to “modernise” the handling.

4.2 List Columns by Field Name

Classic lists are accessed by column name:

LL_List(ColumnName, RowNum)

Numeric column indexes must not be used unless the codebase already uses them.

4.3 Using nam() for Dynamic Columns

To compute a column identifier dynamically:

Calculate LC_Col as nam(LC_ColName)
Calculate LL_List(LC_Col, RowNum) as ...

This is required Classic behaviour and must not be replaced.

4.4 Loose Typing Rules

Classic allows:

• automatic character-to-number coercion
• booleans treated as numeric values
• blank fields equating to zero in many contexts

Generated code should assume Classic’s permissive type environment.

5. Naming Conventions

ChatGPT must follow Classic variable prefixes already established in the codebase:

Local Variables

• LB_ — boolean
• LC_ — character
• LI_ — item References
• LL_ — list
• LN_ — number

Local Variables

• PB_ — boolean
• PC_ — character
• PF — Field name
• PI_ — item References
• PL_ — list
• PN_ — number

Field names in Files

• Fnn_ — field names in files
• other prefixes consistent with existing procedures

Names must match the user’s code style rather than invented patterns.

6. Structural Expectations

6.1 Readability

Generated code must:

• use clear sequences of Calculate, If, Else, End If
• avoid deeply nested logic where simple steps are clearer
• align with existing jPartner and PHL coding conventions

6.2 No Hidden Behaviour

Classic code is explicit.
ChatGPT must not introduce:

• implicit behaviours
• helper abstractions
• “smart” shortcuts
• refactors that mask control-flow

If logic is complex, it should be split into clear procedural sections or sub-procedures that match Classic norms.

7. jPartner and PHL Context

The following rules apply automatically when working with jPartner or PHL:

• use strict Classic procedural syntax
• respect datafile and list structures already defined
• maintain the existing looping and calculation patterns
• do not introduce Studio-style parameter passing or objects
• assume pick() behaviour, list column naming, and Classic trimming rules

These contexts require adherence to long-established patterns.

8. Purpose of This Document

These preferences exist to ensure:

• stable Classic-compatible code
• predictable procedural execution
• consistency across all jPartner and PHL updates
• elimination of Studio-based interference

ChatGPT must load and follow these behaviours whenever assisting with Omnis Classic programming.