Re: ADRDSSU issue
VSAM data sets are required to be cataloged. If you look up the ADR468E message is says: If the REPLACE or REPLACEUNCONDITIONAL keyword was not specified, one of the following conditions applies: * If DELETE is specified and the entry name is a SYS1., page, or swap data set, the RENAMEUNCONDITIONAL or PROCESS(SYS1) subparameter was not specified. * If the entry name is a cluster name and DELETE was not specified: (1) the RENAMEUNCONDITIONAL subparameter was not specified or (2) the RECAT subparameter was not specified. * If the entry name is an alternate index or a user catalog name: (1) the DELETE subparameter was not specified or (2) the RENAMEUNCONDITIONAL subparameter was specified. * If the entry name is a user catalog name, INDDNAME or INDYNAM was specified. So you either need to specify the DELETE keyword if you are trying to move the data sets. If you are not trying to move the data sets and just want another copy then you need to specify the RECAT(catalogname) where the catalog catalogname is not in the standard order of search (no alias defined to the master catalog). Or if you are trying to just have a copy with a new name then you need to specify the RENAMEU(high_level_qualifier) to rename the data set's high level qualifier to which will then catalog the target VSAM data sets with the new name (other renaming options are available, look up the RENAMEU keyword in the DSS Storage Admin Guide). Some of your non-VSAM data sets may have been copied because they do not have the requirement to be cataloged. So then there is no conflict because they can be copied and leave the target data set uncataloged. BYPASSACS(**) and NSC will bypass the ACS routines and allow you to direct the datasets to a non-SMS volume. Keep in mind though that some data set types require SMS management. Hope that helps. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFDSS QUESTION - ADR8661
There should be no action required with that diagnostic information. This problem was found and fixed in z/OS V1R10 and the message won't be issued from that release on when the rename for that particular reason. Justin Eastman IBM - DFSMSdss Developer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMSrmm Tape encryption
DFSMSdss supports encryption for DUMPs. I believe you need the software encryption facility on your system and then a license to allow DSS to use it. Usage is explained in the z/OS V1R11.0 DFSMSdss Storage Administration guide. DFSMSdss can use the following types of host-based encryption to secure your data: * Triple-length Data Encryption Standard (TDES) clear keys * Secure TDES keys * 128-bit Advanced Encryption Standard (AES) clear keys. If extra CPU cycles are available then host based encryption can be a good solution. If not, hardware encrypting tape drives are a good option if that is a concern. The hardware encrypting tape drives actually encrypt in real-time as the data is written to the tape. Just wanted to let you know the options out there in regards to DFSMSdss. Justin Eastman IBM z/OS DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
While I am not certain of any "magical" incantations, if you update the DATACLAS for the existing data sets with the desired EATTR value then, during a DSS COPY, the new allocation of these data sets should be allocated with the new EATTR value you defined. You could also define a new DATACLAS, do a DSS COPY with RENAMEU and have your ACS routines assign the new DATACLAS based on the naming convention. And, as I have already seen mentioned, you can invoke DSS via an API and in EXIT 28 specify the EATTR value to be used for the target allocation. Finally, there is the undesired pre-allocation method. As far as I know these are the only ways to modify EATTR via the use of DSS. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Magical Incantations in ADRDSSU
EATTR only specifies whether a data set is allocated with F8/F9 DSCBs. In order for a data set to be allocated to the cylinder managed space, it must have EATTR = OPT (or EATTR=NS for VSAM as the default is to have F8/F9 DSCBs) and then it must be larger than the defined Break Point Value(BPV) to be allocated to the cylinder managed region. So if the data set is not greater than your BPV it will be allocated to the track managed region. So unless your BPV is less than the size of all the data sets you are trying to get to the cylinder managed region, its working as designed. Justin Eastman IBM DFSMSdss Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FlashCopy problem?
The problem with doing the full volume copy even with nocopy is that track 0 is always copied which indicates where the VTOC is. So if both of the volumes do not have the VTOC in the same location then the volume will need to be initted so that track zero VTOC field points to the true location of the VTOC. If they are in the same place, then its possible that the tracks of the VTOC or VTOCIX of the source are updated and this kicks off a background copy of the changed track which could then screw up the VTOC or VTOCIX on the target volume if its position overlaps with the source volume. DFSMSdss has been changed in APAR OA18929 to perform a volume INIT when FCWITHDRAW is specified on the DUMP when it is detected that it is needed. Justin Eastman DFSMSdss Development -- 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: FlashCopy problem?
As someone said before you can ignore the DSF messages or you can use BLDWTOR to reply to your messages. The following essentially replies to all ICK003D messages for all steps in the job //STEP01 EXEC PGM=BLDWTOR //WTORIN DD * WHEN(ICK003D,*,*,*) REPLY U But you can modify it for specific steps and such. Justin Eastman IBM - DFSMSdss Development -- 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: FlashCopy problem?
>What is BLDWTOR? I don't have that anywhere that I can find on my z/OS >1.8 system. > My apologies. It is an internal exec. I was under the impression it was a standard thing. Justin Eastman IBM - DFSMSdss Development -- 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: ADRDSSU to dump Selective mebers of PDS to PS or Tape
On Thu, 15 May 2008 16:02:41 +0300, ××× ×× ××× <[EMAIL PROTECTED]> wrote: >The output from ADRDSSU is not meant to be read by humans. > >If you want to copy members from one PDS to another, use IEBCOPY. > >Gadi > Not sure that is all that fair. If you know the format, its perfectly readable. But maybe as a DSS developer, I am not entirely human ; ) Justin Eastman IBM DFSMSdss Development -- 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: ADRDSSU to dump Selective mebers of PDS to PS or Tape
As others have said, you are getting exactly what you are asking for here. If
you simply want to look at another copy other than the original, you can just
do a DFSMSdss logical copy of the data set and then you should be able to
just browse the members. Then, if you wish to print you can then use
DFSMSdss print to print the data sets. Not sure if that is the ultimate
intention of what you wanted to do, but your intentions are not clearly
stated.
Hope that helps. Byt the way, your printout below looks perfectly normal for
the steps you have taken.
Justin Eastman
IBM DFSMSdss Development
On Thu, 15 May 2008 07:43:20 -0500, vignesh
<[EMAIL PROTECTED]> wrote:
>Hi,
>I am trying to use ADRDSSU with Dump option to dump all my PDS members
>using Include option. But the file created with dump option is with Record
>length >80 and data is not viewable / meaningful format.
>I tried the ADRDSSU with PRINT option too.Which also yielded the same
result.
>
>The Following is the output iam getting with the JCL as shown:
>
>//STEP010 EXEC PGM=ADRDSSU,COND=(0,NE)
>//SYSPRINT DD SYSOUT=*
>//INPUT12 DD DSN=xx.xxx.,DISP=SHR (PDS dataset name)
>//BKFILEDD DSN=SVRB.MDM.RAINQ.TEST.PROC1,DISP=SHR
>//SYSIN DD *
> DUMP INDDNAME(INPUT12) OUTDDNAME(BKFILE)
>/*
>//*
>
>My output file contains:
>
>...ç.ØØ._...STM246a...?.ãñè...4ã
>...>.Ø .BMBB.^·°.i...0"Û.0"..ÿ.¬Õ.Ø.{.."[EMAIL
>PROTECTED]
>...>.Ø .BMBB.^[0.i.0.8.
>...>.Ø .BMBB.^B&.iÚ
>
>
>Could anyone offer any help on this.
>Further, I also need to produce a Dump of members named AMP* friom my list
>of PDS files only.
>
>--
>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
--
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: Kudos to IBM's promotion
I think you hit the nail on the head here Steve. I volunteer to help with Universities in Arizona for the IBM Academic Initiative. 2 of the 3 Universities have been approached in Arizona and the heads of the CS departments have stopped IBM in their tracks saying mainframes are not a technology that they see any future for and scoff at the idea of adding some curriculum to support them. These schools have been offered many incentives, but the bottom line is they don't want it. They don't understand the role mainframes play. On an upbeat note, one professor in the 3rd school has just introduced mainframes as part of his OS class and will be attempting to get an upper class z/OS introduction class into their curriculum. IBM Academic Initiative is working with companies to try to bring them to the Universities to speak to the CS departments to convince them of the need for these skills. They are tired of hiring senior level programmers to do entry level jobs. IBM is actively soliciting Universities to try to introduce more curriculum. So hopefully its moving in the right direction. Unfortunately, its an uphill climb at this point. If the interest is there to participate in convincing these Universities by anyone, I can most likely get you in contact with IBM Academic Initiative personel that are the reps in your area. Justin Eastman -- 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: Kudos to IBM's promotion
>But you have to have a two-pronged approach. It's nice >to have the universities offer z/OS-related training, >but you (IBM) still need to win the hearts and minds >of young techies and managers back to the values of the >platform, or they will never select or sustain it. > >We've discussed this to death: small to medium shops >either are getting off their mainframes or never going >there; large shops continue to enlarge their mainframe >capacity but are outsourcing their applications development >and maintenance. [And a number of large shops I know of >are looking to devise a long term strategy to get off >the mainframe.] > >If you don't grow the z/OS base, it will die; and sooner >rather than later. I sympathize with your point. But, tomorrow's techies/managers are the students in the Universities. These are the people that will influence the future of the z/OS base growth/death. Its hard to convince a shop to go BIG when they don't have the people to run it. I don't see an end to the mainframe anytime soon, possibly a slow very long drawn out death. Mainframes for big fortune 100/500 are a necessity rather than a choice. I don't want my bank account managed by a window/linux system, the RAS/Security is not there. Additionally, there are many legacy programs that are blackbox and the time and expertise to rewrite these programs is expensive and again requires the people to do it. SMB is a whole different story, I am a developer not a marketer so I cannot really comment on how to address that kind of problem. Lets not beat the dead horse... just wanted to comment on the educational front as I am involved and have a vested interest. Justin -- 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: HSM changed dataset indicator bit, how to prevent reset?
Try checking here http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/DGT2S440/12.2.11?SHELF=EZ2ZO10G&DT=2005071036 Looks like there is a DUMPCLASS(NORESET) option... hope that was what you were looking for. Justin Eastman On Fri, 5 May 2006 09:34:54 -0500, Jasen Kloeppel <[EMAIL PROTECTED]> wrote: >Is there a way to prevent HSM from reseting the changed datset indicator >bit? I want HSM autobackup to backup all changed datasets (datasets with >the changed bit on), but not reset the changed bit on the datasets it backs >up. > >We currently also run FDR and it does weekly full and daily incremental >backups and resets the changed bit. I want to run the DFSMShsm process >without impacting the current production FDR processing, which I can do if I >can prevent HSM from resetting the changed bit on the datasets. > >With FDR I can prevent it from resetting the changed bit with the >UPDATEFLAG=NOCHANGE option, but I haven't been able to find an equivalent >function in HSM. > >Thanks for any help, > >Jasen Kloeppel >[EMAIL PROTECTED] >573-214-6506 >Shelter Insurance Companies >Columbia, MO 65218 > >_ >FREE pop-up blocking with the new MSN Toolbar – get it now! >http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > >-- >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 >= -- 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: HSM changed dataset indicator bit, how to prevent reset?
>Looks like there is a DUMPCLASS(NORESET) option... hope that was what you >were looking for. Well I guess that is only for the dump case. For autobackup, there may not be a way. Mark Thomen makes a good point, why do you want to not have that bit updated? Justin -- 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 use "ADRDSSU" to copy multiple volume dataset to other DASDs
Tommy, Not sure what you mean by "Flashcopy is deactivated"? Flashcopy Version 1 only supports full volume flashcopy. Flashcopy Version 2 spuports data set level flashcopy, which does not make a distinction between single and multi-volume data sets. So you will have to determine what version of Flashcopy your ESS supports. If you specify FR(REQ) along with DEBUG(FRMSG (DETAILED)), you will get messages letting you know why your flashcopy is not being performed and then it won't be copied using traditional I/O. If you really don't want EXCP to be used you should specify FR(REQUIRED) so that you only get Flashcopy. Other than that you job appears fine. Justin Eastman DFSMSdss Development -- 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: 轉寄： Re: how to use "ADRDSSU" to copy multiple volume dataset to other DASDs
As it mentions in the ADR918I message explanation, for extent reason codes you have to look at the QFRVOLs extent reason codes in the Advanced Services manual. Your target appears to be a PPRC primary volume which cannot normally be eligible for a target Flashcopy relationship. Refer to the following FCTOPPRCprimary keyword explanation: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/DGT2R241/3.6.4.28? SHELF=EZ2ZO10G&DT=20060126011812&CASE= Pretty sure that using this keyword will resolve you issue, but be AWARE your PPRC relationship will go from full duplex to duplex pending state. Again you can refer to the Advanced Services manual for more information on PPRC volume relationships. Also this DFSMSdss support was shipped in OA06196 and will be needed to specify the keyword, but addtionally some HW support is also required (refer to the ++HOLD information in the OA06196 apar). Justin -- 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
