Re: CA OPS/MVS
If you don't mind, please forward them to me. I do work with CA customers and would be interested in what you have Thanks Gerhard -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter X. DeFabritus Sent: Friday, March 29, 2019 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA OPS/MVS I would prefer to send an individual email of the files to anyone who wants this function. -- 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: CA OPS/MVS
I would prefer to send an individual email of the files to anyone who wants this function. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA OPS/MVS
Peter, Is this something you would consider sharing with a larger audience??? I know that we routinely change LPAR weighs at our shop, but we use a manual process. Thanks Tony -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter DeFabritus Sent: Thursday, March 28, 2019 1:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA OPS/MVS [[ SEI WARNING *** This email was sent from an external source. Do not open attachments or click on links from unknown or suspicious senders. *** ]] Martin, I have a REXX EXEC that uses BCPii, not OPS/MVS, to dynamically modify the weights for LPARs, if you'd like it. On Thu, Mar 28, 2019 at 12:27 PM Steve Horein wrote: > I was just comparing OPS/MVS (what I grew up on): > > https://docops.ca.com/ca-opsmvs/12-3/en/administrating/manage-the-processors/opshmc-parameters > > ...with System Automation for z/OS (what I support now): > > https://www.ibm.com/support/knowledgecenter/SSWRCJ_4.1.0/com.ibm.safos.doc_4.1/OperatorGuide/ICNTL.html?pos=2 > > > OPS/MVS appears to provide getAttribute and setAttribute functions that may > allow you to do what you want. > > On Thu, Mar 28, 2019 at 10:43 AM Martin Packer > wrote: > > > I'm asking on behalf of a customer (but I want to know, too, for all the > > right reasons): > > > > Is it possible with CA OPS/MVS to alter the weights for LPARs? I would > > assume that if it could it would use BCPii. > > > > The background is that we are contemplating shifting weights between > LPARs > > at certain times of day. This is their automation tool of choice. And I > > don't know how people alter weights through automation. > > > > Thanks, Martin > > > > Martin Packer > > > > zChampion, Systems Investigator & Performance Troubleshooter, IBM > > > > +44-7802-245-584 > > > > email: martin_pac...@uk.ibm.com > > > > Twitter / Facebook IDs: MartinPacker > > > > Blog: > > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > > > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/ > > or > > > > > > > https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 > > > > > > Youtube channel: > https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU > > > > -- > > 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 > -- 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: Remote access to Z14 ZR1 Support Element via HMC question
OK. I think we are making progress but I am not sure what the sysprogs are doing - seems to be suck it and see. We can now access the SE using SOO but we don't have the right credentials - appear to be just operators which isn't any good if we want to activate CBU's in a DR exercise. I suspect they didn't actually create the right accounts for us. I still think the HMC setup is not quite right. On OSA-ICC we could get to logon screens but go no further (session not bound or something). In an inspiration we snuck a look at SYS1.VTAMLST( MAJNODE) and it didn't look right in that the definitions for devices on the new Z14 didn't resemble existing zBC12 definitions. Since we are effectively outsourced, we cannot update this but I think one of our techs might have asked a casual question why the difference and a few hours later, lo and behold OSA-ICC started to work! No explanations yet but one could say, why argue with success! Export and import would have been much cleaner but I wonder if our support team have never had to do a skip release (12 to 14) and relied on the HMC's to copy information across when the Z14 is so much different and needs either a completely new OSA-ICC setup or export and import as you say, On Thu, Mar 28, 2019 at 8:13 PM Ravi Gaur wrote: > We recently moved to z14 and I exported the OSA-ICC existing configuration > via FTP to mainframe USS as below. > > Exporting OSA-ICC configuration file using OSA Advanced Facilities. > > To export the OSA-ICC configuration file, follow these steps: > > 1. Log on to the HMC, select the CPC you want to operate, and open the OSA > Advanced > Facility. > 2. Select the OSC CHPID to export the OSA-ICC configuration file. Next, > select Card > specific advanced facilities. Select Manual configuration options and > click OK > 3. The Manual Configuration Options window opens as below . Select Export > source > file and click OK. > 4. The task requests that hostname/username and mainframe Password is > entered with Unix file system to get the configuration in the USS > 6. The HMC displays the ACT2042 window (. Click OK. > 7. On Mainframe in USS you can see File should have been exported at the > given path. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
On Fri, 29 Mar 2019, at 17:29, Paul Gilmartin wrote: > On Fri, 29 Mar 2019 12:56:59 -0400, Jeremy Nicoll wrote: > > > >In the calling exec the rc from the (ispf) edit would be checked, because > >invoking edit might have failed, eg because of spfdsn enqueues on the > >target file. In the 'production' systems I wrote the execs usually then > >slept for a few seconds, then tried again (when they were part of the > >batch jobs). If the edit was something invoked from an ispf dialog run > >in the foreground, the dialog might have told the user to try again (as > >they'd probably already have seen a line-mode dataset contention > >message). > > > I have, on occasion, added a final step, IEFBR14,COND=(0,LE) with > a DD DISP=SHR for any such data set so my job would be held by > the initiator until the data sets were available. > > (Always JES2) One system had a PDS containing members each of which were requests for something for a specific day. Different users could (via the dialogs) append more requests into a particular day's member even while a batch job had been demanded (via CA7) to deal with those requests. Right up to the point where the batch job actually began to process requests more could be added. And, if for some reason the batch job abended and went through restart, it would subsequently deal with more requests added to that same member in the interim period (ie while the data files, usually recalled from ML2, were still available for immediate use). It wasn't practical to prevent access to these 'sysin' members while the jobs using them ran. IIRC the running jobs also updated the members with state info about the results of running the jobs, eg locations in the sysout database [SAR] where individual users' results had actually been placed. I can't quite remember if the dialogs I'd written also front- ended extraction of reports from SAR so they needn't be printed (as had previously been the case) to the users' locations. In a different system I wrote, the front-end dialogs set up parameters for much more rarely-run batch jobs, but the process of parm setup then authorising a run of such a job renamed the parameter file (as did other steps like CA-7 demanding the relevant batch job started, using SA/390 to track that specific job's progress/abend/restart etc.) The renames of these files allowed us to control who (users, or schedulers/ops, or SA/390's auto-ops etc) could transition each such job through its different states. (This latter system also ran started tasks as part of the overall control. It was quite complicated...) -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
On Fri, 29 Mar 2019 12:56:59 -0400, Jeremy Nicoll wrote: > >In the calling exec the rc from the (ispf) edit would be checked, because >invoking edit might have failed, eg because of spfdsn enqueues on the >target file. In the 'production' systems I wrote the execs usually then >slept for a few seconds, then tried again (when they were part of the >batch jobs). If the edit was something invoked from an ispf dialog run >in the foreground, the dialog might have told the user to try again (as >they'd probably already have seen a line-mode dataset contention >message). > I have, on occasion, added a final step, IEFBR14,COND=(0,LE) with a DD DISP=SHR for any such data set so my job would be held by the initiator until the data sets were available. (Always JES2) In one instance the effect was disastrous -- it created an uncatalogued instance of the DSN on every storage volume. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
On Fri, 29 Mar 2019, at 16:02, Paul Gilmartin wrote: > Neat! I never became proficient with the ISPF variable pool. > > Is there any restriction on the content of ISPF variables? Special > characters? Length? > Can they be delimited strings, subject to the design deficiencies of > delimited strings? I'm sorry, it's been 20 years since I did any of this, and even if I could remember the limitations then, they might have changed. I should have added earlier that I usually used the same vput/vget method to pass flags and/or extracted data back from the macro to a calling exec. My macros would typically issue "builtin save" if a file had to be modified by the macro, then continue to test the rc from the save, do the necessary vput(s), and finally "builtin cancel" to end the edit session. In the calling exec the rc from the (ispf) edit would be checked, because invoking edit might have failed, eg because of spfdsn enqueues on the target file. In the 'production' systems I wrote the execs usually then slept for a few seconds, then tried again (when they were part of the batch jobs). If the edit was something invoked from an ispf dialog run in the foreground, the dialog might have told the user to try again (as they'd probably already have seen a line-mode dataset contention message). Then (if invoking edit had worked) the exec would vget the vars setup by the macro and analyse those to find out if the macro had worked. (Sometimes, those vars that should have been created by this run of a macro, would have been preloaded with "it didn't work" values, in the exec before I called edit.) I don't (at home, 20 years on...) have any examples of the typical 'production code' versions of any of these, unfortunately. -- Jeremy Nicoll - my opinions are my own. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF edit macro behaivor in SDSF
Thanks Rob, the top of my rexx is basically the same as your test and seemed to behave the same as mine. But your suggestion prodded me in the right direction to an explanation of whats going on. What I discovered, is in the PFKey settings used in SDSF EDIT, 'ISF Keylist ISFEDKEY' I had the PFkeys set to: PF22 . . ;CA E PF23 . . ;CA V Once I removed the ';' from the beginning of the command all is well and working correctly. I thought at one time, the prefix ';' was needed on a pfkey to simulate the command preserving the cursor position, but apparently that isn't needed any more. Seems like it was initially needed for the QW clist to allow point and shoot at message numbers. Further, I don't find any reference to the prefix ';' in ISPF User's Guide Vol II. The only special characters shown there are ':' and '>'.Could this have changed sometime in the last (cough cough) years? Dana On Fri, 29 Mar 2019 14:07:12 +, Rob Scott wrote: > >I would double-check your REXX exec code - perhaps paste to the forum? > >"SE" and "SJ" use ISPF "EDIF" services - pretty much all SDSF does is supply >the data for the "get first/next" record request from EDIF. > >I have just executed the following simple REXX EDIT macro in SDSF SJ and SE in >2.2 and 2.3 and the results were as expected: > >address ISREDIT "MACRO" >address ISREDIT "(CURROW CURCOL) = CURSOR " >address ISREDIT "(CURLINE) = LINE "CURROW >say currow >say curline > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
On Fri, 29 Mar 2019 07:56:36 -0500, Elardus Engelbrecht wrote: >Jeremy Nicoll wrote: > >>Remember that when an ispf edit macro starts to execute you have access to >>the underlying ispf session, and indeed underlying TSO. So change the macro >>to, for example: > >>address ispexec "vget (parmin parmuit) profile" > Neat! I never became proficient with the ISPF variable pool. Is there any restriction on the content of ISPF variables? Special characters? Length? Can they be delimited strings, subject to the design deficiencies of delimited strings? I've sometimes resorted to adding a temporary data set to my SYSEXEC concatenation and creating Execs/Macros dynamically there, often with a TSO REPRO from an instream data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset
On Fri, 29 Mar 2019 02:32:04 -0500, Elardus Engelbrecht wrote: > >> INREC FINDREP=(ENDPOS=2004, >>Note : For FB fies the end position would be 2000 ( No addition of the RDW) > >Not many people understand that little 4 bytes trick for that RDW. ;-D ;-D > When I first encountered MVS, I found including the RDW in LRECL counterintuitive. If the "L" stands for "Logical" it should count only the data, not metadata. CMS counts only the data in record length. But that led to an error in emulated OS I/O: Circa VM/370, OPEN failed to add 4 for compatibility. I don't know if it was ever fixed. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA OPS/MVS
OPS/MVS has an additional feature you can install called CA OPS/MVS OPSHMC REXX. On Fri, Mar 29, 2019, 5:50 AM Graham Cornwell wrote: > Hi Peter, > > I am that customer, I am very interested in seeing your rexx to do this > and would be grateful if you would share it with me. > > Regards Graham > > > > GRAHAM CORNWELL / VP MAINFRAME INFRASTRUCTURE > T +44 20 7255 7151 / M +44 7867 510360 / gcornw...@mediaocean.com > Blue fin Building 110 Southwark St, London SE1 0TA > > T +1 212 633 5060 > 45 West 18th Street, 6th Floor - New York, NY 10011 > MEDIAOCEAN.COM / @TEAMMEDIAOCEAN > > -- > 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: ISPF edit macro behaivor in SDSF
Dana I would double-check your REXX exec code - perhaps paste to the forum? "SE" and "SJ" use ISPF "EDIF" services - pretty much all SDSF does is supply the data for the "get first/next" record request from EDIF. I have just executed the following simple REXX EDIT macro in SDSF SJ and SE in 2.2 and 2.3 and the results were as expected: address ISREDIT "MACRO" address ISREDIT "(CURROW CURCOL) = CURSOR " address ISREDIT "(CURLINE) = LINE "CURROW say currow say curline Rob Scott Rocket Software. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dana Mitchell Sent: Friday, March 29, 2019 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISPF edit macro behaivor in SDSF I have an edit macro that I've used in one form or another for many years, it's my version of the point and shoot edit. Place the cursor on a dataset name in a jcl member for instance, hit the PFK set to ';CA' and you are taken to edit of that dataset. It discerns the dataset name by doing a ISREDIT "(lne,col) = CURSOR" and parsing out the dataset name you are pointing at. I'm not sure when I first noticed it, but it appears to not operate correctly in SDSF (z/OS 2.2 currently) edit of JCL or output from the SJ or SE line command. The row and column returned are of the first non-blank character of the next line, someone pressed enter before invoking the macro, which usually with a JCL listing, just happens to be a '/' so you end up with a 'z/OS UNIX Directory List' of the root. I don't find any mention of any restrictions on edit macros in the SDSF FM. Anybody else tried this? is it pmr time? Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ISPF edit macro behaivor in SDSF
I have an edit macro that I've used in one form or another for many years, it's my version of the point and shoot edit. Place the cursor on a dataset name in a jcl member for instance, hit the PFK set to ';CA' and you are taken to edit of that dataset. It discerns the dataset name by doing a ISREDIT "(lne,col) = CURSOR" and parsing out the dataset name you are pointing at. I'm not sure when I first noticed it, but it appears to not operate correctly in SDSF (z/OS 2.2 currently) edit of JCL or output from the SJ or SE line command. The row and column returned are of the first non-blank character of the next line, someone pressed enter before invoking the macro, which usually with a JCL listing, just happens to be a '/' so you end up with a 'z/OS UNIX Directory List' of the root. I don't find any mention of any restrictions on edit macros in the SDSF FM. Anybody else tried this? is it pmr time? Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
Jeremy Nicoll wrote: >Remember that when an ispf edit macro starts to execute you have access to the >underlying ispf session, and indeed underlying TSO. So change the macro to, >for example: >address ispexec "vget (parmin parmuit) profile" Thanks for showing where to put the vget and vput commands. That was the missing link I needed. >Personally I'd also set up error handling, probably at least a little >validation of the incoming parameters, and I might check that the 'save' >actually works before 'end'ing the macro. As it stands you won't be able to >tell from the invoking rexx exec whether what the macro was intended to do >actually worked. Excellent! I will remember this. >So, what happens is that you use the ispf variables support to save the values >of parmin etc before invoking edit, then once the macro has control it asks >ispf for the values that were saved. Thanks, this is what I want. I want variables which can be used in 'child' processes including macros. Anyways, I will play around with your suggestions, while 'they' will put the DFSORT solution in production. At least this (vget + vput) is something new for me to keep me busy. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
On Fri, 29 Mar 2019, at 07:24, Elardus Engelbrecht wrote:
> Now, for my problem is, I have this macro (which is not working):
>
> ISREDIT MACRO (PARMIN PARMUIT)
> ISREDIT RESET
> ISREDIT CAPS OFF
> ISREDIT CHANGE ALL
> ISREDIT SAVE
> ISREDIT END
Remember that when an ispf edit macro starts to execute you have
access to the underlying ispf session, and indeed underlying TSO.
So change the macro to, for example:
address ispexec "vget (parmin parmuit) profile"
address isredit
"macro"
"reset"
"caps off"
"change" parmin parmuit "all"
"save"
"end"
Personally I'd also set up error handling, probably at least a little
validation of the incoming parameters, and I might check that the
'save' actually works before 'end'ing the macro. As it stands you
won't be able to tell from the invoking rexx exec whether what the
macro was intended to do actually worked.
> Above macro is called by this:
>
> /*REXX*/
> TRACE ALL
> PARSE ARG DSN PARMIN PARMUIT
> SAY DSN PARMIN PARMUIT
> Z = "EDIT DATASET('"||DSN||"') MACRO(CHANGEIT) CONFIRM(NO) "
> ADDRESS ISPEXEC Z
> EXIT
and in that before you invoke ispf edit, insert
address ispexec "vput (parmin parmuit) profile"
So, what happens is that you use the ispf variables support to save
the values of parmin etc before invoking edit, then once the macro
has control it asks ispf for the values that were saved.
--
Jeremy Nicoll - my opinions are my own.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA OPS/MVS
Hi Peter, I am that customer, I am very interested in seeing your rexx to do this and would be grateful if you would share it with me. Regards Graham GRAHAM CORNWELL / VP MAINFRAME INFRASTRUCTURE T +44 20 7255 7151 / M +44 7867 510360 / gcornw...@mediaocean.com Blue fin Building 110 Southwark St, London SE1 0TA T +1 212 633 5060 45 West 18th Street, 6th Floor - New York, NY 10011 MEDIAOCEAN.COM / @TEAMMEDIAOCEAN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Batch edit of large dataset
ISPF Edit Macros in batch... ? – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: 28 March 2019 07:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Batch edit of large dataset Hi to all, I've got a requirement where a single line in large dataset (RECFM=VB or FB and LRECL=) needs to be edited/changed in batch. Changed dataset is then to be used in next job steps. Sounds easy? Interactively with TSO yes, but they want it to be done in a batch job. Something like c '???' '!!!' which can be easily done interactively. I have a look at the different utilities. One utility I could find useful is the EDIT and CHANGE commands running under IKJEFT. Unfortunately those IKJEFT01 commands require that the dataset lines need to be numbered. I tried it out: READY EDIT '??.TEST' OLD TEXT ASIS NONUM EDIT CHANGE 1 2000 'ONE' 'TWO' IKJ52502I DATA SET NOT LINE NUMBERED EDIT END The IKJ52502I is not what I want. Is there a batch utility where I can edit a line in large dataset? I am very sure I am overlooking something obvious. Many thanks in advance. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset
Sri h Kolusu wrote: >You skipped over the most important Utility DFSORT. ... and I discovered it (and ICETOOL) again! ;-) (see my other thread about this matter) >It can find and REPLACE one or more strings. Here is an example. I eventually used your example I discovered in another thread you posted some years ago. > INREC FINDREP=(ENDPOS=2004, >Note : For FB fies the end position would be 2000 ( No addition of the RDW) Not many people understand that little 4 bytes trick for that RDW. ;-D ;-D >Further if you have any questions please let me know. I will do so, of course. Thanks again for your kind help. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset
Paul Gilmartin wrote: >>Unfortunately those IKJEFT01 commands require that the dataset lines need to >>be numbered. >Could you run ISPF Edit under IKJEFT and use its CHANGE command in an initial >macro? Thanks for asking. Eventually yes, I could do it and bypass the problem of line numbers, but please see my other reply to you. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Batch edit of large dataset - Solved
Paul Gilmartin wrote:
>>But I have problems to pass the two arguments for the ISREDIT CHANGE command.
>>It is easy (after lots of RTFM on KC! ;-D ) to do that interactively, but not
>>in batch.
>Where does the problem arise? Is it the TSO parser's meddling with delimited
>strings?
>ISPF Edit assignment statements allow parenthesized names of Rexx variables to
>be used as source or target, bypassing delimiter rigamarole.
>Unfortunately, ISREDIT CHANGE has no such capability. Sounds like an
>invitation for an RFE.
Seymour J Metz wrote:
>What problem do you have using ISREDIT in batch? How is the semicolon handled
>in ISREDIT?
Thanks to both Paul and Shmuel for asking!
I am going to answer both of you with this what I experienced.
In book 'z/OS ISPF Edit and Edit Macros' there is an interactive example of
passing parameters:
:
You have this: ISREDIT MACRO (PARM1,PARM2,REST)
This means that if you enter (interactively): FIXIT GOOD BAD AND UGLY
This macro has then 3 parameters where the last one is 'AND UGLY'.
It is also written:
"You can enter parameters along with an edit macro name as a primary command by
using the MACRO command. This command allows you to identify the names of one
or more variables to contain any passed parameters.
Note: For edit line macros, only one parameter is passed to the macro. This
parameter is the line command, including any repetition, as it was entered on
the line."
Nothing about doing the same in batch is written.
Now, for my problem is, I have this macro (which is not working):
ISREDIT MACRO (PARMIN PARMUIT)
ISREDIT RESET
ISREDIT CAPS OFF
ISREDIT CHANGE ALL
ISREDIT SAVE
ISREDIT END
PS: If I remove the PARMIN and PARMUIT and replace it with the actual text,
then it is working.
Above macro is called by this:
/*REXX*/
TRACE ALL
PARSE ARG DSN PARMIN PARMUIT
SAY DSN PARMIN PARMUIT
Z = "EDIT DATASET('"||DSN||"') MACRO(CHANGEIT) CONFIRM(NO) "
ADDRESS ISPEXEC Z
EXIT
This is the JCL:
//EDITASC EXEC PGM=IKJEFT1B,
// PARM='ISPSTART CMD(%EDITA )'
//SYSEXEC DD DISP=SHR,DSN=
Dataset is passed successfully, but how do I pass the PARMIN (text to be
removed) and PARMUIT (new text to be placed) all the way to the ISREDIT CHANGE?
Thanks in advance!
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
