I have an edit macro that I've written and have been using for over a year to convert production JCL to JCL I can use on the test system. I bring up the JCL and run my edit macro as my personal edit macro.
I would like to set up JCL so the other members of my team can use this. I set up the JCL - and it runs perfectly.. as long as I take out any profile commands - like HILITE, CAPS ON, etc.
when I run the profile commands, I get RC-28 on each profile command, and batch job RC of 990.
I figure I must be setting up my ISPPROF DD incorrectly in the batch JCL, but no matter how I define this DD, I get the same error.
does anyone have JCL to run an edit macro in batch that will change the user's ISPF profile? that you can post here?
/* REXX */
/* ------------------------------------------------------------------ */
/* All REXX reserved words are shown in CAPS and all user */
/* defined variables are shown in 'lower case'. */
/* ------------------------------------------------------------------ */
PARSE ARG filename macro1
ADDRESS ISPEXEC
"EDIT DATASET('"filename"') MACRO("macro1")"
exit;
my edit macros that I tested with:
XNULL - works (just to test JCL)
Joined: 07 Feb 2009 Posts: 1226 Location: Vilnius, Lithuania
1) Setting BDISPMAX to 99,999 is bad, bad, bad, macros should not display a single screen, and a useless loop trying to show what is quite likely an error screen 99,999 times is insane!
2) You do not mess with profile settings (of others) in edit macros. Period. Full stop. End of story!
3) Don't ever use your existing PROFILE dataset in batch.
And
4) Production JCL should be fully parametrised. Once I've slapped on the required GPL statement, I'll post my code and show you why.
1) Setting BDISPMAX to 99,999 is bad, bad, bad, macros should not display a single screen, and a useless loop trying to show what is quite likely an error screen 99,999 times is insane!
2) You do not mess with profile settings (of others) in edit macros. Period. Full stop. End of story!
3) Don't ever use your existing PROFILE dataset in batch.
And
4) Production JCL should be fully parametrised. Once I've slapped on the required GPL statement, I'll post my code and show you why.
Robert
1. but it doesn't show a loop, does it. and I have a "save" and and "end" at the end of the macro. so, how do you find what is looping. when this works fine when I executed it in foreground under ispf? What am I doing wrong?
2. small group. and with their permission. and only settings that I've set for them manually (over and over) to help them view their data better and not lose their edits.
3. it was a test profile, that I copied from my own. I wanted to see if it changed anything. it didn't. so.. this isn't really answering why I get the RC28s. or for that matter, why I get the BDISPMAX error. You are just telling me I've been a bad bad girl. in your opinion. but not explaining the errors IBM is giving me.
if there is something in IBM documentation that says you should not issue profile commands in batch - that explains why, please show me. I looked - but perhaps I did not search for the right terms.
Joined: 07 Feb 2009 Posts: 1226 Location: Vilnius, Lithuania
Lynne Schuler wrote:
prino wrote:
1) Setting BDISPMAX to 99,999 is bad, bad, bad, macros should not display a single screen, and a useless loop trying to show what is quite likely an error screen 99,999 times is insane!
2) You do not mess with profile settings (of others) in edit macros. Period. Full stop. End of story!
3) Don't ever use your existing PROFILE dataset in batch.
And
4) Production JCL should be fully parametrised. Once I've slapped on the required GPL statement, I'll post my code and show you why.
Robert
1. but it doesn't show a loop, does it. and I have a "save" and and "end" at the end of the macro. so, how do you find what is looping. when this works fine when I executed it in foreground under ispf? What am I doing wrong?
It doesn't, it just tries to display a panel 99,999 times and then gives up. Change the invocation to 999,999 and it will try 999,999 times, and still not show a loop.
Lynne Schuler wrote:
2. small group. and with their permission. and only settings that I've set for them manually (over and over) to help them view their data better and not lose their edits.
Then why is there any need to do it all over again?
Lynne Schuler wrote:
3. it was a test profile, that I copied from my own. I wanted to see if it changed anything. it didn't. so.. this isn't really answering why I get the RC28s. or for that matter, why I get the BDISPMAX error. You are just telling me I've been a bad bad girl. in your opinion. but not explaining the errors IBM is giving me.
28 is a really bad error, something of a last resort one. Try running with a &&profile temporary dataset profile.
Lynne Schuler wrote:
if there is something in IBM documentation that says you should not issue profile commands in batch - that explains why, please show me. I looked - but perhaps I did not search for the right terms.
You should be able to issue them, but as I wrote, it's not the done thing to mess with profile settings of others.
I might start my z/OS system sometime this weekend, I do have to add two hitchhike trips, and update my EJCLPARM with a GPL statement, and post it together with my old JPRINO exit, EJCLPARM pulls the symbolics from production JCL, and optionally uses a user-defined exit , J"&sysuid" to modify these (and it obviously was written before 8-character userids were made an option.)
I did run with a temporary dataset to begin with. same problem. If you look at my JCL, you can see I commented it out before trying it with an actual profile datset defined.
I looked up RC 28 return code for edit macro commands - this is what it says in the IBM ISPF Edit and Edit Macro manual V2R3:
Quote:
Header: Return codes from user-written edit macros
20 and higher
Indicate a severe error. The meanings of the severe return codes are:
20
Command syntax error or Dialog service routine error.
24
Macro nesting limit of 255 exceeded (possible endless loop; see the BUILTIN macro command).
28
Command found either preceding the ISREDIT MACRO command, or following the ISREDIT END
or ISREDIT CANCEL command.
but, like I said in my post before, and like you can see in the edit macro, I do have an ISREDIT END following the profile commands.
so, is there a way to narrow down what the problem to something more definitive than "really bad error"?[/quote]
It's not the profile datataset, your problem is that HILITE ON JCL will try to do some display, which it can't as there is no screen. Hence the rc -28 and eventually the BDISPMAX message. Just curious, what did you expect a HILITE command would do in batch?
You could show (SAY) the ZERRLM variable when you get the rc 28. I haven't tried for that particular error, so I don't know if ZERRLM contains anything useful.
You could show (SAY) the ZERRLM variable when you get the rc 28. I did a quick batch test:
Code:
9 *-* "hi jcl"
>>> "hi jcl"
+++ RC(28) +++
10 *-* say rc zerrlm
>>> "28 Enhanced coloring is not available on this terminal because the terminal does not support extended highlighting."
ISREDIT MACRO_MSG = ON
"HILITE ON ASM"
SAY 'ZEDILMSG= ' ZEDILMSG
SAY 'ZEDISMSG= ' ZEDISMSG
SAY 'ZEDMSGNO= ' ZEDMSGNO
but it didn't have any messages.
so, thanks.
and Willy, I realized that even though I visually didn't see the screen change for those profile instructions - it was because I already had those settings in my datasets. duuh.. my bad. you are right.
but I still want to see what the message is, so I will try what you recommended. Now I'm just curious as to how to show exactly what IBM says the problem is.
Plus.. I am going to see if there is something to say "No Panel Displays". I kind of thought NOPROCESS did that, but once you end the macro, everything is processed. besides, Process is really different than suppressing screen refreshes.
I have a hard time believing IBM would say, "look, you can run your edit macros in batch - but first you have to bypass any instruction that refreshes the screen". seems like that would affect so many edit macros already written. Seems like they would have said, yes, you have to suppress panel refreshes in batch, and this I how you turn it off in batch.
I will look around.. after I try your zerrlm suggestion.
For the life of me, I can not understand why somebody would care about terminal hiliting when running an edit macro in BATCH.
Please 'highlight' me.
Thanks...
LOL. I like that - please "highlight" me.
actually, I realize this is better done in ISPF. But where I work, it is hard to get a plug in to the main ispf panel. I did write a logon proc, but I found out people before me have done that (probably for the same reason).
I have an ISPF edit macro that I've been using for myself for a couple of years to convert production JCL with all the changes we need to be able to test in the test environment. Others would like to use it. I decided to do this in batch job, so I could just allocate the SYSEXEC DD in the jcl. Which I've done.
but when I help others, I end up showing them how to set up the profile so they get coloring. and recovery on. We have very aggressive time out. If I could change profile once in this batch job, it would be on from that point on for that person's dsn type. but I was thinking it was just a matter of setting up the user profile dd in batch and executing the correct ISPF edit commands. but I realize now, not so simple.
but now, others in other groups are interested, so not such a small group anymore. so, I do not want to do this anymore as I do not know if other groups do anything with their profiles.
but.. when I had to problems, I just wanted to know why. even though I'm not going to do it now. Just wanted to know exactly why it didn't work. even for just me.
I did some more searching and found that ZHILITE which defines whether extended highlighting is available for a terminal (which includes coloring) is automatically turned off for batch.
