Re: IPCS command , VERBEXIT collection

[Robert Wright]

Miklos Szigetvari wrote:
I see in the BLSXSUMT  REXX  exec comment , it is a part of  the 
"Level 2  toolkit", and I would like to have this toolkit  ...


If you have BLSXSUMT on your system, you have the "Level 2 toolkit".  Go 
into the IPCS dialog, and enter option 2.6i.  There will be a disclaimer 
at the top of the panel shown, a panel that strongly resembles the one 
that you see when using option 2.6.  The toolkit first appeared in z/OS R8.


--
Bob Wright - [EMAIL PROTECTED]

--
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: Trsmain Unpack

[Robert Wright]

Field, Alan C. wrote:
It's in OA24147. 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Cebell, David
Sent: Friday, September 26, 2008 10:30
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Trsmain Unpack

AMATERSE is not in our LINKLST.  z/os 1.6 ( S806 Not found)
Anyone know where this program resides? 

  
OA24147 was, indeed, the rollback APAR for AMATERSE, but it only rolled 
the formal support back to z/OS 1.7.  On 1.6 only the TRSMAIN download 
is available.  AMATERSE installs into MIGLIB, a linklist library, on 1.7 
and up.


--
Bob Wright - [EMAIL PROTECTED]

--
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: Trsmain Unpack

[Robert Wright]

Alan Schwartz wrote:

I'm testing the process to upload a PSP bucket of ptf's using an uploaded CSI 
to only get the ptf's I need.  Everything seems to be working and I've got the 
bin files on the mainframe. But when I try and unpack them I run into two 
problems.
 
1.  The job is abending with 878-08.  Here is the full message:

IEC028I 837-08,IFG055  
,TSYS001,UNPACK1,SYS1,10B1,QR0015,SYS08269.T142124.RA000.TSYS001.TRSTMP.H03
 
Here is the jcl:
 
//UNPACK1   EXEC  PGM=TRSMAIN,PARM=UNPACK,REGION=0M//SYSPRINT DD  SYSOUT=*  //INFILE   DD  DISP=SHR,DSN=TSYS001.INSTLIB.BIN   //OUTFILE  DD  DISP=(NEW,CATLG,DELETE),UNIT=(SYSDA,8),   // DSN=TSYS001.INSTLIB.UNPACKED,SPACE=(CYL,(600,100,50),RLSE) 
 
Obviously there's a dynamically allocated file that isn't big enough.  I looked in IBMlink but nothing matched there.  I checked the recent archives and found one thread that matched but the posters issue was with PDS-E.  This is coming via SRD and as far as I can see is documented as a pds.
 
2.  When the job abends the allocation messages show:
 
IEF285I   TSYS001.INSTLIB.UNPACKED  CATALOGED  IEF285I   VOL SER NOS= QR0015.
 
I have to delete the file before I can rerun   
 
Appreciate any ideas.
  
OA22765 discusses a circumvention of including a large data set 
associated with a TMPSPACE ddname in your JCL.  OA22765, itself, was 
closed as a FIN.  


--
Bob Wright - [EMAIL PROTECTED]

--
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: SYSABEND and 64bit

[Robert Wright]

Thompson, Steve wrote:

I have been asked to help an internal customer with a "dump" problem.

They want to use a SYSABEND  DD to get a dump of a job that they have
using above the bar storage (ATB).

Well, I've looked in a few manuals (INIT & TUNE, DIAG Tools & Srvc, MVS
Diag), and I can't find anything that needs to be set to include ATB
storage in such a dump. Problem is, I don't think SYSABEND processing
was ever set up to handle this because it would cause a line of storage
to be too long for the 121 byte format (if I calculate correctly, it
would take a line out to 130).

So, what manual and what keyword, if any? Anyone know?

[Yes, I am trying to get them to use SYSMDUMP or even an SDUMP macro so
they can use IPCS. Pudding and wall come to mind.]
  
Use of storage above the bar is one of the triggers for ending the use 
of formatting at time of error.  SNAP/ABDUMP doesn't go there.  If 
problems can be debugged without storage above the bar, keep using 
SYSABEND.  Otherwise, it's time to move to unformatted dumping.


--
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 Rexx Exec w/ISPF TBDISPL Services Options

[Robert Wright]

Todd Burch wrote:


modaddr = some_variable_determined_above ; 
pgm.1 = "/* rexx */" ; 
pgm.2 = "Address IPCS ""LIST" modaddr". LENGTH(256)""" ; 
pgm.0 = 2 ; 
Address TSO "ALLOC F(TEMP) DA(CLIST.CLIST(TEMP)) SHR REUSE" ; 
Address MVS "EXECIO * DISKW TEMP (FINIS STEM pgm." ; 
Address ISPEXEC "SELECT PGM(BLSGSCMD) PARM('%TEMP') NEWAPPL(BLSG) PASSLIB" ;


.
.
.

(the above typed from memory - not copy/pasted from my working exec) 


So it's clunky.  Plus, if running the first time, if member TEMP does not
exist in CLIST.CLIST, it blows up, so for production use, I would have to
add logic to determine if it already exists, if not, blah blah blah.  

I tried to do this, but it didn't work: 


text = "IPCS LIST" modaddr". LENGTH(256)" ;
Address ISPEXEC "SELECT PGM(BLSGSCMD) PARM('"text"') NEWAPPL(BLSG) PASSLIB" 

or some flavor thereof, and that did not work.  Thus the clunk.  
  
I don't see your rationale for getting a data set into the picture.  
Instead of passing a LIST subcommand to IPCS, you should be able to pass 
an ISPEXEC request as though it were the original subcommand that you 
had in mind.  Skipping the quotation marks and substitution concerns:


   Address IPCS ispexec PGM(BLSGSCMD) PARM(list modaddr length(256)) 
PASSLIB


BLSGSCMD takes care of breaking out the subcommand/command-procedure 
invocation using what TSO I/O service routines call an instorage list.  
IPCS/TSO code lets your pass command names and operands in mixed case, 
folding those operands that need it to upper case during parsing.  I'd 
have to double-check whether the text interpreted by ISPEXEC needs to be 
in upper case as I've shown.


--
Bob Wright - [EMAIL PROTECTED]

--
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 Rexx Exec w/ISPF TBDISPL Services Options

[Robert Wright]

Todd Burch wrote:



When the user does select a line, (to drill into raw storage), I detect the
table row selection and successfully call Address IPCS "LIST ..." from
within the TBDISPL "do while" loop.  Here's where the trouble starts. 


 

  
If you want each LIST subcommand treated as a distinct ISPF transaction, 
use dialog program BLSGSCMD.  The API is documented in /z/OS MVS IPCS 
Customization./  Short output from LIST will be handled on the way back 
from the subcommand to your exec, allowing it to be reviewed until no 
longer wanted.  Long output can be partially viewed if that gives the 
user enough information without bothering to generate the entire report 
requested from LIST.  My recollection is that your "signal on halt" exit 
should not be entered.


--
Bob Wright - [EMAIL PROTECTED]

--
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: cbt

[Robert Wright]

Lizette Koehler wrote:
I am not sure if the requestor is doing this for education or 
if there is something missing that other tools do not provide.


I am thinking of the LKED Map or ISPF 3.4, etc.  Plus I believe 
that there are several free products that can do similar functions. (PDS?)


Possibly IPCS could also help?
  
Regrettably not.  Contents supervisor doesn't generally keep anything in 
storage (dumped or not) that would support identifying CSECTs within 
programs in memory.  The z/OS nucleus is the sole exception that IPCS 
component code exploits.  Individual components do tend to keep 
information around so that their ESTAE and FRR recovery routines can 
fill in that symptom accurately should ABENDs occur, but there's no 
generally-accepted place to look for that information at this time.


--
Bob Wright - [EMAIL PROTECTED]

--
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: UR1 vs FIN

[Robert Wright]

Roger Bolan wrote:
>
> FIN means "fixed in next", but this does not absolutely guarantee 
that there will be a "next release".  That's why you might have heard it 
as "fixed IF next".   It's generally used for certain kinds of changes 
that are only allowed to happen on a release boundary (like a 
significant change in the packaging protocol) or some other kind of 
really significant change that can't be done by just a PTF.


FIN really means "Fixed IF next" for good, legal reasons.  In addition 
to the situations that you describe for FIN use, it opens the door wider 
for customers to report nits that neither the customer nor IBM thinks 
warrant shipping more PTFs in the service streams for current releases. 
 OA25428, for example, let current IPCS developers know that a 
developer 14 years ago made a data entry field on one panel two 
characters too narrow to accept the widest item that can properly be 
entered there.  Hopefully, a lot of these irritants can go away as a 
consequence of similar FIN APARs.


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: AMATERSE big

[Robert Wright]

Miklos Szigetvari wrote:
Try to TERSE a 3 Gbyte input file, and got IKJ56245I ," dynalloc error, 
not enough space on volume " message,

Can I control this ?



See OA22765, an APAR closed as FIN because there currently is a 
circumvention.


"AMATERSE currently uses ddname TMPSPACE as an intermediate and
asks whether that file has been preallocated. Supplying that
ddname allocated to a large data set can circumvent the
problem."

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 RUNARRAY/CBFORMAT question

[Robert Wright]

Robert Wright wrote:


  PROC 0
  EVALSYM X CLIST(POSITION(P) LENGTH(L) HEXADECIMAL)
  CBFORMAT X+&P POSITION(0) LENGTH(&L.) MODEL()


Of course the CLIST would work better if the CBFORMAT subcommand took 
into account that the length in variable L had been formatted using 
hexadecimal digits:


  CBFORMAT X+&P POSITION(0) LENGTH(X'&L.') MODEL()

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 RUNARRAY/CBFORMAT question

[Robert Wright]

Gord Tomlin wrote:
Apparently I'm a bit thick today, but I cannot seem to get the results I 
want from the IPCS RUNARRAY subcommand when combined with the CBFORMAT 
command.


I have an array of control blocks in a dump, and I want to use a format 
model to display each element of the array. In a simple example, each 
element is x'19' bytes long and there are four elements. I entered the 
following command:


runarray address(2a401b00.) length(25) entries(1:4) structure
exec((cbf x model()))

Instead of seeing each of the four elements formatted, I see all but the 
first element truncated with zeroes replacing the data that actually 
resides at the storage locations:


LIST 2A401B00. ASID(X'00BA') LENGTH(X'19') ENTRY(X'+01') STRUCTURE
:2A401B00
   +  ENTRYFLG. 00NAME.   # 0001 
CPUTOT...   Z#...   ZCPUTOT.. 


LIST 2A401B00. ASID(X'00BA') POSITION(X'+19') LENGTH(X'19') 
ENTRY(X'+02') STRUCTURE

:2A401B00
   +  ENTRYFLG. 00NAME.   #  
CPUTOT...   Z#...   ZCPUTOT.. 

Control block is truncated

LIST 2A401B00. ASID(X'00BA') POSITION(X'+32') LENGTH(X'19') 
ENTRY(X'+03') STRUCTURE

:2A401B00
   +  ENTRYFLG. 00NAME.   #  
CPUTOT...   Z#...   ZCPUTOT.. 

Control block is truncated

LIST 2A401B00. ASID(X'00BA') POSITION(X'+4B') LENGTH(X'19') 
ENTRY(X'+04') STRUCTURE

:2A401B00
   +  ENTRYFLG. 00NAME.   #  
CPUTOT...   Z#...   ZCPUTOT.. 

Control block is truncated

The actual storage is as follows:
2A401B00. 00404040 40404040 4000 0100    
 
2A401B20.  0001    005C E4D5D2D5 
D6E6D500 
2A401B40.    D4E9F1C3  E2C3C8F7 0001 
0102 

2A401B60. 0102

Any suggestions as to how to get CBFORMAT to use the intended length for 
each array element?




Your focus on the length is on the wrong aspect of this.  RUNARRAY 
processes array entries by updating the POSITION attribute as you see 
from the model LIST subcommands.  The model processor assumes a zero 
offset as the origin of the list of fields that it processes, and all of 
the fields for the 2nd and subsequent array entries fall in the range 
prior to the "origin" of that array entry.  You can circumvent that with 
a command procedure, but I don't think that there's a single command 
solution to getting the job done, eg:


  PROC 0
  EVALSYM X CLIST(POSITION(P) LENGTH(L) HEXADECIMAL)
  CBFORMAT X+&P POSITION(0) LENGTH(&L.) MODEL()

When an offset is used in an address expression and the POSITION keyword 
is also used, IPCS sums the current address and offset values to form 
the logical address of the target and sets the offset to the value 
specified by the POSITION operand.  That lets your one model that 
assumes a zero origin work against each array entry - if you invoke the 
CLIST instead of directly invoking the CBFORMAT subcommand.


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: CTRACE writer peculiarity

[Robert Wright]

Richard Peurifoy wrote:


I have not used wrap, so I don't have any experience
with this. If I have some time, I will experiment.



You didn't mention an option that was introduced for both CTRACE and GTF 
in z/OS V1R7, VSAM linear data sets with a 32K CISIZE.  They can be used 
for either WRAP or NOWRAP purposes.  Striping is supported as is 
extended format (64-bit RBAs).  The striping option allows you to 
increase the effective data rate for recording, and extended format 
yields capacity.  Trace processing subcommands under IPCS accept them 
directly.  If you're experimenting, give them a try.


Bob Wright - z/OS 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: What is needed to run IPCS against 1.9 on 1.8?

[Robert Wright]

Binyamin Dissen wrote:

I steplib to the 1.9 miglib and miglibe. What else is critical?


In addition to the parmlib requirement mentioned by Charles Hardee, 
consider whether you will be interested in JES or other areas of the 
system where two or more instances may be installed.  You'll need to 
pick the program and parmlib libraries applicable to the ones that are 
actually of interest to you, adding them to TSOLIB and allocate 
operations that you'd use to prepare for use of the IPCS edition of your 
choice.  If they have supplied command procedures or materials solely of 
interest during an ISPF session, add in either the permanent allocation 
or the use of LIBDEF and ALTLIB to bring them into the picture during 
use of the IPCS 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: IPCSs hidden qualities

[Robert Wright]

Shane wrote:

Must be nice for Bob and his team to know where the product is going in
the next few years, and be able plan whether to have code in place when
it gets there.



You paint a lovely picture.  I wish I lived there  Like you we know 
a lot of things that would be good to do, and we know as much as a year 
before you what will arrive in the next release.  Beyond that things get 
muddy, obtaining funding for things that make sense, staffing with real 
heads versus virtual ones,   We're just middlemen at a different 
point in the loop.


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: IPCSs hidden qualities

[Robert Wright]

Barbara Nitz wrote:
 > Speaking of IPCS's hidden qualities: A former colleague showed me an 
IPCS full command named SYSTRACW, which is NOT available to customers in 
the normal product (I checked). This looked suspiciously (if very much 
better)like my old rexx/verbx combinations that takes a system trace and 
does an IPCS where on the relevant addresses. Saves tons of time 
analyzing loops and time delays.


Is there any chance to make that available publicly on an as-is basis with no 
IBM commitment to fix anything should a problem occur?

My former colleague also told me that there are any number of commands somehow in the product but neither documented outside IBM nor available in the product going out to customers, with the rationale, that IBM doesn't want to spend resources on supporting it. Funny thing is, the level1/2 people also don't really know its there much less how to use it. 


In many cases, this might speed up problem determination for a customer without 
going through the several-days/weeks-delays until the dump finally finds 
someone who not only knows which questions to ask but also how to interpret the 
answers. :-)



If you're running release 8 or later, take a look a dialog option 2.6i. 
 It's not advertised on the analysis panel, and the disclaimer on the 
2.6i panel hopefully explains why.


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 format the current linkage stack for a SLIP dump taken in SRB mode?

[Robert Wright]

Tom Harper wrote:


They should be formatted out towards the top of the SUMMARY FORMAT REGS
display. 



Minor correction "REGS" should be "regs".  The FORMAT option of the IPCS 
SUMMARY subcommand tolerates but ignores a "REGS" keyword as part of the 
invocation syntax.  Formatting of registers is always done.  The "REGS" 
option is only honored by the KEYFIELD report of SUMMARY.


The directions regarding where to look in the SUMMARY FORMAT output are 
excellent.


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: Help with TSO parsing?

[Robert Wright]

McKown, John wrote:

 talking to myself and feeling old...

I found the problem. I had a parse validation check routine which was
returning an invalid return code, causing the PARSE to fail.



You might think of removing explicit aliases DDN and DSN.  IKJPARS will 
recognize them as unambiguous truncations of DDNAME and DSNAME keywords 
unless the rest of the syntax is rather strange.


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: DCF (was Re: System z10 announcement (in English))

[Robert Wright]

Edward Jaffe wrote:

What software do they use?


It's a mixture of internal tools and some commercially-available SGML 
workstation products.  I don't think the details are confidential, but I 
don't know them beyond what I just said.  I briefly looked into using 
the "workbench" some time ago.


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 NAMETOKN Command

[Robert Wright]

Wayne Driscoll wrote:

Bob, thanks, but I guess I need to dig deeper into the REXX manuals.  I
haven't done a ton of REXX work in years, except for some IPCS stuff,
and this one has me stumped.  The token contains an address and other
data.  I was expecting that REXX(TOKEN(VAR)) would behave similar to
REXX(STORAGE(VAR)) does in the evaluate and set the variable to an
external format, since it doesn't, I need to find the REXX function to
get it into this format.


I'll defer to many who contribute to IBM-MAIN and use REXX more than I 
do to help with the conversion.  We'll add something like a FORMATTED 
(always as hexadecimal digits) versus UNFORMATTED (current default) 
option to the wish list for improving the NAMETOKN subcommand.  It 
would, as you suggest, make it easier to use NAMETOKN in situations like 
you describe and would make it feasible to use NAMETOKN reliably in a 
CLIST.  That said, we never know when priority activities will lighten 
enough to pursue items on the wish list.  Do polish your REXX skills and 
get it working with REXX builtins.


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 NAMETOKN Command

[Robert Wright]

Wayne Driscoll wrote:

Once again I find myself writing IPCS formatting execs.  My application
makes use of name/token pairs, and I am attempting to track down the
contents.  I know how to dig the contents out myself, but I would prefer
to use the supported method, but I am having a problem.  I issue the
command 
Nametokn ASCBnnn nolist rexx(token(tokeval))

And if tokeval changes from the pre-seed that I use, I know I have token
I am looking for.  All good.  However, the contents of the rexx variable
is unformatted data, so how do I utilize the data?  If I specify LIST it
is able to format the data, but I want to use the data for later
processing (basically I would like to perform in a program actions
similar to the actions done manually in the second example of the
NAMETOKN command in the IPCS Commands manual.


REXX provides you the means to break TOKEVAL apart into the bytes that 
have independent meaning to your application.  If some of that data 
yields a storage address or length, REXX can convert the binary value to 
an EBCDIC one that can be substituted into an appropriate IPCS 
subcommand to access the addressed data and the length of the instance 
referenced.  If the piece is truly EBCDIC and printable in the 1st 
place, no conversion is needed.


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: AMATERSE available (was: TSO TRANSMIT ...)

[Robert Wright]

Mark Pace wrote:

It was a surprise to me when I went looking for it on my freshly installed
z/OS 1.9 system and it was not there.



Check SYS1.MIGLIB.  You should find AMATERSE there with its TRSMAIN 
alias.  MIGLIB is forced into the linklist, so you have access to it 
without a need for a STEPLIB.


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: AMATERSE available (was: TSO TRANSMIT ...)

[Robert Wright]

Paul Gilmartin wrote:

On Tue, 29 Jan 2008 13:47:24 -0500, John Eells wrote:

See APAR OA19194, which makes AMATERSE, alias TRSMAIN, available on z/OS
R7 and up.  That's all supported releases since R6 is out of service and
AMATERSE is included in z/OS R9.  The PTFs closed 4 November 2007.  They
are:

UA36927 - z/OS R7
UA36928 - z/OS R8


If you say so.  But the IBM Enhanced Customer Data Repository Service
page at:

http://www-05.ibm.com/de/support/ecurep/mvs_create.html

appears to be unaware of this.  I'll try to contact them.


The PTFs closed in July, 2007, so we're just reaching the point in time 
where most customers would have AMATERSE installed since those PTFs 
didn't qualify as emergency service.  If you have TRSMAIN from the 
source described on that page, the data stream is compatible with AMATERSE.


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: TSO/REXX Does Not FREE Storage?

[Robert Wright]

Joe Denison wrote:
I'm having an issue with REXX EXECs (interpreted, not compiled) that seem to 
*not* free storage after they terminate.  Is this a known issue?  Has anyone 
else experienced this?  


It would be helpful if you could go at least one step beyond what you 
reported here to determine whether the growth that you're seeing is in a 
particular subpool.  Subpool 78 is intentionally shared by all TSO tasks 
to permit storage that should persist across command and other task 
terminations to do so, and authorized programs have the ability to 
attribute storage ownership to the job step TCB for similar reasons. 
The identity of the subpool would cut the list of potential culprits 
down significantly although it would hardly point at just one.


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: HLASM & HLASM Toolkit

[Robert Wright]

Jie J Zhang wrote:

There is only one product named HLASM Toolkit in the z/OS V1.9, which is 
chargeable. If I want to use HLASM only, do I need to order the toolkit? 
Or HLASM is included in z/OS V1.9, HLASM toolkit is totally a different 
product from HLASM.


John Eells already responded regarding the status of HLASM and the HLASM 
Toolkit.  The HLASM toolkit is a set of functions that add value to 
HLASM if you're doing a significant amount of HLASM coding.  There is a 
source scanning utility, ASMXREF, that produces a series of reports 
regarding source code.  There is also a symbolic debugging function that 
understands some optional data produced by HLASM and allows you to talk 
about locations in your program and DSECTs referenced by it 
symbolically.  Several other functions are also present.


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 in batch

[Robert Wright]

Frank Chu wrote:

We have a batch job that's worked reliably for the last 7 or 8 years 
that's stopped working when we moved to zOS 1.9 from zOS 1.8.  For some 
reason that I can't figure out, "BLSCPRNT CURRENT" is not processing any 
more.  Other parameter for BLSCPRNT works, just CURRENT is failing.


Nothing in the IPCS docs stand out and I didn't come across anything in 
the APAR database.  Anybody else come across this?


Our level 2 team has recently been working with a 1.7 customer who has 
been seeing a looping condition when running BLSCPRNT CURRENT.  I 
located some logic that clearly needed to be updated when dumps include 
data above the bar, a problem that doesn't appear to be the customer's 
specific problem with the CLIST.  We're currently poring over some 
output supplied where LIST and CONLIST options were turned on.


I'd recommend that you open a PMR and describe what is going wrong for 
you.  I hope it turns out to be the same thing and can be addressed with 
a single set of PTFs.


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: GTF or CTRACE

[Robert Wright]

Miklos Szigetvari wrote:


   To gather trace data from an application I can select GTF or CTRACE 
to write external trace data

 From the speed and  overhead which is the better choise ?

Apologies to those of you seeing this twice.  I responded first to my 
local newsgroup feed.


I agree with Mark Jacobs in recommending CTRACE over GTF.  GTF exploits 
the monitor call instruction and the limited monitor call masking that 
was designed in the mid-1960s.  Regrettably, as the system has grown 
more complex, the reliance made by GTF on the lowest-level serialization 
technique used by z/OS, disablement, has made it less desirable than 
letting components employ serialization as decentralized as possible 
during tracing - the CTRACE approach.


Unauthorized CTRACE APIs allow you to start exploiting CTRACE by (1) 
supplying a CTRACE statement in IPCS's parmlib input, (2) ensure that 
trace tables get dumped when appropriate, (3) write a component find 
routine, and (4) use trace entries that CTRACE's default formatting can 
format tolerably.  That's not a huge cost of entry, and subsequent 
action can improve your results incrementally.  The starting point of 
in-storage tracing lets your component tolerate tracing that would be 
excessive if an attempt were made to write entries to a data set,  one 
action that you might contemplate as an enhancement once you have 
implemented your tracing and tuned the level to balance density with 
intrusiveness.


Bob Wright - z/OS 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: Dynamic panels - calling rexx?

[Robert Wright]

[EMAIL PROTECTED] wrote:

I recently posted this

http://groups.google.co.uk/group/bit.listserv.ibm-main/browse_thread/thread/76ecb6f525fc3813/54b53d08aaca496c

Bob Wright was good enough to respond to, giving examples of dynamic
panels in
SYS1.SBLSPNL0 members BLSPDISD and BLSPDISP

Please could Bob or someone else also direct me to the rexx procedure
that invokes these panels?

More examples would be appreciated too.


The two panels that I mentioned to you are driven by a dialog program 
written in HLASM (PL/X-generated) that is part of an OCO component of 
z/OS.  Sorry, I can't share them with you, and I haven't written 
anything that uses dynamic areas in an interpreted language like REXX.


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: Using CSVINFO

[Robert Wright]

David Day wrote:

It doesn't on my system.  Bit is not set in the MODI data area returned.
- Original Message - From: "Robert Wright" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, December 04, 2007 2:34 PM
Subject: Re: Using CSVINFO


See "MODI_MINOR EQU X'04' This is a MINOR entry point".  That will 
correlate with alias entries.


Double-check how you're addressing the various sections of the data 
returned by CSVINFO.  MODI_MINOR appears in the MODI_1 section, and 
MODI_8_BYTE_MAJOR_NAME appears in the MODI_5 section.  That was true 
some time ago when I last used CSVINFO in my code.


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: Using CSVINFO

[Robert Wright]

David Day wrote:

Based upon a fairly recent discussion here on IBM-Main, I've changed my code to 
now use CSVINFO(as opposed to using LPDE's) to identify modules in the PLPA.  
The macro is coded CSVINFO FUNC=LPA,ENV=MVS.  My MIPR routine is getting called 
with a MODI data for both alias and real load modules, but I'm not seeing any 
indicator anywhere to tell the MIPR routine that the data presented to the 
routine is for an alias.  For instance, I get a data area for ICVTST01 with a 
load point and length identical to IGC0013I, prior to the data area for 
IGC0013I. ICVTST01 is an alias of IGC0013I.  To get the real name for this load 
module, do I need to use CSVQUERY?  Am I missing something in the MIPR 
processing that indicates the entry is an alias?   Any help would be 
appreciated.



See "MODI_MINOR EQU X'04' This is a MINOR entry point".  That will 
correlate with alias entries.


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: NCP Dump DCB

[Robert Wright]

Patrick O'Keefe wrote:

On Mon, 19 Nov 2007 08:52:37 -0600, Richard Pinion <[EMAIL PROTECTED]> wrote:


...Can anyone tell
me the DCB attributes for the data set that would accept an NCP Dump.
...


Ours, allocated in 1997, is RECFM=FBS,LRECL=2048,BLKSIZE=2048.
That is obviously a pretty poor blocksize.  I don't know if it is required
or just a very poor choice on our part.

Looks like the last dump was taken in 2001 so I know it worked with
those characteristics back then.  And I doubt the requirements have
changed since them.



NCP dumping suppport was originally done cost-effectively, exploiting 
IPCS's support for addressing a data set by relative byte.  At that time 
IPCS didn't support blocking, something that may explain the degenerate 
BLKSIZE you see.  In today's world, IPCS wouldn't object if you copied 
the data set to one with an efficient BLKSIZE.  I don't know whether the 
code on the writing side has ever been upgraded to utilize an efficient 
BLKSIZE directly.


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: Dynamic ISPF panels?

[Robert Wright]

Cloink wrote:

My company is soon to move away from something called Roscoe which has
a programming facility similar to ISPF/CLIST/REXX in TSO.

In Roscoe, 'on the fly'/dynamic panel definitions can be created to
display output and/or accept user input; these are especially useful
when accommodating either a 24x80, 27x132 or 43x80 screen size (or
even some other size if the screen is split).  Though I would like to
use dynamic panels for more advanced reasons too - i.e., I realise I
could have 3 different fixed panel definitions, and choose one or
other based on screen size, but I don't want to do that.

I have read ISPF/CLIST/REXX documentation regarding panel definitions
but can't find any mention of dynamically-created ones.  My only
remaining supposition is that it would be necessary to write a
definition to a PDS, and tell the rexx to look in that PDS for the
definition.

Does anyone know how best to create dynamic panel definitions?



Take a look at SYS1.SBLSPNL0 members BLSPDISD and BLSPDISP, the panel 
definitions behind two of the key screens that you see when you use the 
browse option (option 1) of the IPCS dialog.  They're set up to use a 
tiny portion of the screen face in a "fixed" manner and allow the 
program behind the panels to fill in the dynamic area as desired.  Even 
the "fixed" portion of the panel flexes to fill the width of the screen.


I haven't used the comparable Roscoe facility to determine how easy it 
might be to migrate code using one to the other, but a great deal of 
flexibility is there in ISPF.


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 CBF question

[Robert Wright]

al chu wrote:


I am learning IPCS and formating a control block using the model in IPCS.

I wrote a model using BLSQMDEF and BLSQMFLD, and compiled linkedited it.

The command CBF xxx MODEL(MODyyy) works fine. Most of fields look good and
readable.

However some fields are a double word STCK timestamp and some fields are a
double word which contains elapsed time in units of 16 microsecond. 


I'd like format it nicely in HH:MM:SS.n format. I have no problem with
formatting if it is normal batch assembler program.

Questions I have;

Is it possible to format it using the model only? I searched the archive and
found Bob Wright's response to a similar question (dated Jul 13, 2006),
however it shows how to format flags using an additional model definition. 



It is possible to rely on formatting support supplied with z/OS to do 
the formatting of interest to you.  The model processor allows a 
BLSQMFLD macro to say that your big data area contains instances of 
smaller data areas for which formatting support is provided by others, e.g.


BLSQMFLD NAME=BLSRDATC,OFF=ESSYD-ESSY,LEN=L'ESSYD,*
  DECODE,CALLCBF,NEWLINE,MODELNAME,STACK,VIEW=X'0220'

I extracted the preceding from one of the models supplied by the IPCS 
component of z/OS MVS.  Translated to English it says that an instance 
of a STRUCTURE(BLSRDATC) resides at offset ESSYD-ESSY and occupies 
L'ESSYD bytes.  IPCS is to invoke the formatter for that structure on 
the next occasion that a break between output lines comes along if the 
VIEW specified by the caller has any of the nonzero bits on in it that 
match the X'0220' mask.


Appendix D of z/OS MVS IPCS Commands lists roughly 6 pages of structures 
for which some special support is provided by z/OS.  Most of the ones 
listed include formatting support.  Your question would seem to point to 
the use of either TODCLOCK or TODCNULL formatters.  (TODCNULL considers 
an all-zero field of 8 bytes to be the absence of a valid TOD clock value.


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 L command returns KEY(??)

[Robert Wright]

al chu wrote:
> Does anyone know what KEY(??) means in the output of LIST command.
>
> I have the following output
>
> LIST 8BD000. ASID(X'0288') LENGTH(X'30') AREA
> ASID(X'0288') ADDRESS(8BD000.) KEY(??)
> 008BD000 LENGTH(X'30')==>All bytes contain X'00'

KEY(??) means that the dump records contained X'FF' in the slot where a 
storage key would have normally been placed.  It wasn't captured at the 
time of the dump.  You may be able to use RSM or VSM reports to get the 
missing information, assuming that their key data areas were included in 
the dump.


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: Anybody have an IPCS clist to disassemble?

[Robert Wright]

Binyamin Dissen wrote on 2007-08-02 17:17:40:

> Anybody have an IPCS clist to disassemble?

Starting  with z/OS V1R7 that should not be needed.  IPCS added support for
an INSTRUCTION data type and companion support in the LIST subcommand to
format small blocks of instructions.

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: Batch IPCS CTRACE commands

[Robert Wright]

Tom Schmidt wrote on 2007-07-26 15:09:39:

> I can't find BLSCBSUQ in the standard documentation either, but a google
> search revealed it from an old IBM Redbook ("Interoperability Between VSE

> DL/I and OS/390 IMS DBCTL").

BLSCBSUQ is a CLIST that is shipped in support of IPCS dialog option 5.4,
"Perform supplementary dump analysis".  It was designed to accept a short
command from BLSPBSUP that fit in the first 72 characters of one card image
placed into the COMMAND ddname.  If you have a long command that needs to
be performed by IPCS via that route or via the kind of JCL shown earlier in
this thread, the thought was that you would make that long command into a
CLIST or REXX exec and would invoke it via something like the following:

  exec 'my.clist(ctraceit)'

Frankly, we never thought of BLSCBSUQ as something that you'd use directly
in your own JCL, and the product documentation reflects that line of
thought.  It may be useful as a starting point for a CLIST of your own that
does things 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: RCFs (was Valid hexadecimal" (was: EBCDIC to HEX translation in Assembler?))

[Robert Wright]

I wrote on 2007-07-25 08:19:01:

> I found the following in the front matter of several books from the z/OS
> MVS bookshelf:
>
> --
>
> IBM welcomes your comments. A form for readers’ comments may be provided
at
> the back of this document, or you may address your comments to the
> following address:
>
> International Business Machines Corporation
> Department 55JA, Mail Station P384
> 2455 South Road Poughkeepsie, NY 12601-5400
> United States of America
>
> FAX (United States & Canada): 1+845+432-9405
> FAX (Other Countries):
>   Your International Access Code +1+845+432-9405
>
> IBMLink™ (United States customers only): IBMUSM10(MHVRCFS)
> Internet e-mail: [EMAIL PROTECTED]
> World Wide Web: www.ibm.com/servers/eserver/zseries/zos/webqs.html
>
> If you would like a reply, be sure to include your name, address,
telephone
> number, or FAX number.
>
> Make sure to include the following in your comment or note:
> v Title and order number of this document
> v Page number or topic related to your comment
>
> When you send information to IBM, you grant IBM a nonexclusive right to
use
> or distribute the information in any way it believes appropriate without
> incurring any obligation to you.

I found identical information in TSO/E, DFSMS, and DFSORT books.  ISPF
books carry similar statements, but they invite responses to
[EMAIL PROTECTED]  Look just inside the front cover of recent books for
invitations to supply feedback electronically.

Bob Wright - MVS Service Aids

Re: RCFs (was Valid hexadecimal" (was: EBCDIC to HEX translation in Assembler?))

[Robert Wright]

Peter Relson wrote on 2007-07-25 07:39:42:

> 
> Ugghh. The z/OS MVS books (i.e., the ones I am involved with) all have a
> page at the end "Readers' Comments -- We'd Like to Hear from You".
> I'm not sure why there is no electronic mechanism. I'll inquire.
>
> But that is not consistent across the z/OS elements, unfortunately.
> I'll ask about that too.

I found the following in the front matter of several books from the z/OS
MVS bookshelf:

--

IBM welcomes your comments. A form for readers’ comments may be provided at
the back of this document, or you may address your comments to the
following address:

International Business Machines Corporation
Department 55JA, Mail Station P384
2455 South Road Poughkeepsie, NY 12601-5400
United States of America

FAX (United States & Canada): 1+845+432-9405
FAX (Other Countries):
  Your International Access Code +1+845+432-9405

IBMLink™ (United States customers only): IBMUSM10(MHVRCFS)
Internet e-mail: [EMAIL PROTECTED]
World Wide Web: www.ibm.com/servers/eserver/zseries/zos/webqs.html

If you would like a reply, be sure to include your name, address, telephone
number, or FAX number.

Make sure to include the following in your comment or note:
v Title and order number of this document
v Page number or topic related to your comment

When you send information to IBM, you grant IBM a nonexclusive right to use
or distribute the information in any way it believes appropriate without
incurring any obligation to you.

-

My personal favorite, used often, is the internet e-mail address.  There is
a good, disciplined process to ensure that the comments get responses.

I don't have an answer regarding publications from other elements of z/OS,
but I'll look in tandem with Peter.

Bob Wright - MVS Service Aids

Re: IPCS Question(s)

[Robert Wright]

Charles Hardee wrote on 2007-07-20 10:16:57:

> What about simply another internal variable, similar to say, TITLE.
> One could then code
>
> For Page:   EVAL PAGENUM CLIST|REXX(STO(variable_name))
> For Line:   EVAL LINENUM CLIST|REXX(STO(variable_name))
>
> I mean, if one could dream and hope, I would think this might be the
> easiest to implement. I'm guessing here, but there's probably a table of
> keywords that are looked for, like TITLE, etc, that trigger an internal
> routine call rather than a read of the dump directory to satisfy the
> return of the value, maybe?
>
> Just a thought.
>
> In any case, I can and have coded my own page logic before but in this
> case, I didn't want to start the display generation on a new page, I
> just wanted to generate it right in line with headers when appropriate.
>
> Thanks for listening Bob, and the rest of the list as well.

IPCS symbol tables are attached to dumps, traces, or other data sources.
The information that you want to extract pertains to the current session
environment and is not necessarily related to such a source of data, but
the answer would change depending on routing to terminal, print, or both.
That's why I mentioned an EVALPAGE subcommand whose operands could be
designed to do several things. (a) Let you foreshadow message routing
options that you intend to employ shortly afterward.  (b) Indicate whether
the command procedure that was listening was written as a CLIST, REXX exec,
or ISPF dialog. (c) Select the information to be extracted rather than
having IPCS blast data into many times the number of command procedure
variables than you want or need.

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 Question(s)

[Robert Wright]

Charles Hardee wrote on 2007-07-20 08:22:06:

> Thanks for the info Bob.
>
> Unfortunately, this is a report currently being produced via code from a
> CLIST. I'm not sure I want to add much code to it, however, as the
> CLISTs are in the process of being converted to REX EXECs.
> In any case, your info seems to be something that would be available to
> a report interface written in Assembler, which I am not doing.
> If, however, your group ever decides to make the fields available to
> CLIST or REXX, I would be very interested in hearing about it.

Sorry I misread your original post as referring to HLASM code.  It was
clear about your use of a command procedure.  I guess I heard the question
I wanted to hear.  It finally registered when Kenneth Tomiak restated the
context.

I can't hold out a lot of hope that we'll get this sort of thing into the
product.  My nose would grow as I reassured someone that it would sell an
additional zSeries or z/OS system on one.  Designing and coding an EVALPAGE
subcommand would be a lot easier than justifying it.

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 Question(s)

[Robert Wright]

Kenneth Tomiak wrote on 2007-07-19 19:26:00:

> 
> I have not found a variable accessible to REXX or CLIST code to tell you
a
> current page or line location. You mention 'producing a report'. Who is
> producing the report? If your code, you count it in your variable. In the

> IPCSIVP I have that demonstrates using REXX for IPCS, under ISPF, there
is
> no page. Just a long stream of output.

Any CLIST, REXX exec, or compiled/assembled program to which IPCS gives
control in response to a subcommand is potentially a report generator.
IPCS recognizes one message routing destination, its print file that is
usually associated with ddname IPCSPRNT, that supports true pagination.
The other, the TSO terminal or ddname SYSTSPRT is a message stream without
formal pagination.  To gain consistency between the two, a program that can
see the BLSABDPL fields that I mentioned will see pseudo-pagination taking
place.  If both the print file and terminal are routing destinations
concurrently, the real print file pagination dominates the numbers.  If
only the terminal is the destination, IPCS picks dimensions of a
pseudo-page and keeps count based on those values.

There are no IPCS-supported built-ins for CLISTs or REXX execs that provide
simple access to BLSABDPL that is being used by IPCS to support them.  I
could cobble together some ACTIVE storage reference logic in either CLIST
or REXX that would accomplish that, but I hope that no one bothers to try
that in a production command procedure.  This is one area where individuals
coding IPCS extensions in HLASM enjoy a current advantage.  Command
procedure authors enjoy some advantages in other areas.

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 Question(s)

[Robert Wright]

Charles Hardee wrote on 2007-07-19 13:04:29:

> Does anyone know if there is a means of finding our what page and/or
> line on a page one is in when running IPCS in batch and producing a
> report using REXX  or CLIST commands?

Yes, look at BLSABDPL in maclib.  It contains the following:

ADPLLNCT DCH'0'   Line count per output page
ADPLLNRM DCH'0'   Current number of lines
* remaining on the output page

>
> Also, does anyone know if there is an IPCS list like IBM Main?

No separate list that I've found, and I own the component.

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: Utility to print tracks

[Robert Wright]

Clark Morris wrote on 2007-07-01 18:58:35:

> >FDRDSF can print any track on a volume, by cylinder and head (or range)
> Of course this facility should be highly restricted since this
> probably bypasses all dataset access checking.  This comment would
> apply to the other programs mentioned as well.

Indicting FDR on the basis of a "probably bypasses" premise is not fair.
If the program does not do that gratuitously, restricting access can
diminish productivity in your installation.

There is no reason to apply restrictions to SPZAP.  It makes no attempt to
circumvent normal restrictions that apply to the data sets referenced by
its SYSLIB ddname.

Blindly restricting access to a few programs is false security.

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: Utility to print tracks

[Robert Wright]

Rick Fochtman wrote on 2007-06-29 12:11:01:

> ---
>
> >>AMASPZAP opens the SYSLIB dataset with a DCB, not an ACB, so it can't
> >>open a VSAM dataset.
> >
> >z/OS MVS Diagnosis:  Tools and Service Aids disagrees:
> >
> >In addition, SPZAP can be used to inspect and modify data other than
> >executable programs. Examples of such types of data are:
> >
> >...
> >o A VSAM sequential or indexed data set.
> >
> -
> That's a bit of a surprise, Bob. When did that capability come to
> AMASPZAP? The last utility I knew of that could "ZAP" a VSAM cluster was
> the old VSAMZAP program, from (probably) 20 years ago. (I used it many
> times to good effect, and loved it!)

I don't have an answer for you.  I inherited the code several generations
of programmers after Don Ludlow moved on, and the module prolog offers no
hint of any changes to explicitly add the capability of working with VSAM
objects.  I do know that we asked inside IBM for anyone who had exploited
the capability within modern memory and couldn't find anyone at a time when
some DASD changes were being considered.  It doesn't appear to be the most
valuable thing that SPZAP does - barring input from IBM-MAIN contributors
or other customers to the contrary.

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: Utility to print tracks

[Robert Wright]

Rick Fochtman wrote on 2007-06-28 12:21:14:

> AMASPZAP opens the SYSLIB dataset with a DCB, not an ACB, so it can't
> open a VSAM dataset.

z/OS MVS Diagnosis:  Tools and Service Aids disagrees:

In addition, SPZAP can be used to inspect and modify data other than
executable programs. Examples of such types of data are:

...
o A VSAM sequential or indexed data set.

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: Utility to print tracks

[Robert Wright]

Mark Zelden wrote on 2007-06-27 09:36:19:

> Can you provide an example or more detail please of how to do this
> with IPCS?

OK, here's output from a session that I cranked up a few moments ago:

setd dsn('rlw.saveddir') local
IPCS
open dsn
IKJ56650I TIME-10:33:16 AM. CPU-00:00:01 SERVICE-36182864 SESSI
BLS18122I Initialization in progress for DSNAME('RLW.SAVEDDIR')
BLS18123I 3 blocks, 960 bytes, in DSNAME('RLW.SAVEDDIR')
IKJ56650I TIME-10:33:16 AM. CPU-00:00:01 SERVICE-36182929 SESSI
IPCS
l 0 ttr(1)

LIST 00. TTR(X'01') LENGTH(X'60') AREA
00. LENGTH(X'60')==>All bytes contain X'00'
IPCS
l 0 ttr(1) length(x'3000')
BLS18070I Storage description adjusted

LIST 00. TTR(X'01') LENGTH(X'0C00') AREA
00. LENGTH(X'80')==>All bytes contain X'00'
80. LENGTH(X'0B80')==>Storage not available
IPCS
l 0 ttr(2) length(x'3000')
BLS18070I Storage description adjusted

LIST 00. TTR(X'02') LENGTH(X'0C00') AREA
. E2C4  40404040 40404040   000
0020.    0290  00020800 004
0040. 40080D00      000
0060.      F0F0F040 4040404
0080 LENGTH(X'20')==>All bytes contain X'40', EBCDIC C' '
00A0. 40404040 40404040 00015C40 40404040  4040 4040404
00C0. C3E5  0001    006
00E0. 40404040 40404040 40404040 40404040  40404040 4040404
0100 LENGTH(X'01C0')==>All bytes contain X'00'
02C0. LENGTH(X'0940')==>Storage not available
IPCS

Since I was doing this adhoc, I managed to forget that the records of the
data set in question were limited to X'C00' bytes, so you see several
BLS18070I messages as I asked for 3 pages of data.  I truncated the lines
from the session on the right.  My session is a virtual 3290, so there was
a bit beyond what is shown.  Each block in the data set is being treated as
an "address space" that may hold BLKSIZE bytes and may be called by several
names, e.g. BLOCK(0) or TTR(1).  The whole data set can be viewed using the
RBA address space where the records are logically concatenated one after
the other - the rationale for scanning the whole thing before letting me
look at any specific block.

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: Utility to print tracks

[Robert Wright]

Alan Schwartz wrote on 2007-06-26 17:59:53:

> I'm scratching at some dead brain cells.  I'm thinking there was some
> utility, IBM or ISV, I had at some point that I could supply a TTR
address
> for some volume and print what was at that address.  Does this ring a
bell
> with anyone?

If your search argument is truly a TTR value, try using IPCS.  AMASPZAP
definitely doesn't do TTR arguments relative to the origin of a data set,
and my recollection is that ADRDSSU doesn't either.

IPCS supports TTR arguments against conventional data sets when it is
convinced that the record lengths may vary.  If you data set is truly
RECFM=F or RECFM=FBS, you'll need to use a ddname and override the RECFM
with one that qualifies.  IPCS reads and maps the entire data set before
honoring your LIST request, so you may want to avoid using it to show just
one record in a huge data set.

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: Finding the last IPL time

[Robert Wright]

Dave Cole wrote on 2007-06-25 14:45:28:

> Is there a way (an API or a cblock field) by which a program an find
> out the local time of the last IPL?
>

Check out IHAIPA in MACLIB.  Field IPAICTOD may give you what you want.
It's the value that you'll see as "IPL time" when you use IPCS subcommand
IPLDATA STATISTICS.

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 measure actual usage of BLSR buffers?

[Robert Wright]

Darren Gavin wrote on 2007-05-09 16:44:48:

> Far as I know there is no way to get actual usage statistics from any
> kind of buffering (zOS, VSAM(AMP), LSR, GSR, BLSR or IMS LSR's) unless
> it's a 3rd party product.

Check out SHOWCB ACB and the information that it makes available.  Of
course, that presumes that you have access to the source code and an
inclination to change it - a direct contradiction to the reason that you
are expected to use batch LSR.  If you have such access and inclination,
you can probably do a better job of employing an LSR pool than batch LSR's
one-size-fits-all processing.

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: SVCDUMP vs. SYSMDUMP (was SP230?)

[Robert Wright]

Pat O'Keefe wrote on 2007-04-19 15:05:53:

> On Wed, 18 Apr 2007 19:54:55 -0400, Craddock, Chris
> <[EMAIL PROTECTED]> wrote:
>
> >... You would have to look at the allocated areas within the
> >address space to see if there's any indication of who the "real culprit"
> >is. You can't get that from anything less than an SVC dump. Sorry.
> >
>  Oh, oh.   An assumption I've had for many years is about to get
> shot down.  What does an SVCDUMP give you that an MDUMP doesn't?
> Or are you just implying that you can get the SVCDUMP at a more
> appropriate place with a SLIP trap?

SYSMDUMP does only one ASID, and there is quite a bit of work done by the
code supporting SYSMDUMP to only allow you to see what your code could see
of the system.  Storage that was fetch-protected relative to your code
should not get into a SYSMDUMP since you own the data set where it is
placed.  SVCDUMP writes its data into a data set owned by the installation
and is presumed to be viewed only by trusted personnel.  RACF, DFSMS, ...
data can go there that would be inappropriate in a SYSMDUMP.

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: REXX Under IPCS

[Robert Wright]

Charles (Chuck) Hardee wrote on 2007-04-13 08:50:29:

> Does anyone know if a REXX EXEC can be compiled and linked into a load
> module and then executed within an IPCS session?

No, the compiled REXX load module format bumps into the logic within the
IPCS monitor that allows you to intermingle TSO commands with your IPCS
subcommands to the extent that they're unambiguous.  When IPCS runs what it
considers to be a TSO command, there is no support supplied for the TSO
command to communicate with IPCS services.  Use one of the other REXX
compiler formats if you want to compile an exec for use with IPCS.

I think that we got the restriction documented - briefly - at the time that
the REXX compiler developed their support.  If you don't find it where
you'd expect to find the documentation, please submit a reader's comment
form.  If the restriction is a significant inconvenience, please submit a
requirement.  At the moment I don't know of any really simple way to tell
IPCS that a module should be handled so that IPCS subcommands embedded
within it will be honored, but we'd take another look if it turns out to be
important.

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 Questions (two)

[Robert Wright]

John Ticic wrote on 03/21/2007 04:30:44 AM:

> Bob, I took a look at the IPCS manuals to get an update on some of the
new
> features. Good stuff!
>
> I couldn't find any information on the INSTRUCTION data type, but I tried
> it anyway on the pointer panel. Typing INSTRUCTION in the data area field
> results in FLOAT being substituted. Could you point me (no pun intended)
in
> the right direction.

Thanks for pointing that experiment out.  I just repeated it and got the
same result.  I also used the following sequence of subcommands to quickly
confirm that line mode support is intact on V1R8, the release we're running
on our production system:

  eq x iefbr14 module
  list x instruction

That worked, not that both of us didn't already know what it would show.
That tells me that our code that tries to keep the IPCS dialog in full
screen mode when you talk to IPCS via ISPF is the culprit.  I'll get it
fixed in a new release unless you or some other IBM-MAIN subscriber asks
for an APAR.

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 Questions (two)

[Robert Wright]

Charles Hardee wrote on 03/20/2007 12:31:45 PM:


> I have two questions regarding IPSC.

> 1) From within an IPCS oriented CLIST or REXX Exec, is there a way
> to determine what IPCS level one is executing under?

No.  You can glean a lot of information about the dump being processed by
looking at its header record, but we haven't created an intended interface
via which your code can ask about the level of IPCS.

> 2) The new OPCODE function is great, but I am really in need of a
> CLIST or REXX based disassembler that can be executed from within the
> IPCS environment. Has anyone seen anything like this?

If you're running z//OS V1R8, IPCS has support for an INSTRUCTION data type
that is formatted as an instruction stream much as the HLASM toolkit
functions show instructions.

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: AMASPZAP doesn't work

[Robert Wright]

Tommy Tsui wrote on 2007-02-12 04:25:28:

> After we migrate to z/os 1.7. ASMSPZAP does not work. Anyone knows why?
It
> only shows SYSLIB I/O ERROR. I have checked the blocksize and dataset
> organisation.  All definition seems correct.
>
> //FAMVSZAP EXEC PGM=AMASPZAP
> //SYSPRINT DD SYSOUT=*
> //SYSABEND DD SYSOUT=*
> //SYSLIB   DD  DSN=TEST.TESTXXX.LOADLIB,DISP=OLD
> //SYSINDD *
>  NAME TEST
>  DUMP TEST
>
> AMA101I SYSLIB I/O ERROR  5080READ  ,OUT OF EXTENT  ,BPAM
> AMA130I SYSLIB DATA SET NOT OPENED
>
Verfify that you have the fix for APAR OA15883 installed.  The symptoms
that you cite match one of the problems corrected by that fix.

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: Question about SVC 109

[Robert Wright]

Lindy Mayfield wrote on 12/21/2006 15:13:04:

> Can someone please tell me if I have gotten this right? (:
>
> SVC's are numbered from 0 to 255.
>
> From 0 to 199 are reserved for IBM use.
>
> SVC 109 is basically an SVC that can call an SVC from 0 to 255, and
> again IBM has reserved 0 - 199 for their own use.  This in essence
> extends the range of SVC's from 256 to 256*2.
>
> SVC's called by SVS 109 can only be type-4 SVC's.
>
> Why not type-3?  Nowdays, I cannot see any differences between
> type-3 and type-4.  Am I missing something?

SVC 109 is a distinct type-4 SVC in its own right, and it is a middle-man.
By the early 1970s when it was created, IBM was running out of the 128 SVC
numbers that we'd claimed for our own.  SVC 109 was part of the answer.  It
steals one of the GPRs that other type-4 SVCs might want to use as part of
their API and uses its contents as a function code.  The function code
determines which module, in turn, receives control from the middle-man.
The functional module(s) deliver the function(s).  SVC 109 has none of its
own.

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 & ASID

[Robert Wright]

Steve Thompson wrote on 12/19/2006 12:13:11:

> I'm working on a little problem. I have an SVCDUMP that contains more
> than one address space. I have a LARGE exec library for diagnosing
> various things.
>
> =20
>
> The problem is, I just can't seem to establish the ASID to be used for
> addresses, C/Bs, etc.
> 
>
> The problem is with FIND inside our REXX code. If we use SETDEF
> ASID(x'0043') (or some such), the FIND returns RC=4. If we put the ASID
> on the FIND it returns RC=4.
>
> If we do an =1; ; and set to the ASID we want with address "00." and
> then issue FIND for the same data, it finds what we are looking for.
>
> The RC=4 just doesn't tell us enough about what is wrong with the FIND
> in this case. It would appear that it is not a syntax problem because
> the FIND in question works just fine when the dump contains a single
> address space (via DUMP, SLIP or SYSMDUMP).

I would expect that FIND would yield consistent results if you specify not
only the ASID but also the range of addresses that you want searched.  The
FIND subcommand performs both the function that you get in ISPF from
entering FIND and the one associated with RFIND (PF5 usually).  If you only
specify ASID and no address range, the ASID option is ignored (just as
LENGTH, POSITION, ... would be ignored).  You need a literal or symbolic
address range to force FIND to think about searching someplace new.

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: Using DUMP command with the REMOTE option?

[Robert Wright]

Mark Zelden wrote on 12/19/2006 11:17:47:

> On Tue, 19 Dec 2006 06:39:19 -0800, Mark T. Regan, K8MTR
> <[EMAIL PROTECTED]> wrote:

>
> >So, I was wondering if that can be done using the REMOTE= along with the
> >SYSLIST= option?
>
> Yes
>
> >And in my case, the JOBNAME on system 1 would be TCPIP1, while on system
> >two, the JOBNAME would be TCPIP2; and the SDATA is different for each
also.
>
> Again, yes.   But the syntax can get tricky.   For example (not including
> SDATA differences):
>
> DUMP COMM=(TCPIP)
> R XX,JOBNAME=(TCPIP1),CONT
> R XX,REMOTE=(SYSLIST=(sysid('TCPIP2')))
>
> See the MVS Commands manual for more details.
>
> If you have a system specific parmlib (which you probably don't have)
> you could just issue RO *ALL,DUMP PARMLIB=xx (the IEADMCxx member would
> be different in each system specific parmlib).   If you do this often
> enough it might be worth setting up the different parmlibs.  I guess
> you could also set up a different symbol on each LPAR like IPDUMP and
> have it equal to XX on one system and YY on another.  The issue
> RO *ALL,DUMP PARMLIB=&IPDUMP or something like that (I haven't tested
> this).

The option with REMOTE has the advantage that you'll acquire one incident
ID to tie both of the dumps together.  Broadcasting DUMP commands may allow
you to associate the results via time stamps that are very close to each
other and the title that you supply, but the system will consider them the
results of separate incidents.

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 too calculate DASD requirements for SAD?

[Robert Wright]

Kees Vernooy wrote on 11/02/2006 10:06:26 AM:

> SAD has been optimized in the past to dump only what is needed, but you
> must count on a substantial part of CS plus what it needs from the page
> datasets. I would suggest at least 20 GB in your situation. There are
> also several options to speed up SAD to Dasd by using parallellisme.

Left to its own preferences, SADMP will dump all of main storage plus
things like LSQA and SWA from auxilliary storage.  All-zero pages of
storage are summarized rather than dumped as distinct, separate records, so
you'll see a lot smaller SADMPs generated early in an IPL than after the
full workload is in flight.  If there are some existing dumps that were
written to tape from this LPAR while a lot of system activity was going on,
that size would be a better estimate than the 20GB that you proposed.
Otherwise, 20GB wouldn't be a bad starting point.

Multi-volume SADMP data sets are the recommended targets for SADMP today.
Extended format data sets broke the 64K track per volume barrier in the
earliest release and their use of BLTs rather than TTRs allows them to hold
more blocks per volume that can be accessed by old programs, so we tend to
recommend their use.  If you can be generous with the volume count and
careful about making the paths to each volume independent, you'll see a
significant reduction in the time needed to record a SADMP and get back
into production.

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: REFR -- Real Intent v. Actual Use?

[Robert Wright]

Steve Thompson wrote on 10/25/2006 10:44:18 AM:

> REFR as an attribute, does this also imply that the code is
> self-relocating so that if the code is reloaded at a different place, it
> is still able to continue execution (of the task in flight)? So PRE DAT
> days, this would be an overlay type program, right?

REFR was intended to let the system know that it could re-fetch a module in
circumstances such as storage going bad or overlays being detected that
might impact the module.  As things like the ability to load from DCBs that
had been opened temporarily became prevalent, it became less practical, and
storage was becoming more reliable in the same time frame.  It's no longer
supported but the attribute has been retained.

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: Question on setting a storge alteration slip trap to take an SVC dump

[Robert Wright]

David Day wrote on 10/23/2006 01:00:09 PM:

> Since this is not an error situation, in the sense that there is an
> SDWA and such to be recorded and RTM2 area to look at, what do I
> tell the slip process to record such that I can go to the dump, and
> easily identify the task and PSW that is walking on a piece of
> storage?  The storage is in the private area of a multi-tasking
application.

SLIP considers the trapped context to the the equivalent of an "error
situation" for purposes of scheduling a system dump.  The task, PSW, and
registers are packaged as "entry to SLIP" data, and the dump title is
simply made "SLIP TRAP n" or something like that.  Some years back it was
realized that the dump title wasn't particularly informative, so SLIP also
makes the entire text of the trap available in the dump.  When the dump
reaches IPCS for dump analysis, you should be able to see most of the data
just mentioned in the inventory (title and first bytes of trap) or STATUS
REGS (PSW, registers, and task).  Even more selectivity is available using
symbols TCBCURRENT, REGGEN, REGCTL, PSW, and a few that I'm undoubtedly
forgetting at the moment.

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: TRSMAIN and Tape

[Robert Wright]

Lizette Koehler wrote on 10/12/2006 10:57:25 AM:

> I was going to use TRSMAIN to pack some SMF Data from TAPE data set
> to dasd for FTP process.  However the documentation for TRSMAIN
> states it cannot use tape.
>
> I do not understand why this is the case.  What is special about
> TRSMAIN and tape processing.  I would have thought it would just be
> simple BSAM writes of compacted data.  Can anyone shed some
> light on why tape is not handled by TRSMAIN?

TRSMAIN tries to include a size of the target data set so that its UNPACK
processing can do its job.  That's feasible if it depends on format 1 and 3
DSCBs for the input data set.  Tape input is harder to handle with the same
goal in mind.

   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: Command to clear Sysplex Dump Directory??

[Robert Wright]

If you defined your directory with the REUSE option, the IPCSDDIR TSO
command with that option will do what you want.

R.L. (Bob) Wright, z/OS MVS Service Aids, R4GA, [EMAIL PROTECTED]
Robert Wright/Poughkeepsie/IBM @ IBMUS (notes to notes)
IBMUS(RLW) (host to notes), PLPSC.RLW (MVS) or S390VM.RLW (VM)

George Dranes wrote on 09/26/2006 08:13 AM:

> I know there is a command which clears all entries from the SYS1.DDIR but

> I
> can't find any Docs for it.  Could someone point me to the correct manual

> or
> give me the command? Our dump directory is nearly full and I would like
to
>
> clear it without going into IPCS and manually deleting each entry.  I
know
> I've
> entered the command before but I've went totally blank.  Thanks for your
> help.

--
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: SVC Dumps and DB2

[Robert Wright]

Lizett Koehler wrote on 08/08/2006 04:02:23 PM:

> Will look at Compressed to see if it could provide any releif.

We have a large inventory of compressed dumps in Poughkeepsie, and our
experience suggests that you'll save around 40% of the space that you'd use
without compression.

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 BLSQMDEF

[Robert Wright]

Peter Relson wrote on 07/14/2006 07:27:21 AM:

> Here's an example from the TCB formatter, for the 3 bytes at offset
x'AD'.
> I'm not sure if it conforms to Bob Wright's recommendations, as it is
quite
> old. When in doubt, follow Bob's advice!
>
> BLSQMFLD NAME=TCBNDSP,OFF=X'00AD',LEN=3,VIEW=X'8280',DECODE
>
> ,...
>
> TCBNDSP  BLSQMDEF CBLEN=X'0003',MAINTLV=HBB5520,PREFIX=8,  X
>HEADER=TCBNDSP,OFFSETS=NOPRINT
> * -NDSP1 BITS --
>  BLSQMFLD SHDR=NDSP1HD,VIEW=X'FF08'
>  BLSQMFLD SHDR=DARTN,VIEW=X'8008',NEWLINE
>   
> * -NDSP2 BITS --
>  BLSQMFLD SHDR=NDSP2HD,VIEW=X'FC04'
>  BLSQMFLD SHDR=ABD,VIEW=X'8004',NEWLINE
>   

The only recommendations that I'd make if a similar model were being
composed today would be that it make maximum use of the mapping macro for
the data area.  That wasn't done with the model for the TCB, and there's
little rationale for going back and changing that since the TCB is
extremely compatible from release to release at the object code level.
However, you just have to know that this code knows about all of the
NDSP1-NDSP3 flag field bits.  A scan of source code won't easily tell you.

The example is helpful, however, to illustrate a number of things about
models.

o  VIEW=X'8280' in the initial model allows this one model to serve
multiple formatting purposes.  SUMMARY KEYFIELD can use it with one set of
view bits turned on that do not cause flag bit decoding to occur, and
SUMMARY FORMAT can use it to cause detailed formatting of all fields.  In
the former case, SUMMARY KEYFIELD need only avoid turning on any of the
bits on in the view mask that cause the three flag fields to be called out.
The TCB model is very popular and uses an elaborate combination of view
bits in its BLSQMFLD VIEW masks to serve all of the requirements placed on
it.

o  VIEW=X'FF08' and VIEW=X'FC04' allow a comment to be put out pertaining
to a specific flag byte having bits with related meaning on in it.
Subheaders are selected based on at least one bit remaining on after ANDing
with the flag byte itself.

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 BLSQMDEF

[Robert Wright]

Tom Harper wrote on 07/13/2006 08:54:40 AM:

> Got a question for a colleague about the IPCS macro BLSQMDEF, which is
> used for making control block models. I understand most parameters of
> the macro, with the exception of interpreting bits in a flag byte.
>
> The only way I know to make this work is to use a control block
> formatter module and pass the flag byte in ADPLPVC1 and then invoke the
> control block formatter to let the bits be defined as in the model. How
> can you get IPCS to format out the bits in a more straight-forward
> manner?

What you know isn't part of the intended interface, and the intended
interface is - as you indicate - not well documented.  Let me attack your
immediate question and commit to getting the documentation in better shape.

MVS IPCS Customization "IPCS Exit Services, Invoking with the Exit Services
Router, Format Model Processor Service" shows an example of invoking the
model processor plus a model.  If that example attempted to format the two
flag bits in MYBLKDEF, it would need the following BLSQMFLD macro added to
the model shown just before the final BLSQMDEF macro.

 BLSQMFLD NAME=FLGDCODE,OFF=MYBLKDEF-MYBLK,LEN=L'MYBLKDEF,DECODE

That tells the model processor to go look for another model that I've
called FLGDCODE and pass MYBLKDEF as the data to it.  In order to format
the two flags shown in the book, I then need to add the definition of the
model plus some subheader definitions to provide text.

FLGBYTE1 EQU   8Select 1st flag byte (4 supported)
FLGDCODE BLSQMDEF CBLEN=L'MYBLKDEF,OFFSETS=NOPRINT,
   HEADER=FLGDCODE,PRIFIX=8,LBLSPC=2
 BLSQMFLD SHDR=TXTD80,VIEW=MYBLKD80*256+FLGBYTE1,NOSPLIT
 BLSQMFLD SHDR=TXTD40,VIEW=MYBLKD40*256+FLGBYTE1,NOSPLIT
 BLSQMDEF END
TXTD80   BLSQSHDR ' 1st flag bit. '
TXTD40   BLSQSHDR ' 2nd flag bit. '

I threw in the definition of FLGBYTE1 should you have multiple adjacent
flag bytes.  The last 4 bits of the view in the flag bit decoding model
tell the model processor which flag byte is of interest.

Caveat emptor.  I haven't had time to assemble and test this example yet.

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: extract SVCDUMP from SADMP

[Robert Wright]

Barbara Nitz wrote on 06/28/2006 05:24:31 AM:

> use IPCS COPYCAPD. (It took me a while to find the current name, but
> thanks to Bob Wright Jim Mulders former "verbx dmpwrite" made it
> into IPCS as a standard command, and we don't even need to think
> about 31 and 64 bit versions!)

You do, however, need to ensure that you're using the release of IPCS that
captured the dump.  The largest SDUMPs are getting larger fast, and we've
been forced to update the way that storage for capturing dumps is managed
several times since COPYCAPD went into the product formally.  More changes
are likely to be needed as growth proceeds.

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: Long IPCS subcommands in batch

[Robert Wright]

Pat O'Keefe wrote on 06/14/2006 07:19:02 PM:

> Does anyone have an example of a batch IPCS job that processes long
> (greater than 80 characters) IPCS subcommands?  If so, would you be
> willing to share it?
>
> I know the the IPCS ISPF diaglog supports long subcommands, but I haven't

> figured out how to duplicate that in a batch TSO job.  My usual technique
> of invoking the BLSCBSUQ clist doesn't support continuations and
> processes multiple lines as separate commands.

The batch TMP, IPCS,  and I/O service routines know that SYSTSIN is a file,
and the TMP retrieves "logical lines" from that source.  You can use either
plus (+) or minus (-) continuation characters as described in TSO books to
continue commands and subcommands from the source.  The following is a job
that I just ran successfully to confirm my recollection that this is the
case:

//RLWG JOB '796634,?,S=I','RL WRIGHT',MSGLEVEL=(2,1),
// CLASS=2,NOTIFY=RLW,MSGCLASS=H
//IKJEFT01 EXEC PGM=IKJEFT01,REGION=4096K,DYNAMNBR=50
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
IPCS NOPARM DEFER
note 'Now is the time for all good men to come to the aid of their +
country.  At least that''s how I recall my first typing class''s +
initial exercise' ASIS TERMINAL NOPRINT
END

--
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: GTF Woes

[Robert Wright]

Peter Hunkeler wrote on 06/14/2006 08:09:32 AM:

> While being correct, it is highly missleading. The first two sentences
> of the Explanation as well as the System Programmer Response talk about
> a missing DD statement, not about attributes. So does the message text.
>
> Why not say the data set has incorrect attributes, right in the message
> text?

It looks like AHL084I and a few friends went into GTF in the early 1990s.
There is no message that talks about the failure of the tests in question
for a specific ddname.  AHL084I is produced because, after filtering out
ddnames that could not be used on the basis of the tests described, no
candidates remain.  It is possible that AHL084I was the consequence of
forgetting an output ddname entirely.  Your suggestion, interpreted in this
context, is to add a new message that points at ddname IEFRDER or GTFOUTaa
and says something specific about them.  We'll add that to a (long) list of
things that might improve service aids, reduce confusion using them, and
reduce the number of PMRs that result.

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: GTF Woes

[Robert Wright]

Ted MacNeil wrote on 06/12/2006 08:00:00 PM:

> Mind you, as I've said, I haven't been directly involved in GTF in
> over 15 years.
>
> Of course, if you could allow the output dsn to go intO extents and not
wrap?

We've done better than that.  VSAM linear data sets are now supported.
That means you can stripe them and store well more than 4G in it if data
rate and wrap time warrant.

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: GTF Woes

[Robert Wright]

Ted MacNeil wrote on 06/12/2006 08:00:00 PM:

> I'm a little curious about this one.
> I was told (over 20 years ago) that, due to architectural
> constraints, only one instance of the monitor instruction could run.
>
> I had a few times (same era -- I haven't been involved with GTF in
> over 15 years) where I could have run two (or more) traces and
> solved problems in parallel rather than sequentially.

If you have occasion to use GTF now, you have the option available to
attack the problems in parallel.  As I responded to Ed Jaffe, each instance
of GTF sees all events for which monitor call is enabled for any instance
and must perform software filtering.  The cost of quite unlike monitoring
criteria is obviously higher than running each with focus, but it is a
decision that should be left in the hands of the installation rather than a
restriction imposed by the control program.

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: GTF Woes

[Robert Wright]

Edward Jaffe wrote on 06/13/2006 06:18:52 PM:

>
> As implemented right now in z/OS, PER is system wide and not changed
> when address space switching occurs (though that should be technically
> feasible). But, what's to stop multiple GTFs in z/OS 1.6 and higher from
> processing a single PER event?

Nothing.  Each instance of GTF is treated as an independent agent, capable
of using software filtering to disregard events of no interest to it.  It
sees all events that are of interest to any active instance of GTF, so
running multiple instances is certainly going to incur higher monitoring
costs.  The rationale for supporting this is that a large, complex system
may have several nagging problems, and it should be possible to decide to
collect data targetted to solving each of them - if you're willing to pay
in the coin of the realm - performance degradation.

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: GTF Woes

[Robert Wright]

John Chase wrote on 06/13/2006 11:51:07 AM:

> When I deleted SYS1.GTFTRACE and changed the JCL to allocate a new one
> (DISP=(,CATLG)), it worked fine.  Didn't know that GTF doesn't support
> preallocated dataset for output any more, because ISTR that it used to.
>
> Oh, the "old" GTFTRACE dataset was VB with BLKSIZE=8192 and LRECL=8188;
> the "new" iteration is VB,LRECL=27994,BLKSIZE=27998.

The check that is failing for you is for DSORG, not RECFM.  You probably
preallocated the data set via an IEFBR14 step in JCL.  The data set never
gets opened in that situation, and it keeps the default DSORG of undefined.
If you shift to using IEBGENER or an equivalent that opens the data set for
output using sequential access methods and just turns around an closes it,
you'll find it has acquired DSORG=PS as an attribute.  GTF has been doing
this check since the early 1990s.

As of z/OS V1R6 it will also tolerate DSORG=VS at that point in its logic.
Later on during GTF initialization there will be some checks that, if it is
VSAM, it better be a linear data set with CISIZE of 32K.  Linear data set
support was added to exploit VSAM support for striping.  We'd been seeing
more and more GTF and CTRACE external traces sprayed across a bunch of
conventional data sets that DFSMS thinks are unrelated, data sets that must
be put back together using IPCS COPYTRC before the trace originally
requested makes sense again.  Striping one linear data set increases the
capacity without introducing the awkward step in the middle.

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: TRSMAIN as a base component (was How-to read a tersed file directly from USS?)

[Robert Wright]

Rob Schramm wrote on 06/12/2006 01:01:56 PM:

> I hadn't intended my comment to be just rhetoric.  I was just picking up
> on the "...SUPPORTED AT THIS TIME.." part of the message.
>
> I had fallen into a bit of a quandary with TRSMAIN.  Do we support it
> for other off-the-shelf software (i.e. cobol)?  How do I go about
> keeping it up to date?
>
> I am in full agreement that IBM should just make the utility a base
> component.  Dumps both to IBM and ISV software are usually
> requested/sent in TRSMAIN format.  From my view it appears to be
> "expected" that everyone download/install it.

Quite a few requests for fully supported status have been submitted.  The
response to all of them at this time is "Recognized".

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 Clist Evaluate command and character strings

[Robert Wright]

Wayne Driscoll wrote on 06/01/2006 09:24:31 PM:

> I am writing a number of IPCS clists and and I have a question about the
> EVALUATE command.  I am using the command to extract a character string
from
> the dump for use in a NOTE command.  However, the character string
contains
> mixed case data, yet the CLIST variable always contains an uppercased
> version of the string.  Is there any way to get mixed case output from an
> evaluate command?

Yes, you can ask EVALUATE to place UNFORMATTED data in a command procedure
variable.  No, you can't get lower case letters through the editing process
for CHARACTER data - at least not since MVS/SP 2.1.2 (JBB2125, circa 1982).

If you do intend to use the UNFORMATTED option, I'd encourage you to use
REXX rather than CLIST.  REXX doesn't mind if arbitrary binary content
lands in its variables.  The same cannot be said for CLIST variables.

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: Determining what, if any, dataspaces are in a dump

[Robert Wright]

Wayne Driscoll wrote on 05/09/2006 01:10:41 PM:

> If I know, 1 - that the address spaced owned dataspaces, and 2 - that the
> DSPLIST was coded on the dump, why wouldn't there be any dataspaces
dumped?
> This is on z/OS 1.7, and the DSPLIST field is NOT in common storage
> (according to Peter Relson, in another thread, this is NOT required).

   If the service for OA12358 had not been applied, that would be
sufficient to cause data spaces from not getting dumped.  That's the most
recent service that I found that lines up with the symptoms that you
describe.  The PTFs for that APAR (UA19704 HBB7709,  UA19705 HBB7720)
closed September 19th, 2005.

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: Determining what, if any, dataspaces are in a dump

[Robert Wright]

Wayne Driscoll wrote on 05/09/2006 12:32:30 PM:

> I have an SVC dump taken on a z/OS system, with the DSPLIST parm on the
> SDUMPX macro.  The parm specified the current asid, with an * for the
> dataspace name.  How do I determine what dataspaces have been dumped?

If you're interested in what actually arrived in the dump, try

  listdump dsname(your-data-set-name) select(dumped)

or just enter "ld" to the left of the data set name when it is shown on the
inventory panel of the IPCS 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: IPCS in Batch

[Robert Wright]

R.L. (Bob) Wright, z/OS MVS Service Aids, R4GA, [EMAIL PROTECTED]
Robert Wright/Poughkeepsie/IBM @ IBMUS (notes to notes)
IBMUS(RLW) (host to notes), PLPSC.RLW (MVS) or S390VM.RLW (VM)

IBM Mainframe Discussion List  wrote on 03/20/2006
12:27:20 PM:

> Having "fun" trying to format a CTRACE using IPCS in batch mode.  Seems
> that no matter what I specify for the PROFILE LINESIZE( ) subcommand, I
> get the output formatted for 80 columns (I'd really like to get it in
> "full print width" of 132 or more).
>
> Also having difficulty understanding how to get the output to DDNAME
> IPCSPRNT instead of SYSTSPRT.
>
> Here's the latest iteration of the JCL I'm trying (based on the example
> in the "IP Diagnosis Guide"):
>
> //IPCSEXEC PGM=IKJEFT01
> //STEPLIB   DD DISP=SHR,DSN=SYS1.MIGLIB
> //SYSPRINT  DD SYSOUT=*
> //SYSUDUMP  DD SYSOUT=*
> //IPCSTOC   DD SYSOUT=*
> //PRINTER   DD SYSOUT=*
> //SYSPROC   DD DISP=SHR,DSN=SYS1.CLIST
> //  DD DISP=SHR,DSN=SYS1.SBLSCLI0
> //IPCSPARM  DD DISP=SHR,DSN=SYS1.PARMLIB
> //  DD DISP=SHR,DSN=SYS1.PARMLIB.PRD1Z15
> //  DD DISP=SHR,DSN=SYS1.PARMLIB.ZOS15
> //  DD DISP=SHR,DSN=SYS1.IBM.PARMLIB
> //IPCSPRNT  DD DISP=(,CATLG),DSN=.CTRACE.FORMAT,
> // UNIT=SYSDA,VOL=SER=VOLSER,SPACE=(CYL,(120,30),RLSE),
> // DCB=(RECFM=FBA,LRECL=133,BLKSIZE=0)
> //SYSTSPRT  DD SYSOUT=*
> //IPCSDDIR  DD DISP=SHR,DSN=.DDIR
> //SYSTSIN   DD *
>   IPCS NOPARM
>   PROFILE LINESIZE(132)
>   SETDEF DA('.CTRACE1')
>   CTRACE COMP(SYSTCPDA) SUB((TCPIP)) FULL LOCAL PRINT
>   END
> /*
>
> Any tips, hints, etc. would be appreciated.  The above JCL fills the
> spool rather quickly.

I'd recommend the following changes relative to what you show:

o  Make the IPCSPRNT ddname say RECFM=VBA, not FBA.

o  Add "PRINT NOTERM" to your SETDEF options or just add NOTERM to your
CTRACE subcommand options.  IPCS is willing to route messages to both
destinations, but you rarely want that combination.  When it is done, IPCS
sets the recommended line width to the minimum of the two available.

Everything else looks like it will give you what you want - with one minor
concern.  If you use SETDEF against your personal dump directory, the
changes in defaults will persist and apply to your next interactive
session.  If you want to avoid cross-talk between batch and interative but
do want to use one dump directory, you'll need to save and restore SETDEF
options.  See various BLSB CLISTs in SYS1.SBLSCLI0 for how you can
combine EVALDEF and SETDEF to get saving and restoring 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: z/OS 1.8 (pre) announcement

[Robert Wright]

Jon Brock wrote on 02/28/2006 09:23:41 AM:

> Depends on exactly what "simplifying" has been done; it needn't
> necessarily equate to dumbing down.  OTOH, including the phrase "for
> the new generation of IT professionals" has started alarm bells
> ringing in my head.

It shouldn't.  It is talking about the same thing as what is needed to
allow existing programming staffs to cope with more and more FMIDs and
getting the job done.  On the other hand a lot of us who work on z/OS are
eligible to retire, and that has more than a few managers concerned.  So
the phrase talks to them.

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: accessing data in a dataspace

[Robert Wright]

Todd Burch wrote on 02/03/2006 11:57:09 AM:

> Reading through IPCS customization, it is not clear to me how to go about
> accessing data in the dataspace through a verbexit.
>
> I would typically use the Storage Access Service (Chap 10.2.18) to acess
> data  in a dump, but it says right up front to use the Storage Access
> function of the Symbol Service (Chap. 10.2.20).
>
> In the Symbol Service, I have to supply an ESR, which in turn describes
the
> ASID of the owning dataspace and the DSPNAME itself.  OK so far.
>
> What is not clear to me is where to supply the address within the
dataspace,
> or the length of the data I want returned.  Do I have to create a symbol
> (using the Equate Symbol Service) for each address/length I want to
> (programmatically) look at in the dataspace?  Seems like a pain.
>
> On the other hand, I considered using the Storage Map Service (Chap
> 10.2.19), as this indicates dataspace access is supported.  But,
similarly
> to the Symbol Service, I have not figured out how/where to specify the
> address & length of storage I am insterested in.

The BLSRESSY (symbol service) and BLSRSASY structures both use three
elements to talk about the dump data of interest:

1.  A BLSRDATS structure (field name suffix AS) that you've characterized
accurately.  It tells IPCS what address space (broader term than you
generally hear being used to discuss z/OS) is of interest.  A large variety
of address spaces are supported in various contexts, including ASID(a)
DSPNAME(d).  Part of IPCS considers every address space to have full 64-bit
addresses.  Some front-end functions notice that you really cannot talk
about addresses beyond 1040 in a HEADER record and that most data spaces
are still limited to 31-bit addresses.

2.  An address that comes in two flavors, depending on whether you asked
for an ABITS(64) structure or accepted a default ABITS(31) structure.  The
former is a 64-bit address, and the latter is a 31-bit address in a 32-bit
field.  In all cases the field name suffix is LAD for "logical address".
The logical address is the value that you expect to find in other blocks
that point to whatever is being discussed.  In the case of blocks like
TCBs, UCBs, RBs, ASVTs, JSCBs, and at least a few others, it is not the
address of the first byte occupied by the thing being discussed.

3.  A BLSRDATC structure (field name suffix D in BLSRESSY and F in
BLSRSASY) that supplies an attribute bundle including offset, length, and
one-dimensional array characteristics.  The offset plus the logical address
yields the address of the first byte occupied by whatever is being
discussed in the address space in the dumped system.  When you request a
dump access function, the first phsical byte of interst lands in the first
byte of the buffer that you provide.  That may require an interesting USING
operation to get proper addressability to what lands in the buffer.

There are also some other fields that help explain why BLSRESSY (symbol
table) and BLSRSASY (storage map) records are different.

I hope that this helps.

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 The Movie: LOST IN SPACE, er... DATA SPACE

[Robert Wright]

Barbara Nitz wrote on 01/25/2006 01:40:23 AM:

> >IPCS won't necessarily think about the WHOLE data space, just enough
> >locations adjacent to the final byte in the space to fill the screen on
> >the storage panel. Smart code processing data spaces notices such things
> >as invalid segments in a data space and produces big numeric answers
> >along the way. Similar smart code processing address spaces also thinks
> >about invalid regions.
> So IPCS is even smarter than I thought!
It has to be.  Run the numbers, and going byte by byte or page by page
would produce response times that you could not survive a typical debugging
session.

>
> Whenever I had similar performance problems, my dump directory was very
much
> fragmented with CI/CA splits. It usually helped to just delete/define the
> dump directory and redo the analysis. If you still have that problem with
a
> fresh directory (you could use a different name to start with and repro
the
> old data in - just make it big enough), then at least you'll know it's
not
> VSAM related. What I also do in cases like this is take a dump of my hung
> user and look at the trace table to see what I am doing.

I periodically discipline myself to go through my inventory, throw out the
descriptions of things no longer of interest, and then run the following
CLIST that must be 25 years old:

PROC 1 DSN
CONTROL LIST
ALLOCATE FILE(SAVEDDIR) UNIT(SYSVIO) CYL SPACE(10 10) +
RECFM(U) BLKSIZE(3072) REUSE NEW
REPRO INDATASET(&DSN) OUTFILE(SAVEDDIR)
REPRO INFILE(SAVEDDIR) OUTDATASET(&DSN) REUSE
FREE FILE(SAVEDDIR)

It should run a little faster than REPROs between two directories because
only the 2nd REPRO pass builds an index.

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 The Movie: LOST IN SPACE, er... DATA SPACE

[Robert Wright]

Barbara Nitz wrote on 01/24/2006 02:50:20 AM:

> if you do a max PF8 while browsing, AFAIK you're out of luck. IPCS is
going
> to read the whole dataspace, all 2GB of it, if you're unlucky. (Or all of
> the 64bit address space, for that matter.)

IPCS won't necessarily think about the WHOLE data space, just enough
locations adjacent to the final byte in the space to fill the screen on the
storage panel.  Smart code processing data spaces notices such things as
invalid segments in a data space and produces big numeric answers along the
way.  Similar smart code processing address spaces also thinks about
invalid regions.

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 The Movie: LOST IN SPACE, er... DATA SPACE

[Robert Wright]

Todd Burch wrote on 01/23/2006 07:15:01 PM:

> Woe to those who hit PF8 and advance into unused DATASPACE storage.
>
> Is there an option in IPCS Browse to overcome the HANG (X CLOCK)
situation
> when paging into the unused portion of a 2G dataspace dump?

I just tried DOWN MAX against several of the data spaces in an SDUMP that
is my current z/OS 01.07.00 default, and the response was instantaneous for
them all.  If you're seeing a different result, you may want to open a PMR
and get both the dump and your usage scenario to us.  Little details really
loom as important when we deal with missing storage ranges.

>
> Perhaps an option to turn off similar line compression?

Repetitive data compression has very little to do with the performance
concern mentioned earlier.  Most TSO users work with an emulated screen
that can almost always be filled with the contents of one 4K page of data
that is available.  I don't know of anyone seriously asking to see
terrabytes of missing storage described 16 or 32 bytes per line.  (IPCS
really could fill the screen fast if anyone wanted that.)  It is missing
storage ranges that are the real performance challenge for IPCS and the RSM
component code that helps with most such analysis.

I just checked the service history of IAXZRADS, the module most concerned
with helping IPCS cope with missing storage in a data space, and there have
been no PTFs against it for several releases.  APAR OA12445 affected
performance of BLSRRAGE, the IPCS routine that calls IAXZRADS when that is
necessary.  The PTFs for OA12445 dealt with excessive path length concerns
in many scenarios.

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 Standard Print Service

[Robert Wright]

Todd Burch wrote on 01/16/2006 03:09:36 PM:

> Here is perhaps the smallest verb exit I've ever written to demonstrate
the
> blank lines at the top of the IPCS print dataset.  There are three blank
> lines at the top.  How do I access these?  When I write a REXX routine
that
> call the "NOTE" command, these blank lines do not exist in the print
> dataset.
>
> Assemble, linkedit, place in a library in your available TSO load libs,
and
> issue "verbx miniverb" from IPCS option 6.
>
> 

I ran the requested experiment and got basically what I expected in the
RECFM=VBA data set.  The following was cut and pasted from ISPF browse
afterward - after turning on its display of control characters:

 1COMPON=REAL STORAGE MANAGEMENT,C
 +
 0WHY DOES THIS SHOW UP ON LINE 4?

The first line of output from MINIVERB should appear on line 3, following
an underscored title line on line 1 and a blank line 2.

You've been using the term "print dataset" which is what I've been
addressing, but your script would cause MINIVERB output to be sent to the
terminal as a destination unless you added "print noterm" as options like I
did.  There I do see 3 blank lines preceding the first one produced by
MINIVERB.  That's a consequence of PRDMP compatibility as well as some TSO
terminal output stream considerations.

o  PRDMP started the output from all verbs on a new page, but it didn't get
around to supporting ADPLEJEC until its final years.  ADPLEJEC is the bit
that says eject.  Old PRDMP exits put out between 60 and 90 blank lines to
cause the current page to overflow as a means to get to the top of the next
page.

o  The TSO output stream has no sense of pagination since it originally was
written to continuous forms fed through hardcopy terminals like 2741s.

IPCS's terminal support tries to make sense of all this by limiting the
number of consecutive blank lines that it actually honors and, conversely,
by slipping in some (3) blank lines when something nonblank shows up in the
output stream.
So the 3 blank lines that you see in your terminal output are the
consequence of the VERBEXIT subcommand putting out one blank line with a
page eject indication before giving control to the exit.

Now for some good news since you don't seem fond of the blank lines.  There
is a NOTOC option on VERBEXIT that suppresses several inherited behaviors
related to invoking verb exits, and one of those behaviors is forcing a new
page.  If you change your invocation to "verbx miniverb notoc", you'll have
your output start on the first line.  (If you say "note 'hi' page", you'll
get the 3 blank lines before HI.)

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 Batch on "ACTIVE" ?

[Robert Wright]

Cwi Jeret wrote on 01/19/2006 02:45:58 AM:

> U want to submit an IPCS Batch Job on the TSO "ACTIVE" storage
> rather than on a DUMP DataSet, like I do on the "Source" entry on the
> IPCS Defaults panel of the Online Dialog .
>
> How do I have to change my following JOB ?
>
> //IPCS  EXEC PGM=IKJEFT01,REGION=4M
> //IPCSDDIR  DD DSN=User.IPCSDDIR,DISP=SHR
> //DUMP  DD DSN=SYS1.DUMP,DISP=SHR<<<  How to change
> to "ACTIVE" ?
> //SYSPROC   DD DSN=SYS1.SBLSCLI0,DISP=SHR
> //SYSUDUMP  DD SYSOUT=V
> //SYSTSPRT  DD SYSOUT=V
> //SYSPRINT  DD SYSOUT=V
> //IPCSPRNT  DD SYSOUT=V
> //SYSTSIN   DD *
> PROFILE MSGID
> IPCS NOPARM
> DROPDUMP DDNAME(DUMP)
> SETDEF  DDNAME(DUMP)  PRINT NOTERMINAL  NOCONFIRM
> IPLDATA STATUS
> DROPDUMP DDNAME(DUMP)
> END
> //*
> //
You want to do the following:

1.  Remove the DUMP ddname from the JCL.

2.  Change all instances of DDNAME(DUMP) in the input stream to read
ACTIVE.

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 question

[Robert Wright]

Barbara Nitz wrote on 01/18/2006 01:20:07 AM:

>  it will always
> tell you the storage key, even for summary dump data (that AFAIR SDUMP
> doesn't collect storage keys for).

While the provision remains for SADMP and SDUMP to indicate "I don't know
the storage key" in dump records, storage keys are now nearly always
available where IPCS can access them easily.  This changed for the better
in z/OS V1R2 (HBB7705).

Your reliance on RSMDATA presumes that RSM data areas will be available in
a dump.  This has been true historically, but the practice has been getting
scrutiny as customers have been able to run with ever larger amounts of
main storage.  You may need to get familiar with DISPLAY(MACHINE) as an
option since some dumps may eventually only have storage key information
for storage that the dumping process decided was important enough to dump.
If dumped pages have RSM attributes that are sufficiently important that
you would want them captured along with each dumped page and formatted via
DISPLAY(MACHINE), let us know.  We tried to put enough reserved space in
the front of dump records when we went from LRECL=4104 to LRECL=4160
(remember HBB3310?) so we could add more vital attributes to those captured
today, but that has only become relevant as memory prices have fallen in
recent years.

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: IKJ56876I

[Robert Wright]

Paul Gilmartin wrote on 01/17/2006 12:29:07 PM:

> In a recent note, Robert Wright said:
>
> > it can by-pass catalog lookup if the requestor uses a combination of
> > DYNALLOC keys implying acceptance of ddname reuse.  You'll find a list
of
> > keys that prevent such ddname reuse as part of DYNALLOC documentation.
The
> > performance gain can result from less ENQs ranging from ones that are
> > sysplex-wide (e.g. system catalog requests) to ones for the TIOT.  The
> > SYSDSN ENQ is in effect as long as the dsname is allocated and reflects
the
> >
> Does this mean even while allocated, but marked not-in-use?

Yes, the serialization ENQ lasts as long as the ddname exists.

I skipped your question regarding mutually-exclusive keywords on ALLOCATE.
I don't know the answer.

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: IKJ56876I

[Robert Wright]

Brian Peterson wrote on 01/17/2006 10:48:40 AM:

> In this context, I believe that the "in-use" and "not-in-use" references
> are referring to allocations which have been marked "not-in-use" using
the
> DAIR interface.  This interface is documented in TSO/E Programming
Services
> topic 17.2.2.11  Marking Data Sets as Not in Use (Entry Code X'2C').

You're correct about when the bit came into existence, and retaining
allocations after the command that initially requested them was motivated
to a significant degree by DAIR's sluggish performance.  However, the bit
has enduring significance.  It tells the system that a command has asked
for use of the ddname and may or may not have a DCB/ACB open to use it.  At
the completion of the command's processing, it works together with the
permanent allocation bit and other factors to determine whether it makes
sense to mark the ddname as not in use or to free the allocation.

>
> Basically, my understanding is that the DAIR interface is as old as the
> hills, and the concept of optimizing TSO performance by marking
> allocations "not in use" probably dates to OS/360 - but of course the TSO
> historians will correct me with the details.
>
> The two concepts - 1) marking an allocation "not in use" and reusing a
"not
> in use" allocation, and 2) using the REUSE keyword on the ALLOC command,
> are two totally separate and distinct concepts.

Total separation is a slight overstatement.  The in-use bit may interact
with an attempt to free a ddname so a replacement can be established.  It
would be reasonable for DYNALLOC to reject a request to free an in-use
ddname unless the requester explicitly said it was OK.

>
> Another way to think about this is DAIR predates DYNALLOC.  And, it used
to
> be that Allocation was REALLY SLOW.  So the DAIR service to mark
> allocations "not in use" was an attempt to optimize TSO, back in the
olden
> days.
>
> Brian
>
> On Tue, 17 Jan 2006 08:04:49 -0700, Paul Gilmartin wrote:
>
> >The description of DYNALLOC is frightening with in-use and not-in-use
> >allocations, and the possibility of reusing an existing allocation
> >rather than creating a new one.  It states there is a performance gain
> >for reusing an existing allocation.  Where?  Can it bypass catalog
> >lookup or VTOC lookup?  Does the SYSDSN ENQ remain in effect while an
> >allocation is not-in-use?  If not, what happens if another job
> >deletes (and perhaps even recreates and catalogues) a data set
> >associated with a not-in-use allocation?  Does the TSO FREE command
> >actually remove the allocation, or merely set the not-in-use flag?

Yes, it can by-pass catalog lookup if the requestor uses a combination of
DYNALLOC keys implying acceptance of ddname reuse.  You'll find a list of
keys that prevent such ddname reuse as part of DYNALLOC documentation.  The
performance gain can result from less ENQs ranging from ones that are
sysplex-wide (e.g. system catalog requests) to ones for the TIOT.  The
SYSDSN ENQ is in effect as long as the dsname is allocated and reflects the
highest level of serialization ever needed while one or more ddnames were
associated with the dsname.

The FREE command does what you ask.  If you asked that the dsname be freed,
multiple ddnames may be freed or discussed via diagnostic messages that
talk about concatenated ddnames that could not be freed.  If you asked
about a specific ddname, that instance of an allocation to dsname(s) will
be affected.

Bob Wright - Never a DYNALLOC developer but a long time user

--
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 question.

[Robert Wright]

John McKown wrote on 01/16/2006 10:06:47 AM:

> Is there an **EASY** way to give IPCS an address and have it tell me:
> (1) the storage key and (2) whether it is fetch protected?

The easiest way that I know is to use the LIST subcommand together with the
DISPLAY(MACHINE) option, e.g.

  list 12345. asid(678) disp(mach nostor)

My example threw in the DISPLAY(NOSTORAGE) option, abbreviated slightly, to
just ask that the "MACHINE" information (interesting facts known to IPCS
about storage such as storage keys and underlying absolute storage
addresses) be included in the output.

Note:  If you regularly value MACHINE information for the work that you do,
"SETDEF DISPLAY(MACHINE)" will make it part of the output by default.

It is possible that IPCS won't know the storage key for some storage,
mostly storage for which SDUMP couldn't/didn't collect that information.  I
think that DISPLAY(MACHINE) output was written so that IPCS doesn't remind
you of all the things it doesn't know.

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 Format Models

[Robert Wright]

Wayne Driscoll wrote on 01/07/2006 04:01:51 PM:

> Thanks for your response.  I looked at the BLSQMDEF macro, and I have the
> CBLEN field coded, and looking at the expansion, I see the length being
> generated at offset x'18' into the area generated by the CBLEN field, but
as
> you say if I issue a LEN value on the CBF command, then I get the full
> amount of data dumped out.  I know have a couple of models that this
happens
> with, but not all of them, so it has me confused.  Any other ideas?

My earlier note mentioned that BOTH CBLEN and an acronym are required for
IPCS to infer anything other than the default data length from a model.
The rationale for that was that we wanted to at least minimally confirm
that a valid instance of a structure was being processed.  The acronym
check is the only thing that you have mentioned in your notes.  Hopefully,
that's it since you did say that all of your structures have some acronym
that can be checked.

Bob Wright

--
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: IBM Mainframe DSLIST to Dataset w/ Wildcards?

[Robert Wright]

Howard Brazee wrote on 01/06/2006 13:53:57:

> I'm passing on this question (with permission from Doc Dwarf) that I
> expect a Rexx expert will come up with the best solution
>
> [EMAIL PROTECTED] wrote in comp.lang.cobol:
>
>
> [OT] IBM Mainframe DSLIST to Dataset w/ Wildcards?
>
> All righty... here's how we're spending some slow time here.  Datasets
> get
> generated on a biweekly basis with the format:
>
> USERID01.TAn.Pooo.Ddddhhmm.node
>
> ... where n represents a division, ooo is a pay period, ddd =
> 'Julian'
> date, hhmm = time and .node is any one of four possible values.  The
> primary criterion of selection will be ooo, the pay period.
>
> (Pay period is designated as single-digit year and 01 - 27, a biweekly
> cycle; research has determined that the earliest datasets are P0, year
> 2000, and that no P9 exist.)
>
> (I know... but I didn't design the naming convention.)
>
> Folks in corner offices want these deleted and their wills be done...
> but
> I'm looking to automate the task since there are about 14,000 datasets
> involved, spread out over five USERIDs... oh, and most - but not all -
> are
> in MIGRAT1 or MIGRAT2 status.
>
> Now... if I use the (Library Function) 3.4 Data Set List Utility I can
> specify a wildcarded string - eg USERID02.TA*.P0* - and the P
> command-line
> option; if I log off and Keep my listing dataset I can then use it as
> input to a DFSORT, taking the listings of
>
> USERID02.TA1.P001.NODE1
> USERID02.TA1.P001.NODE2
> USERID02.TA2.P001.NODE1
> USERID02.TA2.P002.NODE2
>
> ... etc. and editing/reformatting them to create another file,
> consisting
> of...
>
> HDELETE USERID02.TA1.P001.NODE1
> HDELETE USERID02.TA1.P001.NODE2
> HDELETE USERID02.TA2.P001.NODE1
> HDELETE USERID02.TA2.P002.NODE2
>
> ... and use that as a SYSTSIN for an IKJEFT01.  For the datasets that
> aren't archived I can do this again and create an IDCAMS input of
>
> DELETE USERID02.TA3.P026.NODE3
>
> ... and get rid of the last.
>
> Combining an interactive task, a logoff/logon sequence and a batch job
> in
> this way - while it will work - offends my sense of elegance; while I
> have
> a solution I'm looking for a better one.
>
> What I'd like to do is find a utility that does in batch what the Data
> Set
> List Utility does in the foreground, something that I can feed a string
> like USERID02.TA*.P0* and have it generate the listing of the datasets
> that I can feed to a SYSOUT and pass to the DFSORT edit/reformat step.
>
> Might anyone be able to suggest where I might look to find such a
> utility?

You should be able to use the LMDLIST service of ISPF to perform a catalog
search that would return all the data sets of interest plus some needing to
be filtered from the deletion action to a REXX exec (or compiled program if
you're more comfortable with that).  Then just walk through the list and
delete the subset needing that action.  You can test your logic by using a
SAY statement in REXX to talk about which data sets would have been deleted
by development editions of your exec before actually performing deletion.

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 Format Models

[Robert Wright]

Wayne Driscoll wrote on 12/30/2005 01:06:35 PM:

> I am starting to write IPCS format models for a number of our internal
> control blocks, but I am having problems with one of them.  For one of
the
> models, I always get just the first 4 bytes (the eyecatcher) formatted,
> followed by message "Control block is truncated", however if I do an "IP
> LIST addr LEN(64)" I see the entire control block in storage.  The
entries
> in parmlib(blscuser) are there for all the models, they are all in the
same
> load module, separate csects with aliases defined.  If I look at the
model
> load module, everything looks good, but I have no idea on how to diagnose
> the "Control block is truncated" message.

It sounds like you forgot to supply a CBLEN equal in length to that block.
If you refer to the block by its structure name and don't have a scan
routine, IPCS will try to access the model to determine the eyecatcher and
length for that type of data.  If the acronym isn't defined to allow
minimal validation of the block or the CBLEN is zero, the model won't be
used to define the length of the block.  The current SETDEF LENGTH value
will be used, and that, in turn, defaults to 4.  That sets the stage for
the following to occur:

1.  The model processor retrieves the portion of the block of interest, 4
bytes in this case.

2.  All of the BLSQMFLD macros are processed to see which fields you might
like to have formatted.  If any of them lies outside the portion of the
block that was retrieved and the model processor has not been told to be
silent about the situation, one complaint about control block truncation
will emerge.

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 Standard Print Service

[Robert Wright]

Todd Burch wrote on 12/24/2005 11:04:08 AM:

> The first 5 lines that come out in my print file are empty (all blank).
> I've read further after your reply but it's not apparent which service I
can
> use to cause ANY title lines (mine - not that I've defined any, or IPCS's
> title lines) to come out.  I did find one sentence in IPCS Customization
> that referenced being able to use the Table of Contents Service to supply
> title lines in a verbexit routine (my routine is a verbexit routine), but
> nothing is jumping out at me for how to do this.
>
> When using REXX to build a print file with the NOTE facility, my output
> lines start on line 1, just like I expect.  So, I figure there's a way to
do
> this from assembler.
>
> I've even tried setting ADPLLNRM (lines remaining on page) to the value
in
> ADPLLCNT (line count per page) and that didn't do it either.   On entry
to
> my routine, ADPLLCNT is X'3C' and ADPLLNRM is X'39'; a difference of 3,
...
> I think I must be printing a blank line or two myself (thus the 5 blank
> lines at the top) on entry.

I tried "VERBEXIT SUMDUMP PRINT NOTERM" to a test file, and I didn't see
the symptom of 5 blank lines at the beginning of the report.  I think that
bug is on your side of the API rather than the IPCS side.

The Table of Contents service is normally associated with an IPCSTOC
ddname, and it was designed to contain a brief set of entries that point
you to places in the print file.  If you want to use it in your code, put
out the first line of text that you want referenced to the print file.
Then put out a table of contents entry, usually with text very similar to
what was just written to the print file.  If you're writing code for a verb
exit, the VERBEXIT subcommand will have produced a level 1 table of
contents entry pertaining to the output from the exit unless NOTOC told it
not to do that.  You'd normally use level 2 entries to point to the
beginning of significant portions of the report(s) produced by the verb
exit.

The table of contents service has been sparsely exploited by the programs
that generate IPCS reports.  If your exit supports it well, it will not
have a lot of company.  It's a shame in a way.  We thought of trapping
table of contents entries written when you send a report to the terminal
via the IPCS dialog.  You'd enter some primary command like "CONTENTS" and
get a selection list that allowed you to jump to important places in report
output. Oh well...

The BLSABDPL fields that you mention are all fields that the host-supplied
print service uses to inform exits about print file status.  They should
not be modified by anything other than 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: IPCS Standard Print Service

[Robert Wright]

Ann & Lynn Wheeler wrote on 12/24/2005 11:00:30 AM:

> can you say dumprx
> http://www.garlic.com/~lynn/subtopic.html#dumprx
>
> very early, when it was still rex ... and long before it was released as
> a product ... I wanted to do a demonstration that rex was more than just
> another command scripting language (ala exec/exec2).

VM's IPCS and MVS's were two distinct efforts.  The Wheelers are referring
to the former, and Todd Burch to the latter.

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 Standard Print Service

[Robert Wright]

Todd Burch wrote on 12/24/2005 09:46:29 AM:

> I've written some routines (in assembler) to access IPCS dump data using
the
> IPCS Customization Services.  I had written the same routines before in
> REXX, but slowness of REXX made the pain too great to bear any more.
So,
> now I am a happy camper with my very high speed assembler routines.
What
> was taking 3-4 minutes in REXX to process now takes sub-seconds with
> assembler.
>
> I've only explored the Standard Print Service and the Storage Access
> Service, and both are meeting my needs so far.
>
> However, I have not been able to figure out how to get my output dataset
to
> start on line 1.  It always starts on line 6.  I've tried the ADPLEJEC
bit,
> but to no avail.(I'm not using BLSUPPR2 or the expanded print
service,
> just the ADPLSPRT service code.)
> What can I do to start my data on the top of the output page (viewing
> online)?   Or, is this area reserved for header or other summary
information
> I have not tapped into yet?

I'm glad that your general experience has been positive.  Your concern
regarding the print services is one that you can't fix without a
requirement being addressed by IPCS.  IPCS always puts title lines at the
top of a print file page, using a hierarchy of sources for title text.
Note that the expanded print service is available under both IPCS and SNAP
hosts.  It uses the host-supplied print API to get all lines of output sent
out.  There are reasons to look at its use, but circumventing host
restrictions isn't one of them.

It also inherited a compatibility requirement from PRDMP/SNAP.  The
original, common API defined by those two hosts did not originally have an
ADPLEJEC bit.  Applications were simply expected to put out around 60 blank
lines to ensure that a current page had overflowed and that the next
non-blank line would appear at the top of the succeeding page.  IPCS came
along late enough in the evolution of technology that it was obvious that
line width and page depth both needed to be specified by the used, so
ADPLEJEC needed to be used and was, of course, a better solution.

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: Converting TOD to Local Time

[Robert Wright]

IBM Mainframe Discussion List  wrote on 12/13/2005
07:07:18 AM:

> We are using an Assembler program to analyse SMF output records
> of CICS transactions.
> The timestamps in the CICS SMF records are in TOD format.
> In order to get a readable timestamp we are using the STKCONV macro,
> but this gives us the GMT time rather than our local time.
>
> Does anybody have an example of an ASSEMBLER routine to convert
> the TOD time figures to our local time ?

I don't have an assembler routine to contribute, but I can warn you that
there are three, not two, interpretations of a TOD time stamp available.

1.  The STCK instruction produces an absolute time stamp.

2.  Adjusting that using CVT field CVTLSO from the generating CICS system
yields a UTC (nearly synonymous with obsolete term GMT) time stamp.

3.  Adjusting that using CVT field CVTLDTO from the generating CICS system
yields a local time stamp.  You may, however, use CVTLDTO from the system
doing your formatting if your goal is to get a report adjusted to YOUR
system's local time.

Be certain which interpretation applies to your starting value.  The
adjustment values are doublewords and either require that your assembler
routine use zSeries doubleword arithmetic or use fullword arithmetic plus
overflow logic to carry/borrow from one word to the other.

Bob Wright

--
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: ISPF PROFILE Question.

[Robert Wright]

Howard Rifkind wrote on 11/04/2005 11:31:03 AM:

> Sorry I forgot how to change the profile in ISPF ... the part where
> I can change PF key meanings like retrieve etc.

Do two things:

1.  Get into the application where you want to see/alter the definitions of
the program function keys.  Each application has a separate set.

2.  Type KEYS as a primary command.

You'll see a panel showing either all your keys (12-pfkey terminals) or the
primary ones.

Bob Wright

--
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: TSO EDIT command

[Robert Wright]

Steve Comstock wrote on 10/27/2005 08:55:31 AM:

> > Read up on the EXEC subcommand of EDIT.
>
> OK, done. Interesting, but less than enlightening. It
> looks like when I am in TSO EDIT I can issue the
> EXEC subcommand and invoke a CLIST or a REXX exec.
>
> But, the doc goes on to say:
>
> "Specify only REXX instructions in the REXX exec.
> Specify only EDIT subcommands and CLIST statements
> in the CLIST."  [interesting restrictions; not
> useful for my needs; also interesting that this
> is one of those areas where a CLIST can be more
> powerful than a REXX exec]
>
> But, the short write up ends with this mysterious
> assertion:
>
> "You cannot specify TSO/E commands in the CLIST or
> REXX exec until you specify END to terminate EDIT."
>
> I consider it mysterious because it seems to imply
> you can be in TSO EDIT, invoke a CLIST or exec which
> can terminate TSO EDIT and then continue to run,
> issuing TSO commands. This seems really unlikely.
>
> Anyway, thanks for pointing this feature out to me.

CLISTs do have the property that you doubt - as long as the commands of
interest use the TSO I/O service routines to get line mode input.  You can
use a CLIST to start EDIT, change whatever you want, exit from EDIT, 
Unfortunately, EDIT was designed before the CLIST facility was added to
TSO, so subcommands don't supply return codes to do things like let your
CLIST know whether FIND found the thing of interest, but it is quite useful
for a class of editng tasks where you have a well-defined group of things
to alter before saving or submitting the data.

Bob Wright

--
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: SYSMDUMP with RECFM=VB, LRECL=139

[Robert Wright]

No, those DCB parameters are not supported.  I don't have immediate access
to the open processing at the moment, so I can't say how the error
condition would currently be handled.  I believe that the code that opens
SYSMDUMP uses a DCB with RECFM=FBS,LRECL=4160 supplied.  The DCB wins when
logical conflicts occur, so the DCB OPEN exit receives control with
BLKSIZE=3120 still incorrectly shown.  Then the DCB exit will either fix
the mismatched LRECL and BLKSIZE or will suffer an ABEND when OPEN is asked
to continue.  A successful repair of BLKSIZE would cause that data set to
be overwritten and DCB attributes set to RECFM=FBS, LRECL=4140, and
BLKSIZE=4160.

R.L. (Bob) Wright, z/OS MVS Service Aids, R4GA, 708-1F30, [EMAIL PROTECTED]
Robert Wright/Poughkeepsie/IBM @ IBMUS (notes to notes)
IBMUS(RLW) (host to notes), PLPSC.RLW (MVS) or S390VM.RLW (VM)

Jerry Ragland wrote on 10/24/2005 01:30:55:

> Is it possible to have a valid SYSMDUMP withe the following properties -
> RECFM=VB
> LRECL=139
> BLOCKSIZE=3120

--
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: TSO EDIT command

[Robert Wright]

Steve Comstock wrote on 10/18/2005 02:10:12 PM:

> In our TSO CLIST course, we include a brief discussion
> of the [rather arcane] TSO EDIT command; it is clear
> I can include an edit command followed by various
> edit subcommands in a CLIST.
>
> But I have trouble accomplishing the same work in
> a REXX exec. I've tried emulating the CLIST approach
> (edit command followed by lines with edit subcommands)
> and  PUSHing the edit subcommands on the stack before
> issuing the edit command. To no avail.
>
> Looks like I'll have to call a CLIST to get that
> work done. Anyone able to shed any light on this one?

EDIT is an example of what the original TSO design called a modal command,
one that chats with you repeatedly until you say END.  (IPCS is another.)
CLIST caters to such commands by yielding control each time that a GETLINE,
PUTLINE, PUTGET, or STACK operation completes, allowing the TMP to pass
control to a program and the program, in turn, to solicit input from the
same CLIST.  REXX assumes a different control flow model.  It sets up shop
and passes what are generally-expected to be requests for complete
transactions to commands.  REXX can pass control to a modal command, but it
just waits for the command to complete before progressing past invoking the
modal command.

Bob Wright - z/OS 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 ADPLSMAP service

[Robert Wright]

DanD wrote on 10/05/2005 12:20:43 PM:

>
> I was wondering if anyone has used the ADPLSMAP IPCS service routine to
map
> a dataspace?
> Any code  samples would be welcome.
>

Can you expand on the phrase "map a dataspace"?  In my mind I'm hearing it
meaning the following:

1.  Somehow you or your program know that mapping hasn't been done already.

2.  You have a program that, pointed at a data space owned by your code,
can say which structures span which addresses within the space.

3.  You want the descriptions recorded so that subsequent WHERE service
requests or IPCS subcommands can relate data space addresses to the
structures in the data space.

If that's the question, then the answer is that it may be tricky but all of
the services that you'll need are available to an HLASM program:

1.  The ECT service can be used to request that something like the
following subcommand be run:

EVALMAP GE ADDR(0) ASID(a) DSPNAME(d)

If EVALMAP can't find any records pertaining to the data space, it will
produce a high return code and you'll know that you haven't gone to the
effort of mapping previously.  If what I'm describing is what you and
others intend to do, we should add an item to the IPCS wish list that you
be able to do this through the Storage Map Service (just map service
henceforth).  You can't do that today.

2.  You'll need to supply scan routines to handle each type of structure
that you want mapped.  Two versions of the protocol to invoke them are
supported.

a.  The most common one that we expected was one where all the scan routine
would need is the identity of the address space and the address within the
space.  It would retrieve an image of the block of interest and would be
able to deduce the length and category (eg. RB is a PRB or UCB is a UCBDA)
from fields within the block itself.  When the scan routine exits, IPCS
takes care of caching the information from the BLSRSASY structure generated
into the dump directory.  The scan routine supplies two codes, one to
indicate whether the requested validation completed and the other to
indicate what it thinks of the assertion that the storage contains one of
those things.

b.  Blocks, particularly ones designed by hardware designers, may be
described by information that points to them rather than information within
them, forcing the caller to supply a description but not necessarily to
render an opinion regarding whether the block appears to be a valid
instance of, e.g. an ASN-first-table, ASN-second-table, region table,
segment table,   There's an indication that you have a "remote"
description being supplied to the scan routine.  The scan routines for such
blocks function a lot like the ones in the first category but expect to get
a valid description of the type of block supported.

The caller of the map service can use a 2nd instance of a BLSRSASY
structure in its calling sequence to inform IPCS and the scan routine about
which block led to the block being scanned.

Note:  If you have a block that can be described as an array, eg. the
zArchitecture segment table, do so rather than adding separate items to the
IPCS storage map for each entry.  We were very generous with reserved space
when IPCS storage map entries were designed, and you can use more space to
describe something than the original block occupied.

Bob Wright - z/OS 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: DAE Question

[Robert Wright]

Dean Montevago wrote on 09/29/2005 03:35:56 PM:

> I'm in IPCS looking at DAE data. I want to know what the * next to the
> Date of the DUMP means. I did a help and the last line starts to explain
> it, but I can't figure out how to advance to the next page. I've tried
> everything I could think of and all I keep getting is the ISPF help
> tutorial. Can someone help ?

The last person to update the tutorial panel forgot the guidelines about
the maximum number of lines on a tutorial panel.  Lines 23 and 24 read as
follows:

Note: a trailing asterisk (*) in the Date of Dump field means
  SYMPTOM STRING TRUNCATED.

I know who originally wrote the dialog, and I think that between us we can
locate the current owner and get it updated for a future release.

Bob Wright - z/OS 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