Yep, that's it.

General note (to the powers that be): Identifying when a function is not available in command mode and/or having a table/list of these functions would likely be beneficial.

I'm trying to use XEQ() to process a CALL, but am receiving Error#22:

Quote-}call "Check_Access","ADMIN",OK
-}?ok
1
-}?xeq("Check_Access",OK,"ADMIN",OK)
Error #22: Invalid compound statement
-}

I've changed OK to OK$ in the CALL and the ENTER, thinking the return arg needed to be a string, but no change.

Any ideas?

Same results in v15.1 and v22.1.

What is the error being returned to your program?

It looks like the year portion of the date was created using the "%A" format of the DTE() function.

Any variable that starts with "%" is a global variable. For example: %Company$ or %Max_Size

Simply using the name "declares" it to be global.

That's a good news/bad news situation...
Great that you found it and could fix it. Unfortunately, our company policy it to stay 1 major release back, so we won't be able to use that until next year at the earliest (unless you folks provide another interim release for v22...days before your v23 release...).

These parameters are set in START_UP and our lead program sequence:

SET_PARAM 'KF'=2
SET_PARAM '+A'=12
SET_PARAM 'BY'=0
SET_PARAM -'D0'
SET_PARAM 'FF'=3
SET_PARAM 'OP'
SET_PARAM 'XT'=0
SET_PARAM 'F,'
SET_PARAM 'XF'
SET_PARAM 'NE'
SET_PARAM '+M'
SET_PARAM -'SB'

SET_PARAM 'PQ'=PRM('PQ')

EXECUTE "[WDX]SET_PARAM 'TC'=3"
SET_PARAM 'TC'=3

There is no server-side pxplus.ini in use. The Windows-side pxplus.ini file contains:

[Font]
Points=19
Charset=0
Name=Lucida Console
[WindowFrame]
TypeSizeLoc=1,902,594,200,131
After exiting to command mode, I entered the statements shown in the previous example.

The PxPlus version has been upgraded to 22.01 and it still produces the same results.

The server is running RHEL 9.7
Client is Windows 11 Enterprise 10.0.26100 Build 26100

Many aspects of the PC are managed by the company. Would there be any restrictions on this behavior coming from there? Would there be any sort of "memory protection" prohibiting this?

The screen snip I included is exactly the process I went through. There were no other actions between the steps. This is being launched out of Connection Manager. The v22.01 version should be installed in the next couple of days, so I'll re-test it when it gets here.

Tested using v22.00.0002

We'll be updating to 22.01 shortly.

Could it be a difference between Linux-based and Windows-based systems? I attached what I got with your test.

Any insights?

We're looking at the DEF ENV directive to set some things up as we start our application. Doing some very preliminary tests, it seems as though the BEGIN directive clears out anything that had been set. I thought this was setting the Windows Environment variables for the session, which I would think would be session-permanent.
Is BEGIN supposed to clear these out?

It looks like you're using HTTP 1.0. FedEx may be expecting 1.1.

Any insights? So we don't wander in the dark...

When stepping through, have you tried disabling the seterr in the process?
Do you have any system parameters set that might have some effect on this ('WL', 'WD', 'VW', etc.)?