Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?
On Tue, 4 Feb 2020, at 16:31, Robert Prins wrote: > On 2020-02-04 14:39, Jeremy Nicoll wrote: > > That's confusing. Earlier you implied it was the execs (ie the logic, I > > assumed) > > that was changing. Now you say it's the data. Have you got both logic and > > data > > in the same file(s)? > > 1) An input file, subject to frequent changes (at least once per month), > processed by a handful of execs/edit macros > > 2) A handful of execs/edit macros that process the input file, with > some of them using some (potentially new, last new keyword was > added on 2018-07-31) keywords from 1) > > 3) A "master" exec/edit macro that reads 1), and updates the keyword tables > inside the "handful of others" > > > Why don't you leave the execs alone and make them read their data from > > external files, and just change those? > > If my uncle had been a woman, she'd my aunt... OK, fair enough... and if you were designing it now you'd probably choose a different structure. Couldn't the table inside the execs, that gets changed every so often, be put in a rexx external function, called by every exec/macro that needs to access the data? Or be vput into application profile variables, or even an ispf table? Whether that's practical depends on the size of the table(s), I suppose. > > I suppose I'd have chosen to read the existing definitons first and only > > call an > > edit macro to update them if they needed to change. > > Same difference, but in that case you would have to open the "handful > of others" potentially twice! So what? -- 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-L] "macro_msg" edit macro command not working for "COMPARE" command?
On 2020-02-04 14:39, Jeremy Nicoll wrote: On Tue, 4 Feb 2020, at 13:19, Robert Prins wrote: On 2020-02-04 10:56, Jeremy Nicoll wrote: On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote: It also updates the change-logs in each of the affected execs, and as we keep a few generations of older versions around, it's irritating that compares show that the change-log has been updated, but that there are no other changes. So "it also updates the change-logs in each of the affected execs" statement is incorrect. They weren't 'affected execs'. Why on earth are you updating change-logs with (in effect) "no change" statements? Why don't you stop inserting pointless change-log entries ... then you won't have the 'compare' problem? The input file for the affected execs does change, but the changes may not affect all of the REXX execs/edit macros that are used to process its contents. The "master" exec/edit macro (it's both) just extracts all the relevant data, and passes it on to the various per-exec/edit macro subroutines. It has no clue whether the data to be processed by any of these other exec/edit macros has changed. That's confusing. Earlier you implied it was the execs (ie the logic, I assumed) that was changing. Now you say it's the data. Have you got both logic and data in the same file(s)? 1) An input file, subject to frequent changes (at least once per month), processed by a handful of execs/edit macros 2) A handful of execs/edit macros that process the input file, with some of them using some (potentially new, last new keyword was added on 2018-07-31) keywords from 1) 3) A "master" exec/edit macro that reads 1), and updates the keyword tables inside the "handful of others" Why don't you leave the execs alone and make them read their data from external files, and just change those? If my uncle had been a woman, she'd my aunt... The code in some of the "handful of others" goes back to 1992, the "master" exec was added as a quick hack in 2005, as manually updating the "handful of others" was error-prone. The, until yesterday, code would willy-nilly copy the new data, whether changed or not, into the member, and update the change-log. What I wanted to do was to just insert the data, do a "COMPARE *", and then either do a "cancel", if there were no changes... I suppose I'd have chosen to read the existing definitons first and only call an edit macro to update them if they needed to change. Same difference, but in that case you would have to open the "handful of others" potentially twice! Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?
On Tue, 4 Feb 2020, at 13:19, Robert Prins wrote: > On 2020-02-04 10:56, Jeremy Nicoll wrote: > > On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote: > > > >> It also updates the change-logs in each of the affected execs, and as > >> we keep a few generations of older versions around, it's irritating > >> that compares show that the change-log has been updated, but > >> that there are no other changes. > > > > So "it also updates the change-logs in each of the affected execs" > > statement is incorrect. They weren't 'affected execs'. > > > > Why on earth are you updating change-logs with (in effect) "no change" > > statements? > > > > Why don't you stop inserting pointless change-log entries ... then you > > won't have the 'compare' problem? > > The input file for the affected execs does change, but the changes may not > affect all of the REXX execs/edit macros that are used to process its > contents. > The "master" exec/edit macro (it's both) just extracts all the relevant data, > and passes it on to the various per-exec/edit macro subroutines. It has no > clue > whether the data to be processed by any of these other exec/edit macros has > changed. That's confusing. Earlier you implied it was the execs (ie the logic, I assumed) that was changing. Now you say it's the data. Have you got both logic and data in the same file(s)? Why don't you leave the execs alone and make them read their data from external files, and just change those? > The, until yesterday, code would willy-nilly copy the new data, whether > changed > or not, into the member, and update the change-log. What I wanted to do was > to > just insert the data, do a "COMPARE *", and then either do a "cancel", if > there > were no changes... I suppose I'd have chosen to read the existing definitons first and only call an edit macro to update them if they needed to change. -- 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-L] "macro_msg" edit macro command not working for "COMPARE" command?
On 2020-02-04 10:56, Jeremy Nicoll wrote: On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote: It also updates the change-logs in each of the affected execs, and as we keep a few generations of older versions around, it's irritating that compares show that the change-log has been updated, but that there are no other changes. So "it also updates the change-logs in each of the affected execs" statement is incorrect. They weren't 'affected execs'. Why on earth are you updating change-logs with (in effect) "no change" statements? Why don't you stop inserting pointless change-log entries ... then you won't have the 'compare' problem? The input file for the affected execs does change, but the changes may not affect all of the REXX execs/edit macros that are used to process its contents. The "master" exec/edit macro (it's both) just extracts all the relevant data, and passes it on to the various per-exec/edit macro subroutines. It has no clue whether the data to be processed by any of these other exec/edit macros has changed. The, until yesterday, code would willy-nilly copy the new data, whether changed or not, into the member, and update the change-log. What I wanted to do was to just insert the data, do a "COMPARE *", and then either do a "cancel", if there were no changes, or call a common subroutine to update the change-log. Given that the "COMPARE" command doesn't seem to return its messages in the designated variables, I have for now resorted to comparing every line of the block-of-lines-to-be-replaced with its new version, and only when that tells me that there are any changes I will replace the old lines with the new ones, and update the change-log. Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?
On Tue, 4 Feb 2020, at 11:44, Robert Prins wrote: > It also updates the change-logs in each of the affected execs, and as > we keep a few generations of older versions around, it's irritating > that compares show that the change-log has been updated, but > that there are no other changes. So "it also updates the change-logs in each of the affected execs" statement is incorrect. They weren't 'affected execs'. Why on earth are you updating change-logs with (in effect) "no change" statements? Why don't you stop inserting pointless change-log entries ... then you won't have the 'compare' problem? -- 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-L] "macro_msg" edit macro command not working for "COMPARE" command?
On 2020-02-03 21:52, Bob Bridges wrote: I've never used the COMPARE command. (Never used MACRO_MSG, either.) What message were you expecting from COMPARE? "Files are the same" or of course the message that tells me they're not. It would allow me to cancel the update that in fact isn't an update, there's a "master" REXX exec that fires off updates of a lot of other execs and edit macros if some key file is changed. It also updates the change-logs in each of the affected execs, and as we keep a few generations of older versions around, it's irritating that compares show that the change-log has been updated, but that there are no other changes. For now I've worked around it by comparing the (relatively) small number of lines-to-be changed with what's already there, and cancelling the update if they are the same. Robert -- Robert AH Prins robert(a)prino(d)org The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html > -Original Message- From: ispf-l-l...@nd.edu [mailto:ispf-l-l...@nd.edu] On Behalf Of Robert Prins Sent: Monday, February 3, 2020 09:11 I've been using this for ages, and in case you've never heard of it: MACRO_MSG Set or Query the Macro Message switch The MACRO_MSG assignment statement sets or retrieves the value of the macro_msg switch, which controls whether macro processing delivers ISPF messages to the macro. Syntax >>--ISREDIT--(varname)-- = --MACRO_MSG-->< +-ON--+ >>--ISREDIT--MACRO_MSG-- = --+-+>< +-OFF-+ varname The name of a variable containing the setting of MACRO_MSG. ON ISPF messages generated by macro commands are formatted. OFF ISPF messages are not formatted. Description The MACRO_MSG assignment statement sets a switch for subsequent macro processing. When set ON, any message that is generated by a macro command is formatted and made available in variables in ZEDILMSG, ZEDISMSG, and ZEDMSGNO. This is a diagnostic switch and should only be used to extract messages as required. Macros that perform operations on many edit lines may experience a performance degradation if this switch is ON. Return codes 0 Normal completion 20 Severe error I now wanted to use it to get at the message set by the "COMPARE" command, as that just returns RC=0, no matter (differences or no differences) what, but in this case all three above mentioned variables come back as 8-character blank strings. Am I doing something wrong, or is this a bug? Replies please to IBM-MAIN only (I cross-posted this also to ISPF-L) -- Robert AH Prins robert.ah.prins(a)gmail.com The hitchhiking grandfather - https://prino.neocities.org/indez.html Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [ISPF-L] "macro_msg" edit macro command not working for "COMPARE" command?
I've never used the COMPARE command. (Never used MACRO_MSG, either.) What message were you expecting from COMPARE? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* By 2005 or so, it will be clear that the Internet's impact on the economy has been no greater than the fax machine's. -Paul Krugman, Nobel-prize-winning economist in 1998 */ -Original Message- From: ispf-l-l...@nd.edu [mailto:ispf-l-l...@nd.edu] On Behalf Of Robert Prins Sent: Monday, February 3, 2020 09:11 I've been using this for ages, and in case you've never heard of it: MACRO_MSG Set or Query the Macro Message switch The MACRO_MSG assignment statement sets or retrieves the value of the macro_msg switch, which controls whether macro processing delivers ISPF messages to the macro. Syntax >>--ISREDIT--(varname)-- = --MACRO_MSG-->< +-ON--+ >>--ISREDIT--MACRO_MSG-- = --+-+>< +-OFF-+ varname The name of a variable containing the setting of MACRO_MSG. ON ISPF messages generated by macro commands are formatted. OFF ISPF messages are not formatted. Description The MACRO_MSG assignment statement sets a switch for subsequent macro processing. When set ON, any message that is generated by a macro command is formatted and made available in variables in ZEDILMSG, ZEDISMSG, and ZEDMSGNO. This is a diagnostic switch and should only be used to extract messages as required. Macros that perform operations on many edit lines may experience a performance degradation if this switch is ON. Return codes 0 Normal completion 20 Severe error I now wanted to use it to get at the message set by the "COMPARE" command, as that just returns RC=0, no matter (differences or no differences) what, but in this case all three above mentioned variables come back as 8-character blank strings. Am I doing something wrong, or is this a bug? Replies please to IBM-MAIN only (I cross-posted this also to ISPF-L) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
