>Apparently the designers had the foresight to require lexical >termination of symbol names, so permitting longer symbol >names now introduces no new incompatibility; symbol names >are not assumed to be terminated by character count. Is this >true in contexts other than JCL? (And is the behavior >aboriginal?)
I don't know what aboriginal refers to in this context, but the answer to the first question is "yes". And the behavior has existed since the introduction of system symbols. >It is not OK to truncate silently. Would you even dare to suggest that >if in a JCL EXEC PARM='...&FOO....' the resulting PARM should be silently >truncated to 100 bytes if substitution were to cause it to be longer? Yes I certainly do dare. This is practical reality. If a group of customers think it is OK, then it can be OK, even if you choose to disagree, especially when it has no impact to you in the absence of exploitation. You are free not to use a function if you do not like its behavior. There is a cost vs benefit tradeoff in everything all of us do. However it is a moot case in this point because substitution is not processed as a single operation for PARM=. Substitution already is possible in PARM= using JCL symbols and those symbols do not have the value/name restriction. The system already detects that substitution causes the PARM= value to exceed 100 bytes and rejects it. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
