Re: Running REXX program in a batch job
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL > > >"Everything is prohibited even if it's compulsory." > > Canada has a set of laws that are a catch-22. > If you follow one, you break the other. > > 1. You must prove to the Federal Government that you are an > equal opportunity employer, by having suitable numbers of > minorities, handicapped, women, etc. represented in positions > of authority. No doubt "suitable" is not clearly defined anywhere. > 2. You are NOT allowed to collect statsistics on employees > regarding race, colour, disability or gender. You've been taking (wrong) lessons from "Uncle Sam" again.. Here, collecting such statistical information is "voluntary".. But "volunteering" is mandatory! -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
Ed Gould wrote: On Nov 17, 2007, at 11:05 PM, Joel C. Ewing wrote: We don't turn REXX or batch TMP loose as a general tool for Applications development to write code for production batch, but batch REXX, including batch REXX that runs in batch TSO or batch ISPF environments, has been frequently used by Technical Services to quickly implement a number of simple utilities needed by Applications Development. These utilities are documented and made available to application programming for use in production batch, and if they break, Tech Services does the debugging. We have not found any significant problems in using batch TMP in this way, as properly disciplined REXX code can be restartable, can check for internal failures and reflect failures back to the step completion code if necessary, and issues with a job scheduler or job restart software can be avoided. In many cases these utilities that run under TMP may actually do a better job of providing meaningful diagnostic messages than if implemented in some other way - it seems to take much less effort to provide meaningful text diagnostic messages in REXX, so it's more likely they will be implemented. Before programmers started using the DB2 Call Attach Facility (CAF) to handle the connect to the appropriate DB2 subsystem, the only way to execute a program using DB2 in batch was to run it under the TSO DSN Command processor under TMP in batch TSO. As long as the application program was implemented in a high level language with a runtime environment that provides reasonable debugging information, the fact that the runtime environment is under TMP really did not have any significant impact on difficulty of problem resolution. One thing which may make this practical in our environment which I gather may not be true in yours - our production support people are the same people who do application development. We find receiving 0300 problem calls provides strong incentive to Applications Development (and to Technical Services) to design things for reasonable diagnostics and restartability, and to promptly resolve any deficiencies in those areas. Joel, Interesting. I guess that works in your environment. In the environments I have worked in there is too much political stuff going on and the finger pointing gets rather well pointed. (sorry about the pun). I have always worked in environments that the production control is separate and distinct from support. No programmers (unless they got paid for OT) wants to be called at to handle space abends and the like so production support is always there to handle mundane issues. As a side issue most of the time that I have seen the day to day issues are really better handled by production control people. There are some exceptions of course but most of the time the documentation turned over at turnover time is really gone through with a fine tooth comb and acceptance only occurs when the people who will be handling the jobstream are comfortable with it. That is NOT to say they are right 100 percent of the time but pretty close and the few percent they aren't is because of either a rare fluke or the doc was in error (most likely cause). Point taken on the DB2 issue (or other DB issues) there probably isn't a schedular package in the world that can handle those. Also, I have never worked in an environment where (except for extremely minor programs) TS has written essentially application code. The one exception I can think of was 30+ years ago where there was a database and a program was written so that the applications people could call the code for read/write access to the database. There was (I think) never any issue of issues because it was extremely simple interface and handled errors quite well. In the several years I was there I don't recall a error ever happening in that code. I wrote a few utility type programs but those were more of conversion type programs where applications types never saw the code. The operators were in a sense my end users for those programs. I have written exits and such where the application types doesn't invoke them per se but is on the receiving end of their submissions. So I supported them but in a semi passive way. AFAIK none of my code has ever broken. The exits may have had to be recompiled or changed because IBM does change parameter lists or macros change or JES changes. None of the places I have ever worked do not allow products to be put in a production jobstream unless there is 24x7 support from the vendor PERIOD and only then under a really stringent set of "ifs". I have worked on both sides of the Atlantic and programmers in the states are somewhat more accepting of midnight calls (exceptions exist), so it may well be the area you are from that make exceptions to the normals. Ed ... Ed, I gather from remarks I have heard at SHARE and elsewhere that our data processing environment may b
Re: Running REXX program in a batch job
The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well. [EMAIL PROTECTED] (Paul Gilmartin) writes: > I believe Cowlishaw's book reports that Rexx was developed in the VM > and MVS environments concurrently. It flourished in the former and > withered in the latter, less likely because CLIST fulfilled the need > better than EXEC2 than because less enthusiasm for innovation exists > in the MVS environment (case in point: TCP/IP). Rexx didn't resurface > under MVS until TSO/E. well, not quite: posting of old reference/quote http://www.garlic.com/~lynn/2005j.html#41 TSO replacement from Melinda's vm history paper http://www.princeton.edu/~melinda/25paper.pdf one of the quotes: Mike Cowlishaw had made the decision to write a new CMS executor on March 20, 1979. two months later, he began circulating the first implementation of the new language, which was then called ``REX''. Once Mike made REX available over VNET, users spontaneously formed the REX Language Committee, which Mike consulted before making further enhancements to the language. He was deluged with feedback from REX users, to the extent of about 350 mail files a day. By consulting with the Committee to decide which of the suggestions should be implemented, he rather quickly created a monumentally successful piece of software. ... snip ... similar comments are mentioned in rexx wiki page http://en.wikipedia.org/wiki/REXX and another old quote from this post http://www.garlic.com/~lynn/2006p.html#31 25th Anniversary of the Personal Computer" from one of the references in the above: By far the most important influence on the development of Rexx was the availability of the IBM electronic network, called VNET. In 1979, more than three hundred of IBM's mainframe computers, mostly running the Virtual Machine/370 (VM) operating system, were linked by VNET. This store-and-forward network allowed very rapid exchange of messages (chat) and e-mail, and reliable distribution of software. It made it possible to design, develop, and distribute Rexx and its first implementation from one country (the UK) even though most of its users were five to eight time zones distant, in the USA. ... snip ... and for other topic drift, this was part of the thread related to the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet having been larger than the arpanet/internet from just about the beginning until sometime mid-85. part of the internal network issues was that while there were mvs/jes2 nodes, nearly all the nodes were vm ... and the jes2 nodes had to be carefully regulated. there were several issues around why jes2 nodes had to be carefully regulated on the internal network (some independent of the fact that the number of vm systems were significantly larger than the number of mvs systems) 1) jes2 networking started out being some HASP mods from TUCC that defined network nodes using the HASP psuedo device table ... limited to 255 entries ... 60-80 entries nominally taken up by psuedo spool devices ... leaving possibly only 170 entries for network node definitions 2) jes2 implementation would discard traffic if it didn't have either the origin or destination node in local defintion. the internal network had more nodes than jes2 could define for the majority of its lifetime ... so jes2 needed to be restricted to boundary nodes (at least not discarding traffic just passing thru). 3) jes2 implementation had a number of other deficiencies, including having confused header information as to network specific and local process handling. different versions or releases with minor variation in headers would bring down whole mvs system. even restricted to purely boundary nodes, there is infamous story of jes2 upgrade in san jose resulted in mvs system crashes in hursley. as a consequence there was special vm drivers created for talking to mvs jes2 systems ... which would convert jes2 headers to compatible format for the specific system on the other end of the line. this was somewhat the side-effect of the vm implementation having separated networking control information from other types of information ... effectively providing a kind of gateway implementation ... something not possible in the JES2 networking infrastructure (including not having a way from protecting itself from other JES2 systems, requiring intermediary vm systems to keep the JES2 systems from crashing each other). misc. past posts mentioning hasp, jes2, and/or jes2 networking http://www.garlic.com/~lynn/subtopic.html#hasp at some point ... while VM could run native protocol drivers as well as (multiple different) JES2 drivers ... JES2 could only run a specific JES2 drivers ... it was decided to start shipping VM only with JES2 drivers (even tho the native VM protocol drivers were more efficient). this was seen in the bitnet deployment http://www.garlic.com/~lynn/subnetwork.html#bitnet the vm tcp/ip product was deve
Re: Running REXX program in a batch job
On Sun, 18 Nov 2007 22:51:36 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>Rexx didn't resurface under MVS until TSO/E. > >Later than that. >TSO/E came out with MVS/XA. >REXX came (back?) with MVS/ESA 3.1.0e (circa 1989). >I remember that for two reasons: >1. I was reading Colishaw's REXX book while my ex was getting prepped for a Caesarean for my first son. >2. I had just started at a new company and had a manager complain about the overhead of REXX under TSO, and I had to 'prove' it was cost-effective. > > I first used REXX under MVS/XA 2.2.0. It was optional though. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
On Nov 18, 2007, at 4:51 PM, Ted MacNEIL wrote: Rexx didn't resurface under MVS until TSO/E. Later than that. TSO/E came out with MVS/XA. REXX came (back?) with MVS/ESA 3.1.0e (circa 1989). I remember that for two reasons: 1. I was reading Colishaw's REXX book while my ex was getting prepped for a Caesarean for my first son. 2. I had just started at a new company and had a manager complain about the overhead of REXX under TSO, and I had to 'prove' it was cost-effective. IIRC, REXX under VM was available around 1978. Tedd: My memory thought in was in 1991(for XA) (early if I remember correctly) I remember having to sit on it for a 2 month wait as a pre req PTF was PE and it took that long to get the fix. We weren't the first on the block but close. My memory of that time is a bit cloudy but it could have become available as much as an year earlier. I do remember distinctly looking on IBMLINK daily for closure of a key PE PTF. Even then it was difficult to get the application people interested in it they couldn't even get interested in clists though. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
>Rexx didn't resurface under MVS until TSO/E. Later than that. TSO/E came out with MVS/XA. REXX came (back?) with MVS/ESA 3.1.0e (circa 1989). I remember that for two reasons: 1. I was reading Colishaw's REXX book while my ex was getting prepped for a Caesarean for my first son. 2. I had just started at a new company and had a manager complain about the overhead of REXX under TSO, and I had to 'prove' it was cost-effective. IIRC, REXX under VM was available around 1978. - Too busy driving to stop for gas! -- 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: Running REXX program in a batch job
Conmackie, Mike wrote: Perhaps I missed the sarcasm but IIRC REXX was born in the VM environment as an improvement over EXEC2. Believe me. Pat knew that. That's why he included the "smiley". -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
And of course there are REXX interpreters that run in non-MVS environments with their own "or ...". (Take a look at Regina, for instance.) I've heard that even VM has REXX. :-) Perhaps I missed the sarcasm but IIRC REXX was born in the VM environment as an improvement over EXEC2. Mike Conmackie Compuware Corp. Detroit, MI The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. -- 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: Running REXX program in a batch job
On Sat, 17 Nov 2007 12:29:47 -0600, Mark Zelden <[EMAIL PROTECTED]> wrote: >>I'm just curious, what sorts of things can a Rexx program can do that >>doesn't interact with TSO or ISPF (or...)? >>... The key is in that "(or...)". It may not have TSO or ISPF, but it has some "or" that provides a functioning environment. >... >The same sort of things you can do in other programming languages >without TSO / ISPF - even SAS :-).Read a file, process it, write a file, >look at storage / control blocks, etc. > >Many of the utilities on my web site run fine with IRXJCL. >... IRXJCL provides an "or ..." environment where the REXX interpreter can execute. And beyond IRXJCL, the programmatic invocation of REXX via IRXINIT allows the invoking environment to provide the storage management, I/O, etc. routines that the REXX interpreter will use so that REXX can be smoothly integrated into that invoking environment. I assume that is what SAS does. I *know* that is what NetView does. NetView initialization requires REXX; the primary initialization routines are written in REXX. The TSO REXX Reference manual goes into great detail describing how to run REXX on MVS in a non-TSO environment. And of course there are REXX interpreters that run in non-MVS environments with their own "or ...". (Take a look at Regina, for instance.) I've heard that even VM has REXX. :-) Pat O'Keefe -- 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: Running REXX program in a batch job
>"Everything is prohibited even if it's compulsory." Canada has a set of laws that are a catch-22. If you follow one, you break the other. 1. You must prove to the Federal Government that you are an equal opportunity employer, by having suitable numbers of minorities, handicapped, women, etc. represented in positions of authority. 2. You are NOT allowed to collect statsistics on employees regarding race, colour, disability or gender. Dilbert lives! - Too busy driving to stop for gas! -- 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: Running REXX program in a batch job
On Sat, 17 Nov 2007 11:07:02 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >... "Everything is prohibited unless it's compulsory." >... Unless you work for a bank. Then it's : "Everything is prohibited even if it's compulsory." Pat O'Keefe -- 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: Running REXX program in a batch job
Ed Gould wrote: Interesting. I guess that works in your environment. In the environments I have worked in there is too much political stuff going on and the finger pointing gets rather well pointed. (sorry about the pun). They were probably holding their "pointing" fingers and thumb in the shape of a handgun; waiting for someone to make the slightest mistake. Bang!! You're fired!! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
On Nov 17, 2007, at 11:05 PM, Joel C. Ewing wrote: We don't turn REXX or batch TMP loose as a general tool for Applications development to write code for production batch, but batch REXX, including batch REXX that runs in batch TSO or batch ISPF environments, has been frequently used by Technical Services to quickly implement a number of simple utilities needed by Applications Development. These utilities are documented and made available to application programming for use in production batch, and if they break, Tech Services does the debugging. We have not found any significant problems in using batch TMP in this way, as properly disciplined REXX code can be restartable, can check for internal failures and reflect failures back to the step completion code if necessary, and issues with a job scheduler or job restart software can be avoided. In many cases these utilities that run under TMP may actually do a better job of providing meaningful diagnostic messages than if implemented in some other way - it seems to take much less effort to provide meaningful text diagnostic messages in REXX, so it's more likely they will be implemented. Before programmers started using the DB2 Call Attach Facility (CAF) to handle the connect to the appropriate DB2 subsystem, the only way to execute a program using DB2 in batch was to run it under the TSO DSN Command processor under TMP in batch TSO. As long as the application program was implemented in a high level language with a runtime environment that provides reasonable debugging information, the fact that the runtime environment is under TMP really did not have any significant impact on difficulty of problem resolution. One thing which may make this practical in our environment which I gather may not be true in yours - our production support people are the same people who do application development. We find receiving 0300 problem calls provides strong incentive to Applications Development (and to Technical Services) to design things for reasonable diagnostics and restartability, and to promptly resolve any deficiencies in those areas. Joel, Interesting. I guess that works in your environment. In the environments I have worked in there is too much political stuff going on and the finger pointing gets rather well pointed. (sorry about the pun). I have always worked in environments that the production control is separate and distinct from support. No programmers (unless they got paid for OT) wants to be called at to handle space abends and the like so production support is always there to handle mundane issues. As a side issue most of the time that I have seen the day to day issues are really better handled by production control people. There are some exceptions of course but most of the time the documentation turned over at turnover time is really gone through with a fine tooth comb and acceptance only occurs when the people who will be handling the jobstream are comfortable with it. That is NOT to say they are right 100 percent of the time but pretty close and the few percent they aren't is because of either a rare fluke or the doc was in error (most likely cause). Point taken on the DB2 issue (or other DB issues) there probably isn't a schedular package in the world that can handle those. Also, I have never worked in an environment where (except for extremely minor programs) TS has written essentially application code. The one exception I can think of was 30+ years ago where there was a database and a program was written so that the applications people could call the code for read/write access to the database. There was (I think) never any issue of issues because it was extremely simple interface and handled errors quite well. In the several years I was there I don't recall a error ever happening in that code. I wrote a few utility type programs but those were more of conversion type programs where applications types never saw the code. The operators were in a sense my end users for those programs. I have written exits and such where the application types doesn't invoke them per se but is on the receiving end of their submissions. So I supported them but in a semi passive way. AFAIK none of my code has ever broken. The exits may have had to be recompiled or changed because IBM does change parameter lists or macros change or JES changes. None of the places I have ever worked do not allow products to be put in a production jobstream unless there is 24x7 support from the vendor PERIOD and only then under a really stringent set of "ifs". I have worked on both sides of the Atlantic and programmers in the states are somewhat more accepting of midnight calls (exceptions exist), so it may well be the area you are from that make exceptions to the normals. Ed --
Re: Running REXX program in a batch job
We don't turn REXX or batch TMP loose as a general tool for Applications development to write code for production batch, but batch REXX, including batch REXX that runs in batch TSO or batch ISPF environments, has been frequently used by Technical Services to quickly implement a number of simple utilities needed by Applications Development. These utilities are documented and made available to application programming for use in production batch, and if they break, Tech Services does the debugging. We have not found any significant problems in using batch TMP in this way, as properly disciplined REXX code can be restartable, can check for internal failures and reflect failures back to the step completion code if necessary, and issues with a job scheduler or job restart software can be avoided. In many cases these utilities that run under TMP may actually do a better job of providing meaningful diagnostic messages than if implemented in some other way - it seems to take much less effort to provide meaningful text diagnostic messages in REXX, so it's more likely they will be implemented. Before programmers started using the DB2 Call Attach Facility (CAF) to handle the connect to the appropriate DB2 subsystem, the only way to execute a program using DB2 in batch was to run it under the TSO DSN Command processor under TMP in batch TSO. As long as the application program was implemented in a high level language with a runtime environment that provides reasonable debugging information, the fact that the runtime environment is under TMP really did not have any significant impact on difficulty of problem resolution. One thing which may make this practical in our environment which I gather may not be true in yours - our production support people are the same people who do application development. We find receiving 0300 problem calls provides strong incentive to Applications Development (and to Technical Services) to design things for reasonable diagnostics and restartability, and to promptly resolve any deficiencies in those areas. Ed Gould wrote: On Nov 17, 2007, at 12:15 AM, Joel C. Ewing wrote: I've always assumed there was slightly less overhead in running batch REXX without the TSO TMP, provided you didn't need any TSO commands or ISPF services - but I suspect this overhead is minimal. I believe you also avoid the need for several DDs, which in a bizarre case might make a difference. We regularly run batch TSO (batch TMP), batch REXX, and batch ISPF from production batch jobs, which all run under userids with no TSO access (No TSO Segment and not in SYSUADS). I can't conceive of any rational reason why a sysadmin or auditor would want to restrict batch TMP usage. It buys you no power or data access that could not be derived by other means, except perhaps for the somewhat dubious ability to execute CLISTs - but everything a CLIST can do can be better done by REXX. Joel: Interesting idea about not restricting TMP usage in batch. One reason (amongst others) is that debugging is hard (if not impossible) to do after an issue. Of course its one thing in a testing environment but in a production environment? I just can't see production support people supporting such an environment. Their job is difficult enough with JCL and typical abends but to throw in TMP (non abends usually) issue is just an environment that most support people would run away from and refuse to have any responsibility over. While it might be possible, I have seen most support people say "NO" to TMP issues (bugs whatever). Trying to get a scheduling package to handle issues in that environment would probably be almost impossible. Ed ... -- Joel C. Ewing, Fort Smith, AR[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: Running REXX program in a batch job
But the whole point it seems to me is that with batch TSO we are talking about what can be done by someone who already has the ability to submit a batch job. If you have batch job capability you don't have to execute batch TMP to be able to allocate datasets, as that can already be done via JCL DD statements or internally in various utilities. One can directly invoke utilities as a job step to examine dataset attributes, list members or contents of members of PDSs, invoke APF authorized programs, or invoke IDCAMS functions, etc., etc. You can even simulate dynamic dataset allocation by using a program implemented in REXX or some other language to dynamically generate and submit another job to an Internal Reader. I would contend that batch TMP (and batch ISPF) doesn't really give the batch user any fundamental power to do good or ill that is not already there in other forms in the batch environment, it just adds some convenient, and in some cases more efficient, additional ways to do things. Paul Gilmartin wrote: On Sat, 17 Nov 2007 00:15:03 -0600, Joel C. Ewing wrote: I can't conceive of any rational reason why a sysadmin or auditor would want to restrict batch TMP usage. It buys you no power or data access that could not be derived by other means, except perhaps for the somewhat dubious ability to execute CLISTs - but everything a CLIST can do can be better done by REXX. Under TMP, but not otherwise in Rexx, you get: o ALLOCATE (yes, BPXWDYN is a near equivalent, but lacks some keywords.) o ISPF o LISTDSI (other TSO functions?) o IDCAMS commands (RENAME, ...) o CALL APF authorized programs. But I'm being devil's advocate. Restricting users' access to TMP is as irrational as restricting their access to Unix System Services. But some auditors feel such an irrational desire to exclude access to any facility a user doesn't need to perform his job. The Totalitarian view: "Everything is prohibited unless it's compulsory." -- gil -- Joel C. Ewing, Fort Smith, AR[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: Running REXX program in a batch job
On Nov 17, 2007, at 12:15 AM, Joel C. Ewing wrote: I've always assumed there was slightly less overhead in running batch REXX without the TSO TMP, provided you didn't need any TSO commands or ISPF services - but I suspect this overhead is minimal. I believe you also avoid the need for several DDs, which in a bizarre case might make a difference. We regularly run batch TSO (batch TMP), batch REXX, and batch ISPF from production batch jobs, which all run under userids with no TSO access (No TSO Segment and not in SYSUADS). I can't conceive of any rational reason why a sysadmin or auditor would want to restrict batch TMP usage. It buys you no power or data access that could not be derived by other means, except perhaps for the somewhat dubious ability to execute CLISTs - but everything a CLIST can do can be better done by REXX. Joel: Interesting idea about not restricting TMP usage in batch. One reason (amongst others) is that debugging is hard (if not impossible) to do after an issue. Of course its one thing in a testing environment but in a production environment? I just can't see production support people supporting such an environment. Their job is difficult enough with JCL and typical abends but to throw in TMP (non abends usually) issue is just an environment that most support people would run away from and refuse to have any responsibility over. While it might be possible, I have seen most support people say "NO" to TMP issues (bugs whatever). Trying to get a scheduling package to handle issues in that environment would probably be almost impossible. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
Ok fair enough. (-: I misunderstood then. I made the assumption that no TSO commands included EXECIO and that no TSO segment included also no OMVS segment. --- (You can call Rexx programs from SAS very easily by the way. For example I made a simple hack to IGGCSIRX where you can wildcard search the catalog and put the datasets into a SAS dataset.) > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Mark Zelden > Sent: 17. marraskuuta 2007 20:30 > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Running REXX program in a batch job > > On Sat, 17 Nov 2007 19:05:50 +0100, Lindy Mayfield > <[EMAIL PROTECTED]> wrote: > > >I'm just curious, what sorts of things can a Rexx program can do that > >doesn't interact with TSO or ISPF (or...)? > > > >I tried, but I couldn't think of much, so I must have something wrong. > > > >Lindy > > > > The same sort of things you can do in other programming languages > without TSO / ISPF - even SAS :-).Read a file, process it, write a > file, > look at storage / control blocks, etc. > > Many of the utilities on my web site run fine with IRXJCL. > > Mark -- 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: Running REXX program in a batch job
On Sat, 17 Nov 2007 19:05:50 +0100, Lindy Mayfield wrote: >I'm just curious, what sorts of things can a Rexx program can do that >doesn't interact with TSO or ISPF (or...)? > >I tried, but I couldn't think of much, so I must have something wrong. > See: Title: z/OS V1R7.0 Using REXX and z/OS UNIX System Services Document Number: SA22-7806-09 URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB661/CCONTENTS -- 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: Running REXX program in a batch job
On Sat, 17 Nov 2007 19:05:50 +0100, Lindy Mayfield <[EMAIL PROTECTED]> wrote: >I'm just curious, what sorts of things can a Rexx program can do that >doesn't interact with TSO or ISPF (or...)? > >I tried, but I couldn't think of much, so I must have something wrong. > >Lindy > The same sort of things you can do in other programming languages without TSO / ISPF - even SAS :-).Read a file, process it, write a file, look at storage / control blocks, etc. Many of the utilities on my web site run fine with IRXJCL. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
I'm just curious, what sorts of things can a Rexx program can do that doesn't interact with TSO or ISPF (or...)? I tried, but I couldn't think of much, so I must have something wrong. Lindy > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Joel C. Ewing > Sent: 17. marraskuuta 2007 8:15 > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Running REXX program in a batch job > > I've always assumed there was slightly less overhead in running batch > REXX without the TSO TMP, provided you didn't need any TSO commands or > ISPF services - but I suspect this overhead is minimal. I believe you > also avoid the need for several DDs, which in a bizarre case might make > a difference. > > We regularly run batch TSO (batch TMP), batch REXX, and batch ISPF from > production batch jobs, which all run under userids with no TSO access > (No TSO Segment and not in SYSUADS). > -- 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: Running REXX program in a batch job
On Sat, 17 Nov 2007 00:15:03 -0600, Joel C. Ewing wrote: > >I can't conceive of any rational reason why a sysadmin or auditor would >want to restrict batch TMP usage. It buys you no power or data access >that could not be derived by other means, except perhaps for the >somewhat dubious ability to execute CLISTs - but everything a CLIST can >do can be better done by REXX. > Under TMP, but not otherwise in Rexx, you get: o ALLOCATE (yes, BPXWDYN is a near equivalent, but lacks some keywords.) o ISPF o LISTDSI (other TSO functions?) o IDCAMS commands (RENAME, ...) o CALL APF authorized programs. But I'm being devil's advocate. Restricting users' access to TMP is as irrational as restricting their access to Unix System Services. But some auditors feel such an irrational desire to exclude access to any facility a user doesn't need to perform his job. The Totalitarian view: "Everything is prohibited unless it's compulsory." -- 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: Running REXX program in a batch job
I've always assumed there was slightly less overhead in running batch REXX without the TSO TMP, provided you didn't need any TSO commands or ISPF services - but I suspect this overhead is minimal. I believe you also avoid the need for several DDs, which in a bizarre case might make a difference. We regularly run batch TSO (batch TMP), batch REXX, and batch ISPF from production batch jobs, which all run under userids with no TSO access (No TSO Segment and not in SYSUADS). I can't conceive of any rational reason why a sysadmin or auditor would want to restrict batch TMP usage. It buys you no power or data access that could not be derived by other means, except perhaps for the somewhat dubious ability to execute CLISTs - but everything a CLIST can do can be better done by REXX. The reasons for restricting interactive TSO usage have traditionally been because of the greater system overhead of running tasks in an interactive environment, and perhaps because of the fear that the relative ease of interactive searching and browsing would potentially make it easier for someone logged on to TSO to stumble across and misuse sensitive data if someone had failed to adequately protect it. Use of TMP non-interactively in batch has not raised these issues. Paul Gilmartin wrote: On Mon, 12 Nov 2007 10:00:05 -0500, Farley, Peter x23353 wrote: Try IRXJCL on for size, see if it fits your needs (watch the line wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/12.2.1?SHELF=IKJ4BK70.bks&DT=20060626210253&CASE= Wrap fixed, I believe. Get a better mailer. Often, when faced with this problem, I trim the QUERY_STRING: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/12.2.1 What's the advantage in IRXJCL? I know that when coding an EXEC for greatest portability, I test it under all of: o TSO TMP o Unix shell o IRXJCL. ... but I don't know who benefits from the last. I suppose it somewhat verifies compatibility with the API. I see Walt F. answered in anticipation my question of availability of TSO TMP when user has no TSO segment. But why is this permitted? Frequently, sysadmins ask on this list how to preclude a user's access to Unix System Services. Simple answer: give the user no OMVS segment, and define no default OMVS segment. But what answer can be given the sysadmin who wants to preclude a user's access to the TSO TMP? (Ignoring the question of why any sysadmin feels compelled to limit access to either. Overzealous auditors?) -- gil ... -- Joel C. Ewing, Fort Smith, AR[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: Running REXX program in a batch job
I use IRXJCL if I'm not using ISPF services. Here is a sample of batch IRXJCL. I pass an exec name and some parameters for execution and read and write a file. Does this help? The REXX is CALLDCOM and rest are comma delimited parameters parsed out at the start. There are no TSO ALLOCATES in the REXX, the files are explicitly defined in DD statements and ir uses EXECIO. //REXXBAT EXEC PGM=IRXJCL,PARM='CALLDCOM T01,KEY01,00900,DUURT900,, // UPDAT,099,1,10,11,10,21,10,' //INPDD DD DSN=WAYNE.T015.EXTRT01,DISP=SHR //OUTDD1 DD DSN=WAYNE.DIAG,DISP=SHR, // UNIT=SYSDA,SPACE=(CYL,(1,1)),RECFM=VB //SYSEXEC DD DSN=WAYNE.REXX.SOURCE,DISP=SHR //SYSTSPRT DD SYSOUT=* //SYSABOUT DD SYSOUT=* //SYSTSIN DD DUMMY //SNAPER DD SYSOUT=* //SYSPRINT DD SYSOUT=* On 11/13/07, R.S. <[EMAIL PROTECTED]> wrote: > > Paul Gilmartin wrote: > > On Sat, 10 Nov 2007 18:48:23 -0800, Edward Jaffe wrote: > > > >>> I'm trying to port a REXX utility program from z/VM to z/OS. It will > do I/O > >>> (reading and writing regular QSAM files), but the wrinkle is that it > cannot > >>> run in the TSO batch environment (most of the jobs that will use it > aren't > >>> associated with a TSO userid). > >> Not sure why this matters. > >> > > Will the TMP even run if no TSO segment is defined for the > user? (Reasoning > > (perhaps improperly) by analogy with Unix System Services, which are not > > available unless (at least a default) OMVS segment is available for the > > user.) > > Yes, TSO in batch will run with userid without TSO segment. > BTW: The user can have segment in RACF or in SYS1.UADS. > > BTW2: OMVS segment is mandatory for USS activity, however > BPX.DEFAULT.USER can supply "default OMVS segment for everyone" who > hasn't it's own one. > > -- > Radoslaw Skorupka > Lodz, Poland > > > -- > BRE Bank SA > ul. Senatorska 18 > 00-950 Warszawa > www.brebank.pl > > Sąd Rejonowy dla m. st. Warszawy > XII Wydział Gospodarczy Krajowego Rejestru Sądowego, > nr rejestru przedsiębiorców KRS 025237 > NIP: 526-021-50-88 > Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w > całości opłacony) wynosi 118.064.140 zł. W związku z realizacją > warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z > dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu > do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w > całości opłacone. > > -- > 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 > -- Wayne V. Bickerdike
Re: Running REXX program in a batch job
Paul Gilmartin wrote: On Sat, 10 Nov 2007 18:48:23 -0800, Edward Jaffe wrote: I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O (reading and writing regular QSAM files), but the wrinkle is that it cannot run in the TSO batch environment (most of the jobs that will use it aren't associated with a TSO userid). Not sure why this matters. Will the TMP even run if no TSO segment is defined for the user? (Reasoning (perhaps improperly) by analogy with Unix System Services, which are not available unless (at least a default) OMVS segment is available for the user.) Yes, TSO in batch will run with userid without TSO segment. BTW: The user can have segment in RACF or in SYS1.UADS. BTW2: OMVS segment is mandatory for USS activity, however BPX.DEFAULT.USER can supply "default OMVS segment for everyone" who hasn't it's own one. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- 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: Running REXX program in a batch job
Paul Gilmartin wrote: Will the TMP even run if no TSO segment is defined for the user? (Reasoning (perhaps improperly) by analogy with Unix System Services, which are not available unless (at least a default) OMVS segment is available for the user.) It should. At a quick glance, all the above links sorely omit any mention of the Unix Rexx environment. That provides the ADDRESS SH subcommand environment whereas none of the others do. And Unix Rexx has its own distinct flavor of the TSO subcommand enviroment, sometimes for better; often for worse. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB670/CCONTENTS -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
On Mon, 12 Nov 2007 10:00:05 -0500, Farley, Peter x23353 wrote: > >Try IRXJCL on for size, see if it fits your needs (watch the line wrap): > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/12.2.1?SHELF=IKJ4BK70.bks&DT=20060626210253&CASE= > Wrap fixed, I believe. Get a better mailer. Often, when faced with this problem, I trim the QUERY_STRING: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/12.2.1 What's the advantage in IRXJCL? I know that when coding an EXEC for greatest portability, I test it under all of: o TSO TMP o Unix shell o IRXJCL. ... but I don't know who benefits from the last. I suppose it somewhat verifies compatibility with the API. I see Walt F. answered in anticipation my question of availability of TSO TMP when user has no TSO segment. But why is this permitted? Frequently, sysadmins ask on this list how to preclude a user's access to Unix System Services. Simple answer: give the user no OMVS segment, and define no default OMVS segment. But what answer can be given the sysadmin who wants to preclude a user's access to the TSO TMP? (Ignoring the question of why any sysadmin feels compelled to limit access to either. Overzealous auditors?) -- 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: Running REXX program in a batch job
> -Original Message- > From: Mark L. Wheeler [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 10, 2007 9:29 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Running REXX program in a batch job > > Greetings all, > > I'm trying to port a REXX utility program from z/VM to z/OS. It will do > I/O (reading and writing regular QSAM files), but the wrinkle is that it > cannot run in the TSO batch environment (most of the jobs that will use it > aren't associated with a TSO userid). > > Is this possible? If so, where would I find reference info on how to do > it? I've turned Google and the IBM Publications web site upside down > looking, with no luck. Try IRXJCL on for size, see if it fits your needs (watch the line wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/12.2.1?S HELF=IKJ4BK70.bks&DT=20060626210253&CASE= HTH 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
On Sat, 10 Nov 2007 18:48:23 -0800, Edward Jaffe wrote: >> I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O >> (reading and writing regular QSAM files), but the wrinkle is that it cannot >> run in the TSO batch environment (most of the jobs that will use it aren't >> associated with a TSO userid). > >Not sure why this matters. > Will the TMP even run if no TSO segment is defined for the user? (Reasoning (perhaps improperly) by analogy with Unix System Services, which are not available unless (at least a default) OMVS segment is available for the user.) >The TSO/E REXX environment is the most robust on the platform. There are >alternatives: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.2 > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.3 > >But, I suggest you avoid them if you can. This table explains why: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.6 > At a quick glance, all the above links sorely omit any mention of the Unix Rexx environment. That provides the ADDRESS SH subcommand environment whereas none of the others do. And Unix Rexx has its own distinct flavor of the TSO subcommand enviroment, sometimes for better; often for worse. -- 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: Running REXX program in a batch job
On Sat, 10 Nov 2007 20:29:17 -0600, Mark L. Wheeler <[EMAIL PROTECTED]> wrote: >I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O >(reading and writing regular QSAM files), but the wrinkle is that it cannot >run in the TSO batch environment (most of the jobs that will use it aren't >associated with a TSO userid). Using TSO batch does not require the job to run under an ID that can use TSO. You may get a warning message during step initialization, but just ignore the message. -- 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: Running REXX program in a batch job
I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O (reading and writing regular QSAM files), but the wrinkle is that it cannot run in the TSO batch environment (most of the jobs that will use it aren't associated with a TSO userid). Not sure why this matters. Is this possible? If so, where would I find reference info on how to do it? I've turned Google and the IBM Publications web site upside down looking, with no luck. The TSO/E REXX environment is the most robust on the platform. There are alternatives: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.3 But, I suggest you avoid them if you can. This table explains why: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ4A370/8.6 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Running REXX program in a batch job
Mark, when running REXX in batch and to disassociate your code from a TSO user-ID, as the first statement in your script use the PROFILE NOPREFIX statement. Then you can reference z/OS data sets by name, with or without a TSO prefix as the HLQ. From: IBM Mainframe Discussion List on behalf of Mark L. Wheeler Sent: Sat 11/10/2007 6:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Running REXX program in a batch job Greetings all, I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O (reading and writing regular QSAM files), but the wrinkle is that it cannot run in the TSO batch environment (most of the jobs that will use it aren't associated with a TSO userid). Is this possible? If so, where would I find reference info on how to do it? I've turned Google and the IBM Publications web site upside down looking, with no luck. Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com "Extraordinary claims require extraordinary evidence." Carl Sagan "Science is organized common sense where many a beautiful theory was killed by an ugly fact." Thomas Henry Huxley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Running REXX program in a batch job
Greetings all, I'm trying to port a REXX utility program from z/VM to z/OS. It will do I/O (reading and writing regular QSAM files), but the wrinkle is that it cannot run in the TSO batch environment (most of the jobs that will use it aren't associated with a TSO userid). Is this possible? If so, where would I find reference info on how to do it? I've turned Google and the IBM Publications web site upside down looking, with no luck. Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com “Extraordinary claims require extraordinary evidence." Carl Sagan “Science is organized common sense where many a beautiful theory was killed by an ugly fact.” Thomas Henry Huxley -- 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
