Jeffrey

The issue may be related to invalid data in your file.  PxPlus doesn't, by default, validate that the data you write into the files matches the data dictionary specifications. On the other hand, ODBC access relies on the fact that the data adheres to the specifications.

What might be happening is that there is a field whose contents is larger than expected thereby causing a memory access problem.

To check this try running the Verify Data option on the Database export utility.  Basically pretend you are going to export your data to a database, launch the export utility from the data dictionary and select "Verify Data".  It should read through your file and check that the file contents adheres to the Data Dictionary specifications.

Good luck

This is actually a Linux issue.  Record locking is done by placing a Write lock against the file however Linux doesn't allow us to add a write lock to a read only file.

Also, since the EXTRACT directive can be used to position the file PxPlus could not return the error. A fairly common coding technique looking to read records starting with a known record key is to use an EXTRACT to the desired starting record then create a loop doing a standard READ next.  The EXTRACT positions the file such that a subsequent read next will return the extracted record making the coding cleaner.

The CMD_STR$="U...." loads the designated panel passing it all the current variables and leaves both panels active -- that is the controls on each panel are all active and they share a common environment (variables).

The PROCESS command is basically like a CALL.  The current panel will be deactivated and panel designated will be loaded and displayed with its set  of variables.  Only controls on the new panel will be active.  When the user closes the panel control will return to the program/panel that initiated the PROCESS directive.  Now you can pass values on the PROCESS command, these will be mapped into the variables ARG_1$, ARG_2$, ... in the new panel using the same rules as a CALL directive in terms of passing arguments.

Looks like Sage's SSL certificate is bad.  You need to contact them.

It sure sounds like there is something wrong with your setup.  The PROCESS definitely should run faster than a spawn.

One difference between the PROCESS vs spawn is that with the spawn you are starting from a clean environment whereas the PROCESS will inherit the environment from the menu. 

I would suggest you try enabling a timed trace on the PROCESS to see what might be causing the issue.
I might also make sure you aren't doing anything such as turning off turbo mode which would also explain the fact that general performance seems to be suffering when using PROCESS.

A PROCESS directive should take less time than spawning.   Perhaps the SHOW(-1) is causing a issue?

Jean,

I'm away at the moment, but I will contact you next week with some tips/ideas on how to get started.

The easiest solution might be to just dynamically define unique FID values for every process.  You can then use the SETFID directive to set the session FID value.

FID(0) values can be up to 12 characters long -- assuming your code will accept that length. 

There are any number of ways you could generate the FID values perhaps using a specific range for each workstation and a control file where you can lock records to assure uniqueness of FID.

In theory you might be able use the process ID as a FID(0) value which would assure uniqueness.

Another simple solution, which will work when using older PxPlus, is to predefine the JSON structure then load the values:

For example, we can preload the numeric JSON elements with zero values.  Only the numeric values need be declared.

->x$="{'Balance':0}"
->dim load json$=x$

The above will create the array json$ with add the element Balance marked as numeric.  Now you can define the various values you need.

->json$["Name"]="Mike King"
->json$["Addr"]="123 Main St"
->json$["Balance"]="123.45"
->json$["Email"]="mike.king@bbsysco.com"

When the Array is converted back to JSON the Numeric indicator for Balance is remembered.

->print dim(list edit json$)
{
  "Addr":"123 Main St",
  "Balance":123.45,
  "Email":"mike.king@bbsysco.com",
  "Name":"Mike King"
}

Actually you can get the IOLIST for the Nomads screen definition file from the Nomads object.

It can be accessed by IOL=%nomads'_lib_iol$

My suggestion would be to upload to a temporary directory then check the file size and contents using a virus scan and only then copy it to the proper location.

Technically there is no 'sure fire' way to control what the user is uploading.  For example while you might want to restrict a user to only upload a JPG or PNG, they could simply rename a infected file to have a .png or .jpg suffix.  Only once the file is uploaded can you confirm its contents. 

For JPG, PNG and BMP files you can read the first few bytes of the uploaded file to confirm the file type, then run whatever anti-virus software you want on the file before accepting it.  For example if you use Avast as your anti-virus the command ashCmd.exe can be used to scan a specific file and report its findings.

Here is a simple web program that will return a PDF file:

0010 OPEN (HFN)"*pdf*;file=output.pdf"
0020 FOR i=1 TO 20
0030 PRINT (LFO)"This is line ",i
0040 NEXT i
0050 CLOSE (LFO)
0060 OPEN (HFN,ISZ=-1)"output.pdf"
0070 READ RECORD (LFO,SIZ=1000000)contents$
0080 CLOSE (LFO)
0090 WRITE RECORD (%print_fn)contents$
0100 LET %Content_type$="Application/pdf"
0120 END

It creates a PDF file on "output.pdf" with lines 1 thru 20, sets the content type, and returns the PDF file contents.

You should be able to save this on your PxPlus Web server in the document root directory as something like pdf.pxp then call up the URL.  It will display the PDF.

Obviously in production you would dynamically create the PDF output file name and delete it when done.

Let me know if you have any issue with setting the content type.  It should work.

As for me, while we have left PVX Plus Technologies, I am enjoying semi-retirement.  Doing some ad-hoc consulting in order to keep active and busy.

Anyway, if you need help feel free to contact me and we will see what we can do.

Another thought, if the web server is Apache you might be able to use ProxyPass (and possibly ProxyPassReverse) to have the web simply re-route the specific request to your backend PVX Plus web server. 

This could be used to forward to whole request and return the result or to forward a request for the resultant PDF file and simply leave the PDF files on the PxPlus server.

There is something similar available for IIS if needed.

How is the website forwarding the request to the PxPlus web server?  If its by a standard web request you likely could have the PxPlus web server application respond with the contents of the web file and set the content type to "application/pdf".  Basically open/read the resultant PDF file as a binary file and write it to %PRINT_FN.

Assuming the webs site forwards the response that it receives along with its headers the PDF should get displayed.