Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> All I'm looking for is a system trace. Hoping to find hints what do look for > next. Make sure that you have your systrace set at maximum, then (not the default 64K, and even 1MB will not be enough, especially on a busy system). LE processing takes up a whole lot of real estate in systrace from the inintial incident to the time the trace actually gets captured. > I did in parallel to the discussion here and succeeded. I now know how to > change the options, but as you might have guessed, I'm working for a large > company. And large companies have processes. It will take quite some time to > bring those changed options to production, once I could convince engineering > to actually do it. Do I know about processes! :-( > Not at will, yet, but it reocurred in production. Application people are > still trying to reproduce it in test. Would make everyting much easier. Did you get the same set of insufficient dump data? Just for comparison - were the same addresses involved? > ESPIE for unauthorized programs (like LE) supports interrupt codes > 1-15 (decimal), which does not include 17 (x'11') page fault. So > SLIP SET,A=SVCD,C=0C4,RE=11,ML=1,MODE=PP,J=jobname,END > should be able take a dump of this problem without interference from > LE's ESPIE. Admittedly we never specified RE=11 (or mode=pp) on the slip trap we had attempted for an 0C4 in my last job, but the slip trap on OC4 only prodcued a dump when TRAP was set to OFF. Maybe what interfered was the fact that parts of the code were authorized. Maybe Peter's "middleware infrastructure" is also authorized, at least in parts. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> >I don't know how LE plays that game. A SLIP of the 0C4 would have true > >contents. > System Trace would also help with this information but it is not in the dump > produced by the "little"helpers". Setting a SLIP in production is a not so > short adventure trip; and SLIPping for a 0C4 is not trivial as long as I > don't have more information what actually happens. > I have asked that the job be changed to switch off the 'little helpers' and a > SYSMDUMP DD be added. Hopefully I will have more information next time it > fails. Just my 2 cents: As long as TRAP(ON,SPIE) is set (and you said you cannot turn it off for various reasons) slip will not get control because (E)SPIE gets control before slip. So your slip trap probably won't match at all. And your sysmdump may contain a dump, but not the first 0C4. I speak from three years of dealing with LE in the picture (lucky for me, it was only LE). If it were me, I would a) try to find out if that dump option thing is customizable and if not kick the vendor in the behind - very hard - for disabling installation set dump options, and b) I would try to figure out where that bit is set and zap it off to get the full set of dump options that I have defined (everything except the IBM-software-support-all-time-favourite of ALLNUC which is unnecessary for most problems anyway, but gets copied every time a slip dump is requested). >Machine State: > ILC. 0002Interruption Code. 0004 That's the ZMCH and that is what FLIH recorded. It gets copied early in LE processing and is the first problem that occured. >RTPSW1... 478D0400 A31A7BB8 >RTPSW2... 00020011 231A7800 >What can I learn from this? How do I properly use these fields in dump >analysis? There's your PIC 11 in RTPSW2. So following the first 0c4-4 (see ZMCH in LE) you got (at least one) subsequent 0c4-11. If both fields are set, it means that while RTM was still dealing with the first problem, a second problem occured. I think that the fields in the XSB may have also been reused by the later problem, which means at the time of the dump things are definitely not the way they were at the time of the first problem anymore (they never are when LE has a chance to get at something first). I'm sure that Jim will correct me if I said something wrong here. If it were me, I would try to find out what address is supposed to be at r7+x'90'. Assuming that DCA$DCT is a vendor control block and not one belonging to JES2. To do that, take a slip dump of the same program execution in test (the equivalent of address 24D90BE0 in your code snippet), find the same control block in it using the eyecatcher, look at that storage and see if the addresses look similar to what you have in the error case. If they do, then find out where the address at x'90' points to. Maybe that will give a clue. Another option would be getmain/freemain trace (if you can set that up in production) presumably for SP0, KEY8. Another idea - get yourself IPCS access to private storage in other address spaces (a FACILITY class profile) and while the job is running, look at the same control block - I am betting that it will always be at offset DC20. In IPCS active storage (using the asid) you can then use the pointer command (?) to see where offset x'90' points to. Maybe it is getmained then! Not sure that you mentioned it - is the problem reproducible at will? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Knowledge Centre and Browsers
> Assuming you can *find* the damned PDFs! That takes a while now. Sad what > IBM has become. Try Pubcenter: http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=DE (and don't use the DE at the end). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Knowledge Centre and Browsers
> * Disable any script blocker. * Well, if you only allow cookies selectively, then it is hell browsing IBM websites if you are forced into disabling script blockers. I should know, I get forced into using IE with scripts enabled (cannot disable them). What happens is that there is a general script on *all* IBM websites that tells you that you can configure cookies, and of course allowing IBM to litter the computer liberally with cookies is the default. If you only allow the cookies needed for the website to function, you're forced to twiddle your thumbs for more than a minute. And again if you happen to switch from an ibm.com to an ibm.de website. I hate it. Not to mention that even SIS didn't work properly under IE. As for knowledge center - I avoid it whenever I can. I'd rather use the pdfs (which I also heartily dislike), but for fast and easy information retrieval I still go back to the 1.13 bookmanager books residing on my own private toy laptop (that will never see the internet since it runs W10). As time goes by, I'll be forced more and more into the pdfs, though. At that time the toy laptop will switch to Debian. :-) The internet isn't anymore what it used to be, as far as I am concerned. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM secure z/OS software delivery: Don't get locked out!
> Just because I specify deliverycb-bld.dhe.ibm.com doesn't mean that when > it resolves that it is the same: > > Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21 > > I ran into this with our Firewall weenies and it took a bit of work for them > to get it right. > > This may not be exactly as Barb was stating but it is in the ballpark. This sounds like what we are seeing - the firewall complains about a missing certificate for site deliverycb01-bld.dhe.ibm.com which is what gets shown in the browser. I don't even get to the download JCL. I can access the file to download when I manually remove the 01 - then the certificate matches the site. Thanks Kurt for talking to the site owners... Never mind that both my colleague and I apparently got it completely wrong - we both thought it is download to a work station using https. I don't think direct z/OS access is allowed here. I'll ask next week when I am back at work. Thanks Kurt for clarifying my/our misunderstanding. Barbara Oh, and by the way - download director is a definite no-no here. It immediately complains that our java version is out-of-date. None of us has installation rights, so even if we click the helpful link to upgrade java - it requires admin rights that we don't have (and are unlikely to get) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM secure z/OS software delivery: Don't get locked out!
Kurt, we do have a problem with https download because the certificate we have is for one part of the website, but the test adds a 01 inside, and the corporate firewall objects to that (I am currently home so I cannot name the full url). When we manually remove the 01 in the url, we are able to get past that certificate failure, but we don't get the popup asking where to store. Our firewall guys think it is an IBM problem, and they don't want to make exceptions for every number that could be in that url. What do you think? (Hold your fire against me - I am just repeating what I was told, I know nothing about the rules governing this). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EAV bug or feature?
> One of the things I found appalling is that there is not a single > example of how to allocate an EAV dataset in the cylinder-managed space > anywhere in any IBM doc. You can find EATTR=OPT if you know to look for > it, but do a search on how to allocate an EAV dataset. Nothing. When I tried that on an ADCD system about two years ago with my own 10cyl EAV, I found the same thing. I got lucky in that I had some presentation handy that directed me to the EATTR attribute. I remember that I spend almost an hour trying to figure it out. > So if you want to use EAV's, make them SMS. That way you can set > EATTR(OPT) in all your DATACLASses and fuhgeddabotit. Non-SMS EAV's > don't make a whole lotta sense, unless updating thousands of JCL members > is your thing. I *was* using an SMS-managed EAV. I went through several iterations in the dataclass until I got it right. I promptly forgot how I did it, though. All I needed was the track managed space filled with a huge (but empty) data set, and then a small data set in cylinder managed space, just to have an example for testing. Of course the product(s) were unable to deal with DSCB8/9's. I remember that I had not gotten the management class right, so the huge thing got migrated to ML1 (since it was basically empty, it apparently got severely compressed). Let me tell you that it was a real problem trying to recall that data set, because it didn't want to go back to the one and only EAV and failed allocation on my small mod9's. I think I ended up hdeleting it and reallocating. :-( Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SURVEY] What ISPF terminal model do you use
> Hi Barbara, > > I use Attachmate Extra also. Depending on what I am doing, I use mod 2 > (24x80), mod 3 (32x80), mod 4 (43x80), or mod 5 (24x132). It depends de on > what I am doing. I also have 12 sessions defined, some with different > background colors that I only use for one lpar. Open your session tab and you > should be able to set the model number for that session. Depending on your > VTAM setup you may also need to use the long longon format for example ~ LOG > applid,S3270R4q > > Since you are getting mod5, you should be able to at least get more lines on > your screen. The Attachmate Extra I have been using is very old. Linda, I went to Tom Brannons site and discovered that Vista3270 can be used on a trial basis. Had to do some guessing as to the port to use (different on each system), but I managed to connect to all systems I have to work with. Setting the screen colours to a white background was easy (certainly easier than customizing Attachmate). I showed off Vista3270 to my colleague(s), one of which also downloaded and installed because he needs more lines than Attachmate offers and a wide display. I also made them envious by showing them that the mouse scroll wheel works on 3270! :-) Thanks to Tom Brannon! Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SURVEY] What ISPF terminal model do you use
> Can anyone tell me where this is? Don't see it under Options, 6. Set screen > characteristics... ISPF options 0, when you only have 24 lines it is on the second screen. Additionally, your 'logmode' has to match and you have to have your emulation set to accept the largest screen size it can handle. If the 'logmode' is one of the ones that allow the emulation and IP to query each other and agree on one size during connection establishment, then it comes down to 'only' specifying the screen size you want in the emulation, the rest is set automagically. >Tom Brennan is too modest to peddle his product, so I'll do it. Get a copy of >Vista3270. Screen size flexibility is only one of its many virtues. I would if I could install anything on the office equipment. Unfortunately just about no one has local admin rights. :-( Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SURVEY] What ISPF terminal model do you use
> Barbara - I've been trying to find a way and so far (at least up to > Attachmate release 9.3) have not found a way. Pity. I can hope that the new emulation they want to use can handle it. (Saying in German: Hope dies last - die Hoffnung stirbt zuletzt). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SURVEY] What ISPF terminal model do you use
> On Thu, 10 Mar 2016 21:45:48 +0800, David Crayford wrote: > >What screen size do you use? > I would love to use the standard 62x162 screensize (and have for the past 7 years or so), but unfortunately my new employer uses an attachmate extra emulation that can only do 27x132. Does anyone know if I can fool attachmate into a larger screensize (like I could with PComm before it offered 62x160) by editing the parameter file? Having only 27 lines severely limits my productivity. :-( Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Identifier in low level qualifier of name of temporary data set
> Again there once were more members in the plex, but where would I find that
> number? D XCF tells me the names of the systems, only.
Do an ADRDSSU print dump of the sysplex CDS (or use review to browse online).
Then you should be able to see the names of the long gone systems. I cannot
check right now, but there may be XCF/XES messages at IPL telling you the
number ('id') of the just IPL'd system. Check for that number for the currently
active systems and use the appropriate position in the entries for the long
dead systems to verify if that is the number used. In any case, you can just
count system names shown - they get filled from the start, AFAIK.
While that number was my suspicion, too, I don't know if there is an interface
that lets a component other than XCF/XES use that index into the CDSs for
identification purposes. To the best of my knowledge, that number is XCF/XES
internal only. But I may be wrong.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: rsync anyone?
> Q). Does anyone have a better way to move a directory that has files and > subdirectories to a different LPAR? Or do you just keep installing the same > code for each instance? Not sure it is a better way, but when I migrated to 2.1, I converted all ZFSs back to HFSs since I find them infinitely easier to handle. I used bpxbatch: //S1 EXEC PGM=BPXBATCH //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDPARM DD * sh cd /u/zfs;su;pax -rwvCMX -p eW . /u/hfs Setting the directory to what you need to copy will copy just about anything including permissions, uids and gids. I also had security problems doing this on the originating system where I tried it first. When I went into OMVS and used an OMVS shell to issue the pax command, everything (including all ownerships) were correctly copied. Using bpxbatch I saw RACF messages for DIRACCESS, and some ownerships were lost with some error message that I haven't kept. I needed the output for reference and I wasn't familiar enough with the commands to pipe it somewhere. I ended up doing the conversion on 'my' system, and here it worked like a charm using bpxbatch. One problem may have been that IBMUSER (who owned most of the files since they were installed under IBMUSER) on the originating system had a uid of 2 (not 0!). I remember that I did quite a bit of reading on the shell and I even changed some settings for my own userid, but I was unable to determine why I got the errors on the originating system. As far as I could see, all RACF definitions were in place on both systems. On 'my' system, I ended up correcting ownership to 'my' RACF database and its uids/gids, which looked like this: //S1 EXEC PGM=BPXBATCH //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* //STDPARM DD * sh su; find /u/mp1 -group 1 -exec chgrp -h 0 äü ';' or another command: sh su; find /u/mp1 -user 9500 -exec chown -h 0 äü ';' I was quite proud of myself of recognizing the codepage problem. :-) Of course, this was all a one-time effort on my part. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Coupling Facility Structure Re-sizing
> 1) Should INITSIZE and MINSIZE always be specified? I have always specified both, and I have always made them equal. I had some unpleasant surprises when MINSIZE was smaller than INITSIZE. And I have always set INITSIZE to half of SIZE. > 2) Are all structures 'eligible' to be defined with these parameters? IIRC yes. If not, IXCMIAPU will tell you. > 3) Besides the ratio specified above, are their any guidelines for the > definitions? Check 'Setting up a sysplex' for general guidelines, considerations for individual structures are usually found where the product documentation is. Don't bother going to the PRISM guide (if that is still referenced in sysplex setup) - the CFSizer is pretty good instead. > 4) The sizer tool is based on current allocation which may not be ideal. Is > there a way to confirm if I have the best fit? Check the SMF records once things are set and change as needed. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Delete part of spool for active job
> In a case # 2 situation, you could force the job to be swapped out > unconditionally by quiescing it: E jobname,QUIESCE. This might give you some > time to purge enough unneeded output to be able to login to TSO and perform > further actions. Actions might be to save the output to a data set then > cancel the job or allocate new spool space and let the job continue (E > jobname,RESET), or whatever suits your needs. Good idea, but have you had only a z/OS console in a 100% spool shortage recently? Problems I encountered in that situation: - Logon not possible - The system's console had an American keyboard layout (on a really stupid 3270 emulation that doesn't know the difference between ctrl and enter, remote login) and my actual keyboard is German: Just issuing the JES2 commands with all its special characters to determine *which* was the offending job became a nightmare. - Cancel command of offending job got accepted, but the job did not terminate (because it needs spool space to terminate - TGSs were at 100%) - Job had to get forced (force arm also didn't work). - I am used to using SDSF, so using the JES2 commands (aside from the keyboard issue) to purge the offending job was a real challenge. The first time I hit these problems, I learned my lesson: 1. Always keep a spare spool volume (or two) around and have written notes on how to activate that. Also, keep in mind that some JES shortages (I forgot which) prevent the addition of new volumes, IIRC because that also needs *some* spool space. (An ADCD system comes with a minuscule spool, and I went through some iterations for increasing check point sizes, too, to accomodate the larger spool.) 2. Always keep some older output around that can be purged so that the TSO logon can succeed (even if I understand the zeal to have the JES2 spool as empty as possible). Always attempt to logon before purging anything. If you're able to logon, first save the offending output (even if it gets a B37) so you have some chance of problem determination. 3. All else failing, have an established procedure for a JES2 cold start, *especially* if you run a monoplex. 4. Have automation procedures in place to cancel a job consuming more than 50% of spool space (I had to change the JES init parms to accomplish that). 5. Have automation procedures in place to report shortages before they hit 100% (jobs are not executed anymore or new address spaces started once you're in 100%). The primary goal in this situation is always to logon to TSO again. Some installations have a local non-SNA TSO user that is always running and never logs off. At least that allows for easier problem analysis (aside from the keyboard issue), but I was unlucky enough having to purge a job that the logged-on userid didn't have RACF access to, and the userid didn't have RACF SPECIAL, either. I firmly believe that Murphy's law applies in any JES2 shortage! :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S00C Slip trap for any Stc
abend00C always means some problem with coupling services. If you don't know
which connector will be hit for which structure/group, I suggest to set the
slip trap rather generically as
sl set,c=00c,a=(cu,h,s),dspname=('xcfas'.*),id=s00C,e
Not having tested this for correctness, the a=(cu,h,p,s) should ensure that the
current address space along with any home or secondary address space get
dumped. And you may want to include XCFs data spaces, and maybe other data
spaces (depending on the problem). Just make sure that your maxspace is large
enough, especially if you're dealing with DB2. Maxspace needs to get set
beforehand.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S00C Slip trap for any Stc
> Please show the full error message(s) why the 'a' is invalid. Perhaps Barbara > and your z/OS systesm are on different versions. As I said, I did not test this for syntactical correctness. The a should stand for asid, and I am sure that the (cu,h,s) are correct. Check the manuals for what the actual filter keyword is, it may be j (for jobname to be dumped). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Is first page always backed by real storage upon return from STORAGE OBTAIN?
Peter, > I'm allocating 10MiB, that is to work like fill page, I assume. IPCS tells me > the full page is X'00', so there is nothing written in that page. > As said in another response, it's pure curiosity. ask IPCS if the first page is really backed (ip rsmdata virtpage ra(x'page address')) and check the flags in the output. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Authorizing 8 char technical userid to use TSO CONSOLE command
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED IKJ55353I THE CONSPROF COMMAND HAS TERMINATED.+ From what I have read in the FM and in the archives of this forum, I tend to conclude that there is no way to authorize an 8 character userid to use the TSO CONSOLE command, is there? Additional Q: Does anyone know where the default attributes mentioned in msgIKJ56644I are documented? No, I don't think there is a way to define a valid 8 character TSO userid. If you look at the description of IKJ56644I, you are refered to SYS1.UADS. A userid is defined to sys1.uads using the TSO ACCOUNT command. The TSO/E Administration book in chapter 2.1.2 'Selecting a userid' states that it can only be 7 characters long. I imagine the rest of the default attributes are described under the ACCOUNT command. I recently went through the account command exercise when I changed to a different sys1.uads... Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
