We have a strange PXPlus crash occurring at one client, using a routine that is used at multiple clients. 

The routine gets an error 61 (Authorization failure) when issuing a LOCAL command to localize several variables.  At that point, the SETERR branch is taken, and the routine tries to close files.  The PXPlus session then crashes when closing one particular file (the same file every time). 

I don't really have a clue what would cause an error 61 on a LOCAL command!

- I've removed the LOCAL command that was getting an error.  The error then occurs on a different line that is also issuing a LOCAL command, and the session still crashes.
- I've renamed the particular file that is being closed every time the session crashes (thus leaving it in place on the hard drive), then re-created the file.  Still crashes.

Before the system crashes, I print the MSG(-1) to a trace file, but it is blank. 

We suspect a memory/swap file issue, so I also dump the contents of the Linux "free" command to text file immediately after the error 61.  The file shows that there is over 2megs of free memory at that moment, so it wouldn't seem to be an issue with allocating memory for the LOCAL command.  I don't know if the swap file is configured correctly, but it does show swap file available but not being used (or only a tiny amount of swap used).

The client is running PXPlus version 12.50 on a Linux server running RedHat 7.9. 

Any suggestions on how to resolve this, or other ideas on what to check?

The following code will instantly crash (end the session) on all of our installations of PXP version 16.2.  The session will die at line 20.

0010 LET ja$["id"]="123",withnum$="id"
0020 LET json$=DIM(LIST EDIT ja${ALL} WITH NUM(withnum$))

We use similar logic extensively on every other version of PXP, from version 11 through 17.  The code even works correctly on PXP Version 16.1.  The problem is specific to version 16.2, and is somehow related to the "WITH NUM" functionality.  (Removing the WITH NUM functionality allows the code to execute successfully).

We're looking into upgrading our clients that are currently using PXP 16.2, since JSON is used extensively with our web integrations.  However, if there is an easier solution, I'd love to hear it!

Also, I'd be curious if anyone with access to an installation of PXP 16.2 could test this code, so that we can determine if it's something specific to our installation routines.  Our installations are all on Linux servers, generally Centos or RedHat.

Thanks in advance for any suggestions or feedback!

We have a client that is getting an error 99 in *plus/proj/pathinfo on PXP sessions that are running in Linux as cron tasks (ie: there is no Windx connected session).  It appears that this program is related to the TortoiseSVN functionality, but we have never used ANY of the SVN functionality.

The client system is running PXP10, and the line of code getting an error is: 0146 LET api=NEW("[lcl]*obj/winapi")   This line appears to require a Windx session to work correctly.  It does NOT get an error when our programs are run via a Windx session.  It only gets the error when a cron-based program is running.

This system is fairly old and has NOT been updated at all for quite some time, so we are really scratching our heads on why this problem would suddenly appear.  Our guess is that somehow, a program was added to SVN, and is now resulting in this error.  That's just a wild guess at this point, since we have no familiarity with SVN.  Our staff and some of the client staff do have access to PXP consoles, so it's possible that somebody fat-fingered something and turned this on. 

Anyone have any suggestions on how to determine if SVN was somehow turned on for a particular program?

Further info:
We have a utility program named "ischn", which is used for closing channels.  We call that utility program with a line label (ie: call "ischn;CLOSE") to close the open channels.  The error 99 is reported on that CLOSE line label.  So, as soon as that line label is hit, PXP ends up in /usr/pxp10/lib/_plus/proj/pathinfo at line 146, where the actual error 99 occurs.  The prior level program is line 264 of /usr/pxp10/lib/_plus/proj/pxdta

Is a *memory* file using memory on the client or the server?  (For our particular instance, this is using a Linux server, and a Windx client using Simple Client/Server.)

Recently, we've had a couple instances where the EXTRACT on a channel *seems* to be failing to prevent other processes from accessing the record, and I'm trying to figure out if that is really the case, or why.  I'm not certain that is the problem, but it's really the only logical explanation I can find.

We have an order update process that EXTRACTs the order record and writes the record to a different file, but never touches the extracted channel again until it REMOVEs the record when done.  The process hasn't changed for years, and has never been a problem.  Recently, a couple of the records were duplicated, which (seemingly) could only happen if two processes had extracted the record at the same time.

The two processes that run are both using the same FID of "IO", but I don't think that should matter.   There servers are Linux (RedHat) with multiple CPU's, and are fairly new and fast servers, so the processing time is milliseconds when this occurs.  I'm wondering if there is some write caching with the OS or hardware that is affecting this, but don't know how to check that.

In searching these forums and the documentation, I've seen suggestions of using "TIM=0" on the extract, and see that there is a FLUSH command to flush the write buffer to disk.  I don't know if either of these would be useful, but would appreciate any feedback or suggestions!

When pulling in orders from a popular shopping web site, some of the addresses may contain characters that aren't typical characters that can be used to print a mailing label.  Our client has asked us to convert these characters based on a given translation table.   For example, all characters that look like the letter A but with some accent mark should be converted to a simple A.  It sounds easy enough, but finding the oddball characters is definitely a challenge. 

Note that the data is being received in a JSON file, and is using charset=UTF-8, according to the http headers.

For example, suppose the customer entered the following in their order: |àáâãä|ÀÁÂÃÄ|ÿ|Ⓐ| 

This all looks fine in a web browser.  But, the raw JSON data in PXPlus looks like this: |àáâãä|ÀÁÂÃÄ|ÿ|â’¶|

That doesn't display correctly here, so the actual HTA() of that string in PXPlus is: $7C C3A0C3A1C3A2C3A3C3A4 7C C380C381C382C383C384 7C C3BF 7C E292B6 7C$

Most of those characters are 2 bytes characters, but the last one is 3 bytes.  Typically, we just do a CVS(x$,16) on these strings to remove non-printable characters, but the client wants to instead convert them to something similar.  I've tried various CVS() functions such as CVS(x$,"ASCII:UTF8"), but no luck on making any sense of data so that I can convert it using some table.  I haven't figure out how the characters are differentiated between 1-byte, 2-byte, and 3-byte characters.

Searching for each specific hex sequence and replacing it seems like a brute force approach (eg: X$=SUB(X$,$C3A0$,"A"),X$=SUB(X$,$C3A1$,"A"),X$=SUB(X$,$C3A2$,"A")...), and not something I really want to do!

Any suggestions on how to accomplish this?

In parsing xml using the XML() functionality, I've found that multiple spaces are consolidated into a single space, as shown in the following example, where the multiple spaces result in the single space within the string after using the XML function:

-}xml$="abc   123",ofst=0;x$=xml(next from xml$,ind=ofst,key=name$);?x$
abc 123

Researching this, I see that it is fairly standard for XML parsers to consolidate white space.  But, in some cases, we need to keep that white space (eg: a user entered a value that comes through the xml, and we need to match based on that value). 

Is there any way to tell the XML() command to *NOT* consolidate the white space?

On a particular Linux system, FIN(x,"filelength") is returning a negative number for large files (>2.4Gb), but DEC($00$+MID(FIN(x),1,4)) does properly return the file size.  I suspect some 32-bit/64-bit issue, but Linux is 64-bit, and PXPlus is version 12, so it seems that that the "filelength" should work.  I've also tested on version 12 in our development system, and it works fine.  Any suggestions on what I might look at to figure out why the "filelength" isn't working in some systems?

-}open(1)"/usr/common/bigfile.zip"
-}print fin(1,"filelength")
-1472746782
-}print dec($00$+mid(fin(1),1,4))
 2822220514
-}end
-}print ssn
1250-664-0656993
-}print tcb(29)
 12500002