To all interested in this thread If two of the responses had been the same, I could have replied "SNAP"!
The following is a text article at http://paul.saers.com/MVS_treasures_01.html It's small enough just to post and I believe it answers the question. I know almost nothing about this topic but I do know how to Google: "svc 50" mvs". <quote> Hidden treasures in MVS I want to spread some info that can be very valuable to many people who want to know more about what is really happening in MVS or in their applications. As so often before... all info is there. It is just a matter of knowing where to find it and then to interpret the info. I hope that I can help out here. One of the greatest places for info in MVS is the system trace table. It contains a lot of information, but don't bother with all info that you do not understand. Stay focused on things you do understand and you will feel a lot better. MVS has a default trace buffer per processor. These will be formatted as a single trace table by abend routines. How can they be treated as a single trace table? Easy! All trace entry's have a time stamp. All that is needed is to merge the trace tables based on this time stamp. There is much more about time stamping in the TOD links from the header page. You will typically see the trace when something goes really wrong in MVS or in an application. The trace will be part of the debug material (part of the dump). The trace table is like the flight data recorder in an airplane. It contains vital data from vital instruments at the time of an accident. The trace data is such a good window into MVS. Why not try to get a view of it without something going bad? Can that be done? Sure. Just include a SNAP macro like this in your assembler program: PAUL SNAP DCB=SNAP1,SDATA=TRT,STORAGE=(USRLIST,ENDLIST) At the label PAUL, we have the SNAP macro. We need a DCB that tells us what DD card to use for output. The STORAGE keyword is to tell what part of storage we want dumped to our DD card. But for now, the TRT parameter is what we focus on. The TRT is short for Trace Table. That is about all we need to do. But... MVS is concerned that we can see too much info. If the caller of the snap macro is a normal user, then he will only get trace entry's that belong to his address space. If the caller is authorized (AC=1), then he will receive all the trace info. Now that we know how to get the trace data out, how do we get some info into it? Normally, you do not need to do anything, since any interrupt (plus some other events) will end up in the system trace. But, we can activate branch trace or activate PER (program event recording) and so get much more into the trace. The drawback is that the trace table will wrap around much faster. You cannot look so far back into history as you would like. All this is also adding overhead to the system. There is one secret way to get footprints from your program into the trace. Secret?? Well, not really secret, since it was documented in my handbook for OS-360: S229-3169-3 (System/360 Operating System field engineering handbook) from 1971. I seem to remember that it was also mentioned in the VS2-SVS handbook (and I have no copy of it) but no more after that. What is the secret? The NOP SVC. Yes, there is an SVC that does nothing. Yes, it is still there today. Since it is an SVC, it generates an interrupt and so it is traced. This is SVC 50 or 0A32 for real programmers. It can be inserted freely into your code and will leave footprints behind. You may have a separate job that is authorised and only snaps out the trace table on demand and you will be able to see the timestamped footprints from your program. You will have to do a little research yourself if you want to use this SVC a lot (remember - it is not documented in today's versions of MVS!). Find out if any register contents are damaged across the SVC handling (check E, F, 0 and 1 just to be sure). You may also want to have a look for what registers are saved in the trace entry's. This is a good way to send info to the person using the trace data. You could tell what routine was active or what transaction was active or so. It is up to you. So, you like this, but it does add a little overhead to the program. Can we enable / disable this feature? Yes, there is always a way, once you have a deep look at it. Just do like this: You have a program that has some kind of control block pointed to during its lifetime. Let's assume that you have reg 8 pointing to this control block all the time. Put the SVC in a free place in this block (assume offset 444). Instead of having SVC's in our program, we will use Execute instructions instead. So, all we do is to insert 44008444 anywhere in our code. Now we execute the SVC and get the footprint. But, if we want, we replace the SVC with a 0700 and we will not do any footprints at all. There is much more about the TOD clock in a separate link from the header page. For now, just take the TOD value from 2 interesting trace entry's and subtract them from each other. Skip the last 3 characters (the last 12 bits or the last 11/2 byte). Convert this to decimal and you have the difference in time in millionth's of a second. Really easy. Now you can get into program elapsed times without really doing any overhead or without any costly monitors. /Paul Saers http://paul.saers.com Reference info: System trace table: see A22-7585.00 z/OS V1R1.0 MVS Data Areas, Vol 5 (SSAG-XTLST) Snap macro: see A22-7607.00 z/OS V1R1.0 MVS Programming Assembler Services Reference Vol 2 </quote> A story: The reason I paid any attention to this thread is that it reminded me of an episode in 1971 or so. I had been developing a technique to convert the source of English Electric System 4 Model 30 programs written in Assembler - the usual programming language at the time for System 4 machines - so that the programs ran on MVS. A London local authority had such a machine and needed to be persuaded to buy an IBM machine. However, they needed to see their programs converted and run so that they could be "benchmarked", timed. A team put together for the project managed to get the job done and the benchmark ran well- but with one hiccough! In the program suite there was one solitary program written in COBOL - a usable COBOL compiler had just about been developed for the System 4 and the customer had been in the process of switching from Assembler to COBOL. The task, more checking than converting, of getting the COBOL program working had been given to a COBOL specialist drafted into the team. However, the COBOL program had subroutines in Assembler. The subroutines were there to exploit an unique feature of the Model 30 - not found in other machines in the System 4 range. This feature was the "binary" storage to storage instructions: "Add Binary" and "Subtract Binary". The technique I developed consisted of automating the conversion as much as possible and then manually "fixing" the tricky bits. (I later developed completely automated conversion programming for the higher model numbers in the System 4 range - mainly "marketed" in Bulgaria and Czechoslovakia - but that's another story!) I dealt with the "Add Binary" and "Subtract Binary" instructions using macros which performed the function of these instructions. However, since that was inherently going to be grossly inefficient, I arranged that the fact that the macros had been used would be identified so that the position in the program where they were used could be "visited" for manual rewriting. I used a SNAP macro - with output to a SNAP data set. Unfortunately again, while working on his program, the COBOL specialist hadn't understood this technique and merely discarded the output with a DUMMY DD- statement. During the benchmark, the programs converted from Assembler sailed through very quickly and impressed the prospective customer as was intended. On the other hand, the COBOL program limped through amazingly slowly! After the team had disbanded and we'd gone our separate ways, the brightest member of the team, who was deeply "into" MVS matters, undertook a day or two later to investigate why the COBOL program had been so slow. His technique was to interrupt the program at regular intervals in order to see what it was doing - I forget precisely how this was done. It was only now discovered what the Assembler subroutines in the COBOL program were doing since it turned out that the program spent most of its time executing an SVC 50, the SVC associated with the SNAP macro. Chris Mason On Wed, 25 Mar 2009 16:04:34 -0500, Paul Schuster <[email protected]> wrote: >Does anyone know what this SVC does? The diag ref manual only says 'reserved'. > >Thank you. > >Paul ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
