Re: instream data
On 2010-06-24 13:59, Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks, I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Back in 1991, I greatly appreciated the JCL enhancements that came in MVS/ESA 4.1 (INCLUDE, SET, proc/include nesting, etc), but I felt disappointed that in-line control-cards were still incompatible with PROCs - like you say. Since the target became MVS/ESA 4.1, most of the VSE/MVS conversions I was involved in didn't use procedures in their MVS JCL, because most of the reasons procs had to be used before MVS/ESA 4.1 were gone. Several of these conversion projects had a VSE scheduler that supported variables in control cards, and needed something equivalent in MVS. So, in MVS, they used TSREPVAR, TSIDCAMS, other similar utilities, or SUBSYS=(CCSS,... -- they're described here: http://gsf-soft.com/Products/CCSS.shtml -- Gilbert Saint-Flour GSF Software http://gsf-soft.com PS: Sorry it took me so long to reply to this message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Chris Mason wrote: Frank You'll be wanting symbol substitution in the instream data next! That actually was I wanted to help me manage for my test/education systems where I did a great deal of work at the (VM) console. I just wanted to be able to set up started task procedures in order to do all sorts of operations without having to bother to start up TSO. This often meant setting up procedures calling utility programs which - since time immemorial - make that the mid- '60s - have used much of the time trivial statements in a SYSIN data set. ... text deleted You might like to look at Declaring Card Files in Jol here: http://tinyurl.com/22jz7vj You can also use any Symbolic Variable is a card image file - it will get replaced by the current value of the Symbolic. When the program reads the card file at execution time, it will read the data with Symbolic replaced. There are also some predefined Symbolics that you can use in Jol. Some of these are: *Jol Automatically Initialized Symbolic Variables* Variable Explanation %SYSDATE The current date in Julian format e.g. 86290 %DAY MONDAY, TUESDAY, etc. %MONTH JANUARY, FEBRUARY, etc. %MONTHNO 01, 02 Through 12 %DAYNO 01 through 31 %YEAR 1987, 1988, etc. %HOURS 0 through 23 %MINS 0 through 59 %SECS 0 through 59 %SYSUIDSystem user identification %SYSPREF Dataset Prefix or Current Directory %SYSPFKProgram function key number from PANELs %SYSTEMMVS, DOS, VM, PC, UNIX etc. %SPOOL HASP, ASP, JES1, JES2, JES3, or Blank %TSOCLASS Contains the SYSOUT class used by TSO to retrieve output from a background job Cheers, Clem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Hi Paul, I'll answer next to your questions. In addition, I'll write an FTP Macro instruction in the next few days, and show you exactly how it works, and how symbolic parameter replacement and so on works. Paul Gilmartin wrote: JCL has changed a lot in 40 years. Has Jol kept pace? I am sure that there are things missing. For example, some things for the Unix subsystem. Jol has a very flexible Macro language, and new commands can be added by Users, and shared by Users. Also, Jol not only works on the mainframe, but there is a version that runs on Windows, and creates either Dynamic Allocation code, or JCL that can be submitted to Z/OS. Additionally, there is a DOS/VSE version and a Linux version to be released shortly. By the way, the Windows and Linux versions also run Windows programs, ans well as running Mainframe programs. Jol has progressed a long way towards being the Universal Command Language, and active user participation is actively encouraged. o Does Jol generate JCL and write it to INTRDR? If not, how does it operate? Mainframe Jol can operate in three main ways: 1. It can generate JCL to run in background. It is written to INTRDR. 2. It can NOT create JCL (apart from some startup JCL), and use Dynamic Allocation to run jobs. 3. It can run the created job directly under TSO using Dynamic Allocation. o Does Jol provide the ENQ deadlock protection provided by batch initiators? Sure. The Dynamic Allocation (non JCL) version uses similar ENQ mechanisms, or allows SVC 99 to contral data set allocation. Incidentally, there is an ENQ instruction in Jol that you can use to ENQ on whichever resources you wish to. o Does Jol provide flow control at least comparable to JCL's IF...THEN...ELSE...ENDIF? Absolutely! For example: If Prog1 = 10 prog20 99 maxcc 16 then submit job2; and If %day='Monday' and %month='June' then run step20; o Does Jol support tapes with facilities such as RETAIN and VOL=REF? It does it all automatically. Jol looks at each job and checks to see if a data set is passed to a subsequent step. If so, it uses Disp=(..,PASS), and Vol Retain, and VolRefs if necessary. It looks up the Catalog for Old data sets (to make sure they will be available at Run time), and uses the Volume information for VolRef and Retain, as necessary. o Can Jol's card image files have non-cardlike attributes such as RECFM=VB,LRECL=254 Yes, although the maximum LRECL is limited to 100. This can be increased, if desired. o Does Jol allow PARM length100? Not today. But this can be changed easily. How long would you like it to be? Please don't say unlimited! o Does Jol support jobs with a mixture of steps running authorized and unauthorized programs, with the security of batch JCL? Yes. It uses the same mechanism as the Initiator, and therefore operates in the same way. Most of these questions can be summarized as, What facilities of today's JCL would the programmer sacrifice to gain the benefits of Jol? Hopefully, all necessary missing features can be added quickly. We are setting a new website with more details, and it will allow user participation. Meanwhile, Jol can be downloaded, and full documentation is available. Cheers, Clem -- gil On Mon, 12 Jul 2010 10:03:58 +1000, Clement Clarke wrote: For over 40 years, Jol has allowed you to do just that. Jol is a free format JCL replacement language, loosely based on PL/I. You can declare Data Sets and Programs, and use commands such as Run (a program) or Copy a data set and so on. Jol comes with the ability to declare card files in Jol Procedures or in Macros (which allow you to add new instructions to Jol in a high level language). Furthermore, you can replace Symbolic Parameters or Variables in card image files to create Utility Control Statements and so on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank For over 40 years, Jol has allowed you to do just that. Jol is a free format JCL replacement language, loosely based on PL/I. You can declare Data Sets and Programs, and use commands such as Run (a program) or Copy a data set and so on. Jol comes with the ability to declare card files in Jol Procedures or in Macros (which allow you to add new instructions to Jol in a high level language). Furthermore, you can replace Symbolic Parameters or Variables in card image files to create Utility Control Statements and so on. This example used predefined Symbolic Variables of %DAYNO, %MONTHO and %YEAR to place the current date in a control card. DCL CONTROL * REPLACE; %DAYNO%MONTHNO%YEAR EOF; PRINT CONTROL; /* Copy card to printer */ These statements create a Data Set Identifier (DSID) called CONTROL which will have:- Columns Data 1-2 day number, e.g. 09 3-4 month number, e.g. 07 5-8 year number, e.g. 2009 For example: 09072009 This control file can be used by a program to print headings on a report. You can see more here: For over 40 years, Jol has allowed you to do just that. Jol is a free format JCL replacement language, loosely based on PL/I. You can declare Data Sets and Programs, and use commands such as Run (a program) or Copy a data set and so on. Jol comes with the ability to declare card files in Jol Procedures or in Macros (which allow you to add new instructions to Jol in a high level language). Furthermore, you can replace Symbolic Parameters or Variables in card image files to create Utility Control Statements and so on. This example used predefined Symbolic Variables of %DAYNO, %MONTHO and %YEAR to place the current date in a control card. DCL CONTROL * REPLACE; %DAYNO%MONTHNO%YEAR EOF; PRINT CONTROL; /* Copy card to printer */ These statements create a Data Set Identifier (DSID) called CONTROL which will have:- Columns Data 1-2 day number, e.g. 09 3-4 month number, e.g. 07 5-8 year number, e.g. 2009 For example: 09072009 This control file can be used by a program to print headings on a report. You can see more here: http://tinyurl.com/22jz7vj Cheers, Clem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Mon, 12 Jul 2010 10:03:58 +1000, Clement Clarke wrote: For over 40 years, Jol has allowed you to do just that. Jol is a free format JCL replacement language, loosely based on PL/I. You can declare Data Sets and Programs, and use commands such as Run (a program) or Copy a data set and so on. Jol comes with the ability to declare card files in Jol Procedures or in Macros (which allow you to add new instructions to Jol in a high level language). Furthermore, you can replace Symbolic Parameters or Variables in card image files to create Utility Control Statements and so on. JCL has changed a lot in 40 years. Has Jol kept pace? o Does Jol generate JCL and write it to INTRDR? If not, how does it operate? o Does Jol provide the ENQ deadlock protection provided by batch initiators? o Does Jol provide flow control at least comparable to JCL's IF...THEN...ELSE...ENDIF? o Does Jol support tapes with facilities such as RETAIN and VOL=REF? o Can Jol's card image files have non-cardlike attributes such as RECFM=VB,LRECL=254 o Does Jol allow PARM length100? o Does Jol support jobs with a mixture of steps running authorized and unauthorized programs, with the security of batch JCL? Most of these questions can be summarized as, What facilities of today's JCL would the programmer sacrifice to gain the benefits of Jol? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
In 053f2631ec9c584883847c8b4970a22807337...@josqems1.jsq.bsg.ad.adp.com, on 06/27/2010 at 09:53 AM, Farley, Peter x23353 peter.far...@broadridge.com said: Pardon my immense ignorance, but how would such an obviously useful extension be a serious integrity breach? By having access to privileged functions if run in the Converter environment, and hanging it if forked to its own process. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
-snip--- There was a time, not very long ago, when ad-hoc use of INTRDR was deprecated (controlled?) because they were a finite resource. I suspect one could still create pretty much havoc by OPENing INTRDRs up to a system limit, and feeding each the content of an SVC dump (perhaps throttled to a few dozen bytes/sec) and watching the SKIPPING FOR JOB CARD messages scroll by on the operators' console. ---unsnip- Once upon a time I used a job called RABBIT to stress HASP and JES2. All it did was feed ten copies of itself through the internal reader. With ten copies running, it never took more that a very few minutes to plug up the system pretty badly. I used it to get operators to pay attention to their jobs, instead of playing gin rummy. It usually took only one occurence to smarten them up wonderfully. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
In listserv%201006262246290980.0...@bama.ua.edu, on 06/26/2010 at 10:46 PM, Paul Gilmartin paulgboul...@aim.com said: I do not mean to conflate converter operations with interpreter operations. That doesn't change things; it would be an integrity exoposure either way. If the external generator were forked into a separate address space and setuid submitter, the security exposures would be limited to DoS via long-running or output-spewing generators. Aside from that, Mrs. Lincoln, how was the play? Even as they now recognize /* Rexx ...? In principle, but it would take more code. How does one pass a handle of a PDS member to /bin/sh? Extend the syntax. Use a pipe. There are ways to do it. This instantly gets into trouble with the VTAM TSO half-ass^H^H^Hduplex terminal handling. ObMarkTwain You mean the missing functionality that's been there for decades? Cf. the infuriating RUNNING/INPUT toggle in 3270 OMVS. That's the OMVS application code, not the VTIOC services. Similarly, the behavior of ISPF is due to ISPF code, not TSO. I vaguely recall there there is code on the CBT tape that runs full duplex in TSO. It's not rocket science. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, June 26, 2010 10:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: instream data In listserv%201006252231432049.0...@bama.ua.edu, on 06/25/2010 at 10:31 PM, Paul Gilmartin paulgboul...@aim.com said: Wouldn't it be great if the C/I could run shell scripts (or Rexx, or Perl or ...)? No; it would be a serious integrity breach. Pardon my immense ignorance, but how would such an obviously useful extension be a serious integrity breach? I just do not see the connection. A looping Rexx script submitting infinite new jobs would be just as much of an annoyance as a shell or perl script doing the same thing, but neither rises to the level of integrity breach as far as I can see; punishable programmer stupidity, yes, but not integrity breach. Please explain. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Sun, 2010-06-27 at 09:53 -0400, Farley, Peter x23353 wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, June 26, 2010 10:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: instream data In listserv%201006252231432049.0...@bama.ua.edu, on 06/25/2010 at 10:31 PM, Paul Gilmartin paulgboul...@aim.com said: Wouldn't it be great if the C/I could run shell scripts (or Rexx, or Perl or ...)? No; it would be a serious integrity breach. Pardon my immense ignorance, but how would such an obviously useful extension be a serious integrity breach? I just do not see the connection. A looping Rexx script submitting infinite new jobs would be just as much of an annoyance as a shell or perl script doing the same thing, but neither rises to the level of integrity breach as far as I can see; punishable programmer stupidity, yes, but not integrity breach. Please explain. Peter I am also quite curious as to why/how this would be a breach of integrity. The closest that I have come up with is if the script were allowed to do things such as open/read/write a standard file WHILE EXECUTING AS PART OF THE CONVERTER/INTERPRETER. That might allow improper file access if the initiator is running RACF trusted or with a high security ID. So I guess that I would like the ability to run a special purpose scripting language to enhance JCL creation. Or looping, how I would like some looping at times! -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Sun, 27 Jun 2010 14:10:06 EDT, Ed Finnell wrote: In a message dated 6/27/2010 12:27:56 P.M. Central Daylight Time, joarmc writes: like the ability to run a special purpose scripting language to enhance JCL creation. Or looping, how I would like some looping at times! Yeah, just get your XEDIT guy to code it up. 6000 jobs later, the system comes back! There was a time, not very long ago, when ad-hoc use of INTRDR was deprecated (controlled?) because they were a finite resource. I suspect one could still create pretty much havoc by OPENing INTRDRs up to a system limit, and feeding each the content of an SVC dump (perhaps throttled to a few dozen bytes/sec) and watching the SKIPPING FOR JOB CARD messages scroll by on the operators' console. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Fri, Jun 25, 2010 at 10:31 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Fri, 25 Jun 2010 16:50:23 -0500, Kirk Wolf wrote: snip Wouldn't it be great if the C/I could run shell scripts (or Rexx, or Perl or ...)? //NAME SHELL,DLM=EOD ... shell commands, executed after substituting JCL symbols, whose stdout is fed back to the C/I input stream. ... EOD (Just seeking the least cognitive dissonance to dinos.) Gil, I link your idea a lot. It reminds me of how Unix executables can be any interpreter using the #! /some/prog The general notion that JCL could adopt shell features (while remaining backward compatible) is very interesting. Kirk Wolf Dovetailed Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Howard Brazee wrote: Is that like the ZOOM or SHOWPROC commands that have come with MVS for a decade or so? They come with MVS ... aka OS/390 ... aka z/OS for how long? What are these commands? How do you use them? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
In listserv%201006252231432049.0...@bama.ua.edu, on 06/25/2010 at 10:31 PM, Paul Gilmartin paulgboul...@aim.com said: Wouldn't it be great if the C/I could run shell scripts (or Rexx, or Perl or ...)? No; it would be a serious integrity breach. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
In aanlktinbyi07tylalwfnxfierj7jzlhw5-ithuwxw...@mail.gmail.com, on 06/26/2010 at 06:26 AM, Kirk Wolf k...@dovetail.com said: I link your idea a lot. It reminds me of how Unix executables can be any interpreter using the #! /some/prog The C/I is not a shell. Now, what would be nice would be if the TSO service routines could recognize a shebang or equivalent in SYSPROC and SYSEXEC members. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Sat, 26 Jun 2010 22:52:34 -0400, Shmuel Metz (Seymour J.) wrote: I link your idea a lot. It reminds me of how Unix executables can be any interpreter using the #! /some/prog The C/I is not a shell. I do not mean to conflate converter operations with interpreter operations. I was looking for an enhancement to the lame generative facilities (mostly now limited to PROC and SET) of the converter, such as converter-phase conditionals and looping. Converter, not Interpreter. I would expect John Gilmore's language of choice if this were done to be HLASM with PUNCH statement output fed back to the Converter input stream. If the external generator were forked into a separate address space and setuid submitter, the security exposures would be limited to DoS via long-running or output-spewing generators. Now, what would be nice would be if the TSO service routines could recognize a shebang or equivalent in SYSPROC and SYSEXEC members. Even as they now recognize /* Rexx ...? I agree. Do SYSCALL spawn sh Hmmm. How does one pass a handle of a PDS member to /bin/sh? Copy it to HFS and pass that? Connect stdin to keyboard and stdout and stderr to display? Oops! This instantly gets into trouble with the VTAM TSO half-ass^H^H^Hduplex terminal handling. Cf. the infuriating RUNNING/INPUT toggle in 3270 OMVS. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Thompson, Steve wrote: Let us not forget JES3 (ASP). Interestingly JES2 supports a larger in-stream LRECL than JES3 does (or did, they may have fixed that in the last few releases). It was the other way around. For decades, JES3 supported instream data up to LRECL=32760 while JES2 supported much smaller sizes -- the predominant one being LRECL=80. -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
[replying to my own post...] Steve Comstock wrote: Frank Swarbrick wrote: Steve, That is, in fact, exactly what we have: //PROC DDAR02 PARMENV=PROD.APPLIB //SORT EXEC PGM=SORT //DFSPARM DD DSN=PARMENV..PARM(DDAR021), //DISP=SHR I simply would prefer to see: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A),EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. Try this: from the screen where you do the PEEK, issue the KEYS command and assign a key, say PF4, to :PEEK like: F4 :PEEK___ then end (F3) to save your changes and try placing the cursor on the DD statement and pressing F4. Might make life simpler. The above is if your PEEK command is a line command (entered in the sequence number field; otherwise, omit the leading colon (:). -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 24 Jun 2010 15:40:31 -0700, mzel...@flash.net (Mark Zelden) wrote:
Is that like the ZOOM or SHOWPROC commands that have come with MVS for
a decade or so?
Come with MVS? Please point me to where these are distributed if you can
because I've only seen home grown utilities of this nature (including my
own).
They are REXX utilities. I edit or view some JCL, type Zoom at the
top, and put my cursor on a dataset before hitting Enter. When I
started this job 11 years ago, this shop didn't know about them, but
the customer coordinators were very appreciative when I showed it to
them.Showproc isn't as useful as zoom as it doesn't know about the
// JCLLIB ORDER=(my.proc.lib1,my.proc.lib2)
command.
I see the commands in 'UMS.REXX.APPL.LIB', but since our shop is UMS,
I see that this is location is shop dependent.
My path here is from:
ALLOC F(SYSEXEC) SHR REUSE DA('D44201.REXX.LIB' +
'UMS.REXX.APPL.LIB' +
'ISP.SISPEXEC')
Anybody else able to help here?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Howard Brazee wrote:
On 24 Jun 2010 15:40:31 -0700, mzel...@flash.net (Mark Zelden) wrote:
Is that like the ZOOM or SHOWPROC commands that have come with MVS for
a decade or so?
Come with MVS? Please point me to where these are distributed if you can
because I've only seen home grown utilities of this nature (including my
own).
They are REXX utilities. I edit or view some JCL, type Zoom at the
top, and put my cursor on a dataset before hitting Enter. When I
started this job 11 years ago, this shop didn't know about them, but
the customer coordinators were very appreciative when I showed it to
them.Showproc isn't as useful as zoom as it doesn't know about the
// JCLLIB ORDER=(my.proc.lib1,my.proc.lib2)
command.
I see the commands in 'UMS.REXX.APPL.LIB', but since our shop is UMS,
I see that this is location is shop dependent.
My path here is from:
ALLOC F(SYSEXEC) SHR REUSE DA('D44201.REXX.LIB' +
'UMS.REXX.APPL.LIB' +
'ISP.SISPEXEC')
Anybody else able to help here?
I'm pretty sure those are not generally distributed with z/OS.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Fri, 25 Jun 2010 09:51:34 -0600, Howard Brazee wrote: They are REXX utilities. I edit or view some JCL, type Zoom at the top, and put my cursor on a dataset before hitting Enter I see the commands in 'UMS.REXX.APPL.LIB', but since our shop is UMS, I see that this is location is shop dependent. ... Anybody else able to help here? If you browse them, do they show any copyright information indicating where they came from? IAC, I use Gilbert's FASTPATH for this and other very useful tools. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Fri, 25 Jun 2010 09:51:34 -0600, Howard Brazee howard.bra...@cusys.edu wrote: On 24 Jun 2010 15:40:31 -0700, mzel...@flash.net (Mark Zelden) wrote: Is that like the ZOOM or SHOWPROC commands that have come with MVS for a decade or so? Come with MVS? Please point me to where these are distributed if you can because I've only seen home grown utilities of this nature (including my own). They are REXX utilities. I edit or view some JCL, type Zoom at the top, and put my cursor on a dataset before hitting Enter. When I started this job 11 years ago, this shop didn't know about them, but the customer coordinators were very appreciative when I showed it to them.Showproc isn't as useful as zoom as it doesn't know about the // JCLLIB ORDER=(my.proc.lib1,my.proc.lib2) command. My PROCSHOW utility does :-) No, I've never added it to my CBT file nor web site since the PROCLIBs must be manually coded. There is a bunch of code similar to this: When SMFNAME = ASYS then do tot = tot + 1 proclib.tot = ASYS.PROCLIB tot = tot + 1 proclib.tot = ASYS.TECH.PROCLIB tot = tot + 1 proclib.tot = SYS1.PROCLIB tot = tot + 1 proclib.tot = SYS2.PROCLIB tot = tot + 1 proclib.tot = PROD.PROCLIB tot = tot + 1 proclib.tot = TEST.PROCLIB End -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 25 Jun 2010 09:07:31 -0700, st...@trainersfriend.com (Steve Comstock) wrote: I'm pretty sure those are not generally distributed with z/OS. I wonder how they got distributed to these different shops then. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Fri, 25 Jun 2010 10:34:01 -0600, Howard Brazee
howard.bra...@cusys.edu wrote:
On 25 Jun 2010 09:07:31 -0700, st...@trainersfriend.com (Steve
Comstock) wrote:
I'm pretty sure those are not generally distributed with z/OS.
I wonder how they got distributed to these different shops then.
Looking at the code, I see that Zoom is privately created:
/*PROGRAM: ZOOM **
**AUTHOR:JOHN BUBENHEIM - UNION BANK **
**SYNTAX:ZOOM E - EDIT MODE **
**PURPOSE: PROVIDE CURSOR SENSITIVE DSN AND DDNAME RECOGNITION **
ALLOWING USERS TO ZOOM INTO ANOTHER DATA SET **
WITHOUT LEAVING THEIR CURRENT EDIT SESSION. **
**USAGE PLACE CURSOR UNDER ANY VALID DSN OR DDNAME CHARACTER **
AND START ZOOM FROM THE COMMAND LINE OR A PRE- **
DEFINED PFKEY. PFKEY USE IS RECOMMENDED TO MINIMIZE **
CURSOR REPOSITIONING. IF THE CURSOR IS LEFT ON THE **
COMMAND LINE, THE FIRST DATA LINE DISPLAYED WILL BE **
SEARCHED FOR A VALID DSN. **
**FEATURES: DSN SYNTAX CHECKING WITH SYSDSN **
** SYMBOLIC VARIABLE SUBSTITUTION. **
** CONCATENATION RECOGNITION WITH MEMBER SEARCH OPTION. **
** AUTOMATIC SWITCH TO BROWSE MODE IF EDIT FAILS. **
** ALLOWS EDIT SESSIONS TO BE STACKED. **
** ALLOWS MODULAR ADDITION OF NEW FUNCTION. */
SETUP:
/*/
/* SET ERROR AND MESSAGE CONTROLS **
** ESTABLISH EDIT MACRO ENVIRONMENT **
** SET MODE */
/*/
ISPEXEC CONTROL ERRORS RETURN
X = MSG(OFF)
ISREDIT MACRO (FUNC)
IF TRANSLATE(SUBSTR(FUNC,1,1)) = E THEN FUNC = EDIT
ELSE FUNC = BROWSE
CHECK_CURSOR_DATA:
/*/
/* FIND AND SAVE CURRENT CURSOR LOCATION
REPOSITION CURSOR TO DATA FIELD IF NECESSARY
SET DATA LENGTH AND A LIST OF VALID DSN CHARACTERS
DETERMINE IF CURSOR IS ON VALID DSN CHARACTER
CHECK IF DSN OR DDNAME AND CALL APPROPRIATE ROUTINE */
/*/
ISREDIT (LIN,COL) = CURSOR
OLIN = LIN ; OCOL = COL
IF COL = 0 THEN
DO
ISREDIT FIND '.' .ZCSR .ZCSR
IF RC = 4 THEN ISREDIT CURSOR = .ZCSR 1
ISREDIT (LIN,COL) = CURSOR
END
ISREDIT (DATA) = LINE .ZCSR
DATA = TRANSLATE(DATA)
LEN = LENGTH(DATA)
VAL = abcdefghijklmnopqrstuvw...@#$0123456789.()-+
IF VERIFY(SUBSTR(DATA,COL,1),VAL,N) \= 0 THEN
DO
SAY INVALID CURSOR LOCATION
SIGNAL QUIT
END
MEM =
IF SUBSTR(DATA,1,2) = // COL POS( DD ,DATA) THEN CALL DDNAME
ELSE CALL DSNAME
PROCESS_STACK:
/*/
/* PULL DSN'S FROM STACK IN FIFO ORDER
CHECK FOR SYMBOLICS AND TAKE APPROPRIATE ACTION
PERFORM FIRST LEVEL CHECK USING SYSDSN
PROTECT CURRENT STACK FROM RECURSIVE EDITS
CHECK SYSDSN MSG AND DECIDE WHETHER TO PROCEED */
/*/
DO QUEUED()
PULL DSN
IF POS(,DSN) \= 0 POS(,DSN) = 0 THEN CALL SYMBOLIC
IF MEM \= THEN DSN = DSN || ( || MEM || )
MSG = SYSDSN('DSN')
NEWSTACK
IF (MSG = INVALID DATASET NAME, 'DSN' MEM = ) |,
(MSG = MEMBER NOT FOUND MEM = ) |,
(MSG = OK) THEN INTERPRET CALL FUNC
ELSE SAY MSG - DSN
DELSTACK
END
QUIT:
/*/
/* RESET EXCLUDED LINES
RETURN CURSOR TO ORIGINAL LOCATION
EXIT FROM ZOOM */
/*/
ISREDIT RESET
ISREDIT CURSOR = 0LIN 0COL
EXIT
DDNAME:
/*/
/* THIS ROUTINE IS DESIGNED FOR JCL DDNAME PROCESSING
SET CURRENT DDNAME
DETERMINE TOTAL NUMBER OF LINES
GET NEW LINE OF DATA IF NEEDED AND PARSE IT
FIND ALL OCCURRENCES OF DSN= AND DSNAME= IN CURRENT
DDNAME, REPOSITION CURSOR TO FIRST DSN POSITION, AND
CALL DSNAME (DO NOT PROCESS JCL COMMENT STATEMENTS)
IF CONCATENATION DETECTED (MORE THAN ONE DSN QUEUED)
ASK USER IF MEMBER SEARCH IS DESIRED
RETURN TO ORIGINAL CALLER */
/*/
DDN = SUBSTR(DATA,3,POS( ,DATA) - 3)
ISREDIT (LAST) = LINENUM .ZLAST
DO N = 1 TO (LAST - LIN + 1) BY 1
IF N \= 1 THEN ISREDIT (DATA) = LINE LIN + N - 1
PARSE VAR DATA V1 3 V2 V3 V4 V5
IF V1 = // THEN
SELECT
WHEN SUBSTR(DATA,3,1) = * THEN NOP
WHEN SUBSTR(DATA,3,1) = | N = 1 THEN
DO
IF V2 \= V3 = DD THEN V2 = V4
IF V2 = DD THEN V2 = V3
IF POS(DSNAME=,V2) \= 0 THEN
DO
COL = POS(DSNAME=,DATA) + 7
CALL DSNAME
END
IF
Re: instream data
On Fri, 25 Jun 2010 10:38:52 -0600, Howard Brazee howard.bra...@cusys.edu wrote: On Fri, 25 Jun 2010 10:34:01 -0600, Howard Brazee howard.bra...@cusys.edu wrote: On 25 Jun 2010 09:07:31 -0700, st...@trainersfriend.com (Steve Comstock) wrote: I'm pretty sure those are not generally distributed with z/OS. I wonder how they got distributed to these different shops then. Looking at the code, I see that Zoom is privately created: /*PROGRAM: ZOOM ** **AUTHOR:JOHN BUBENHEIM - UNION BANK ** snip That program is also on CBT file 671 (http://www.cbttape.org) and indicates it was copied from the TSO Times Fall 1994 edition, so it is not surprising it has made its way to more than one shop. I looked at http://www.tsotimes.com/archives.html and it looks like it only goes back to 1995. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Point-and-shoot (was: instream data)
Howard, I think almost every mainframe shop has some form of ZOOM or PEEK or EDDSN (etc). These are often written by someone at the site or brought to the site by someone who used to work at a different site. They are almost always edit macros, which means you can only use them if you're editing or viewing a file. You cannot (for example) use them in browse or when you're on an ISPF menu or when you see a data set name in an ISPF message (etc). AFAIK SimpList has the most powerful point-and-shoot utility. It can be used on any panel, even if the data set name isn't in the screen buffer. It can be used to point at data set names in messages, and members in concatenated libraries (such as programs called by other programs or copy books used by programs or PROCS called by drivers, etc). If you click the following link and see the heading near the top called The most powerful point-and-shoot facility it tells you a bit more about it. http://www.soft-center.com/SimpListFeatures.html Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Fri, 25 Jun 2010 10:34:01 -0600 From: howard.bra...@cusys.edu Subject: Re: instream data To: IBM-MAIN@bama.ua.edu On 25 Jun 2010 09:07:31 -0700, st...@trainersfriend.com (Steve Comstock) wrote: I'm pretty sure those are not generally distributed with z/OS. I wonder how they got distributed to these different shops then. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Look 'em in the eye: FREE Messenger video chat http://go.microsoft.com/?linkid=9734386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
I have a copy of a ZOOM exec, written by Doug Nadel in 1999, with updates in 2000 and 2001, using ZSCREENI and ZSCREENC. Not sure of its origin... * Don * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Instream Data
If someone else has provided this information, I apologize, as I only get a digest- There was, at one time, a submission on the CBT distribution, which provided a subsystem to accomplish just that purpose. I was able to do some interesting extensions to it, as well, but the politics of an absentee management structure led me to put myself out to pasture. Since I've retired, I have no access to my old stuff or an MVS system to dig into the CBT, so I can't refer you directly to which entry it is (or was). Dale Miller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Instream Data
http://cbttape.org/cbtdowns.htm file #364 - Control Card Subsystem. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dale Miller Sent: Friday, June 25, 2010 1:26 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Instream Data If someone else has provided this information, I apologize, as I only get a digest- There was, at one time, a submission on the CBT distribution, which provided a subsystem to accomplish just that purpose. I was able to do some interesting extensions to it, as well, but the politics of an absentee management structure led me to put myself out to pasture. Since I've retired, I have no access to my old stuff or an MVS system to dig into the CBT, so I can't refer you directly to which entry it is (or was). Dale Miller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Paul, Since you mentioned the Unix shell vs JCL, why not use both? Here's a simple example of using the Unix shell with a 'here document' to do parameter substitution for an instream dataset using JCL parameters: // SET NEWGDG=FOO.BAR.MYGDG // SET GDGLIM=3 //* // EXEC PGM=COZBATCH, FREE BPXBATCH replacement // PARM='/NEWGDG=NEWGDG GDGLIM=GDGLIM' //STDOUT DD DSN=TEMP,DISP=(NEW,PASS), // DCB=(RECFM=FB,LRECL=80),SPACE=(CYL,(1,1)) //STDIN DD * cat EOD DEFINE GDG(NAME($NEWGDG) - LIMIT($GDGLIM)- NOEMPTY - SCRATCH) EOD //* //DEFGDG EXEC PGM=IDCAMS //SYSIN DD DSN=TEMP,DISP=(OLD,DELETE) //SYSPRINT DD SYSOUT=* // (And if you know the Unix shell, sed, awk, etc you can see how this could be extended to do all sorts of file processing and symbol substitution in the context of venerable JCL). Of course, it would be much better if we could automatically import JCL variables in the running program, and weren't limited by the pesky 100 character PARM= limit. But we have a workaround to the latter see example #6 here: http://dovetail.com/docs/cozbatch/examples.html Regards, Kirk Wolf Dovetailed Technologies http://dovetail.com PS You going to SHARE in Boston? We will be there on Tuesday doing JZOS meets Web 2.0 On Thu, Jun 24, 2010 at 8:48 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Thu, 24 Jun 2010 13:37:50 -0500, Chris Mason wrote: You'll be wanting symbol substitution in the instream data next! Me, too! When I do an SMP/E zone definition (assuming I'm still allowed to) I'd cherish being able to define several symbols with JCL SET statements, they apply them in JCL DD statements (as I can today), and likewise in instream IDCAMS SYSIN and SMP/E UCLIN data sets (which I can not. The suggestion of a horde of PARMLIB members selected by symbol values and concatenated falls short because of namespace constraints. And what happens if two symbols need to be substituted on the same line. UNIX directories with members selected by parameters would much relieve those constraints, as would a multitude of PS data sets. But from an ISV perspective, how do the parmeter libraries get set up and populated? I'd expect customers to see see either multiple PS data sets or multiple UNIX directories as unacceptable. I'd rather supply a JCLLIB INCLUDE member that the customer could tailor and which would perform all necessary substitutions in DD and SYSIN and UCLIN. Oh! the answer to your question is that a procedure consists of job control language statements and the card images between the //x DD * and /* card images are not job control language statements. Which is hardly an answer at all. On recognizing instream data, the reader shunts it aside to a data set and replaces it in the JCL with a reference to that data set. I see no reason that shouldn't work as well within a PROC as in open code. Symbol substitution would greatly complicate it; it would require substituting symbol values at the point of PROC call rather than at the point of PROC definition. Still a worthwhile facility. I'm accustomed to doing it in POSIX shell scripts; it would be equally useful in MVS JCL. Implementation: UNIX sh generally copies instream data to a file and then passes that file to the command executed. But it does the Right Thing (unlike JCL) and does the copy at the point of procedure call rather than at procedure definition, and substitutes symbols (optionally, of course) with their values at the point of call. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
In 4c2348ff.6f0f.008...@efirstbank.com, on 06/24/2010 at 11:59 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Because of the original implementation of the Reader/Interpreter in OS/360. Is there a technical reason, or is it just because? No; there's an economic and political reason; someone would have to formally request it and provide a compelling business case. The same applies to an option for substituting variables in instream data sets[1]; it won't happen unless enough customers ask for it and provide business cases. We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Is that sound configuration management? Are those data that you might want to change without changing the JCL, or vice versa? [1] Which IMHO is long overdue. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 6/25/2010 at 6:33 AM, in message 20100625225945.4c9f5f58...@smtp.patriot.net, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 4c2348ff.6f0f.008...@efirstbank.com, on 06/24/2010 at 11:59 AM, Frank Swarbrick frank.swarbr...@efirstbank.com said: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Because of the original implementation of the Reader/Interpreter in OS/360. Is there a technical reason, or is it just because? No; there's an economic and political reason; someone would have to formally request it and provide a compelling business case. The same applies to an option for substituting variables in instream data sets[1]; it won't happen unless enough customers ask for it and provide business cases. We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Is that sound configuration management? Are those data that you might want to change without changing the JCL, or vice versa? I don't see there being an disadvantage to changing instream data in a JCL PDS member versus changing it in a parm PDS member. Both have to go through the same change control to be implemented. I see using a parm library being useful only if more than one job is sharing the same parm data, or for use in our operator controlled parm library (which is not controlled by change control). But for most instream data, such as SORT control cards, it's simply a hassle. Not sure if my business case of I just want it is a compelling business case. :-) Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Fri, 25 Jun 2010 16:50:23 -0500, Kirk Wolf wrote: Since you mentioned the Unix shell vs JCL, why not use both? Here's a simple example of using the Unix shell with a 'here document' to do parameter substitution for an instream dataset using JCL parameters: // SET NEWGDG=FOO.BAR.MYGDG // SET GDGLIM=3 //* // EXEC PGM=COZBATCH, FREE BPXBATCH replacement // PARM='/NEWGDG=NEWGDG GDGLIM=GDGLIM' //STDOUT DD DSN=amp;TEMP,DISP=(NEW,PASS), // DCB=(RECFM=FB,LRECL=80),SPACE=(CYL,(1,1)) //STDIN DD * cat EOD DEFINE GDG(NAME($NEWGDG) - LIMIT($GDGLIM)- NOEMPTY - SCRATCH) EOD //* //DEFGDG EXEC PGM=IDCAMS //SYSIN DD DSN=amp;TEMP,DISP=(OLD,DELETE) //SYSPRINT DD SYSOUT=* // I haven't yet ventured into the Co:Z arena, so I'd: #! /bin/sh # Could be arguments to script or read in from # a library member. # NEWGDG=FOO.BAR.MYGDG GDGLIM=3 submit EOD // //NAME JOB ... //* //DEFGDG EXEC PGM=IDCAMS //SYSIN DD * DEFINE GDG(NAME($NEWGDG) - LIMIT($GDGLIM)- NOEMPTY - SCRATCH) //SYSPRINT DD SYSOUT=* // EOD Fewer steps and no 100-character PARM limit. I do this regularly; it's my modal technique for manipulating JCL. Would other IBM-MAIN contributors predict the modal reaction of customers if I inflicted this on them? Or made fourth-party utilities (however free if unsupported) a prerequisite? (And if you know the Unix shell, sed, awk, etc you can see how this could be extended to do all sorts of file processing and symbol substitution in the context of venerable JCL). Some, but not so much as I rely on looping and function calls in the shell to shift that elaboration from C/I to shell. Wouldn't it be great if the C/I could run shell scripts (or Rexx, or Perl or ...)? //NAME SHELL,DLM=EOD ... shell commands, executed after substituting JCL symbols, whose stdout is fed back to the C/I input stream. ... EOD (Just seeking the least cognitive dissonance to dinos.) Of course, it would be much better if we could automatically import JCL variables in the running program, and weren't limited by the pesky 100 character PARM= limit. But we have a workaround to the latter see example #6 here: http://dovetail.com/docs/cozbatch/examples.html A common technique. I suppose that in some cases it threatens the limit of the number of job steps. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
instream data
Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 06/24/10 13:59, Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank My WAG would be a combination of the two. There might have been a good technical reason why not and to change the rules 40+ years after the fact might break working processes in unexpected ways. -- Mark Jacobs Time Customer Service Tampa, FL Serendipity is looking for a needle in a haystack and discovering a farmer's daughter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 24 Jun 2010 11:09:39 -0700, mark.jac...@custserv.com (Mark Jacobs) wrote: On 06/24/10 13:59, Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank My WAG would be a combination of the two. There might have been a good technical reason why not and to change the rules 40+ years after the fact might break working processes in unexpected ways. Besides anything can break if it is touched, I'm not thinking of how his proposed change would break existing procs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, June 24, 2010 1:00 PM To: IBM-MAIN@bama.ua.edu Subject: instream data Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank -- Frank Swarbrick That has been a restriction since the dawn of OS/360. In that case, I think it was due to the primitive nature of the reader code. IIRC, the original reader code (pre HASP), read cards from the card reader. When it detected in-stream data, it actually created an temporary OS dataset and wrote the cards into that dataset. The processing of PROCs (expansion) was done in another part of the code, not in the actual reader. So, to have in stream data would require a more complicated and advanced expansion. And that was not really possible at the time. To the best of my limited knowledge, JES2 still sort of works this way. JCL is read in and written to the job's JESJCL SPOOL dataset. Instream data causes the allocation of a separate SPOOL dataset, with the data being written to it. When th end of the instream data is detected, this sysin SPOOL dataset is close and JES resumes writing the JCL images to the JESJCL SPOOL dataset. Once the job is totally read in, JES2 invokes a z/OS supplied routine to convert the JCL to internal text. If instream data were allowed in a PROC, this converter would need to know how to process it and create/write it to the a new JES SPOOL dataset. Which it does not know how to do. IIRC, JES passes parameters to the converter so that it can read the JESJCL SPOOL dataset and write to the $INTTEXT SPOOL dataset. But the converter does not have an interface create and write to a new sysin type SPOOL dataset. Of course, that is not really a good reason to continue to have this restriction, IMO. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Frank You'll be wanting symbol substitution in the instream data next! That actually was I wanted to help me manage for my test/education systems where I did a great deal of work at the (VM) console. I just wanted to be able to set up started task procedures in order to do all sorts of operations without having to bother to start up TSO. This often meant setting up procedures calling utility programs which - since time immemorial - make that the mid- '60s - have used much of the time trivial statements in a SYSIN data set. If I anticipate what I usually need I can set up a started task procedure with a suitable name with suitable symbol variables. I then used a little program I wrote - no longer available I'm afraid to say - which converted the PARM data into card image records. Naturally I needed a convention for special characters in order to cause the start of a new record and so on. Obviously the temporary output data set from this little program is the typically SYSIN data set of a following utility program step. And, as you might guess, there is a further step which is another little program - also no longer available I'm afraid to say - which can take the temporary output, SYSPRINT often, data set from the utility and print it with WTO statements on the (VM) console. Note that sometimes the function was performed with batch TSO - still not having to bother to start up TSO, as it were. In this way I get both to have a procedure which benefits from sort- of instream data *and* symbol substitution! - Oh! the answer to your question is that a procedure consists of job control language statements and the card images between the //x DD * and /* card images are not job control language statements. Chris Mason On Thu, 24 Jun 2010 11:59:59 -0600, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Mark Jacobs wrote: On 06/24/10 13:59, Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank My WAG would be a combination of the two. There might have been a good technical reason why not and to change the rules 40+ years after the fact might break working processes in unexpected ways. 'sFunny, I didn't see your original post, Frank. Are you not posting to list directly now? Anyway, it is what it is. But a simple xx.PARMLIB with members that contain what you would put into instream data seems to work just fine, right? Out of curiosity, why do you consider instream data better than that? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, June 24, 2010 11:00 AM To: IBM-MAIN@bama.ua.edu Subject: instream data Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Well, I might argue with the assertion Instream datasets are good as I try to avoid them in production jobs, but that's just me. I put most such data as members of a datalib PDS(E). On the other hand, it is quite possible to use overrides to make instream data available to a PROC step (it is trickier to get it into a nested PROC) //STEP1 EXEC MYPROC //SYSIN DD * Stuff //MYPROC PROC //MYSTEP EXEC PGM=MYPGM //SYSIN DD etc. // PEND Dave Gibney Information Technology Services Washington State University Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank Ah, here we are. I got the first reply before I got your original post. That explains it. The wonders of email, eh? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Thursday, June 24, 2010 1:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: instream data SNIPPAGE That has been a restriction since the dawn of OS/360. In that case, I think it was due to the primitive nature of the reader code. IIRC, the original reader code (pre HASP), read cards from the card reader. When it detected in-stream data, it actually created an temporary OS dataset and wrote the cards into that dataset. The processing of PROCs (expansion) was done in another part of the code, not in the actual reader. So, to have in stream data would require a more complicated and advanced expansion. And that was not really possible at the time. SNIP JES2 specific comment Of course, that is not really a good reason to continue to have this restriction, IMO. SNIPPAGE Let us not forget JES3 (ASP). Interestingly JES2 supports a larger in-stream LRECL than JES3 does (or did, they may have fixed that in the last few releases). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Steve, That is, in fact, exactly what we have: //PROC DDAR02 PARMENV=PROD.APPLIB //SORT EXEC PGM=SORT //DFSPARM DD DSN=PARMENV..PARM(DDAR021), //DISP=SHR I simply would prefer to see: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A), EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. But instream still seems to me to be better. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 6/24/2010 at 12:46 PM, in message 4c23a807.8060...@trainersfriend.com, Steve Comstock st...@trainersfriend.com wrote: Mark Jacobs wrote: On 06/24/10 13:59, Frank Swarbrick wrote: Now that we've been on z/OS for a few weeks I feel to need to ask a question that has annoyed me since I started working on z/OS two years ago. Instream datasets are good. Why are they not supported inside of procs? Is there a technical reason, or is it just because? We use procs for almost all of our production jobs, with many steps that could take advantage of instream datasets if not for this restriction. Thanks, Frank My WAG would be a combination of the two. There might have been a good technical reason why not and to change the rules 40+ years after the fact might break working processes in unexpected ways. 'sFunny, I didn't see your original post, Frank. Are you not posting to list directly now? Anyway, it is what it is. But a simple xx.PARMLIB with members that contain what you would put into instream data seems to work just fine, right? Out of curiosity, why do you consider instream data better than that? The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On 24 Jun 2010 13:13:25 -0700, frank.swarbr...@efirstbank.com (Frank Swarbrick) wrote: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A), EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. But instream still seems to me to be better. Frank Is that like the ZOOM or SHOWPROC commands that have come with MVS for a decade or so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
No idea. I have not been on MVS for decades. On 6/24/2010 at 2:43 PM, in message opg726pc9c7v80nvstalto1d1c7b3o7...@4ax.com, Howard Brazee howard.bra...@cusys.edu wrote: On 24 Jun 2010 13:13:25 -0700, frank.swarbr...@efirstbank.com (Frank Swarbrick) wrote: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A), EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. But instream still seems to me to be better. Frank Is that like the ZOOM or SHOWPROC commands that have come with MVS for a decade or so? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
Frank Swarbrick wrote: Steve, That is, in fact, exactly what we have: //PROC DDAR02 PARMENV=PROD.APPLIB //SORT EXEC PGM=SORT //DFSPARM DD DSN=PARMENV..PARM(DDAR021), //DISP=SHR I simply would prefer to see: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A), EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. Try this: from the screen where you do the PEEK, issue the KEYS command and assign a key, say PF4, to :PEEK like: F4 :PEEK___ then end (F3) to save your changes and try placing the cursor on the DD statement and pressing F4. Might make life simpler. But instream still seems to me to be better. Frank -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Thu, 24 Jun 2010 14:43:06 -0600, Howard Brazee howard.bra...@cusys.edu wrote: On 24 Jun 2010 13:13:25 -0700, frank.swarbr...@efirstbank.com (Frank Swarbrick) wrote: //PROC DDAR02 //SORT EXEC PGM=SORT //DFSPARM DD * SORT FIELDS=(1,10,PD,A, 13,4,PD,A, 17,4,PD,A, 11,2,PD,A), EQUALS Someone here did write a nice PEEK command where we type PEEK on the command line and put our cursor on the DD statement and it will go to the correct library and pull up the member. But instream still seems to me to be better. Frank Is that like the ZOOM or SHOWPROC commands that have come with MVS for a decade or so? Come with MVS? Please point me to where these are distributed if you can because I've only seen home grown utilities of this nature (including my own). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: instream data
On Thu, 24 Jun 2010 13:37:50 -0500, Chris Mason wrote: You'll be wanting symbol substitution in the instream data next! Me, too! When I do an SMP/E zone definition (assuming I'm still allowed to) I'd cherish being able to define several symbols with JCL SET statements, they apply them in JCL DD statements (as I can today), and likewise in instream IDCAMS SYSIN and SMP/E UCLIN data sets (which I can not. The suggestion of a horde of PARMLIB members selected by symbol values and concatenated falls short because of namespace constraints. And what happens if two symbols need to be substituted on the same line. UNIX directories with members selected by parameters would much relieve those constraints, as would a multitude of PS data sets. But from an ISV perspective, how do the parmeter libraries get set up and populated? I'd expect customers to see see either multiple PS data sets or multiple UNIX directories as unacceptable. I'd rather supply a JCLLIB INCLUDE member that the customer could tailor and which would perform all necessary substitutions in DD and SYSIN and UCLIN. Oh! the answer to your question is that a procedure consists of job control language statements and the card images between the //x DD * and /* card images are not job control language statements. Which is hardly an answer at all. On recognizing instream data, the reader shunts it aside to a data set and replaces it in the JCL with a reference to that data set. I see no reason that shouldn't work as well within a PROC as in open code. Symbol substitution would greatly complicate it; it would require substituting symbol values at the point of PROC call rather than at the point of PROC definition. Still a worthwhile facility. I'm accustomed to doing it in POSIX shell scripts; it would be equally useful in MVS JCL. Implementation: UNIX sh generally copies instream data to a file and then passes that file to the command executed. But it does the Right Thing (unlike JCL) and does the copy at the point of procedure call rather than at procedure definition, and substitutes symbols (optionally, of course) with their values at the point of call. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PUBLIBZ (was: TSO TRANSMIT and instream data set DLM=)
On Mon, 28 Jan 2008 20:22:34 -0600, Paul [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BTW, is there a new format of Publibz? Suddenly, I seem to be required to display a shelf list before I can filter for a string in a publication title. This could be undesirable on a slow connection. I'll have to see whether I get used to it. IBM changed some internal tools and the templates used for developing IBM web pages, and the library maintainer found that his automated tools for maintaing the library pages would not work any more. In addition, the library has enough pages that he could not maintain them manually. Removing the ability to search for books by title before displaying the list allowed continued use of the automated tools, so that's the approach he took. He has now figured out another design for the library web pages that allowed a reasonable way to maintain them, and still allows the title search function to work. The new pages are live now, and you can find them in the same place. They have a different format, but the function works well, in my opinion. For z/OS R9, see http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r9books.html -- Walt Farrell, CISSP IBM STSM, z/OS Security 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: PUBLIBZ (was: TSO TRANSMIT and instream data set DLM=)
On Fri, 1 Feb 2008 12:45:09 -0600, Walt Farrell wrote: He has now figured out another design for the library web pages that allowed a reasonable way to maintain them, and still allows the title search function to work. The new pages are live now, and you can find them in the same place. They have a different format, but the function works well, in my opinion. Thanks. Aw, shucks; I raised my hopes falsely. I notice that once I display a list of selected documents, I see a Search Documents option -- I thought, just what I long wanted: a facility to search for keywords in a subset of documents selected by title. Alas, it doesn't do that; it goes back and searches the entire shelf. The search is so fast it scarcely matters to me; I just feel a little guilt at spending IBM's cycles. For z/OS R9, see http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r9books.html Thanks for not putting a period after the URL. I hate when people do that. Thanks, 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: TSO TRANSMIT and instream data set DLM=
Paul Gilmartin wrote: BTW, is there a new format of Publibz? Suddenly, I seem to be required to display a shelf list before I can filter for a string in a publication title. This could be undesirable on a slow connection. I'll have to see whether I get used to it. (I really wish I could have searched for TRANSMIT in all publications whose titles contain TSO.) I think that the new format sucks. It is harder to search for information if you are not sure to which component it belongs. Also, I don't remember seeing any notice that there was going to be a change. Are these the same people who keep updating IBMLINK without telling anyone??? Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: TSO TRANSMIT and instream data set DLM=
On Tue, 29 Jan 2008 19:49:03 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. Hmmm. I see DD names are now SYSUT1 and SYSUT2 instead of INFILE and OUTFILE. I guess Standards is Good. Does it now respect alternate DD name lists? It claims to. And if you use the TRSMAIN alias, it uses the old DDNAMEs by default. This part is quite nicely done, by the look of things. Tony H. -- 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: TSO TRANSMIT and instream data set DLM=
Paul [EMAIL PROTECTED] wrote: One of my disappointments with TSO TRANSMIT is that I know no safe way to imbed INMR text in an instream data set: the format seems to allow any digraph to appear in columns 1-2. But today, attempting to test a trial-and-error routine to scan a TRANSMITted IEBCOPY unloaded JCL library for a digraph not appearing in columns 1-2, I was startled to find no '//' (but many '/*') in those columns. I consider this a statistical anomaly -- I found numerous '//' in 2-3 and wrapped from 80-1. Have the authors done us a favor by coding to avoid '//' in 1-2? I can find no mention of this in the documentation. I'd be delighted to exploit the feature if I were confident it was supported. BTW, is there a new format of Publibz? Suddenly, I seem to be required to display a shelf list before I can filter for a string in a publication title. This could be undesirable on a slow connection. I'll have to see whether I get used to it. (I really wish I could have searched for TRANSMIT in all publications whose titles contain TSO.) -- gil Paul, See the following as an example of how to include such data instream using standard IBM utilities. This example includes Terse output (but could easily be Transmit), that has been reformatted as 64 bytes and offset to pos 3. It uses the fact that the lrecl for a dataset can be overridden so long as is still valid for the blocksize. So we override to 64 on the SPLIT step, then back to 1024 on the unterse step..(also watch the nested DLMs XX, YY,ZZ!!!) I'd like to take credit for it;-).. but the IEBGENER/IEBDG steps are based on the method that IBM uses within z/OS HCD to transmit IODFs..I just adapted it to use DSS/TRSMAIN input Cheers roy //jobname JOB (0),'XMIT IODF', // NOTIFY=SYSUID, // CLASS=X,MSGCLASS=A //* //* DSS DUMP IODF TO TEMPORARY FILE //* //DSS EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DUMP DD DSN=DSSIODF,DISP=(,PASS), // UNIT=SYSDA,SPACE=(CYL,(50,50),RLSE) //SYSIN DD * DUMP DATASET (INCLUDE (- SYSX.IODF0B.CLUSTER - ))- ALLDATA(*) ALLEXCP - OUTDD(DUMP) /* //* //* TERSE THE DSS DUMP //* //TERSE EXEC PGM=TRSMAIN,PARM='PACK' //SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA) //INFILEDD DISP=OLD,DSN=DSSIODF //OUTFILE DD DISP=(,PASS),DSN=TERIODF, // UNIT=SYSDA,SPACE=(CYL,(50,10),RLSE) //* //* OVERRIDE THE LRECL TO SPLIT INTO 64 BYTE CHUNKS //* AND SHIFT TO COL3. THIS ALLOWS TO BE SUBMITTED //* INSTREAM. //* //* This Step uses the technique of overriding the lrecl //* of the previous terse output to 64. //* This works as 64 is a common factor of 1024 //* (and thus of the blocksize) //* If you use this for other than terse with other lrecls //* ie 80, then ensure the blocksize is a multiple of 64 ie 8000 //* //SPLIT EXEC PGM=IEBDG //SYSPRINT DD SYSOUT=* //INDD DSN=TERIODF,DISP=OLD, //LRECL=64,RECFM=FB //OUT DD DSN=SPLIT,DISP=(,PASS),SPACE=(CYL,(50,10),RLSE), //LRECL=80,RECFM=FB //SYSIN DD * DSD OUTPUT=(OUT),INPUT=(IN) FD NAME=FD1,LENGTH=2 FD NAME=FD2,LENGTH=64,STARTLOC=3,FROMLOC=1,INPUT=IN CREATE NAME=(FD1,FD2),INPUT=IN END //* //* NOW SUBMIT TO REMOTE NODE //* //SUBMIT EXEC PGM=IEBGENER //SYSINDD DUMMY //SYSPRINT DD DUMMY //SYSUT2 DD SYSOUT=(,INTRDR) //SYSUT1 DD DATA,DLM=ZZ //jobname JOB (0),'RESTORE IODF', // NOTIFY=SYSUID, // CLASS=X,MSGCLASS=A /*ROUTE XEQ remote node //* //* RE-JOIN 64 BIT CHUNKS TO CREATE THE TERSED FILE //* //JOIN EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSINDD * GENERATE MAXFLDS=1 RECORDFIELD=(64,3) //SYSUT2 DD DISP=(,PASS),DSN=JOIN, //UNIT=SYSDA,SPACE=(CYL,(50,10),RLSE), //DCB=(RECFM=FB,LRECL=64,BLKSIZE=10240) //SYSUT1 DD DATA,DLM=XX ZZ //DD DSN=SPLIT,DISP=OLD //DD DATA,DLM=YY XX //* //* UN- TERSE FILE. //* OVERRIDE LRECL TO 1024 //* //UNTERSE EXEC PGM=TRSMAIN,PARM='UNPACK' //SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA) //INFILEDD DISP=OLD,DSN=JOIN,LRECL=1024 //OUTFILE DD DISP=(,PASS),DSN=DSSIODF, // UNIT=SYSDA,SPACE=(CYL,(50,50),RLSE) //* //* RESTORE DSSDUMP //* //DSSREST EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //DUMP DD DSN=DSSIODF,DISP=OLD //IODF DD UNIT=3390,VOL=SER=IODF00,DISP=SHR //SYSIN DD * RESTORE DATASET (INCLUDE (- SYSY.IODF00.CLUSTER - ))- INDD(DUMP) OUTDD(IODF) /* YY -- 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
Re: TSO TRANSMIT and instream data set DLM=
On Mon, 28 Jan 2008 20:22:34 -0600, Paul [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: BTW, is there a new format of Publibz? Suddenly, I seem to be required to display a shelf list before I can filter for a string in a publication title. This could be undesirable on a slow connection. Yes, they do seem to have implemented a new format. So far, I think I like the old method better, but we'll see. On a slow connection, perhaps you could let the list start loading then click the stop button in your browser, then do the filtering. I'll have to see whether I get used to it. (I really wish I could have searched for TRANSMIT in all publications whose titles contain TSO.) TSO/E has its own bookshelf, so if you start by listing the shelves, you can then locate an open the TSO/E shelf, and then search for TRANSMIT. -- Walt -- 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: TSO TRANSMIT and instream data set DLM=
On Tue, 29 Jan 2008 09:33:23 +, Roy Hewitt wrote: See the following as an example of how to include such data instream using standard IBM utilities. This example includes Terse output (but could easily be Transmit), that has been reformatted as 64 bytes and offset to pos 3. Thanks for suggesting the utilities. Hmmm. The largest divisor of 80 I could use is 40. This cuts the efficency to 50% from your 80% with TERSE. That's still acceptable, and I don't need TERSE which is not yet a standard IBM utility at all supported releases. I've done similar with uuencode as a test. All things considered, I'd prefer not to frighten the customer with complexity; I'll continue my trial-and-error search for a delimiter. If I use only alphabetics and numerics, there are 3844 candidate digraphs, which exceeds the number of records in my current TRANSMIT archive, so I'm guaranteed a success; and even with a larger archive the chance of failure is negligible. In fact, it has always succeeded for my data on the first trial. I tried the experiment of putting a few records of all slashes in my source PDS. I did get '//' in 1-2, so my hopeful conjecture is refuted. Thanks again, 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: TSO TRANSMIT and instream data set DLM=
Paul Gilmartin wrote: On Tue, 29 Jan 2008 09:33:23 +, Roy Hewitt wrote: See the following as an example of how to include such data instream using standard IBM utilities. This example includes Terse output (but could easily be Transmit), that has been reformatted as 64 bytes and offset to pos 3. Thanks for suggesting the utilities. Hmmm. The largest divisor of 80 I could use is 40. This cuts the efficency to 50% from your 80% with TERSE. That's still acceptable, and I don't need TERSE which is not yet a standard IBM utility at all supported releases. Just to clarify, 64 has to be a factor of the blocksize, not the record length, so with FB 80, blksize=8000, you could still split up to 64 byte chunks I've done similar with uuencode as a test. All things considered, I'd prefer not to frighten the customer with complexity; I can understand that Roy -- 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: TSO TRANSMIT and instream data set DLM=
Paul Gilmartin wrote: snip Hmmm. The largest divisor of 80 I could use is 40. This cuts the efficency to 50% from your 80% with TERSE. That's still acceptable, and I don't need TERSE which is not yet a standard IBM utility at all supported releases. snip See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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
Re: TSO TRANSMIT and instream data set DLM=
On Tue, 29 Jan 2008 19:29:47 +, Roy Hewitt wrote: Hmmm. The largest divisor of 80 I could use is 40. This cuts the efficency to 50% from your 80% with TERSE. That's still acceptable, and I don't need TERSE which is not yet a standard IBM utility at all supported releases. Just to clarify, 64 has to be a factor of the blocksize, not the record length, so with FB 80, blksize=8000, you could still split up to 64 byte chunks What happens if the last block contains 7920 characters, which is not a multiple of 64? If the dangling partial record were not a problem, one could use BLKSIZE=6320 (i.e. 79*80), indent only one column, and use 79 characters per line. -- 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: TSO TRANSMIT and instream data set DLM=
On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote: See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS R7 and up. That's all supported releases since R6 is out of service and AMATERSE is included in z/OS R9. The PTFs closed 4 November 2007. They are: UA36927 - z/OS R7 UA36928 - z/OS R8 Thanks. Experimenting on R9. Hmmm. I see DD names are now SYSUT1 and SYSUT2 instead of INFILE and OUTFILE. I guess Standards is Good. Does it now respect alternate DD name lists? But, YA case of anti-Unix-System-Services bigotry: If I code: //* = //TESTCEXEC PGM=AMATERSE,PARM=UNPACK //* STEPLIB DD DISP=SHR,DSN=STEPLIB //SYSPRINT DD SYSOUT=(,) //SYSUT1DD UNIT=SYSALLDA,SPACE=(CYL,0), // RECFM=FB,LRECL=1024,BLKSIZE=20480 // DD PATHOPTS=ORDONLY,FILEDATA=BINARY, // RECFM=FB,LRECL=1024,BLKSIZE=20480, // PATH='/u/user/pmr70484.tersed' //SYSUT2DD DISP=(,PASS),UNIT=SYSDA,SPACE=(CYL,(10,10,DIR)) //* //* = ... it runs fine with: * TOP OF DATA ** ** AMA572I STARTING TERSE DECODE UNPACK 18:16:21 01/29/2008 ** AMA527I INPUT - DDNAME : SYSUT1 DSNAME: SYS08029.T181620.RA000.TERSEHFS.R ** AMA528I OUTPUT - DDNAME : SYSUT2 DSNAME: SYS08029.T181620.RA000.TERSEHFS.R ** AMA555I THE VALUES ARE: BLKSIZE= 4160LRECL=4160PACKTYPE=SPACK REC ** AMA573I TERSE COMPLETE DECODE UNPACK 18:16:38 01/29/2008 ** AMA504I RETURN CODE: 0 BOTTOM OF DATA ... but if I omit the empty CKD data set: //* = //TESTDEXEC PGM=AMATERSE,PARM=UNPACK //* STEPLIB DD DISP=SHR,DSN=STEPLIB //SYSPRINT DD SYSOUT=(,) //SYSUT1DD PATHOPTS=ORDONLY,FILEDATA=BINARY, // RECFM=FB,LRECL=1024,BLKSIZE=20480, // PATH='/u/user/pmr70484.tersed' //SYSUT2DD DISP=(,PASS),UNIT=SYSDA,SPACE=(CYL,(10,10,DIR)) //* //* = ... it fails dreadfully with: * TOP OF DATA ** ** AMA572I STARTING TERSE DECODE UNPACK 18:16:38 01/29/2008 ** AMA527I INPUT - DDNAME : SYSUT1 DSNAME: ...PATH=.SPECIFIED... ** AMA557E FOR INPUT - ONLY SEQUENTIAL DATA SETS ARE SUPPORTED AT THIS TIME ** AMA564E THIS IS NOT A RECOGNIZABLE TERSED DATA SET ** AMA573I TERSE COMPLETE DECODE UNPACK 18:16:38 01/29/2008 ** AMA504I RETURN CODE: 12 BOTTOM OF DATA ... Hmmm. AT THIS TIME. Does this mean there's hope for the near future? Why do they do this? Are they insufficiently motivated to test with all device types, and too ethical to deny supporting something they haven't tested? (People speak of a time when TRSMAIN (not AMATERSE) was documented as not supporting tape data sets, although the same people found it appeared to work.) In any case, uniform behavior over the range of device types ought to be the responsibility of the access method, not of the utility employing it. -- 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: TSO TRANSMIT and instream data set DLM=
Paul Gilmartin wrote: On Tue, 29 Jan 2008 19:29:47 +, Roy Hewitt wrote: Hmmm. The largest divisor of 80 I could use is 40. This cuts the efficency to 50% from your 80% with TERSE. That's still acceptable, and I don't need TERSE which is not yet a standard IBM utility at all supported releases. Just to clarify, 64 has to be a factor of the blocksize, not the record length, so with FB 80, blksize=8000, you could still split up to 64 byte chunks What happens if the last block contains 7920 characters, which is not a multiple of 64? True..I hadn't really thought it through for FB 80. My usage has always been with lrecl(mod64) Cheers Roy -- 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
TSO TRANSMIT and instream data set DLM=
One of my disappointments with TSO TRANSMIT is that I know no safe way to imbed INMR text in an instream data set: the format seems to allow any digraph to appear in columns 1-2. But today, attempting to test a trial-and-error routine to scan a TRANSMITted IEBCOPY unloaded JCL library for a digraph not appearing in columns 1-2, I was startled to find no '//' (but many '/*') in those columns. I consider this a statistical anomaly -- I found numerous '//' in 2-3 and wrapped from 80-1. Have the authors done us a favor by coding to avoid '//' in 1-2? I can find no mention of this in the documentation. I'd be delighted to exploit the feature if I were confident it was supported. BTW, is there a new format of Publibz? Suddenly, I seem to be required to display a shelf list before I can filter for a string in a publication title. This could be undesirable on a slow connection. I'll have to see whether I get used to it. (I really wish I could have searched for TRANSMIT in all publications whose titles contain TSO.) -- 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
