The client (WindX) is the client. The server (Linux, Unix, Windows, etc.) is the server. One side of the client-server pair can talk with the other side, regardless of the mix.

Caveat: If you have system calls to one type of server (e.g., Linux), they may need to be modified or changed to retrieve the desired information from another server (e.g., Windows).

This probably doesn't have a bearing on the situation, but do you have <CR> characters with the <LF> where POSTMAN does not?

The downloads only seem to have updates for Windows and WindX. Do the updates affect any of the other builds?

It seems to follow the same search logic for non-exename ("mystuff.ini") files as well, instead of the prefix sequencing.

After resetting a few things, including restarting a new session, it looks like all is working as documented.

(Still curious about the default path, though...)

Presuming you have confirmed the source of the transmission sent it properly...

There is a phenomenon that is pretty rare earthside, but seems to happen more commonly outside the atmosphere: cosmic ray bit-flipping. The 64 value change suggests that, as it's just a single bit in the byte. If it happens consistently at the same character, that might also suggest a memory error or failure of some sort.

Not sure what you're referring to with "the R asc 54 will be asc 12", as "R" is ascii 82.

We're looking at using an INI file on our Linux server for some startup information. The documentation indicates the file spec can include a path, but that doesn't seem to be the case. It also doesn't look for the file in the same directory as the executable, which is what we would expect if no path is specified. It's actually in the user launch (home) directory. (We've got that part under control, btw)

Is there something wrong in the usage? The documentation? Other? We're using v15.10 (I know...) on RHEL 7 through WindX.

If you're not adding it in there (accidentally?), then I'm not sure what else it could be.
Are you including images that might overflow the column size?

Looks like it's space-padded. Remove those and "..." should go away.

My apologies...I just re-read your original post and saw that you wanted to set the column widths before loading data. What I provided was to set the widths after loading the data.

That said, we also try to pre-set the widths before loading the data, with something like this:
N_Cols=<#Columns>
ColWidth[*]=<Column Widths>
! fnCell$(Col,Row) returns the Cell ID for Excel (eg, (4,6) returns "D6")
! fnColumn$(Col) returns the Column ID for Excel (eg, (30) return "AD")
!
for C=1 to N_Cols
  Stat=MyExcel'SetRange(fnCell$(C,1))
  Stat=MyExcel'SetColumnWidth(ColWidth[C])
  ! Assign MyExcel'Excel'Columns(fnColumn$(N))'NumberFormat$ if appropriate
next C
This provides a preliminary sizing, with the AutoFit applied after all of the data is loaded in, and only referring to cell A1.

We use the *obj/excel object to export to Excel. With that set in MyExcel, we do 2 steps:
Stat=MyExcel'SetRange("A1")
if Stat then Stat=MyExcel'Excel'Columns'AutoFit()This ensures we don't limit the sizing to only part of the spreadsheet, and then have Excel set the optimal fit for each column.

Basically, what you're doing is creating a JSON array. In PxPlus (v15.1 at least), an array has to have a name of some sort. In our experience, we've used "records". Then have an incrementing counter to identify the relative record within the array.

We send arrays with records that have a key value and a set of data values. Our associative array keys come out looking like: 
records.1.key_value
records.1.data.fieldn
and the result looks like:
{
  "records":[
    {
      "key_value":"12345",
      "data":{
        "fielda":"abcde",
        ...
        "fieldx":"xyz"
      }
    },
    {
      "key_value":"12346",
      "data":{
        "fielda":"abcdx",
        ...
        "fieldx":"qqq"
      }
    }
  ]
}
For your example, the keys may come out like:
records.1.Order
records.1.Customer
records.2.Order
records.2.Customer
with the output looking like:
{
  "records":[
    {
      "Order":"123456",
      "Customer":"ABC Co"
    },
    {
      "Order":"123457",
      "Customer":"XYZ Co"
    }
  ]
}
Hope this helps...

That is "standard procedure" for any expressions. Those expressions at the same "precedence level" will be operated on from left to right.
And yes, parentheses will clarify any precedence questions (though not necessarily make it easier to read...).

From the online manual (Introduction to Using PxPlus -> Language Elements -> Data Type, Literals and Variables -> Numeric Values):

g - Logical Operators
When PxPlus encounters either an AND or an OR logical operator, it attempts to perform a shortcut in the evaluation of the expression. If the value to the left of an AND operator is zero (false), then the expression/value on the right is skipped and the relationship returns 0 (zero). If the value to the left of an OR is non-zero, then the expression/value on the right is skipped and the relationship returns 1.

In this case, there are two expressions being evaluated: "1 OR 0" and "<result> AND 0"
The result of "1 OR 0" is 1, which is fed to the second expression of "1 AND 0", yielding 0.

Try the LOAD first, then the SORT.