Loren,

At the risk of decreased performance, you could turn off output buffering.

->! Sample one
->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
->erase "temp.txt"


->! Sample two
->serial "temp.txt"
->open lock(1)"temp.txt"
->print (1)'-B',
->print(1)dim(100,"X")
->print fin(1,"filelength")
101
->close(1);open(1)"temp.txt";print fin(1,"filelength");close(1)
101
->erase "temp.txt"

HTH

Mike,

This is running on RedHat and the file is being accessed locally.

The supplier recommended replacing the problem file with an fresh empty copy from the installation media.  Since the corruption is happening frequently, we are instead renaming the problem file and recreating it with this keyed directive:

keyed file_name$,"[1:1:2]+[2:1:3]+[3:1:10]+[4:1:6],[1:1:2]+[5:1:12]+[6:1:1]",,-256

Mike,

We have this message coming up on a problem file quite regularly.  This particular file tracks locking activities, so it can be erased and recreated without data loss.

However, even after erasing and recreating the file, after a few hours, the file again shows data corruption problems.  We have been working to programmatically handle the data problems we can capture, but cannot control this message.

Since we cannot find a cause for the corruption, we are looking for a way to disable the "Correcting missing key" message.

Mike,

What does an "application integrity check" entail?

Hello,

Recently, we have started seeing PxPlus messages indicating a missing key has been corrected.  The exact message has PxPlus at the header and shows the filename along with the statement "Correcting missing key" with an OK and Cancel button.

The message appears to be hard coded in the pxplus executable and it is causing concern with our users.

What can be done to determine these cause of these messages?

Is there is any way to suppress them?

Thanks,

Danilo,

It is unclear whether you want to speed things up by retrieving a smaller amount of data or if you want to improve the processing speed when you retrieve a large amount of data.

Your fetch command is basically requesting the entire message. Looking at the imap spec (RFC 3501), under the fetch command, it says the TEXT part specifier refers to the text body of the message (everything but the header). You can either use a different part specifier or add the syntax to request a partial reply.  Reading and understanding what is in the specification can help you tune the conversation so you get only what you want.

To make your retrieval more efficient when working with the large messages involves fixing the slow processing. Alan's suggestion to use += helps. However, you should also make sure you are working with good size communication blocks. That means for each read, X$ should be at least 1k in length to minimize how much work your loop is doing.

Jeff,

Check out the 'LC' system parameter.  That and some other mixed case logic determines how variables appear when a program is listed.  Generally speaking, I would not worry about it.

Jeff,

If you want to try putting a fix in *plus/web/request, give this a try:

A few lines ahead of your error, you should see a line where r$ being cleared (just before the while loop).  Try adding o=0 (reset variable o to zero) to that line.  The line will then look like this:

r$=""; o=0

Basically, this ensures o is reset each time the while loop is encountered.  In the normal flow, that is not very critical.  However, if a redirect is encountered and the read record inside the while loop times out, I could see that causing the error 47.

HTH

Give this a try:

0010 ! begin
0020 x$="0000000001000000"
0030 print dec($00$+fn_atob$(x$))
0040 end
0100 FN_BTOA:! ^100
0110 ! Function which converts ASCII data to its binary representation
0120 def fn_btoa$(local x$)=hta(tbl(hta(tbl(hta(x$),"0123456789ABCDEF",
0120:$00010203101112132021222330313233$)),"0123",$00011011$))
0200 FN_ATOB:! ^100
0210 ! Function which returns ASCII value corresponding to a string a binary data
0220 def fn_atob$(local x$)=ath(tbl(ath(tbl(ath(x$),$00011011$,"0123")),
0220:$00010203101112132021222330313233$,"0123456789ABCDEF"))

Hello,

I am working with *web/request to interface with an https server.  Most of the time everything works great.  However, on occasion it throws an error 0 reading the server response.  At that time, the value of msg(-1) is this:

Short read of 1536 bytes from address 553615872 (fh: 15 seg: 116 page: 553645568 64seek: 000000368cde2a00) wanted type 128 Max 2014982656 (err/ret=2/2)

I would like to find out what is causing the request failures and can see that specific message comes from PxPlus.  What does it mean?  Is it related to the request failures?

Thanks,

Chris Kukuchka
Sequoia Group, Inc.

Allen,

Have you looked here:

https://home.pvxplus.com/downloads/pxserver/

Modern versions of PvxPlus have built in zip library handling capabilities. Using those tools, you could do something like this:

1) run a server side program that creates a zip file containing your images

2) transmit the zip file to the client

3) call a client side program to extract the images from the zip file and place them where needed for your application

Keep in mind, this is mainly helpful on slow networks.  The compress/uncompressed time is often burdensome when running on a fast network.

Print followed by parenthesis is interpreted as you passing a channel number. That means the first part of your formula (2/6374) is evaluated to zero. So the remainder of the print '-(1/6557.5)' is output to screen.

You can fix this by putting a 0+ in front of the formula:

->? 0+(2/6374)-(1/6557.5)   
.1612775690797811975E-03   

Another option is to use a unique variable to avoid conflict.  Something like this:

def fnget_extension$(local filename$)=xeq("functions;get_extension",fnget_extension_ret_val$,filename$,fnget_extension_ret_val$)

Even better is to wrap these functions into a global object so you do not have a maintain a bunch of scattered local functions and their associated iolists throughout your application.