> I know, but how do you go back to where you were? Say you're following a > chain of linked addresses and you want to go back. Typing in stuff to > remember the addresses would be a pain. Web browsers give you all that for > free. As far as I am concerned, one works differently in the z/OS world. I use the back button a lot on windoze, and a lot of internet sites (IBM included) make it hard for me to use it at all. Sometimes it gets perverted to have other meanings (provided I allow javascript on the page, which I mostly don't), often I get told that information needs to get resend. And if all of the pages displayed have the same name, I have a hard time remembering what my 'starting page' was, so to speak. And I will not patiently click on back and back and back and... you get my meaning. For IPCS, I learned early to start out with an address and assign a symbol to it. I still do this (p is always the psw for me), even if I don't know if I need to go back to that address. Same for save areas - the p gets a number assigned so I know how far back I am. I do the same to linkage stack entries (split screen is your friend here, too). And chains of addresses I display using the runchain command, possibly with anoth er command interspersed to give me formatted output. No need to go back and forth.
> Well that's odd because back in the days when I worked on Java for z/OS, I > wrote the code to extract a java heapdump from an sdump. Way out of date > but you can still find references to "java -cp svcdump.jar > com.ibm.zebedee.commands.Convert" here: > https://publib.boulder.ibm.com/httpserv/cookbook/Operating_Systems-zOS.html > . The modern way to do that is using jdmpview, see > https://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.lnx.70.doc/diag/tools/dump_viewer_dtfjview/dump_viewer_commands.html It was the java development in Hursley that told me there is no tool, about 5 years ago. Maybe your tool was internal use only. Either I had not used the correct docs when I searched for it or it just wasn't there at the time. Fortunately these days I don't have to deal with Java on z/OS anymore - other than to install it. But thanks for the link. > Oh, and besides not liking IPCS, the other reason I wrote sdump analysis > software in Java was that about 15 years ago someone had written a Rexx > script to extract useful info from a dump using IPCS but in some cases it > would take about 24 hours to run! Who said that that REXX was well written? And <tongue in cheek> how is it any different from Java on z/OS? Java applications have always been cpu hogs back when I had to deal with them. I am still pretty sure that having your tool analyze a standalone dump (say, an RSM problem with large real storage amounts in the lpar) would take forever, if the tool can even deal with an sadump. More than one support person doesn't have a clue how to read an sadump properly, starting with determining what the error asids are (when all cpus are in a no-work-wait). And now I'm really off my soap box. :-) Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
