Re: CDE *PATHNAM

2007-08-09 Thread Bob Wright

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?

2005-09-12 Thread Bob Wright

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

2005-09-01 Thread Bob Wright

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)

2005-06-29 Thread Bob Wright

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

2005-06-27 Thread Bob Wright

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

2005-06-08 Thread Bob Wright

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

2005-06-08 Thread Bob Wright

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

2005-06-02 Thread Bob Wright

[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

2005-06-01 Thread Bob Wright

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

2005-05-31 Thread Bob Wright

[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

2005-05-31 Thread Bob Wright

[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 ?

2005-05-27 Thread Bob Wright

[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 ?

2005-05-27 Thread Bob Wright

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