Re: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/16/2006 at 08:52 AM, Greg Shirey [EMAIL PROTECTED] said: Well, I'm confused. The manual (TSO/E User's Guide) does seem to be pretty consistent in using the word statement to refer essentially to a line (whether continued or not) of JCL - the EXEC statement, the JOB statement, the SYSIN DD statement, the SYSTSIN DD statement etc. Are they not using their own terminology correctly? I'd say not: EDIT first.DSN - second.dsn Is two records. It's clearly on statement. BTW, does the CLIST documentation also say statement when they mean record? That could get even more confusing, since some CLIST statements are not commands. As for dconcatenation, I'd suggest testing a concatenation of DASD and SYSIN data sets, e.g., //SYSTSIN DD DSN=SOME.INPUT,DISP=SHR // DD * more input // DD DSN=YET.MORE.INPUT,DISP=SHR If there is a problem, that is more likely to hit it than concatenating like data sets. -- 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: Batch TMP RECFM(VB) Input
OK, when I search the bookshelf on-line for z/OS 1.7, I get 386 hits for 'statement.' In the JCL manual, it says (partially): A JCL statement consists of one or more 80-byte records. Each record is in the form of an 80-column punched-card image. Each JCL statement is logically divided into the following five fields In Chapter 13 of the CLIST manual (z/OS V1R7.0 TSO/E CLISTs), there is a section entitled How to Read the CLIST Statement Syntax and each following section describes a different statement - ATTN, CLOSFILE, CONTROL, etc. There is a section of the CLIST manual entitled JCL Statements which contains this information: From a CLIST, you might want to submit a jobstream for execution. In the CLIST, you can include the required JCL statements (EXEC, DD, and so on). However, when you include the following JCL statements in a CLIST, you must use a particular CLIST function to prevent the CLIST from modifying the statements and causing subsequent JCL errors. The IBM terminology site (http://www-306.ibm.com/software/globalization/terminology/) defines statement as: An instruction in a program or procedure. However, they don't define tautology. :-) For concatenation, I have no problem running this job: //DPC088RX JOB (DPC088,JDG),'REXX RUN',CLASS=A,MSGCLASS=X, // MSGLEVEL=(1,1),NOTIFY=DPC088 TYPRUN=SCAN // EXEC PGM=IKJEFT1B //SYSEXEC DD DSN=DPC088.REXX.LIB,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DSN=DPC088.JCL.CNTL(REXX1),DISP=SHR // DD * %DISPDATE D /* // DD DSN=DPC088.JCL.CNTL(REXX2),DISP=SHR // DD * %DISPDATE U /* It produces this result: READY %DISPDATE J J 06076 READY %DISPDATE D D 76 READY %DISPDATE W W Friday READY %DISPDATE U U 03/17/06 READY END Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, March 17, 2006 8:03 AM BTW, does the CLIST documentation also say statement when they mean record? That could get even more confusing, since some CLIST statements are not commands. As for dconcatenation, I'd suggest testing a concatenation of DASD and SYSIN data sets, e.g., //SYSTSIN DD DSN=SOME.INPUT,DISP=SHR // DD * more input // DD DSN=YET.MORE.INPUT,DISP=SHR If there is a problem, that is more likely to hit it than concatenating like data sets. -- 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: Batch TMP RECFM(VB) Input
[EMAIL PROTECTED] wrote: P.S.: You can also use the EX command in SYSTSIN to invoke your RACF command file as a CLIST, instead of specifying it directly in the SYSTSIN DD statement. SYSTSIN DD * EX 'DSN' /* Nice idea, but how do I get the same behavior as feeding the file into program IKJEFT1A, i.e. execution stops after the first command with non-zero return code? -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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: Batch TMP RECFM(VB) Input
IKJEFT1A does return after the first non-zero return code even if the input comes from a data set executed via ex command. Either the SYSTSIN DD * or the PARM= version work for me. Or did I missunderstand you question? Peter Hunkeler CREDIT SUISSE -- 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: Batch TMP RECFM(VB) Input
//TMP EXEC PGM=IKJEFT01, // PARM='EX ''VB.INPUT'' LIST CLIST' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY It seems I have supplanted the CLIST facility ;-) Peter Hunkeler CREDIT SUISSE -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/14/2006 at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said: No, command == TSO command Statement == line within file You're overlooking continuation lines. -- 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: Batch TMP RECFM(VB) Input
No, command == TSO command Statement == line within file You're overlooking continuation lines. Actually, I'm not. The poster I replied to was confused about the statement: Each command must start on a new statement. That was what I was trying to clarify. A continuation is not a new statement. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/14/2006 at 11:41 AM, Paul Gilmartin [EMAIL PROTECTED] said: IBM's lexical conventions, traceable to the limitations of the 029 keypunch and 407 card reader Not even close. No professor, having a limited number of lectures to deliver, will choose to waste any of them describing the continuation conventions for JCL, or HLASM, or even TSO. If the teacher is tasked with teaching JCL, HLASM or TSO and fails to describe continuation conventions then he is not doing his job. It's more productive to teach UNIX or Windows instead. That sort of decision is up to the department, not the individual professor. It is the duty of the professor to teach the material that the University promised the students in the course catalog. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/14/2006 at 12:14 PM, Tom Schmidt [EMAIL PROTECTED] said: Each command or subcommand must begin on a separate statement. That sounds like a candidate for an RCF. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/14/2006 at 03:08 PM, Paul Gilmartin [EMAIL PROTECTED] said: I know, but it could also be cabled to a 70* computer and used as a printer and card reader, in which case it could read only 72 columns of each card. There was certainly a 716[1] printer for the 7090 using a box similar to a 407, but it was strictly[2] a printer. The 7090 used a separate 711[1] unit for a card reader. In contrast, the PDP-6 stored five characters per word, The PDP-6 also stored 6 characters per word. [1] The three digit number indicating that it was carried over from the earlier 709. [2] Well, it was also a clock. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/14/2006 at 08:25 PM, Chris Mason [EMAIL PROTECTED] said: The real reason I'm posting - and again relying on positively antique OS education - is that I have always treated it as a golden rule of data set concatenation that the attributes of the first data set in the concatenation reign supreme - in other words, the attributes of the first data set will be the ones set in the OS control blocks at the time the data set is opened and the attributes of succeeding data sets are utterly ignored. Well, I dare say there may be some exceptions to this rule and this is the perfect forum for these exceptions to be flushed out. There's a bit in the DCB for concatenation of unlike attributes, and it's been there since the 1960's. There's additional support for mixed block sizes that came in incrementally with various releases of DFP. For a long time it has been the cases that are not handled that are the exceptions rather than the cases that are handled. Now I'll stick my neck out and suggest that maybe the manual author has got a few points wrong Certainly writting statement when he ws referring to a record rather than a statement. -- 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: Batch TMP RECFM(VB) Input
In a recent note, Shmuel Metz (Seymour J.) said: Date: Wed, 15 Mar 2006 07:48:58 -0500 In [EMAIL PROTECTED], on 03/14/2006 at 03:08 PM, Paul Gilmartin [log in to unmask] said: I know, but it could also be cabled to a 70* computer and used as a printer and card reader, in which case it could read only 72 columns of each card. There was certainly a 716[1] printer for the 7090 using a box similar to a 407, but it was strictly[2] a printer. The 7090 used a separate 711[1] unit for a card reader. I may well stand corrected on the device type. However I have a distinct memory of colleagues at one 7090 installation submitting jobs with the notation to the operator: 80 column data; do not read job online! meaning that the operator must submit the job via the 1401/1402 rather than the 7xx. The essence arose from 36-bit words and row binary converted to characters in software. In contrast, the PDP-6 stored five characters per word, The PDP-6 also stored 6 characters per word. Agreed. Symptomatic of a very late design decision. I conjecture they recognized the need for 7-bit ASCII too late to redesign the OS programming interface. -- 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: Batch TMP RECFM(VB) Input
Norbert Friemel wrote: Ulrich, how about this: 1) create a simple two line rexx in data set A.B.EXEC: /* rexx */ Or replace //TMP EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DISP=OLD,DSN=VB.INPUT with //TMP EXEC PGM=IKJEFT01, // PARM='EX ''VB.INPUT'' LIST CLIST' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY Norbert, your suggested solution looks very interesting and easy. Thanks a lot, I'll try it. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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: Batch TMP RECFM(VB) Input
First a correction of my own typo. I was familiar with a 407 at the University of Colorado circa 1970, not mid-1950's. (Not quite that old, yet.) And it was standalone on the job prep floor, not connected to any computer. In a recent note, Shmuel Metz (Seymour J.) said: Date: Wed, 15 Mar 2006 07:56:00 -0500 There's a bit in the DCB for concatenation of unlike attributes, and it's been there since the 1960's. There's additional support for mixed block sizes that came in incrementally with various releases of DFP. For a long time it has been the cases that are not handled that are the exceptions rather than the cases that are handled. And I understand that nowadays at least BLKSIZE is taken from the maximum among the catenands, not the first. But the calling program must be notified synchronously of the crossing of the unlike-attribute-boundary so it may adjust its behavior accordingly. (RECFM=F must be treated differently from RECFM=V.) I tried the jobstep: //* Test validity of catenation in SYSTSIN. //* //STEP EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=(,) //SYSTSIN DD * ALLOCATE - // DD * SHR - // DD * DUMMY // DD * LISTALC STATUS SYSNAMES with no errors and expected results, even for the extreme case of concatenation within a single statement (or is that command?) RCF submitted. Now I'll stick my neck out and suggest that maybe the manual author has got a few points wrong Certainly writting statement when he ws referring to a record rather than a statement. Three errors of fact in sixteen lines of text. I wonder if this is representative of the entire publication. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/15/2006 at 07:05 AM, Paul Gilmartin [EMAIL PROTECTED] said: I may well stand corrected on the device type. However I have a distinct memory of colleagues at one 7090 installation submitting jobs with the notation to the operator: 80 column data; do not read job online! meaning that the operator must submit the job via the 1401/1402 rather than the 7xx. That notation only suggests that the 711 was limited to 72 columns. Which, in fact, it was. It does *not* suggest that the card reader was related to the 407. Agreed. Symptomatic of a very late design decision. Why? The PDP-6 had byte handling instructions. It could deal with 7-bit bytes just as well as with 6-bit bytes. The decision to use one or the other was strictly a matter of software. I conjecture they recognized the need for 7-bit ASCII too late to redesign the OS programming interface. The PDP-6 was the PDP-6 and the OS was the OS. There was nothing in the hardware design that constrained the OS to use a specific character code or size. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/15/2006 at 08:37 AM, Paul Gilmartin [EMAIL PROTECTED] said: And I understand that nowadays at least BLKSIZE is taken from the maximum among the catenands, not the first. But the calling program must be notified synchronously of the crossing of the unlike-attribute-boundary so it may adjust its behavior accordingly. You get that with the unlike attributes bit set. Without it you must have compatible record formats in the concatenation. -- 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: Batch TMP RECFM(VB) Input
In [EMAIL PROTECTED], on 03/15/2006 at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said: Actually, I'm not. Then you're confused. The poster I replied to was confused about the statement: Each command must start on a new statement. Hardly surprising, because that sentence says nothing. The author was confusing statement with record. That was what I was trying to clarify. And instead further confused the issue. A continuation is not a new statement. Then it's a good thing that I never claimed that it was. A record is not necessarily a statement, and vice versa. The two fail to be synonymous precisely in the case where there is a continuation line, in which case the statement comprises multiple records. -- 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
Batch TMP RECFM(VB) Input
I have a question that's so basic I'm almost ashamed to ask. Quite often I need to execute RACF commands via the TMP in batch. The commands are lengthy and don't always fit in 80 columns so I'm using variable length records. With VB data sets, the TSO command parser expects line numbers in the first 8 columns so the commands must not start before column 9. Fixing this is rather trivial using the ISPF editor with ))9 or by adding a string of blanks in front of each line if the commands are generated by program but it is nevertheless inconvenient. I've looked in a couple TSO/E manuals in search of an option that would tell the TSO command parser to ignore or not expect line numbers but couldn't find anything. Is there an option or some other trick to allow commands to start in column 1? -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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: Batch TMP RECFM(VB) Input
Ulrich, Not knowing exactly which commands you are doing, or how many this may or may not work for you. You can always use a FB record. The commands can be split along multiple lines so long as there is a hyphen (-) or plus (+) at the end of the line to indicating it is being continued on the next line. Other than that, I am not aware of any way to prevent line numbers from being used for a VB file in a batch TMP. To make my process easier (to create multi line commands) I typically create a REXX to read a flat file of the element (data set name, tso id, etc) and then use ISPF Skel functions to build the JCL and command. Saves me from typing a lot of commands. Or I build an ISPF panel if the task is small and again use ISPF SKEL to build the JCL and commands. Just the other day I had to list 248 DB2 Data bases, so I used this process to make the work easier. Otherwise I would still be typing now. Lizette Koehler -- 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: Batch TMP RECFM(VB) Input
On Tue, 14 Mar 2006 15:45:03 +0100 Ulrich Boche [EMAIL PROTECTED] wrote: :I have a question that's so basic I'm almost ashamed to ask. :Quite often I need to execute RACF commands via the TMP in batch. The :commands are lengthy and don't always fit in 80 columns so I'm using :variable length records. With VB data sets, the TSO command parser :expects line numbers in the first 8 columns so the commands must not :start before column 9. :Fixing this is rather trivial using the ISPF editor with ))9 or by :adding a string of blanks in front of each line if the commands are :generated by program but it is nevertheless inconvenient. I've looked in :a couple TSO/E manuals in search of an option that would tell the TSO :command parser to ignore or not expect line numbers but couldn't find :anything. :Is there an option or some other trick to allow commands to start in :column 1? You can use 80 character records. Put a + at the end of the line which tells TSO that the command is continued on the next line. -- Binyamin Dissen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Batch TMP RECFM(VB) Input
Binyamin Dissen wrote: You can use 80 character records. Put a + at the end of the line which tells TSO that the command is continued on the next line. I know how to continue TSO input lines. However, in most cases, splitting the line would be more inconvenient than shifting the variable length records. I'm looking for something that's really easy. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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: Batch TMP RECFM(VB) Input
I just created a VB PDS, added a job and submitted it and it ran without incident. No line numbers anywhere, no need to shift anything to make room for non-existent line numbers. All is well. Are you using ISPF edit or TSO edit? Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Boche Sent: Tuesday, March 14, 2006 11:09 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Batch TMP RECFM(VB) Input Binyamin Dissen wrote: You can use 80 character records. Put a + at the end of the line which tells TSO that the command is continued on the next line. I know how to continue TSO input lines. However, in most cases, splitting the line would be more inconvenient than shifting the variable length records. I'm looking for something that's really easy. -- *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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: Batch TMP RECFM(VB) Input
Ulrich, Then the only other thought I have is that you are doing this under ISPF. You need to change the profile of the Data Set you are using from one that has numbs on to a different profile. I do not have a system in front of me. But if you create a new VB file with the profile you want, you maybe able to remove the requirement of numbers cols 1-8. That means no CNTL, TEXT, etc.. type of file. Make a new one, like MYVB. So your new file might be called TSOID.JCL.MYVB Lizette Koehler -- 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: Batch TMP RECFM(VB) Input
If your commands are already in a separate VB file rather than inline, you could precede the TMP step with a DFSORT step (if you have it) that reads the file and creates a temporary VB file that has the sequence numbers. OPTION COPY OUTFIL OUTREC=(1,4,SEQNUM,8,ZD,5) Bill Godfrey On Tue, 14 Mar 2006 17:09:10 +0100, Ulrich Boche wrote: Binyamin Dissen wrote: You can use 80 character records. Put a + at the end of the line which tells TSO that the command is continued on the next line. I know how to continue TSO input lines. However, in most cases, splitting the line would be more inconvenient than shifting the variable length records. I'm looking for something that's really easy. -- -- 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: Batch TMP RECFM(VB) Input
In a recent note, Lizette Koehler said: Date: Tue, 14 Mar 2006 10:31:20 -0700 Then the only other thought I have is that you are doing this under ISPF. You need to change the profile of the Data Set you are using from one that has numbs on to a different profile. I do not have a system in front of me. But if you create a new VB file with the profile you want, you maybe able to remove the requirement of numbers cols 1-8. That means no CNTL, TEXT, etc.. type of file. Make a new one, like MYVB. So your new file might be called TSOID.JCL.MYVB As I read it, the OP's issue is not with ISPF's (or any editor's) adding or not adding line numbers; it's with the TMP's expectation that they exist, even on a command file generated by a process other than ISPF (or any particular editor). -- 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: Batch TMP RECFM(VB) Input
In a recent note, Imbriale, Donald (Exchange) said: Date: Tue, 14 Mar 2006 11:39:53 -0500 I just created a VB PDS, added a job and submitted it and it ran without incident. No line numbers anywhere, no need to shift anything to make room for non-existent line numbers. All is well. Are you using ISPF edit or TSO edit? Ummm. Job. Was your VB command file inline in the job, or referenced by a //SYSTSIN DD DSN= statement? If the former, was the job submitted with the ISPF SUBMIT command. I believe ISPF SUBMIT converts everything to FB 80. You can easily check this: include in your command file some commands that extend beyond column 80 (one of the OP's requirements), and verify that all columns (1-8 and 81-*) are interpreted properly as part of the command. -- 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: Batch TMP RECFM(VB) Input
Ulrich, The short answer to your question is: No. As documented in the fine manual: The SYSTSIN and SYSTSPRT DD statements can refer to a sequential data set or a member of a partitioned data set. It is recommended that the SYSTSIN DD be defined as a fixed block format data set, with an LRECL of 80. If SYSTSIN is a fixed length data set (FB), the last 8 bytes of the record will be treated as a sequence number and ignored. If SYSTSIN is a fixed length data set with ASA control characters (FBA), the first byte of the record will be treated as a carriage control character and ignored. If SYSTSIN is a variable length data set (VB), the first 8 bytes of the record will be treated as a sequence number and ignored. If SYSTSIN is a variable length data set with ASA control characters (VBA), the first 9 bytes of the record will be treated as a sequence number, followed by a carriage control character and ignored. You cannot refer to concatenated data sets on the SYSTSIN DD statement. Each command or subcommand must begin on a separate statement. The fine manual being, in this case, TSO/E User's Guide Chapter 16, the section heading is Submitting Jobs in TSO Batch, subsection Writing JCL for Command Execution subheading SYSTSIN DD Statement. (You can have any color car you want as long as you only want black - H. Ford) -- Tom Schmidt Madison, WI -- 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: Batch TMP RECFM(VB) Input
In a recent note, Tom Schmidt said: Date: Tue, 14 Mar 2006 12:14:08 -0600 If SYSTSIN is a variable length data set (VB), the first 8 bytes of the record will be treated as a sequence number and ignored. If SYSTSIN is a variable length data set with ASA control characters (VBA), the first 9 bytes of the record will be treated as a sequence number, followed by a carriage control character and ignored. ??? Gulp! Is there any printer driver or utility that honors ASA carriage control in column 9 as the above suggests? What's the point? It fails to make clear what the behavior is for RECFM=VBM. You cannot refer to concatenated data sets on the SYSTSIN DD statement. Hmmm. I hadn't known this. I'll have to try one and see how it fails. Does it mean, perhaps, merely that concatenated data sets must have similar attributes? Each command or subcommand must begin on a separate statement. Sounds redundant. Aren't command and statement synonyms? The fine manual being, in this case, TSO/E User's Guide Chapter 16, the section heading is Submitting Jobs in TSO Batch, subsection Writing JCL for Command Execution subheading SYSTSIN DD Statement. FSVO fine. (That's actually unfair. The manual is probably pretty fine; the subject matter is crude.) IBM's lexical conventions, traceable to the limitations of the 029 keypunch and 407 card reader (I know, but..) are unduly burdensome. They deter beginners starting on the mainframe career track. No professor, having a limited number of lectures to deliver, will choose to waste any of them describing the continuation conventions for JCL, or HLASM, or even TSO. It's more productive to teach UNIX or Windows instead. -- 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: Batch TMP RECFM(VB) Input
Paul, Carriage (aka printer) control characters are always in column 1 if my OS education of long, long ago is to be relied upon - in other words I have eschewed looking up any manuals. The 9 is mentioned because it's the addition of 1 and 8, in that order - in other words, column 1 for the carriage control character and columns 2 to 9 for the sequence number - I guess - but I could be wrong. Maybe Tom has it the wrong way round. I expect VBM and VBA, actually any xxxA and xxxM, are identical except for the way the carriage control character is interpreted. I would be surprised if concatenated data sets could not be used in any context which expects a sequential data set - but, again, I could be wrong. Why make complicated exceptions when it's all done for you? The real reason I'm posting - and again relying on positively antique OS education - is that I have always treated it as a golden rule of data set concatenation that the attributes of the first data set in the concatenation reign supreme - in other words, the attributes of the first data set will be the ones set in the OS control blocks at the time the data set is opened and the attributes of succeeding data sets are utterly ignored. Well, I dare say there may be some exceptions to this rule and this is the perfect forum for these exceptions to be flushed out. Having got to the end of this post and seen a manual reference, I decided it wasn't fair on my the contributors and audience not to check the manual. What Tom has given us is very much exactly what section 3.4.4.1.4 SYSTSIN DD Statement of the said manual says. Now I'll stick my neck out and suggest that maybe the manual author has got a few points wrong - including forgetting about the machine, M, carriage control character (actually the printer CCW code if my memory serves me well). Manual authors getting it wrong has also been known from time to time. Chris Mason - Original Message - From: Paul Gilmartin [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 14 March, 2006 7:41 PM Subject: Re: Batch TMP RECFM(VB) Input In a recent note, Tom Schmidt said: Date: Tue, 14 Mar 2006 12:14:08 -0600 If SYSTSIN is a variable length data set (VB), the first 8 bytes of the record will be treated as a sequence number and ignored. If SYSTSIN is a variable length data set with ASA control characters (VBA), the first 9 bytes of the record will be treated as a sequence number, followed by a carriage control character and ignored. ??? Gulp! Is there any printer driver or utility that honors ASA carriage control in column 9 as the above suggests? What's the point? It fails to make clear what the behavior is for RECFM=VBM. You cannot refer to concatenated data sets on the SYSTSIN DD statement. Hmmm. I hadn't known this. I'll have to try one and see how it fails. Does it mean, perhaps, merely that concatenated data sets must have similar attributes? Each command or subcommand must begin on a separate statement. Sounds redundant. Aren't command and statement synonyms? The fine manual being, in this case, TSO/E User's Guide Chapter 16, the section heading is Submitting Jobs in TSO Batch, subsection Writing JCL for Command Execution subheading SYSTSIN DD Statement. FSVO fine. (That's actually unfair. The manual is probably pretty fine; the subject matter is crude.) IBM's lexical conventions, traceable to the limitations of the 029 keypunch and 407 card reader (I know, but..) are unduly burdensome. They deter beginners starting on the mainframe career track. No professor, having a limited number of lectures to deliver, will choose to waste any of them describing the continuation conventions for JCL, or HLASM, or even TSO. It's more productive to teach UNIX or Windows instead. -- 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: Batch TMP RECFM(VB) Input
Sounds redundant. Aren't command and statement synonyms? No, command == TSO command Statement == line within file - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Batch TMP RECFM(VB) Input
No professor, having a limited number of lectures to deliver, will choose to waste any of them describing the continuation conventions for JCL, or HLASM, or even TSO. It's more productive to teach UNIX or Windows instead. The above tends toward the ludicrous. If you're not going to teach the conventions, then why teach the language? If you're teaching about mainframes, you have to teach the conventions. This is akin to saying, I'll teach you C, but I won't teach you how to compile the programme. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Batch TMP RECFM(VB) Input
the attributes of the first data set will be the ones set in the OS control blocks at the time the data set is opened and the attributes of succeeding data sets are utterly ignored. Not true, since ESA 3, for block-size. (I cannot remember for sequential, but it reallocates the buffer for PDS, when the blocksize changes in the concatenation) - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Batch TMP RECFM(VB) Input
Unless there were two of them, the 407 was a tabulating machine in the 1950's. Sounded like a washing machine in distress when operating properly. snip IBM's lexical conventions, traceable to the limitations of the 029 keypunch and 407 card reader (I know, but..) are unduly burdensome. They deter beginners starting on the mainframe career track. No professor, having a limited number of - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: Batch TMP RECFM(VB) Input
In a recent note, Kirk Talman said: Date: Tue, 14 Mar 2006 16:29:20 -0500 Unless there were two of them, the 407 was a tabulating machine in the I know, but it could also be cabled to a 70* computer and used as a printer and card reader, in which case it could read only 72 columns of each card. This contributed to the convention of using eight columns for sequence numbers. In contrast, the PDP-6 stored five characters per word, which gave rise to a convention of five-character sequence numbers. 1950's. Sounded like a washing machine in distress when operating properly. That's the 150 LPM model. University of Colorado had one in the middle 1950's, but it was the 100 LPM model that sounded like a waltzing washing machine: print, print, ..., print, print, ..., print, print, ..., IBM's lexical conventions, traceable to the limitations of the 029 keypunch and 407 card reader (I know, but..) are unduly burdensome. They deter beginners starting on the mainframe career track. No professor, having a limited number of -- 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: Batch TMP RECFM(VB) Input
Ulrich, how about this: 1) create a simple two line rexx in data set A.B.EXEC: /* rexx */ execio * diskr cmdin (finis 2) run your batch tmp with DD=CMDIN pointing to the VB data set and the following line in SYSTSIN: EX 'A.B.EXEC' EX The rexx will read all lines from the data set and put them onto the stack. The TMP will see the data on the stack after the REXX ends and will execute the stacked lines one by one. The rexx may of course also be a PDS member instead of only a plain PS data set. Peter Hunkeler CREDIT SUISSE -- 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: Batch TMP RECFM(VB) Input
Ulrich, how about this: 1) create a simple two line rexx in data set A.B.EXEC: /* rexx */ Or replace //TMP EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DISP=OLD,DSN=VB.INPUT with //TMP EXEC PGM=IKJEFT01, // PARM='EX ''VB.INPUT'' LIST CLIST' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY Norbert Friemel __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 -- 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
SV: Batch TMP RECFM(VB) Input
Hi You may use fixed length records longer than 80 bytes. Med venlig hilsen / Kind regards Frode Pedersen Coop Norden IT Systemteknik +45 43 86 49 94 E-mail: [EMAIL PROTECTED] -Oprindelig meddelelse- Fra: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] På vegne af Ulrich Boche Sendt: 14. marts 2006 17:09 Til: IBM-MAIN@BAMA.UA.EDU Emne: Re: Batch TMP RECFM(VB) Input Binyamin Dissen wrote: You can use 80 character records. Put a + at the end of the line which tells TSO that the command is continued on the next line. I know how to continue TSO input lines. However, in most cases, splitting the line would be more inconvenient than shifting the variable length records. I'm looking for something that's really easy. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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
