Re: How long can a TSO command be?
On Thu, 10 Mar 2016 17:29:40 -0800, retired mainframer wrote: >Wouldn't it be easier to take a command like LISTDS and paste a couple of >dozen (or hundred) DSNs between the parentheses and see when it finally >complains rather than see how many ways this thread can be hijacked. > Excellent idea! Thanks! Concatenating 255 members in a 14553-character ALLOCATE command succeeds; takes 22 seconds; 256 exceeds an allocation limit. I see no practical limit to command length. Terminal windows impose their own limits, sometimes of necessity, sometimes frivolously. (No need for LISTDS; ALLOCATE doesn't require members to exist.) I don't consider this thread severely hijacked. For a Friday. Thanks again, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On Thu, 10 Mar 2016 20:33:11 -0500, Ted MacNEIL wrote: >I believe a path can be up to 1024. > Sort of. IIRC, that's the value in the Users Guide, Command Ref., et al. But it's subject to change with new filesystypes. It might be different in a future OS release. Hopefully not smaller. Legacy UNIX systems define a constant, PATH_MAX. POSIX deprecates this (see above) and z/OS UNIX does not provide it. The recommendation is a query, "PATH_MAX = pathconf( *file_name, _PC_PATH_MAX )". But Allocation imposes its own limit of 256, incomprehensible in that the length field of a TU is a halfword. And Allocation should not attempt to enforce any limit; it should call the kernel services with whatever it's given, up to 32767, and diagnose any error response from kernel. Likewise for TSO TMP and JCL C/I. Resolution of symbolic links can result in a resolved pathname longer or shorter than coded. I need to try an experiment. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
W dniu 2016-03-10 o 22:26, Paul Gilmartin pisze: Got my Black Team coat on. Is there any limit to the length of a TSO command other than that imposed by the aggregate length of the various operands? I think the limit is 32kB. Of course other limits, like p.6 "screen capacity" apply. However I don't remember where I saw this number. -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On Thu, 10 Mar 2016 15:26:13 -0600 Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: :>Got my Black Team coat on. :>Is there any limit to the length of a TSO command other than that imposed by :>the aggregate length of the various operands? :>ISPF Command Shell imposes a limit of 240. Absurdly small given that a PATH() :>for ALLOCATE may be up to 255. :>Panel ISRTSOA accepts 3 x ZSCREENW then quietly truncates to 240. I loathe :>quiet truncation. :>What's the API for TSO commands called so I can look it up? CPPLCBUF has a two byte length. I would expect all programs treat it as signed. :>BTW, similar question for JCL statements. Remember that symbol substitution :>may result in a statement (much) shorter than coded. Oh, I ain't gonna touch that. -- Binyamin Dissen 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
I believe a path can be up to 1024. -teD Original Message From: Paul Gilmartin Sent: Thursday, March 10, 2016 20:04 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: How long can a TSO command be? On Thu, 10 Mar 2016 17:38:27 -0500, Steve Thompson wrote: >On 03/10/2016 04:26 PM, Paul Gilmartin wrote: >> Got my Black Team coat on. >It depends. You doing SUBMIT? You feeding your JCL to the INTRDR >with JES2 or JES3? > I know that in JES2 only cols 1-72 of the source statement are processed. 73-80 are only listed; 81 and beyond vanish completely. FTP enforces a limit of 254. I believe this is an obsolete JES3 limit. SYSIN may be far longer; I've encountered no practical limit. Symbol substitution and continuation may result in a statement shorter or longer than the source. I'm idly curious (Black Team) what limit exists on the source. >Are you expecting your PARM= to be limited to 100 characters, or >would you like it to be more than that (PARMDD in the JCL REF >z/OS 2.1). > PARMDD is a kludge. They ought simply to have allowed a longer PARM. If PARMDD allows substitution of system symbols, that should have been supported likewise in EXEC PARM. >And, off the top of my head, TSO has a limit of 256 characters. >But I haven't needed to deal with that problem for a decade or so. > By experiment, ALLOCATE PATH supports longer, but I don't know how much longer, nor whether any limit exists in the API, at the READY prompt, or both. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
Wouldn't it be easier to take a command like LISTDS and paste a couple of dozen (or hundred) DSNs between the parentheses and see when it finally complains rather than see how many ways this thread can be hijacked. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, March 10, 2016 1:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: How long can a TSO command be? > > Got my Black Team coat on. > > Is there any limit to the length of a TSO command other than that imposed by > the aggregate length of the various operands? > > ISPF Command Shell imposes a limit of 240. Absurdly small given that a PATH() > for ALLOCATE may be up to 255. > > Panel ISRTSOA accepts 3 x ZSCREENW then quietly truncates to 240. I loathe > quiet truncation. > > What's the API for TSO commands called so I can look it up? > > BTW, similar question for JCL statements. Remember that symbol substitution > may result in a statement (much) shorter than coded. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
Paul: Too bad Schmuel isn't still around he could make the argument . The "design" "flaw" is embedded in the OS all over the place from start to finish. It would break existing code and some code (like TSO) that it would not work anymore as that is one of the many reasons TSO is dead (you pick your word). It would break just about all user code and it would have to be rewritten as well. From Compiler to OS it would just break. MVS would probably have to be rewritten from scratch. It could probably be done but with the rewrite of user code, the community wouldn't stand for it. Ed On Mar 10, 2016, at 6:34 PM, Paul Gilmartin wrote: On Thu, 10 Mar 2016 18:20:42 -0600, Ed Gould wrote: On Mar 10, 2016, at 5:08 PM, Paul Gilmartin wrote: PARMDD is a kludge. They ought simply to have allowed a longer PARM. If PARMDD allows substitution of system symbols, that should have been supported likewise in EXEC PARM. Paul: If you change the 255 character limit you will break the entire OS. It was a design flaw from day 1, although you would never get the designers to acknowledge it. Which "255 character limit"? And "break the entire OS" is a pretty sweeping statement. But I suppose that if it prevented IPL the entire OS could be considered broken. But surely they could fix that. Storage was expensive when some of those limits were set. It's now almost a million times cheaper. It's time that was exploited. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On Thu, 10 Mar 2016 18:20:42 -0600, Ed Gould wrote: >On Mar 10, 2016, at 5:08 PM, Paul Gilmartin wrote: >>> >> PARMDD is a kludge. They ought simply to have allowed a longer PARM. >> If PARMDD allows substitution of system symbols, that should have been >> supported likewise in EXEC PARM. > >Paul: > >If you change the 255 character limit you will break the entire OS. >It was a design flaw from day 1, although you would never get the >designers to acknowledge it. > Which "255 character limit"? And "break the entire OS" is a pretty sweeping statement. But I suppose that if it prevented IPL the entire OS could be considered broken. But surely they could fix that. Storage was expensive when some of those limits were set. It's now almost a million times cheaper. It's time that was exploited. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On Mar 10, 2016, at 5:08 PM, Paul Gilmartin wrote: PARMDD is a kludge. They ought simply to have allowed a longer PARM. If PARMDD allows substitution of system symbols, that should have been supported likewise in EXEC PARM. Paul: If you change the 255 character limit you will break the entire OS. It was a design flaw from day 1, although you would never get the designers to acknowledge it. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On 10 March 2016 at 16:26, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > Is there any limit to the length of a TSO command other than that imposed by the aggregate length of the various operands? IKJSCAN and IKJPARSE are probably what define this, though there may be other de facto limits. But all the TSO service routines deal with buffers starting with a halfword length which includes the length of itself and the next halfword. Here's the doc from the MVS 3.8 source for IKJPARS: * THE COMMAND BUFFER IS OF THE FORM - * * * * *** * * BUFFER:/ LENGTH/ OFFSET / TEXT /* * *** * * OFFSET: 02 4 * * * * THE LENGTH INCLUDES THE LENGTH OF THE LENGTH AND OFFSET FIELDS* * WITH THE BUFFER OFFSET POINTING TO THE LOCATION IN THE BUFFER * * WHERE PARSE IS TO BEGIN SCANNING. THE COMMAND SCAN SERVICE* * ROUTINE PREVIOUSLY UPDATED THE OFFSET PAST THE COMMAND NAME. * SCAN is typically looking at just the first few bytes of the buffer, but in theory you could pass in a very long buffer with the command in the last few bytes. So I'd say in theory a command could be 32k-4 or 64k-4 bytes long. > ISPF Command Shell imposes a limit of 240. Absurdly small given that a PATH() > for ALLOCATE may be up to 255. Sure. But ISPF has blatantly ignored many of the basic rules of TSO pretty much from the beginning. As have a whole new generation of IBM developers who've written non conforming TSO commands. > What's the API for TSO commands called so I can look it up? API to do what - invoke a command? Within ISPF I have no idea. And there isn't really a native TSO API to say "run this command". You set up the command buffer, and the CPPL which points to it, and ATTACH the program that is the command. Well, there is Johnny-come-lately IKJEFTSR, and if documents the command buffer length (without the two halfwords) as 32767, even though the length field is a fullword. Tony H. Tony H...fff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On Thu, 10 Mar 2016 17:38:27 -0500, Steve Thompson wrote: >On 03/10/2016 04:26 PM, Paul Gilmartin wrote: >> Got my Black Team coat on. >It depends. You doing SUBMIT? You feeding your JCL to the INTRDR >with JES2 or JES3? > I know that in JES2 only cols 1-72 of the source statement are processed. 73-80 are only listed; 81 and beyond vanish completely. FTP enforces a limit of 254. I believe this is an obsolete JES3 limit. SYSIN may be far longer; I've encountered no practical limit. Symbol substitution and continuation may result in a statement shorter or longer than the source. I'm idly curious (Black Team) what limit exists on the source. >Are you expecting your PARM= to be limited to 100 characters, or >would you like it to be more than that (PARMDD in the JCL REF >z/OS 2.1). > PARMDD is a kludge. They ought simply to have allowed a longer PARM. If PARMDD allows substitution of system symbols, that should have been supported likewise in EXEC PARM. >And, off the top of my head, TSO has a limit of 256 characters. >But I haven't needed to deal with that problem for a decade or so. > By experiment, ALLOCATE PATH supports longer, but I don't know how much longer, nor whether any limit exists in the API, at the READY prompt, or both. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How long can a TSO command be?
On 03/10/2016 04:26 PM, Paul Gilmartin wrote: Got my Black Team coat on. Is there any limit to the length of a TSO command other than that imposed by the aggregate length of the various operands? ISPF Command Shell imposes a limit of 240. Absurdly small given that a PATH() for ALLOCATE may be up to 255. Panel ISRTSOA accepts 3 x ZSCREENW then quietly truncates to 240. I loathe quiet truncation. What's the API for TSO commands called so I can look it up? BTW, similar question for JCL statements. Remember that symbol substitution may result in a statement (much) shorter than coded. -- gil It depends. You doing SUBMIT? You feeding your JCL to the INTRDR with JES2 or JES3? Are you expecting your PARM= to be limited to 100 characters, or would you like it to be more than that (PARMDD in the JCL REF z/OS 2.1). And, off the top of my head, TSO has a limit of 256 characters. But I haven't needed to deal with that problem for a decade or so. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How long can a TSO command be?
Got my Black Team coat on. Is there any limit to the length of a TSO command other than that imposed by the aggregate length of the various operands? ISPF Command Shell imposes a limit of 240. Absurdly small given that a PATH() for ALLOCATE may be up to 255. Panel ISRTSOA accepts 3 x ZSCREENW then quietly truncates to 240. I loathe quiet truncation. What's the API for TSO commands called so I can look it up? BTW, similar question for JCL statements. Remember that symbol substitution may result in a statement (much) shorter than coded. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
