Loren,
If you suspect a problem with memory limits, you also need to consider the limit that an individual session can use.
Check prm('SZ') and prm('IZ').

If prm('IZ') is off, I would turn it on and see if the problem goes away.
If it does, then you can decide if you want to leave it on or if you instead prefer to increase the prm('SZ') to allow each session more memory, but not unlimited.
If it doesn't, back to square one.

Anyone know of of a company in Reno, NV that provides good hardware and network support?  I know of a company that is relocating to Reno that is looking for those services.  If anyone can recommend someone, please let me know.

I modified one line of code in '*cmd/system/ver' a long time ago to account for this.

Orig:
if all_ver then goto NEXT_VER

I went back and forth between two options:

if all_ver then if mod(prg_ver,20)=0 then escape end_if ; goto NEXT_VER
or
if all_ver and prg_ver<20 goto NEXT_VER

Just depends on if you want it to only show 20 versions or if you want it to escape after printing 20 versions.  Having it escape is a nuisance, but allows you to either RUN to see more or END.

Thank you Devon and Mike.

I was able to recover the file over the weekend, but tried your solutions anyway out of curiosity and to verify things as my method of reading through the file with IND= didn't appear to get all records.  The original file reported that there were 8828949 records, but I only recovered 8828387.  I wasn't sure if I lost 562 records or if the original record count was inaccurate due to the corrupt key tree.

Yes, the keyed load worked when run directly on the server as opposed to WindX.  It reloaded 8828387 keys, which was the same number of records I recovered while reading through the file with IND= (but keyed load did it in under 10 minutes with the file locked as opposed to the couple of hours my method took).

The fixvlr2 utility did report a bunch of "Bad key len" errors, but recovered the same 8828387 records and took 30-40 minutes.
I assume there were 562 records skipped due to "Bad key len".

I'm sure I lost 562 records now, but now know we recovered everything we could.
Thanks again for your help.

I may have a solution...  reading through the file with IND= to ignore the corrupt key tree.
Any other suggestions welcome as I'm not positive yet.

I have a 4.5 GB enhanced VLR file that has a corrupt key structure (error 105).
When trying to repair it using the 'keyed load' directive, it fails with this message:  "Reception error...  Crc Recvd:0FEA...  Computed:F3D7".  screenshot attached.

I also tried using *UFAR, but the original file says it has 8.8 million records and the restructured file from *UFAR only has 2.4 million records.
This post indicates that *UFAR shouldn't be used on files over 2GB and that *fixvlr should be used instead:
     https://forum1.pvxplus.com/index.php?topic=124.new#new
However that utility doesn't exist on my version of PxPlus.

Can the *fixvlr utility be provided to me and if so, will it work on PxPlus 11.65?  Is there another way to fix this file?

RHEL 7.6
PxPlus 11.65

Thanks for any help you can provide.

A single channel...

open lock (5)"/tmp/crashlog"
print (5)'-B' ! Now anything sent to this channel will be written to disk immediately instead of buffered

Loren,
You mentioned that that you added traces to your program and that it was dying at random places.

If you are using settrace or logging something to a file, I just wanted to confirm that you are turning off buffering on that file channel with the '-B' mnemonic.  Otherwise, it might appear to die at random places just because results were buffered and not written to disk before the process crashed.  Fair warning... it will slow down processing.

Jim,
Assuming prm('xk')=1...  Limit for your file is 32 GB.
See here:
https://manual.pvxplus.com/PXPLUS/parameters/xk.htm

While I don't know the answer to your specific question, have you considered just using a normal file and just writing without a record/iolist?  I believe your write syntax will be the same as you are using now to write to your SORT file  You will need to use a bigger block size to exceed 8 GB.  Since you are using EFF files, this should allow it to grow to 64 GB:
CREATE TABLE "/usr4/gg",32,BSZ=8,SEP=$0A$

Disregard... Found it.
https://manual.pvxplus.com/PXPLUS/parameters/xk.htm

In the manual, both the 'keyed' and 'create table' directives show file size limits for EFF files.  Where can I find similar limits for VLR files?
My problem is that I'm getting an error 16 when writing to a VLR file.  Current file size is 32 GB and the block size is 4K.  I assume 32 GB is the limit for that block size, but would like to confirm that is the problem.  I'd also like to know file size limit for different key block sizes so I can pick the right block size for my rebuild.

Pages with file limits for EFF files only (not VLR):
https://manual.pvxplus.com/PXPLUS/directives/keyed.htm
https://manual.pvxplus.com/PXPLUS/directives/create_table.htm

PxPlus 1165 on RHEL 7.6.

Paula,
Looking at _ext\system\get_pswd, it appears that you can set %z_password prior to opening the file and you won't be asked for the password.  Assuming these files have the same password, you could have your utility program set that variable prior to checking files.

Alternatively, if you are only looking to see if the file exists, you could do this:
open(hfn,ISZ=-1) "filename"

Jeff,
There may be a better way, but just save the program below and run it.  It should return the contents of line 10.
The called routine is simply a modified version of *pg.cnv, but serves your purpose of simply grabbing a specific line instead of converting the program.

0050 call pgn+";get_line","PROG1","",10,line$
0060 print line$
0090 end
0500 ! ^500
0510 GET_LINE:
0520 enter prog$,passwd$,line,line$,err=*next
0530 line$="",p$=pgn
0540 x$=lst(pgm(tcb(4)+1)); execute x$(5),err=*end
0550 load prog$; password passwd$; line$=lst(pgm(line)); load p$; goto GET_LINE_EXIT
0560 GET_LINE_EXIT:
0570 exit

Jeff,
I think you are saying that the the new program is created, but it is compiled PxPlus code rather than a text file.
If that is the case, you just need to make sure that there is an existing text file there before you call *pg.cnv.  If there isn't, it will create a PxPlus program.

You will need to add error trapping, but try this:

erase "s:\jeff\jeff.txt"
serial "s:\jeff\jeff.txt"
call "*pg.cnv","PROG1","s:\jeff\jeff.txt"