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.)?

If you ESCAPE before the WRITE, you can step through it. The embedded IO routing will be steppable and you can find the offending situation that way.

Documentation indicates *obj/json was implemented last year: PxPlus 2025.

We're finally moving off 2018 (v15.10) ourselves soon, and will be glad to have the various new objects and tools available.

How about creating a PDF and downloading it?