I'm sorry, but off the top of my head I cannot remember which OpenSSL was supported by version 12.5.

Generally, on Linux, PxPlus uses the OS installed version of OpenSSL however there are changes within the OpenSSL interface that limit which version can be used without code changes within the PxPlus kernel.

PxPlus, like PHP, runs server side thus the answer is no, you cannot directly access JavaScript variables from PxPlus.

Below is a link to the same question asked about PHP where they discuss why server side processing, like PxPlus and PHP, cannot directly access JavaScript variables.

https://stackoverflow.com/questions/2379224/how-can-i-use-a-javascript-variable-as-a-php-variable

While upgrading your PxPlus would likely be your best solution, you might want to consider simply using 'curl' (or 'wget') to send your requests, especially since you said curl can connect.

Obviously it would require some coding changes but invoking curl to submit the request wouldn't be all that difficult and would remove the need to update your PxPlus to a version that supports TLS1.2 or TLS1.3.

I suspect your call to the export method is incorrect.

I did a search on the web and on this page found an example that appears to show the Export method wants the exportOptions to be passed, not a boolean.

    Dim wordExportOptions As New ExportOptions()
    wordExportOptions.ExportDestinationType = ExportDestinationType.DiskFile
    wordExportOptions.ExportDestinationOptions = dfDestinationOptions
    wordExportOptions.ExportFormatType = ExportFormatType.WordForWindows
    wordExportOptions.ExportFormatOptions = Nothing
    
    rd.Export(wordExportOptions)

Have you tried setting 'VAL$ of the *VARIANT object then changing its type?

->def object v,"*variant"
->v'val$="false"
->?v'val$
false
->print v'type$
S
->v'type$="B"
->print v'val
 0
->v'val$="true"
->print v'type$
S
->v'type$="B"
->print v'val$
-1As per the docs, setting the type will cause the *VARIANT to properly convert the value.

The routine may require that you explicitly pass a boolean.  If so you can likely define a *VARIANT object, set its type to boolean and value then pass that.

Here is some information on *VARIANT

https://manual.pvxplus.com/PXPLUS/Automation%20in%20PxPlus/PxPlus%20COM%20Interface%20Extensions/Overview.htm#variant

You should just be able to disable the 'NE' and then re-enable it around the function call. That being said, I confirmed the operation of 'NE' using the following Object and test programs:

Object (with error cascading):
  def class "test"
 !
 ! Method
 !
  function method$(a$)
  enter a$
  x$=_obj'subMethod$(a$,err=CascadeErr)
  return x$
 !
 CascadeErr:
  exit err
 !
 ! Submethod
 !
  function subMethod$(a$)
  enter a$
  if a$="bad" \
   then exit 11
  return ucs(a$)
 !
  end defTest Program:
  oTest=new("test" for program)
  set_param 'NE'=0 ! Default setting
  gosub DoTest
 !
  set_param 'NE'=1
  gosub DoTest
 !
  end
 !
 DoTest:
  print "--------",'LF',"Test with 'NE'=",prm('NE')
 !
  print oTest'method$("good")
  print otest'method$("bad",err=RptErr)
  escape ! Should not get here
 !
 RptErr:
  print "Error exit taken"
  return
When I ran this I got the following:

->run "test
--------
Test with 'NE'= 0
GOOD
Error exit taken
--------
Test with 'NE'= 1
GOOD
Error exit taken

If you remove the ERR=CascadeErr from the object the error occurs if running with 'NE' enabled:

->run "test
--------
Test with 'NE'= 0
GOOD
Error exit taken
--------
Test with 'NE'= 1
GOOD
0007 LET x$=_obj'subMethod$(a$) ! ,err=CascadeErr)
Error #11: Record not found or Duplicate key on write

---

I would strongly recommend you use the ERR= branch to detect if a item is missing.  The return value of a null string ("") doesn't let you know if the value is undefined versus defined explicitly in the JSON as "".

Generally internal errors being reported by objects or subprograms should be cascaded back to the user application.

I suspect that the json object is making some form of internal call that itself is returning an error that is not being properly cascaded back to your application.  This means if the 'NE' system parameter is set your application will fail with an error inside the object.

Normally when creating an object for which you anticipate returning an error from, if you need to invoke another method, object or subprogram that can return an error, you should explicitly provide an error trap that itself invokes an EXIT ERR.  This should allow the error condition to be passed back to your application regardless of the setting of 'NE'.

For Example:

Method1:
  ENTER A$,B$
  X$=_obj'SubMethod(A$, ERR=CascadeErr)
  ...
CascadeErr:
  EXIT ERR

Do you enable the 'NE' system parameter? 

The problem you are having sounds a lot like the error is being generated in the object and it may be assuming that the error will be cascaded back up the stack which it would be if the 'NE' parameter is not enabled.

You are most welcome.

There are any number of ways to do this using the PxPlus charting facility. You simply need to define the data set you want charted using the Nomads Query system and the type of chart and settings.  The system will do the rest. 

The charting utility can create charts in a couple of formats such as a fixed image (JPG/PNG) which you can embed in your web page, or it can create a HTML page that you can use in an iframe or directly copy into your pages.

If using Webster+ you can also use the [chart] short code to automatically embed a chart.  (ref: https://manual.pvxplus.com/PXPLUS/Webster/Short%20Codes.htm#chart)

Using Webster+ you can also assign events to the chart so that the user can use it to drill down to the underlying data.

You could also use the *OBJ/CHART routine to create the chart directly from your code and then embed/use the output (JPG, PNG or HTML)

The issue might be a missing end of line terminator in the data.

Using RCD the system assumes the input contains a proper end of line terminator which is 0A on Linux, but 0D 0A on Windows.  If there is no terminator an error may be generated since the pipe will return EOF status and the record will be considered incomplete.

Try using a read record with a SIZ= small TIM= value to see what CURL is actually returning.

If running on Windows, instead of using *plus/web/request try calling *wininet which is a Windows only alternative that uses the Windows internet DLL (wininet.dll).

The calling sequence is the same as *plus/web/request.

The extra information that Explorer shows generally comes from reading the physical file.  It extracts various pieces of information based on file type. Attributes such as address and subject are simply being determined based on the contents of the file and are not truly physical file attributes.

Explorer uses the file suffix and contents to determine how to extract the information based on known file types.

You could replicate that functionality however that would require to know how to parse each of the file types you encounter.

Hi Phil,

Since retiring from PVX Plus Technologies I have been offering my services to assist people with PxPlus application development.  While I am not looking for full time work, I'm available to assist both developers using PxPlus or with other software development issues.

I don't know exactly how long I will continue to offer my services but I'm not in any hurry to put software development/consulting completely behind me.  I still enjoy a good challenge.