MVSFORUMS.com

Cogito-Ergo-Sum · Posted: Wed Nov 30, 2005 2:59 am Post subject:

nevilh,

semigeezer · Posted: Wed Nov 30, 2005 3:34 am Post subject:

The CVT, ASVT, ASCB, CSCB and RMCT are documented in the data areas books. The books list fields that are approved programming interfaces and fields that are not. WHile writing this program, I didn't check if the fields I used are valid programming interfaces. ASCBINTS is not listed as a programming interface and neither is RMCTTOC. CHTRKID isn't even documented correctly. It works as it always has, but isn't part of the interface either. CVTASVT is approved and the ASVT itself is unclearly documented (no fields are listed, but none are excluded either), but everyone uses these particular ASVT fields so they are unlikely to change.

Now... will these fields or their offsets change? I doubt it, at least in the near term, since there is lots of software out there that uses them (except for RMCTTOC), but it is possible, especially since they deal with things like the hardware clock. If the hardware clock changes to be more than 64 bits, and it could considering that it rolls over in 2041, then all of these control blocks could change. It may have already changed in a recent architecture level and I didn't notice, but these fields haven't changed. Also, MVS always tries to keep commonly used interfaces backward compatible if it is at all possible. (The subsystems like JES2 are another story -- they frequently change internals).

I have to agree with nevilh. Taking a program like this and throwing it into production without understanding it is dangerous. This one, for example uses the field RMCTTOC which is part of the system resource manager (SRM). I simply looked in likely control blocks until I found one that had a fairly up-to-date clock value because I can't issue a STCK instruction in Rexx. Normally, a program like this would call an assembler program to issue an STCK to get the current time, so this is really a 'hack'. But SRM appears to update the RMCT often enough (several times per second) for a program like this to be OK using it.

If this program breaks, it will be because of a change in the hardware architecture, or exploitation of changes that have already occured (or because I guessed wrong at what these fields really do), but if the architecture changes, this little program will be the least of the conversion efforts.

To answer your other question...
The program will only list jobs. TSO users, started tasks, and system tasks have different values for the CHTRKID field. Unix tasks share the same value as jobs but I excluded them by checking a field in the associated OUCB control block. The exec I modified to create this shows all the system tasks and can be found here.

acevedo · Posted: Wed Nov 30, 2005 8:28 am Post subject:

I'm agree with nevilh, though I've downloaded lots of programs/utilities from Doug or CBT or Lionel B.D .... In case I want to put it in Production I take care of understand it.

the other question, as said, I really hope IBM keep changing any Data Areas in areas that do not affect existing code... could happen but I do hope not.

amit4u79 · Posted: Sun Dec 18, 2005 11:18 pm Post subject:

Hey Seemigeezer thanks for the update on Doug's REXX and I am grateful that you explained the queries of mine in such a descriptive manner. I really appreciate that.
I have gone thru the MVS data areas manual and got the offsets of all the CVT, ASVT, RMCT, ASCB and CSCB control blocks.

I have only the following queries:

a) why do we do a (ASVTMAXU - 1) while performing the DO loop on the MAX entries found in the ASVT Control block ??
b) Is there any document where I can check what values in the control block is for what ?? I mean for e.g. CHTRKID = '03' x for Batch jobs and UNIX tasks, '02' x is for STC and things like that... Also, where can I find information regarding oucbomvs in ASCB Data Area ?? The MVS Data Areas book only gives information regarding the offset, it doesnt explain each field in detail.

Thanks,
Amit Joshi
Singapore.
_________________
I did not fail; I have found 10,000 ways that would not work - Albert Einstein.

semigeezer · Posted: Sun Dec 18, 2005 11:25 pm Post subject:

I was wondering where I got that about the CHKTRKID too when I wrote the last post. I did not see it in the books so it may have been just finding it by "trial and error".
I also don't remember why ASVTMAXU - 1 is used. I seem to recall some documentaiton on that, but I don;t see it now. Anyone know? is that even correct?

MikeBaker · Beginner Joined: 04 May 2004 Posts: 96 Topics: 9

semigeezer · Posted: Mon Dec 19, 2005 11:37 am Post subject:

I gotta stop answering questions when I'm exhausted. Obviously the asvtmaxu-1 is an offset issue because of the calculation of addresses is not the same as an array index. And the chktrkid... oh... nevermind Smile

amit4u79 · Posted: Tue Dec 20, 2005 8:37 pm Post subject:

Hey thanks a lot Mike and Seemigeezer for your responses and pointers for the answer to my queries.

Thanks again,
Amit Joshi.
_________________
I did not fail; I have found 10,000 ways that would not work - Albert Einstein.

strat · Beginner Joined: 10 Jun 2005 Posts: 3 Topics: 0

Check your syslog for $HASP308. If you have it, use automation to generate a console alert. The message will be $HASP308 'jobname' ESTIMATED TIME EXCEEDED BY '##' MINUTES.
I don't know what automation tool you use but if it is CA-OPSMVS
Rexx code:

amit4u79 · Posted: Thu Dec 22, 2005 9:33 pm Post subject:

Hey strat, this is a good one by you. The only thing is I checked my syslog and there is no $HASP308 * message there though there are jobs which are running since long there. Is there any way I can set the JES parm to give this message and then may be I can trap the message at regular intervals and throw error message if it exceeds the stipulated time ??

How to set the JES to show this message on console. Any setting needs to be done ??

Pls respond.

Thanks.
_________________
I did not fail; I have found 10,000 ways that would not work - Albert Einstein.

strat · Beginner Joined: 10 Jun 2005 Posts: 3 Topics: 0

Check your JES2 member in your PARMLIB for ESTIME. Modify the following example so it does generate the $hasp308 when you want them:
ESTIME NUM=60, /* 60 minutes for 1st Message */
INT=60, /* then at 60 minute Intervals */
OPT=YES /* Issue $HASP308 message */

strat · Beginner Joined: 10 Jun 2005 Posts: 3 Topics: 0

If ESTIME is already in the JES2 member, you can display the value with $D ESTIME.
Since a JES2 restart is needed to pick up the parm change, you can dynamically change it for testing purposes by issuing:
$T ESTIME,NUM=#,INT=#,OPT=YES. Change # to whatever value you want.

I test with $T ESTIME,NUM=1,INT=1,OPT=YES. That way, the first message is generated at 1 minute and the interval is set to every minute thereafter.

Enjoy the holidays!!!