Re: CDE *PATHNAM
Miklos Szigetvari wrote: If someone knows how to find out the OMVS path name (module name ) from the CDE(Contents Directory Entry) The CSVQUERY service should give the information that you want. See the OUTPATHNAME option of that service. Bob Wright - MVS Service Aids -- 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
Re: CONVTOD--ETODVAL Year Input Still Limited to 2042?
Art Celestini wrote: I'm testing some code on z/OS 1.5 and find that CONVTOD will not accept a year greater than 2042, even though an ETOD is requested. Does anyone know if there is an APAR that extends this limit? I'm trying to use it for date calculations that could, potentially, involve dates that are 100 years into the future. If you don't get the result you want, take a look at BLSUETOD/BLSUETID as documented in z/OS MVS IPCS Customization. Both take two parameters. The first goes from 16-byte STCKE value to 26-byte time stamp, and the latter goes the other way. They've been available since z/OS V1R4. -- Bob Wright - MVS Service Aids -- 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
Re: ipcs query
mary george wrote: We have got a sysdump in our shop for a LE abend. When we tried formatting it by first setting the dataset to IPCS,instead of getting ASID we got RBA. When we tried few basic commands on the dump dataset using IPCS it says, BLS18100I,HEADER 0168 not available for BLSRPRD BLS18104I,Symbol CVT not found BLS18104I,Symbol ASVT not found BLS17543I,Select service could not obtain the ASVT BLS17541I,No address spaces with the CURRENT attribute were found BLS17541I,No address spaces with the ERROR attribute were found Does this mean that the dump is not usable? The most common reason for seeing this is copying your dump to a RECFM=FB data set with an interesting BLKSIZE. IPCS requires RECFM=FBS in order to calculate relative record addresses, so it decided that you might be interested in viewing it just as a data set containing a sequence of bytes (RBA view of the thing) and did not attempt to generate a view of the dumped z/OS system. That's the bad news. The good news is that you probably copied the dump using a tool that, in fact, produced a RECFM=FBS data set but didn't add the S for standard length blocks. This has happened so often around our shop that I have a little CLIST that allocates the dump as SYSUT2 for IEBGENER, specifying DISP=MOD and RECFM=FBS. SYSUT1 is a dummy with similar attributes. The result of copying the empty data set at the end of the one that you have is to rewrite the EOF record and to update the DSCB to say that the data set has RECFM=FBS. After doing this, use DROPDUMP and restart your dump analysis. It should go a lot better. Note: The above is not a panacea. I've also seen folks FTP dumps with translation and tell transcription programs that some of the 4160-bytes in dump records really weren't all that important! The targets of those transcriptions were useless. Check what you have as a starting point before bothering to try the recipe for in-place repair. -- Bob Wright - MVS Service Aids -- 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
Re: IGVFSMAN 0C4 (was IPCS missing module)
Mark wrote: May I ask how one goes about getting those libraries? I believe that I'll be potentially looking at dumps from any z/OS system. This suggests that I'll need to find libraries for the all the various releases. Mark, if, as it sounds, you function as a vendor for z/OS products, you'll want to contact IBM vendor relations. Hopefully, one of the many vendors who use this forum can give you a specific email address to start you off. I presented at a vendor disclosure session some time ago where the topic of establishing a distribution process for these libraries was suggested, and everyone in the room at the time seemed to agree that it would be a good thing. Someone from the IBM Dallas contingent of vendor relations folks took it as a to-do to follow up and get back with the group. I lost track of what happened since then. -- Bob Wright - MVS Service Aids -- 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
Re: How to find fetch protected area
Al Slovacek wrote: To determine storage key/fetch protection: 1) Initialize (or reinitialize) your dump with the MACHINE option. There is no MACHINE option at the time that you perform dump intialization. 2) When asked to use summary dump info, specify NO (for full init) if prompted. If you're running z/OS V1R2 or later, reinitialization is not needed, and it may be counterproductive to suppress the use of summary dump data. Starting with that release SDUMP dumps summary dump data in page increments and collects the storage keys of the pages dumped. 3) In option 1 while browsing storage Locate the area of storage: (6dd0 is the example used here) type in on the command line IPCS LIST 6dd0. 4) The following is displayed: LIST 6DD0. ASID(X'0243') LENGTH(X'04') AREA ASID(X'0243') ADDRESS(6DD0.) KEY(88)= First nibble is storage key, second nibble is fetch protect bit 6DD0. 6DD0 The 2nd nibble also contains the bits associated with reference and change monitoring, but they're not necessarily useful when you're dealing with an SDUMP. -- Bob Wright - MVS Service Aids -- 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
Re: Multiple SYSMDUMP in a dataset
Miklos Szigetvari wrote: We produce SYSMDUMP's with DISP=MOD, and the SYSMDUMP dataset contains a number of DUMP's Any method to select the second etc. dump? ( I see I could use GENER to copy from the 'DR2 H' header) Any better idea maybe ? Using DISP=MOD is a good idea. ISPF, for one, can see some applications ABENDs that produce dumps and, in turn, conclude that its physical screen task is a potential villain. When that happens, you'll get two, related dumps from a single incident. The first, generated closest to the point of error is likely to be the best one, and it can be directly examined using IPCS. The header record for the 2nd will be treated as a logical EOF for IPCS purposes. But you asked about the 2nd, 3rd, The IPCS COPYDUMP subcommand was designed to address this situation, allowing you to manually walk through the contents of a data set and select which logical dump(s) that you want copied to data sets by themselves. The many return codes that can be generated should, in principle, also allow you to come up with a command procedure that helps you perform the processing your way. -- Bob Wright - MVS Service Aids -- 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
Re: Multiple SYSMDUMP in a dataset
Don Poitras wrote: Another method of handling programs that produce multiple dumps is to use FREE=CLOSE to allow multiple dump snip FREE=CLOSE is a problematic API to exploit. I'm fairly certain that we've (MVS element of z/OS) never documented that SYSMDUMPs are opened just once per logical dump, and that's true of most applications that I've encountered as well. While it may be true of someone's current implementation, foreclosing a design option for the future is rarely done. -- Bob Wright - MVS Service Aids -- 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
Re: 3290 datastream question
[EMAIL PROTECTED] wrote: I'm trying to understand the special magic inside the 3290 terminal that enables it to do VSPLIT in ISPF. My problem is I don't have access to real 3290 hardware to trace the datastream. Would someone of you be prepared to email me a sample trace of the datastream ? I'm intrested in particular in the datastream during ISPF initialization and what happens when the VSPLIT command is entered. (I'm realy not after your password) There is a book online, 3270 Information Display System Data Stream Programmer's Reference, Document Number GA23-0059-07, that talks about partitions. It also discusses a read partition query order that permits an application to ask a 3270 what features, including partitioning, that it supports. The 3290 is the only hardware that I've encountered that ever supported software partitioning as described in the book. It also supported hardware partitioning, allowing it to imitate four distinct 3278s, albeit with orange and black appearing rather than the usual pair of colors. I live within the IBM firewall, and I got to the book by using the following URL: http://ehone.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US. I was able to download a copy in a few seconds via a broadband connection. The book will likely tell you more than you really want to know about the subject. -- Bob Wright - MVS Service Aids -- 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
Re: Userids
Barry Merrill wrote: It's my understanding snip The story is largely apocryphal but much simpler and more entertaining than what occurred. -- Bob Wright - MVS Service Aids -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In reaction to the recent DUMMY and ISPLOG BLKSIZE=0 thread, I did a test with the following: //GENEREXEC PGM=IEBGENER //SYSPRINT DD DISP=(NEW,CATLG), // DSN=SYSUID..IEBGENER.SYSPRINT, // DCB=(RECFM=FBA,LRECL=121,BLKSIZE=0), // UNIT=SYSDA,SPACE=(TRK,1) (Note this is SYSPRINT, not SYSUT2.) The characteristics of the created data set are: Data Set Name . . . : user.IEBGENER.SYSPRINT General Data Current Allocation Volume serial . . . : TSO002 Allocated tracks . : 1 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PS Record format . . . : FBA Record length . . . : 121 Block size . . . . : 121Current Utilization 1st extent tracks . : 1 Used tracks . . . . : 1 Secondary tracks . : 0 Used extents . . . : 1 This BLKSIZE does not appear to be the SDB supplied value (a similar test with IDCAMS REPRO gives 27951). It has been my perception that it is IBM's policy to allow SDB to operate on utility output rather than forcing a BLKSIZE in the utility's code. Should this be reported to IBM? (And how is Utilities Development likely to react in view of the recent waffle on the IEBGENER PARM='SDB=YES' default waffle?) -- gil Try again with DSORG=PS added to the DCB attributes. I don't have a book detailing SDB requirements nearby, but I seem to recall that the DSORG must be PS and known to data management in time to apply SDB. -- Bob Wright - MVS Service Aids -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In a recent note, Bob Wright said: Date: Tue, 31 May 2005 11:45:55 -0400 Try again with DSORG=PS added to the DCB attributes. I don't have a book detailing SDB requirements nearby, but I seem to recall that the DSORG must be PS and known to data management in time to apply SDB. Bingo! That makes the difference. I'm somewhat surprised; I would have believed that the call to OPEN supplies all information necessary to determine DSORG, and SDB takes effect fairly late in the OPEN process (after the DCB EXIT), when DSORG should have been fixed. And puzzled further that REPRO causes SDB to be applied. I suppose the difference might be that REPRO places DSORG in the DCB before OPEN whereas IEBGENER doesn't. (Would PO work as well as PS?) Thanks, gil You're welcome. I thought that we'd bumped into something like that in the course of some service aids development where we had an old DCB that didn't specify DSORG, leaving that for a DCB OPEN exit to supply. I have no idea why IEBGENER would be going that route, but it certainly needs to be available to OPEN before a DCB OPEN exit to implement SDB. -- Bob Wright - MVS Service Aids -- 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
Re: How to Display Data from a Dataspace using IPCS ?
[EMAIL PROTECTED] wrote: I'd like to analyse data in a dataspace returned by MCSOPMSG using IPCS. I produced a system dump and have the access register's alet value. But how on earth can I display the data in this data space using IPCS. Search the archives at http://bama.ua.edu/archives/ibm-main.html What you need to do is to get the ASID and DSPNAME that name the data space. The NAME subcommand is intended to help with that task, and you may have reason to know the values without the use of that subcommand. Once you know the name of the space, just supply the address within it plus the name to any of the IPCS functions like the browse option of the dialog. -- Bob Wright - MVS Service Aids -- 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
Re: How to Display Data from a Dataspace using IPCS ?
Knutson, Sam wrote: You can tell what's in a dump including data spaces use this IPCS command. listdump dataset(your.svc.dump.dataset.abc) select(attributes) That gives you what you need to use IPCS to access the storage in a dump if it is included. I'd recommend SELECT(DUMPED) as the option rather than SELECT(ATTRIBUTES). That's what you'll get if you enter LD to the left of the data set name when viewing the inventory in the IPCS dialog. Sam made a point of saying that that the data set name pertained to a system dump. SADMPs record main storage as ABSOLUTE, leaving it to IPCS (with a little help from RSM) to relate that storage to the ASIDs and data spaces that it backs. As a result, LISTDUMP won't necessarily see all of the data spaces that may be available after translation has been demanded. IPCS waits until you or your analysis routines ask about virtual storage before commencing translation. -- Bob Wright - MVS Service Aids -- 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