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?

With so many web services using webhooks now, it's getting harder to work with some services without being able to receive the webhooks.  Our PXPlus application servers are behind firewalls, and we don't really want to open up ports to receive the webhooks, or manage an entire Apache server outside the firewall instance just to receive the webhook files.  We don't need to send webhooks - we just need to receive and store them.  I thought about writing a simple receiver (based on the nthost processor) or using EZWeb, but either option probably wouldn't handle the volume of some web API's, and we'd still need to open up ports in the firewall.  I started looking into other services to handle this, and have found several apps that will just act as a webhook receiver (for example, Hookdeck).

Anyone out there have any experience/ideas/suggestions for receiving webhooks?  I'd appreciate any info you can share before I'm forced to re-invent the wheel!

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!

I have a large program (406k) that recently started dying, very unceremoniously!  No error traps were triggered even though an error handler program and a SETERR were in place.  I added traces to the program, and found that it was dying at completely random places each time.  This leads me to believe that it was a memory issue (ie: ran out of memory). The program runs on Linux as a cron process, and the startup environment allocates 32m of memory to all of the processes.  I added a SET_PARAM 'SZ'=64000 into the routine to increase the available memory, and that seems to have resolved the problem.

However, I'd like to see if there is a better way to handle this.

The program is large since it encompasses several CALLed routines, and it will CALL itself several times using line labels.  (eg:  call PGN+";line_label",a$,b$,c).  I suspect that each time it calls itself, a new copy of the (large) program is loaded into memory, thus using up a lot more memory.  Some of the called routines also call other routines in the same program, so a call which is several levels deep could be loading several copies of the program into memory *if that is how the CALL command works*.

My question is: 
- When a program CALLs itself, does it load a new copy of the program into memory?
- And if so, will using ADDR to lock the program in memory prevent a new copy of the program from being loaded into memory?  (and thus reduce my need to allocate additional memory to the session)

Thanks in advance for any info you can provide!

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

When was the functionality added to specify a filename (rather than a channel) to a READ() statement?  For example: READ ("/MyDataFile",key="ABC")

I use this quite a bit in command mode since it's easier than opening a channel, but I don't want to add it to our programs without knowing which version it was added, since we have some older clients that might not support it.

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

PXPlus 11 made it really easy to work with JSON.  GraphQL is similar, but the queries/mutations are a little different then JSON.  Are there any tricks or functionality in PXP that can help with creating the mutations, other than hard-coding the structure?

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!

We have a new Redhat server, with PXPlus 2020 (version 17) installed, and are trying to setup Simple Client/Server using a secured connection.  The setup that we've always used just isn't working.  We were thinking that the cert we are using is invalid for some reason - it was created in 2008, and may not be up-to-snuff with newer SSL options, but has worked with all of our other installations.  I know the server is using OpenSSL 1.1.1.c, but that should work with PXPlus v17 according to messages I've seen on these forums.

So, just to confirm that secure connections are working, I tried just running PXPlus, then opened a secure TCP connection using OPEN (1) "[tcp]www.pvxplus.com;443;secure". That worked fine.

Then, I tried open a local TCP host using OPEN (1)"[tcp];1234;SECURE=/usr/common/cert.cer", which seemed to work fine.  But the connection fails when I try to open that TCP port as a client using OPEN (2)"[tcp]localhost;1234;SECURE".

If I try the host/client without using SECURE, it works fine.

So, thinking maybe it was the cert, I generated a new cert using this command: openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
Then, I cat'ted the two files into a single file using: cat key.pem cert.pem >/usr/common/cert.cer

I retried the host/client again, and it still fails.

Any suggestions on what else I can try or check to get this thing working?

Thanks in advance for any 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?

Is there any way to get the file size (filelength) for an open serial file that is being written to?  The fin(chan,"filelength") doesn't seem to know the length until after the file is closed, but I need to know the length of the file while I'm writing to it, so that I can restrict the size.

For example, I wrote 100 bytes to a serial file, and would like to know that it is 100 bytes at any time.  But, the filelength returns zero until I close and re-open the file.

-}serial "temp.txt"
-}open lock(1)"temp.txt
-}print(1)dim(100,"X")
-}print fin(1,"filelength")
0
-}close(1);open(1)"temp.txt";print fin(1,"filelength");close(1)
101

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?

I'm trying to print a rectangle to either a printer using *winprt*, or a PDF file using *pdf*.  I'm using the 'pen' mnemonic to set the width of the lines for the rectangle. But, the width of the lines is significantly different between the *winprt* output and the *pdf* output. 

I'm using Nomads to design a form, and adding a Shape control to the screen, which is a rectangle.  The pen width is taken from the Width field of the Nomads shape.  That field is defined in the documentation as using graphical units, and can have a value of 0-255.

This appears to be related to the resolution of the output.  If I print the rectangle to a *winprt* printer with a resolution of 300x300, the rectangle prints as expected.  But, if I use the same logic to print to *pdf*, the lines of the rectangle seem to be about 4 times thicker.  I can't find a method to set the resolution for *pdf*, but it appears that the resolution of the *pdf* may be 72x72.  Thus, a graphical unit on *pdf* would be 4.17 times larger the graphical unit on the printer, since 300/72=4.17.  I'm not certain that this is how graphical units work, or if this is the problem.

In a nutshell, I want to be able to print a rectangle to either *winprt* (various printers) or *pdf*, and have them look nearly identical.  Any suggestions on how to properly handle the 'pen' width would be appreciated!

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

We have a client where a certain program just quit working in the middle of the night last week.  A Secure TCP connection can no longer connect, and return MSG(-1) as 'cannot connect securely'.  This has been working fine for months, and there were no changes to any of our programs.  We aren't aware of any changes to the Linux server either, and have no insight into any network changes since it's a huge company with an extensive network. 

We updated everything on the OS, but still can't connect.

So, I tried using 'curl' instead of a PXPlus [TCP] channel.   I *CAN* connect using in PXPlus using a Linux input from curl (ie: OPEN (1)"< curl -X ....."), but trying to open the same site using PXPlus (ie: OPEN (1)"[TCP]some.server;443;SECURE;NODELAY;STREAM") fails ever time. 

PXPlus version is 12.50, and I've tried using NOSSLV2 and other options, but no luck.  I'm assuming that PXPlus is using the same SSL libraries as the Linux OS, so it makes no sense to me why curl can open the connection, but PXPlus cannot.

Any suggestions on what I can look for?

A web service that we use is switching to using SNI (Server Name Indication) for TLS1.2 connections.  In a nutshell, we need to specify the servername that we are trying to connect to when making a secure TCP connection.  I suspected that PXPlus was ahead of the game and already added support for this, and I wasn't disappointed! 

In testing this on Linux server with the latest OpenSSL libraries, I found that I can successfully make a connection using version 14 (ie: tcb(29)=14100000), but not when using version 12 (ie: tcb(29)=12500000). 

Can you confirm that SNI is supported by PXPlus, and what version it was added?  Also, is there any documentation on how it works or modifying how it works (for example, is there a method to specify a different servername using a tcp_opt with the [TCP] command, such as "SERVERNAME=xxxxx")?

We are having a problem making a secure [TCP] connection from one RedHat Linux server, but the same connection works elsewhere.  The problem server is new, and is running PXPlus 14. 

On the working server, we can open the [TCP] channel, then print the FIN(xx,"X509_Subject") to confirm that the certificate was found, as shown below:

-} open(1,tim=5)"[tcp]images.e-brandid.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
/C=US/postalCode=92626/ST=Costa Mesa/L=Costa Mesa/street=Building A/street=3185 Airway Ave/O=Brand ID/OU=IT/OU=Secure Link SSL/CN=images.e-brandid.com
-} write record(1)"test"
-} end

But, on the bad server, the connection opens, but the X509_Subject is blank, and writing to the channel results in an Error 15, as shown below:
-} open(1,tim=5)"[tcp]images.e-brandid.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
-}
-} write record(1)"test"
Error #15: Operating system command failed
Last IO to [tcp]images.e-brandid.com;443;Secure, channel 1
[TCP][Sockets]Error[0]:Success (5:<Unk>)

On the bad server, I can open secure connections to other https URL's, and they return a proper X509_Subject.  For example, a connection to the test Cybersource server is shown below:
-} open(1,tim=5)"[tcp]ics2wstesta.ic3.com;443;Secure"
-} print fin(1,"Secure")
1
-} print fin(1,"X509_Subject")
/C=US/ST=California/L=Foster City/O=VISA INTERNATIONAL SERVICE ASSOCIATION/CN=ics2wstesta.ic3.com
-}

The fact that I can open other secure connections leads me to believe that PXPlus is properly using the Linux certificate authorities, but nothing I've tried lets me connect to the problem URL. 

I was able to connect using curl, as shown below:

$ curl -i -v -X POST https://images.e-brandid.com:443/xml2/xmlreceiver.asmx   -H "Content-Type: text/xml"   -H "SOAPAction: https://images.e-brandid.com/xml2/XMLOrder" -d @/usr/common/test.xml

* About to connect() to images.e-brandid.com port 443 (#0)
*   Trying 64.79.171.67...
* Connected to images.e-brandid.com (64.79.171.67) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_3DES_EDE_CBC_SHA
* Server certificate:
*       subject: CN=images.e-brandid.com,OU=Secure Link SSL,OU=IT,O=Brand ID,STREET=3185 Airway Ave,STREET=Building A,L=Costa Mesa,ST=Costa Mesa,postalCode=92626,C=US
*       start date: May 24 00:00:00 2016 GMT
*       expire date: Aug 05 23:59:59 2019 GMT
*       common name: images.e-brandid.com
*       issuer: CN=Network Solutions OV Server CA 2,O=Network Solutions L.L.C.,L=Herndon,ST=VA,C=US

I was able to issue another command that retrieved the certificate chain from the server (attached file brandid.cer.txt), and I tried everything that I can find on Google to update the root CA's for RHEL and to get that specific certificate chain to be recognized, but nothing is working.  At this point, I'm at a loss as to what to do to make this work in PXPlus. 

Any suggestions?