Re: An Alternative Modest PARM Proposal
(Tiring of people arguing in circles and getting nowhere) Let's take a poll. Suppose for the sake of argument that I had in my posession a set of system modifications which allowed specification of EXTPARM, which let you specify program parms of up to 32767 characters in length, and that you could obtain this modification for a small fee. Who would be interested in using it? Who would refuse to use it? What if you could specify in your parmlib the list of programs which could be invoked with this parameter? Would you use it then? After all, aren't we really talking about a limited number of potential uses at any given site? Take it a step further. Suppose IBM supplied this capability with the next z/OS release. Also suppose that you could enable or disable the functionality via a parmlib value as well as specify the programs that were eligible for use. Would you be interested then? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Wed, 4 Nov 2009 08:30:01 -0600, Martin Kline wrote: Let's take a poll. Suppose for the sake of argument that I had in my posession a set of system modifications which allowed specification of EXTPARM, which let you specify program parms of up to 32767 characters in length, and that you could obtain this modification for a small fee. Who would be interested in using it? Who would refuse to use it? Depends on the value of small. I'd say 65535 rather than 32767. But either is larger than practically useful. That would be about 5000. What if you could specify in your parmlib the list of programs which could be invoked with this parameter? Would you use it then? After all, aren't we really talking about a limited number of potential uses at any given site? It would certainly be useful to have one more syntactic extension in the PARMLIB member: AC=0 /* Unauthorized programs are relatively harmless. */ NAME=FRED NAME=JOE ... Take it a step further. Suppose IBM supplied this capability with the next z/OS release. Also suppose that you could enable or disable the functionality via a parmlib value as well as specify the programs that were eligible for use. Would you be interested then? We'd need to take a poll at our site; I can't make that decision alone. But I'd vote yes. But there are tradeoffs. If resources forced a choice between long PARM and symbol substitution in SYSIN, I'd take the latter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
Several JCL improvements have been discussed. From my reading of these threads, I would guess that a plurality of folks might agree on these: 1) new PARMX= keyword on EXEC PGM= - does the same thing as PARM=, but allows 100 characters - can't have both PARM and PARMX - a new keyword means that the JCL coder has to intentionally use it (and be responsible to test programs for 100 character compatability) - programs that already work 100 don't need to be modified 2) Keep JCL and PROC variables around and use them to populate an ASASYMBM table (separate from the system table) Maybe have an LE option that automatically imports these as environment variables, but non-LE assembler programs could use ASASYMBM to access them. 3) Symbol substition in SYSIN; something like: //FOO DD DATA,SUB=YES INPUT OPT=JCLVAR /* IMO, *all* three of these solve important (and independent) usability problems with JCL. A poll on IBM-MAIN is not enough - requirements need to be submitted to IBM via support center, SHARE, zBLC, etc. It would be nice if there were some consensus here; but that's too much to hope for :-) Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 3 Nov 2009 20:51:59 -0800, in bit.listserv.ibm-main you wrote: On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin paulgboul...@aim.com wrote: snip You're inconsistent in your assumptions. You appear to believe that: o Some JCL programmers won't take responsibility ... but o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be presumed to take responsibility for ensuring that the interface requirements of any program they may call are met. I strongly doubt the second of those statements. Therefore, to avoid breaking programs in unpredictable ways, the OS must be reinforced to avoid ever passing a PARM 100 characters. This must be done at the SVC level in order to preclude the programmer's loading registers and issuing the LINK or ATTACH SVC with an oversize PARM. In fact, there's no way to prevent the programmer's coding LOAD followed by BALR. Give me a program with AC=0 that doesn't check its PARM length and I'll break it. (Wanna see me make ASMA90 S0C4? I needed to use ATTCHPGM; couldn't break it with ATTCHMVS. I have a tester's temperament; you can't assume I'll always for be responsible for ensuring that a program's interface requirements, documented or otherwise are met.) http://bama.ua.edu/archives/ibm-main.html No I am not inconsistent in my assumptions, but I've obviously failed to communicate them to you. Let me try one last time. The fact that you can find programs that are well behaved in the circumstances you're talking about is not at all in dispute. But neither is it in the slightest bit relevant. Whether you choose to accept it or not, the initiator's documented interface existed long before the other interfaces you're citing (with the exception of plain old CALL) were even a developer's wet dream. Lots of horses fled the barn in the mean time. And I agree that I can't assume you will be responsible for ensuring your called program's interface requirements are met. In fact, I'm sure I can't. That's the whole point. Your tester's temperament is at odds with the stability needs of a production batch environment and I'll take a healthy sized bet that those production batch environments were there before you were, so whether you like it or not, they get grandfathered in, even if they don't play well by the rules you imagine they must. (Sorry if my architect's temperament is showing) The danger of a PARMX in JCL that passes parms greater than 100 bytes is two fold. 1. A specific JCL will have an EXEC statement that invokes the program with PARMX= without someone having tested the program to verify that it can handle that PARM length. This is sloppy programming and the installation deserves what it gets. 2. An installation will either change all JCL to use PARMX instead of PARM or require it for new JCL without verifying that the programs can handle it. Again this might be considered poor management because a mass change is made to an interface without testing. Both cases require specific action to break something existing, i.e. the JCL change. A change to existing JCL to create a PARM greater than 100 bytes in length on an EXEC statement with PARM= would still cause job failure. In one sense a more basic question is what do we see the future of the z series as being. People on other platforms look at many of the restrictions in JCL as being archaic (8 byte program names, 44 byte data set names, upper case only, and so forth). Even those coming from VSE (formerly Dumb Operating System) look askance at some of the restrictions (like not being able to handle FBA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
Authorized programs should be written to a higher standard. Above and beyond normal error checking, they should be written to prevent intentional abuse. That is the standard IBM uses when they accept APARs on their authorized programs. A malicious user can be expected to attempt to use any and all unintended means to invoke an authorized program. JCL is not the only way to invoke an authorized program. There are other means to invoke an authorized program which pass more than 100 characters. Authorized programs should already be protecting themselves from any problems which could be caused by long parameters. PARMX passing more than 100 characters would not be a new risk, although arguably easier than other methods. Regardless, if an authorized program is discovered to behave in a destructive manner when passed more than 100 characters, then you are already at risk and it should be corrected. That is what IBM does. That is what everybody should do. If you feel that PARMX would be increase the risks in your environment, then it could be controlled with the SAF (RACF, etc.) protection addendum. 1. Is there a significant number of frequently used authorized programs known to have highly undesirable consequences? I don't think so. 2. Is it likely that the PARMX proposal would have undesirable dire consequences? I don't think so. 3. Does simply making it easier to pass more than 100 characters to an authorized program, justify canning the PARMX proposal? I believe the benefits far outweigh the risks. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Craddock Sent: Tuesday, November 03, 2009 5:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: An Alternative Modest PARM Proposal On Tue, Nov 3, 2009 at 1:36 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote: In 6fh0f55c4lt4scbntma0r9udums736r...@4ax.com, on 11/03/2009 at 05:06 PM, Binyamin Dissen bdis...@dissensoftware.com said: The API is defined as 100 byte maximum There is no such formal API. The limitations of the R/I and C/I were just that, limitations. They were never a contract to the programmer. Au contraire. The 100 character limit has been documented since the beginning of time. An unknowably large number of programmers wrote an unknowably large number of (arguably incorrect) batch job step programs that functioned correctly ONLY because they were guaranteed never to get more than 100 bytes of parameter data from the initiator. You can play verbal semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We can all agree it was a bad idea and that wiser programmers might have properly dealt with the interface even then, but so what? All of those bad programs will, for better or worse, continue to run safely because the behavior of the initiator is not going to change. New programs wishing to use a larger plist can be coded to use a new way to get to the data. If it were only a case of new programs then I would agree that the existing format is obsolete. However, existing programs, including those from IBM, support the existing interface for parms longer than 100. http://bama.ua.edu/archives/ibm-main.html No Shmuel, that's where you have it precisely backwards. SOME existing programs can/do correctly interpret the existing interface when called with a longer parm string by a program other than the initiator. An unknowably large number don't behave that way and giving a JCL programmer a means (even accidentally) to pass longer parameter data to those existing programs through the existing interface is just begging for trouble, which is why it won't happen. Dressing the proposal up with a cheat-sheet approach where the initiator can consult a secret decoder ring to decide whether the long parameter string is allowed or not is (frankly) kinda nutty. It presents loads more mechanism and complexity for the OS and creates a maintenance problem with no guarantees of avoiding a 3AM collision with an otherwise valid program whose interface needs have not yet been documented. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 4 Nov 2009 09:02:35 -0800, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: The danger of a PARMX in JCL that passes parms greater than 100 bytes is two fold. 1. A specific JCL will have an EXEC statement that invokes the program with PARMX= without someone having tested the program to verify that it can handle that PARM length. This is sloppy programming and the installation deserves what it gets. 2. An installation will either change all JCL to use PARMX instead of PARM or require it for new JCL without verifying that the programs can handle it. Again this might be considered poor management because a mass change is made to an interface without testing. We can't protect all idiots from themselves. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee Sent: Wednesday, November 04, 2009 12:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: An Alternative Modest PARM Proposal On 4 Nov 2009 09:02:35 -0800, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: The danger of a PARMX in JCL that passes parms greater than 100 bytes is two fold. 1. A specific JCL will have an EXEC statement that invokes the program with PARMX= without someone having tested the program to verify that it can handle that PARM length. This is sloppy programming and the installation deserves what it gets. 2. An installation will either change all JCL to use PARMX instead of PARM or require it for new JCL without verifying that the programs can handle it. Again this might be considered poor management because a mass change is made to an interface without testing. We can't protect all idiots from themselves. snip It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
We can't protect all idiots from themselves. We should. That attitude is what makes M$ suck! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
To me, the PARMX approach strikes the right balance: - You have to explicitly change existing JCL to have a program see 100. - Existing programs that already support 100 work with only a JCL change As far as the argument that PARMX is dangerous because someone could code PARMX with a program that didn't support 100: This seems selectively cautious to me... any program could fail if you change its input to something it doesn't support. You don't need a new JCL keyword. As far as starting a debate between the three suggested JCL enhancements (PARMX, JCL variables available at runtime, and SYSIN substitution) - why? IMO, its better to lump everything into a single requirement bundle that has wide rather than fractured demand. IBM will choose what and how to implement anyway (if at all). Maybe we should just be thankful that we have 100 and not 80 :-) On Wed, Nov 4, 2009 at 11:01 AM, Clark Morris cfmpub...@ns.sympatico.ca wrote: On 3 Nov 2009 20:51:59 -0800, in bit.listserv.ibm-main you wrote: On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin paulgboul...@aim.com wrote: snip You're inconsistent in your assumptions. You appear to believe that: o Some JCL programmers won't take responsibility ... but o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be presumed to take responsibility for ensuring that the interface requirements of any program they may call are met. I strongly doubt the second of those statements. Therefore, to avoid breaking programs in unpredictable ways, the OS must be reinforced to avoid ever passing a PARM 100 characters. This must be done at the SVC level in order to preclude the programmer's loading registers and issuing the LINK or ATTACH SVC with an oversize PARM. In fact, there's no way to prevent the programmer's coding LOAD followed by BALR. Give me a program with AC=0 that doesn't check its PARM length and I'll break it. (Wanna see me make ASMA90 S0C4? I needed to use ATTCHPGM; couldn't break it with ATTCHMVS. I have a tester's temperament; you can't assume I'll always for be responsible for ensuring that a program's interface requirements, documented or otherwise are met.) http://bama.ua.edu/archives/ibm-main.html No I am not inconsistent in my assumptions, but I've obviously failed to communicate them to you. Let me try one last time. The fact that you can find programs that are well behaved in the circumstances you're talking about is not at all in dispute. But neither is it in the slightest bit relevant. Whether you choose to accept it or not, the initiator's documented interface existed long before the other interfaces you're citing (with the exception of plain old CALL) were even a developer's wet dream. Lots of horses fled the barn in the mean time. And I agree that I can't assume you will be responsible for ensuring your called program's interface requirements are met. In fact, I'm sure I can't. That's the whole point. Your tester's temperament is at odds with the stability needs of a production batch environment and I'll take a healthy sized bet that those production batch environments were there before you were, so whether you like it or not, they get grandfathered in, even if they don't play well by the rules you imagine they must. (Sorry if my architect's temperament is showing) The danger of a PARMX in JCL that passes parms greater than 100 bytes is two fold. 1. A specific JCL will have an EXEC statement that invokes the program with PARMX= without someone having tested the program to verify that it can handle that PARM length. This is sloppy programming and the installation deserves what it gets. 2. An installation will either change all JCL to use PARMX instead of PARM or require it for new JCL without verifying that the programs can handle it. Again this might be considered poor management because a mass change is made to an interface without testing. Both cases require specific action to break something existing, i.e. the JCL change. A change to existing JCL to create a PARM greater than 100 bytes in length on an EXEC statement with PARM= would still cause job failure. In one sense a more basic question is what do we see the future of the z series as being. People on other platforms look at many of the restrictions in JCL as being archaic (8 byte program names, 44 byte data set names, upper case only, and so forth). Even those coming from VSE (formerly Dumb Operating System) look askance at some of the restrictions (like not being able to handle FBA). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: An Alternative Modest PARM Proposal
On 3 Nov 2009 06:37:12 -0800, thomas.b...@swedbank.se (Thomas Berg) wrote: Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Chris Craddock Skickat: den 3 november 2009 07:39 Till: IBM-MAIN@bama.ua.edu Ämne: Re: An Alternative Modest PARM Proposal THAT my friends is compatibility. Not elegant, not pretty, but guaranteed compatible. Now can we all just get over this nonsense? Tsk, tsk. I think You should leave this matter to more persons with more knowledge. You see, this is a complicated matter, which You will maybe grasp when You have got some experience. Wow! Do you have ANY idea of who you just challenged??? I see blood and the streets, and it won't be Chris'. Eric -- Eric Chevalier E-mail: et...@tulsagrammer.com Web: www.tulsagrammer.com Is that call really worth your child's life? HANG UP AND DRIVE! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 17:12:51 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote: ::The suffix does not violate compatibility. A CVT bit could indicate the ::support for the suffix. ::So that a program that works with a long parm today, such as the Assembler, ::would have to be modified to test the CVT and look in a new place for the ::long parm. A poor solution, IMO. :Compatibility has its costs. This solution does not change the number of :parameters and is completely compatible. :You and I have diametrically opposed perspectives of compatibility. :To me, compatibility means the facility to call a program from JCL :with a long PARM presenting exactly the same interface as today when :it's called from other languages (such as Rexx), and requiring :modification neither of the target program nor of the calling language :(i.e. Rexx). You seem to advocate that the interface when called :from JCL should differ from the interface when called from Rexx, etc. :I can't view that as compatible. You have an unusual understanding of compatibility. Compatibility means that an existing program runs as is without needing to make any changes with the APIs remaining the same. New programs requiring new features use new APIs. :Yes, some programs would break if they could be called from JCL :with long parms, identically as they'd break if called from Rexx, :etc. with the same parms. Even that identical behavior in breakage :is a form of compatibility. Or if called as a CP or if called with a random parameter list. The API is defined as 100 byte maximum and programs are coded for that. Any change must respect the existing programs. New programs wishing to use a larger plist can be coded to use a new way to get to the data. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 2 Nov 2009 14:55:21 -0800, paulgboul...@aim.com (Paul Gilmartin) wrote: First, as Shmuel notes, most programs don't differentiate between being CALLED and JCL LAUNCHED. They're oblivious, and it's pretty hard to tell; parameters is parameters. If a second parameter is present, it shall be taken as a ddnamelist. I don't know of any reason why this shouldn't be the case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I still say dump the request for a change to PARM length max for JCL and/or the PARMX=. For __NEW__ functionality, implement POSIX environment variables into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can do an getenv() type call to grab the environment variable(s) they are interested in. The plus of this is that others, in other threads, have wanted to be able to get the contents of SET variables in their programs. Again, this would allow that. But it would take a change to the converter/intepreter as well as the initiator. Another plus is that you could use this instead of parsing the PARM field. For example, instead of: // EXEC PGM=MYPROG, // PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3' You could have: // SET VAR1=VAL1 // SET VAR2=VAL2 // SET VAR7=VAL7 // SET VAR3=VAL3 // EXEC PGM=MYPROG and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so on. No parsing of the PARM= needed. It would also simplify using UNIX programs because the environment variables could be set in JCL (and as symbolic parameters passed into a PROC) instead of somehow getting them in via the //STDENV statement (which doesn't do symbolic substitution). Just my from-left-field idea, yet again. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
This does not have to be a 'all-or-none', or 'my-way-or-the-highway' issue. Assume the some programs can accept JCL-format parms of more than 100 bytes. Also assume that some programs cannot accept such parms. Also assume you don't want to force program changes. So what's the issue? In some cases, you want to be able to pass more than 100 characters as a JCL parm to a program that is capable of handling it. I believe it's been discussed already, but why not just request an additional JCL parameter, such as PARMX or EXTPARM, or whatever, that has the following restrictions: Cannot be specified along with PARM, and a maximum length of 32767 characters, with the same formatting requirements as the PARM parameter. Document the restriction that passing more than 100 characters to a program should only be done when the program supports it. The resulting data as presented to the called program would be the same: pointer to HW length followed by data of that length. So, coding PARM='RENT' or PARMX='RENT' results in the same data. I have no requirement for passing more than 100 characters in the parm for the linkage editor or HLASM. So, I could code PARM or PARMX. It makes no difference. I don't even care if these two programs ever support more than 100 characters. However, I may need to pass more than 100 characters to some program, such as the COBOL compiler. First, I have to know that the compiler supports it. Second, I need the JCL support. Today, assuming the called program supports the parm, if I want to create a simulated parm, I could front-end the compiler with REXX or assembler, building the long parm list as needed. With a new JCL option, I could bypass the front end process. Finally, what about users who pass more than 100 character parms to programs that are not coded to handle them? That's why you document Don't do that, or you get unexpected results. What happens now if I pass an invalid parm to a program? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote: I still say dump the request for a change to PARM length max for JCL and/or the PARMX=. For __NEW__ functionality, implement POSIX environment variables into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can do an getenv() type call to grab the environment variable(s) they are interested in. The plus of this is that others, in other threads, have wanted to be able to get the contents of SET variables in their programs. Again, this would allow that. But it would take a change to the converter/intepreter as well as the initiator. Another plus is that you could use this instead of parsing the PARM field. For example, instead of: // EXEC PGM=MYPROG, // PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3' You could have: // SET VAR1=VAL1 // SET VAR2=VAL2 // SET VAR7=VAL7 // SET VAR3=VAL3 // EXEC PGM=MYPROG and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so on. No parsing of the PARM= needed. I'd almost support that. And a simple wrapper program to concatenate variables of a distinguished format could assemble a PARM of enormous length and issue a CALL. If the wrapper is not itself AC=1, there's no hazard of invoking authorized programs with oversized PARM. My reservation? Use of symbols in the operand of SET is not supported. Damn! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I like John's idea. I think that this idea was discussed before with the suggestion that JCL PROC/SET variables be stored in a special ASASYMBM table. Re: Use of symbols in the operand of SET is not supported. - really? This works fine: // SET PRFX=SYS1 // SET MACLIB=PRFX..MACLIB // SET AMACLIB=PRFX..AMACLIB // SET LINKLIB=PRFX..LINKLIB Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, Nov 3, 2009 at 10:04 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote: I still say dump the request for a change to PARM length max for JCL and/or the PARMX=. For __NEW__ functionality, implement POSIX environment variables into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can do an getenv() type call to grab the environment variable(s) they are interested in. The plus of this is that others, in other threads, have wanted to be able to get the contents of SET variables in their programs. Again, this would allow that. But it would take a change to the converter/intepreter as well as the initiator. Another plus is that you could use this instead of parsing the PARM field. For example, instead of: // EXEC PGM=MYPROG, // PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3' You could have: // SET VAR1=VAL1 // SET VAR2=VAL2 // SET VAR7=VAL7 // SET VAR3=VAL3 // EXEC PGM=MYPROG and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so on. No parsing of the PARM= needed. I'd almost support that. And a simple wrapper program to concatenate variables of a distinguished format could assemble a PARM of enormous length and issue a CALL. If the wrapper is not itself AC=1, there's no hazard of invoking authorized programs with oversized PARM. My reservation? Use of symbols in the operand of SET is not supported. Damn! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 17:06:23 +0200, Binyamin Dissen wrote: The API is defined as 100 byte maximum and programs are coded for that. Any change must respect the existing programs. New programs wishing to use a larger plist can be coded to use a new way to get to the data. The JCL manual does say, The length of the subparameters passed must not exceed 100 characters, but I wouldn't call that an API. The Assembler Services Guide describes the API. It reads, quote When your program receives control from the system, register 1 contains the address of a fullword on a fullword boundary in your program's address space (see Figure 2-4). The high-order bit (bit 0) of this word is set to 1. The system uses this convention to indicate the last word in a variable-length parameter list. Bits 1-31 of the fullword contain the address of a two-byte length field on a halfword boundary. The length field contains a binary count of the number of bytes in the PARM field, which immediately follows the length field. If the PARM field was omitted in the EXEC statement, the count is set to zero. To prevent possible errors, always use the count as a length attribute in acquiring the information in the PARM field. /quote It does not mention the 100 byte limit. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 3 Nov 2009 08:29:39 -0800, m42tom-ibmm...@yahoo.com (Tom Marchant) wrote: To prevent possible errors, always use the count as a length attribute in acquiring the information in the PARM field. /quote It does not mention the 100 byte limit. No. But it does a CYA by telling us to program correctly. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 00:39:03 -0600, Chris Craddock wrote: The PARM interface is older than dirt and even though we can all agree with hindsight that it was a momentously stupid design, it is nevertheless a formal, documented interface and literally thousands of badly written programs work correctly ONLY because the initiator is never going to give them a parameter string of more that 100 characters. That's the one and only interface contract. The assertion that you can find programs that behave well when called directly with longer parameter strings is also true, but completely uninteresting. Changing the behavior of PARM is fraught with incompatibilities. So much so that wiser heads elected not to pull the trigger on it. There are lots of ways of enabling (much longer) parameter strings but they all necessarily involve defining some brand new and non- overlapping interface definition. New programs written to the putative new parameter interface spec will work correctly and completely oblivious of the old spec. And since the existing PARM interface will remain unchanged, all old programs will continue work as they do now, completely oblivious of any new interface. THAT my friends is compatibility. Not elegant, not pretty, but guaranteed compatible. Now can we all just get over this nonsense? The Assembler CALL interface (likewise older than dirt) plus Rexx ATTCHMVS and many other language calling interfaces (mostly newer than dirt) have long supported parameters longer than 100. Are you suggesting that these facilities are fraught with incompatibilites? Perhaps so risky that the facilities should be curtailed? The existence of these other interfaces, at least to AC=0 programs, makes the JCL PARM limit a barrier that surrounds and protects little. If the JCL PARM limit were relaxed, all old programs would continue to work exactly as they do now, when passed the PARMs they are now being passed, completely oblivious of any new capability. BTW, I wonder, which is older, Assembler CALL or JCL PARM? Historians might answer. If Assembler is older, JCL is the interloper with a novel restriction. And I have seen no horror stories of programs being called outside JCL with oversize PARMs (although this musing might evince some). I suspect that when it happens, the programmer merely shrugs, Oops. I won't do that any more. As an experiment, I called ASMA90 with a PARM length of 32767. Worked fine, however pointless. With a PARM length of 32768, SOC4. But that behavior does not mandate a proscription of the facility (Rexx ATTCHPGM) that I used to call ASMA90 that way, nor any blot on compatibility. It's just a Don't do that!, even as if the JCL PARM limit were relaxed to allow me to EXEC PGM=ASMA90,PARMX=some 32768 characters and cause it to ABEND, it would not be an incompatibility, just a behavior for the programmer to avoid. not be an incompatibility, -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 11:56:19 -0600, Rick Fochtman wrote: -snip Wow! Do you have ANY idea of who you just challenged??? I see blood and the streets, and it won't be Chris'. ---unsnip--- While I agree that Chris needs a better understanding of all the issues involved, I must admit that I agree with the sentiments expressed. Yes, compatability must be maintained, as ugly as it may be. Making a major change now, after 45+ years, could cause major chaos and discontent in MANY shops. And you, also, need a better understanding. No one is proposing any change that will cause existing dusty programs with existing dusty JCL to fail. (Well, disregarding the possibility that someone is deliberately coding an oversize PARM with the intent of causing a JCL error. Is anyone actually doing that?) Even so, each innovation to JCL, such as the OUTPUT statement, the SET statement, the IF statement, allowing nested PROC calls, etc. has caused some constructs that previously would have received JCL errors now to execute, even in some cases with unintended results. Do you call those new behaviors incompatibilities? Did you object to them as such when they appeared? And this is not even considering the impact of those innovations on JCL syntax checkers. None of those raises a valid objection, nor should a longer PARM (or PARMX). --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 11/3/2009 at 9:04 AM, in message listserv%200911031004341010.0...@bama.ua.edu, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote: I still say dump the request for a change to PARM length max for JCL and/or the PARMX=. For __NEW__ functionality, implement POSIX environment variables into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can do an getenv() type call to grab the environment variable(s) they are interested in. The plus of this is that others, in other threads, have wanted to be able to get the contents of SET variables in their programs. Again, this would allow that. But it would take a change to the converter/intepreter as well as the initiator. Another plus is that you could use this instead of parsing the PARM field. For example, instead of: // EXEC PGM=MYPROG, // PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3' You could have: // SET VAR1=VAL1 // SET VAR2=VAL2 // SET VAR7=VAL7 // SET VAR3=VAL3 // EXEC PGM=MYPROG and MYPROG would simply do a getenv(VAR1) to get the value of VAR1 and so on. No parsing of the PARM= needed. I'd almost support that. And a simple wrapper program to concatenate variables of a distinguished format could assemble a PARM of enormous length and issue a CALL. If the wrapper is not itself AC=1, there's no hazard of invoking authorized programs with oversized PARM. My reservation? Use of symbols in the operand of SET is not supported. Damn! I think someone in a prior posting suggested a PARM JCL statement. I'm not sure if this is what he meant, but how about this? // SET MYVAL=VAL1 // PARM VAR1=MYVAL // PARM VAR2=VAL2 // PARM VAR7=VAL7 // PARM VAR3=VAL3 // EXEC PGM=MYPROG SET would still function at it always has. PARM would be a new type of statement that would set an environment variable, and would support the use of symbolics. Could we go further and allow these environment variables in some sort of conditional checking, such as: // IFPARM VAR1='SOMETHING' THEN //MYDD DD DISP=SHR,DSN=MY.FILE // ENDIF I have no idea of the internals of how JCL is supported, so this may be way off the beam. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 03 Nov 2009 13:14:53 -0500, des...@verizon.net wrote: I find the whole issue of compatibility bogus. Existing programs are compatible with existing parms. Increasing the max is irrelevant to compatibility. Longer parms are a total waste of time though. They're too hard to code. Real environment variables is a much better way to go. For me, the bigger issue is having a system where the JCL calls programs just as programs call programs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In ts3ue5lagh91i16hlub6vm6poq4oc65...@4ax.com, on 11/02/2009 at 06:59 PM, Binyamin Dissen bdis...@dissensoftware.com said: Huh? Paul is referring to the documented[1] OS/360 convention that a main program is just another subroutine. The suffix does not violate compatibility. It breaks compatibility for existing code that already supports more than 100 characters. Don Ault has already stated that IBM will not do that. [1] From the beginning. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I still don't see why there would be a problem with just PARM= behaving just as it does now. and having a new PARMX= (or whatever) that sets up exactly the same thing except that the string can be up to whatever that two-byte length field allows (I don't remember if it's supposed to be signed or unsigned ... I would guess that it's signed)? you can use PARM= OR PARMX= on an EXEC statement but not both ... if you leave your JCL alone for old stuff, they should still work and not have to worry about these long PARMs. if you change your JCL to use PARMX= then you should make sure your program does handle a long parm string. if YOU choose to switch to PARMX= and it results in a problem, then it's YOUR fault. --Stephen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In 6fh0f55c4lt4scbntma0r9udums736r...@4ax.com, on 11/03/2009 at 05:06 PM, Binyamin Dissen bdis...@dissensoftware.com said: The API is defined as 100 byte maximum There is no such formal API. The limitations of the R/I and C/I were just that, limitations. They were never a contract to the programmer. New programs wishing to use a larger plist can be coded to use a new way to get to the data. If it were only a case of new programs then I would agree that the existing format is obsolete. However, existing programs, including those from IBM, support the existing interface for parms longer than 100. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 2 Nov 2009 13:22:56 -0800, in bit.listserv.ibm-main you wrote: On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote: If we really go the new syntax road, I liked the suggestion, by someone I don't remember for the moment, that we introduce a new JCL operand: // PARM '...' I like that partly beacuse of possibility to have a concatenate function like: // PARM 'part 1 .' // PARM 'part 2 .' // PARM 'part 3 .' etc. An easy way to input a long parm (in JCL). That would be of considerable value even given the 100-character limit. PARM continuation is a PITA, particularly when the JCL is being generated by a program. OTOH, JCL symbols provide fast symptomatic relief: PARM='PART1PART2PART3' *BUT*, we still we have the problem of backward incompatibility regardless of the input format... As long as authorized programs are excluded, no new incompatibility is introduced. Any programmer can today call any unauthorized program with Rexx with a 65,535 character PARM. Actually if you use PARMX to pass exactly the same parm with the exception that the PARM can be over 100 bytes in length, fallout should be minimal. The only time PARMX would be used is to pass such a parm and I would hope that someone would test said use before it goes into production. Existing JCL would not be affected and backward compatibility shouldn't be a problem. Since an explicit action would have to be taken to pass a 101 - 65K parm, it should NOT unexpectedly affect existing programs. Of course if some makes mass PARM= to PARMX= changes to JCL all bets are off. ... PARM = d2c( 65535 )left( 'WOMBAT', 65535 ) address ATTCHPGM 'MYPROGM PARM' ... But that's not a solution because it's cumbersome and doesn't support the use of JCL symbols. Regarding John M's suggestion of using STEPLIB to suppress execution in authorized state: o I'm uneasy with such reliance on a side effect; it lacks referential transparency (not that that's ever been much a concern in the design of JCL). o It leaves too great a hazard of inadvertently executing a program in authorized state with a long PARM, either - because the programmer doesn't supply a STEPLIB and symbol substitution unexpectedly creates a long PARM - or because the data set the programmer supplies is later marked authorized without consideration of the indirect consequence. Tom M. has supplied an example. Regarding Clark M's assertion: Any authorized program that didn't verify that the parm length was acceptable was poorly coded. I know that my programs checked for maximum value and also minimum values so that I knew that the program didn't pick up garbage. Kudos. But even representatives of the most reputable organizations can slip up: Linkname: Re: Long parms ... again (was: Reading DD card information) URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainamp;P=153276 (My apologies for misattributing this to John EElls; it was Jim Mulder, citing a survey by Karl Schmitz.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 3 Nov 2009 09:58:50 -0800, rfocht...@ync.net (Rick Fochtman) wrote: Yes, compatability must be maintained, as ugly as it may be. Making a major change now, after 45+ years, could cause major chaos and discontent in MANY shops. Maybe in this case, the benefit wouldn't be worth the cost in shops that had poor programming. But in general, backwards compatibility is over-valued and the costs of backwards compatibility are under-valued. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In 4aef4550.4040...@ync.net, on 11/02/2009 at 02:47 PM, Rick Fochtman rfocht...@ync.net said: IIRC, the IBM compilers will also accept a *PROCESS statement that can be as long as necessary. The options on *PROCESS can't be specified in JCL; the options in PARM can. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In 75pte5d4gbjq6ivuct5cia1svu0khlb...@4ax.com, on 11/02/2009 at 03:55 PM, Binyamin Dissen bdis...@dissensoftware.com said: Not at all. There's a compatibility problem with programs that currently use HW + characters as the first parameter and don't rquire the length to be less than 101. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, Nov 3, 2009 at 11:48 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Tue, 3 Nov 2009 00:39:03 -0600, Chris Craddock wrote: The PARM interface is older than dirt and even though we can all agree with hindsight that it was a momentously stupid design, it is nevertheless a formal, documented interface and literally thousands of badly written programs work correctly ONLY because the initiator is never going to give them a parameter string of more that 100 characters.snip The Assembler CALL interface (likewise older than dirt) plus Rexx ATTCHMVS and many other language calling interfaces (mostly newer than dirt) have long supported parameters longer than 100. Are you suggesting that these facilities are fraught with incompatibilites? Perhaps so risky that the facilities should be curtailed? The existence of these other interfaces, at least to AC=0 programs, makes the JCL PARM limit a barrier that surrounds and protects little. If the JCL PARM limit were relaxed, all old programs would continue to work exactly as they do now, when passed the PARMs they are now being passed, completely oblivious of any new capability. When you call a batch job step program through another interface than EXEC PGM= you are taking responsibility for ensuring that the program's interface requirements are met. And you're right there are many such programs that can safely and easily be called exactly as you describe. That's completely and utterly not the point. There exists an unknowably large pool of programs that were written as batch job step programs with no expectation or intention of ever being invoked through any other interface. If you tried to call one of those via an assembler CALL interface, or ATTACHMVS, or any other permutation you can cook up and pass it more than 100 bytes of PARM data, you would break that program in an unpredictable way. Your prescription of well don't do that is fine in a world where everyone knows what they are doing and pays attention to the rules. That doesn't resemble the world we live in though. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 17:36:05 -0500, Tony Harminc wrote: The argument would be that if such a program fails only because it copies parmlength bytes to a 100-byte buffer without checking that the length does not exceed 100, it does not compromise MVS System Integrity, since the Integrity statement talks about Installation Control, and clearly the installation has the ability to disallow the invocation of such programs via TSO/E CALL, TESTAUTH, authorized REXX, and so on. However this could be tested, I believe, by using the EXECMVS (BPX1EXM) service. This can pass a parm string of length up to 4096 (yet another arbitrary number) to any program in linklist (or possibly a private STEPLIB), and will invoke AC(1) programs in an authorized state, with, as far as I know, no method of installation control other than denying UNIX access entirely. An attack based on this would take some effort, even assuming a buffer overflow and subsequent code execution can be accomplished, not least because the overlaying code would have to come from global storage. But PC malware authors have done the same under more difficult conditions. So if someone can find an AC(1) IBM module in linklist that does something Really Bad with a long parm string, this'd be the way. BPX1EXM invokes its target program as a new jobstep with no DD statements in effect. So someone would need to find an AC(1) IBM module in linklist that does something Really Bad with a long parm string and no DD statements. Quite a challenge. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 17:01:12 -0600, Chris Craddock wrote: When you call a batch job step program through another interface than EXEC PGM= you are taking responsibility for ensuring that the program's interface requirements are met. And you're right there are many such programs that can safely and easily be called exactly as you describe. That's completely and utterly not the point. There exists an unknowably large pool of programs that were written as batch job step programs with no expectation or intention of ever being invoked through any other interface. If you tried to call one of those via an assembler CALL interface, or ATTACHMVS, or any other permutation you can cook up and pass it more than 100 bytes of PARM data, you would break that program in an unpredictable way. Your prescription of well don't do that is fine in a world where everyone knows what they are doing and pays attention to the rules. That doesn't resemble the world we live in though. You're inconsistent in your assumptions. You appear to believe that: o Some JCL programmers won't take responsibility ... but o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be presumed to take responsibility for ensuring that the interface requirements of any program they may call are met. I strongly doubt the second of those statements. Therefore, to avoid breaking programs in unpredictable ways, the OS must be reinforced to avoid ever passing a PARM 100 characters. This must be done at the SVC level in order to preclude the programmer's loading registers and issuing the LINK or ATTACH SVC with an oversize PARM. In fact, there's no way to prevent the programmer's coding LOAD followed by BALR. Give me a program with AC=0 that doesn't check its PARM length and I'll break it. (Wanna see me make ASMA90 S0C4? I needed to use ATTCHPGM; couldn't break it with ATTCHMVS. I have a tester's temperament; you can't assume I'll always for be responsible for ensuring that a program's interface requirements, documented or otherwise are met.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 14:20:36 -0500, Don Williams wrote:
I have wanted to be able to pass long parms from JCL since the early 80's.
I've have to use inventive ways to get around that restriction. I've
listened to many people complain that 100 characters was too small.
Something like PARMX has be desired for a very long time by many people. A
solution is long over due.
The PARMX suggestion would not require any existing programs to be changed,
would not require existing JCL to be changed. Existing JCL and programs
would continue to work without any changes. You don't have to use it, if you
don't like it. PARMX would allow JCL to pass long parms more like other
existing languages.
You could create new JCL or update old JCL to invoke an existing program
using PARMX; that program may or may not be able to gracefully handle parms
greater that 100 characters. If it can, then you have a easy way to pass
that program more than 100 character parm. If it can't, don't use PARMX with
that program.
SAF could be used to control usage of PARMX for those would don't like it.
Implementing PARMS would not prevent other features like environment
(PARMX, I assume.)
variables, etc. from being implemented as well. That is about as compatible
as you can get. It seems like we are making a mountain out of mole hill, so
I'm going to submit a PARMX requirement to IBM. So IBM will decide.
Amen.
But take care to address Jim Mulder's serious concern that invoking
certain APF-authorized programs with long parms can be highly
destructive. This could be prevented simply by invoking all
programs in the unauthorized state when PARMX is specified.
But I'd prefer something more transparent, such as a new keyword,
AUTH={ YES | NO | SAF }, where:
o YES (the default) maintains the current behavior: PARM100
causes a JCL error. If PARM=100, the PGM is invoked according
to its AC attribute.
o NO allows PARM100, but any PGM is invoked unauthorized.
o SAF causes a SAF call to determine whether PGM is allowed a
to be invoked authorized with PARM100.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
SNIPPAGE This reminds me of PL/1. Designed and implemented by committee. How about writing it up, and if you are a SHARE member, submitting it for a vote. Let IBM decide how they are going to deal with it (they will any way, given my experience with JES2 development). But, this is just one person's opinion. Regards, Steve Thompson -- STD disclaimer, opinions expressed by me, may not be those of my employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, Nov 3, 2009 at 1:36 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote: In 6fh0f55c4lt4scbntma0r9udums736r...@4ax.com, on 11/03/2009 at 05:06 PM, Binyamin Dissen bdis...@dissensoftware.com said: The API is defined as 100 byte maximum There is no such formal API. The limitations of the R/I and C/I were just that, limitations. They were never a contract to the programmer. Au contraire. The 100 character limit has been documented since the beginning of time. An unknowably large number of programmers wrote an unknowably large number of (arguably incorrect) batch job step programs that functioned correctly ONLY because they were guaranteed never to get more than 100 bytes of parameter data from the initiator. You can play verbal semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We can all agree it was a bad idea and that wiser programmers might have properly dealt with the interface even then, but so what? All of those bad programs will, for better or worse, continue to run safely because the behavior of the initiator is not going to change. New programs wishing to use a larger plist can be coded to use a new way to get to the data. If it were only a case of new programs then I would agree that the existing format is obsolete. However, existing programs, including those from IBM, support the existing interface for parms longer than 100. http://bama.ua.edu/archives/ibm-main.html No Shmuel, that's where you have it precisely backwards. SOME existing programs can/do correctly interpret the existing interface when called with a longer parm string by a program other than the initiator. An unknowably large number don't behave that way and giving a JCL programmer a means (even accidentally) to pass longer parameter data to those existing programs through the existing interface is just begging for trouble, which is why it won't happen. Dressing the proposal up with a cheat-sheet approach where the initiator can consult a secret decoder ring to decide whether the long parameter string is allowed or not is (frankly) kinda nutty. It presents loads more mechanism and complexity for the OS and creates a maintenance problem with no guarantees of avoiding a 3AM collision with an otherwise valid program whose interface needs have not yet been documented. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In 3ukue5d024hvsqq36tesv225fu3lr0c...@4ax.com, on 11/02/2009 at 11:50 PM, Binyamin Dissen bdis...@dissensoftware.com said: Compatibility has its costs. This solution does not change the number of parameters and is completely compatible. No; it breaks compatibility with existing code that supports more than 100 characters. It also leads to users believing that they have specified a parameter when the program actually never sees it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In listserv%200911031148532643.0...@bama.ua.edu, on 11/03/2009 at 11:48 AM, Paul Gilmartin paulgboul...@aim.com said: BTW, I wonder, which is older, Assembler CALL or JCL PARM? Neither; they were contemporaneous. Both were in the original OS/360 announcement, as was the principle that a main program is just another subroutine. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 10:25:51 -0600, Kirk Wolf wrote: Re: Use of symbols in the operand of SET is not supported. - really? This works fine: // SET PRFX=SYS1 // SET MACLIB=PRFX..MACLIB // SET AMACLIB=PRFX..AMACLIB // SET LINKLIB=PRFX..LINKLIB Outdated information? I clearly remember a warning in the JCL RM that symbols were not to be used in the arguments of SET, but I can no longer find it. Can anyone help me here?. It always worked, but IBM maintains a fine distinction between supported and happens to work. For example from elsewhere in the JCL RM: 17.1.4.5 z/OS V1R11.0 MVS JCL Reference __ 17.1.4.5 Relational-Expression Keywords The following keywords are the only keywords supported by IBM and recommended for use in relational-expressions. Any other keywords, even if accepted by the system, are not intended or supported keywords. And the fact that symbols are not substituted between apostrophes in the argument of SET is a PITA, even though it can be worked around, painstakingly. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
Tom Marchant wrote: exceed 100 characters, but I wouldn't call that an API. The Assembler Services Guide describes the API. It reads, quote snipped? /quote It does not mention the 100 byte limit. It also does not mention that you could receive a four word list if called as a CP, or a two word list with DD names, etc. I take it to provide the minimum you need to know to handle a PARM, with no deeper significance. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I have wanted to be able to pass long parms from JCL since the early 80's. I've have to use inventive ways to get around that restriction. I've listened to many people complain that 100 characters was too small. Something like PARMX has be desired for a very long time by many people. A solution is long over due. The PARMX suggestion would not require any existing programs to be changed, would not require existing JCL to be changed. Existing JCL and programs would continue to work without any changes. You don't have to use it, if you don't like it. PARMX would allow JCL to pass long parms more like other existing languages. You could create new JCL or update old JCL to invoke an existing program using PARMX; that program may or may not be able to gracefully handle parms greater that 100 characters. If it can, then you have a easy way to pass that program more than 100 character parm. If it can't, don't use PARMX with that program. SAF could be used to control usage of PARMX for those would don't like it. Implementing PARMS would not prevent other features like environment variables, etc. from being implemented as well. That is about as compatible as you can get. It seems like we are making a mountain out of mole hill, so I'm going to submit a PARMX requirement to IBM. So IBM will decide. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Tuesday, November 03, 2009 12:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: An Alternative Modest PARM Proposal -snip Wow! Do you have ANY idea of who you just challenged??? I see blood and the streets, and it won't be Chris'. ---unsnip--- While I agree that Chris needs a better understanding of all the issues involved, I must admit that I agree with the sentiments expressed. Yes, compatability must be maintained, as ugly as it may be. Making a major change now, after 45+ years, could cause major chaos and discontent in MANY shops. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
-snip Wow! Do you have ANY idea of who you just challenged??? I see blood and the streets, and it won't be Chris'. ---unsnip--- While I agree that Chris needs a better understanding of all the issues involved, I must admit that I agree with the sentiments expressed. Yes, compatability must be maintained, as ugly as it may be. Making a major change now, after 45+ years, could cause major chaos and discontent in MANY shops. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In p06240805c71505a12...@[192.168.1.11], on 11/02/2009 at 04:58 PM, Robert A. Rosenberg hal9...@panix.com said: When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept a longer than 100 character PARM Entry (while also accepting DDNAME Overrides in Parms 2+)? Yes. They're not coded to test for jobstep; in fact, there's no incentive for them to test. If they have code for a first parameter of, e.g., up to 255 then it works just fine for 100 or less. If so THEN you have a conflict with using a PARMX. Which was why I proposed an alternative to PARMX. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, 3 Nov 2009 16:46:26 -0600, Chris Craddock wrote: Au contraire. The 100 character limit has been documented since the beginning of time. An unknowably large number of programmers wrote an unknowably large number of (arguably incorrect) batch job step programs that functioned correctly ONLY because they were guaranteed never to get more than 100 bytes of parameter data from the initiator. You can play verbal semantic games all you want, but THAT *IS* A CONTRACT to the programmer. We can all agree it was a bad idea and that wiser programmers might have properly dealt with the interface even then, but so what? All of those bad programs will, for better or worse, continue to run safely because the behavior of the initiator is not going to change. from the initiator is a major hedge. Any of those bad programs (at least with AC=0) can readily be invoked with a long parm by other means. If this *IS* A CONTRACT it has so many loopholes that I'd deem it fraudulent. If it were only a case of new programs then I would agree that the existing format is obsolete. However, existing programs, including those from IBM, support the existing interface for parms longer than 100. http://bama.ua.edu/archives/ibm-main.html No Shmuel, that's where you have it precisely backwards. SOME existing programs can/do correctly interpret the existing interface when called with a longer parm string by a program other than the initiator. An unknowably large number don't behave that way and giving a JCL programmer a means (even accidentally) to pass longer parameter data to those existing programs through the existing interface is just begging for trouble, which is why it won't happen. Can't we assume that Shumel implied the SOME? And existing interfaces (not the interface; stop trying to pretend there's only one) allow (at least some: those with AC=0) existing programs to be passed longer parameter data. For those programs, the putative hazard has existed as long as the assembler CALL interface. The universe hasn't ended as a consequence. If system integrity or data security is a concern, then all means of calling any program with a long parm must be proscribed. Dressing the proposal up with a cheat-sheet approach where the initiator can consult a secret decoder ring to decide whether the long parameter string is allowed or not is (frankly) kinda nutty. It presents loads more mechanism and complexity for the OS and creates a maintenance problem with no guarantees of avoiding a 3AM collision with an otherwise valid program whose interface needs have not yet been documented. Agreed. But much simpler: o AC=0: long parm allowed, as it is now via those pesky alternate interfaces. o AC=1: long parm prohibited, even as now. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
If a program is APF-authorized and can be invoked from JCL and does not
properly validate any parameter(s) provided to it by its invoker, then I
would argue that the program is defective and that the lack of parameter
validation is APAR'able.
John P. Baker
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Tuesday, November 03, 2009 4:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: An Alternative Modest PARM Proposal
But take care to address Jim Mulder's serious concern that invoking
certain APF-authorized programs with long parms can be highly
destructive. This could be prevented simply by invoking all
programs in the unauthorized state when PARMX is specified.
But I'd prefer something more transparent, such as a new keyword,
AUTH={ YES | NO | SAF }, where:
o YES (the default) maintains the current behavior: PARM100
causes a JCL error. If PARM=100, the PGM is invoked according
to its AC attribute.
o NO allows PARM100, but any PGM is invoked unauthorized.
o SAF causes a SAF call to determine whether PGM is allowed a
to be invoked authorized with PARM100.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In b0c6f15b0911022239s3a22a2a2gf6404101562bb...@mail.gmail.com, on 11/03/2009 at 12:39 AM, Chris Craddock crashlu...@gmail.com said: The PARM interface is older than dirt and even though we can all agree with hindsight that it was a momentously stupid design, it is nevertheless a formal, documented interface No; it is documented that the C/I (originally the R/I) will never pass more than 100 characters. It was also documented that there might be other callers than the Initiator. Changing the behavior of PARM is fraught with incompatibilities. So much so that wiser heads elected not to pull the trigger on it. Changing the behavior is exactly what you propose, and IBM has already decided that they won't do that. The wiser heads at IBM decided that long PARM support will continue to use a HW length followed by the characters, with the main issue left open whether the limit[1] would be 32 KiB - 1 or 64 KiB - 1. There are lots of ways of enabling (much longer) parameter strings but they all necessarily involve defining some brand new and non- overlapping interface definition. Not unless you need a PARM longer than 64 KiB - 1. Otherwise the existing HW length will work just fine. THAT my friends is compatibility. Not elegant, not pretty, but guaranteed compatible. Compatibility means one thing to you and something quite different to me. Now can we all just get over this nonsense? Well, per Don Ault we already have; there will be no arbitrary new interface when the existing interface can handle the job. Of course, we disagree on what is nonesense. [1] Yes, a FW would allow for a much higher limit, but per Don Ault that's not going to happen, and I have never run into a situation where 1 32 KiB - 1 limit would be inadequate. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
2009/11/3 John P. Baker jbaker...@comporium.net:
If a program is APF-authorized and can be invoked from JCL and does not
properly validate any parameter(s) provided to it by its invoker, then I
would argue that the program is defective and that the lack of parameter
validation is APAR'able.
The argument would be that if such a program fails only because it
copies parmlength bytes to a 100-byte buffer without checking that
the length does not exceed 100, it does not compromise MVS System
Integrity, since the Integrity statement talks about Installation
Control, and clearly the installation has the ability to disallow the
invocation of such programs via TSO/E CALL, TESTAUTH, authorized REXX,
and so on.
However this could be tested, I believe, by using the EXECMVS
(BPX1EXM) service. This can pass a parm string of length up to 4096
(yet another arbitrary number) to any program in linklist (or possibly
a private STEPLIB), and will invoke AC(1) programs in an authorized
state, with, as far as I know, no method of installation control other
than denying UNIX access entirely. An attack based on this would take
some effort, even assuming a buffer overflow and subsequent code
execution can be accomplished, not least because the overlaying code
would have to come from global storage. But PC malware authors have
done the same under more difficult conditions.
So if someone can find an AC(1) IBM module in linklist that does
something Really Bad with a long parm string, this'd be the way.
Tony H.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
But take care to address Jim Mulder's serious concern that invoking
certain APF-authorized programs with long parms can be highly
destructive. This could be prevented simply by invoking all
programs in the unauthorized state when PARMX is specified.
But I'd prefer something more transparent, such as a new keyword,
AUTH={ YES | NO | SAF }, where:
o YES (the default) maintains the current behavior: PARM100
causes a JCL error. If PARM=100, the PGM is invoked according
to its AC attribute.
o NO allows PARM100, but any PGM is invoked unauthorized.
o SAF causes a SAF call to determine whether PGM is allowed a
to be invoked authorized with PARM100.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In listserv%200911021027099979.0...@bama.ua.edu, on 11/02/2009 at 10:27 AM, Tom Marchant m42tom-ibmm...@yahoo.com said: No. As I recall, Shmuel's original proposal was to provide a list somewhere, preferably in PARMLIB, of programs that could not handle the long parm. More precisely, a list of maximum parm lengths, using wildcardsw to provide defaults. I suspect that for IEB* and IEH* that a maximum of 256 would be safe. From a 1995 message that I had forgotten, IBM is more likely to do the checking in the Interpreter than in the C/I. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Tue, Nov 3, 2009 at 5:44 PM, Paul Gilmartin paulgboul...@aim.com wrote: snip You're inconsistent in your assumptions. You appear to believe that: o Some JCL programmers won't take responsibility ... but o All Assembler, Rexx, FORTRAN, COBOL, C, PL/I, ... can be presumed to take responsibility for ensuring that the interface requirements of any program they may call are met. I strongly doubt the second of those statements. Therefore, to avoid breaking programs in unpredictable ways, the OS must be reinforced to avoid ever passing a PARM 100 characters. This must be done at the SVC level in order to preclude the programmer's loading registers and issuing the LINK or ATTACH SVC with an oversize PARM. In fact, there's no way to prevent the programmer's coding LOAD followed by BALR. Give me a program with AC=0 that doesn't check its PARM length and I'll break it. (Wanna see me make ASMA90 S0C4? I needed to use ATTCHPGM; couldn't break it with ATTCHMVS. I have a tester's temperament; you can't assume I'll always for be responsible for ensuring that a program's interface requirements, documented or otherwise are met.) http://bama.ua.edu/archives/ibm-main.html No I am not inconsistent in my assumptions, but I've obviously failed to communicate them to you. Let me try one last time. The fact that you can find programs that are well behaved in the circumstances you're talking about is not at all in dispute. But neither is it in the slightest bit relevant. Whether you choose to accept it or not, the initiator's documented interface existed long before the other interfaces you're citing (with the exception of plain old CALL) were even a developer's wet dream. Lots of horses fled the barn in the mean time. And I agree that I can't assume you will be responsible for ensuring your called program's interface requirements are met. In fact, I'm sure I can't. That's the whole point. Your tester's temperament is at odds with the stability needs of a production batch environment and I'll take a healthy sized bet that those production batch environments were there before you were, so whether you like it or not, they get grandfathered in, even if they don't play well by the rules you imagine they must. (Sorry if my architect's temperament is showing) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 13:40:44 +0100 Thomas Berg thomas.b...@swedbank.se wrote: :If the current JCL PARM format change from HW + 0-100 bytes :to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm, :are there any backward compatibility problems ? Not at all. Would require a CVT bit to indicate the new support. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote: At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An Alternative Modest PARM Proposal: Therefore, you should understand very well why this won't work. Such utilities will misinterpret the Long Parm as a DDN override list. There is NO REASON to send a Long Parm to these IBM utilities so this potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPARM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. Does this help? No. As I recall, Shmuel's original proposal was to provide a list somewhere, preferably in PARMLIB, of programs that could not handle the long parm. You have added essentially the same list to is incompatible and excessively complicated alternative. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote: :If the current JCL PARM format change from HW + 0-100 bytes :to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm, :are there any backward compatibility problems ? :There would be a lateral compatibility problem, in that the :parm passed from JCL would have a format different from the :parm passed by other languages, thereby violating one of :the oldest conventions of OS/360. Huh? :Put the length of the parm, whatever length, in the HW. It's :how all languages that support long parms now do it. The suffix does not violate compatibility. A CVT bit could indicate the support for the suffix. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote: On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote: :On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote: :If the current JCL PARM format change from HW + 0-100 bytes :to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm, :are there any backward compatibility problems ? :There would be a lateral compatibility problem, in that the :parm passed from JCL would have a format different from the :parm passed by other languages, thereby violating one of :the oldest conventions of OS/360. Huh? :Put the length of the parm, whatever length, in the HW. It's :how all languages that support long parms now do it. The suffix does not violate compatibility. A CVT bit could indicate the support for the suffix. So that a program that works with a long parm today, such as the Assembler, would have to be modified to test the CVT and look in a new place for the long parm. A poor solution, IMO. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote: Don't we then have a usage problem here ? I'm thinking of thousands of sites with many more programmers and operators etc. that have to deal with - now - two forms of parms. I'm thinking of some sort of caos... And don't we still have the problem of powerful system modules that (although somewhat wrongly) depends on JCL parm never having more that 100 bytes ? ... Today, any programmer can invoke such powerful system modules from Assembler, Rexx, or several other languages with a long PARM (or a short PARM. Simply, they will execute unauthorized (unless the caller was authorized). If the rule were that specifying PARMX caused the PGM always to be run unauthorized, the hazard would be removed. ... (Will PARMX appear as an ordinarie parm to the receiving program ?) I would hope so, to avoid the chaos you fear. (Operators shouldn't be concerned with PARM. Perhaps production supervisors.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On 2 Nov 2009 10:23:59 -0800, in bit.listserv.ibm-main you wrote: On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote: Don't we then have a usage problem here ? I'm thinking of thousands of sites with many more programmers and operators etc. that have to deal with - now - two forms of parms. I'm thinking of some sort of caos... And don't we still have the problem of powerful system modules that (although somewhat wrongly) depends on JCL parm never having more that 100 bytes ? ... Today, any programmer can invoke such powerful system modules from Assembler, Rexx, or several other languages with a long PARM (or a short PARM. Simply, they will execute unauthorized (unless the caller was authorized). If the rule were that specifying PARMX caused the PGM always to be run unauthorized, the hazard would be removed. ... (Will PARMX appear as an ordinarie parm to the receiving program ?) I would hope so, to avoid the chaos you fear. (Operators shouldn't be concerned with PARM. Perhaps production supervisors.) Any authorized program that didn't verify that the parm length was acceptable was poorly coded. I know that my programs checked for maximum value and also minimum values so that I knew that the program didn't pick up garbage. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
snip There is NO REASON to send a Long Parm to these IBM utilities Of course there is. It ignores, e.g., IBM compilers. --unsnip--- IIRC, the IBM compilers will also accept a *PROCESS statement that can be as long as necessary. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I would prefer to be able to pass a long parm to authorized programs. Authorized programs should be well written to check everything it receives, otherwise it is a security risk. In other words, an authorized program should always be written to prevent any detrimental activity, malicious or otherwise. If it doesn't, I would consider it broken and in need of repair. However, I understand that there could be situations where it might not be feasible to fix them. I would prefer an option to use a security class/profile control the use of PARMX. Perhaps something like class FACILITY profile JCL.EXEC.PARMX.program-name. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, November 02, 2009 1:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: An Alternative Modest PARM Proposal On Mon, 2 Nov 2009 18:57:49 +0100, Thomas Berg wrote: Don't we then have a usage problem here ? I'm thinking of thousands of sites with many more programmers and operators etc. that have to deal with - now - two forms of parms. I'm thinking of some sort of caos... And don't we still have the problem of powerful system modules that (although somewhat wrongly) depends on JCL parm never having more that 100 bytes ? ... Today, any programmer can invoke such powerful system modules from Assembler, Rexx, or several other languages with a long PARM (or a short PARM. Simply, they will execute unauthorized (unless the caller was authorized). If the rule were that specifying PARMX caused the PGM always to be run unauthorized, the hazard would be removed. ... (Will PARMX appear as an ordinarie parm to the receiving program ?) I would hope so, to avoid the chaos you fear. (Operators shouldn't be concerned with PARM. Perhaps production supervisors.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 21:16:42 +0100, Thomas Berg wrote: If we really go the new syntax road, I liked the suggestion, by someone I don't remember for the moment, that we introduce a new JCL operand: // PARM '...' I like that partly beacuse of possibility to have a concatenate function like: // PARM 'part 1 .' // PARM 'part 2 .' // PARM 'part 3 .' etc. An easy way to input a long parm (in JCL). That would be of considerable value even given the 100-character limit. PARM continuation is a PITA, particularly when the JCL is being generated by a program. OTOH, JCL symbols provide fast symptomatic relief: PARM='PART1PART2PART3' *BUT*, we still we have the problem of backward incompatibility regardless of the input format... As long as authorized programs are excluded, no new incompatibility is introduced. Any programmer can today call any unauthorized program with Rexx with a 65,535 character PARM. ... PARM = d2c( 65535 )left( 'WOMBAT', 65535 ) address ATTCHPGM 'MYPROGM PARM' ... But that's not a solution because it's cumbersome and doesn't support the use of JCL symbols. Regarding John M's suggestion of using STEPLIB to suppress execution in authorized state: o I'm uneasy with such reliance on a side effect; it lacks referential transparency (not that that's ever been much a concern in the design of JCL). o It leaves too great a hazard of inadvertently executing a program in authorized state with a long PARM, either - because the programmer doesn't supply a STEPLIB and symbol substitution unexpectedly creates a long PARM - or because the data set the programmer supplies is later marked authorized without consideration of the indirect consequence. Tom M. has supplied an example. Regarding Clark M's assertion: Any authorized program that didn't verify that the parm length was acceptable was poorly coded. I know that my programs checked for maximum value and also minimum values so that I knew that the program didn't pick up garbage. Kudos. But even representatives of the most reputable organizations can slip up: Linkname: Re: Long parms ... again (was: Reading DD card information) URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainamp;P=153276 (My apologies for misattributing this to John EElls; it was Jim Mulder, citing a survey by Karl Schmitz.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 14:47:12 -0600, Rick Fochtman wrote: snip There is NO REASON to send a Long Parm to these IBM utilities Of course there is. It ignores, e.g., IBM compilers. --unsnip--- IIRC, the IBM compilers will also accept a *PROCESS statement that can be as long as necessary. o Have you checked _all_ the compilers? What about HLASM? o What about ISV programs and even user programs? o Does this support JCL symbol substitution in the body of the *PROCESS statement? (I suspect not.) Admitted, I've been able to pass long parms to programs from Rexx. And even to manufacture those parms using JCL symbols passed in the parm to Rexx. The Modest Proposal under discussion here is to make the operation simpler. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 11:32:34 -0600 Tom Marchant m42tom-ibmm...@yahoo.com wrote: :On Mon, 2 Nov 2009 18:59:19 +0200, Binyamin Dissen wrote: :On Mon, 2 Nov 2009 10:50:06 -0600 Paul Gilmartin paulgboul...@aim.com wrote: ::On Mon, 2 Nov 2009 13:40:44 +0100, Thomas Berg wrote: ::If the current JCL PARM format change from HW + 0-100 bytes ::to HW + 100 bytes + FW for the new long parm + 0-??? bytes long parm, ::are there any backward compatibility problems ? ::There would be a lateral compatibility problem, in that the ::parm passed from JCL would have a format different from the ::parm passed by other languages, thereby violating one of ::the oldest conventions of OS/360. :Huh? ::Put the length of the parm, whatever length, in the HW. It's ::how all languages that support long parms now do it. :The suffix does not violate compatibility. A CVT bit could indicate the :support for the suffix. :So that a program that works with a long parm today, such as the Assembler, :would have to be modified to test the CVT and look in a new place for the :long parm. A poor solution, IMO. Compatibility has its costs. This solution does not change the number of parameters and is completely compatible. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: an alternative modest PARM proposal
| Of course there is. It ignores, e.g., IBM compilers. | | --unsnip--- | | IIRC, the IBM compilers will also accept a *PROCESS | statement that can be as long as necessary. You don't remember correctly. Some process statements are limiteds to a proper substring of a card image. Multiple process statements are, however, often supported. Le bon Dieu est dans le détail. John Gilmore Ashland, MA 01721-1817 USA _ Hotmail: Trusted email with Microsoft's powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ http://clk.atdmt.com/GBL/go/177141664/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
At 11:26 -0600 on 11/01/2009, Rick Fochtman wrote about Re: An Alternative Modest PARM Proposal: -snip- There is NO REASON to send a Long Parm to these IBM utilities so this potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPRM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. unsnip-- Do you intend to include in that list the potentially thousands of application programs that might accept a parm string in any business shop? And parse that list at IPL time? Or at program initiation time? What about existing apps that nobody can even remember the details inside? Why not? For ISV code they just supply the needed PARMLIB member as they currently do. As for RYO code, the program is BAD (Broken As Designed) if it accepts additional parms when called as opposed to JCL Launched and does not validate them. Note that my comment is NOT about passing a longer than 100 byte parm as the ONLY entry in the passed Parm List but passing a 2 entry parm with the 2nd entry as the extended parm. The only case where there would be a conflict (and thus a need to suppress the passing of the PARMX) is for those programs ALREADY able to be passed a mult-parm parm list WHEN CALLED. All other programs would need to be written to look for a 2nd parm with an PARMX longer string. If you have multi-parm accepting programs you are unaware of, WHY are you attempting to pass them a PARMX via JCL in the first place? Remember that you need to add the support in the first place and thus it is an error to just code a PARMX for a program that will not accept it (independent of the CALLED PARMLIST issue). You also have the sanity check issue I mentioned above where the PARMX attempt should cause the program to reject the PARMX or malfunction and this signal the need to fix the JCL to remove the erroneous PARMX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about Re: An Alternative Modest PARM Proposal: There is NO REASON to send a Long Parm to these IBM utilities Of course there is. It ignores, e.g., IBM compilers. When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept a longer than 100 character PARM Entry (while also accepting DDNAME Overrides in Parms 2+)? If so THEN you have a conflict with using a PARMX. If the passed PARM is still only 100 bytes even when called, there is no issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 16:58:37 -0500, Robert A. Rosenberg wrote: At 12:58 -0500 on 11/01/2009, Shmuel Metz (Seymour J.) wrote about Re: An Alternative Modest PARM Proposal: There is NO REASON to send a Long Parm to these IBM utilities Of course there is. It ignores, e.g., IBM compilers. When CALLED as opposed to JCL LAUNCHED, do these IBM Compilers accept a longer than 100 character PARM Entry (while also accepting DDNAME Overrides in Parms 2+)? If so THEN you have a conflict with using a PARMX. If the passed PARM is still only 100 bytes even when called, there is no issue. First, as Shmuel notes, most programs don't differentiate between being CALLED and JCL LAUNCHED. They're oblivious, and it's pretty hard to tell; parameters is parameters. If a second parameter is present, it shall be taken as a ddnamelist. Then, as I cited yesterday (but I also often fail to read the preceding plies in threads): Linkname: Invoking the assembler dynamically URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMP1020/7.5 Clearly mentions that ddnamelist is supported, but omits mention of a limit of length of optionlist. RCF submitted. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Mon, 2 Nov 2009 23:50:17 +0200, Binyamin Dissen wrote: :The suffix does not violate compatibility. A CVT bit could indicate the :support for the suffix. :So that a program that works with a long parm today, such as the Assembler, :would have to be modified to test the CVT and look in a new place for the :long parm. A poor solution, IMO. Compatibility has its costs. This solution does not change the number of parameters and is completely compatible. You and I have diametrically opposed perspectives of compatibility. To me, compatibility means the facility to call a program from JCL with a long PARM presenting exactly the same interface as today when it's called from other languages (such as Rexx), and requiring modification neither of the target program nor of the calling language (i.e. Rexx). You seem to advocate that the interface when called from JCL should differ from the interface when called from Rexx, etc. I can't view that as compatible. Yes, some programs would break if they could be called from JCL with long parms, identically as they'd break if called from Rexx, etc. with the same parms. Even that identical behavior in breakage is a form of compatibility. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
You and I have diametrically opposed perspectives of compatibility. To me, compatibility means the facility to call a program from JCL with a long PARM presenting exactly the same interface as today when it's called from other languages (such as Rexx), and requiring modification neither of the target program nor of the calling language (i.e. Rexx). You seem to advocate that the interface when called from JCL should differ from the interface when called from Rexx, etc. I can't view that as compatible. Yes, some programs would break if they could be called from JCL with long parms, identically as they'd break if called from Rexx, etc. with the same parms. Even that identical behavior in breakage is a form of compatibility. The PARM interface is older than dirt and even though we can all agree with hindsight that it was a momentously stupid design, it is nevertheless a formal, documented interface and literally thousands of badly written programs work correctly ONLY because the initiator is never going to give them a parameter string of more that 100 characters. That's the one and only interface contract. The assertion that you can find programs that behave well when called directly with longer parameter strings is also true, but completely uninteresting. Changing the behavior of PARM is fraught with incompatibilities. So much so that wiser heads elected not to pull the trigger on it. There are lots of ways of enabling (much longer) parameter strings but they all necessarily involve defining some brand new and non- overlapping interface definition. New programs written to the putative new parameter interface spec will work correctly and completely oblivious of the old spec. And since the existing PARM interface will remain unchanged, all old programs will continue work as they do now, completely oblivious of any new interface. THAT my friends is compatibility. Not elegant, not pretty, but guaranteed compatible. Now can we all just get over this nonsense? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
-snip- There is NO REASON to send a Long Parm to these IBM utilities so this potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPARM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. unsnip-- Do you intend to include in that list the potentially thousands of application programs that might accept a parm string in any business shop? And parse that list at IPL time? Or at program initiation time? What about existing apps that nobody can even remember the details inside? Rick --- Accept the fact that some days you're the pigeon, other days you're the statue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
Accept the fact that some days you're the pigeon, other days you're the statue. Also, accept the fact that as long as you only discuss it on IBM-Main, nothing will happen. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In p06240806c7116c639...@[192.168.1.11], on 10/31/2009 at 12:33 AM, Robert A. Rosenberg hal9...@panix.com said: There is NO REASON to send a Long Parm to these IBM utilities Of course there is. It ignores, e.g., IBM compilers. Does this help? No. It ignores problems with the 100 character limit going back to the 1960's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In p0624080ac7110bd5f...@[192.168.1.11], on 10/30/2009 at 05:42 PM, Robert A. Rosenberg hal9...@panix.com said: OK. The current standard is a single FW (with the high bit set) pointing at a HW with length followed by 0-100 bytes of data (the FW being pointed to by R1). No, the current standard is that bit 0 indicates the end of the list and that the first word points to a halfword length followed by characters. The 100 character limit is strictly a C/I limited, and various IBM utilities accept longer parms. Make the new method a 2 FW Parm list with FW 1 pointing at the old 100 character PARM and FW 2 (which is End of Parmlist flagged) pointing at the new Long Parm. That would break compatibility badly. BTW: There are a number of IBM utilities that ALREADY check the length of their Parmlist since they support being launched by JCL with a PARM and being CALLED with a real muli-parm parmlist (the 2nd and subsequent parms often being DDN overrides). Which is one of the reasons why your suggestion won't fly. BTW, I had forgotten about an old (1995) post from Don Ault in which he said that IBM will not implement long parms in a fashion incompatible with the existing interface. He left it open as to whether the length field would be signed or unsigned. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote: At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An Alternative Modest PARM Proposal: Therefore, you should understand very well why this won't work. Such utilities will misinterpret the Long Parm as a DDN override list. There is NO REASON to send a Long Parm to these IBM utilities so this Very wrong! RTFM. Namely: Linkname: Invoking the assembler dynamically, 7.5 URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmp1020/7.5 Harsh langage? Perhaps, but: o You're the one who started shouting (NO REASON). o I'm weary of writers spreading disinformation on this topic with the goal of inciting FUD. Not a utility, precisely, but a supported and widely used IBM program. And I personally have usefully called HLASM (from Rexx) with a PARM exceeding 100 characters. I recognized this to my frustration when I attempted to replace the Rexx with JCL. potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPARM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. Does this help? No. Far too much an administrative burden. It'll never fly. I have a better idea. Indicate to the program that it's being passed a long PARM by calling it with R1 pointing to a fullword (with the sign bit set) addressing a halfword containing a value greater than or equal to 101, followe by the parameter string. Indicate to the program that it's being passed an old-fashioned PARM by calling it with R1 addressing a fullword (with the sign bit set) addressing a halfword containing a value less than or equal to 100, followed by the parameter string. Fully compatible with the current behavior of HLASM and many other programs, and no added administrative duties. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Sat, 31 Oct 2009 00:33:10 -0400, Robert A. Rosenberg wrote: At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An Alternative Modest PARM Proposal: Therefore, you should understand very well why this won't work. Such utilities will misinterpret the Long Parm as a DDN override list. There is NO REASON to send a Long Parm to these IBM utilities so this Very wrong. RTFM. Namely: Linkname: Invoking the assembler dynamically URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMP1020/7.5 Harsh language? Perhaps. However: o You're the one who started shouting (NO REASON). o I'm weary of writers spreading disinformation on this topic with the goal of inciting FUD. Not precisely a utility, but a very standard and widely used IBM program which accepts both an alternate DDNAME list and to which I have long been usefuly passing a long PARM (from Rexx), as I realized with dismay when I attempted to convert the Rexx to JCL. potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPARM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. Does this help? No. It's an unacceptable burden to administrators, and even to maintainers of IBM utilities themselves. I have a better idea. Indicate to a program that it's being invoked with a long parm by placing in R1 the address of a fullword (with the sign bit set) addressing a halfword containing a value greater than or equal to 101, followed by the parameter string. Indicate to a program that it's being passed an old-fashioned PARM by placing in R1 the address of a fullword (with the sign bit set) addressing a halfword containing a value less than or equal to 101, followed by the parameter string. This is fully compatible with the existing design of HLASM and many other IBM and ISV programs, and places no new duties on adminstrators. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P. Baker Sent: Thursday, October 29, 2009 4:29 PM To: IBM-MAIN@bama.ua.edu Subject: An Alternative Modest PARM Proposal All, The proposal previously set forth is interesting, but I would like to put forward an alternative proposal. For a short PARM= value (compatibility mode), R1 - fullword address of PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by a string buffer not exceeding 100 bytes. For a long PARM= value, R1 - fullword address of PARM= info, consisting of a 4-byte length prefix (negated (high-order bit = B'1'), value 101..installation-defined-maximum), followed by a fullword address of a string buffer not exceeding installation-defined-maximum bytes, followed by a fullword ALET identifying the dataspace wherein the string buffer is located. FWIW, z/VSE currently allows a maximum PARM= length of 300 bytes, coded in up to three (3) PARM=value specifications on an EXEC statement, with the values being concatenated by the JCL processor. John P. Baker Same problem with this as with all others. You have changed the interface expected by OLD code. Suppose your old code is coded for the current standard. If someone used a long PARM, then your old code will fail. Any changes to this must keep the current interface as it currently is. I still like using POSIX environment variables and being able to set them at the job level via JCL. Then just use the getenv() type call to get the value for any particular variable you're expecting. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In listserv%200910291643073774.0...@bama.ua.edu, on 10/29/2009 at 04:43 PM, Paul Gilmartin paulgboul...@aim.com said: Aren't we going overboard here? While 100 characters in JCL is painfully constraining, and 255 might be an uncomfortable limit, any programmer who feels the need for 65535 in JCL, even mechanically generated JCL, should probably choose a different language. Personally, I could live with 32 KiB - 1. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
In 00fa01ca58de$cbaac1b0$630045...@net, on 10/29/2009 at 05:28 PM, John P. Baker jbaker...@comporium.net said: The proposal previously set forth is interesting, but I would like to put forward an alternative proposal. Actually, it's a proposal for an alternative goal. My goal was to preserve compatibility with existing code. For a long PARM= value, R1 - fullword address of PARM= info, consisting of a 4-byte length prefix (negated (high-order bit = B'1'), value 101..installation-defined-maximum), followed by a fullword address of a string buffer not exceeding installation-defined-maximum bytes, followed by a fullword ALET identifying the dataspace wherein the string buffer is located. That might be a good design for a new system with no compatibility constraints, but it destroys compatibility with existing code. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
At 07:29 -0500 on 10/30/2009, McKown, John wrote about Re: An Alternative Modest PARM Proposal: Same problem with this as with all others. You have changed the interface expected by OLD code. Suppose your old code is coded for the current standard. If someone used a long PARM, then your old code will fail. Any changes to this must keep the current interface as it currently is. OK. The current standard is a single FW (with the high bit set) pointing at a HW with length followed by 0-100 bytes of data (the FW being pointed to by R1). Make the new method a 2 FW Parm list with FW 1 pointing at the old 100 character PARM and FW 2 (which is End of Parmlist flagged) pointing at the new Long Parm. The only GOTHCHA with an old style program is if it gets paranoid and actually checked the end-of-parmlist flag on the single FW it expects to be passed to it. BTW: There are a number of IBM utilities that ALREADY check the length of their Parmlist since they support being launched by JCL with a PARM and being CALLED with a real muli-parm parmlist (the 2nd and subsequent parms often being DDN overrides). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Fri, 30 Oct 2009 17:42:09 -0400, Robert A. Rosenberg wrote: At 07:29 -0500 on 10/30/2009, McKown, John wrote about Re: An Alternative Modest PARM Proposal: Same problem with this as with all others. You have changed the interface expected by OLD code. Suppose your old code is coded for the current standard. If someone used a long PARM, then your old code will fail. Any changes to this must keep the current interface as it currently is. OK. The current standard is a single FW (with the high bit set) pointing at a HW with length followed by 0-100 bytes of data (the FW being pointed to by R1). Make the new method a 2 FW Parm list with FW 1 pointing at the old 100 character PARM and FW 2 (which is End of Parmlist flagged) pointing at the new Long Parm. The only GOTHCHA with an old style program is if it gets paranoid and actually checked the end-of-parmlist flag on the single FW it expects to be passed to it. BTW: There are a number of IBM utilities that ALREADY check the length of their Parmlist since they support being launched by JCL with a PARM and being CALLED with a real muli-parm parmlist (the 2nd and subsequent parms often being DDN overrides). Therefore, you should understand very well why this won't work. Such utilities will misinterpret the Long Parm as a DDN override list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
--snip OK. The current standard is a single FW (with the high bit set) pointing at a HW with length followed by 0-100 bytes of data (the FW being pointed to by R1). Make the new method a 2 FW Parm list with FW 1 pointing at the old 100 character PARM and FW 2 (which is End of Parmlist flagged) pointing at the new Long Parm. The only GOTHCHA with an old style program is if it gets paranoid and actually checked the end-of-parmlist flag on the single FW it expects to be passed to it. BTW: There are a number of IBM utilities that ALREADY check the length of their Parmlist since they support being launched by JCL with a PARM and being CALLED with a real muli-parm parmlist (the 2nd and subsequent parms often being DDN overrides). ---unsnip What's to stop older programs from interpreting the second FW as a pointer to a DDNAME list? Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
At 17:40 -0500 on 10/30/2009, Paul Gilmartin wrote about Re: An Alternative Modest PARM Proposal: Therefore, you should understand very well why this won't work. Such utilities will misinterpret the Long Parm as a DDN override list. There is NO REASON to send a Long Parm to these IBM utilities so this potential glitch can easily be handled by a new PARMLIB member with a list of programs that are NOT to be passed an extended parm (IBM knows who they are and the NOXPARM00 member can be supplied with the PTF or FUNCTION that adds PARMX Support). For ISV (and Home Grown RYO) utilities that accept mult-parm parmlibs, have the vendor/author supply the needed members to be placed into PARMLIB. Does this help? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
On Thu, 29 Oct 2009 17:28:44 -0400, John P. Baker wrote: For a short PARM= value (compatibility mode), R1 - fullword address of PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by a string buffer not exceeding 100 bytes. For a long PARM= value, R1 - fullword address of PARM= info, consisting of Again, NO! Provide in JCL the facility now provided by Rexx address ATTCHMVS, in a completely compatible fashion. a 4-byte length prefix (negated (high-order bit = B'1'), value 101..installation-defined-maximum), followed by a fullword address of a string buffer not exceeding installation-defined-maximum bytes, followed by a fullword ALET identifying the dataspace wherein the string buffer is located. An interesting alternative. But why not just use 64-bit addressing? dataspaces are _so_ 20th century. How does the JCL programmer specify the dataspace? Or does the Interpreter select one by colonic extraction? Aren't we going overboard here? While 100 characters in JCL is painfully constraining, and 255 might be an uncomfortable limit, any programmer who feels the need for 65535 in JCL, even mechanically generated JCL, should probably choose a different language. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: An Alternative Modest PARM Proposal
I think that would break many programs. Many standard utilities, compilers, etc. expect to invoked from either JCL where there is only one parm or dynamically called with one or more parms. Off the top of my head I can't remember for format of the second parm other than it is used to dynamically change the standard DDNAMEs to user specified. This mean that if you accidently executed one of those programs with PARMX='' it would get all confused. I still vote for a simple PARMX='long-string' where the GPR1 - fullword (w/ high bit set to 1) - 2-byte-length followed by a long string. I originally said that the max length could be 32k-1 or 64k-1, but only because that's was a convenient max for a 2 byte length field. However, a max size even as small as 1024 to 4096 would very likely satisfy well over 99% of anyone's true need to pass a long parm. I find it difficult to envision JCL with a parm string that was many thousands of characters long (that's a lot of continuations). Besides there are very likely other limits in the converter/interpreter, text units, JES, etc. that would make massively long parms difficult to implement. If even longer parms are needed, the various current methods to pass longer parms by dynamically calling the program could still be used. I think that my proposal seems to be the simplest (KISS), seems likely to break fewer things, and the very important to IBM, cheaper to design, implement, and test while satisfying many customer's long standing desire to have a much long parm field. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John P. Baker Sent: Thursday, October 29, 2009 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: An Alternative Modest PARM Proposal All, The proposal previously set forth is interesting, but I would like to put forward an alternative proposal. For a short PARM= value (compatibility mode), R1 - fullword address of PARM= info, consisting of a 2-byte length prefix (value 0..100) followed by a string buffer not exceeding 100 bytes. For a long PARM= value, R1 - fullword address of PARM= info, consisting of a 4-byte length prefix (negated (high-order bit = B'1'), value 101..installation-defined-maximum), followed by a fullword address of a string buffer not exceeding installation-defined-maximum bytes, followed by a fullword ALET identifying the dataspace wherein the string buffer is located. FWIW, z/VSE currently allows a maximum PARM= length of 300 bytes, coded in up to three (3) PARM=value specifications on an EXEC statement, with the values being concatenated by the JCL processor. John P. Baker -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
