Last week, I was having an issue with STRREP and the 4000 character length limitaton. The CTRAN function is a great substitute and doesn't seem to have the same limitation. This week, I'm trying to replace a GETTOK function that has the same problem. The character string is over 4000 characters long and includes a long concatenated list of variables (delimited by an "^" character). I was using GETTOK within a loop to break it up into individual variables like this:

You could split the string into chunks of a manageable size for GETTOK.

Make sure that if you find a substring at the end of a line, concatenate the next line to it and repeat the last GETTOK - or combine the last result with the first one on the next line.

Another option is to push the work to an RDBMS that you can connect to. Some have particularly convenient functions for stuff like this, such as being able to return a result-set of tokens as a virtual table. Of course this does mean an extra round-trip for your parameters.

Your kind of pushing a boulder up hill here. Maybe you could give an overview of what you are trying to do. Specifically why such long variables to start with, and how you plan on using the final variables your process.

One of the good users of this forum might have an alternate approach.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

My company created it's own OEM type reporting portal that fits seamlessly with the rest of our website. It has similar features to the WF portal in that the user can select fields / sorts / filters...etc. When the user hits the run button, we accumulate all choices that the user makes into a single string and pass that to the webfocus fex at runtime. In the past this wasn't an issue since the string length was under the 4000 character limit of the functions we were using, but as our clients get more complicated, that string has increased to a level where it's causing the functions (like GETTOK and STRREP) to fail. Unfortunately, some of our servers are still on 8009 and some of the newer functions aren't available like REPLACE() and SUBSTRING() and TOKEN().

Off the top of my head I would (in this order):1. Ask your portal developers to chop into multiple parameters with a size limit. On the WF side, if the parameter exists, then parse it.2. Build a WFRS Java plug-in that can take the large parameter and parse it into the desired output as the final .fex that contains -SET ...; statements.3. Build a Java Filter that overrides the getParameters[] method of the http request and break the string down into the final parameters values.

2 and 3 will work with all versions if WF so long as it is compiled with the lowest version of Java that your servers run with.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Ok, We decided to move all servers to version 8105 so we will have access to TOKEN() and SUBSTRING() which should be able to handle larger strings. Unfortunately during testing I'm having issues when running this code. It fails when it tries to use SUBSTRING to create the &parm_values variable. If you change the function to look for characters 12 to 200 it works fine, but anything over 200 and it causes an error:

Just wanted to give a heads up that we figured out that we needed to change a value in TOMCAT:

Changed the two occurrences of maxPostSize="0" to maxPostSize="-1" and restarted tomcatAfter troubleshooting some more we noticed an error with the maxHttpHeaderSize and under to two occurences of maxPostSize we added maxHttpHeaderSize="16384" and that appeared to resolve the issue when running the procedure from DevStudio and App Studio.