Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
61
Thin Client/WindX / Re: Can't get Simple CS to work on a new Redhat server
« on: October 13, 2020, 11:53:13 AM »
Thanks for the tips - this is resolved now.
Using the old cert, msg(-1) was returning a message "Can not use certificate on file (err/ret=2/2)". That old cert used SHA1, and I suspect that the new Redhat server is configured out of the box to not allow SHA1. So, I generated a new cert using SHA256, and it worked fine.
Devon, the tip on testing an SSL connection was great! I could never get my two sessions to talk to each other over TCP since the secure connection always failed. Hitting 'enter' on the READ RECORD for the 'host' process immediately after trying to open the client port worked perfectly, and allowed the connection to be secured. Thanks!
Using the old cert, msg(-1) was returning a message "Can not use certificate on file (err/ret=2/2)". That old cert used SHA1, and I suspect that the new Redhat server is configured out of the box to not allow SHA1. So, I generated a new cert using SHA256, and it worked fine.
Devon, the tip on testing an SSL connection was great! I could never get my two sessions to talk to each other over TCP since the secure connection always failed. Hitting 'enter' on the READ RECORD for the 'host' process immediately after trying to open the client port worked perfectly, and allowed the connection to be secured. Thanks!
62
Thin Client/WindX / Can't get Simple CS to work on a new Redhat server
« on: October 12, 2020, 04:25:24 PM »
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!
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!
63
Programming / Re: Converting UTF-8 data from web service
« on: September 29, 2020, 07:23:53 PM »
Well, that was too simple - all I had to do was switch the position of UTF8 and ASCII in the CVS function. I'm a victim of over-thinking the problem! Thanks for getting me turned around, Ken!
And thanks for the mock up of the TRANSLATE code, Devon. I had planned to use translate for the very reason that you mentioned (it allows multiple values to be translated), but just couldn't figure out how to get the source values.
And thanks for the mock up of the TRANSLATE code, Devon. I had planned to use translate for the very reason that you mentioned (it allows multiple values to be translated), but just couldn't figure out how to get the source values.
64
Programming / Converting UTF-8 data from web service
« on: September 28, 2020, 06:07:01 PM »
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?
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?
65
Programming / How to get Filelength for an open serial file
« on: March 10, 2020, 10:35:05 AM »
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
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
66
Programming / Re: White space in XML is consolidated
« on: March 09, 2020, 10:16:00 AM »
Thanks, Mike!
67
Programming / White space in XML is consolidated
« on: March 05, 2020, 09:10:25 AM »
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?
-}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?
68
Programming / 'PEN' width when printing to *PDF* versus *WINPRT*
« on: February 20, 2020, 10:27:14 AM »
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!
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!
69
Programming / FIN(x,"filelength") returns a negative value
« on: October 21, 2019, 11:02:11 AM »
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
-}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
70
Language / Re: PXPlus support for SNI with TLS1.2
« on: August 27, 2019, 05:39:41 PM »
Mike, do you know if PXPlus includes the port in the SNI information? For example, if I open [tcp]www.contoso.com:443, does PXPlus set the SNI-Host as "www.contoso.com" or "www.contoso.com:443"?
71
Programming / Re: [TCP] open fails, but curl works
« on: August 20, 2019, 04:07:14 PM »
FYI to all - the problem was the network speed. Some email sync was killing the network. They changed the routing on the network so that our PXPlus server used a different gateway, and the problems disappeared instantly.
72
Programming / Re: [TCP] open fails, but curl works
« on: August 20, 2019, 11:21:36 AM »
Devon - Thanks for that. I did the 'which openssl' and found "libssl.so.10 => /usr/lib64/libssl.so.10", so looked in the /usr/lib64/ directory (instead of /lib64/). The libssl and libcrypto links were there. So, that resolves my concern about how this could ever work in the first place.
Allen - We tried the 'yup update libssl', but it says that's not a valid package. So we did 'yum update openssl', and it did update the libssl files. But, that didn't resolve the issue. I suspect there may be something else blocking the connections from S1/S2.
I went back to the P1 (bad) server, and ran the test program in a loop, and found that it is actually connecting occasionally now! (about 25% of the time). Over the last few days, we haven't been able to connect at all, but they did change some network settings/hardware yesterday since their network speeds were as low as 32kbps (ouch!) , and that seems to have had an effect. At this point, I'm going to assume that the network issues are the cause, since the fact that we can occasionally connect indicates that the PXPlus/Linux installation is correct.
Alllen, Mike, and Devon - Thanks for all of your input on this!
Allen - We tried the 'yup update libssl', but it says that's not a valid package. So we did 'yum update openssl', and it did update the libssl files. But, that didn't resolve the issue. I suspect there may be something else blocking the connections from S1/S2.
I went back to the P1 (bad) server, and ran the test program in a loop, and found that it is actually connecting occasionally now! (about 25% of the time). Over the last few days, we haven't been able to connect at all, but they did change some network settings/hardware yesterday since their network speeds were as low as 32kbps (ouch!) , and that seems to have had an effect. At this point, I'm going to assume that the network issues are the cause, since the fact that we can occasionally connect indicates that the PXPlus/Linux installation is correct.
Alllen, Mike, and Devon - Thanks for all of your input on this!
73
Programming / Re: [TCP] open fails, but curl works
« on: August 20, 2019, 10:40:16 AM »
Thanks, Allen - I'll try the yum update later and post the results.
But, on the P1 (bad) server, why would ANY secure connections ever work if the libssl/libcrypto files don't even exist?
But, on the P1 (bad) server, why would ANY secure connections ever work if the libssl/libcrypto files don't even exist?
74
Programming / Re: [TCP] open fails, but curl works
« on: August 20, 2019, 09:49:58 AM »
Well, that's interesting! The server with a problem (which I'll call P1) doesn't even have the symlinks for libssl.so and libcrypto.so, nor the files that they would normally point to!
$ ldd /usr/pxp12/pxplus
linux-vdso.so.1 => (0x00007ffeedffa000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000034cc000000)
libm.so.6 => /lib64/libm.so.6 (0x00000034cc800000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00000034ce400000)
libc.so.6 => /lib64/libc.so.6 (0x00000034cb800000)
/lib64/ld-linux-x86-64.so.2 (0x00000034cb400000)
$ ls -l /lib64/libssl.so
ls: cannot access /lib64/libssl.so: No such file or directory
$ ls -l /lib64/libcrypto.so
ls: cannot access /lib64/libcrypto.so: No such file or directory
$ ll libssl*
ls: cannot access libssl*: No such file or directory
$ ll libcrypto*
ls: cannot access libcrypto*: No such file or directory
Now, we do have 3 other servers of various ages (which I'll call S1, S2, & S3, with S3 being the newest), which also run the same PXPlus version 12 (tcb(29)=1250000). My test program fails on S1 & S2, but works on S3. So, I checked the files on all 3 servers. The symlinks are exactly the same on all three, but the target files are newer and larger on S3 (the working server)
Logs from S1/S2 (where the test program fails) are below:
lrwxrwxrwx. 1 root root 16 Sep 21 2016 /lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx. 1 root root 19 Sep 21 2016 /lib64/libcrypto.so -> libcrypto.so.1.0.1e
-rwxr-xr-x. 1 root root 449880 May 9 2016 /lib64/libssl.so.1.0.1e
-rwxr-xr-x. 1 root root 2017168 May 9 2016 /lib64/libcrypto.so.1.0.1e
Logs from S3 (where the test program works) are below. Note that the target files are larger/newer:
lrwxrwxrwx. 1 root root 16 Jun 19 2017 /lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx. 1 root root 19 Jun 19 2017 /lib64/libcrypto.so -> libcrypto.so.1.0.1e
-rwxr-xr-x. 1 root root 454008 Feb 20 2017 /lib64/libssl.so.1.0.1e
-rwxr-xr-x. 1 root root 2025760 Feb 20 2017 /lib64/libcrypto.so.1.0.1e
The fact that the problem server P1 doesn't even have the libssl.so and libcrypto.so links or targets makes me wonder if those files are even used any more since the program did work fine up until last week! Mike or Allen, can you confirm whether those links are still needed in PXPlus 12?
I'm tempted to update the target files (libssl.so.1.0.1e and libcrypto.so.1.0.1e) on the S1 & S2 servers so that they match S3, but I have no idea how to update them. Any suggestions on how or whether those files can be updated?
Again, I appreciate any feedback - it may seem minor or irrelevant, but it may trigger something I haven't looked at, and I'm really curious now to figure out what is causing this!
$ ldd /usr/pxp12/pxplus
linux-vdso.so.1 => (0x00007ffeedffa000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000034cc000000)
libm.so.6 => /lib64/libm.so.6 (0x00000034cc800000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00000034ce400000)
libc.so.6 => /lib64/libc.so.6 (0x00000034cb800000)
/lib64/ld-linux-x86-64.so.2 (0x00000034cb400000)
$ ls -l /lib64/libssl.so
ls: cannot access /lib64/libssl.so: No such file or directory
$ ls -l /lib64/libcrypto.so
ls: cannot access /lib64/libcrypto.so: No such file or directory
$ ll libssl*
ls: cannot access libssl*: No such file or directory
$ ll libcrypto*
ls: cannot access libcrypto*: No such file or directory
Now, we do have 3 other servers of various ages (which I'll call S1, S2, & S3, with S3 being the newest), which also run the same PXPlus version 12 (tcb(29)=1250000). My test program fails on S1 & S2, but works on S3. So, I checked the files on all 3 servers. The symlinks are exactly the same on all three, but the target files are newer and larger on S3 (the working server)
Logs from S1/S2 (where the test program fails) are below:
lrwxrwxrwx. 1 root root 16 Sep 21 2016 /lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx. 1 root root 19 Sep 21 2016 /lib64/libcrypto.so -> libcrypto.so.1.0.1e
-rwxr-xr-x. 1 root root 449880 May 9 2016 /lib64/libssl.so.1.0.1e
-rwxr-xr-x. 1 root root 2017168 May 9 2016 /lib64/libcrypto.so.1.0.1e
Logs from S3 (where the test program works) are below. Note that the target files are larger/newer:
lrwxrwxrwx. 1 root root 16 Jun 19 2017 /lib64/libssl.so -> libssl.so.1.0.1e
lrwxrwxrwx. 1 root root 19 Jun 19 2017 /lib64/libcrypto.so -> libcrypto.so.1.0.1e
-rwxr-xr-x. 1 root root 454008 Feb 20 2017 /lib64/libssl.so.1.0.1e
-rwxr-xr-x. 1 root root 2025760 Feb 20 2017 /lib64/libcrypto.so.1.0.1e
The fact that the problem server P1 doesn't even have the libssl.so and libcrypto.so links or targets makes me wonder if those files are even used any more since the program did work fine up until last week! Mike or Allen, can you confirm whether those links are still needed in PXPlus 12?
I'm tempted to update the target files (libssl.so.1.0.1e and libcrypto.so.1.0.1e) on the S1 & S2 servers so that they match S3, but I have no idea how to update them. Any suggestions on how or whether those files can be updated?
Again, I appreciate any feedback - it may seem minor or irrelevant, but it may trigger something I haven't looked at, and I'm really curious now to figure out what is causing this!
75
Programming / Re: [TCP] open fails, but curl works
« on: August 20, 2019, 08:22:12 AM »
Allen, I was wondering about the symlinks myself, since I know this used to be a more common problem when updating the OS. But, I can't remember or find any info on where to check for the symlinks used by PXPlus. If you have some pointers, I'd appreciate it!