Rexx SDSF API

[Gilbert C Cardenas]

Could someone please point me to the proper method for releasing allocated SDSF datasets via the REXX api.
The manual only shows how to allocate the jes datasets but I cannot find any notes about release them?

I have the following code excerpt which all works fine except that the jes allocations remain:

ISFRC = ISFCALLS( "ON")
ISFACTIONS = "ON"
ISFPREFIX='*'
ISFOWNER = "*"

ADDRESS SDSF "ISFEXEC OK (DELAYED"
IF ISFRC <> 0 THEN CALL MSGRTN

DO IX = 1 TO ISFROWS

ADDRESS SDSF "ISFACT OK TOKEN('"TOKEN.IX"') PARM(NP ?)(PREFIX JDS_)"
SAY "=============================================================="
SAY JNAME.IX " HAS " JDS_DDNAME.0 " DDNAMES ALLOCATED."
SAY "=============================================================="
IF ISFRC <> 0 THEN CALL MSGRTN

DO JY=1 TO JDS_DDNAME.0
ADDRESS SDSF "ISFACT OK TOKEN('"TOKEN.IX"') PARM(NP SA)"
IF ISFRC <> 0 THEN CALL MSGRTN
SAY "ISFDDNAME: " ISFDDNAME.JY
SAY "ISFDSNAME: " ISFDSNAME.JY
SAY "DDNAME: " JDS_DDNAME.JY
SAY "DSNAME: " JDS_DSNAME.JY
"FREE FI("ISFDDNAME.JY")"
END

END

ISFRC = ISFCALLS( "OFF")

I have tried freeing the ISFDDNAME.JY, the JDS_DDNAME.JY and the JDS_DSNAME.JY, however, when I look at my allocated datasets I still see several iterations of the jes datasets and I have to manually free them after executing the script.

SHR,KEEP > SYS00988 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00989 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00990 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00991 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00992 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00993 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00995 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00996 ---------- JES2 Subsystem file -------------
SHR,KEEP > SYS00997 ---------- JES2 Subsystem file -------------

I did find mention where there is a global setting for UNALLOC (NO) | (YES) but I'm not sure if this applies or how? I'm stumped!

A kind nudge in the right direction would be greatly appreciated.

________________________________
This e-mail (and any attachments) may contain information that is confidential and/or protected by law. Any review, use, distribution or disclosure to anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.


----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Paul Gilmartin]

On 2012-03-06 12:21, Gilbert C Cardenas wrote:
> Could someone please point me to the proper method for releasing allocated SDSF datasets via the REXX api.
> The manual only shows how to allocate the jes datasets but I cannot find any notes about release them?
>

In another context, with a different utility, I use BPXWDYN('info ..')
before and after
and build lists of allocated DDNAMEs. Then I go through the latter list
and FREE
everything not appearing in the former.

Sucks.

But often, in CABAL mode, I use the Rexx SDSF API under Unix System
Services with
_BPX_SHAREAS=NO. Presto! All the allocations vanish when the EXEC
returns to shell.

-- gil

[Gilbert C Cardenas]

Looking at the IBM Education Assistant example "z/OS V1r9 SDSF Support for REXX", it shows in the browse job datasets example:

Browse job data sets
Use ISFACT to issue new SA action character against job
Allocates the data set (free=close)
REXX only

You can browse the data sets for a job with REXX. Rather than using the S action
character as you would when running SDSF interactively, you use a REXX-only action
character, SA. This allocates a data set that you can then read with a utility such as
EXECIO. SDSF uses special variables for the DDNAME and data set name.

I was thinking that maybe it was a requirement to open the dataset for processing and then close it, but I added a DISKR instruction to read the dataset(s) into a stem but results were still the same:

"EXECIO * DISKR" ISFDDNAME.JY " ( STEM IL. FINIS"
SAY IL.0 "TOTAL LINES PROCESSED FOR" ISFDDNAME.JY ISFDSNAME.JY
DROP IL

Guess I'll have to do as you mentioned and go through a list of all of the allocated DDNAMES left behind and free the ones left allocated.

Sucks indeed!

This e-mail (and any attachments) may contain information that is confidential and/or protected by law. Any review, use, distribution or disclosure to anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.

[Paul Gilmartin]

On Mar 7, 2012, at 06:46, Gilbert C Cardenas wrote:

> Looking at the IBM Education Assistant example "z/OS V1r9 SDSF Support for REXX", it shows in the browse job datasets example:
>

You have me curious -- Are you using the

isfcalls( 'ON' )
address 'SDSF'

interfaces described in:

Document Number SA22-7670-11

#12.0 "z/OS V1R10.0 SDSF Operation and Customization"
12.0 Using SDSF with the REXX programming language

??? These are fairly new; V1r9 seems about right.

> Guess I'll have to do as you mentioned and go through a list of all of the allocated DDNAMES left behind and free the ones left allocated.
>

So I wrote the code myself, and tried it. I FREEd all the DDNAMEs
SDSF told me about as I processed them, and found none that SDSF
had allocated and left unFREEd.

My code:

/* Build list of previously allocated DDNAMEs.
*/
Allocated. = 0
RC = ListDD( 'BEFORE' )
do I = 1 to AlDDN.BEFORE.0
DDN = AlDDN.BEFORE.I
Allocated.DDN = 1; end I

/* ... process a job ... */

/* List unFREEd DDNAMEs
*/
RC = BPXWDYN( 'alloc new msg(WTP)' ) /* Experimental control. */
RC = ListDD( 'AFTER' )
do I = 1 to AlDDN.AFTER.0
DDN = AlDDN.AFTER.I
if Allocated.DDN then nop
else say "Dangling " DDN; end I
exit

/* Return list of allocated DDNames in stem AlDDN.arg(1).*
*/
ListDD: procedure expose AlDDN.

parse arg W
do DDX = 1 until last<>0
Call bpxwdyn 'info inrelno('DDX')' ,
'inrtddn(AlDDN.W.'DDX') inrtlst(last) msg(WTP)'; end DDX
AlDDN.W.0 = DDX
return( 0 )

[Gilbert C Cardenas]

I am using isfcalls( "ON' ) and I did find in the 12.0 Using SDSF with the REXX programming language usage notes:



SDSF allocates SYSOUT data sets using the FREE=CLOSE attribute. This

causes the system to free the allocation when the data set is closed by the

application. If an application causes a data set to be allocated but does not open

it, it should free the allocation explicitly. Failure to free the data sets may result in

the allocation limit being reached and further allocations being rejected.

The REXX caller should also ensure that the DYNAMNBR JCL keyword is set to

a high enough limit to accommodate all of the expected allocations done by the

exec.

You can use the FINIS option of EXECIO to close the data set when EXECIO

completes.



The API does a dynamic allocation using the NP SA parm and I am not explicitly coding one.

I did not open the dataset but merely displayed the properties so I am confused about why the allocations remained.

I also tried reading the dataset using the FINIS option and still the allocations remained.

I was able to loop through the allocations and manually free them though I was not expecting to have to do that.

We are on z/OS 1.9 but the system I am testing on has coreq/prereqs for z/OS 1.13 so I am wondering if the doc is wrong or there might be a PTF to address this etc.



Anyhow, thanks for your feedback.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin
Sent: Wednesday, March 07, 2012 11:35 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Rexx SDSF API

For TSO-REXX subscribe / signoff / archive access instructions, send email to LIST...@VM.MARIST.EDU<mailto:LIST...@VM.MARIST.EDU> with the message: INFO TSO-REXX

________________________________

This e-mail (and any attachments) may contain information that is confidential and/or protected by law. Any review, use, distribution or disclosure to anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.

[Rob Zenuk]

Interesting issue... I had never seen it and I use this SDSF API a lot...
However, I always EXECIO the SYSOUT when I do this. It seems weird to me to
go through all this then not use the data. So, I wrote a simple example of
this process to play with.

What I found is when you actually EXECIO the SYSOUT and use the FINIS
option, everything nicely deallocates. When you do not EXECIO, the SYSOUTs
all stay allocated. You will see the following lines in my sample below:

/* address TSO "EXECIO * DISKR" isfddname.1 "(STEM OUT. FINIS" */
say jname.j $ddname.d isfddname.1 out.0
"FREE F("isfddname.1")"
/* drop out. */

When the EXECIO was not commented out, the FREE would fail (since the EXECIO
caused the deallocate). When the EXECIO was commented out the FREE worked
fine.


Here is my testing code:

/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Review all SYSOUTS for a prefix of jobs */
/*-------------------------------------------------------------------*/
/* Syntax: SDSFSOUT */
/*-------------------------------------------------------------------*/
/* Parms: PATTERN - Valid SDSF PREFIX value (def: current jobname) */
/* LPAR - Valid SDSF SYSNAME value (def: all LPAR's) */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Mar 2012 Initial Creation */
/* */
/*********************************************************************/
/* Accept the JOB prefix */
/*********************************************************************/
arg pattern lpar
if pattern = '' then
pattern = mvsvar('SYMDEF','JOBNAME')
if lpar = '' then
lpar = '*'
isfprefix = pattern
isfsysname = lpar
out.0 = 0
/*********************************************************************/
/* Invoke SDSF DA using the prefix */
/*********************************************************************/
if isfcalls('ON') <> 0 then exit 99
call sdsfapi "ISFEXEC DA"
/*********************************************************************/
/* LISTA ST */
/*********************************************************************/
"LISTA ST"
/*********************************************************************/
/* Find the matching jobnames */
/*********************************************************************/
do j=1 to isfrows
/*********************************************************************/
/* Select the jobname and allocate all the output sysout datasets */
/*********************************************************************/
say jname.j jobid.j sysname.j
call sdsfapi "ISFACT DA TOKEN('"token.j"') PARM(NP ?) (PREFIX $"
/*********************************************************************/
/* Read the DD list for each job */
/*********************************************************************/
do d=1 to $ddname.0
call sdsfapi "ISFACT DA TOKEN('"$token.d"') PARM(NP SA)"
/*********************************************************************/
/* Read each SYSOUT */
/*********************************************************************/
/* address TSO "EXECIO * DISKR" isfddname.1 "(STEM OUT. FINIS" */
say jname.j $ddname.d isfddname.1 out.0
"FREE F("isfddname.1")"
/* drop out. */
end
end
say
call isfcalls 'OFF'
/*********************************************************************/
/* LISTA ST */
/*********************************************************************/
"LISTA ST"
exit 0
/*********************************************************************/
/* SDSF error conditions */
/*********************************************************************/
sdsfapi: parse arg sdsfcall
address SDSF sdsfcall
select
/*********************************************************************/
/* Ignorable conditions */
/*********************************************************************/
when isfmsg = '' then return
when isfmsg = 'DATA SET ALLOCATED' then return
/*********************************************************************/
/* Real errors - always RC=16 */
/*********************************************************************/
otherwise
do
say isfmsg
say
do e=1 to isfmsg2.0
say sdsfcall right(e,2)':' isfmsg2.e
end
exit 16
end
end


Hope this helps.

Rob

[Paul Gilmartin]

On 2012-03-07 15:53, Rob Zenuk wrote:
> Interesting issue... I had never seen it and I use this SDSF API a lot...
> However, I always EXECIO the SYSOUT when I do this. It seems weird to me to
> go through all this then not use the data. So, I wrote a simple example of
> this process to play with.
>
> What I found is when you actually EXECIO the SYSOUT and use the FINIS
> option, everything nicely deallocates. When you do not EXECIO, the SYSOUTs
> all stay allocated. You will see the following lines in my sample below:
>
> /* address TSO "EXECIO * DISKR" isfddname.1 "(STEM OUT. FINIS" */
> say jname.j $ddname.d isfddname.1 out.0
> "FREE F("isfddname.1")"
> /* drop out. */
>
> When the EXECIO was not commented out, the FREE would fail (since the EXECIO
> caused the deallocate). When the EXECIO was commented out the FREE worked
> fine.
>

I concur. In my EXEC, I was processing every spool data set in the
job, not merely SYSOUT but also SYSIN and JCL, using IEBGENER to
UNIX files. IEBGENER apparently CLOSES all of them; none were left
allocated. But when I added my probe, I found that while I had
conscientiously closed SYSUT2, I had been neglecting to FREE SYSIN
and SYSPRINT. Fixed. I also modified the EXEC so it does not alter
any pre-existing allocations.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,

send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Gilbert C Cardenas]

Thanks Rob, I do intend to use it however, I do not want to waste the resources in opening and reading the dataset. I merely want to allocate it and then attempt to ftp or last resort LPR it (I didn't really want to send it to a Windows print spool but to a file).

I have tried using EXECIO (reading zero records and also reading all records) with the FINIS option, however, the allocations remain...
"EXECIO 0 DISKR" ISFDDNAME.JY " (FINIS"
"EXECIO * DISKR" ISFDDNAME.JY " (FINIS"

I have gotten past this by looping through the allocations and deallocating them at the end of the script but I will most definitely have to go back and cleanse my code to make sure I'm not falling through somewhere.

I have a small application where I need to move mainframe reports from the Jes queue to files on a server. I really just wanted to test to see if the SDSF api was hearty enough to handle this.

Right now I am working on trying to FTP the dataset using the FTPAPI and I'm having an issue specifying the path to the dataset:
ID - dbg Date - 03/08/2012 Time - 08:07:23 Process ID - 0000000000000330 TCB Address - 0000000
dbg SCMD >user bogusid|w
dbg >>> USER bogusid
dbg 331 Password required for bogusid.
dbg Command(00-19-USER-331):
dbg SCMD < .
dbg SCMD >pass ********|w
dbg >>> PASS
dbg 230 User logged in.
dbg Command(00-26-PASS-230):
dbg SCMD < W
dbg SCMD >PUT 'OMVSKERN.GSDP065F.JOB01280.D0000002.JESMSGLG' GSDP065F.SYS00217.JOB01280|w
dbg Local file not found
dbg Command(18-27- - ):
dbg SCMD <
dbg SCMD >QUIT|W (Generated by TERM)
dbg >>> QUIT
dbg 221 Goodbye.
dbg FtpStop(00-29-QUIT-221):
dbg SCMD <
dbg TERM >


I've tried to FTP by specifying DDNAME but apparently that is not allowed using the FTPAPI.

[Rob Zenuk]

When I break it (no EXECIO and no FREE) I can see the allocated datasets. I
added the ISFDSNAME.1 to my "say" and these look like spool datasets, not
traditional datasets.

So, I ran my EXEC under my TSO ID and used TSO ISRDDN to try and look at the
allocations... Here is what I saw when I tried to Browse one of the
allocations.

Current Data Set Allocations Invalid device
Command ===> Scroll ===> CSR



Volume Disposition Act DDname Data Set Name Actions: B E V M F C I Q

TTS902 SHR,KEEP > SYSPROC MY.CLIST
SYS106 SHR,KEEP > SYS0.CMDPROC

IPLPS4 SHR,KEEP > SYS1.CMDPROC

NEW,DEL > SYSTERM ------- Allocated to the terminal -------
SHR,KEEP > b SYS00022 ------- JES2 Subsystem file -------------
SHR,KEEP > SYS00023 ------- JES2 Subsystem file -------------
SHR,KEEP > SYS00024 ------- JES2 Subsystem file -------------
-------------------------- End of Allocation List --------------------------

Using the 'B' line command I received the "Invalid device" error message in
the upper right corner. So, while the SDSF API makes the spool datasets
available to EXECIO I am suspecting this is an internal interface. I also
suspect this is why FTP can't use the //DD:DDNAME feature.

Maybe you need to externalize the spool dataset first... Another option
may be to use the FTP FILETYP=JES interface.

[Gilbert C Cardenas]

This is the exact behavior I am seeing. This is definitely a work in progress so I'll have to re-strategize.

Thanks for the insight.

[Paul Gilmartin]

On Mar 8, 2012, at 10:00, Adrian Stern wrote:

> I said this last time - but I'll say it again. You seem to be using the
> wrong tool for the job quite honestly. If you just want to get hold of
> datasets from job output; either write to normal datasets or use the tso
> output command. Much simpler than the sdsf api.
>
I'll admit to an element of prejudice here. When SDSF appeared,
I was so delighted with its features that I turned away from
OUTPUT and never looked back.

Will OUTPUT separate, enumerate, and identify the various
SYSOUT data sets from a job?

Data sets? Can you direct job log to a data set? And there's
the nuisance of allocating them, and deleting them to
clean up. UNIX files might be friendlier; I use them a lot.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,

send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Paul Gilmartin]

On Mar 8, 2012, at 09:36, Rob Zenuk wrote:
>
> Using the 'B' line command I received the "Invalid device" error message in
> the upper right corner. So, while the SDSF API makes the spool datasets
> available to EXECIO I am suspecting this is an internal interface. I also
> suspect this is why FTP can't use the //DD:DDNAME feature.
>

I have a different suspicion. I have ample evidence that when
I transmit via FTP from //DD:DDNAME, FTP doesn't merely OPEN a
a DCB on the DDNAME; do GETs; and transmit over the socket.
Rather, it seems to rummage through control blocks, find the
underlying object and transmit from that. Overriding attributes
in the allocation tend to be ignored; if reading from the
DDNAME is possible with QSAM but FTP is ignorant of the
underlying object, FTP fails.

> Maybe you need to externalize the spool dataset first... Another option
> may be to use the FTP FILETYP=JES interface.
>

Does this interface work on the local file, or only on the
remote. I.e. does LOCSITE FILE=JES work?

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
> Gilbert C Cardenas
> Sent: Thursday, March 08, 2012 8:18 AM
>

> Thanks Rob, I do intend to use it however, I do not want to waste the
> resources in opening and reading the dataset. I merely want to allocate it
> and then attempt to ftp or last resort LPR it (I didn't really want to send
> it to a Windows print spool but to a file).
>
> I have tried using EXECIO (reading zero records and also reading all
> records) with the FINIS option, however, the allocations remain...
> "EXECIO 0 DISKR" ISFDDNAME.JY " (FINIS"
>

That worked for me and freed the allocation.

> I have gotten past this by looping through the allocations and deallocating
> them at the end of the script but I will most definitely have to go back and
> cleanse my code to make sure I'm not falling through somewhere.
>

Easy to suspect. Can you verify by wrapping TRACE R around EXECIO?

> Right now I am working on trying to FTP the dataset using the FTPAPI and I'm

> having an issue specifying the path to the dataset ...
>
See above. FTP is evil; it thinks it knows better than what
the programmer asks for.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,

send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Paul Gilmartin]

On Mar 8, 2012, at 09:36, Rob Zenuk wrote:
>

> Using the 'B' line command I received the "Invalid device" error message in
> the upper right corner. So, while the SDSF API makes the spool datasets
> available to EXECIO I am suspecting this is an internal interface. I also
> suspect this is why FTP can't use the //DD:DDNAME feature.
>

I have a different suspicion. I have ample evidence that when
I transmit via FTP from //DD:DDNAME, FTP doesn't merely OPEN a
a DCB on the DDNAME; do GETs; and transmit over the socket.
Rather, it seems to rummage through control blocks, find the
underlying object and transmit from that. Overriding attributes
in the allocation tend to be ignored; if reading from the
DDNAME is possible with QSAM but FTP is ignorant of the
underlying object, FTP fails.

> Maybe you need to externalize the spool dataset first... Another option
> may be to use the FTP FILETYP=JES interface.
>

Does this interface work on the local file, or only on the
remote. I.e. does LOCSITE FILE=JES work?

[Jeffrey C Benson]

My first question to this forum,

I trying to convert my clists (legacy) to REXX. Is is possible to execute
a REXX exec from a clist? If yes, how?. I getting this message:

A command entered or contained in a CLIST has invalid syntax.

Any help would be appreciated.

Jeffrey C Benson
Mainframe Security, Corporate BTS, Security, & Risk
Tel 212-919-2613 • Fax 212-919-4248
Mobile 646-306-0090
7 Hanover Square 2nd Fl, New York, NY 10004
Jeffrey...@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com





-----------------------------------------
This message, and any attachments to it, may contain information
that is privileged, confidential, and exempt from disclosure under
applicable law. If the reader of this message is not the intended
recipient, you are notified that any use, dissemination,
distribution, copying, or communication of this message is strictly
prohibited. If you have received this message in error, please
notify the sender immediately by return e-mail and delete the
message and any attachments. Thank you.

[Dave Salt]

It's been a long time since I've worked with CLIST's, but this should do what you want:

"ISPEXEC SELECT CMD(%yourrexx)"


Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html




> Date: Fri, 30 Mar 2012 14:11:37 -0400
> From: Jeffrey...@GLIC.COM
> Subject: Rexx from Clist
> To: TSO-...@VM.MARIST.EDU

[Don Imbriale]

What command are you issuing in an attempt to execute the REXX exec?

- Don Imbriale

On Fri, Mar 30, 2012 at 2:11 PM, Jeffrey C Benson
<Jeffrey...@glic.com>wrote:

> My first question to this forum,
>
> I trying to convert my clists (legacy) to REXX. Is is possible to execute
> a REXX exec from a clist? If yes, how?. I getting this message:
>
> A command entered or contained in a CLIST has invalid syntax.
>
> Any help would be appreciated.
>
> Jeffrey C Benson
> Mainframe Security, Corporate BTS, Security, & Risk
> Tel 212-919-2613 • Fax 212-919-4248
> Mobile 646-306-0090
> 7 Hanover Square 2nd Fl, New York, NY 10004
> Jeffrey...@glic.com
>
>
>

[Barry Schwarz]

On 30 Mar 2012 11:18:16 -0700, Jeffrey...@GLIC.COM (Jeffrey C

Benson) wrote:

>My first question to this forum,
>
>I trying to convert my clists (legacy) to REXX. Is is possible to execute
>a REXX exec from a clist? If yes, how?. I getting this message:
>
>A command entered or contained in a CLIST has invalid syntax.
>
>Any help would be appreciated.

Why not show us the code so we can help?

--
Remove del for email

[Steve Comstock]

On 3/30/2012 12:27 PM, Dave Salt wrote:
> It's been a long time since I've worked with CLIST's, but this should do what you want:
>
> "ISPEXEC SELECT CMD(%yourrexx)"

Dave,

That assumes an ISPF environment, which was not stated in the OP.

I thought what he's after is something like:

ex 'library_name(exec_name)' [parm list] EXEC

of, if the EXEC is in the SYSEXEC concatenation, this might work:

exec_name [parm list]

or even

%exec_name [parm list]

>
>
> Dave Salt
>
> SimpList(tm) - try it; you'll get it!
>
> http://www.mackinney.com/products/program-development/simplist.html
>
>
>
>
>> Date: Fri, 30 Mar 2012 14:11:37 -0400
>> From: Jeffrey...@GLIC.COM
>> Subject: Rexx from Clist
>> To: TSO-...@VM.MARIST.EDU
>>
>> My first question to this forum,
>>
>> I trying to convert my clists (legacy) to REXX. Is is possible to execute
>> a REXX exec from a clist? If yes, how?. I getting this message:
>>
>> A command entered or contained in a CLIST has invalid syntax.
>>
>> Any help would be appreciated.
>>
>> Jeffrey C Benson

>> Mainframe Security, Corporate BTS, Security,& Risk

>> Tel 212-919-2613 • Fax 212-919-4248
>> Mobile 646-306-0090
>> 7 Hanover Square 2nd Fl, New York, NY 10004
>> Jeffrey...@glic.com
>>
>>
>>
>>
>> The Guardian Life Insurance Company of America
>>
>> www.guardianlife.com
>>
>>
>>
>>
>


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html

[Dave Salt]

If ISPF is available, one of the nice things about using ISPEXEC SELECT is the error messages that are generated if something goes wrong.

Dave Salt

SimpList(tm) - try it; you'll get it!

http://www.mackinney.com/products/program-development/simplist.html

> Date: Fri, 30 Mar 2012 13:15:55 -0600
> From: st...@TRAINERSFRIEND.COM
> Subject: Re: Rexx from Clist

[Ted MacNEIL]

You can use the EXEC command -- check the syntax.

Or:

Put the REXX code in

SYSEXEC concatenation, or

SYSPROC

In the latter case the first line of each REXX exec has to be /* REXX

(With a closing /* -- eventually)
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

-----Original Message-----
From: Jeffrey C Benson <Jeffrey...@GLIC.COM>
Sender: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Date: Fri, 30 Mar 2012 14:11:37

[Ted MacNEIL]

> ex 'library_name(exec_name)' [parm list] EXEC

You have to enclose the [parm list] in quotes, as so:

ex 'library_name(exec_name)' '[parm list]' EXEC

-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL

[Paul Gilmartin]

On 2012-03-30 12:11, Jeffrey C Benson wrote:
> My first question to this forum,
>
> I trying to convert my clists (legacy) to REXX. Is is possible to execute
> a REXX exec from a clist? If yes, how?. I getting this message:
>
> A command entered or contained in a CLIST has invalid syntax.
>

Do any of your Rexx EXECs work?

Can you run the EXEC in question from the command line?

Is the first line of your EXEC "/* Rexx */ ..."?

Can you post the first few lines of your EXEC here?

Dave's comment is ISPF-centric, but it may be relevant.

-- gil

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,

send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Mickey]

'EX some.pds.name(myrexx) EX'

Mickey

--------------------------------------------------

From: "Jeffrey C Benson" <Jeffrey...@GLIC.COM>

Sent: Friday, March 30, 2012 2:11 PM
To: <TSO-...@VM.MARIST.EDU>

Subject: [TSO-REXX] Rexx from Clist

[Fenner, Jim]

Hi Jeffrey,
If your procedure abends and leaves something queued up, and the
TSO command processor starts to execute the commands, this message will
be seen

A command entered OR contained in a CLIST has invalid syntax

Maybe you are using the stack in your new REXXes as a byproduct of using
EXECIO or even explicitly with QUEUE,PUSH,PULL, and so on
If so, the style is to bracket your STACK processing with
address tso 'NEWSTACK' in front, and address tso 'DELSTACK' at the end,
PLUS to be careful to drain the stack if you make an error exit

http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fco
m.ibm.zos.r12.ikjc300%2Fikj4c31096.htm

Personally, I bracket with NEWSTACK and DELSTACK and do my IO into
stems, which are a great little data structure, and keep stuff off the
stack except I'll queue the stem JUST before an EXECIO write


Thanks,

Jim
Ph 02 621 64448 Mob 0401-712-978

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf

Of Jeffrey C Benson
Sent: Saturday, 31 March 2012 05:12
To: TSO-...@VM.MARIST.EDU
Subject: Rexx from Clist

My first question to this forum,

I trying to convert my clists (legacy) to REXX. Is is possible to
execute
a REXX exec from a clist? If yes, how?. I getting this message:

A command entered or contained in a CLIST has invalid syntax.

Any help would be appreciated.

Jeffrey C Benson
Mainframe Security, Corporate BTS, Security, & Risk

Tel 212-919-2613 * Fax 212-919-4248

Mobile 646-306-0090
7 Hanover Square 2nd Fl, New York, NY 10004
Jeffrey...@glic.com




The Guardian Life Insurance Company of America

www.guardianlife.com





-----------------------------------------
This message, and any attachments to it, may contain information
that is privileged, confidential, and exempt from disclosure under
applicable law. If the reader of this message is not the intended
recipient, you are notified that any use, dissemination,
distribution, copying, or communication of this message is strictly
prohibited. If you have received this message in error, please
notify the sender immediately by return e-mail and delete the
message and any attachments. Thank you.

**********************************************************************
IMPORTANT
The information transmitted is for the use of the intended
recipient only and may contain confidential and/or legally
privileged material. Any review, re-transmission, disclosure,
dissemination or other use of, or taking of any action in
reliance upon, this information by persons or entities other
than the intended recipient is prohibited and may result in
severe penalties. If you have received this e-mail in error
please notify the Privacy Hotline of the Australian Taxation
Office, telephone 13 2869 and delete all copies of this
transmission together with any attachments.
**********************************************************************