Re: checking for the existence of a file in batch REXX
On Fri, 22 May 2009 10:26:48 -0500, Paul Gilmartin
wrote:
>>
>Rube Goldberg:
>
>You might be able to use SYSCALL SPAWN (BPX1SPN?) to invoke a
>bridging EXEC you'd create in a UNIX directory which would use
>the new-fangled (z/OS 1.4) "address TSO" to invoke TXT2PDF
>with full TSO facilities.
>
>You'd likely need to re-do severall ALLOCates for SYSEXEC, etc.
>
>(I successfully use (part of) this technique to invoke authorized
>facilities from an unauthorized environment.)
>
The attached calls txt2pdf successfully.
-- 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
/* REXX */ signal on novalue;
trace Err
RC = 'SYSCALLS'('ON')
address 'SYSCALL'
'open /dev/null (O_RDONLY)'
trace C
address 'TSO'
STEPLIB = userid()'.TXT2PDF.NEW.LOAD:'
RC = environment( 'STEPLIB', STEPLIB )
'profile noprefix wtpmsg prompt'
'allocate dd(SYSEXEC) shr dsn('''userid()'.TXT2PDF.NEW.EXEC'')'
'%txt2pdf' arg(1)
XRC = RC
'logoff'
exit(XRC)
--
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: checking for the existence of a file in batch REXX
2009/5/22 Jim McAlpine > OK, we've implemented that bit of code and got to the point of executing > IKJEFTSR to issue a LISTDS command but that invocation failed with - > > IKJEFTSR FAILED - RC= -1 > REASON CODE= 68 > and the following - > > IKJ56652I You attempted to run an authorized command or program. This is > not supported under the Dynamic TSO Environment. > > which seems self explanatory. I've checked in the AUTHCMD names table and > LISTDS is in there. Two further questions - > > 1. Does LISTDS absolutely need to be in AUTHCMD. > 2. Do most sites have LISTDS in AUTHCMD. Some uses of LISTDS issue a RACHECK, which will fail with a 282-010 abend if the issuer is not APF authorized. These uses would be those that need to open the dataset, such as the MEMBERS option. It sounds as though IKJEFTSR is being patronizing about this, and rather than just invoking the command unauthorized, it refuses to even try. (Well, I know it's more complex than that, since IKJEFTSR has the ability to invoke auhtorized programs from some unauthorized environments. Probably they just didn't want to deal with the IKJTSOEV case.) However... Why do you need IKJEFTSR to run a TSO command? Maybe it's a COBOL problem, but can you not ATTACH the command directly from your program (unauthorized, of course) and let it run? LISTDS itself does not check for APF before trying, so as long as you don't need to open the dataset it should work. Another possibility would be to make a copy of LISTDS that is not marked AC(1), and then invoke that. But first test the particular LISTS options you want to see how they behave in an unauthorized environment. A quick & easy way to do that is with TSO TEST: READY test *(listds) cp IKJ57090A ENTER COMMAND FOR CP listds TEST run and see what happens. Tony H. -- 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: checking for the existence of a file in batch REXX
On Fri, 22 May 2009 15:09:02 +0100, Jim McAlpine wrote: > >run the TXT2PDF freeware rexx program from COBOL without change. >Unfortunately TXT2PDF includes a number of LISTDS commands. > Rube Goldberg: You might be able to use SYSCALL SPAWN (BPX1SPN?) to invoke a bridging EXEC you'd create in a UNIX directory which would use the new-fangled (z/OS 1.4) "address TSO" to invoke TXT2PDF with full TSO facilities. You'd likely need to re-do severall ALLOCates for SYSEXEC, etc. (I successfully use (part of) this technique to invoke authorized facilities from an unauthorized environment.) -- 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: checking for the existence of a file in batch REXX
On Fri, May 22, 2009 at 2:51 PM, Paul Gilmartin wrote: > On Fri, 22 May 2009 12:22:41 +0100, Jim McAlpine wrote: > > > If it's not it will execute nonauthorized, with likely curtailment > of function. > > >2. Do most sites have LISTDS in AUTHCMD. > > > I suspect that's the default from IBM configuration. > > Have you tried the BPXWDYN approach? > > -- 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 > Yes, BPXWDYN works fine for the original problem, thankyou. However we have now moved on and someone had the bright idea that we could use the code provided by Walter to crack another problem we had which was to be able to run the TXT2PDF freeware rexx program from COBOL without change. Unfortunately TXT2PDF includes a number of LISTDS commands. Jim McAlpine -- 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: checking for the existence of a file in batch REXX
On Friday 22 May 2009, Jim McAlpine wrote: > On Fri, May 22, 2009 at 9:18 AM, Jim McAlpine wrote: > > Walter, many thanks. We will certainly give this a try. > > > > Jim McAlpine > > OK, we've implemented that bit of code and got to the point of > executing IKJEFTSR to issue a LISTDS command but that invocation > failed with - > > IKJEFTSR FAILED - RC= -1 > REASON CODE= 68 > and the following - > > IKJ56652I You attempted to run an authorized command or program. > This is not supported under the Dynamic TSO Environment. > > which seems self explanatory. I've checked in the AUTHCMD names > table and LISTDS is in there. Two further questions - > > 1. Does LISTDS absolutely need to be in AUTHCMD. > 2. Do most sites have LISTDS in AUTHCMD. Jim -- Can you make do with using the SYSDSN command instead of LISTDS, or do you need more fine grained info about the file than just whether it exists? I don't believe that SYSDSN requires authorization (won't have a chance to double check this till sometime this afternoon, though). -- Bob -- 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: checking for the existence of a file in batch REXX
On Fri, 22 May 2009 12:22:41 +0100, Jim McAlpine wrote: > >IKJ56652I You attempted to run an authorized command or program. This is >not supported under the Dynamic TSO Environment. > >which seems self explanatory. I've checked in the AUTHCMD names table and >LISTDS is in there. Two further questions - > >1. Does LISTDS absolutely need to be in AUTHCMD. If it's not it will execute nonauthorized, with likely curtailment of function. >2. Do most sites have LISTDS in AUTHCMD. > I suspect that's the default from IBM configuration. Have you tried the BPXWDYN approach? -- 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: checking for the existence of a file in batch REXX
On Fri, May 22, 2009 at 9:18 AM, Jim McAlpine wrote: > Walter, many thanks. We will certainly give this a try. > > Jim McAlpine > > > OK, we've implemented that bit of code and got to the point of executing IKJEFTSR to issue a LISTDS command but that invocation failed with - IKJEFTSR FAILED - RC= -1 REASON CODE= 68 and the following - IKJ56652I You attempted to run an authorized command or program. This is not supported under the Dynamic TSO Environment. which seems self explanatory. I've checked in the AUTHCMD names table and LISTDS is in there. Two further questions - 1. Does LISTDS absolutely need to be in AUTHCMD. 2. Do most sites have LISTDS in AUTHCMD. Jim McAlpine -- 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: checking for the existence of a file in batch REXX
Walter, many thanks. We will certainly give this a try. Jim McAlpine On Thu, May 21, 2009 at 6:47 PM, Bass, Walter W wrote: > Jim McAlpine wrote: > > > > > Thanks for all the replies and suggestions. Having spoken again to > > the developer who originally asked the question, it seems it is a tad > > > more complicated in that he actually wants to do i/o against the file > > from the REXX program. The question now becomes, can we call TSO from > > > a COBOL program without being authorised. And to answer Walts > > suggestion, no we can't have the COBOL program invoked from IKJEFT01 > > as that part of the architecture is carved in stone. > > > > You can call TSO from COBOL without being authorized, you just can't use > any authorized services. I do it in a program on the CBT called > SYMBSUB (file 779). Basically you just call IKJTSOEV to create the > TSO environment, then call IKJEFTSR to issue TSO commands. > > Here is a code snippet to give you a head start if you wish to pursue > this further. This should not necessarily be considered an endorsement > of using this approach. It's a pretty big gun to use if your target > happens to be small. > > > 01 WS-IKJEFT-PARMS. > 05 WS-IKJEFT-DUMMY PIC S9(8) COMP-5. > 05 WS-IKJEFT-RC PIC S9(8) COMP-5. > 05 WS-IKJEFT-REASON-CD PIC S9(8) COMP-5. > 05 WS-IKJEFT-INFO-CDPIC S9(8) COMP-5. > 05 WS-IKJEFT-CPPL-ADDR PIC S9(8) COMP-5. > 05 WS-IKJEFT-FLAGS PIC X(4) VALUE X'00010001'. > 05 WS-IKJEFT-BUFFER PIC X(256). > 05 WS-IKJEFT-LENGTH PIC S9(8) COMP-5 VALUE ZERO. > *** > * CREATE TSO ENVIRONMENT > CALL 'IKJTSOEV' USING WS-IKJEFT-DUMMY > WS-IKJEFT-RC > WS-IKJEFT-REASON-CD > WS-IKJEFT-INFO-CD > WS-IKJEFT-CPPL-ADDR > END-CALL > > IF WS-IKJEFT-RC NOT = ZERO >MOVE WS-IKJEFT-RCTO WS-DISPLAY-RC >DISPLAY 'IKJTSOEV FAILED - RC=' WS-DISPLAY-RC > END-IF > > * ISSUE TSO COMMAND (E.G. ALLOCATE TEMP DATASET) > MOVE SPACES TO WS-IKJEFT-BUFFER > STRING 'ALLOC DD(TEMPDD) ' DELIMITED BY SIZE >'DSORG(PS) LRECL(80) BLKSIZE(0) RECFM(F B) ' > DELIMITED BY SIZE >'UNIT(SYSDA) SPACE(1,1) TRACKS ' DELIMITED BY SIZE >'NEW DELETE' DELIMITED BY SIZE > INTO WS-IKJEFT-BUFFER > END-STRING > PERFORM 8000-CALL-TSO THRU 8000-EXIT > > *** > * IF YOU CODED A SELECT ... ASSIGN TO TEMPDD, THEN YOU COULD > * CODE COBOL OPEN/WRITE/CLOSE, OPEN/READ/CLOSE, ETC. HERE. > *** > > * ISSUE TSO COMMAND (E.G. FREE TEMP DATASET) > MOVE 'FREE DD(TEMPDD)' TO WS-IKJEFT-BUFFER > PERFORM 8000-CALL-TSO THRU 8000-EXIT > > *** > 8000-CALL-TSO. > *** > PERFORM VARYING WS-IKJEFT-LENGTH > FROM LENGTH OF WS-IKJEFT-BUFFER BY -1 > UNTIL WS-IKJEFT-LENGTH = 1 > OR WS-IKJEFT-BUFFER(WS-IKJEFT-LENGTH:1) > SPACES > END-PERFORM > > CALL 'IKJEFTSR' USING WS-IKJEFT-FLAGS > WS-IKJEFT-BUFFER > WS-IKJEFT-LENGTH > WS-IKJEFT-RC > WS-IKJEFT-REASON-CD > WS-IKJEFT-DUMMY > END-CALL > > IF WS-IKJEFT-RC NOT = ZERO >MOVE WS-IKJEFT-RCTO WS-DISPLAY-RC >DISPLAY 'IKJEFTSR FAILED - RC=' WS-DISPLAY-RC >MOVE WS-IKJEFT-REASON-CD TO WS-DISPLAY-RC >DISPLAY ' REASON CODE=' WS-DISPLAY-RC >DISPLAY 'CMD=<' WS-IKJEFT-BUFFER(1:WS-IKJEFT-LENGTH) '>' > END-IF > . > 8000-EXIT. EXIT. > > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified > that any dissemination, distribution or copying of this e-mail is > prohibited. If you have received this e-mail in error, please notify the > sender by replying to this message and delete this e-mail immediately. > > -- > 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 / ar
Re: checking for the existence of a file in batch REXX
On Thu, 21 May 2009 15:29:12 +0100, Jim McAlpine wrote: > And to answer Walts suggestion, no we >can't have the COBOL program invoked from IKJEFT01 as that part of the >architecture is carved in stone. I'm not sure how this counts as "architecture", Jim. If I had said, couldn''t you have a TSO user run the COBOL program, that might be architecture. But all my suggestion is is a JCL change (as I suspect you know), but perhaps others in your organization don't understand? Instead of // EXEC PGM=cobol-program,PARM='whatever' // DD statements here you go with // EXEC PGM=IKJEFT01,PARM='CALL *(cobol-program)' ''whatever''' //SYSTSPRT DD SYSOUT=* //SYSTSIN DD DUMMY // DD statements here The COBOl program should never notice the difference. -- Walt -- 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: checking for the existence of a file in batch REXX
Jim McAlpine wrote: > > Thanks for all the replies and suggestions. Having spoken again to > the developer who originally asked the question, it seems it is a tad > more complicated in that he actually wants to do i/o against the file > from the REXX program. The question now becomes, can we call TSO from > a COBOL program without being authorised. And to answer Walts > suggestion, no we can't have the COBOL program invoked from IKJEFT01 > as that part of the architecture is carved in stone. > You can call TSO from COBOL without being authorized, you just can't use any authorized services. I do it in a program on the CBT called SYMBSUB (file 779). Basically you just call IKJTSOEV to create the TSO environment, then call IKJEFTSR to issue TSO commands. Here is a code snippet to give you a head start if you wish to pursue this further. This should not necessarily be considered an endorsement of using this approach. It's a pretty big gun to use if your target happens to be small. 01 WS-IKJEFT-PARMS. 05 WS-IKJEFT-DUMMY PIC S9(8) COMP-5. 05 WS-IKJEFT-RC PIC S9(8) COMP-5. 05 WS-IKJEFT-REASON-CD PIC S9(8) COMP-5. 05 WS-IKJEFT-INFO-CDPIC S9(8) COMP-5. 05 WS-IKJEFT-CPPL-ADDR PIC S9(8) COMP-5. 05 WS-IKJEFT-FLAGS PIC X(4) VALUE X'00010001'. 05 WS-IKJEFT-BUFFER PIC X(256). 05 WS-IKJEFT-LENGTH PIC S9(8) COMP-5 VALUE ZERO. *** * CREATE TSO ENVIRONMENT CALL 'IKJTSOEV' USING WS-IKJEFT-DUMMY WS-IKJEFT-RC WS-IKJEFT-REASON-CD WS-IKJEFT-INFO-CD WS-IKJEFT-CPPL-ADDR END-CALL IF WS-IKJEFT-RC NOT = ZERO MOVE WS-IKJEFT-RCTO WS-DISPLAY-RC DISPLAY 'IKJTSOEV FAILED - RC=' WS-DISPLAY-RC END-IF * ISSUE TSO COMMAND (E.G. ALLOCATE TEMP DATASET) MOVE SPACES TO WS-IKJEFT-BUFFER STRING 'ALLOC DD(TEMPDD) ' DELIMITED BY SIZE 'DSORG(PS) LRECL(80) BLKSIZE(0) RECFM(F B) ' DELIMITED BY SIZE 'UNIT(SYSDA) SPACE(1,1) TRACKS ' DELIMITED BY SIZE 'NEW DELETE' DELIMITED BY SIZE INTO WS-IKJEFT-BUFFER END-STRING PERFORM 8000-CALL-TSO THRU 8000-EXIT *** * IF YOU CODED A SELECT ... ASSIGN TO TEMPDD, THEN YOU COULD * CODE COBOL OPEN/WRITE/CLOSE, OPEN/READ/CLOSE, ETC. HERE. *** * ISSUE TSO COMMAND (E.G. FREE TEMP DATASET) MOVE 'FREE DD(TEMPDD)' TO WS-IKJEFT-BUFFER PERFORM 8000-CALL-TSO THRU 8000-EXIT *** 8000-CALL-TSO. *** PERFORM VARYING WS-IKJEFT-LENGTH FROM LENGTH OF WS-IKJEFT-BUFFER BY -1 UNTIL WS-IKJEFT-LENGTH = 1 OR WS-IKJEFT-BUFFER(WS-IKJEFT-LENGTH:1) > SPACES END-PERFORM CALL 'IKJEFTSR' USING WS-IKJEFT-FLAGS WS-IKJEFT-BUFFER WS-IKJEFT-LENGTH WS-IKJEFT-RC WS-IKJEFT-REASON-CD WS-IKJEFT-DUMMY END-CALL IF WS-IKJEFT-RC NOT = ZERO MOVE WS-IKJEFT-RCTO WS-DISPLAY-RC DISPLAY 'IKJEFTSR FAILED - RC=' WS-DISPLAY-RC MOVE WS-IKJEFT-REASON-CD TO WS-DISPLAY-RC DISPLAY ' REASON CODE=' WS-DISPLAY-RC DISPLAY 'CMD=<' WS-IKJEFT-BUFFER(1:WS-IKJEFT-LENGTH) '>' END-IF . 8000-EXIT. EXIT. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- 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: checking for the existence of a file in batch REXX
On Thursday 21 May 2009, Jim McAlpine wrote: > > Thanks for all the replies and suggestions. Having spoken again to > the developer who originally asked the question, it seems it is a > tad more complicated in that he actually wants to do i/o against the > file from the REXX program. The question now becomes, can we call > TSO from a COBOL program without being authorised. And to answer > Walts suggestion, no we can't have the COBOL program invoked from > IKJEFT01 as that part of the architecture is carved in stone. So, I think Paul has nailed it - do they need anything more than SVC 99 services and basic EXECIO style I/O (which can both be achieved without a TSO environment)? If there are specific TSO services needed, then pull out your trusty "TSO/E Programming Services" and bone up on IKJTSOEV and IKJEFTSR. Note that you can't use any authorized TSO services via this interface. If you need that, then the stones may really need to be re-cut, along the lines that Walt suggested. Cheers, Bob -- 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: checking for the existence of a file in batch REXX
> And to answer Walts suggestion, no we can't have the COBOL program invoked from IKJEFT01 as that part of the architecture is carved in stone. Which is more important? The business need? Or, the architecture? The architecture should never exclude a solution to the problem at hand. This kind of issue is why IT gets a bad name from the business side of the organisation. I'm not saying that Walt's solution is the right one, but if it becomes the one to be used, the architecture should NEVER get in the way of the business! - Too busy driving to stop for gas! -- 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: checking for the existence of a file in batch REXX
On Thu, 21 May 2009 15:29:12 +0100, Jim McAlpine wrote: > >Thanks for all the replies and suggestions. Having spoken again to the >developer who originally asked the question, it seems it is a tad more >complicated in that he actually wants to do i/o against the file from the >REXX program. The question now becomes, can we call TSO from a COBOL >program without being authorised. And to answer Walts suggestion, no we >can't have the COBOL program invoked from IKJEFT01 as that part of the >architecture is carved in stone. > You can at least use BPXWDYN() and address MVS EXECIO without TSO. Do you need more i/o facilities than those? -- 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: checking for the existence of a file in batch REXX
Jim McAlpine wrote: [snip] Thanks for all the replies and suggestions. Having spoken again to the developer who originally asked the question, it seems it is a tad more complicated in that he actually wants to do i/o against the file from the REXX program. The question now becomes, can we call TSO from a COBOL program without being authorised. And to answer Walts suggestion, no we can't have the COBOL program invoked from IKJEFT01 as that part of the architecture is carved in stone. Jim McAlpine It is definitely possible to call TSO _services_ from a COBOL program. You don't need to necessarily bring in all of TSO! We offer a two day course, "Introduction to TSO and REXX APIs" that demonstrates issuing TSO commands as well as invoking various REXX services from programs written in Assembler, COBOL, PL/I, and C. For details, check out: http://www.trainersfriend.com/TSO_Clist_REXX_Dialog_Mgr/a780descrpt.htm Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques ==> Check out the Trainer's Friend Store to purchase z/OS <== ==> application developer toolkits. Sample code in four<== ==> programming languages, JCL to Assemble or compile, <== ==> bind and test. <== ==> http://www.trainersfriend.com/TTFStore/index.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: checking for the existence of a file in batch REXX
On Thu, May 21, 2009 at 3:14 PM, Walt Farrell wrote: > On Wed, 20 May 2009 14:51:10 +0100, Jim McAlpine > wrote: > > >We have a REXX program which is called from COBOL in batch in which we > need > >to check for the existence of a file. Obviously there is no TSO > environment > >here so no commands like LISTDS. Is there anyway to acheive this without > >the TSO environment. > > I don't think anyone else has mentioned it, so I will. You could run > IKJEFT01 in your batch job and have it CALL your COBOL program. Then, when > your program invokes the REXX exec it would have the TSO facilities > available to it. > > > -- > Walt > > -- > 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 > Thanks for all the replies and suggestions. Having spoken again to the developer who originally asked the question, it seems it is a tad more complicated in that he actually wants to do i/o against the file from the REXX program. The question now becomes, can we call TSO from a COBOL program without being authorised. And to answer Walts suggestion, no we can't have the COBOL program invoked from IKJEFT01 as that part of the architecture is carved in stone. Jim McAlpine -- 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: checking for the existence of a file in batch REXX
On Wed, 20 May 2009 14:51:10 +0100, Jim McAlpine wrote: >We have a REXX program which is called from COBOL in batch in which we need >to check for the existence of a file. Obviously there is no TSO environment >here so no commands like LISTDS. Is there anyway to acheive this without >the TSO environment. I don't think anyone else has mentioned it, so I will. You could run IKJEFT01 in your batch job and have it CALL your COBOL program. Then, when your program invokes the REXX exec it would have the TSO facilities available to it. -- Walt -- 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: checking for the existence of a file in batch REXX
On Thursday 21 May 2009, McKown, John wrote: > > I feel rejected . Doesn't anybody like using the "new" > Enterprise COBOL feature which does the DYNALLOC behind the scenes? There, there...that would be fine also. We've just been exploring all the options available to OP. (I haven't really used COBOL in [mumblemumble] years, so I haven't kept up with the newer features. Sounds slick.) Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. www.woodsway.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: checking for the existence of a file in batch REXX
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Woodside > Sent: Thursday, May 21, 2009 12:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: checking for the existence of a file in batch REXX > > On Wednesday 20 May 2009, Paul Gilmartin wrote: > > > > Doesn't IKJEFT01 require that it be invoked only from an > > APF authorized program, which might be an obstacle to the > > OP? > > Actually, I believe I spoke before thinking earlier. > I think the > program would need to call IKJTSOEV and IKJEFTSR, and I don't think > they're restricted to authorized programs. But your suggestion of > calling BPXWDYN is much more sensible. > > > If the OP intends to process the file in the COBOL program, > > might allocating it in Rexx shortcut the need to allocate > > it in the COBOL code? > > If all the Rexx program is used for is to check > whether the file > exists, then they can eliminate it altogether by just calling BPXWDYN > directly from the COBOL program. But if there's more to it than that, > then yes, if the Rexx program call to BPXWDYN succeeded it might as > well leave the file allocated, and the COBOL program needn't do that. I feel rejected . Doesn't anybody like using the "new" Enterprise COBOL feature which does the DYNALLOC behind the scenes? -- 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: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Paul Gilmartin wrote: > > Doesn't IKJEFT01 require that it be invoked only from an > APF authorized program, which might be an obstacle to the > OP? Actually, I believe I spoke before thinking earlier. I think the program would need to call IKJTSOEV and IKJEFTSR, and I don't think they're restricted to authorized programs. But your suggestion of calling BPXWDYN is much more sensible. > If the OP intends to process the file in the COBOL program, > might allocating it in Rexx shortcut the need to allocate > it in the COBOL code? If all the Rexx program is used for is to check whether the file exists, then they can eliminate it altogether by just calling BPXWDYN directly from the COBOL program. But if there's more to it than that, then yes, if the Rexx program call to BPXWDYN succeeded it might as well leave the file allocated, and the COBOL program needn't do that. -- 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: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Bob Woodside wrote: > > Would it be feasible for you to invoke IKJEFT01 instead of > the Rexx interpreter... On the other hand Forget my earlier lame suggestion. As a couple of other people have already pointed out, calling BPXWDYN is the way to go. It will do exactly what you need. You should be able to call it directly from your COBOL program. Or, you could call it from your Rexx program, which you might want to have available for other programs to call, from a variety of environments - TSO, MVS batch, or USS. -- 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: checking for the existence of a file in batch REXX
On Wed, 20 May 2009 17:15:38 -0400, Bob Woodside wrote: >On Wednesday 20 May 2009, Jim McAlpine wrote: >> We have a REXX program which is called from COBOL in batch in which >> we need to check for the existence of a file. Obviously there is no >> TSO environment here so no commands like LISTDS. Is there anyway to >> acheive this without the TSO environment. > >Would it be feasible for you to invoke IKJEFT01 instead of the >Rexx interpreter to run your Rexx exec? That way you have the TSO >environment available to your Rexx script, and can use SYSDSN and >friends. IKJEFT01 will return the return value from last command >executed. > >Or is your COBOL program linked with compiled Rexx code? How >does your program communicate with Rexx? > Doesn't IKJEFT01 require that it be invoked only from an APF authorized program, which might be an obstacle to the OP? If the OP intends to process the file in the COBOL program, might allocating it in Rexx shortcut the need to allocate it in the COBOL code? -- 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: checking for the existence of a file in batch REXX
On Wednesday 20 May 2009, Jim McAlpine wrote: > We have a REXX program which is called from COBOL in batch in which > we need to check for the existence of a file. Obviously there is no > TSO environment here so no commands like LISTDS. Is there anyway to > acheive this without the TSO environment. Would it be feasible for you to invoke IKJEFT01 instead of the Rexx interpreter to run your Rexx exec? That way you have the TSO environment available to your Rexx script, and can use SYSDSN and friends. IKJEFT01 will return the return value from last command executed. Or is your COBOL program linked with compiled Rexx code? How does your program communicate with Rexx? -- 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: checking for the existence of a file in batch REXX
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim McAlpine
> Sent: Wednesday, May 20, 2009 8:51 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: checking for the existence of a file in batch REXX
>
> We have a REXX program which is called from COBOL in batch in
> which we need
> to check for the existence of a file. Obviously there is no
> TSO environment
> here so no commands like LISTDS. Is there anyway to acheive
> this without
> the TSO environment.
>
> Jim McAlpine
Jim,
Is is a requirement to test for existance in the REXX program? Would it be
acceptable to test for existance in the COBOL program? Are you aware that it is
possible to set up Enterprise COBOL to do a dynamic allocation for a dataset?
It is not really very difficult and is documented in the current COBOL manuals.
FILE-CONTROL.
SELECT CONTROL-CARD ASSIGN TO DSNAME
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS CONTROL-CARD-FILE-STATUS-1.
...
WORKING-STORAGE SECTION.
77 CONTROL-CARD-FILE-STATUS-1PIC XX.
77 RETURN-DATA PIC X(4).
01 ENV-DATA.
05 FILLER PIC X(11) VALUE 'DSNAME=DSN('.
05 DSN PIC X(110) VALUE IS LOW-VALUES.
01 P POINTER.
01 RC PIC S9(9) BINARY.
01 EOF-SWITCH PIC X VALUE IS LOW-VALUES.
88 EOF VALUE IS HIGH-VALUES.
LINKAGE SECTION.
01 MVS-PARM.
05 MVS-PARM-LENGTH PIC S999 USAGE BINARY.
05 MVS-PARM-VALUEPIC X(120) .
...
MOVE MVS-PARM-VALUE(1:MVS-PARM-LENGTH) TO
DSN(1:MVS-PARM-LENGTH)
MOVE ') SHR' TO DSN(MVS-PARM-LENGTH + 1:5)
MOVE LOW-VALUES TO DSN(MVS-PARM-LENGTH + 6:1)
SET P TO ADDRESS OF ENV-DATA
CALL 'PUTENV' USING BY VALUE P RETURNING RC
IF RC > 0 THEN
DISPLAY 'PUTENV FAILED RC=' RC UPON SYSOUT
MOVE +8 TO RETURN-CODE
STOP RUN
END-IF
OPEN INPUT CONTROL-CARD
IF CONTROL-CARD-FILE-STATUS-1 NOT = 0 THEN
DISPLAY 'CANNOT OPEN FILE RC=' CONTROL-CARD-FILE-STATUS-1
UPON SYSOUT
MOVE +8 TO RETURN-CODE
STOP RUN
END-IF
The above is some code in which the DSN is passed into the COBOL program via
the PARM=. It could just as easily be read from another file. If the file fails
to OPEN, then it is not available for some reason. It might be "in use" or "not
found" or something else.
ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg40/1.8.3
--
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: checking for the existence of a file in batch REXX
On Wed, May 20, 2009 at 3:03 PM, Paul Gilmartin wrote: > On Wed, 20 May 2009 14:51:10 +0100, Jim McAlpine wrote: > > > What do you intend to do if: > > o It exists? > > o It doesn't exist? > > respectively > > -- 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 > if it exists - then run the program if it doesn't exist - then end the program gracefully with some message. Jim McAlpine -- 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: checking for the existence of a file in batch REXX
On Wed, 20 May 2009 14:51:10 +0100, Jim McAlpine wrote: >We have a REXX program which is called from COBOL in batch in which we need >to check for the existence of a file. Obviously there is no TSO environment >here so no commands like LISTDS. Is there anyway to acheive this without >the TSO environment. > ALLOCate it with BPXWDYN and check the return code/messages? What do you intend to do if: o It exists? o It doesn't exist? respectively -- 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
