IBM wheels out bleedin' big 15TB tape drive Proprietary tape format bits shrink while capacity bulks up

[Edward Gould]

> http://www.theregister.co.uk/2017/05/11/ibm_15tb_tape_drive/ 
> 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AUTOIPL SADUMP LOADPARM flag value

[Tom Conley]

On 5/12/2017 5:18 PM, Jesse 1 Robinson wrote:

It's Friday, so I can (re)tell my war story. Shortly after z/OS R13 hit our 
first prod system, I noticed one morning that the system had been IPLed around 
05:00. Everyone denied having done it. Then I discovered a fresh SAD taken 
around the same time. Sent if off to IBM. Next day or two, the same thing 
happened. The system was wait-stating after running clean out of storage 
frames! It made no sense. I posted the problem here.

Jim Mulder saw the thread and rang me up with a few questions. The failing 
system, unlike the sandbox, was being mirrored to the DR data center. All of 
it. Every single volume. Jim suspected and then confirmed that because of a 
change in R13, a failing page-in caused an I/O redrive, which lost track of the 
failing page request, which never got put back on the queue. With XRC active, 
some percentage of page-ins got tangled up with SDM I/O. More lost frames. 
Eventually MVS ran completely out of frames, and the system wait-stated. Auto 
SAD. Auto IPL. It was Development, so at 05:00, there were no user calls. Ops 
never noticed.

Jim fixed the problem immediately. I believe in auto IPL.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com



Just don't forget to set MVS(LAST).  The res volume you save may be your 
own.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

It's Friday, so I can (re)tell my war story. Shortly after z/OS R13 hit our 
first prod system, I noticed one morning that the system had been IPLed around 
05:00. Everyone denied having done it. Then I discovered a fresh SAD taken 
around the same time. Sent if off to IBM. Next day or two, the same thing 
happened. The system was wait-stating after running clean out of storage 
frames! It made no sense. I posted the problem here. 

Jim Mulder saw the thread and rang me up with a few questions. The failing 
system, unlike the sandbox, was being mirrored to the DR data center. All of 
it. Every single volume. Jim suspected and then confirmed that because of a 
change in R13, a failing page-in caused an I/O redrive, which lost track of the 
failing page request, which never got put back on the queue. With XRC active, 
some percentage of page-ins got tangled up with SDM I/O. More lost frames. 
Eventually MVS ran completely out of frames, and the system wait-stated. Auto 
SAD. Auto IPL. It was Development, so at 05:00, there were no user calls. Ops 
never noticed. 

Jim fixed the problem immediately. I believe in auto IPL. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Friday, May 12, 2017 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

On Fri, 12 May 2017 16:18:14 +, Jesse 1 Robinson  
wrote:

>I'm curious as to why you do not want automatic reIPL after SADMP. Your   
>system is in a non-restartable wait state, after all. I view that as the  
>ultimate performance degradation. ;-) You have an SAD. If want to look at 
>it or at OPERLOG, you need at least one system in the sysplex up and  
>running. Why not this one?
>  
>IBM has recommended auto IPL for many years based on decades of problem   
>analysis.  Nothing will ever get better on a dead system. ReIPL might fail,   
>but it's worth a try. You can also speed up SAD such that no operator 
>intervention is required. It's possible for a system to die, take an SAD, 
>and reIPL before the operator gets back from coffee break. I've seen it   
>happen.   
>  

If IBM-MAIN had a like button or thumbs up, you would have it.   Haven't 
actually had
a crash in a long time, but the last time my client had one that was basically 
the scenario.
By the time I was getting instant messages and automated alerts / pages were 
going out to everyone, the system was already back up and had 100% application 
availability.  It was something like a 10 minute outage total.  The client 
wasn't happy, but it sure beats the heck out of "the old days" of initiating a 
stand alone dump manually and re-ipling after it completed.  That's if an 
operator or even a sysprog could find the doc or knew how to do an SADUMP and 
do it correctly! 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AUTOIPL SADUMP LOADPARM flag value

[Mark Zelden]

On Fri, 12 May 2017 16:18:14 +, Jesse 1 Robinson  
wrote:

>I'm curious as to why you do not want automatic reIPL after SADMP. Your   
>system is in a non-restartable wait state, after all. I view that as the  
>ultimate performance degradation. ;-) You have an SAD. If want to look at 
>it or at OPERLOG, you need at least one system in the sysplex up and  
>running. Why not this one?
>  
>IBM has recommended auto IPL for many years based on decades of problem   
>analysis.  Nothing will ever get better on a dead system. ReIPL might fail,   
>but it's worth a try. You can also speed up SAD such that no operator 
>intervention is required. It's possible for a system to die, take an SAD, 
>and reIPL before the operator gets back from coffee break. I've seen it   
>happen.   
>  

If IBM-MAIN had a like button or thumbs up, you would have it.   Haven't 
actually had
a crash in a long time, but the last time my client had one that was basically 
the scenario.
By the time I was getting instant messages and automated alerts / pages were 
going
out to everyone, the system was already back up and had 100% application 
availability.  It was something like a 10 minute outage total.  The client 
wasn't happy,
but it sure beats the heck out of "the old days" of initiating a stand alone 
dump 
manually and re-ipling after it completed.  That's if an operator or even a 
sysprog
could find the doc or knew how to do an SADUMP and do it correctly! 

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

[Peter Hunkeler]

>> Interesting. A reference to _gtca() also in LE Vendor Interfaces. Hints here 
>> and there in the C/C++ docs.

> I suspect _gtca() does something similar to what is described in "Chapter 14. 
> Anchor support" in the LE Vendor Interfaces manual.


Out of curiosity, I had a look at CEEARLU. The instruction sequence matches 
what is documented in the above mentioned chapter, except for the checking of 
R12 before continuing with it. 58C0 0010  | L   R12,X'10'58CC   
| L   R12,X'0'(R12)58CC 0004  | L   R12,X'4'(R12)58CC 0144  | L 
  R12,X'144'(R12)BFCF C000  | ICM R12,X'F',X'0'(R12)4780 F022  
| BC  X'8',X'22'(,R15)BFCF C000  | ICM R12,X'F',X'0'(R12)4780 F022  
| BC  X'8',X'22'(,R15)07FC   | BCR X'F',R121BCC   | 
SR  R12,R1207FE   | BCR X'F',R14


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AUTOIPL SADUMP LOADPARM flag value

[Jesse 1 Robinson]

I'm curious as to why you do not want automatic reIPL after SADMP. Your system 
is in a non-restartable wait state, after all. I view that as the ultimate 
performance degradation. ;-) You have an SAD. If want to look at it or at 
OPERLOG, you need at least one system in the sysplex up and running. Why not 
this one?

IBM has recommended auto IPL for many years based on decades of problem 
analysis. Nothing will ever get better on a dead system. ReIPL might fail, but 
it's worth a try. You can also speed up SAD such that no operator intervention 
is required. It's possible for a system to die, take an SAD, and reIPL before 
the operator gets back from coffee break. I've seen it happen. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Thursday, May 11, 2017 11:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AUTOIPL SADUMP LOADPARM flag value

Hello Jim,

thank you.

summary:-

SADUMP treats last LOADPARM character as if it is a hexadecimal nibble.

1...  8   - reserved for IBM - do not use
.1..  4   - SADUMP will attempt re-ipl using stored DIAG member MVS() 
parameter values
..1.  2   - unassigned - do not use
...1  1   - unassigned - do not use

We will be coding "0" to ensure no auto re-ipl is attempted by SADUMP.
Our exercise is to speed up SADUMP capture. we will use loadparm  SNSYSC0.

For our general usage we will code a SYMBOL for the SADUMP ucb address, and use 
AUTOMATION script to identify the UCB address of the second volume in the 
sysres set based on our volume naming standards, use SYMUPDTE process to 
dynamically update the symbol value, then use SET DIAG command to update the 
SADUMP UCB address. This to be performed after every IPL.

Activities, such as TDMF relocation of SYSRES volumes will be managed by 
re-driving the AUTOMATION script.

Regards
Bruce Hewson

On Wed, 10 May 2017 14:35:09 -0400, Jim Mulder  wrote:

>  Currently, "2" will be treated the same as "0" or " " (blank).There 
>is no reason
>why you should have specified "2", and a good reason not to - there is  
>a possibility that in some future release, we might assign some meaning 
>to "2".
>
>  Standalone dump treats this character as a hexadecimal digit 
>representing four option bits.  The first bit is an undocumented option 
>intended to be used only under my direction.  The second bit is what is 
>documented for "4".  The third (corresponding to "2") and fourth bits 
>are currently unused.
>
>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>Poughkeepsie NY


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to find Cobol (and C) Working Storage variables in an SVCDUMP

[Tom Marchant]

On Thu, 11 May 2017 17:08:41 -0500, John McKown wrote:

> STM R0,RF,12(RD) SAVE ALL REGS.
> L R3,0(,R1) POINT TO RETURN AREA
> ​MVC 0(64,R3),12(RD) MOVE REGS AT ENTRY
> SLR RF,RF
> BR RE
>
>This does not use standard linkage, but is that really necessary?

You are going to store 16 registers (64 bytes) at offset 12 in a 
72-byte save area? What is in the word that you will clobber?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: job output into dataset

[venkat kulkarni]

Hello Lizette,

Thanks for reply. I will add JESLOG=SPIN in my proc. But one of my query
still answered that do we need to recycle address space after changing STC
class outdisp paramter to write,write  to make this spin work . Or can we
do it dynamically without shutting down address space.

On Fri, May 12, 2017 at 10:05 AM, Lizette Koehler 
wrote:

> So the best option would be to do
>
> 1)  Check the STC in the JES2 Class and see if JESLOG=SPIN is included.
>
> 2)  Start the STC with the SPIN Option
>
> JESLOG=
> Specifies for the indicated jobclass that each job's JESLOG data
> (JESMSGLG and JESYSMSG data sets) is to be spun at a certain time interval,
> suppressed from being recorded, or not spun at all.
> Note: Specifying JESLOG=SPIN will cause a job in this class to use at
> least 2 additional track groups of SPOOL space for the two JESLOG data sets
> (JESMSGLG or JESYSMSG ). If this job class normally has a large number of
> jobs that use a minimal amount of SPOOL space, then an increase of 2 track
> groups could significantly increase SPOOL utilization. Consider these
> additional SPOOL requirements when deciding whether to use JESLOG=SPIN.
>
> SPIN
> Jobs running in this job class are 'spinnable'. $TJ,SPIN can
> be used to immediately spin the JESMSGLG and JESYSMSG data sets.
>
> (SPIN,+hh:mm)
> Indicates to spin JESLOG every hh:mm time interval.
>
> where:
>
> hh is hours and has a range of 0 through 23
> mm is minutes and has a range of 00 through 59
>
> Note: You must specify a minimum of 10 minutes or JES2 issues
> an error message. Also, for time intervals of less than one hour, you must
> specify the following format: JESLOG=(SPIN,+00:mm).
> (SPIN,hh:mm)
> Indicates to spin JESLOG at hh:mm every 24 hours.
> (SPIN,nnn)
> Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG
> has nnn lines.'nnn is the number (1–999) of lines in the data set.
> Note:
> You must specify a minimum of 500 lines or JES2 issues an
> error message.
> (SPIN,nnnK)
> Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG
> has "nnnK" lines, where "K" indicates thousands of lines.
> (SPIN,nnnM)
> Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG
> has "nnnM" lines, where "M" indicates millions of lines.
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of venkat kulkarni
> > Sent: Thursday, May 11, 2017 9:37 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: AW: Re: job output into dataset
> >
> > Hello All,
> >
> > Finally I have good news. Today we performed below steps.
> >
> > 1) I changed my message class z out disp parameter to write,write and
> then
> > run spin command but still no oputut saved in output queue.
> >
> > 2) I restarted IMS address space and before running spin command against
> > jesmsglg dd, I verified that my stc class outdisp is set to write,write .
> > Now, when I run spin command, I get record in output queue with
> destination
> > local and this is what we were looking for u .
> >
> > But this whole excersice make me to conclude that
> >
> > a) any running address space will not accept new value of outdisp
> parameter
> > on stc class( or any other class) using dynamic command $t .
> > So, we will have to recycle address space to take this effect. This
> dynamic
> > command is only useful for new address space we start after we change
> > parameter using $t.
> >
> > b) when we use spin command with jes dd like jesmsglg etc, we will not
> get
> > successful completion message on console .
> >
> > 3) do we have any way to make this process successful without recycle of
> > address space .
> >
> > Thank you so much for all help .
> >
> > On 10-May-2017 11:48 PM, "Lizette Koehler" 
> wrote:
> >
> > > NOTE:  JES2 has a counter in the JCT.  Even if output is spun, it will
> > > not reduce that counter by what is spun.  The counter will continue to
> > > increase.  And it can increase until, the number of lines, exceeds
> > > what
> > > JES2 knows that should be produced which can cause a task to abend
> > > with a
> > > S722 abend.  No way around that other than cycling the tasks.
> > >
> > > I currently have a task that is prone to S722 abends.  It is an STC
> > > and it is now being cycled monthly to prevent an unexpected S722 abend.
> > >
> > >
> > >
> > > Spin - to copy/route the information in a SYSOUT DD statement to the
> > > OUTPUT class specified by the SYSOUT statement.
> > >
> > > If your JES2 INITDECK says
> > >
> > > OUTPUT(A) OUTDISP=(HOLD,HOLD)
> > >
> > > You have
> > > //DDlabel  DD SYSOUT=A
> > >
> > > Then the DDlabel:  $Txx,SPIN,DDNAME=DDlabel
> > >
> > > The output will show up in the HELD Class A queue.   

Re: rename datasets

[Lizette Koehler]

The TMC has two fields.

Full tape dataset name

And a second field that contains the last 17 characters.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, May 11, 2017 9:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: rename datasets
> 
> On Thu, 11 May 2017 08:40:47 -0500, Scott Barry wrote:
> >
> >Any datasets on tape or all DASD (any with more than 17 character tape
> dataset name?)  TMC consideration possibly depending on the tape management
> subsystem (i.e., CA-1 has a utility but last 17 characters are recorded in
> the TMC)?  Otherwise depending on security/authority, IDCAMS ALTER should
> likely satisfy.
> >
> So renaming a tape data set might involve updating the HDR1 label?
> 
> Let's not go there.  Or not attempt a rename to alter those last 17
> characters.
> 
> I'd expect TMC to record the entire 44 characters so it could deal with DSNs
> identical in the last 17 but with different prefixes.
> 
> -- gil
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AW: Re: job output into dataset

[Lizette Koehler]

So the best option would be to do 

1)  Check the STC in the JES2 Class and see if JESLOG=SPIN is included.

2)  Start the STC with the SPIN Option

JESLOG=
Specifies for the indicated jobclass that each job's JESLOG data (JESMSGLG 
and JESYSMSG data sets) is to be spun at a certain time interval, suppressed 
from being recorded, or not spun at all.
Note: Specifying JESLOG=SPIN will cause a job in this class to use at least 
2 additional track groups of SPOOL space for the two JESLOG data sets (JESMSGLG 
or JESYSMSG ). If this job class normally has a large number of jobs that use a 
minimal amount of SPOOL space, then an increase of 2 track groups could 
significantly increase SPOOL utilization. Consider these additional SPOOL 
requirements when deciding whether to use JESLOG=SPIN.

SPIN
Jobs running in this job class are 'spinnable'. $TJ,SPIN can be 
used to immediately spin the JESMSGLG and JESYSMSG data sets.

(SPIN,+hh:mm)
Indicates to spin JESLOG every hh:mm time interval.

where:

hh is hours and has a range of 0 through 23
mm is minutes and has a range of 00 through 59

Note: You must specify a minimum of 10 minutes or JES2 issues an 
error message. Also, for time intervals of less than one hour, you must specify 
the following format: JESLOG=(SPIN,+00:mm).
(SPIN,hh:mm)
Indicates to spin JESLOG at hh:mm every 24 hours.
(SPIN,nnn)
Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG has 
nnn lines.'nnn is the number (1–999) of lines in the data set.
Note:
You must specify a minimum of 500 lines or JES2 issues an error 
message.
(SPIN,nnnK)
Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG has 
"nnnK" lines, where "K" indicates thousands of lines.
(SPIN,nnnM)
Indicates to spin JESLOG whenever either JESMSGLG or JESYSMSG has 
"nnnM" lines, where "M" indicates millions of lines.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of venkat kulkarni
> Sent: Thursday, May 11, 2017 9:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: job output into dataset
> 
> Hello All,
> 
> Finally I have good news. Today we performed below steps.
> 
> 1) I changed my message class z out disp parameter to write,write and then
> run spin command but still no oputut saved in output queue.
> 
> 2) I restarted IMS address space and before running spin command against
> jesmsglg dd, I verified that my stc class outdisp is set to write,write .
> Now, when I run spin command, I get record in output queue with destination
> local and this is what we were looking for u .
> 
> But this whole excersice make me to conclude that
> 
> a) any running address space will not accept new value of outdisp parameter
> on stc class( or any other class) using dynamic command $t .
> So, we will have to recycle address space to take this effect. This dynamic
> command is only useful for new address space we start after we change
> parameter using $t.
> 
> b) when we use spin command with jes dd like jesmsglg etc, we will not get
> successful completion message on console .
> 
> 3) do we have any way to make this process successful without recycle of
> address space .
> 
> Thank you so much for all help .
> 
> On 10-May-2017 11:48 PM, "Lizette Koehler"  wrote:
> 
> > NOTE:  JES2 has a counter in the JCT.  Even if output is spun, it will
> > not reduce that counter by what is spun.  The counter will continue to
> > increase.  And it can increase until, the number of lines, exceeds
> > what
> > JES2 knows that should be produced which can cause a task to abend
> > with a
> > S722 abend.  No way around that other than cycling the tasks.
> >
> > I currently have a task that is prone to S722 abends.  It is an STC
> > and it is now being cycled monthly to prevent an unexpected S722 abend.
> >
> >
> >
> > Spin - to copy/route the information in a SYSOUT DD statement to the
> > OUTPUT class specified by the SYSOUT statement.
> >
> > If your JES2 INITDECK says
> >
> > OUTPUT(A) OUTDISP=(HOLD,HOLD)
> >
> > You have
> > //DDlabel  DD SYSOUT=A
> >
> > Then the DDlabel:  $Txx,SPIN,DDNAME=DDlabel
> >
> > The output will show up in the HELD Class A queue.   So the H Panel in SDSF
> >
> > If you have coded in the JES2 INITDECK
> > OUTPUT(A) OUTDISP=(WRITE,WRITE)
> >
> > And you have
> > //DDLabel  DD SYSOUT=A
> >
> > The output will show up in the OUTPUT CLASS A.  So the O Panel in SDSF
> >
> > Note:  If you do not CODE FREE=CLOSE,SPIN=UNALLOC You will NOT see the
> > output
> >
> > The SPIN will not be available until TASK end.
> >
> > The ST panel in SDSF can see everything available on Spool.
> >
> > NOTE SYSOUT=* in a started task defaults the the STC definition in JES2.
> >
> > Spin data set processing
> >
> > z/OS JES2 

Re: AUTOIPL SADUMP LOADPARM flag value

[Bruce Hewson]

Hello Jim,

thank you.

summary:-

SADUMP treats last LOADPARM character as if it is a hexadecimal nibble.

1...  8   - reserved for IBM - do not use
.1..  4   - SADUMP will attempt re-ipl using stored DIAG member MVS() 
parameter values
..1.  2   - unassigned - do not use
...1  1   - unassigned - do not use

We will be coding "0" to ensure no auto re-ipl is attempted by SADUMP.
Our exercise is to speed up SADUMP capture. we will use loadparm  SNSYSC0.

For our general usage we will code a SYMBOL for the SADUMP ucb address, and use 
AUTOMATION script to identify the UCB address of the second volume in the 
sysres set based on our volume naming standards, use SYMUPDTE process to 
dynamically update the symbol value, then use SET DIAG command to update the 
SADUMP UCB address. This to be performed after every IPL.

Activities, such as TDMF relocation of SYSRES volumes will be managed by 
re-driving the AUTOMATION script.

Regards
Bruce Hewson

On Wed, 10 May 2017 14:35:09 -0400, Jim Mulder  wrote:

>  Currently, "2" will be treated the same as "0" or " " (blank).There 
>is no reason
>why you should have specified "2", and a good reason not to - there is  a
>possibility that in some future release, we might assign some meaning to 
>"2".
>
>  Standalone dump treats this character as a hexadecimal digit 
>representing four option bits.  The first bit is an undocumented option 
>intended to be used only under my direction.  The second bit is what
>is documented for "4".  The third (corresponding to "2") and fourth bits 
>are 
>currently unused. 
>
>Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>Poughkeepsie NY

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: rename datasets

[Peter Hunkeler]

>we are looking at renaming all of the datasets like the below.
 >
>Old dataset - >  SLXR5V.SAPDB.*
>New dataset - > SLXR5V.SAPDB.X.*



Something that nobody had mentionesd so far: A rename will *not* move that data 
set to some other storage group. I.e. while a rename will drive ACS routines, 
and the data set may get different Management and Storage classes assigned, the 
data set will *not* be physically moved. So data sets may be left with 
conflicting attributes, e.g. a management class requesting some backup or 
performance attribute that the current DASD (storage group) does not provide.




I doubt this matters in your case. But generally speaking, keep the above in 
mind when doing renames.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN