IDCAMS memory leak WAS: REXX assistance
Circling back around on this topic. After a lot of back and forth with IBM, it appears that at the V2.4 OS level, IDCAMS does have a memory leak that wouldn’t necessarily be noticed in a typical batch execution. We use Netview automation in our FTP process that calls IDCAMS 10's of thousands of times a week from the Netview address space.We tested this APAR in our non-prod environment, and it does indeed appear to fix the problem. APAR Identifier .. OA59421 Last Changed 20/06/18 MEMORY LEAK WITH IDCAMS REPRO EXECUTION AT 2.4 Symptom .. AB ABEND878 Status ... CLOSED PER Severity ... 3 Date Closed . 20/06/02 Component .. 5695DF103 Duplicate of Reported Release . 240 Fixed Release 999 Component Name ACCESS METHOD S Special Notice Current Target Date ..20/09/30 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 240 : UJ03097 available 20/06/18 (1000 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: At the 2.4 release, every execution of REPRO may leave a block of SP252 Key0 btl user region storage. This becomes an issue when 10's of thousands of REPROs are executed from a single jobstep. This APAR will also address issues with other commands such as DCOLLECT (but not limited to) that uses similar 'AR' control blocks. In the case of DCOLLECT for instance, the orphaned storage is in SP0 Key8. In all cases, orphaned storage will contain similar 'AR' identifiers. | .. | | ..AR.. \ | <- | 8 SA...q...0 | | volser.. | Applications that execute IDCAMS internally such as NETVIEW may experience storage creep without executing 1000s of commands in a single step due to the nature of each individual command orphaning a block at a time. ADDITIONAL SYMPTOMS: IEC340I - IGC0002F, INSUFFICIENT STORAGE FOR THE CATALOG WORKAREA ABENDS106 CATKEYS: IDC2020 IDCABEND IDCREPRO IDCDCOLL LOCAL FIX: BYPASS/CIRCUMVENTION: split REPRO commands into multiple job steps PROBLEM SUMMARY: * USERS AFFECTED: * * All DFSMS users of release V24 and up affect.* * PROBLEM DESCRIPTION: * * When customers executed a large amount of REPRO commands in * * a single job step , for example more than 10's of thousands * * of REPRO commands, the abend106 occurred as results of * * insufficient storage for the catalog workarea. * * The problem occurred because the pool id was assigned* * incorrectly in getting storage to process/retrieve the data * * set information (UIOINFO macro). * * RECOMMENDATION: * PROBLEM CONCLUSION: The problem is solved by assignment of a correct storage pool id. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dave Jousma Sent: Wednesday, May 20, 2020 7:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: REXX assistance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** All, We have some relatively new Netview automation to process inbound FTP processing that is written in REXX, and over time we’ve seen Netview abends with 878’s, etc. IBM indicates we may have a problem below the line, specifically SP0 being exhausted. They are seeing a lot junk that looks like workpack volser’s PCW, temp dataset names, etc. It is my belief that it is the remnants of calling IDCAMS to do our FTP processing to create special dataset catalog entries amongst other stuff and cleanup is not occurring that over time causes our problems. Here is the bit of rexx code I am looking at. Look at how IDCAMS is being called in line 318. I’m not a REXX coding expert by any means. Is that the equivalent of just a standard CALL? Or like entering TSO IDCAMS at a command line in TSO? I’m wondering if there is a better way to call IDCAMS? I see references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM. I’m embarras
Re: REXX assistance
I run some IDCAMS processing under NetView for collecting certain data and have
never seen such a problem. The following are some old examples of the code and
this runs a LISTCAT and puts everything into a stem:
Do i = 1 To dsn.0
lc.1 = ' LISTCAT -' /* LISTCAT SYSIN statements */
lc.2 = 'LVL('dsn.i') -'
lc.3 = 'NONVSAM -'
lc.4 = 'VOLUME '
lc.0 = 4
'PIPE STEM lc.' , /* Run a PIPE with LISTCAT */
'| COLLECT' ,
'| NETV MOE DSIVSMX IDCAMS' ,
'| STEM lvl. APPEND'
End
The following runs DCOLLECT and writes the output to a dataset:
'ALLOCATE DATASET('"'"outpdsn"'"') FILE(OUTDS) OLD'
dc.1 = ' DCOLLECT -'
dc.2 = 'OFILE(OUTDS) -'
dc.3 = 'NODATAINFO -'
dc.4 = 'VOLUME('dasd_type')'
dc.0 = 4
'PIPE STEM dc.' ,
'| COLLECT' ,
'| NETV MOE DSIVSMX IDCAMS' ,
'| STEM vs.'
'FREE DATASET('"'"outpdsn"'"') NOHOLD'
To then read that dataset, I just use the QSAM stage:
'PIPE QSAM (DSN)' outpdsn ,
'| STEM uv.'
Do i = 1 To uv.0
Hopefully this gives some ideas on what to do. I don't use EXECIO in NetView
but the QSAM stage to read datasets so that might be causing your problem.
Sebastian
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ATTCHMVS (was: REXX assistance)
"Was the syntax upward-compatible?" Yes, it was - mostly. My ATTCHJRG command processor was 100% compatible with how you called ATTCHMVS, except it supported one additional parameter: TASKDD(ddname). If you supplied that, then it would pass whatever you had previously allocated to ddname as a TASKLIB on the ATTACH macro call. If you didn't supply TASKDD, then it worked exactly like ATTCHMVS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
Rob,
You sent it to the right place the first time. I thought I responded to it.
At any rate, I've asked IBM if netview will support an ATTCHMVS. We are doing
additional problem identification with tracing, so hopefully that will turn
something up, and we can definitively find the culprit.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Robert Garrett
Sent: Friday, May 22, 2020 10:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FW: REXX assistance
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
Somehow, I managed to send this suggestion to the wrong mailing list a few days
ago – my bad…
Hi Dave,
I've seen that kind of problem before myself invoking various IBM utilities
repeatedly. A lot of them assume that they will always run at the jobstep
level and don't ever freemain their SP0 storage, instead "assuming" step
termination will handle it for them. That can cause problems like the one
you're seeing (if you’re repeatedly calling them from a parent REXX exec). The
solution I've implemented in the past is to invoke those utilities using
ATTCHMVS, which will run then under a new TCB which thus will obtain its own
SP0 storage. When the utility finishes and that TCB gets detached, that
separate SP0 storage will get freemain'ed even if the utility doesn't clean up
after itself, thus avoiding the problem. I also wrote my own custom version
of ATTCHMVS that allowed me to pass a loadlib to be used as a TASKLIB on the
ATTACH. In my case, I was repeatedly invoking the CICS DFHCSDUP utility and
needed to be able to call different releases of it dynamically from the parent
exec.
Try using ATTCHMVS and see if that doesn't solve your problem.
Rob
From: Dave Jousma
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu<mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu>>
Sent: Wed May 20 06:48:49 CDT 2020
To: "IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>"
Subject: REXX assistance
All,
We have some relatively new Netview automation to process inbound FTP
processing that is written in REXX, and over time we’ve seen Netview abends
with 878’s, etc. IBM indicates we may have a problem below the line,
specifically SP0 being exhausted. They are seeing a lot junk that looks like
workpack volser’s PCW, temp dataset names, etc. It is my belief that it
is the remnants of calling IDCAMS to do our FTP processing to create special
dataset catalog entries amongst other stuff and cleanup is not occurring that
over time causes our problems.
Here is the bit of rexx code I am looking at. Look at how IDCAMS is being
called in line 318. I’m not a REXX coding expert by any means. Is that the
equivalent of just a standard CALL? Or like entering TSO IDCAMS at a command
line in TSO? I’m wondering if there is a better way to call IDCAMS? I see
references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM. I’m
embarrassed to say that I do not know the nuances of each of these, and when
appropriate to use. Do any of these create a new environment, do the
function, and then tear the environment down upon exit? It seems like this is
what we need to use to fix this issue.
000308 /* */
000309 /* We have now created all the IDCAMS statements, we now write them*/
000310 /* to our dataset to be used as SYSIN for IDCAMS command */
000311 /* */
000312 Say "Number of Queued Lines is " QueuedLines
000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
000314 /* */
000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
000316 /* after the command as SYSIN and SYSPRINT */
000317 /* */
000318 IDCAMS Infile Outfile
000319 Say "IDCAMS RC for File Rename = " RC
000320 If RC > 4 Then
000321 Do
000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
000323 do xy = 1 to Prtrex.0
000324 Say "Idcams output = " Prtrex.xy
000325 end
000326 end
000327 "free fi("Infile")"
000328 "free fi("Outfile")"
000329
For IBM-MAIN subscribe / signoff / archive access instruct
ATTCHMVS (was: REXX assistance)
On Fri, 22 May 2020 14:07:50 +, Robert Garrett wrote: > >I've seen that kind of problem before myself invoking various IBM utilities >repeatedly. A lot of them assume that they will always run at the jobstep >level and don't ever freemain their SP0 storage, > IBM once REJected my APAR: "Use a bigger virtual machine." >I also wrote my own custom version of ATTCHMVS that allowed me to pass a >loadlib to be used as a TASKLIB on the ATTACH. > Was the syntax upward-compatible? And I've wished for a flavor of ATTCHMVS that would allow the subtask to run concurrently, returning the address of a completion ECB on which the programmer could WAIT. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
Thanks John. I appreciate it. We are working a PMR with IBM Netview support.
We're going to run a getmain/freemain trace specifically of SP0 below the line
to see if we can see a pattern. We've been somewhat "guessing" at the culprit
based on the eye catchers we see in that subpool from the dumps.
Your suggestion is good. I also have asked IBM, but have gotten no response
yet about the difference in syntax calling IDCAMS like this:
000314 /* */
000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
000316 /* after the command as SYSIN and SYSPRINT */
000317 /* */
000318 IDCAMS Infile Outfile
000319 Say "IDCAMS RC for File Rename = " RC
Or from this Netview Sample. I get the entire PIPE portion of all this, but my
question is specifically calling idcams as NETV MOE DSIVSMX IDCAMS
SAY 'Attempting to define the VSAM file'basename
k.0 = 14
k.1 = ' DEFINE CLUSTER -'
k.2 = ' (NAME ('basename') -'
k.3 = ' INDEXED -'
k.4 = ' KEYS('key_size RKP') -'
k.5 = ' SHAREOPTIONS('shr1 shr2') -'
k.6 = ' RECORDSIZE('avg_recsize max_recsize') -'
k.7 = ' VOLUMES(CPDLB2) -'
k.8 = ' NOREUSE ) -'
k.9 = ' DATA -'
k.10 = ' (NAME ('basename'.DATA) -'
k.11 = ' CYLINDERS('data_size') ) -'
k.12 = ' INDEX -'
k.13 = ' (NAME ('basename'.INDEX) -'
k.14 = ' CYLINDERS('index_size') )'
'PIPE STEM k.|COLLECT|NETV MOE DSIVSMX IDCAMS|STEM R1.'
Define_rc = 4;
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
John S. Giltner, Jr.
Sent: Friday, May 22, 2020 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
As others have pointed out "IDCAMS" is a NetView command that calls IDCAMS.
The original intent was to allow you to automate maintenance of the VSAM files
that NetView uses without bringing down NetView. However I sure that others,
like you and me, have found other purposes for it.
We also use it for inbound file transfer automation to rename the files so they
have date/time stamps. I have never experienced 878 abends, but that could be
due to the number of times it is called. We now have FTP exits that add the
date/time stamps when the file is created the majority of the time instead of
after the transfer ends. So end up not doing renames calling IDCAMS that much.
From NetView I don't know of another way to call IDCAMS, the only thing I can
think of would be to change your automation so that instead of calling IDCAMS
directly from NetView is to create a file with the control statements you need
and then submit either a batch job or run it as a separate started task
pointing to the file with the control statements. I think somebody else
suggested this also.
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL
EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: REXX assistance
Somehow, I managed to send this suggestion to the wrong mailing list a few days
ago – my bad…
Hi Dave,
I've seen that kind of problem before myself invoking various IBM utilities
repeatedly. A lot of them assume that they will always run at the jobstep
level and don't ever freemain their SP0 storage, instead "assuming" step
termination will handle it for them. That can cause problems like the one
you're seeing (if you’re repeatedly calling them from a parent REXX exec). The
solution I've implemented in the past is to invoke those utilities using
ATTCHMVS, which will run then under a new TCB which thus will obtain its own
SP0 storage. When the utility finishes and that TCB gets detached, that
separate SP0 storage will get freemain'ed even if the utility doesn't clean up
after itself, thus avoiding the problem. I also wrote my own custom version
of ATTCHMVS that allowed me to pass a loadlib to be used as a TASKLIB on the
ATTACH. In my case, I was repeatedly invoking the CICS DFHCSDUP utility and
needed to be able to call different releases of it dynamically from the parent
exec.
Try using ATTCHMVS and see if that doesn't solve your problem.
Rob
From: Dave Jousma
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu<mailto:01a0403c5dc1-dmarc-requ...@listserv.ua.edu>>
Sent: Wed May 20 06:48:49 CDT 2020
To: "IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>"
Subject: REXX assistance
All,
We have some relatively new Netview automation to process inbound FTP
processing that is written in REXX, and over time we’ve seen Netview abends
with 878’s, etc. IBM indicates we may have a problem below the line,
specifically SP0 being exhausted. They are seeing a lot junk that looks like
workpack volser’s PCW, temp dataset names, etc. It is my belief that it
is the remnants of calling IDCAMS to do our FTP processing to create special
dataset catalog entries amongst other stuff and cleanup is not occurring that
over time causes our problems.
Here is the bit of rexx code I am looking at. Look at how IDCAMS is being
called in line 318. I’m not a REXX coding expert by any means. Is that the
equivalent of just a standard CALL? Or like entering TSO IDCAMS at a command
line in TSO? I’m wondering if there is a better way to call IDCAMS? I see
references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM. I’m
embarrassed to say that I do not know the nuances of each of these, and when
appropriate to use. Do any of these create a new environment, do the
function, and then tear the environment down upon exit? It seems like this is
what we need to use to fix this issue.
000308 /* */
000309 /* We have now created all the IDCAMS statements, we now write them*/
000310 /* to our dataset to be used as SYSIN for IDCAMS command */
000311 /* */
000312 Say "Number of Queued Lines is " QueuedLines
000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
000314 /* */
000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
000316 /* after the command as SYSIN and SYSPRINT */
000317 /* */
000318 IDCAMS Infile Outfile
000319 Say "IDCAMS RC for File Rename = " RC
000320 If RC > 4 Then
000321 Do
000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
000323 do xy = 1 to Prtrex.0
000324 Say "Idcams output = " Prtrex.xy
000325 end
000326 end
000327 "free fi("Infile")"
000328 "free fi("Outfile")"
000329
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with
the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
As others have pointed out "IDCAMS" is a NetView command that calls IDCAMS. The original intent was to allow you to automate maintenance of the VSAM files that NetView uses without bringing down NetView. However I sure that others, like you and me, have found other purposes for it. We also use it for inbound file transfer automation to rename the files so they have date/time stamps. I have never experienced 878 abends, but that could be due to the number of times it is called. We now have FTP exits that add the date/time stamps when the file is created the majority of the time instead of after the transfer ends. So end up not doing renames calling IDCAMS that much. From NetView I don't know of another way to call IDCAMS, the only thing I can think of would be to change your automation so that instead of calling IDCAMS directly from NetView is to create a file with the control statements you need and then submit either a batch job or run it as a separate started task pointing to the file with the control statements. I think somebody else suggested this also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
It looks like the Netview IDCAMS command accepts at most two parameters
that must be DDNAMEs. The second DDNAME will default to SYSPRINT if not
specified. The DDNAMEs are basically INPUT and OUTPUT files. So the INPUT file
must be built prior to invoking the Netview IDCAMS command.
The DSIVSMX IDCAMS command also calls the IDCAMS utility, but the
IDCAMS control statements are read from the message that started the DSIVSMX
command. This is more conducive to being used within a PIPE with a STEM
variable as the input stream.
The Netview help for DSIVSMX IDCAMS (Option F) references those same
Netview samples; CNMS8013, CNMS8014, CNMS8015 and CNMS8020.
Also, the groups.io group or Netview can be found here:
https://groups.io/g/NetView
Hth
Tony
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Jousma, David
Sent: Wednesday, May 20, 2020 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
Thanks Tony. I see that IDCAMS used within netview is a valid netview command.
But then I see this in the netview samplib
Define_Base_Cluster_VSAM_File:
/* Called by Define_and_Load_Base_Cluster*/
SAY 'Attempting to define the VSAM file'basename
k.0 = 14
k.1 = ' DEFINE CLUSTER -'
k.2 = ' (NAME ('basename') -'
k.3 = ' INDEXED -'
k.4 = ' KEYS('key_size RKP') -'
k.5 = ' SHAREOPTIONS('shr1 shr2') -'
k.6 = ' RECORDSIZE('avg_recsize max_recsize') -'
k.7 = ' VOLUMES(CPDLB2) -'
k.8 = ' NOREUSE ) -'
k.9 = ' DATA -'
k.10 = ' (NAME ('basename'.DATA) -'
k.11 = ' CYLINDERS('data_size') ) -'
k.12 = ' INDEX -'
k.13 = ' (NAME ('basename'.INDEX) -'
k.14 = ' CYLINDERS('index_size') )'
'PIPE STEM k.|COLLECT|NETV MOE DSIVSMX IDCAMS|STEM R1.'
What purpose is the last line, specifically the NETV MOE DSIVSMX IDCAMS
portion? Why not just NETV MOE IDCAMS?According to the fine manual
DSIVSMX is labelled as a "command processor". Does that imply setting up an
environment? I've asked IBM these questions too.
IBM Tivoli NetView for z/OS, Version 6.2 The DSIVSMX command processor can
define, read, and write VSAM keyed files directly from REXX without using data
services tasks. This enables the implementation of VSAM applications, including
end-use application development in REXX (in conjunction with the pipeline
facility), and intensive VSAM diagnostics.
The DSIVSMX command provides REXX access to keyed VSAM files and to IDCAMS, the
VSAM Access Method Services utility.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Cieri, Anthony
Sent: Wednesday, May 20, 2020 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
In this instance the IDCAMS command represents a NETVIEW command:
CMDDEF.IDCAMS.MOD=DSIDCAMS
CMDDEF.IDCAMS.FOLDUP=Y
DISPMOD DSIDCAMS
CNM263I MODULE LENGTH CSECTDATE PTF EPA AM ATTR
CNM263I DSIDCAMS 000570 DSIDCAMS 05/30/14 --- 000291B0 24 RN RU
CNM265I END OF DISPLAY
In my example, I am running Netview V6.2.1. I believe that the intent
here was to provide a method for Netview to runs IDCAMS "maintenance" functions
on the various Netview Databases; NLDM, NPDA, TARA etc, without the need to
recycle the Netview tasks. I do use them for such maintenance, but they run
infrequently.
I don't claim to understand the relationship/difference between using
the Netview IDCAMS command and the TSO or batch flavor, but it likely that the
storage issue is related to how Netview invokes IDCAMS.
It might be help to route this question/issue to the Net
Re: REXX assistance
Thanks Tony. I see that IDCAMS used within netview is a valid netview command.
But then I see this in the netview samplib
Define_Base_Cluster_VSAM_File:
/* Called by Define_and_Load_Base_Cluster*/
SAY 'Attempting to define the VSAM file'basename
k.0 = 14
k.1 = ' DEFINE CLUSTER -'
k.2 = ' (NAME ('basename') -'
k.3 = ' INDEXED -'
k.4 = ' KEYS('key_size RKP') -'
k.5 = ' SHAREOPTIONS('shr1 shr2') -'
k.6 = ' RECORDSIZE('avg_recsize max_recsize') -'
k.7 = ' VOLUMES(CPDLB2) -'
k.8 = ' NOREUSE ) -'
k.9 = ' DATA -'
k.10 = ' (NAME ('basename'.DATA) -'
k.11 = ' CYLINDERS('data_size') ) -'
k.12 = ' INDEX -'
k.13 = ' (NAME ('basename'.INDEX) -'
k.14 = ' CYLINDERS('index_size') )'
'PIPE STEM k.|COLLECT|NETV MOE DSIVSMX IDCAMS|STEM R1.'
What purpose is the last line, specifically the NETV MOE DSIVSMX IDCAMS
portion? Why not just NETV MOE IDCAMS?According to the fine manual
DSIVSMX is labelled as a "command processor". Does that imply setting up an
environment? I've asked IBM these questions too.
IBM Tivoli NetView for z/OS, Version 6.2
The DSIVSMX command processor can define, read, and write VSAM keyed files
directly from REXX without using data services tasks. This enables the
implementation of VSAM applications, including end-use application development
in REXX (in conjunction with the pipeline facility), and intensive VSAM
diagnostics.
The DSIVSMX command provides REXX access to keyed VSAM files and to IDCAMS, the
VSAM Access Method Services utility.
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Cieri, Anthony
Sent: Wednesday, May 20, 2020 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
**CAUTION EXTERNAL EMAIL**
**DO NOT open attachments or click on links from unknown senders or unexpected
emails**
In this instance the IDCAMS command represents a NETVIEW command:
CMDDEF.IDCAMS.MOD=DSIDCAMS
CMDDEF.IDCAMS.FOLDUP=Y
DISPMOD DSIDCAMS
CNM263I MODULE LENGTH CSECTDATE PTF EPA AM ATTR
CNM263I DSIDCAMS 000570 DSIDCAMS 05/30/14 --- 000291B0 24 RN RU
CNM265I END OF DISPLAY
In my example, I am running Netview V6.2.1. I believe that the intent
here was to provide a method for Netview to runs IDCAMS "maintenance" functions
on the various Netview Databases; NLDM, NPDA, TARA etc, without the need to
recycle the Netview tasks. I do use them for such maintenance, but they run
infrequently.
I don't claim to understand the relationship/difference between using
the Netview IDCAMS command and the TSO or batch flavor, but it likely that the
storage issue is related to how Netview invokes IDCAMS.
It might be help to route this question/issue to the Netview users
group. I believe that they are at Groups.io.
Hth
Tony
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Wednesday, May 20, 2020 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote:
>All,
>...
In a JCL example in
https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zdatamgmt/zsysprogc_utilities_IDCAMS.htm
I see:
//SYSPRINT DD *
Is that probably what the writer intended? Is it even legal?
Writers should hand their examples back to coders for review and testing.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instruct
Re: REXX assistance
David, I would, IMHO , check the region= and make sure the main task for Netview and sub tasks. A dump also provide insight into the offending module. I would also check maintenance against Netview. Eileen is correct Profile high is usually TSO rexx , been through this several times. The Rexx internal buffer space is not unlimited, you could ask for another buffer, I.e.; Makebuf equivalent. HTH, Scott On Wed, May 20, 2020 at 1:02 PM Cieri, Anthony < 02d7f4ec1fff-dmarc-requ...@listserv.ua.edu> wrote: > > In this instance the IDCAMS command represents a NETVIEW command: > > CMDDEF.IDCAMS.MOD=DSIDCAMS > CMDDEF.IDCAMS.FOLDUP=Y > > DISPMOD DSIDCAMS > > CNM263I MODULE LENGTH CSECTDATE PTF EPA AM > ATTR > CNM263I DSIDCAMS 000570 DSIDCAMS 05/30/14 --- 000291B0 24 RN > RU > CNM265I END OF DISPLAY > > In my example, I am running Netview V6.2.1. I believe that the > intent here was to provide a method for Netview to runs IDCAMS > "maintenance" functions on the various Netview Databases; NLDM, NPDA, TARA > etc, without the need to recycle the Netview tasks. I do use them for such > maintenance, but they run infrequently. > > I don't claim to understand the relationship/difference between > using the Netview IDCAMS command and the TSO or batch flavor, but it likely > that the storage issue is related to how Netview invokes IDCAMS. > > It might be help to route this question/issue to the Netview users > group. I believe that they are at Groups.io. > > Hth > Tony > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Paul Gilmartin > Sent: Wednesday, May 20, 2020 12:26 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX assistance > > [[ SEI WARNING *** This email was sent from an external source. Do not > open attachments or click on links from unknown or suspicious senders. *** > ]] > > > On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote: > > >All, > >... > In a JCL example in > > https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zdatamgmt/zsysprogc_utilities_IDCAMS.htm > I see: > //SYSPRINT DD * > > Is that probably what the writer intended? Is it even legal? > Writers should hand their examples back to coders for review and testing. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
In this instance the IDCAMS command represents a NETVIEW command: CMDDEF.IDCAMS.MOD=DSIDCAMS CMDDEF.IDCAMS.FOLDUP=Y DISPMOD DSIDCAMS CNM263I MODULE LENGTH CSECTDATE PTF EPA AM ATTR CNM263I DSIDCAMS 000570 DSIDCAMS 05/30/14 --- 000291B0 24 RN RU CNM265I END OF DISPLAY In my example, I am running Netview V6.2.1. I believe that the intent here was to provide a method for Netview to runs IDCAMS "maintenance" functions on the various Netview Databases; NLDM, NPDA, TARA etc, without the need to recycle the Netview tasks. I do use them for such maintenance, but they run infrequently. I don't claim to understand the relationship/difference between using the Netview IDCAMS command and the TSO or batch flavor, but it likely that the storage issue is related to how Netview invokes IDCAMS. It might be help to route this question/issue to the Netview users group. I believe that they are at Groups.io. Hth Tony -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Wednesday, May 20, 2020 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX assistance [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote: >All, >... In a JCL example in https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zdatamgmt/zsysprogc_utilities_IDCAMS.htm I see: //SYSPRINT DD * Is that probably what the writer intended? Is it even legal? Writers should hand their examples back to coders for review and testing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
> I've found no use for ADDRESS LINK/ATTACH. They seem to be
relics of Rexx's gestation under CMS.
I doubt it. It doesn't look like either the CMS tokenized parameter list or the
CMS extended parameter list.
> IIRC, they use R0 as a parameter register.
Passing the address of the ENVBLOCK in R0 is pervasive in REXX. In particular,
REXX also passes the ENVBLOCK in R0 when calling commands in the ATTACHMVS and
LINKMVS environments.
> ADDRESS LINKMVS/ATTCHMVS are similar, but Rexx automatically supplies the
> length prefix.
Prefixes. They seem tailored to calling language processors and utilities,
which include halfword lengths at the beginnings of, e.g., ddname lists.
> Sigh. "IDCAMS" appears to be an implied string literal while context implies
> that "Infile" and "outfile" are Rexx variables.
Bog standard, and perfectly readable, especially if you adopt the convention of
putting the names of uninitialized variables in upper case. I see no value in
novalue.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, May 20, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote:
>All,
>
>We have some relatively new Netview automation to process inbound FTP
>processing that is written in REXX,
>
ITschak or Eileen can surely give you better information about
TSO, IDCAMS, and Netview than I. But I know some Rexx.
>Look at how IDCAMS is being called in line 318. ... Is that the equivalent of
>just a standard CALL? Or like entering TSO IDCAMS at a command line in TSO?
>
I believe it's the eqivalent of entering "IDCAMS ..." on the
TSO command line (READY prompt). I believe I've encountered
errors entering such as "TSO IDCAMS ..." as a TSO command.
I find neither TSO nor IDCAMS in the TSO Command Ref.
> ... I see references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM.
>
I've found no use for ADDRESS LINK/ATTACH. They seem to be
relics of Rexx's gestation under CMS. IIRC, they use R0 as a parameter
register. ADDRESS LINKPGM/ATTCHPGM are similar to their Assembler
macro counterparts. The caller is expected to supply a 16-bit length
prefix if the function called requires it. ADDRESS LINKMVS/ATTCHMVS
are similar, but Rexx automatically supplies the length prefix.
>000309 /* We have now created all the IDCAMS statements, we now write them*/
>000310 /* to our dataset to be used as SYSIN for IDCAMS command */
>000311 /* */
>000312 Say "Number of Queued Lines is " QueuedLines
>000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
>000314 /* */
>000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
>000316 /* after the command as SYSIN and SYSPRINT */
>000317 /* */
>000318 IDCAMS Infile Outfile
>
Sigh. "IDCAMS" appears to be an implied string literal while context implies
that "Infile" and "outfile" are Rexx variables.
The coder could have clarified this enormously with
signal on novalue
SaveTrace = trace( 'R' )
"IDCAMS" Infile Outfile
call trace( SaveTrace )
>000319 Say "IDCAMS RC for File Rename = " RC
>000320 If RC > 4 Then
>000321 Do
>000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
>000323 do xy = 1 to Prtrex.0
>000324 Say "Idcams output = " Prtrex.xy
>000325 end
>000326 end
>000327 "free fi("Infile")"
>000328 "free fi("Outfile")"
>000329
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote: >All, >... In a JCL example in https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zdatamgmt/zsysprogc_utilities_IDCAMS.htm I see: //SYSPRINT DD * Is that probably what the writer intended? Is it even legal? Writers should hand their examples back to coders for review and testing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
On Wed, 20 May 2020 06:45:57 -0500, Dave Jousma wrote:
>All,
>
>We have some relatively new Netview automation to process inbound FTP
>processing that is written in REXX,
>
ITschak or Eileen can surely give you better information about
TSO, IDCAMS, and Netview than I. But I know some Rexx.
>Look at how IDCAMS is being called in line 318. ... Is that the equivalent of
>just a standard CALL? Or like entering TSO IDCAMS at a command line in TSO?
>
I believe it's the eqivalent of entering "IDCAMS ..." on the
TSO command line (READY prompt). I believe I've encountered
errors entering such as "TSO IDCAMS ..." as a TSO command.
I find neither TSO nor IDCAMS in the TSO Command Ref.
> ... I see references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM.
>
>
I've found no use for ADDRESS LINK/ATTACH. They seem to be
relics of Rexx's gestation under CMS. IIRC, they use R0 as a parameter
register. ADDRESS LINKPGM/ATTCHPGM are similar to their Assembler
macro counterparts. The caller is expected to supply a 16-bit length
prefix if the function called requires it. ADDRESS LINKMVS/ATTCHMVS
are similar, but Rexx automatically supplies the length prefix.
>000309 /* We have now created all the IDCAMS statements, we now write them*/
>000310 /* to our dataset to be used as SYSIN for IDCAMS command */
>000311 /* */
>000312 Say "Number of Queued Lines is " QueuedLines
>000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
>000314 /* */
>000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
>000316 /* after the command as SYSIN and SYSPRINT */
>000317 /* */
>000318 IDCAMS Infile Outfile
>
Sigh. "IDCAMS" appears to be an implied string literal while context implies
that "Infile" and "outfile" are Rexx variables.
The coder could have clarified this enormously with
signal on novalue
SaveTrace = trace( 'R' )
"IDCAMS" Infile Outfile
call trace( SaveTrace )
>000319 Say "IDCAMS RC for File Rename = " RC
>000320 If RC > 4 Then
>000321 Do
>000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
>000323 do xy = 1 to Prtrex.0
>000324 Say "Idcams output = " Prtrex.xy
>000325 end
>000326 end
>000327 "free fi("Infile")"
>000328 "free fi("Outfile")"
>000329
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
Is not PROF for TSO, not Netview? The 878 abend is occurring in Netview.
You can just use Netview to automate the starting of a procedure to run
directly under TSO.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
ITschak Mugzach
Sent: Wednesday, May 20, 2020 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX assistance
It's simple. use "PROF VARSTORAGE(HIGH)" to direct EXECIO and other getmains
above the line.
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for
z/OS, x/Linux & IBM I **| z/VM comming son *
On Wed, May 20, 2020 at 2:46 PM Dave Jousma <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> All,
>
> We have some relatively new Netview automation to process inbound FTP
> processing that is written in REXX, and over time we’ve seen Netview abends
> with 878’s, etc. IBM indicates we may have a problem below the line,
> specifically SP0 being exhausted. They are seeing a lot junk that looks
> like workpack volser’s PCW, temp dataset names, etc. It is my belief
> that it is the remnants of calling IDCAMS to do our FTP processing to
> create special dataset catalog entries amongst other stuff and cleanup
> is not occurring that over time causes our problems.
>
> Here is the bit of rexx code I am looking at. Look at how IDCAMS is
> being called in line 318. I’m not a REXX coding expert by any means.
> Is that the equivalent of just a standard CALL? Or like entering TSO
> IDCAMS at a command line in TSO? I’m wondering if there is a better way to
> call
> IDCAMS? I see references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM,
> ATTCHPGM. I’m embarrassed to say that I do not know the nuances of each of
> these, and when appropriate to use. Do any of these create a new
> environment, do the function, and then tear the environment down upon
> exit? It seems like this is what we need to use to fix this issue.
>
> 000308 /*
> */
> 000309 /* We have now created all the IDCAMS statements, we now write
> them*/
> 000310 /* to our dataset to be used as SYSIN for IDCAMS command */
> 000311 /*
> */
> 000312 Say "Number of Queued Lines is " QueuedLines
>
> 000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
>
> 000314 /*
> */
> 000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names
> listed */
> 000316 /* after the command as SYSIN and SYSPRINT */
> 000317 /*
> */
> 000318 IDCAMS Infile Outfile
>
> 000319 Say "IDCAMS RC for File Rename = " RC
>
> 000320 If RC > 4 Then
>
> 000321 Do
>
> 000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex.
> FINIS'
> 000323 do xy = 1 to Prtrex.0
>
> 000324 Say "Idcams output = " Prtrex.xy
>
> 000325 end
>
> 000326 end
>
> 000327 "free fi("Infile")"
>
> 000328 "free fi("Outfile")"
>
> 000329
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail, including any attachments, may be confidential, privileged or
otherwise legally protected. It is intended only for the addressee. If you
received this e-mail in error or from someone who was not authorized to send it
to you, do not disseminate, copy or otherwise use this e-mail or its
attachments. Please notify the sender immediately by reply e-mail and delete
the e-mail from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX assistance
It's simple. use "PROF VARSTORAGE(HIGH)" to direct EXECIO and other
getmains above the line.
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son *
On Wed, May 20, 2020 at 2:46 PM Dave Jousma <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> All,
>
> We have some relatively new Netview automation to process inbound FTP
> processing that is written in REXX, and over time we’ve seen Netview abends
> with 878’s, etc. IBM indicates we may have a problem below the line,
> specifically SP0 being exhausted. They are seeing a lot junk that looks
> like workpack volser’s PCW, temp dataset names, etc. It is my belief
> that it is the remnants of calling IDCAMS to do our FTP processing to
> create special dataset catalog entries amongst other stuff and cleanup is
> not occurring that over time causes our problems.
>
> Here is the bit of rexx code I am looking at. Look at how IDCAMS is
> being called in line 318. I’m not a REXX coding expert by any means. Is
> that the equivalent of just a standard CALL? Or like entering TSO IDCAMS at
> a command line in TSO? I’m wondering if there is a better way to call
> IDCAMS? I see references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM,
> ATTCHPGM. I’m embarrassed to say that I do not know the nuances of each of
> these, and when appropriate to use. Do any of these create a new
> environment, do the function, and then tear the environment down upon
> exit? It seems like this is what we need to use to fix this issue.
>
> 000308 /*
> */
> 000309 /* We have now created all the IDCAMS statements, we now write
> them*/
> 000310 /* to our dataset to be used as SYSIN for IDCAMS command
> */
> 000311 /*
> */
> 000312 Say "Number of Queued Lines is " QueuedLines
>
> 000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
>
> 000314 /*
> */
> 000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed
> */
> 000316 /* after the command as SYSIN and SYSPRINT
> */
> 000317 /*
> */
> 000318 IDCAMS Infile Outfile
>
> 000319 Say "IDCAMS RC for File Rename = " RC
>
> 000320 If RC > 4 Then
>
> 000321 Do
>
> 000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex.
> FINIS'
> 000323 do xy = 1 to Prtrex.0
>
> 000324 Say "Idcams output = " Prtrex.xy
>
> 000325 end
>
> 000326 end
>
> 000327 "free fi("Infile")"
>
> 000328 "free fi("Outfile")"
>
> 000329
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
REXX assistance
All,
We have some relatively new Netview automation to process inbound FTP
processing that is written in REXX, and over time we’ve seen Netview abends
with 878’s, etc. IBM indicates we may have a problem below the line,
specifically SP0 being exhausted. They are seeing a lot junk that looks like
workpack volser’s PCW, temp dataset names, etc. It is my belief that it
is the remnants of calling IDCAMS to do our FTP processing to create special
dataset catalog entries amongst other stuff and cleanup is not occurring that
over time causes our problems.
Here is the bit of rexx code I am looking at. Look at how IDCAMS is being
called in line 318. I’m not a REXX coding expert by any means. Is that the
equivalent of just a standard CALL? Or like entering TSO IDCAMS at a command
line in TSO? I’m wondering if there is a better way to call IDCAMS? I see
references to LINK, ATTACH, LINKMVS, ATTCHMVS, LINKPGM, ATTCHPGM. I’m
embarrassed to say that I do not know the nuances of each of these, and when
appropriate to use. Do any of these create a new environment, do the
function, and then tear the environment down upon exit? It seems like this is
what we need to use to fix this issue.
000308 /* */
000309 /* We have now created all the IDCAMS statements, we now write them*/
000310 /* to our dataset to be used as SYSIN for IDCAMS command */
000311 /* */
000312 Say "Number of Queued Lines is " QueuedLines
000313 Address MVS 'EXECIO 'QueuedLines' DISKW 'Infile' (FINIS'
000314 /* */
000315 /* The IDCAMS statement calls IDCAMS using the 2 DD names listed */
000316 /* after the command as SYSIN and SYSPRINT */
000317 /* */
000318 IDCAMS Infile Outfile
000319 Say "IDCAMS RC for File Rename = " RC
000320 If RC > 4 Then
000321 Do
000322 Address MVS 'EXECIO * DISKR 'Outfile' (STEM Prtrex. FINIS'
000323 do xy = 1 to Prtrex.0
000324 Say "Idcams output = " Prtrex.xy
000325 end
000326 end
000327 "free fi("Infile")"
000328 "free fi("Outfile")"
000329
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
