How to read JESYSMSG?

neeharika · New User Joined: 23 May 2008 Posts: 14 Location: Hyderabad

Hi,

We can get the corresponding library name and member name if we are executing our REXX code on the command line using the following ISPF edit commands in our REXX code.

expat · Posted: Thu Apr 30, 2009 4:40 pm

You can use SDSF to copy from JES into a dataset, many many examples available on the forum.

Please search.

neeharika · New User Joined: 23 May 2008 Posts: 14 Location: Hyderabad

Hi,

My intention is not copy the job from the spool into a dataset. I can use XDC to copy into a dataset.
But I want to execute a REXX utility by opening the job in edit mode i.e, by giving SE against it. I want to read the data from JESYSMSG into my REXX utility, when I execute that utility from the command line.

Thanks,
Neeharika.

expat · Posted: Thu Apr 30, 2009 5:06 pm

Only available with z/OS 1.9 and above I believe.

Please search the IBM website - redbooks - for SDSF / REXX if your OS is compatible.

dbzTHEdinosauer · Posted: Thu Apr 30, 2009 5:41 pm

Neeharika,

neeharika · New User Joined: 23 May 2008 Posts: 14 Location: Hyderabad

Hi Dick,

Actually I would like to design a REXX utility to delete the GDG generations in case of resubmitting the job on the same day. This job will be part of my daily cycle.
So, I don't want to create another new generation on the same day just because I have resubmitted it.
We have CA11 utility which deletes the flat files. I would like to develop a REXX utility which deletes the GDG generations as well.

dbzTHEdinosauer · Posted: Thu Apr 30, 2009 6:55 pm

Neeharika,

do not miss-interpret my comments as support for your endevor.

I can not believe that CA-7 & 11 do not delete gdg's.
why? because that is IBM's answer to files with dates as part of the dsn.

CA7/11 are written (in part) by ex-ibmers that understand the gdg concept,
and I can not believe that their product does not handle it.

I know nothing of CA7/11 (or enough to say how it is done),
but that is a nice thing about this website -
there are enough contributors to insure a knowledge gap does not exist.

now that you have explained your goal, I am sure there will be posts suggesting solutions.

as far as how to do what you want with your rexx macro,
you would FIND lines that have the info that you want,
LINE the data into your scripts storage,
construct the necessary JCL
submit the job.

Pedro · Posted: Thu Apr 30, 2009 8:51 pm

Anuj Dhawan · Posted: Thu Apr 30, 2009 10:02 pm

dick scherrer · Posted: Fri May 01, 2009 12:20 am

Robert Sample · Posted: Fri May 01, 2009 12:35 am

Sounds like Alice in Wonderland -- jam (delete) yesterday and jam (delete) tomorrow but never jam (delete) today!

expat · Posted: Fri May 01, 2009 1:02 am

Nah, Robert surely you meant to mention Bob Marley

We're Jammin ...............................................

Robert Sample · Posted: Fri May 01, 2009 1:04 am

Hey, I thought I got it right ... maybe I need to go listen to the steel drums again?

Anuj Dhawan · Posted: Fri May 01, 2009 1:10 am

Actually, once upon a time I was also trying to create a similar "tool"; and these type of tools are supposed to be of "generic" nature. Given the job name and tool should be able to delete the respective "latest" generations . . . I'm pretty sure that idea behind this tool is "if any job gets abended " delete "all" the GDGs created in that "bad run" even if some GDG is updated multiple times. If it was for a single job, might be I could succeed by preparing a list of all GDGs in that job but then it was not of generic nature . . .

Anuj Dhawan · Posted: Fri May 01, 2009 2:20 am

dbzTHEdinosauer · Posted: Fri May 01, 2009 3:41 am

Anuj,

[start of opinion and fact]

That is what is 'out-of-the-box'.
What that means is if you want to deal with gdg's,
you need to tailor the CA definition of each JOB.

I know for a fact that at several of the sites that I have worked,
which had trained and competent CA users in operations
- user exit implementation,
-detailed JOB definition parameterized (yes i know, misspelled the word) ,
we never had to have REXX Tools like this thread has discussed.

Unfortunately almost every JOB is a little different.
To write a generic REXX Tool, I believe is going to bite you in the ass, eventually.

To make the Tool effective, there will be required more and more specialized - job dependent - code.

Which is what a sophisticated scheduling system can be tailored to do.

Now, if the OP/TS works at one of the cheapie-sites that write their own scheduling system,
the requirement for this REXX Tool is understood.

But if the OP/TS's site has already invested in a scheduler
(and they are not cheap)
they are better off learning how to master their bought-and-paid-for Tool
instead of writing a quick and dirty all purpose REXX.

When one considers the rather lengthy experience of most of the contributors to this thread have,
the basic (negative) theme has been:
every JOB is different - so define and control in one place - the scheduler.

[end of opinion and fact]

dick scherrer · Posted: Fri May 01, 2009 4:43 am