I've sorted string arrays using this logic.  The sort is all done in one line (line 40).  The rest of this is just setup for demo purposes.

0010 BEGIN
0020 LET data$="Red,Orange,Yellow,Green,Blue,Indigo,Violet,"
0030 DIM a$[1:POS(","=data$,1,0)]; READ DATA FROM data$,SEP="," TO a${ALL}
0040 READ DATA FROM SRT(REC(CPL("iolist a${all}"))) TO a${ALL}
0050 PRINT "Raw Data:    ",data$
0060 PRINT "Sorted Data: ",REC(CPL("iolist a${all}"),SEP=",")


I like Stephane's approach since it's simple and clean because the 'totalSize' tells you how many records are in each segment. 

I generally use WHILE/WEND, since I've never encountered any JSON that included a record count.  When using the WHILE/WEND, you just need to identify a field that will occur in each new segment to indicate a new record.  In this case, the "Id" field serves that purpose.  In case you run into a scenario where the record count ("totalSize") isn't included or isn't reliable, the bit of code below is an example of how to read through the JSON without relying on a record count.

0010 BEGIN
0020 LET json$=$7B22746F74616C53697A65223A312C22646F6E65223A747275652C227265636F726473223A5B7B2261747472696275746573223A7B2274797065223A224F72646572222C2275726C223A222F73657276696365732F646174612F7635342E302F736F626A656374732F4F726465722F383031324430303030303136787135514141227D2C224964223A22383031324430303030303136787135514141222C224F726465724E756D626572223A223030303030313030222C224372656174656444617465223A22323032322D30322D32315431333A31333A30312E3030302B30303030222C224F726465724974656D73223A7B22746F74616C53697A65223A312C22646F6E65223A747275652C227265636F726473223A5B7B2261747472696275746573223A7B2274797065223A224F726465724974656D222C2275726C223A222F73657276696365732F646174612F7635342E302F736F626A656374732F4F726465724974656D2F38303232443030303030314767563551414B227D2C224964223A2238303232443030303030314767563551414B222C2250726F6475637432223A7B2261747472696275746573223A7B2274797065223A2250726F6475637432222C2275726C223A222F73657276696365732F646174612F7635342E302F736F626A656374732F50726F64756374322F303174324430303030303530694B72514149227D2C2253746F636B4B656570696E67556E6974223A223235227D2C225175616E74697479223A352E302C22546F74616C5072696365223A313235302E307D5D7D7D5D7D$
0030 DIM LOAD test${ALL}=json$
0040 LET pf1=0
0050 WHILE 1
0060 LET pf1$="records."+STR(++pf1)+"."
0070 IF NOT(DIM(INDEX test$[pf1$+"Id"])) THEN BREAK
0080 PRINT test$[pf1$+"Id"]
0090 PRINT test$[pf1$+"attributes.type"]
0100 PRINT test$[pf1$+"attributes.url"]
0110 PRINT test$[pf1$+"OrderNumber"]
0120 PRINT test$[pf1$+"CreatedDate"]
0130 !
0140 LET pf2=0
0150 WHILE 1
0160 LET pf2$=pf1$+"OrderItems.records."+STR(++pf2)+"."
0170 IF NOT(DIM(INDEX test$[pf2$+"Id"])) THEN BREAK
0180 PRINT test$[pf2$+"Id"]
0190 PRINT test$[pf2$+"attributes.type"]
0200 PRINT test$[pf2$+"attributes.url"]
0210 PRINT test$[pf2$+"Product2.attributes.type"]
0220 PRINT test$[pf2$+"Product2.attributes.url"]
0230 PRINT test$[pf2$+"Product2.StockKeepingUnit"]
0240 PRINT test$[pf2$+"Quantity"]
0250 PRINT test$[pf2$+"TotalPrice"]
0260 WEND
0270 WEND


Splitting the program to reduce the number of variables seems to have resolved the issue.  Thanks to everyone for all of your suggestions!

One additional question:  The program is importing a lot of JSON data, and some of the JSON files are fairly large.  I'm reading them into an array using DIM LOAD arr${all}=json$, and these arrays sometimes have 20,000+ elements. 

Are all of the individual elements of the array equally affecting the variable table?  Ie: does the variable table just consider "arr${all}" as 1 item, or does it track each element (arr$[1] ,arr$[2], arr$[3],...) separately?  Also, since these array elements have named fields, (eg: arr$["field.1.name"]), I'm assuming that these named fields also may affect the variable table.

I'm working on re-designing the program to avoid this problem, while also allowing room for future enhancements.  If the JSON arrays are having a huge effect on the variable tables, I may need to change the routines that request the JSON to request smaller chunks of data.

Now this is getting interesting, since it doesn't seem to be a memory problem.

I followed all of the suggestions given:  Boosted the memory to 64megs, turned on the 'IZ' parameter to ignore memory limits, and set the '-B' flag on the trace channel.  The process is still dying at random points.  In my for most recent tests, the failing line of code was: trying to CLOSE a channel, PERFORMing a program/line_label, READing a channel to a data file, and setting some variables using an IOLIST.  The only thing in here that is remotely unique is the last item, which does LET KEY$=REC(IOL=KEY_IOL,SEP=$$), but that same code is executed multiple times in the program without a problem.

Since the 'IZ' parameter is set, it would seem to rule out this being a memory issue.

The program is large, and recently got larger.  Mike, we had discussed program size and variable name table size limitations in an earlier thread (https://forum1.pvxplus.com/index.php?topic=887.msg2983#msg2983).  I just checked the variable name table length using the info you provided in that thread, and the value returned is 29,015.

Is it possible that the variable name table size is causing this crash?  Any other suggestions on figuring out exactly what is causing this to crash?

Stephane - I thought about using the 'IZ' switch, but I'd really rather figure out the problem before hitting it with that really big hammer of allowing unlimited memory.  I suspect that there is a memory leak somewhere (like using a "local" variable multiple times in a single routine, which I've seen in the past), and I'd rather find the problem if I can.  If not, I'll try the 'IZ' parameter to see if that helps.

Jason -  Thanks for that tip on buffering.  I don't have the -B switch turned on for the channel, so I'll try that to see if it gives me any different results.

I have a large program (406k) that recently started dying, very unceremoniously!  No error traps were triggered even though an error handler program and a SETERR were in place.  I added traces to the program, and found that it was dying at completely random places each time.  This leads me to believe that it was a memory issue (ie: ran out of memory). The program runs on Linux as a cron process, and the startup environment allocates 32m of memory to all of the processes.  I added a SET_PARAM 'SZ'=64000 into the routine to increase the available memory, and that seems to have resolved the problem.

However, I'd like to see if there is a better way to handle this.

The program is large since it encompasses several CALLed routines, and it will CALL itself several times using line labels.  (eg:  call PGN+";line_label",a$,b$,c).  I suspect that each time it calls itself, a new copy of the (large) program is loaded into memory, thus using up a lot more memory.  Some of the called routines also call other routines in the same program, so a call which is several levels deep could be loading several copies of the program into memory *if that is how the CALL command works*.

My question is: 
- When a program CALLs itself, does it load a new copy of the program into memory?
- And if so, will using ADDR to lock the program in memory prevent a new copy of the program from being loaded into memory?  (and thus reduce my need to allocate additional memory to the session)

Thanks in advance for any info you can provide!

Thanks for your help and explanations of this, Jane.  I've created a support ticket (687435) for your purposes, but the issue is resolved to our satisfaction