Re: PARM=
Skip Robinson wrote: [snip] Let's just KISS: increase the allowable string length to 256. That should be plenty for any well-designed application. [snip] I would say 4K would be a better number. If you wanted to pass two path names, an input and an output for instance, that would easily use up your 256 limit even though the parm strings themselves would be easy to read and understand. If someone is going to take the time, money and trouble to fix this, they may as well make the buffer so large that only extremely badly designed programs will run into the limitation. As you point out, abuse of the large parm string may occur, but that's shouldn't be JCLs concern, it should be the program designer's. Robin Murray Tel: (902) 453-7300 x4177 Cell: (902) 430-0637 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Fri, May 13, 2005 at 08:13:39AM -0400, Bob Shannon wrote: Seriously, we're talking about a parameter. I agree that 256 bytes ought to be sufficient. Indeed. I can't recall where I read it, but someone suggested that program designers avoid constraints that are powers of ten, for they are likely to be seen as artificial constraints rather than legitimate limits imposed by the design. There are good technical reasons for a 256-byte limit on parm length (MVC), and that would seem to be a good dividing line between what belongs on a PARM statement and what belongs elsewhere just for the sake of manageability. What would be a real advance is being able to provide SYSIN to a started task or other JCL proc without having to go through the gyrations of having a separate dataset... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Miklos Szigetvari Hi I would vote for the DD solution. A reserved (maybe changeable) DD name for the long PARM's That is already available. See, e.g., CICS: //STEPNAME EXEC PGM=DFHSIP,PARM=(START=INITIAL,SIT=6$,SYSIN) Although CICS uses the reserved name SYSIN, an application could be coded to accept literally any DDNAME. E.g., CICS could have been coded to use DFHSYSIN. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Raymond, That was my thought as well. It will not have a negative impact on older programs, and will clearly require a change to both the called program, and the caller. Wayne Driscoll Product Developer Western Metal Supply NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Thursday, May 12, 2005 6:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= Have you ever heard the old adage - if it ain't broke, .. Instead of messing around with the PARM= field, how about adding a new one like zPARM= (since these are the days of z/OS, z/VM, z/Linux and (soon to be) z/TPF on our new z/Series processors). Have zPARM= specify a DDNAME, like, zPARM=ZPARMS, then code a //ZPARMS DD * file for the job. Now you can have 15PB (random number for the sake of the example) of data for your parameters. Maybe 15PB won't be enough, though, have you seen some of the parameters on an RPM command for Linux or some of the other open system commands? HITACHI DATA SYSTEMS Raymond E. Noal Lab Manager, San Diego Facility Office: (858) 537 - 3268 Cell: (858) 248 - 1172 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Thursday, May 12, 2005 2:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: PARM= We all know and love (well, at least know) that the limitation in JCL for PARM= is 100 total characters. We are thinking (again) about expanding this, and would like to hear your thoughts. Some of the possibilities include - just extending, in JCL processing, so that the target routine gets what it does today (halfword length followed by string, only the string would potentially be 100). This is obviously the nicest from the target routine's perspective if it can handle the extended length - a service that the target routine can call to give me my parameters. Obviously the target routine would have to change in order to utilize that service, and likely would have to dual-path for systems that do not have the service One choice that proved not feasible was using a second parameter. Various utilities already take advantage of the known structure and pass additional data as additional parameters. Some of the potential problems an existing target routine might have with an extended length parameter are - It provided an area via DS of 100 characters, knowing that the limit was 100, and then did an EX (execute) of an MVC to move the parameter string, using the length in the halfword. Unfortunately, if the length is (for example), 256, this would overlay the next 156 bytes - It did some operation (MVC, TRT, whatever) that is limited to 256 characters which works fine when the limit is 100, but if the routine was passed 257 characters of data, it might process that as 257 mod 256 characters in some ways. What do you think? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In a recent note, Chase, John said: Date: Fri, 13 May 2005 08:05:55 -0500 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy I agree with Gil and Charles. IMO, a DD statement would be pointless. Thanks for all the fish (but, not goodbye.) If a programmer wanted to receive a parm via DD, they could have done it already. One of the advantages of PARM= is that you can stick it in a proc, where DD * will not work. //A PROC //. //SYSIN DD DDNAME=SYSIN // PEND //BB EXEC A //. //BB.SYSIN DD * ... ... /* Works here But not here: //A PROC OPT1=DEFAULT1,OPT2=DEFAULT2,OPT3=DEFAULT3 //. // PEND //BB EXEC A,OPT2='Overriding value 2' ... /* ... You'd require the programmer to reassert the default values of PARM options not overridden. Supplying as examples any number of specific instances in which the 100-character limit is not constraining does not serve to refute those cases in which it is burdensome. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 80 byte jcl record limit
In fact, PARM= is limited to 100 bytes. It can take more than 1 line of JCL. So 80-byte limit for jobcards is not an issue in this context. . I totally disagree. Longer JCL cards would solve a lot of problems in specifying PARMS that span records. I have always hated the 80-byte card limit which had really gone the way of the dodo, ever since MVS had an interactive component. (As someone else said, teaching somebody how to span a PARM across more than one record is very difficult at o'dark-thirty when production is waiting to complete in time. Ted MacNEIL [EMAIL PROTECTED] - Post your free ad now! Yahoo! Canada Personals -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 80 byte jcl record limit
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, May 13, 2005 10:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 80 byte jcl record limit While the 80 character limit has a long history, I have problems with the idea to change the length of a JCL card for what might be a benefit. Not having to learn how to code parameters that span more than one card image. The biggest problem I see is that interactive device one uses to view / edit that JCL. While a mod-5 terminal exist (to display 133 characters) the standard 27 lines or is it 24 lines is very limiting. Not to mention the size of the characters on the screen. A long time ago I played with a source program written in PL/1. The compiler supported input of more than 80 characters. At the time I was interested in writing code that had indentation to improve readability and the 80 character limit was causing a readability problems. Taking two 80 byte records and generating a longer input to the compiler did help. But was more of a problem than a benefit. While I did save the source code, in a longer than 80 byte LRECL dataset, editing the source code was a big pain. You had to always be shifting left and right to see the complete line of input. Kenneth Leidner Imagination is more important than knowledge. You have hit the main reason that I am concerned about support 80 characters. The other one is sequence numbers. Almost all of our JCL has sequence numbers and everybody is used to having them. In most cases, this will not be a problem because the sequence number would be a comment. However, we do have a few jobs which extend out all the way to column 72. In that, relatively rare, case, the comment might be taken as more data for the JCL interpreter. I also agree that the historic limit of 80 columns on a 3270 screen could likely be a problem. I have a C source library which is VB/255. I run a mod-5 (27x132) and, like you, I tried to indent properly. Even at 132, I had problems due to the length of some my lines. Perhaps I just too wordie as a programmer. (Example - in COBOL I almost alway use 'IS EQUAL TO' instead of a simple '='. I'm really weird.) -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 80 byte jcl record limit
In a recent note, [log in to unmask] said: Date: Fri, 13 May 2005 11:21:41 -0400 The biggest problem I see is that interactive device one uses to view / edit that JCL. While a mod-5 terminal exist (to display 133 characters) the standard 27 lines or is it 24 lines is very limiting. Not to mention the size of the characters on the screen. That was then. This is now. I'm looking at an SDSF SYSOUT display on a 58-row by 132-column emulated extended 327x display. (Thanks again to various contributors to this list who helped me select the LOGMODE to make this work.) -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTPing a ADRDSSU file
Thomas, Have you tried this with a ADRDSSU physical dump, or a logical dump,...or does it matter.?? Thanks, gabe -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Conley Sent: Thursday, May 12, 2005 9:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTPing a ADRDSSU file DFDSS DUMP TERSE FTP BIN to preallocated FB1024 file DETERSE DFDSS RESTORE VOILA Regards, Tom Conley - Original Message - From: Gabe Torres [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Thursday, May 12, 2005 1:11 PM Subject: FTPing a ADRDSSU file Hello List, During a past DR Test, we missed taking one of our ADRDSSU Physical dumps of a 3390 disk volume. We were able to FTP the data to the site (finally!), but the FTP-ed data was unusable. The data was unrecognizable to the ADRDSSU program. Does anybody have any suggestions on making this process successful. We will be trying it again on the next DR try. Thanks for any help, Gabe Gabe Torres - Systems Programmer State of Nevada Dept of Information Technology - Computing Div. This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to whom it is addressed. Any review, dissemination or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-Mail and delete all copies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New Xbox from Microsoft
The Wall Street Journal (and other news media) reported today on Microsoft's new game system: the Xbox 360. http://online.wsj.com/article/0,,SB111592630884332003,00.html?mod=home_whats_news_us When I first saw the WSJ article, I couldn't help wondering if the 360 part of the name is pure coincidence, or possibly someone at Microsoft is trying to make a mainframe connection...??? ;-) Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Taddei, Cathy Thank you, Eric, that is indeed what I meant -- you cannot place DD * before the PEND statement, or anywhere in a proclib member. And it is still a restriction in z/OS 1.4, producing error message: IEFC601I INVALID JCL STATEMENT if you put DD * in a proc. And I agree with everyone that said they should get rid of that restriction, in addition to increasing the PARM length. Seems to me that allowing instream data within a PROC would add little value unless it was accompanied by allowing variable substitution to occur within the instream data. Without substitution, any change desired in the instream data would require editing the PROC, which would affect all jobs that invoke it. I'm assuming that in the general sense, each job would require something unique in the instream data; that's why the DDNAME keyword is available on the DD statement. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/VS Cobol Conversion
Miller, Pat wrote: Is there a utility that examines OS/VS COBOL source files and provides a summary of just how much code needs to be altered for Enterprise COBOL? Something a little more concise and less cumbersome than output from the new compiler, I mean. http://gsf-soft.com/Products/CB2CONV.shtml CB2CONV is a mass-conversion tool. You run it against an entire library of COBOL programs and it processes all of them in a single run, producing upgraded programs, most of which will compile with a recent compiler without further need for manual changes. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: PARM=
256 seems WAY to small to me - for such things as the LE ENVAR run-time option. (In fact, just trying to pass all the LE run-time options that one MIGHT want to override - without a CEEUOPT makes me question 4096) Ed Gould [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... on 5/13/05 7:13 AM, Bob Shannon at [EMAIL PROTECTED] wrote: ---SNIP Seriously, we're talking about a parameter. I agree that 256 bytes ought to be sufficient. Bob, I sort of agree with you BUT... I have gotten more JCL errors than at any time when I was trying to get the rules of multiple JCL statements when passing parm info.. I know once you learn you will never forget but trying to teach someone over the phone at 0300 is not pretty:( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: PARM=
Whatever is done, please remember CEE3PRM (and existing SHARE requirement SSLNGC0313586) - and of course the fact that LE claims that this works the same under z/OS and VM. (VSE already addressed this via the new CEE5PRML callable service. See: http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/fl2pre05/CHANGES.1 Although it went with the (strange to me) 300 character limit. Peter Relson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]. .. We all know and love (well, at least know) that the limitation in JCL for PARM= is 100 total characters. We are thinking (again) about expanding this, and would like to hear your thoughts. Some of the possibilities include - just extending, in JCL processing, so that the target routine gets what it does today (halfword length followed by string, only the string would potentially be 100). This is obviously the nicest from the target routine's perspective if it can handle the extended length - a service that the target routine can call to give me my parameters. Obviously the target routine would have to change in order to utilize that service, and likely would have to dual-path for systems that do not have the service One choice that proved not feasible was using a second parameter. Various utilities already take advantage of the known structure and pass additional data as additional parameters. Some of the potential problems an existing target routine might have with an extended length parameter are - It provided an area via DS of 100 characters, knowing that the limit was 100, and then did an EX (execute) of an MVC to move the parameter string, using the length in the halfword. Unfortunately, if the length is (for example), 256, this would overlay the next 156 bytes - It did some operation (MVC, TRT, whatever) that is limited to 256 characters which works fine when the limit is 100, but if the routine was passed 257 characters of data, it might process that as 257 mod 256 characters in some ways. What do you think? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
I like most have had to deal with the strange limit of 100 characters on the PARM statement. I would support raising the limit in any way that would not break the old programs still running. That is the passing of the PARM value should be done in the same way as today. This way, current programs would not need to even be aware of the change. (Yes some person could change the JCL to pass more than 100 characters to a program that would not handle it, but then that person needs to change the program first. IE 255 as a max. Now as for breaking the 8 bit limit, I would say a new parameter in the JCL that can not be used if PARM is. The only thing with the keyword name is; one should look down the line when the current PARM is not used / supported, if ever, and only the new keyword is in use. Use XPARM, PARMX ... whatever as the keyword; but the way the parameter is passed would seem to be the important thing. RR1 = full word length followed by value, program would have to know that the new keyword was used. RR1 = 2 full words. One being the length of the value, the other pointing to the value. So the address of the value is not necessary in storage right next to the length of the value. Use R0 to contain the length and R1 point to the 8 bits of zeros followed by the value, so an old program thinks the length is zero and no PARM was passed. Use a macro to get the length of the PARM and its location, returned in R0 and R1. Let MVS deal with the where the PARM and address are hidden in some control block. R1 on entry would look as if no PARM was passed. Or any of a number of other ways to get a long parameter list to a program. The second thing IBM should provide is a macro that would convert the new PARM format, back to the old one, when the length is 100 characters or less. This way the JCL could be changed to the new way and with a small change, insert MACRO x in the program, all will be well. Kenneth Leidner Imagination is more important than knowledge. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, May 13, 2005 11:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= In a recent note, R.S. said: Date: Fri, 13 May 2005 14:49:53 +0200 256 bytes ? IMHO it is not worth to change from 100 to 256. Many should be enough limits occured much too short. BTW: I know *existing* OS/390 application using more than 256 bytes in PARM. It is c89 compiler. I vaguely recollect, it creates pseudo job for compilation, this job looks like regular JCL, but all the compiler options are in PARM field (many LINES of PARM) and that's why it is circumvented in some way. I don't remember details, but the need is obvious. As you note, it's a pseudo job, so no circumvention is necessary. The compiler is invoked by an ATTACH macro; the JCL is never executed. Personally I vote for //STEP EXEC ... PARMX=ddname //DDNAME DD * put here as much as you want (i.e. 64k) /* Or (good for PROCLIB) PARMX1=' ', PARMX2='' etc. Then what? EXEC whatever,PARM=(PARMX1,PARMX2)? The constructed PARM string is still subject to the 100 character limit. Thinking on the idea of a Binder option to declare the ability of a program to accept a long PARM, there are a couple alternatives: o A PARMLIB option, allowing each installation to select what the JCL and TSO CALL PARM string limit should be. Any site could specify, 100, 255, 65535, or even a value less than 100 if that suited them. o A RACF privilege class identifying the set of users (none, some, or all) permitted to use long PARM strings in JCL or in TSO CALL. Otherwise, I wonder how the PARM is represented while a job is in the input queue? Does it reside in a control block? Is the structure of that block documented as a programming interface? Is there a hazard of other breakage if it changes? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 80 byte jcl record limit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | | This list's contributors had to enlighten me, once. They fixed that a | while back: They fixed it? Wasn't it this way since the dawn of time? - -- ~ With kind Regards|\ _,,,---,,_ ~ZZZzz /,`.-'`'-. ;-;;, ~ Volker Bandke |,4- ) )-,_. ,\ ( `'-' ~ (BSP GmbH)'---''(_/--' `-'\_) ~ Darth Vader sleeps with a Teddywookie. ~ (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFChOnuHm2sbKEAXTARAgaQAJ9tKBsMbUmvdpPyjDC++5zZkWV4LgCeOHQH ckqfoAL/8ik/SmDA6f161a8= =xyGm -END PGP SIGNATURE- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 80 byte jcl record limit
There's a neat idea. The JES spool can handle longer than 80 characters for data sets. I haven't tried it, but can one use the VSAM interface to the INTRDR and put in records 80 characters? Variable-length characters? Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Low, David Sent: Friday May 13 2005 06:58 To: IBM-MAIN@BAMA.UA.EDU Subject: 80 byte jcl record limit Sorry if this is a stupid question... Is there, or has there been any requirement of increasing the 80 byte record limit of jcl? Reading the PARM= thread with interest, I can imagine having much longer jcl records would be a great thing if we suddenly have up to 65K of parm data available. Thanks. Dave Low -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/12/2005 at 04:09 PM, Raymond Noal [EMAIL PROTECTED] said: Instead of messing around with the PARM= field, how about adding a new one like zPARM= (since these are the days of z/OS, z/VM, z/Linux and (soon to be) z/TPF on our new z/Series processors). Have zPARM= specify a DDNAME, like, zPARM=ZPARMS, then code a //ZPARMS DD * file for the job. Now you can have 15PB (random number for the sake of the example) of data for your parameters. That makes sense only if they also support symbolic parameters and static system symbols for instream data. Personally, I'd prefer just raising the limits on PARM. Either way you face the issues that Peter mentioned. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/13/2005
at 09:57 AM, David Andrews [EMAIL PROTECTED] said:
Please also remember the START command processor: convince it to pass
parameters bigger than... what, 61 bytes? (Whatever fits on a single
generated // PARM='...' card image.)
S MYSTC,A=long,B=long,C=long
// EXEC PGM=IEBIBALL,PARM=('A','B','C')
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2http://patriot.net/~shmuel
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
In [EMAIL PROTECTED], on 05/13/2005 at 01:08 AM, Leonard Woren [EMAIL PROTECTED] said: I think you had the right idea and then missed: I propose that the solution should be // PARM and make it mutually exclusive with the PARM= keyword on EXEC. Why complicate things? That question applies as much to your proposal as to anything else. Adding a new statement is much more complicated than raising the limit on an existing keyword. Well, actually it does make things easier. Since // PARM would be all-new, it can be thoughtfully implemented to make it easy to code long continuations correctly. Having different continuation rules for different statements would be a complication for the user. Why complicate things? -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTPing a ADRDSSU file
on 5/13/05 10:49 AM, Gabe Torres at [EMAIL PROTECTED] wrote: Ed, There was no blksize info supplied in the DCB, so it must be defaulting to whatever ADRDSSU likes. gabe Gabe, IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops anything after 32K. The trick is to tell DFDSS (via blkszie=32760) not to create large blksizes. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL II and COMPS
Bill Klein writes: On the other hand, the only time that a COMP-5 data item works differently from a BINARY or COMP (or COMP-4) item (on the mainframe) is *IF* you try and use values greater than the PICTURE clause allows. This is an ugly thing to do and is NEVER recommended. My response is that I strongly recommend that just this be done, and here we have what is not so much an intellectual as a visceral, attitudinal difference. In PL/I, fror example, one writes declare binary_counter binary fixed(31,0) ; /* fullword counter */ declare packed_counter decimal fixed(7,0) ; /* seven-digit packed counter */ In the first declaration (31,0) denotes the number of binary digits and the number of binary digits following the binary point; and in the second declaration (7,0) denotes the nu,mber of decimal digits and the number of decimal digits following the decimal point. COBOL does not make this distinction. Picture specifications are decimal and decimal only EVEN FOR BINARY DATA TYPES. Unfortunately perhaps but unsurprisingly, the powers of 2 and those of 10 are different; and a decimal picture specification cann therefore newver accurately represent the precision of a binary data type: It must significantly understate or, much worse, overstate, it. In the tables |---| | hardware capacity | |---| | b | unsigned | signed | |---| | 1 | 0 = Y = 255 |-128 = y = +127 | | 2 |0 = H = 65,535 | -32,768 = h = +32,767 | | 4 | 0 = F = 4,294,967,295 | -2,147,483,648 = f = +2,147,483,647 | |-|-| |--| |COBOL picture capacity | |--| | b | unsigned | signed | |--| | 1 | 0 = Y = 99 | -99 = y = +99 | | 2 | 0 = H = 9,999 | -9,999 = h = +9,999 | | 4 |0 = F = 999,999,999 | -999,999,999 = f = +999,999,999 | |--| COBOL is the only statement-level procedural language that has come to terms only very grudgingly and still oinly very partially with binary data types that the hardware, be it an Intel microprocessor or an IBM maniframe, makes available. John Gilmore Ashland, MA 01721 U.S.A. _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Corrupted SMF record
on 5/13/05 1:35 PM, Laine, Rogers at [EMAIL PROTECTED] wrote: Hello, I have a SMF dataset that was MOD'ed to a existing dataset that is now corrupted using the program SMFDUMP. I was able to use the program IFASMFDP to create a new output dataset up to the corrupted record. My question is how can I recover the records that are pass the bad one? I recall seeing a work around on this list, any ideas? Rogers Rogerers, Look at the CBTtape I think they have a S002 fixer upper. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Corrupted SMF record
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Laine, Rogers Sent: Friday, May 13, 2005 1:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Corrupted SMF record Hello, I have a SMF dataset that was MOD'ed to a existing dataset that is now corrupted using the program SMFDUMP. I was able to use the program IFASMFDP to create a new output dataset up to the corrupted record. My question is how can I recover the records that are pass the bad one? I recall seeing a work around on this list, any ideas? Rogers Use DFSORT. //COPY EXEC PGM=SORT,REGION=0M //SYSPRINT DD SYSOUT=* //SORTMSG DD SYSOUT=* //SYSOUT DD SYSOUT=* //SORTIN DD ... //SORTOUT DD ... //SYSIN DD * OPTION SPANINC=RC0 SORT FIELDS=(COPY) /* // -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On 13 May 2005 09:53:23 -0700, [EMAIL PROTECTED] (Chase, John) wrote: Seems to me that allowing instream data within a PROC would add little value unless it was accompanied by allowing variable substitution to occur within the instream data. Without substitution, any change desired in the instream data would require editing the PROC, which would affect all jobs that invoke it. I'm assuming that in the general sense, each job would require something unique in the instream data; that's why the DDNAME keyword is available on the DD statement. You're right in a general sense, of course. But in my personal experiences, the parameters that I was passing to a program via a control file were fairly static and usually didn't change very often. So, for me at least, having a sysin dataset embedded within a cataloged proc is valuable, even if no symbolic substitution was performed on the data. (Although it would definitely be a very nice feature to have.) Eric -- Eric Chevalier E-mail: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
On Fri, May 13, 2005 at 02:53:00PM -0700, Charles Mills wrote: As Gil pointed out, the ONLY new exposure is for authorized programs. Formerly, an authorized program could be confident that it's caller was either JCL or another trusted (authorized) program. It would thus be a reasonably valid assumption that the authorized program would either get = 100 bytes of parms from JCL or something proper (however that might be defined) from an authorized caller. [...] With PARM= 100 characters, for the first time, the authorized program expecting = 100 bytes might be subject to malicious buffer overflow from an untrusted source. The solution is a linker set bit similar to AC=1 that says this authorized program expects that it might get 100 bytes if invoked from JCL. Charles By definition, an authorized program is supposed to validity check everything and not make any assumptions about untrusted input. It's a very small leap from there to a conclusion that an authorized program that breaks in any way due to a long parm was incorrectly written in the first place. I've never understood why the exec parm needs to be copied somewhere by the receiving program, except for printing in which case you probably need to check the length anyway. I don't feel like groveling through my source libs right now, but I'd be surprised if any of my programs, going back to the 1970s, would break with long parms. /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
an authorized program that breaks in any way due to a long parm was incorrectly written in the first place Agreed. But that won't get your data back, or make the dumb mainframe hacked stories go away. I would say pretty much by definition all viruses exploit programs that were incorrectly written in the first place. Virus Checkers are still big business. Ah! You say, that's Windows, not z/OS. Exactly. That's why z/OS needs a bit to save authorized programs from surprises they had no reason to expect. Agreed on your other point. I've always felt that application programmers move data; system programmers and software developers manipulate pointers. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Leonard Woren Sent: Friday, May 13, 2005 4:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= On Fri, May 13, 2005 at 02:53:00PM -0700, Charles Mills wrote: As Gil pointed out, the ONLY new exposure is for authorized programs. Formerly, an authorized program could be confident that it's caller was either JCL or another trusted (authorized) program. It would thus be a reasonably valid assumption that the authorized program would either get = 100 bytes of parms from JCL or something proper (however that might be defined) from an authorized caller. [...] With PARM= 100 characters, for the first time, the authorized program expecting = 100 bytes might be subject to malicious buffer overflow from an untrusted source. The solution is a linker set bit similar to AC=1 that says this authorized program expects that it might get 100 bytes if invoked from JCL. Charles By definition, an authorized program is supposed to validity check everything and not make any assumptions about untrusted input. It's a very small leap from there to a conclusion that an authorized program that breaks in any way due to a long parm was incorrectly written in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PARM=
Adrian, I agree with you regarding the 32K, but after reading some posting it seems people asking for unlimited parms. I also would like to see some improvements in this area but everything beside 256 is a nightmare for me. Of course LE runtime overriding is an issue with some user PARM. Perhaps LE should avoid using the PARM statement for those overrides. However, I believe everything beside 256 is strange to code in a JCL regardless of the mapping. I know BPXBATCH might be a big issue but AOPBATCH introduce a nice workaround. I believe Peter Relson receive a lot of input and will be able to find a common solution. Regard Roland -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von Adrian H Auer-Hudson Gesendet: Samstag, 14. Mai 2005 01:25 An: IBM-MAIN@BAMA.UA.EDU Betreff: Re: PARM= --- Schiradin,Roland HG-Dir itb-db/dc [EMAIL PROTECTED] wrote: From: Schiradin,Roland HG-Dir itb-db/dc [EMAIL PROTECTED] Date: Sat, 14 May 2005 00:59:54 +0200 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: PARM= All of our Cobol programs using the PARM will fail if the parm length exceed 32767 Linkage section. 01 OsParms. 05 OsParms-Length pic s9(4) comp. 05 OsParms-Data. 10 OsParms-CicsId. 15 OsParm-CicsId-1-5 pic x(5). 15 pic x(3). 10 pic x. 10 OsParms-Program pic x(8). 10 pic x. 10 OsParms-Quietpic x(5). 88 No-Output value 'QUIET'. Procedure Division using OsParms. However it might be a nightmare to code the correct mapping for 32767 bytes in the JCL regardless of PARMX or DDNAMES Roland My habit has always been to comma delimit the elements of the PARM. I move the parm into working storage and unstring all but the first two bytes for the length held in said two bytes. It would be great to remove the 100 byte limitation. My initial thought was to go for the max addressable by 16 bits. However, I think it would be better to remain consistent with the length available when a sub program is called be another program. I have written programs designed for execution from a JCL exec, or, invocation by a calling program. We all know that it is unlikely any one would ever code a PARM on an exec with 32767 bytes of data. But to impose a shorter length is unnecessarily arbitrary. Have a great weekend Adrian. Webmaster, http://www.losangelesmetro.net. Supporter of Expo Light Rail - Enabler for the Digital Coast http://www.friends4expo.org. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTPing a ADRDSSU file
IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops anything after 32K. The trick is to tell DFDSS (via blkszie=32760) not to create large blksizes. I am not positive, but I believe that when the output backup file is on disk, DSS writes only blocks up to 32K in length (actually 32K-8=32760). This is what FDR does. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing Little Falls, NJ 07424 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.fdr.innovationdp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTPing a ADRDSSU file
on 5/13/05 9:22 PM, Bruce Black at [EMAIL PROTECTED] wrote: IIRC the blksize ends up being greater than 32K (with DFDSS) and FTP drops anything after 32K. The trick is to tell DFDSS (via blkszie=32760) not to create large blksizes. I am not positive, but I believe that when the output backup file is on disk, DSS writes only blocks up to 32K in length (actually 32K-8=32760). This is what FDR does. Bruce, I think we ran into this issue (with DFDSS) a few years ago. I know that we had found the trick with DFDSS. We did not use FDR for back up so we weren't too concerned. What really surprised us is that FTP didn't give any error message (I didn't know if its been fixed or not ). I would have been happy if FTP would have put out an error message at least it would have alerted the user(s). I was really inundated with problems at the time and didn't follow through openning a PMR against FTP. IIRC I had gotten a really rotten response on an a PMR I had openned against them (like this is the way the PC people do things and we are doing everything OUR WAY to heck with IBM's way of doing things.). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
