On Mon, 23 May 2005 10:25:17 -0300, Shmuel Metz (Seymour J.) wrote: >Yes, because all the way back to the early days of OS/360, a main >program was just another subroutine with a specific type of PLIST. I >know of no IBM documentation that ever suggested a limit of 100 >characters for the program. If a batch program calls a second program, >that second program is still running batch. > >>The program was defined to run in batch. > >And when a program running in batch calls it, then it *is* running in >batch, even if the parm string is longer than 100 characters.
This brings up a counterargument I had considered a couple of weeks ago for providing simulated OS support for such an APAR-liable change: Why not, instead, create a single simple program that can (and does) read from a parameterized file, pulling the contents into storage as the downstream program's XPARM= data, setting R1 to point to the newly engorged PARM string? I see fewer APARs as an immediate result. The obvious "bad" thing is that the SMF type 30's would not show the XCTL- ed to program name... and one might offer a handy fix to that, too, if pressed. (Maybe CSRL16J would be better than XCTL here; I don't have clear specs for the program.) The only remaining sniggle is that those programs that Gil is so interested in getting vendor support of PARM>100 would still claim it is via unnatural conditions. So maybe if Don, Greg, Jim (et al) would just state that "it must be so" this whole argument could become moot? A single, simple program front-end could offer the parm length granularity, provide for any file type source for the parm data, and even be shipped in a PTF. (Why wait?) -- Tom Schmidt Madison, WI (Who really says "moot" anyway?) ---------------------------------------------------------------------- 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
