Peter, it is true that some code out there may have these limitations/problems, but until that code is changed, the length limit can just be a documented restriction.
Some of the potential problems an existing target routine might have with an extended length parameter are - It provided an area via DS of 100 characters, "knowing" that the limit was 100, and then did an EX (execute) of an MVC to move the parameter string, using the length in the halfword. Unfortunately, if the length is (for example), 256, this would overlay the next 156 bytes - It did some operation (MVC, TRT, whatever) that is limited to 256 characters which works fine when the limit is 100, but if the routine was passed 257 characters of data, it might process that as 257 mod 256 characters in some ways.
The 100 char limit exists only in JCL. Since any program which can be invoked from JCL can also be LINKed or ATTACHed, allowing the caller to pass a parm of any arbitrary length, I expect that most programs accepting parm data already accomodate over 100 or at least check for 100. I can see that parm length over 256 might be a more common issue, but that is most likely to result in a parm error message instead of a nasty bug.
So I vote for just extending the length.
-- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
