Re: DFDSS RFE - Please read / vote

[willie bunter]

 I thought the UNCOND DELETE PURGE parms could be used along with the COPY 
command

On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden 
 wrote:  
 
 Hi all,

Please read / vote for this RFE.


"Provide abilty for DSS to be able to scratch and reallocate an in use data set 
name that is not the actual dataset in use during a logical copy operation"

https://ideas.ibm.com/ideas/ZOS-I-3862

I think you vote here:
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862

I was honestly shocked this is not supported in DFDSS.  I've been using FDR for 
over 30 years for this.

I don't know if you can see the entire text, so I will copy it below to explain 
the issue, but in summary:

If you are copying a dataset to a maintenance sysres (target sysres that will 
be cloned) and that DSN 
is ENQd, the copy will work - unless the dataset needs to be scratched / 
reallocated because the
input dataset is larger than the output one that already exists.  I've been 
supporting clients for
30 years that keep ISV (and IBM non-OS) products as an extension of the sysres 
and recently
ran into this at a client that dumped FDR since they had DFDSS and ran into 
this problem.

If you know a way around the issue - shoot!  IBM says it is not supported.  You 
can delete the
not in use dataset after rename (if allowed) but that is error prone since you 
have to point to 
the maintenance volume and I don't want JR. people doing this.  One other work 
around is
after the logical copy fails, you can run it again as physical since the 
dataset is enlarged
on the first try, but just fails in scratch.  BTW, "CATALOG" is never used in 
this copy since
the datasets are indirectly catalogged.  

Now for the RFE main part of the RFE text:

---

Putting maintenance onto a "target" / maintenance sysres volume or set has been 
an MVS concept  and cloning an IPLable sysres set (or swapping IPL sets) 
"forever" . Many shops also put other IBM products or ISV products on a 
secondary / tertiary sysres and indirectly catalog them so they are on the 
sysres set.  This is the only way to support rolling IPLs in a sysplex so there 
are not application outages (another MVS concept).  Since those secondary / 
tertiary  volumes are a combination of products, adding new datasets is done 
via logical copy of a product's target libraries to the target / maintenance 
sysres and those datasets are indirectly catalogged using a system symbol like 
, , etc.  The copy to the "target" system (maintenance sysres) 
works fine even if the same named dataset is in use on the live sysres set (be 
it in the LNKLST, TSO PROC, STC STEPLIB etc.).  EXCEPT... when the dataset 
needs to be enlarged as part of the copy process.  In that case you get message 
ADR497E RC 102 Reason code FP-007 and "ERROR OCCURRED WHILE DELETING 
UNCATALOGED DATA SET" and the copy for that dataset fails.  However, the 
dataset to be "overlaid" (if you will), is not the dataset in use so DFDSS 
should have the ability to enlarge it and do the copy.  The only solution is to 
use the DFSMS special SAF authority to rename a dataset in use 
(STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset on the 
maintenance volume, then delete it, then rerun the copy job.  This could be 
very error prone if someone doesn't put in the correct volser on ISPF  and they 
could rename the "real" in use dataset or perhaps one on a different sysres 
set.  

---

Please vote this one up!  

Best 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
  

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

Re: Israel

[willie bunter]

 Yes, of course it has.  The rules depend upon the "subject" being posted.  It 
may have nothing to do with technical information.

On Monday, October 9, 2023 at 08:05:48 p.m. EDT, Dave Beagle 
<0525eaef6620-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Have the rules been suspended?


Sent from Yahoo Mail for iPhone


On Monday, October 9, 2023, 4:55 PM, esmie moo 
<012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

 Enough please about politics.  This is a technical information board.  Daren 
please pull the plug on this thread.  

    On Sunday, October 8, 2023 at 12:46:05 p.m. EDT, Steve Beaver 
<050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Has anyone heard from Benyamin in Israel since the shit storm has started?

Sent from my iPhone

No one said I could type with one thumb 

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

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




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

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

Re: With regrets, after many years I will no longer be following IBM-MAIN

[willie bunter]

 I think that instead of posting surly replies refrain from posting.  No need 
for unpleasantness.

On Monday, September 4, 2023 at 01:37:00 a.m. EDT, Brian Westerman 
 wrote:  
 
 I think even the ones that abuse the list the most still provide assistance 
from time to time that is very useful.  I completely understand that oftentimes 
they want the person to RTFM, which makes a lot of sense because you also don't 
want the list to become a primary school.  The "new guys" need to learn how to 
use the manuals and I think the "old guys" are trying to, in their own way, 
help them to see that using the manuals and figuring stuff out is a good thing. 
 Where it becomes an issue is when the newbie honestly can't figure it out and 
may have truly tried to find the solution on their own. 

It might be helpful for them, in fact everyone, to disclose what you have 
already tried or read about, that way everyone will see that they are trying 
and won't just kiss them off as using the list instead of manuals (and the 
internet) as opposed to using it in conjunction with attempting to learn.  

Sometimes they may have actually read the solution, but just don't see it as 
such, and by disclosing what they have tried so far will allow people to let 
them know where they missed something.  I think that no one likes to think that 
the guy asking the question is not even really trying to work the problem.  But 
without disclosing the path they are currently on, we have no way to know 
otherwise.

Just a thought.

Brian

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

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

Re: Bob Richards

[willie bunter]

 Very sad news.  Some of the best minds who have contributed to this board have 
left us.  Their loss is always felt.
Willie.

On Tuesday, February 28, 2023 at 10:15:10 p.m. EST, Rick Troth 
 wrote:  
 
 friends --

Our colleague Bob Richards passed away early this month (Feb).
He has lots of friends on this list, and I know that some already know, 
but I had not seen an announcement and I thought the rest should be aware.

I was able to keep in touch by way of his wife Rebecca. She is, of 
course, totally devastated.


-- R; <><

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

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

Re: Goodbye and thanks for all the fish

[willie bunter]

 Thanks Rebecca for the heartbreaking news.  His absence will be felt for years 
to come by members of this board.  His technical knowledge and wit is lost 
forever.I am sure, some place up there, Robert is smiling down on you and your 
family.May he rest in place.
Willie.

On Wednesday, February 8, 2023 at 08:11:02 p.m. EST, Rebecca Richards 
<049eeae74309-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Hi All,
This is Rebecca Richards. My husband Robert Richards has been an member of this 
list for many years.I just wanted let you know he died of bladder cancer this 
past Friday. I wanted to let everyone know 
Rebecca Richards


Sent from Yahoo Mail for iPad


On Wednesday, February 8, 2023, 3:17 PM, Wayne Bickerdike  
wrote:

I retired in 2021 but I still maintain an interest here. Good for the brain
cells.

Managed to lose 3Kgs and reduce my blood pressure :)

On Thu, Feb 9, 2023 at 2:11 AM Steve Thompson  wrote:

> Sorry to see you go. And I too am not a very active member. I
> read a lot and learn stuff.
>
> Hope you enjoy your retirement. Or, un-retirement if that is what
> you wish.
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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




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

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

Re: Limiting quantity of tape drives used by user

[willie bunter]

 In our shop we use AFF.  DEFER will mount the tape when requested (when the 
dsn is to be opened).  AFF will prevent multiple tapedrive allocations.

On Monday, November 7, 2022 at 01:46:23 p.m. EST, Paul Gilmartin 
<042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:  
 
 On Mon, 7 Nov 2022 12:24:21 -0600, Mike Schwab wrote:

>We had that in production  One step with a huge number of datasets, so
>allocates all available tape drives even though only 1 in use at any
>one time.
>
Does UNIT=(TAPE,,DEFER), or perhaps AFF, make a difference?

JES2 or JES3?

-- 
gil

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

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

Re: End of several eras

[willie bunter]

 I feel nostalgic after I read your post.  Get this, I started in 1978 and I 
worked on an OS/360.  I was an IMS DB/DC tech. running batch (via BMP) and 
batch jobs which updated the database.  One problem I often encountered - the 
IMS/DC would abend because log tapes (dual logging) due to a STC tape drive 
(6250's) had a problem. IMS/DC had to stay down until I had to copied the log 
tape to another because the EOF was not written.  The phones would be ringing 
off the hook because IMS/DC was down.
Those were the days.amen. 

On Monday, October 31, 2022 at 05:50:37 p.m. EDT, Gibney, Dave 
<03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote:  
 
 I just shutdown our z/OS 2.3 system(s) for the last time.
When I came to school in 1976, the computer was described as  "loosely coupled 
370s". My exposure was via remote cardreader/printer.
When I started working here in 1981, there were still folks that had rewired 
boards for what they had before that.
End of 2019, we moved from a 10 year old z9 to MFaaS with FNTS in Omaha.

Dave Gibney
Information Technology Services
Washington State University


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

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

Re: MCDS CDS BACKVOL fails

[willie bunter]

 Jake,
 I have seen a somewhat of a similar problem however I received the 
following other messages before the ARC0774E.  Check your syslog for other 
messages It may be that the Journal file needs to be enlarged.

ARC0026E JOURNALING DISABLED DUE TO EOV ERROR ON  
ARC0026E (CONT.) JOURNAL. MIGRATION, BACKUP, FRBACKUP, DUMP,
ARC0740I CDS BACKUP STARTING AT 09:17:40 ON 2016/11/15,
ARC0740I (CONT.)  SYSTEM PRD2, TO DASD IN PARALLEL MODE, DATAMOVER=HSM
ARC0744E MCDS COULD NOT BE BACKED UP, RC=0036,  
ARC0744E (CONT.) REAS=. MIGRATION, BACKUP, FRBACKUP, DUMP, AND
ARC0744E (CONT.) RECYCLE HELD.
ARC0100I HOLD COMMAND COMPLETED
ARC0748I LAST SUCCESSFUL CDS BACKUP-SET QUALIFIER IS 
ARC0748I (CONT.) V002
ARC0741I CDS BACKUP ENDING AT 09:17:40 ON 2016/11/15,  
ARC0741I (CONT.) STATUS=UNSUCCESSFUL
To fix that problem I did the following:SHUTDOWN DFHSM
ENARLGED HSM.JRNL TO 500 CYLS
STARTED UP HSM.
HOLD AND RELEASE HSM FUNCTIONS.
NO MORE ARC0026E ERROR MESSAGES ARE RECEIVED.
Let me know how you fared.
Willie


On Sunday, August 21, 2022 at 02:46:14 a.m. EDT, Jake Anderson 
 wrote:  
 
 Hello All,

Good morning

I tried running HSEND BACKVOL CDS but I got failed with below message,
infact I tried allocating the dataset with LLQ V0 but still it fails

ARC0744E MCDS COULD NOT BE BACKED UP, RC=0036, REAS=. MIGRATION, BACKUP

ARC0744E (CONT.) FRBACKUP, DUMP, AND RECYCLE HELD.











ARC0101I QUERY CDSVERSIONBACKUP COMMAND STARTING ON HOST=1

ARC0375I CDSVERSIONBACKUP, MCDSBACKUPDSN=DFHSM.MCDS.BACKUP,

ARC0375I (CONT.) BCDSBACKUPDSN=DFHSM.BCDS.BACKUP,

ARC0375I (CONT.) OCDSBACKUPDSN=DFHSM.OCDS.BACKUP,

ARC0375I (CONT.) JRNLBACKUPDSN=DFHSM.JRNL.BACKUP

ARC0376I BACKUPCOPIES=0003, BACKUPDEVICECATEGORY=DASD,

ARC0376I (CONT.) LATESTFINALQUALIFIER=V000, DATAMOVER=HSM

ARC0101I QUERY CDSVERSIONBACKUP COMMAND COMPLETED ON HOST=1

As per manual for return code 36 it says an error was encountered in
locating the backup data set indicated by DSID. reason code


Regards
Jake

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

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

Re: Extending a VTOC

[willie bunter]

 If you have FDR they have a very safe way of extending the VTOC.  I have done 
it multiple times sometimes at 3 a.m.
Willie


On Monday, August 1, 2022 at 06:15:35 a.m. EDT, Jack Zukt 
 wrote:  
 
 Hi all,
It has been way too many years since the last time I dabbled with ICKDSF
and VTOC definitions (probably over twenty, but I would rather not do the
math).
Back on those days, if memory serves me right, the only way to extend a
VTOC was to clean the DASD of all its contents, put it offline, and
recreate the VTOC with the new size. As a few years have passed, I have
been going through the ICKDSF manual trying to find out if a VTOC can be
extended without having to clear the volume first. I can not say that I
have became enlightened. It seems to be possible but I am not quite sure
about it. And this being a production volume I really would hate if things
do not work as expected.
So, in a nut shell, can I extend a VTOC from 90 to 900 tracks without
having first to clean the DASD of all its files?
Thank you in advance for any help,
Best regards
Jack

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

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

Re: HSM backups and CICS VSAM files,

[willie bunter]

 You will need to check which management class manages this dataset.  Then, 
while in ISMF, all the attributes of the MANAGEMENT class is displayed.It has 
been a few years since I worked with HSM.  Maybe someone else could correct any 
of my erroneous statements if I made any.Good LuckWillie. 

On Tuesday, June 7, 2022 at 08:48:54 p.m. EDT, Frank Swarbrick 
 wrote:  
 
 Is there a particular "rule" I might be looking for?

From: IBM Mainframe Discussion List  on behalf of 
willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, June 7, 2022 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: HSM backups and CICS VSAM files,

Take a look at the management class.  This is where the backup rules are reside.
Willie

    On Tuesday, June 7, 2022 at 12:11:38 p.m. EDT, Frank Swarbrick 
 wrote:

 As a developer I've come to rely on using HSM to restore prior day's data from 
production files where we don't take an explicit daily backup (as it's 
un-needed for normal business processing).  Some of these files are files that 
are open to CICS.  I find that HSM backs them up on some days but not on other 
days.  Is there a specific cause of this behavior?  The file (one particular 
one, but there are others) is open to CICS and being updated constantly 
throughout the day.

Thanks,
Frank

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


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

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

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

Re: HSM backups and CICS VSAM files,

[willie bunter]

 Take a look at the management class.  This is where the backup rules are 
reside.
Willie

On Tuesday, June 7, 2022 at 12:11:38 p.m. EDT, Frank Swarbrick 
 wrote:  
 
 As a developer I've come to rely on using HSM to restore prior day's data from 
production files where we don't take an explicit daily backup (as it's 
un-needed for normal business processing).  Some of these files are files that 
are open to CICS.  I find that HSM backs them up on some days but not on other 
days.  Is there a specific cause of this behavior?  The file (one particular 
one, but there are others) is open to CICS and being updated constantly 
throughout the day.

Thanks,
Frank

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

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

Re: Question About ADRDSSU

[willie bunter]

 No, only the dataset specified in the INCLUDE statement will be moved.  If you 
want ALL dsns moved from the volume (no recommended) instead of the dsn used 
parm INLUDE (**).  Why are you bypassing SMS?

On Monday, April 11, 2022, 07:13:45 p.m. EDT, esst...@juno.com 
 wrote:  
 
 .
Hello
.
I have a question regarding ADRDSSU -
In the past I have used the following control statements to MOVE a specific 
dataset from one volume to another.
.

//COPYMOVE EXEC  PGM=ADRDSSU,REGION=7M,TIME=99 
//SYSPRINT DD  SYSOUT=*                                            
//OUTVOL1  DD  DISP=SHR,VOL=SER=SYSV32,UNIT=SYSALLDA              
//SYSIN    DD    *                                                
  COPY DS( -                                                      
        INCLUDE ( MONSOON.V70.ZFS -                            
                  )  -                                            
          )          -                                            
      OUTDDNAME(OUTVOL1)  -                                        
      BYPASSACS(**)      -                                        
      CATALOG    -                                                
      DELETE    -                                                
      ALLEXCP    -                                                
      ALLDATA(*) -                                                
      TOL(ENQF)                                                    
/*                        
//
.
.
If I used the following INCLUDE statement , my understanding is that ADRDSSU 
will move ALL DATASETS (VSAM and Non VSAM) begining with MONSOON,V70 to another 
volume.
INCLUDE ( MONSOON.V70.** -  
.
Is My Assesment correct ?
.
Second
If the Target Volume already  contains a file begining with MONSOON.V70. what 
will happen  to that dataset ?
.
Paul 
*



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

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

Re: JCL checkers?

[willie bunter]

 I would also suggest JOBSCAN.  We had this product installed on our MAINFRAMES 
because of disatisfaction with other JCL checkers.  JOBSCAN will do the syntax 
and dataset checking.

On Thursday, March 11, 2021, 1:32:20 p.m. EST, Bill Giannelli 
 wrote:  
 
 What JCL checkers are normally available?
TYPRUN=SCAN requires actual submission of the job. I want to check syntax and 
datasets
thanks
Bill

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

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

Re: DFRMM tape movement JCL

[willie bunter]

 If I remember correctly the vaul pattern is defined in the VRS.
On Monday, December 7, 2020, 02:04:24 p.m. EST, Lizette Koehler 
 wrote:  
 
 Did you look in ISMF Option G Reports?

I think there are some in there

Lizette


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Monday, December 7, 2020 3:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFRMM tape movement JCL

Hello

Are there anyone who is still using offsite tapes (Vaults). Is there any 
specific JCLs are there to list the tapes in drive, list the tapes in vaults 
and movement inventory records to record movement of Tapes.

I did look into SYS1.SAMPLIB and ran some some report but still it gives me a 
wrong report about zero tapes in vault whereas we have 24 tapes in vault.

Could someone please point me in the right direction

zOS 2.2

Jake

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

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

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

Re: Goodbye.

[willie bunter]

You will be sorely missed.  Your help that you afforded us all is priceless.  
Enjoy your retirement.  Hopefully KLM rewards you with a plane ticket (business 
class of course) to any destination of your dreams.

Good health and much happiness.

Willie. 

On Monday, August 3, 2020, 3:45:09 AM EDT, Vernooij, Kees (ITOP NM) - KLM 
 wrote:  
 
 After more than 41 years working as a mainframe systems programmer, the time 
has come for me to say goodbye.
I enjoyed the mainframe world in all the aspects that I worked with, from SVS 
1.7 to z/OS 2.4, from a 370/158 to a z13s and all other flavours that came and 
went in the past decades.

It was a pleasure and an honour to participate in the ibm-main group, with all 
its high technical skills, that gave me so many answers and where I could 
answer some questions too.
But most I enjoyed the company of this global community, where I met people 
from all over the world, with their unlimited willingness to help others, their 
humour, their rants and their Friday afternoon subjects. I am really gonna miss 
all this.

I will retire on the 11th and unsubscribe then.
I wish you all the best!

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

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

Re: OFF TOPIC - SIGNING OFF LINKEDIN

[willie bunter]

Super.  It worked.  A massive thanks.


On Saturday, January 4, 2020, 3:53:51 PM GMT, ITschak Mugzach 
 wrote:  
 
 *To close your LinkedIn account:*

  1. Tap your profile picture.
  2. Tap the Settings icon in the top right corner of your profile.
  3. On the Account tab, tap Close account.
  4. Tap Continue to proceed with closing your account.
  5. Tap the reason for closing your account and tap Next.
  6. Enter your account password and tap Done.


On Sat, Jan 4, 2020 at 5:50 PM willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Good Morning All,
>
>    I am trying to end my association with LINKEDIN.  I have looked at all
> the options but I couldn't find anything.  I am sure it is staring me in
> the face.  Any suggestions would be gladly appreciated.
>
> Many thanks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

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

OFF TOPIC - SIGNING OFF LINKEDIN

[willie bunter]

Good Morning All,

    I am trying to end my association with LINKEDIN.  I have looked at all the 
options but I couldn't find anything.  I am sure it is staring me in the face.  
Any suggestions would be gladly appreciated.

Many thanks.

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

Re: COPYING PDS TO PDS ...

[willie bunter]

 Thanks John.  It worked.  Thanks to all who answered my post with their 
suggestions.
On Monday, December 2, 2019, 05:36:29 p.m. UTC, John McKown 
 wrote:  
 
 On Mon, Dec 2, 2019 at 10:47 AM willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> I am tryin to copy a large pds to 2 smaller pds's.  I am trying to copy
> all members starting from A to F to one pds and copy the rest of the
> members - G to Z - to another pds.  Could this be done?
> I was trying IDCAMS using the COUNT and SKIP parms to no avail.
> I would appreciate any  suggestions.
> Thanks.
>
>
IEBCOPY using the COPYGROUP command. Ref:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.idau100/u10601.htm

 An example output that I tried on z/OS 2.3 is:

                                        IEBCOPY MESSAGES AND CONTROL
STATEMENTS                              PAGE    1
IEB1135I IEBCOPY  FMID HDZ2230  SERVICE LEVEL UA92265  DATED 20170618 DFSMS
02.03.00 z/OS    02.03.00 HBB77B0  CPU 3906
IEB1035I JOARMC$  STEP1    11:59:36 MON 02 DEC 2019 PARM=''
GROUPCPY COPYGROUP INDD=I,OUTDD=O
          SELECT  MEMBER=(A*)
IEB1013I COPYING FROM PDSE  INDD=I        VOL=VPWRKC DSN=JOARMC.PDS.JCL
IEB1014I          TO PDS  OUTDD=O        VOL=VPWRKB DSN=JOARMC.JUNK.PDS
IGW01264I TOTAL PRIMARY NAMES: 33, FILTER PATTERN MATCHES: 2
IGW01551I MEMBER AMBLIST  HAS BEEN COPIED
IGW01551I MEMBER ASMACL  HAS BEEN COPIED
IGW01550I 2 OF 2 SPECIFIED  MEMBERS WERE COPIED
IEB147I END OF JOB - 0 WAS HIGHEST SEVERITY CODE

-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

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

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

COPYING PDS TO PDS ...

[willie bunter]

I am tryin to copy a large pds to 2 smaller pds's.  I am trying to copy all 
members starting from A to F to one pds and copy the rest of the members - G to 
Z - to another pds.  Could this be done?  
I was trying IDCAMS using the COUNT and SKIP parms to no avail.
I would appreciate any  suggestions.
Thanks.

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

Re: SMF PUZZLE

[willie bunter]

 John,
The file is PS.  I haven't tried type 42.  I will give it a shot.
On Tuesday, August 27, 2019, 02:16:46 a.m. UTC, John Kelly 
 wrote:  
 
 Did you try Type 42 subtype 27, VTOC update? Since you mentioned all of the
60 records, I assume the file is VSAM, surprised that there's nothing in a
69 recprd.

On Mon, Aug 26, 2019 at 12:34 PM Charles Mills  wrote:

> SMF 118 and/or its preferred replacement, SMF 119, has to be enabled in
> *two* places: SMFPRMxx (just like any other SMF type) and also in the TCPIP
> config file. (And perhaps in a third place for FTP -- I'm trying to
> remember.)
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Monday, August 26, 2019 8:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMF PUZZLE
>
>  Roger,
> I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
>    On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe <
> roger_l...@bigpond.com> wrote:
>
>  On Sat, 24 Aug 2019 17:29:30 +, willie bunter 
> wrote:
>
> >Good Day,
> >I am trying to find the user/job which created a dsn.  I run my
> trustworthy SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66
> 67 68 136 139 163.  The job showed the job which read the dsn & deleted it
> but it doesn't show who or which job created it.According to the LISTCAT
> the creation date of the dsn was Thursday Aug. 22.  I read the SMF tape for
> the previous week and subsequent days including Aug 22 & 23.
> >I was thinking if the dsn was created by a FTP or an UNIX upload process
> which may not be trapped by SMF
> >Any thoughts?  Any suggestions
> >
> If you think it might have been an FTP process, you will need to check out
> the SMF 118 records.
>
> Roger
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Kelly

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

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

Re: SMF PUZZLE

[willie bunter]

 I did search for recid 61-64.
On Monday, August 26, 2019, 03:58:31 p.m. UTC, Carmen Vitullo 
 wrote:  
 
 was a the dataset renamed possibly? not created, if so there should be an SMF 
60-64 breadcrumb I believe to see if it was renamed from another dataset ? 





Carmen Vitullo 

- Original Message -

From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, August 26, 2019 10:50:24 AM 
Subject: Re: SMF PUZZLE 

Roger, 
I looked for SMF 118 but nothing turned up. Thanks for the suggestion. 
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote: 

On Sat, 24 Aug 2019 17:29:30 +0000, willie bunter  
wrote: 

>Good Day, 
>I am trying to find the user/job which created a dsn. I run my trustworthy SMF 
>job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 163. 
>The job showed the job which read the dsn & deleted it but it doesn't show who 
>or which job created it.According to the LISTCAT the creation date of the dsn 
>was Thursday Aug. 22. I read the SMF tape for the previous week and subsequent 
>days including Aug 22 & 23. 
>I was thinking if the dsn was created by a FTP or an UNIX upload process which 
>may not be trapped by SMF 
>Any thoughts? Any suggestions 
> 
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records. 

Roger 

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

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


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

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

Re: SMF PUZZLE

[willie bunter]

 Roger,
I looked for SMF 118 but nothing turned up.  Thanks for the suggestion.
On Sunday, August 25, 2019, 10:45:43 a.m. UTC, Roger Lowe 
 wrote:  
 
 On Sat, 24 Aug 2019 17:29:30 +, willie bunter  
wrote:

>Good Day,
>I am trying to find the user/job which created a dsn.  I run my trustworthy 
>SMF job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 
>163.  The job showed the job which read the dsn & deleted it but it doesn't 
>show who or which job created it.According to the LISTCAT the creation date of 
>the dsn was Thursday Aug. 22.  I read the SMF tape for the previous week and 
>subsequent days including Aug 22 & 23.
>I was thinking if the dsn was created by a FTP or an UNIX upload process which 
>may not be trapped by SMF
>Any thoughts?  Any suggestions
>
If you think it might have been an FTP process, you will need to check out the 
SMF 118 records.

Roger

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

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

SMF PUZZLE

[willie bunter]

Good Day,
I am trying to find the user/job which created a dsn.  I run my trustworthy SMF 
job which looks for recids 05 14 15 17 18 61 62 63 64 65 66 67 68 136 139 163.  
The job showed the job which read the dsn & deleted it but it doesn't show who 
or which job created it.According to the LISTCAT the creation date of the dsn 
was Thursday Aug. 22.  I read the SMF tape for the previous week and subsequent 
days including Aug 22 & 23.
I was thinking if the dsn was created by a FTP or an UNIX upload process which 
may not be trapped by SMF
Any thoughts?  Any suggestions

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

Re: IDCAMS - MASKING

[Willie Bunter]

Thanks Steve.

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

IDCAMS - MASKING

[willie bunter]

Good Day To All,
I am trying to use masking when performing IDCAMS PRINT:
PRINT INDATASET(SYS2.NETVIEW.SKL*) MASK DUMP COUNT(2)

Error Message :IDC3203I ITEM ' SYS2.NETVIEW.SKL* DOES NOT ADHERE TO RESTRICTIONS

I am able to delete dsns using masking.  Is masking only supports DELETE?

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

Re: BATCH JOB TO RUN GRS COMMAND

[willie bunter]

 Anthony,
Thanks for the JCL and the REXX.  It works like a charm.  Much obliged.
On Monday, June 3, 2019, 2:01:51 a.m. UTC, Anthony Thompson 
 wrote:  
 
 Provided you have the appropriate authorities...

Batch job: 

//jobcard
//SDSFCMD  EXEC PGM=IKJEFT01
//SYSTSPRT DD  SYSOUT=*
//SYSPROC  DD  DISP=SHR,DSN=Your.REXX.library
//SYSTSIN  DD  *
  %SDSFCMD D GRS,RES=(*,SYS1.LINKLIB)
/*

SDSFCMD REXX: 

/*REXX*/
blah = ISFCALLS('ON')
ISFCONS  = "ANTCONXX"
ISFDELAY = "1"
PARSE ARG input
cmd.0=1
cmd.1=input
ADDRESS SDSF ISFSLASH "(cmd.)"
IF (ISFULOG.0 > 0) THEN
DO i=1 TO ISFULOG.0
  SAY ISFULOG.i
END
EXIT 0

Ant.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
willie bunter
Sent: Saturday, 1 June 2019 2:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: BATCH JOB TO RUN GRS COMMAND

Hallo All,
Would anybody have an example to run the GRS command for the following dsn  via 
a batch job :
 DGRS,RES=(*,SYS1.LINKLIB)
Thanks in advance

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

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

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

Re: BATCH JOB TO RUN GRS COMMAND

[Willie Bunter]

Thanks John.  I will check out the SDSF option.

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

Re: BATCH JOB TO RUN GRS COMMAND

[Willie Bunter]

I tried the job  but nothing was displayed.

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

BATCH JOB TO RUN GRS COMMAND

[willie bunter]

Hallo All,
Would anybody have an example to run the GRS command for the following dsn  via 
a batch job :
 DGRS,RES=(*,SYS1.LINKLIB)
Thanks in advance

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

Re: DFDSS copy to pre-allocated dsn

[willie bunter]

 Just to add my 2 cents you will need to add parm REPLACEU  if the target dsn 
exists and cataloged.
On Friday, May 17, 2019, 9:59:24 a.m. UTC, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Try added SELECTMULTI(ANY)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Rob
Sent: Thursday, May 16, 2019 7:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I don't know for sure if OUTDD works exactly like OUTDY; I was wondering.  I 
used (no longer a DSS shop) OUTDY to list candidate volumes; COPY makes only 
one copy, whether it exists on one volume or is spread across multiple ones.  
Anyway, since this is non-SMS managed, it can be on only one volume--assuming 
it's really HFS.  I guess the same restriction would apply to ZFS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 16, 2019 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

So you are making 3 copies on 3 different OUTDDNAMES?
If it is one dataset on 3 volumes it would be one OUTDDNAME, right?

On Thu, May 16, 2019 at 4:51 PM Elaine Beal  wrote:
>
> I've found a lot of " it's " confusing comments on this topic and I am 
> beleaguered- I am trying to copy a file to an existing, pre-allocated new 
> name.
> Seems that should be pretty straight forward... but having to specify 
> rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL is 
> not specified but I get this whether I specify it or not-
>
>
>  COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>      LOGINDDNAME(DASD1)  -
>      OUTDDNAME(DASD2,DASD3,DASD4)  -
>      RENAMEU((SYS7.R30.V22.ROOT.HFS,  -
>      SYS7.R30.V22.RSU.ROOT.HFS)) -
>      REPLACEUNCONDITIONAL  -
>      NULLSTORCLAS BYPASSACS(**) -
>      ALLDATA(*) ALLEXCP CANCELERROR -
>      SHARE -
>      WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

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

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

Re: Enlarging SMS SCDS and ACDS

[willie bunter]

 Just  a note.  The ACDS and SCDS should not be on the same DASD.  If I 
remember that it is an IBM recommendation.  Perhaps things have changed with 
the new releases of DFSMS.
On Sunday, November 4, 2018, 5:43:50 a.m. EST, Gadi Ben-Avi 
 wrote:  
 
 Thanks


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Sunday, November 4, 2018 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Enlarging SMS SCDS and ACDS

There are several flavors of the SETSMS command to move the current CDS's from 
current to new.

SETSMS SAVESCDS(new SCDS)
SETSMS SAVEACDS(new ACDS)
SETSMS COMMDS(new COMMDS)

Define new (larger) datasets with IDCAMS and use the SETSMS Commads to populate 
and invoke the new datasets

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Sunday, November 4, 2018 3:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Enlarging SMS SCDS and ACDS

Hi,
In the process of adding volumes to SMS Storage Groups, I ran out of space in 
the SCDS.

What is the best way to enlarge the SCDS and ACDS?

I am running z/OS v2.2 and I have DFSMSdss.

Thanks

Gadi



? ?? ?    ?? ??? ??? ??  ? ??? ?? 
??. ?? ,  ?? ???  ?, ???   ? ?? ??? 
? ?? ?? ?. ? ?  ?? ?? ?? ??  ??  
??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ?? ? 
??? ?/?? ?? ?? ??.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות 
מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי 
מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא 
באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה 
חיצונית ו/או זדונית על הארגון.

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

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

Re: How can I list the contents of a ADRDSSU DUMP dataset?

[willie bunter]

 Sorry,  I forgot to mention that this will need the RESTORE command in order 
for it to work.
On Tuesday, October 23, 2018, 12:40:05 p.m. EDT, willie bunter 
 wrote:  
 
  Jerry,
Try //STEP1   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
I have done it several times and it works.
On Friday, October 19, 2018, 3:48:19 p.m. EDT, Jerry Callen 
 wrote:  
 
 I'd like to be able to list the names of the files present in a "logical dump" 
dataset produced by ADRDSSU. AFAIK, there isn't a command to ADRDSSU to do that 
(seems like an odd omission...). 

The format of the dump dataset is thoroughly described:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/fmtdds.htm

But I really don't want to have to write the code to grovel over the dataset 
and format this stuff if someone else has already done it. :-)

I looked on the CBT Tape; no joy.

Any suggestions?

-- Jerry

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

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

Re: How can I list the contents of a ADRDSSU DUMP dataset?

[willie bunter]

 Jerry,
Try //STEP1   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
I have done it several times and it works.
On Friday, October 19, 2018, 3:48:19 p.m. EDT, Jerry Callen 
 wrote:  
 
 I'd like to be able to list the names of the files present in a "logical dump" 
dataset produced by ADRDSSU. AFAIK, there isn't a command to ADRDSSU to do that 
(seems like an odd omission...). 

The format of the dump dataset is thoroughly described:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.adru000/fmtdds.htm

But I really don't want to have to write the code to grovel over the dataset 
and format this stuff if someone else has already done it. :-)

I looked on the CBT Tape; no joy.

Any suggestions?

-- Jerry

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

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

LISTCAT OBSERVATION

[willie bunter]

Hallo To All,
Just curious.  I just noticed the following when I do a LISTCAT via ISPF 3.4
 ENCRYPTIONDATA                      DATA SET ENCRYPTION-(NO)   
Was it always there?  If not would anybody know when it began to appear?  We 
are running RELEASE z/OS 02.02.00
Thanks.

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

Re: SMS/HSM QUESTION

[willie bunter]

I verified the MC and DSORGs.  No problem found.  No patches either which would 
impede the PSM.  I remember reading or being told that once the SM conditions 
had been met, HSM stops looking at the volume(s).

  From: Graham Harris <harris...@gmail.com>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, March 2, 2018 6:05 PM
 Subject: Re: SMS/HSM QUESTION
   
Primary space management should normally process all volumes in a storage
group. And PSM should normally look to reduce utilisation of a volume down
to the low threshold (caveat - various PATCHes can alter DFHSM standard
behaviour).
Have you checked the messages for space management actions for these
datasets?
It could be that they need to be backed-up before being expired, and
auto-backup may not be running against that SG (as an example of a
condition that could potentially give rise to what you are seeing).
Or another possibility is that they cant be backed up, because, for
example, they may have a null DSORG.  If they cant be backed-up, and the
management class says they must be backed up, then DFHSM will not expire
them until they are backed up.

The above may not precisely match what you are experiencing, but it may
perhaps point you in a better direction.

On 1 March 2018 at 16:18, Willie Bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks for the info., however it doesn't answer my question as to which
> threshold I should modify.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


   

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

Re: SMS/HSM QUESTION

[Willie Bunter]

Thanks for the info., however it doesn't answer my question as to which 
threshold I should modify.

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

Re: Tape to tape copy jcl

[willie bunter]

Besides IEBGENER and DITTO there is not much out there.  However, when we did a 
conversion from physical tape to virtual tape (VTS) we used FATSCOPY, a product 
by INNOVATIONS.  It is an excellent product and very safe to use.  We didn't 
lose not even 1 tape. I highly recommend it (if you are shopping for a software)

  From: venkat kulkarni 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Wednesday, February 28, 2018 4:19 AM
 Subject: Tape to tape copy jcl
   
Hello Group,

We are in the process of migrating physical tape to virtual tape.

I am unable to find any process and JCL which can copy all my data residing
in physical tape cartridge to virtual tape using JCL .

Can you please suggest .

Regards
Venkat

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


   

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

SMS/HSM QUESTION

[willie bunter]

Good Day To All,

I am trouble shooting a problem caused by space abends.  I looked at all of the 
54 SMS managed volumes

(via ISPF 3.4) and  I found 2,930 dsns which are allocated on this specific 
Storage Group which were created in Dec.2017 and have not been referenced since 
their creation.  
According to the Management class, the dsns are to be deleted after 2 days of 
non reference.  Primary and Secondary Space management are run daily on this 
Storage Group.  Since the threshold requirements are being met, SMS does not 
process some of these volumes.  I was thinking of lowering the threshold in 
order to get SMS to select most of the volumes when Space management is run.  

My question is do I modify the Allocation/migration Threshold or the Alloc/Migr 
Threshold Track-Managed.

Below is threshold settings:  
Allocation/migration Threshold :   High85  (1-100)  
Low . . 1   (0-99)
Alloc/Migr Threshold Track-Managed:High85  (1-100)  
Low . . 1   (0-99)

Thanks in advance for your suggestions.

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

Re: Data sets incorrectly cataloged to HSM MIGRAT2

[willie bunter]

Is the HSM cds shared among LPARS?  If so, check if there is an alias for these 
dsns on the LPAR which has the problem.  I had a similar problem.  

  From: Jesse 1 Robinson 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Tuesday, February 20, 2018 4:31 PM
 Subject: Data sets incorrectly cataloged to HSM MIGRAT2
   
We have situation where a lot of data sets are incorrectly cataloged to HSM 
MIGRAT2. For an individual case, I can try HDELETE. If I get the message that 
data set is not migrated, I can issue DEL NSCR.

However we have thousands of these. We can CSI list them by data set name 
pattern. I don't really want to DEL NSCR if a data set is actually migrated. 
Any suggestions for how to handle an enormous number of these?

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


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

   

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

Re: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

Thanks John, I will try out your suggestion. 
Thanks to all who responded and help.

  From: John McKown <john.archie.mck...@gmail.com>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, September 15, 2017 9:23 AM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
On Fri, Sep 15, 2017 at 7:54 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> John,
> Quick question.  Could you tell me how I can continue on the next line.
> For example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate
>
> If the output disn has more characters I run out of space .  I  tried
> typing + as a continuation (in col 72) and then on the next lineI typed '
> (REAllocate.
> mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
>    +(REAllocate
>
>  However the command didn't work because of unbalanced parenthesis.  Do
> you have a solution?
>

​Hum, seems like it should work according to
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halu001/ftpreq.htm

mvsput 'FTP.V8050.MVS.BUILDJCJ' 'DRP.V8050.MVS.BUILDJCL.NEW' +
  (REALLOCATE

or maybe try

mvsput 'FTP.V8050.MVS.BUILDJCJ' +
      'DRP.V8050.MVS.BUILDJCL.NEW'  (REALLOCATE





> Thanks.      From: John McKown <john.archie.mck...@gmail.com>
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Thursday, September 7, 2017 2:04 PM
>  Subject: Re: FTP JCL EXAMPLE - FTP PDS
>
> On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony <aci...@seic.com> wrote:
>
> >
> >        If you are transferring a PDS from one MVS LPAR to another and
> > creating the target PDS, couldn't you use:
> >
> >        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> > (REAllocate
>
>
> ​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
> newest and greatest FTP commands. I need to go read the 2.3 books on that
> to see what other goodies exist.​
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

   

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

Re: FTP JCL EXAMPLE - FTP PDS - CORRECTION

[willie bunter]

Sorry it wasn't parenthesis but: Mismatched quotes on pathname 
'DRP.V8050.MVS.BUILDJCL.NEW'(REAllocate

  From: willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, September 15, 2017 8:54 AM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
John,
Quick question.  Could you tell me how I can continue on the next line.  For 
example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW' 
(REAllocate

If the output disn has more characters I run out of space .  I  tried typing + 
as a continuation (in col 72) and then on the next lineI typed ' (REAllocate.
mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'                
+(REAllocate

  However the command didn't work because of unbalanced parenthesis.  Do you 
have a solution?
Thanks.      From: John McKown <john.archie.mck...@gmail.com>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Thursday, September 7, 2017 2:04 PM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
  
On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony <aci...@seic.com> wrote:

>
>        If you are transferring a PDS from one MVS LPAR to another and
> creating the target PDS, couldn't you use:
>
>        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate


​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
newest and greatest FTP commands. I need to go read the 2.3 books on that
to see what other goodies exist.​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

  

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

   

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

Re: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

John,
Quick question.  Could you tell me how I can continue on the next line.  For 
example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW' 
(REAllocate

If the output disn has more characters I run out of space .  I  tried typing + 
as a continuation (in col 72) and then on the next lineI typed ' (REAllocate.
mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'                
+(REAllocate

  However the command didn't work because of unbalanced parenthesis.  Do you 
have a solution?
Thanks.  From: John McKown 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Thursday, September 7, 2017 2:04 PM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:

>
>        If you are transferring a PDS from one MVS LPAR to another and
> creating the target PDS, couldn't you use:
>
>        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate


​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
newest and greatest FTP commands. I need to go read the 2.3 books on that
to see what other goodies exist.​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

   

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

Re: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

John,

I am stuck again.  Would you have the parm when FTPing a PDS/PDSE?

I tried the following:

 QUOTE SITE PRI=50 SEC=20 CYL  
 MPUT 'FTP.V8050.MVS.BUILDJCL(*)' +  
  'DRP.V8050.MVS.BUILDJCL.NEW'   
 QUIT  


On Fri, 9/1/17, John McKown <john.archie.mck...@gmail.com> wrote:

 Subject: Re: FTP JCL EXAMPLE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 1, 2017, 11:27 AM
 
 On Fri, Sep 1, 2017 at 10:19 AM,
 willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 >      I am
 trying to FTP a dsn of 90 cylinders from one MAINFRAME Lpar
 to
 > another.  The FTP function is
 unsuccessful because of a space abend.
 >
 > Would anybody have an
 example of how to code the space parm in the FTP
 > batch job?
 >
 > I thought about pre-allocation the dsn on
 the target LPAR.  This works
 > however
 because of other dsns which will be FTP'd, the size of
 the dsns are
 > not known because the
 application batch jobs are run overnight.
 >
 > I looked at IBM
 KNOWLEDGE CENTER but I couldn't find anything that
 would
 > satisfy my  requirement.
 >
 > Here is my
 batchjob.  Please note I blanked out the IP address.
 >
 > //STEPFTP  EXEC
 PGM=FTP,REGION=4096K,TIME=5,
 > //
 PARM='1XX.1XX.XX.XXX
 > //SYSPRINT DD
 SYSOUT=*
 > //OUTPUT   DD SYSOUT=*
 > //INPUT      DD *
 >  O00070 PASSWORD
 >
 
 ​QUOTE SITE PRI=20 SEC=20
 CYL​
 
 
 
 >  PUT 'O00070.OTTCAUDR.AUDITLOG'
 +
 >      
 'O00070.OTTCAUDR.AUDITLOG'
 > 
 QUIT
 > /*
 > //
 >
 > Thanks.
 >
 
 ​The
 QUOTE SITE above is equivalent to SPACE=(CYL,(20,20))​. Of
 course,
 this is a "hard coded"
 value which may be too large for some DSNs and not
 large enough for others. If you need something
 which "dynamically adjusts"
 the
 values, then you'll need to do more work. FTP itself
 cannot do this for
 you.
 
 
 -- 
 Caution!
 The OP is an hyperpolysyllabicsesquipedalianist and this
 email may
 cause stress to those with
 hippopotomonstrosesquipedaliophobia.
 
 Maranatha! <><
 John
 McKown
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: FTP JCL EXAMPLE

[willie bunter]

John,

Thanks for your help. It worked.  Thanks to all who helped me out.

Charlesl,

I will try take a look at the site you suggested. 

On Fri, 9/1/17, John McKown <john.archie.mck...@gmail.com> wrote:

 Subject: Re: FTP JCL EXAMPLE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 1, 2017, 11:27 AM
 
 On Fri, Sep 1, 2017 at 10:19 AM,
 willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 >      I am
 trying to FTP a dsn of 90 cylinders from one MAINFRAME Lpar
 to
 > another.  The FTP function is
 unsuccessful because of a space abend.
 >
 > Would anybody have an
 example of how to code the space parm in the FTP
 > batch job?
 >
 > I thought about pre-allocation the dsn on
 the target LPAR.  This works
 > however
 because of other dsns which will be FTP'd, the size of
 the dsns are
 > not known because the
 application batch jobs are run overnight.
 >
 > I looked at IBM
 KNOWLEDGE CENTER but I couldn't find anything that
 would
 > satisfy my  requirement.
 >
 > Here is my
 batchjob.  Please note I blanked out the IP address.
 >
 > //STEPFTP  EXEC
 PGM=FTP,REGION=4096K,TIME=5,
 > //
 PARM='1XX.1XX.XX.XXX
 > //SYSPRINT DD
 SYSOUT=*
 > //OUTPUT   DD SYSOUT=*
 > //INPUT      DD *
 >  O00070 PASSWORD
 >
 
 ​QUOTE SITE PRI=20 SEC=20
 CYL​
 
 
 
 >  PUT 'O00070.OTTCAUDR.AUDITLOG'
 +
 >      
 'O00070.OTTCAUDR.AUDITLOG'
 > 
 QUIT
 > /*
 > //
 >
 > Thanks.
 >
 
 ​The
 QUOTE SITE above is equivalent to SPACE=(CYL,(20,20))​. Of
 course,
 this is a "hard coded"
 value which may be too large for some DSNs and not
 large enough for others. If you need something
 which "dynamically adjusts"
 the
 values, then you'll need to do more work. FTP itself
 cannot do this for
 you.
 
 
 -- 
 Caution!
 The OP is an hyperpolysyllabicsesquipedalianist and this
 email may
 cause stress to those with
 hippopotomonstrosesquipedaliophobia.
 
 Maranatha! <><
 John
 McKown
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

FTP JCL EXAMPLE

[willie bunter]

Good Day To All,

 I am trying to FTP a dsn of 90 cylinders from one MAINFRAME Lpar to 
another.  The FTP function is unsuccessful because of a space abend.

Would anybody have an example of how to code the space parm in the FTP batch 
job? 

I thought about pre-allocation the dsn on the target LPAR.  This works however 
because of other dsns which will be FTP'd, the size of the dsns are not known 
because the application batch jobs are run overnight.

I looked at IBM KNOWLEDGE CENTER but I couldn't find anything that would 
satisfy my  requirement. 

Here is my batchjob.  Please note I blanked out the IP address.

//STEPFTP  EXEC PGM=FTP,REGION=4096K,TIME=5,  
// PARM='1XX.1XX.XX.XXX   
//SYSPRINT DD SYSOUT=*
//OUTPUT   DD SYSOUT=*
//INPUT  DD * 
 O00070 PASSWORD  
 PUT 'O00070.OTTCAUDR.AUDITLOG' + 
  'O00070.OTTCAUDR.AUDITLOG'  
 QUIT 
/*
//

Thanks.

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

Re: DFHSM QUESTION - PROBLEM SOLVED.

[willie bunter]

Just to let you all know I finally was able to delete the records.  I was 
barking up the wrong tree.  I was concentrating on the 'B" instead of the "C" 
records.

I dd a FIXCDS C HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 DELETE
That did the trick.

Thanks to all who responded and helped out with their suggestions.


On Fri, 7/28/17, willie bunter <williebun...@yahoo.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU>
 Received: Friday, July 28, 2017, 12:33 PM
 
 Lizette,
 
 I have taken note of your suggestion
 and I will adhere to it.
 I checked my command and it shows that
 all the contents of the command is as follows as suggested
 by Brian:   HSEND AUDIT DSCTL(BACKUP) FIX.
 
 I didn't have BDELETE or anyother parm
 in the command.  I am not sure why HSM is complaining
 that the command contained these parms.
 
 
 On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com>
 wrote:
 
  Subject: Re: DFHSM QUESTION
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Friday, July 28, 2017, 10:01
 AM
  
  Willie
  
  It would be helpful to include just
 on
  pair of COMMAND and RESPONSE rather
 than all of your error
  messages.  Without the context of
 what command syntax
  you entered, it is difficult to assist
 you.
  
  Next.
  
  For this message:
  
  ARC0085I (H)BDELETE REQUIRES ONE OF
 THE
  FOLLOWING MUTUALLY EXCLUSIVE
 KEYWORDS:
  ARC0085I (CONT.) ALL, VERSIONS, OR
  DATE               
                 
         
  
  It appears that when you entered the
  BDELETE command you did not include
 the subparm of ALL
  VERSIONS or DATE 
  
  Please review this process and ensure
  you are entering the command according
 to the DFHSM Admin
  Guide
  
  Lizette
  
  
  > -Original Message-
  > From: IBM Mainframe Discussion
  List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
  On
  > Behalf Of willie bunter
  > Sent: Friday, July 28, 2017 6:33
  AM
  > To: IBM-MAIN@LISTSERV.UA.EDU
  > Subject: Re: DFHSM QUESTION
  > 
  > Brian,
  > 
  > I tried your suggestion
  unfortunately it didn't get rid of the
 ERR 40.  Here
  > is the message that was sent to
 my
  terminal:
  > 
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > ARC0085I (H)BDELETE REQUIRES ONE
  OF THE FOLLOWING MUTUALLY EXCLUSIVE
  > KEYWORDS:
  > ARC0085I (CONT.) ALL, VERSIONS,
 OR
  DATE
  > 
  > Below is a sample of the output.
  > /* ERR 40 DB2.ARCHLOG2.A0091613
 
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
  > MISSING
  > /* FIXCDS B DUMMY.RECOVER.MCB
  CREATE(X'0014' X'0098257F')
  > /* FIXCDS B DUMMY.RECOVER.MCB
  PATCH(X'002E' BITS(1.1.))
  > /* FIXCDS B DUMMY.RECOVER.MCB
  PATCH(X'0030' X'000100010001')
  > /* FIXCDS B DUMMY.RECOVER.MCB
  EXPAND(X'0040')
  > /* FIXCDS B DUMMY.RECOVER.MCB
  PATCH(X'0050' +
  > /*
  >
 
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
  > 0404040404040')
  > /* FIXCDS B DUMMY.RECOVER.MCB
  PATCH(X'0050'
  >
 
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
  > /* FIXCDS B DUMMY.RECOVER.MCB
  PATCH(X'0082' BITS(0110))
  > /* BDELETE DUMMY.RECOVER.MCB
  > /* MSG 914 - ERROR ON BDELETE
  COMMAND
  > /* MSG 998 - AUDIT CONTINUING,
 SEE
  COMMAND ACTIVITY LOG
  > /* FIXCDS B DUMMY.RECOVER.MCB
  DELETE
  > - END OF -     ENHANCED
  AUDIT - LISTING -
  > 
  >
 
 
  > On Thu, 7/27/17, Brian Fraser
  <brianmfra...@gmail.com>
  wrote:
  > 
  >  Subject: Re: DFHSM QUESTION
  >  To: IBM-MAIN@LISTSERV.UA.EDU
  >  Received: Thursday, July 27,
  2017, 9:18 PM
  > 
  >  HSEND AUDIT DSCTL

Re: DFHSM QUESTION

[willie bunter]

Lizette,

I have taken note of your suggestion and I will adhere to it.
I checked my command and it shows that all the contents of the command is as 
follows as suggested by Brian:   HSEND AUDIT DSCTL(BACKUP) FIX.

I didn't have BDELETE or anyother parm in the command.  I am not sure why HSM 
is complaining that the command contained these parms.


On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, July 28, 2017, 10:01 AM
 
 Willie
 
 It would be helpful to include just on
 pair of COMMAND and RESPONSE rather than all of your error
 messages.  Without the context of what command syntax
 you entered, it is difficult to assist you.
 
 Next.
 
 For this message:
 
 ARC0085I (H)BDELETE REQUIRES ONE OF THE
 FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
 ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE               
                
        
 
 It appears that when you entered the
 BDELETE command you did not include the subparm of ALL
 VERSIONS or DATE 
 
 Please review this process and ensure
 you are entering the command according to the DFHSM Admin
 Guide
 
 Lizette
 
 
 > -Original Message-
 > From: IBM Mainframe Discussion
 List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Friday, July 28, 2017 6:33
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION
 > 
 > Brian,
 > 
 > I tried your suggestion
 unfortunately it didn't get rid of the ERR 40.  Here
 > is the message that was sent to my
 terminal:
 > 
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > ARC0085I (H)BDELETE REQUIRES ONE
 OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR
 DATE
 > 
 > Below is a sample of the output.
 > /* ERR 40 DB2.ARCHLOG2.A0091613
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 > MISSING
 > /* FIXCDS B DUMMY.RECOVER.MCB
 CREATE(X'0014' X'0098257F')
 > /* FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'002E' BITS(1.1.))
 > /* FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0030' X'000100010001')
 > /* FIXCDS B DUMMY.RECOVER.MCB
 EXPAND(X'0040')
 > /* FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050' +
 > /*
 >
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
 > 0404040404040')
 > /* FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050'
 >
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
 > /* FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0082' BITS(0110))
 > /* BDELETE DUMMY.RECOVER.MCB
 > /* MSG 914 - ERROR ON BDELETE
 COMMAND
 > /* MSG 998 - AUDIT CONTINUING, SEE
 COMMAND ACTIVITY LOG
 > /* FIXCDS B DUMMY.RECOVER.MCB
 DELETE
 > - END OF -     ENHANCED
 AUDIT - LISTING -
 > 
 >
 
 > On Thu, 7/27/17, Brian Fraser
 <brianmfra...@gmail.com>
 wrote:
 > 
 >  Subject: Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Thursday, July 27,
 2017, 9:18 PM
 > 
 >  HSEND AUDIT DSCTL(BACKUP)
 FIX
 > 
 ODS('dsn.for.output.listing')
 >  is
 >  what you should run.
 > 
 > 
 >  On Fri, Jul 28, 2017 at 2:56
 AM, Horne, Patti  <patti.ho...@fisglobal.com>
 >  wrote:
 > 
 >  >
 >  You ran the fix on the
 BDELETE not the AUDIT.
 >  >
 >  >
 >  >
 
 --
 For IBM-MAIN subscribe / signoff /
 archive access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION

[willie bunter]

Brian,

I tried your suggestion unfortunately it didn't get rid of the ERR 40.  Here is 
the message that was sent to my terminal:

ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE

Below is a sample of the output.
/* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING 
/* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')   
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) 
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
/* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')   
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +   
/* 
X'4040404040404040404040404040404040404040404040404040404040404040404040404040404040404040')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' 
HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) 
/* BDELETE DUMMY.RECOVER.MCB
/* MSG 914 - ERROR ON BDELETE COMMAND   
/* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG 
/* FIXCDS B DUMMY.RECOVER.MCB DELETE
- END OF - ENHANCED AUDIT - LISTING -   


On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 9:18 PM
 
 HSEND AUDIT DSCTL(BACKUP) FIX
 ODS('dsn.for.output.listing')
 is
 what you should run.
 
 
 On Fri, Jul 28, 2017 at 2:56 AM, Horne, Patti
 <patti.ho...@fisglobal.com>
 wrote:
 
 >
 You ran the fix on the BDELETE not the AUDIT.
 >
 >
 >
 >
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Thursday, July 27, 2017 11:23 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION
 >
 > I ran the FIX and the
 following messages were received :
 >
 > ARC0085I (H)BDELETE REQUIRES ONE OF THE
 FOLLOWING MUTUALLY EXCLUSIVE
 >
 KEYWORDS:
 > ARC0085I (CONT.) ALL,
 VERSIONS, OR DATE
 > ARC0085I (H)BDELETE
 REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I
 (CONT.) ALL, VERSIONS, OR DATE
 > ARC0085I
 (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY
 EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR DATE
 > ARC0085I (H)BDELETE REQUIRES ONE OF THE
 FOLLOWING MUTUALLY EXCLUSIVE
 >
 KEYWORDS:
 > ARC0085I (CONT.) ALL,
 VERSIONS, OR DATE
 > ARC0085I (H)BDELETE
 REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I
 (CONT.) ALL, VERSIONS, OR DATE
 > ARC0085I
 (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY
 EXCLUSIVE
 > KEYWORDS:
 > ARC0085I (CONT.) ALL, VERSIONS, OR DATE
 > ARC0085I (H)BDELETE REQUIRES ONE OF THE
 FOLLOWING MUTUALLY EXCLUSIVE
 >
 KEYWORDS:
 > ARC0085I (CONT.) ALL,
 VERSIONS, OR DATE
 > ARC0085I (H)BDELETE
 REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
 > KEYWORDS:
 > ARC0085I
 (CONT.) ALL, VERSIONS, OR DATE
 >
 > Below is my command
 > 
   HSEND AUDIT DATASETCONTROLS(BACKUP) FIX -
 >         
 ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2)
 >
 
 > On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com>
 wrote:
 >
 >  Subject:
 Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSER

Re: DFHSM QUESTION

[willie bunter]

Brian,

I did that but it didn't clear the ERR 40 records (see below for an example of 
the message).  Thanks for the suggestion however.

/* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING 
/* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')   
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) 
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
/* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')   
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +   
/* X'404040404040404040404040404040404040404040404040404040404040404040404040404
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) 
/* BDELETE DUMMY.RECOVER.MCB
/* MSG 914 - ERROR ON BDELETE COMMAND   
/* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG 
/* FIXCDS B DUMMY.RECOVER.MCB DELETE
- END OF - ENHANCED AUDIT - LISTING -   


On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 10:31 PM
 
 If you run the audit command with
 the FIX parameter, then it should delete
 any
 orphaned C records without a matching B record.
 
 Brian
 
 On Fri, Jul 28, 2017 at 12:11 AM, willie bunter
 <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Should I ignore
 the ERR 40 when I run the AUDIT report?
 >
 >
 
 > On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com>
 wrote:
 >
 >  Subject:
 Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Thursday, July 27, 2017, 12:06
 PM
 >
 >  So is
 everything is correct
 >  now?
 >
 >  Or do you have
 more
 >  questions.
 >
 >  Otherwise I
 >  think your issues are resolved.
 >
 >  Lizette
 >
 >
 >  >
 > 
 -Original Message-
 >  > From:
 IBM
 >  Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  On
 >  > Behalf Of
 willie bunter
 >  > Sent: Thursday,
 July 27, 2017 8:58 AM
 >  > To: IBM-MAIN@LISTSERV.UA.EDU
 >  > Subject: Re: DFHSM QUESTION
 >  >
 >  > I tried
 out the
 >  BDELETE and as expected the
 record was not found.
 >  >
 >  > ARC0195I TYPE B, KEY
 >  DB2.ARCHLOG2.A0091613, FIXCDS DELETE,
 ERROR=RECORD NOT
 >  > ARC0195I
 (CONT.) FOUND
 >  > ARC1001I FIXCDS B
 DB2.ARCHLOG2.A0091613
 >  DELETE COMMAND
 FAILED, RC=0015,
 >  >
 >  ARC1001I (CONT.) REAS=
 >  > ARC1615I
 > 
 FIXCDS COMMAND REJECTED
 >  >
 >  > Below is the HLIST:
 >  >
 >  ARC0138I NO
 BCDS INFORMATION FOUND FOR DATASET
 > 
 DB2.ARCHLOG2.A0091613
 >  >
 > 
 
 >  > On Thu, 7/27/17, Lizette Koehler
 <stars...@mindspring.com>
 >  wrote:
 >  >
 >  >  Subject:
 > 
 Re: DFHSM QUESTION
 >  >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  >  Received: Thursday, July 27,
 2017, 10:52
 >  AM
 > 
 >
 >  >  At this
 >  point, just take one step
 >  >  back.
 > 
 >
 >  >  You wanted to
 >  delete
 >  >  a
 backup version from HSM.
 >  >
 >  >  The dataset is
 >  either DB2.ARCHLOG2.A0091613  or
 >  DB96.ARCHLOG2.B778
 >  >
 >  >  Issue
 an HLIST
 >  >
 > 
 DSN('DB96.ARCHLOG2.B778') BCDS    or 
 HLIST
 > 
 DSN('DB2.ARCHLOG2.A0091613
 >  >
 ')
 >  BCDS
 > 
 >
 >  >
 > 
 >  If you do not
 >  >  see
 >  any backup datasets listed for these
 datasets, then you
 >  have deleted
 >  > the backup copies.
 >  >
 >  >  If
 you still see
 >  BCDS entries, then you
 may  need to do more BDELETE
 >  >
 commands.
 >  >
 > 
 >  AUDIT is used to verify content in
 >  HSM.  However, it may create
 confusion
 >  >
 > 
 with its results.
 >  >
 >  >  I rarely use AUDIT.  If the
 >  >  BDELETE works or there are no
 longer any
 >  BCDS entries, I  will not
 issue
 >  > AUDIT
 >  commands.
 >  >
 >  >
 >  >  If
 you could provide the
 >  > 
 description of the problem you are
 > 
 trying to solve with  BDELETE and AUDIT,
 >  > that will be helpful.
 >  >
 >
 >  >  From what you have posted so
 far,
 >  the BDELETE  looks like it was
 successful
 >  > at some point.
 >  >
 >  >
 >  >  For furth

Re: DFHSM QUESTION

[willie bunter]

Should I ignore the ERR 40 when I run the AUDIT report?  


On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 12:06 PM
 
 So is everything is correct
 now?
 
 Or do you have more
 questions.
 
 Otherwise I
 think your issues are resolved.
 
 Lizette
 
 
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Thursday, July 27, 2017 8:58 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION
 > 
 > I tried out the
 BDELETE and as expected the record was not found.
 > 
 > ARC0195I TYPE B, KEY
 DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
 > ARC0195I (CONT.) FOUND
 > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613
 DELETE COMMAND FAILED, RC=0015,
 >
 ARC1001I (CONT.) REAS=
 > ARC1615I
 FIXCDS COMMAND REJECTED
 > 
 > Below is the HLIST:
 >
 ARC0138I NO BCDS INFORMATION FOUND FOR DATASET
 DB2.ARCHLOG2.A0091613
 >
 
 > On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com>
 wrote:
 > 
 >  Subject:
 Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Thursday, July 27, 2017, 10:52
 AM
 > 
 >  At this
 point, just take one step
 >  back.
 > 
 >  You wanted to
 delete
 >  a backup version from HSM.
 > 
 >  The dataset is
 either DB2.ARCHLOG2.A0091613  or 
 DB96.ARCHLOG2.B778
 > 
 >  Issue an HLIST
 > 
 DSN('DB96.ARCHLOG2.B778') BCDS    or  HLIST
 DSN('DB2.ARCHLOG2.A0091613
 > ')
 BCDS
 > 
 > 
 >  If you do not
 >  see
 any backup datasets listed for these datasets, then you 
 have deleted
 > the backup copies.
 > 
 >  If you still see
 BCDS entries, then you may  need to do more BDELETE
 > commands.
 > 
 >  AUDIT is used to verify content in
 HSM.  However, it may create confusion
 >
 with its results.
 > 
 >  I rarely use AUDIT.  If the
 >  BDELETE works or there are no longer any
 BCDS entries, I  will not issue
 > AUDIT
 commands.
 > 
 > 
 >  If you could provide the
 >  description of the problem you are
 trying to solve with  BDELETE and AUDIT,
 > that will be helpful.
 >
 
 >  From what you have posted so far,
 the BDELETE  looks like it was successful
 > at some point.
 > 
 > 
 >  For further
 >  analysis, issue the command       
    BACKDS  'DB2.ARCHLOG2.A0091613'
 > 
 >  Then do the
 HLIST
 > 
 DSN('DB2.ARCHLOG2.A0091613') BCDS   and see if
 you  get an entry
 > 
 > 
 >  Next do the
 BDELETE command for
 > 
 DB2.ARCHLOG2.A0091613
 > 
 > 
 >  Repeat the HLIST
 command.
 > 
 > 
 >  If there are
 >  no
 entries in the BCDS for this dataset, that should show  the
 process in
 > HSM is working.
 > 
 > 
 >  Lizette
 > 
 > 
 >  >
 -Original
 >  Message-
 >  > From: IBM Mainframe
 >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > Behalf Of willie
 > bunter 
 >
 >  Sent: Thursday, July 27, 2017
 6:53 AM
 >  >
 > 
 To: IBM-MAIN@LISTSERV.UA.EDU
 >  > Subject: Re: DFHSM QUESTION
 >  >
 >  > Here
 are the
 >  commands I tried :
 >  >  HSEND FIXCDS B
 >  DB96.ARCHLOG2.B778 (message
 received) :
 >  >
 >  > ARC0195I TYPE B, KEY
 >  DB96.ARCHLOG2.B778, FIXCDS DISPLAY,
 ERROR=RECORD NOT  > ARC0195I (CONT.)
 > FOUND  > ARC1001I FIXCDS B
 DB96.ARCHLOG2.B778  COMMAND FAILED, RC=0015,
 > REAS=  >  ARC1615I FIXCDS COMMAND
 REJECTED  >  > HSEND  BDELETE
 >
 'DB2.ARCHLOG2.A0091613' ALL No error message 
 received.
 >  >
 > 
 > I
 >  looked at the ERR 40  in the
 doc.  It describes my problem  however it is  >
 > not clear what I should  do.  In this
 case the B record does not exist or  >
 > missing.
 >  > for
 example
 >  it says "If the backup
 version (C) record references a  data set  > (B)
 > record that does not  exist, then a new
 (B) record is created and the  >
 >
 version added".  Not  usre ...then  a new(B) record
 is created and the
 > version  >
 added.
 >  >
 > 
 > I do not understand this.  Any
 > 
 suggestions?
 >  >
 > 
 
 >  > On Wed, 7/26/17, retired mainframer
 <retired-mainfra...@q.com>
 >  wrote:
 >  >
 >  >  Subject:
 > 
 Re: DFHSM QUESTION
 >  >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  >  Received: Wednesday, July 26,
 2017, 1:30  PM  >  >  Please show  the
 > complete AUDIT  >  and BDELETE 
 commands you are using.
 >  >
 >  >  Did you look up ERR40 in the
 "Error
 >  Codes  and
 D

Re: DFHSM QUESTION

[willie bunter]

I understand that the record doesn't exist.  However my question is how do I 
perform the clean up of the ERR 40 records?

On Thu, 7/27/17, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 10:38 AM
 
 I think it's time to list the
 contents of the BCDS, I don't have HSM so I can't
 provide the correct command, 
 
 
 HSEND LIST LEVEL(DB96) BCDS or
 (BACKUPCONTROLDATASET) OUTDATASET(xxx.yyy.xxx) ?? 
 
 but I tent to agree with
 Lizette, the record in the BCDS does not exist 
 
 
     *
 RECORD NOT FOUND—The indicated record was not found; you
 could not delete or update it. 
 
 
 Carmen - Original Message
 -
 
 From: "willie
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Thursday, July 27, 2017 8:52:37 AM
 
 Subject: Re: DFHSM QUESTION 
 
 Here are the commands I tried
 : 
 HSEND FIXCDS B DB96.ARCHLOG2.B778
 (message received) : 
 
 ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778,
 FIXCDS DISPLAY, ERROR=RECORD NOT 
 ARC0195I
 (CONT.) FOUND 
 ARC1001I FIXCDS B
 DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS=
 
 ARC1615I FIXCDS COMMAND REJECTED 
 
 HSEND BDELETE
 'DB2.ARCHLOG2.A0091613' ALL 
 No
 error message received. 
 
 I
 looked at the ERR 40 in the doc. It describes my problem
 however it is not clear what I should do. In this case the B
 record does not exist or missing. 
 for
 example it says "If the backup version (C) record
 references a data set (B) record that does not exist, then a
 new (B) record is created and the version added". Not
 usre ...then a new(B) record is created and the version
 added. 
 
 I do not understand
 this. Any suggestions? 
 
 
 On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com>
 wrote: 
 
 Subject: Re: DFHSM
 QUESTION 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Received: Wednesday, July 26, 2017, 1:30 PM
 
 
 Please show the complete
 AUDIT 
 and BDELETE commands you are using.
 
 
 Did you look up ERR40 in
 the "Error Codes 
 and Diagnosis"
 section (section 3 in my copy) of the 
 "Using the AUDIT Command" chapter (my
 chapter 
 67)? The table (51) identifies
 several possible causes and 
 corrective
 actions. BDELETE is the proper action for only 
 one of the causes. 
 
 > 
 -Original
 Message- 
 > From: IBM 
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 
 On 
 > Behalf Of willie
 bunter 
 > Sent: Wednesday, July 26, 2017
 7:27 AM 
 > To: IBM-MAIN@LISTSERV.UA.EDU
 
 > Subject: DFHSM QUESTION 
 > 
 > Good Day, 
 > 
 > I ran an AUDIT of
 
 the BCDS. I was 99% successfull of
 performing a clean up 
 execept for 
 > the following type dsns: 
 > ERR 40 DB2.ARCHLOG2.A0091613 
 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 
 MISSING 
 > FIXCDS B
 DUMMY.RECOVER.MCB 
 CREATE(X'0014' X'0098257F')
 
 > FIXCDS B DUMMY.RECOVER.MCB 
 PATCH(X'002E' BITS(1.1.)) 
 > FIXCDS B DUMMY.RECOVER.MCB 
 PATCH(X'0030'
 X'000100010001') 
 > FIXCDS B
 DUMMY.RECOVER.MCB 
 EXPAND(X'0040') 
 > FIXCDS B 
 DUMMY.RECOVER.MCB PATCH(X'0050' +
 
 > 
 > 
 X'404040404040404040404040404040404040404040404040404040404040404040404040
 
 > 404 
 > FIXCDS B 
 DUMMY.RECOVER.MCB PATCH(X'0050' 
 > HSMBACK.BACK.T592617.DB2.ARCHLOG 
 > FIXCDS B DUMMY.RECOVER.MCB 
 PATCH(X'0082' BITS(0110)) 
 > BDELETE DUMMY.RECOVER.MCB 
 > FIXCDS B DUMMY.RECOVER.MCB DELETE 
 > END OF - ENHANCED AUDIT - LISTING 
 - 
 > 
 > I
 tried a HSEND 
 BDELETE
 'DB2.ARCHLOG2.A0091613' ALL . The command 
 which I 
 > ran in batch was
 successful 
 however when I ran another AUDIT
 the entry appears. I 
 tried a 
 > HSEND FIXCDS B 
 DB2.ARCHLOG2.A0091613. Again the command was
 
 successful, 
 > however
 the AUDIT says 
 otherwise. 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 
 access instructions, 
 send
 email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION

[willie bunter]

I ran the FIX and the following messages were received :

ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE   
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE 

Below is my command
   HSEND AUDIT DATASETCONTROLS(BACKUP) FIX -   
 ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2)  

On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 11:42 AM
 
 Try using FIX on your audit to
 see if it cleans up the error.
 
 
 
 -Original
 Message-
 From: IBM Mainframe Discussion
 List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Thursday,
 July 27, 2017 10:36 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: DFHSM QUESTION
 
 Lizette,
 
    
  The reason why I think that it is a problem because after I
 run the AUDIT using NOFIX the output shows the dsn (*err
 40).  I do not see this for other LPARS.
 My
 understanding is that if any errors appear a clean up is
 needed to be initiated.  In this case only ERR 40
 appears.
 
 
 On Thu, 7/27/17, Lizette
 Koehler <stars...@mindspring.com>
 wrote:
 
  Subject: Re: DFHSM
 QUESTION
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Thursday, July 27, 2017, 10:22 AM
 
  That does not seem to be a
  failure.
 
  It
 just states the
  record you tried to delete
 no longer exists in HSM.  Once  the record is deleted, it
 cannot be deleted again.
 
 
 Why do you think this is a
  failure?
 
  The message
 
 ARC0195I is all you need to focus on.  The ARC1001 or 
 ARC1615I just states the command could not do any work.
 
 
 
 
  Lizette
 
 
  >
 
 -Original Message-
  > From:
 IBM
  Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > Behalf Of willie bunter  > Sent: Thursday,
 July 27, 2017 6:32 AM  > To: IBM-MAIN@LISTSERV.UA.EDU 
 > Subject: Re: DFHSM QUESTION  >  > Brian, 
 >  > I tried that out  however it didn't work
 (record not found).  Below is  the  > output:
  >
  > ARC0195I TYPE B,
 KEY
  DB2.ARCHLOG2.A0091613, FIXCDS DELETE,
 ERROR=RECORD NOT  > ARC0195I (CONT.) FOUND  >
 ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613  DELETE COMMAND
 FAILED, RC=0015,  >  ARC1001I (CONT.) REAS=  >
 ARC1615I  FIXCDS COMMAND REJECTED  >
 
 
  > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com>
  wrote:
  >
 
 >  Subject:
  Re: DFHSM QUESTION
  >  To: IBM-MAIN@LISTSERV.UA.EDU
  >  Received: Wednesday, July 26, 2017,
 9:23  PM  >  >  If you just  want to get rid of 
 >  the backup, then  you can do the following.
  >
  >  HSEND FIXCDS B
  >
  DB2.ARCHLOG2.A0091613
 *DELETE*
  >
  > 
 Regards
  >  Brian
 
 >
  >  On Thu, Jul 27,
  2017 at 1:30
  >  AM,
 retired mainframer
  <
 
 >  retired-mainfra...@q.com>
  >  wrote:
  >
  >  > Please show the
 
 >  complete AUDIT and BDELETE commands you  are
 using.
  >  >
  > 
 > Did you look up ERR40
  >  in the
 "Error Codes and
  Diagnosis"
 section  (section  > 3 in my copy) of  the  >
 "Using the AUDIT Command"
  chapter
 (my chapter  67)?
  >  > The
  table (51) identifies several
 
 >
  possible causes and corrective
 actions.
  >  >
 
 >  BDELETE is
  the proper action for
 only one of the causes.
  >  >
  >  > >
 
 -Original
  >  Message-
  >  > > From: IBM Mainframe
  >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > > Behalf Of willie  >  bunter  > >
 Sent: Wednesday, July 26, 2017 7:27  AM  > > To:
 IBM-  > m...@listserv.ua.edu 
 > > 

Re: DFHSM QUESTION

[willie bunter]

I tried out the BDELETE and as expected the record was not found.

ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT 
ARC0195I (CONT.) FOUND  
ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, 
ARC1001I (CONT.) REAS=  
ARC1615I FIXCDS COMMAND REJECTED   

Below is the HLIST:
ARC0138I NO BCDS INFORMATION FOUND FOR DATASET DB2.ARCHLOG2.A0091613
 

On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 10:52 AM
 
 At this point, just take one step
 back.
 
 You wanted to delete
 a backup version from HSM.
 
 The dataset is either DB2.ARCHLOG2.A0091613 
 or  DB96.ARCHLOG2.B778
 
 Issue an HLIST
 DSN('DB96.ARCHLOG2.B778') BCDS    or    
 HLIST DSN('DB2.ARCHLOG2.A0091613 ') BCDS
 
 
 If you do not
 see any backup datasets listed for these datasets, then you
 have deleted the backup copies.
 
 If you still see BCDS entries, then you may
 need to do more BDELETE commands.
 
 AUDIT is used to verify content in HSM. 
 However, it may create confusion with its results.
 
 I rarely use AUDIT.  If the
 BDELETE works or there are no longer any BCDS entries, I
 will not issue AUDIT commands.
 
 
 If you could provide the
 description of the problem you are trying to solve with
 BDELETE and AUDIT, that will be helpful.
 
 From what you have posted so far, the BDELETE
 looks like it was successful at some point.
 
 
 For further
 analysis, issue the command           BACKDS
 'DB2.ARCHLOG2.A0091613'     
 
 Then do the HLIST
 DSN('DB2.ARCHLOG2.A0091613') BCDS   and see if you
 get an entry
 
 
 Next do the BDELETE command for
 DB2.ARCHLOG2.A0091613  
 
 
 Repeat the HLIST command.
 
 
 If there are
 no entries in the BCDS for this dataset, that should show
 the process in HSM is working.
 
 
 Lizette
 
   
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 >
 Sent: Thursday, July 27, 2017 6:53 AM
 >
 To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION
 > 
 > Here are the
 commands I tried :
 >  HSEND FIXCDS B
 DB96.ARCHLOG2.B778 (message received) :
 > 
 > ARC0195I TYPE B, KEY
 DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT
 > ARC0195I (CONT.) FOUND
 > ARC1001I FIXCDS B DB96.ARCHLOG2.B778
 COMMAND FAILED, RC=0015, REAS=
 >
 ARC1615I FIXCDS COMMAND REJECTED
 > 
 > HSEND  BDELETE
 'DB2.ARCHLOG2.A0091613' ALL No error message
 received.
 > 
 > I
 looked at the ERR 40  in the doc.  It describes my problem
 however it is
 > not clear what I should
 do.  In this case the B record does not exist or
 > missing.
 > for example
 it says "If the backup version (C) record references a
 data set
 > (B) record that does not
 exist, then a new (B) record is created and the
 > version added".  Not  usre ...then
 a new(B) record is created and the version
 > added.
 > 
 > I do not understand this.  Any
 suggestions?
 >
 
 > On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com>
 wrote:
 > 
 >  Subject:
 Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Wednesday, July 26, 2017, 1:30
 PM
 > 
 >  Please show
 the complete AUDIT
 >  and BDELETE
 commands you are using.
 > 
 >  Did you look up ERR40 in the "Error
 Codes  and Diagnosis" section (section 3
 > in my copy) of the  "Using the AUDIT
 Command" chapter (my chapter  67)?  The
 > table (51) identifies several possible
 causes and  corrective
 > actions. 
 BDELETE is the proper action for only  one of the
 causes.
 > 
 >  >
 >  -Original Message-
 >  > From: IBM
 > 
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > Behalf Of
 > willie bunter 
 > Sent: Wednesday, July 26, 2017 7:27 AM  > To:
 IBM-
 > m...@listserv.ua.edu 
 > Subject: DFHSM QUESTION  >  > Good Day, 
 >  > I ran
 > an AUDIT of  the
 BCDS.  I was 99% successfull of performing a clean up
 > execept for  > the following type
 dsns:
 >  >  ERR 40
 DB2.ARCHLOG2.A0091613
 >  >
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 >  MISSING
 >  > 
 FIXCDS B DUMMY.RECOVER.MCB
 > 
 CREATE(X'0014' X'0098257F')
 >  >  FIXCDS B DUMMY.RECOVER.MCB
 >  PATCH(X'002E'
 BITS(1.1.))
 >  >  FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 PATCH(X'0030' X'000100010001')
 >  >  FIXCDS B DUMMY.RECOVER.MCB
 >  EXPAND(X'0040')
 >  >  FIXCDS B
 > 
 DUMMY.RECOVER.MCB PATCH(X'0050' +
 >  >
 >  >
 > 
 X'4040

Re: DFHSM QUESTION

[willie bunter]

Lizette,

 The reason why I think that it is a problem because after I run the AUDIT 
using NOFIX the output shows the dsn (*err 40).  I do not see this for other 
LPARS.
My understanding is that if any errors appear a clean up is needed to be 
initiated.  In this case only ERR 40 appears.


On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, July 27, 2017, 10:22 AM
 
 That does not seem to be a
 failure.
 
 It just states the
 record you tried to delete no longer exists in HSM.  Once
 the record is deleted, it cannot be deleted again.
 
 Why do you think this is a
 failure?
 
 The message
 ARC0195I is all you need to focus on.  The ARC1001 or
 ARC1615I just states the command could not do any work. 
 
 
 
 
 Lizette
 
 
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Thursday, July 27, 2017 6:32 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION
 > 
 > Brian,
 > 
 > I tried that out
 however it didn't work (record not found).  Below is
 the
 > output:
 > 
 > ARC0195I TYPE B, KEY
 DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
 > ARC0195I (CONT.) FOUND
 > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613
 DELETE COMMAND FAILED, RC=0015,
 >
 ARC1001I (CONT.) REAS=
 > ARC1615I
 FIXCDS COMMAND REJECTED
 >
 
 > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com>
 wrote:
 > 
 >  Subject:
 Re: DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Wednesday, July 26, 2017, 9:23
 PM
 > 
 >  If you just
 want to get rid of
 >  the backup, then
 you can do the following.
 > 
 >  HSEND FIXCDS B
 > 
 DB2.ARCHLOG2.A0091613 *DELETE*
 > 
 >  Regards
 >  Brian
 > 
 >  On Thu, Jul 27,
 2017 at 1:30
 >  AM, retired mainframer
 <
 >  retired-mainfra...@q.com>
 >  wrote:
 > 
 >  > Please show the
 >  complete AUDIT and BDELETE commands you
 are using.
 >  >
 >  > Did you look up ERR40
 >  in the "Error Codes and
 Diagnosis" section  (section  > 3 in my copy) of
 the
 > "Using the AUDIT Command"
 chapter (my chapter  67)?
 >  > The
 table (51) identifies several
 > 
 possible causes and corrective actions.
 >  >
 >  BDELETE is
 the proper action for only one of the causes.
 >  >
 >  > >
 -Original
 >  Message-
 >  > > From: IBM Mainframe
 >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On  > > Behalf Of willie
 >
 bunter  > > Sent: Wednesday, July 26, 2017 7:27 
 AM  > > To: IBM-
 > m...@listserv.ua.edu 
 > > Subject: DFHSM QUESTION  > >  > >
 Good  Day,  > >
 > > > I 
 ran an AUDIT of the BCDS.  I was 99% successfull of 
 performing a
 > clean  > up execept
 for  > > the following type dsns:
 >  > >  ERR 40
 DB2.ARCHLOG2.A0091613
 >  > >
 >  HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 MISSING  > >  FIXCDS B
 >
 DUMMY.RECOVER.MCB  CREATE(X'0014'
 X'0098257F')  > >  FIXCDS B
 > DUMMY.RECOVER.MCB 
 PATCH(X'002E' BITS(1.1.))  > > 
 FIXCDS B
 > DUMMY.RECOVER.MCB 
 PATCH(X'0030' X'000100010001')  >
 >  FIXCDS B
 > DUMMY.RECOVER.MCB
 >  EXPAND(X'0040')
 >  > >
 >  FIXCDS
 B DUMMY.RECOVER.MCB PATCH(X'0050' +  >
 >  > >
 > 
 X'404040404040404040404040404040404040404040404040404040404040
 >  > 404040404040
 > 
 > >
 >  404
 > 
 > >  FIXCDS B DUMMY.RECOVER.MCB
 >  PATCH(X'0050'
 >  > >
 > 
 HSMBACK.BACK.T592617.DB2.ARCHLOG
 >  >
 >
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0082'
 > 
 BITS(0110))
 >  > > 
 BDELETE
 >  DUMMY.RECOVER.MCB
 >  > >  FIXCDS B
 >  DUMMY.RECOVER.MCB DELETE
 >  > > END OF
 > 
 -     ENHANCED AUDIT - LISTING -
 > 
 >
 >  >
 >  >
 > I tried a HSEND BDELETE
 > 
 'DB2.ARCHLOG2.A0091613' ALL .  The command which 
 > I  > > ran in batch  was
 >
 successful however when I ran another AUDIT the entry  >
 appears.  I tried a
 > >  > HSEND
 FIXCDS B DB2.ARCHLOG2.A0091613.  Again the  command was
 > successful,  > > however  the
 AUDIT says otherwise.
 >  >
 >  >
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION

[willie bunter]

Here are the commands I tried :
 HSEND FIXCDS B DB96.ARCHLOG2.B778 (message received) :

ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT 
ARC0195I (CONT.) FOUND
ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS=   
ARC1615I FIXCDS COMMAND REJECTED  

HSEND  BDELETE 'DB2.ARCHLOG2.A0091613' ALL
No error message received.

I looked at the ERR 40  in the doc.  It describes my problem however it is not 
clear what I should do.  In this case the B record does not exist or missing.
for example it says "If the backup version (C) record references a data set (B) 
record that does not exist, then a new (B) record is created and the version 
added".  Not  usre ...then a new(B) record is created and the version added.

I do not understand this.  Any suggestions?

On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, July 26, 2017, 1:30 PM
 
 Please show the complete AUDIT
 and BDELETE commands you are using.
 
 Did you look up ERR40 in the "Error Codes
 and Diagnosis" section (section 3 in my copy) of the
 "Using the AUDIT Command" chapter (my chapter
 67)?  The table (51) identifies several possible causes and
 corrective actions.  BDELETE is the proper action for only
 one of the causes.
 
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Wednesday, July 26, 2017 7:27 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION
 > 
 > Good Day,
 > 
 > I ran an AUDIT of
 the BCDS.  I was 99% successfull of performing a clean up
 execept for
 > the following type dsns:
 >  ERR 40 DB2.ARCHLOG2.A0091613
 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 MISSING
 >  FIXCDS B DUMMY.RECOVER.MCB
 CREATE(X'0014' X'0098257F')
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'002E' BITS(1.1.))
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0030' X'000100010001')
 >  FIXCDS B DUMMY.RECOVER.MCB
 EXPAND(X'0040')
 >  FIXCDS B
 DUMMY.RECOVER.MCB PATCH(X'0050' +
 > 
 >
 X'404040404040404040404040404040404040404040404040404040404040404040404040
 > 404
 >  FIXCDS B
 DUMMY.RECOVER.MCB PATCH(X'0050'
 > HSMBACK.BACK.T592617.DB2.ARCHLOG
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0082' BITS(0110))
 >  BDELETE DUMMY.RECOVER.MCB
 >  FIXCDS B DUMMY.RECOVER.MCB DELETE
 > END OF -     ENHANCED AUDIT - LISTING
 -
 > 
 > I tried a HSEND
 BDELETE 'DB2.ARCHLOG2.A0091613' ALL .  The command
 which I
 > ran in batch was successful
 however when I ran another AUDIT the entry appears.  I
 tried a
 > HSEND FIXCDS B
 DB2.ARCHLOG2.A0091613.  Again the command was
 successful,
 > however the AUDIT says
 otherwise.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION

[willie bunter]

Brian,

I tried that out however it didn't work (record not found).  Below is the 
output:

ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
ARC0195I (CONT.) FOUND 
ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015,
ARC1001I (CONT.) REAS= 
ARC1615I FIXCDS COMMAND REJECTED   

On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, July 26, 2017, 9:23 PM
 
 If you just want to get rid of
 the backup, then you can do the following.
 
 HSEND FIXCDS B
 DB2.ARCHLOG2.A0091613 *DELETE*
 
 Regards
 Brian
 
 On Thu, Jul 27, 2017 at 1:30
 AM, retired mainframer <
 retired-mainfra...@q.com>
 wrote:
 
 > Please show the
 complete AUDIT and BDELETE commands you are using.
 >
 > Did you look up ERR40
 in the "Error Codes and Diagnosis" section
 (section
 > 3 in my copy) of the
 "Using the AUDIT Command" chapter (my chapter
 67)?
 > The table (51) identifies several
 possible causes and corrective actions.
 >
 BDELETE is the proper action for only one of the causes.
 >
 > > -Original
 Message-
 > > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > > Behalf Of willie bunter
 > > Sent: Wednesday, July 26, 2017 7:27
 AM
 > > To: IBM-MAIN@LISTSERV.UA.EDU
 > > Subject: DFHSM QUESTION
 > >
 > > Good
 Day,
 > >
 > > I
 ran an AUDIT of the BCDS.  I was 99% successfull of
 performing a clean
 > up execept for
 > > the following type dsns:
 > >  ERR 40 DB2.ARCHLOG2.A0091613
 > >
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING
 > >  FIXCDS B DUMMY.RECOVER.MCB
 CREATE(X'0014' X'0098257F')
 > >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'002E' BITS(1.1.))
 > >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0030' X'000100010001')
 > >  FIXCDS B DUMMY.RECOVER.MCB
 EXPAND(X'0040')
 > > 
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +
 > >
 > >
 X'404040404040404040404040404040404040404040404040404040404040
 > 404040404040
 > >
 404
 > >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050'
 > >
 HSMBACK.BACK.T592617.DB2.ARCHLOG
 > > 
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082'
 BITS(0110))
 > >  BDELETE
 DUMMY.RECOVER.MCB
 > >  FIXCDS B
 DUMMY.RECOVER.MCB DELETE
 > > END OF
 -     ENHANCED AUDIT - LISTING -
 >
 >
 > > I tried a HSEND BDELETE
 'DB2.ARCHLOG2.A0091613' ALL .  The command which
 > I
 > > ran in batch
 was successful however when I ran another AUDIT the entry
 > appears.  I tried a
 >
 > HSEND FIXCDS B DB2.ARCHLOG2.A0091613.  Again the
 command was successful,
 > > however
 the AUDIT says otherwise.
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive
 access instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 >
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: DFHSM QUESTION - REPOST

[willie bunter]

Lizette,

 I verified the syntax of the BDELETE command and it is correct.  I ran a 
HLIST against the dsn and it says "ARC0138I NO BCDS INFORMATION FOUND FOR 
DATASET DB2.ARCHLOG2.A0091613".

I will keep on digging around.

On Wed, 7/26/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION - REPOST
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, July 26, 2017, 11:15 AM
 
 I would suggest if you are
 running in batch, you may see successful.  But I would
 check the DFHSM Started task for error messages.
 
 That you still see the entry
 seems to indicate that it was not successful.
 
 Please check the syntax of
 your BDELETE Command.
 
 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.arcf000/s4118.htm
 
 
 
 I suggest you do the following
 
 HLIST DSN(your dataset name)
 BCDS
 
 See if you have more
 than one GEN for the backup.
 
 Next review the HSM Command manual for BDELETE
 and make sure you are entering the command correctly.
 
 Lastly, provide all commands
 and message (full details, mask company proprietary data)
 
 There are some functions that
 will return a OK to a command, but it does not mean that
 command was successful
 
 
 
 Lizette
 
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Wednesday, July 26, 2017 7:30 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFHSM QUESTION - REPOST
 > 
 > I am reposting my
 question because some info was truncated.
 > 
 > I ran an AUDIT of
 the BCDS.  I was 99% successfull of performing a clean
 up
 > execept for the following type
 dsns:
 >  ERR 40 DB2.ARCHLOG2.A0091613
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING
 > B RECORD
 >  FIXCDS B
 DUMMY.RECOVER.MCB CREATE(X'0014'
 X'0098257F')
 >  FIXCDS B
 DUMMY.RECOVER.MCB PATCH(X'002E'
 BITS(1.1.))
 >  FIXCDS B
 DUMMY.RECOVER.MCB PATCH(X'0030'
 X'000100010001')
 >  FIXCDS B
 DUMMY.RECOVER.MCB EXPAND(X'0040')
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050' +
 > 
 >
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
 >  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050'
 >
 HSMBACK.BACK.T592617.DB2.ARCHLOG
 > 
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082'
 BITS(0110))
 >  BDELETE
 DUMMY.RECOVER.MCB
 >  FIXCDS B
 DUMMY.RECOVER.MCB DELETE
 > END OF -    
 ENHANCED AUDIT - LISTING -
 > 
 > I tried a HSEND BDELETE
 'DB2.ARCHLOG2.A0091613' ALL .  The command which
 I
 > ran in batch was successful however
 when I ran another AUDIT the entry
 >
 appears.  I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. 
 Again the command
 > was successful,
 however the AUDIT says otherwise.
 > 
 > Anything else I could try?
 > 
 >
 
 > On Wed, 7/26/17, willie bunter
 <001409bd2345-dmarc-
 > requ...@listserv.ua.edu>
 wrote:
 > 
 >  Subject:
 DFHSM QUESTION
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Wednesday, July 26, 2017,
 10:26 AM
 > 
 >  Good
 Day,
 > 
 >  I ran an
 AUDIT of the BCDS.  I was
 >  99%
 successfull of performing a clean up execept for the 
 following type
 > dsns:
 >   ERR 40 DB2.ARCHLOG2.A0091613
 >  HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
 MISSING
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 CREATE(X'0014' X'0098257F')
 > 
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 PATCH(X'002E' BITS(1.1.))
 > 
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 PATCH(X'0030' X'000100010001')
 > 
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 EXPAND(X'0040')
 > 
 > 
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 > 
 PATCH(X'0050' +
 > 
 > 
 > 
 > 
 >
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
 >   FIXCDS B DUMMY.RECOVER.MCB
 >  PATCH(X'0050'
 HSMBACK.BACK.T592617.DB2.ARCHLOG
 >  
 FIXCDS B DUMMY.RECOVER.MCB
 > 
 PATCH(X'0082' BITS(0110))
 > 
 >   BDELETE
 DUMMY.RECOVER.MCB
 > 
 >
 
 > 
 >   FIXCDS B
 DUMMY.RECOVER.MCB
 >  DELETE
 > 
 > 
 >  END OF -     ENHANCED AUDIT -
 >  LISTING -
 > 
 > 
 > 
 >  I tried a HSEND BDELETE
 >  'DB2.ARCHLOG2.A0091613' ALL . 
 The command which I ran  in batch was
 >
 successful however when I ran another AUDIT the  entry
 appears.  I tried a
 > HSEND FIXCDS B 
 DB2.ARCHLOG2.A0091613.  Again the command was 
 successful,
 > however the AUDIT says
 otherwise.
 > 
 > 
 Anything else I could try?
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION - REPOST

[willie bunter]

I am reposting my question because some info was truncated.

I ran an AUDIT of the BCDS.  I was 99% successfull of performing a clean up 
execept for the following type dsns:
 ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING B 
RECORD
 FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')   
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) 
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
 FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')   
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +   
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) 
 BDELETE DUMMY.RECOVER.MCB
 FIXCDS B DUMMY.RECOVER.MCB DELETE
END OF - ENHANCED AUDIT - LISTING -
 
I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL .  The command which I ran 
in batch was successful however when I ran another AUDIT the entry appears.  I 
tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613.  Again the command was 
successful, however the AUDIT says otherwise.

Anything else I could try?


On Wed, 7/26/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> 
wrote:

 Subject: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, July 26, 2017, 10:26 AM
 
 Good Day,
 
 I ran an AUDIT of the BCDS.  I was
 99% successfull of performing a clean up execept for the
 following type dsns:
  ERR 40 DB2.ARCHLOG2.A0091613
 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING 
  FIXCDS B DUMMY.RECOVER.MCB
 CREATE(X'0014' X'0098257F')       
            
  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'002E' BITS(1.1.))       
          
  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0030' X'000100010001')     
           
  FIXCDS B DUMMY.RECOVER.MCB
 EXPAND(X'0040')           
                
    
  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050' +           
                
    
 
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG
  FIXCDS B DUMMY.RECOVER.MCB
 PATCH(X'0082' BITS(0110))       
          
  BDELETE DUMMY.RECOVER.MCB   
                
                
                 
  FIXCDS B DUMMY.RECOVER.MCB
 DELETE             
                
               
 END OF -     ENHANCED AUDIT -
 LISTING -             
                
           
  
 I tried a HSEND BDELETE
 'DB2.ARCHLOG2.A0091613' ALL .  The command which I ran
 in batch was successful however when I ran another AUDIT the
 entry appears.  I tried a HSEND FIXCDS B
 DB2.ARCHLOG2.A0091613.  Again the command was
 successful, however the AUDIT says otherwise.
 
 Anything else I could try?   
                
         
 
 --
 For IBM-MAIN subscribe / signoff /
 archive access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

DFHSM QUESTION

[willie bunter]

Good Day,

I ran an AUDIT of the BCDS.  I was 99% successfull of performing a clean up 
execept for the following type dsns:
 ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING 
 FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')   
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) 
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
 FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')   
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +   
 X'404040404040404040404040404040404040404040404040404040404040404040404040404
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG
 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) 
 BDELETE DUMMY.RECOVER.MCB
 FIXCDS B DUMMY.RECOVER.MCB DELETE
END OF - ENHANCED AUDIT - LISTING -
 
I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL .  The command which I ran 
in batch was successful however when I ran another AUDIT the entry appears.  I 
tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613.  Again the command was 
successful, however the AUDIT says otherwise.

Anything else I could try?

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

Re: DFHSM QUESTION : ARC0506I - RE- POST - PROBLEM SOLVED

[willie bunter]

I found the error.  The ODS(.xxx.etc.etc) was in the wrong starting column. 
 The AUDIT is in progress.

Thanks.

On Tue, 7/25/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> 
wrote:

 Subject: DFHSM QUESTION : ARC0506I - RE- POST
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, July 25, 2017, 12:37 PM
 
 Hallo To All Members,
 
   I am trying to run the following
 AUDIT command:
          
             HSEND AUDIT
 DATASETCONTROLS(BACKUP) FIX
 
 For some reason I am receiving the
 following error message :
 ARC0506I FAILURE TO ALLOCATE SYSOUT
 TYPE DATA SET,   
 ARC0506I (CONT.) RC=04, REAS=0210,
 EXTENDED REASON CODE=
 
 The doc says "For all dynamic
 allocation error and information codes, see the z/OS MVS
 Programming: Authorized Assembler Services Guide"
 
 I am not good at ASSEMBLER.  Any
 suggestions?
 
 Thanks.
 
 --
 For IBM-MAIN subscribe / signoff /
 archive access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: DFHSM QUESTION -

[willie bunter]

Lizette,

I re-posted my question.  I had a glitch.  Yes I am trying to write to a ODS.  
I will check the HSM guide.  As a FYI I did the copy/paste of the command from 
another LPAR on which I last ran it.


On Tue, 7/25/17, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION -
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, July 25, 2017, 12:34 PM
 
 You might try writing to a
 DATASET by using ODS(output.dataset)
 
 The command is in the HSM Admin guide
 
 The REAS=0210 can be found in
 ISPF - Issue PF1 (HELP) two times, select I for INDEX. 
 Enter D on the command line and select D1 - DAIR codes
 
 It is in there.
 
 
 Lizette
 
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Tuesday, July 25, 2017 9:30 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION -
 > 
 > Hallo To All
 Members,
 > 
 >    I
 am trying to run the following AUDIT command:
 >                        HSEND
 AUDIT DATASETCONTROLS(BACKUP) FIX
 > 
 > For some reason I am receiving the
 following error message :
 > ARC0506I
 FAILURE TO ALLOCATE SYSOUT TYPE DATA SET,  862
 > ARC0506I (CONT.) RC=04, REAS=0210,
 EXTENDED REASON CODE=
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

DFHSM QUESTION : ARC0506I - RE- POST

[willie bunter]

Hallo To All Members,

  I am trying to run the following AUDIT command:
  HSEND AUDIT DATASETCONTROLS(BACKUP) FIX

For some reason I am receiving the following error message :
ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET,   
ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE=

The doc says "For all dynamic allocation error and information codes, see the 
z/OS MVS Programming: Authorized Assembler Services Guide"

I am not good at ASSEMBLER.  Any suggestions?

Thanks.

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

DFHSM QUESTION -

[willie bunter]

Hallo To All Members,

   I am trying to run the following AUDIT command:
   HSEND AUDIT DATASETCONTROLS(BACKUP) FIX

For some reason I am receiving the following error message :
ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET,  862 
ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE=

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

Re: DFHSM QUESTION

[willie bunter]

Brian,

Thanks it worked.  That is what I am looking for.

Thanks 

On Fri, 6/30/17, Brian Fraser <brianmfra...@gmail.com> wrote:

 Subject: Re: DFHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, June 30, 2017, 11:34 AM
 
 Try like this:
 HSEND LIST BCDS DSNAME ODS(dsn)
 
 Brian
 
 
 On 29 Jun 2017 21:34,
 "willie bunter" <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 Sorry, I noticed a
 typo.  Should have read DFHSM
 ----
 On Thu, 6/29/17, willie bunter
 <001409bd2345-dmarc-
 requ...@listserv.ua.edu>
 wrote:
 
  Subject: DRHSM
 QUESTION
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Thursday, June 29, 2017, 8:46 AM
 
  Hallo To All,
 
  I am trying to get a list of
 all dsns
  which have a HSM backup.  I tried
 the following command
  but it listed the
 dsns on ML2.  Can someone spot my
 
 error?
 
  HSEND LIST DSN
 SELECT(BACKUP) -
 
 
 ODS(PRODD.LIST.ALL.BACKUP)
 
 
 Thanks.
 
 
 --
  For IBM-MAIN subscribe / signoff /
  archive access instructions,
 
 send email to lists...@listserv.ua.edu
  with the message: INFO IBM-MAIN
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: DRHSM QUESTION

[willie bunter]

I am authorized to use both
Looking at your suggestion to try HLIST  and let you know how I fared.

On Thu, 6/29/17, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: DRHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, June 29, 2017, 9:56 AM
 
 Are you authorized to the the
 HLIST command ? I forget which one, HSEND ot HLIST requires
 authorization , or did at one time, so 
 
 
 HLIST would work - syntax 
 
 
 HLIST
 DATASETNAME or DATASETNAME(dsname) or LEVEL 
 or LEVEL(qualifier) BOTH - OR - BCDS for backup
 
 
 
 HTH's
 
 
 
 Carmen
 
 
 - Original Message
 -
 
 From: "willie
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Thursday, June 29, 2017 7:46:35 AM
 
 Subject: DRHSM QUESTION 
 
 Hallo To All, 
 
 I am trying to get a list of
 all dsns which have a HSM backup. I tried the following
 command but it listed the dsns on ML2. Can someone spot my
 error? 
 
 HSEND LIST DSN
 SELECT(BACKUP) - 
 ODS(PRODD.LIST.ALL.BACKUP)
 
 
 Thanks. 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: DFHSM QUESTION

[willie bunter]

Sorry, I noticed a typo.  Should have read DFHSM 

On Thu, 6/29/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> 
wrote:

 Subject: DRHSM QUESTION
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, June 29, 2017, 8:46 AM
 
 Hallo To All,
 
 I am trying to get a list of all dsns
 which have a HSM backup.  I tried the following command
 but it listed the dsns on ML2.  Can someone spot my
 error?
 
 HSEND LIST DSN SELECT(BACKUP) -  
      
 ODS(PRODD.LIST.ALL.BACKUP)
 
 Thanks.
 
 --
 For IBM-MAIN subscribe / signoff /
 archive access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

DRHSM QUESTION

[willie bunter]

Hallo To All,

I am trying to get a list of all dsns which have a HSM backup.  I tried the 
following command but it listed the dsns on ML2.  Can someone spot my error?

HSEND LIST DSN SELECT(BACKUP) -  
  ODS(PRODD.LIST.ALL.BACKUP)

Thanks.

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

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

I should have clarified it.  The dsn is copied and in the following step it is 
deleted.  Sorry.

On Wed, 5/10/17, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, May 10, 2017, 8:41 AM
 
 You cannot code SHARE and DELETE
 on the same COPY command.  If the dataset is deleted after
 the copy step, then obviously DFDSS has released its enqueue
 and is no longer a factor in the situation you described.
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Wednesday, May 10, 2017 5:26 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFDSS QUESTION :SHARE PARM
 WHEN DOING COPY
 > 
 >
 Thanks for raising the point that the enqueue is caused by
 the initiator and not DFDSS,  I
 > will
 check into this.
 > To answer your
 question about the CICS file.  Yes, the enqueue is
 released.  The dsn is
 > copied and
 deleted and redefined.
 >
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

Thanks for raising the point that the enqueue is caused by the initiator and 
not DFDSS,  I will check into this.
To answer your question about the CICS file.  Yes, the enqueue is released.  
The dsn is copied and deleted and redefined.

Thanks again.

On Tue, 5/9/17, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 9, 2017, 1:27 PM
 
 Since the JCL has a reference to
 the DSN after the DFDSS step, the enqueue that is causing
 your conflict is held by the initiator, not by DFDSS.  The
 section I quoted has additional text that describes how
 DFDSS uses the initiator's enqueue.  You need to look
 at that to determine how it affects your job.
 
 When you close the file in
 CICS, is the enqueue released?  If so, the SHARE option is
 irrelevant since no one else is accessing the dataset. 
 Unless OAM is VSAM under the covers (like PDSE and ZFS), the
 quoted text states that is does apply.
 
 >
 -Original Message-
 > From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Tuesday, May 09, 2017 9:29 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: DFDSS QUESTION :SHARE PARM
 WHEN DOING COPY
 > 
 >
 The job does reference the dsn after it is enabled on
 CICS.
 > 
 > Since the
 dsn is OAM the SHARE parm does appy.  Right?
 > 
 >
 
 > On Tue, 5/9/17, retired mainframer <retired-mainfra...@q.com>
 wrote:
 > 
 >  Subject:
 Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Tuesday, May 9, 2017, 10:19
 AM
 > 
 >  >
 -Original
 >  Message-
 >  > From: IBM Mainframe
 >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  On
 >  > Behalf Of
 willie bunter
 >  > Sent: Tuesday, May
 09, 2017 6:01 AM
 >  > To: IBM-MAIN@LISTSERV.UA.EDU
 >  > Subject: DFDSS QUESTION :SHARE PARM
 WHEN
 >  DOING COPY
 >  >
 >  > Good
 >  Day To All,
 > 
 >
 >  > Could
 >  someone clarify the explanation and my
 understanding about
 >  the SHARE parm
 when
 >  > using COPY.
 >  Following is the explanation in the
 doc:
 >  >
 >  >
 SHARE specifies that
 >  DFSMSdss is to
 share the data sets to be copied for read
 >  > access with other programs.
 >  > SHARE and FULL are mutually
 exclusive; you
 >  cannot specify these
 keywords
 >  >
 > 
 together.
 >  > Do not specify DELETE
 if you
 >  specify SHARE. You must have
 exclusive control
 >  > over data sets
 that are to be deleted;
 >  SHARE does
 not require such exclusive
 >  >
 >  control.
 >  >
 Note: Unlike the RESTORE
 >  command, the
 COPY command honors the SHARE
 >  >
 keyword for VSAM data sets. However, the
 >  SHARE keyword is only honored for
 >  > VSAM
 >  data
 sets that were defined with share options other than
 >  (1,3) or (1,4).
 > 
 > Specifying the SHARE
 >  keyword
 does not cause DFSMSdss to honor the share
 >  > options that are defined for VSAM
 data
 >  sets. For VSAM data sets that
 are defined
 >  > with share options
 other than (1,3) or
 >  (1,4), specifying
 the SHARE keyword allows
 >  > other
 programs to obtain read access. It
 > 
 does not, however, allow write access to
 >  > the data sets while they are being
 copied.
 >  For VSAM data sets that are
 defined
 >  >
 > 
 with share options (1,3) or (1,4), neither read access
 nor
 >  write access by other
 >  > programs is
 > 
 allowed while the data set is being copied.
 >  >
 >  > If my
 understanding
 >  is correct the SHARE
 parm applis to VSAM dsns which are
 > 
 defined
 >  > with share options (2,3)
 .
 >  However the dsn in question is that
 it is an OAM file.
 >  Would the
 >  > SHARE apply to OAM dsns as
 >  well?
 > 
 >  The paragraph that
 >  talks about VSAM datasets I emphasizing
 the difference
 >  between COPY and
 RESTORE.  Since your dataset is not VSAM,
 >  the paragraph does not apply.  Note the
 following quote
 >  from the Data Set
 Serialization section of the
 > 
 manual"
 > 
 > 
 " The
 >  SHARE option has unique
 properties when applied to the
 > 
 following commands:
 >      * For the
 RESTORE
 >  command, SHARE applies to
 non-VSAM data sets only.
 >      * For
 the DUMP and COPY commands, SHARE
 > 
 applies to non-VSAM data sets and VSAM data sets that are
 >  defined with share options other than
 (1,3) and
 >  (1,4)."
 > 
 >  > Before
 >  the COPY is executed the file is closed
 on CICS.  However
 >  after the COPY
 step
 >  &g

Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

The job does reference the dsn after it is enabled on CICS.

Since the dsn is OAM the SHARE parm does appy.  Right?
 

On Tue, 5/9/17, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, May 9, 2017, 10:19 AM
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Tuesday, May 09, 2017 6:01 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFDSS QUESTION :SHARE PARM WHEN
 DOING COPY
 > 
 > Good
 Day To All,
 > 
 > Could
 someone clarify the explanation and my understanding about
 the SHARE parm when
 > using COPY.
 Following is the explanation in the doc:
 > 
 > SHARE specifies that
 DFSMSdss is to share the data sets to be copied for read
 > access with other programs.
 > SHARE and FULL are mutually exclusive; you
 cannot specify these keywords
 >
 together.
 > Do not specify DELETE if you
 specify SHARE. You must have exclusive control
 > over data sets that are to be deleted;
 SHARE does not require such exclusive
 >
 control.
 > Note: Unlike the RESTORE
 command, the COPY command honors the SHARE
 > keyword for VSAM data sets. However, the
 SHARE keyword is only honored for
 > VSAM
 data sets that were defined with share options other than
 (1,3) or (1,4).
 > Specifying the SHARE
 keyword does not cause DFSMSdss to honor the share
 > options that are defined for VSAM data
 sets. For VSAM data sets that are defined
 > with share options other than (1,3) or
 (1,4), specifying the SHARE keyword allows
 > other programs to obtain read access. It
 does not, however, allow write access to
 > the data sets while they are being copied.
 For VSAM data sets that are defined
 >
 with share options (1,3) or (1,4), neither read access nor
 write access by other
 > programs is
 allowed while the data set is being copied.
 > 
 > If my understanding
 is correct the SHARE parm applis to VSAM dsns which are
 defined
 > with share options (2,3) . 
 However the dsn in question is that it is an OAM file. 
 Would the
 > SHARE apply to OAM dsns as
 well?
 
 The paragraph that
 talks about VSAM datasets I emphasizing the difference
 between COPY and RESTORE.  Since your dataset is not VSAM,
 the paragraph does not apply.  Note the following quote
 from the Data Set Serialization section of the
 manual"
 
 " The
 SHARE option has unique properties when applied to the
 following commands:
     * For the RESTORE
 command, SHARE applies to non-VSAM data sets only.
     * For the DUMP and COPY commands, SHARE
 applies to non-VSAM data sets and VSAM data sets that are
 defined with share options other than (1,3) and
 (1,4)."
 
 > Before
 the COPY is executed the file is closed on CICS.  However
 after the COPY step
 > has executed of the
 dsn (no warnings or errors received)  the job abends at the
 following
 > step which tries to enable
 the file on CICS because the dsn is not released from the
 job until
 > it completes.  The job has 6
 steps.
 > My question is
 shouldn''t the dsn be released after the COPY step
 is has completed or does
 > dsn is
 released at the end ot the job?  Could someone please clear
 this up for me?
 
 Does the
 DSN appear anywhere else in the JCL for the job?  Did a
 previous step in the job reference the DSN during
 execution?
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

DFDSS QUESTION :SHARE PARM WHEN DOING COPY

[willie bunter]

Good Day To All,

Could someone clarify the explanation and my understanding about the SHARE parm 
when using COPY. Following is the explanation in the doc:

SHARE specifies that DFSMSdss is to share the data sets to be copied for read
access with other programs.
SHARE and FULL are mutually exclusive; you cannot specify these keywords
together.
Do not specify DELETE if you specify SHARE. You must have exclusive control
over data sets that are to be deleted; SHARE does not require such exclusive
control.
Note: Unlike the RESTORE command, the COPY command honors the SHARE
keyword for VSAM data sets. However, the SHARE keyword is only honored for
VSAM data sets that were defined with share options other than (1,3) or (1,4).
Specifying the SHARE keyword does not cause DFSMSdss to honor the share
options that are defined for VSAM data sets. For VSAM data sets that are defined
with share options other than (1,3) or (1,4), specifying the SHARE keyword 
allows
other programs to obtain read access. It does not, however, allow write access 
to
the data sets while they are being copied. For VSAM data sets that are defined
with share options (1,3) or (1,4), neither read access nor write access by other
programs is allowed while the data set is being copied.

If my understanding is correct the SHARE parm applis to VSAM dsns which are 
defined with share options (2,3) .  However the dsn in question is that it is 
an OAM file.  Would the SHARE apply to OAM dsns as well?
Before the COPY is executed the file is closed on CICS.  However after the COPY 
step has executed of the dsn (no warnings or errors received)  the job abends 
at the following step which tries to enable the file on CICS because the dsn is 
not released from the job until it completes.  The job has 6 steps.  
My question is shouldn''t the dsn be released after the COPY step is has 
completed or does dsn is released at the end ot the job?  Could someone please 
clear this up for me?

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

Re: UNABLE TO DELETE MIGRAT2 DSN - PROBLEM SOLVED

[willie bunter]

Eureka !! I did it.

I deleted the dsn via IDCAMS using NOSCRATCH and the name of the CATALOG.  

DELETE DB21.ARCHLOGA.A0326760 -
NOSCRATCH -
CATALOG(CATALOG.DB21)  

Thanks

On Wed, 3/29/17, willie bunter <williebun...@yahoo.com> wrote:

 Subject: UNABLE TO DELETE MIGRAT2 DSN
 To: IBM-MAIN@listserv.ua.edu
 Received: Wednesday, March 29, 2017, 7:23 AM
 
 Good Day To All,
 
 I am trying to delete a dsn which is at MIGRAT2.  I
 tried the HDELETE command but I get the following :
 
 DB21.ARCHLOGA.A0326760 DELETE FAILED, RC=0002, REAS= 
 ARC1102I DATA SET IS NOT MIGRATED/BACKED UP 
    
 
 I tried DELETE NSCR to no avail.  I even tried DELETE
 NVR which didn't work either.
 
 Is there anything else I could try?
 
 Thanks.
 

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

Re: ADR144E

[willie bunter]

John,

Thanks for pointing out the error :  ** -

Thanks to all who responded.


On Mon, 3/20/17, John McKown <john.archie.mck...@gmail.com> wrote:

 Subject: Re: ADR144E
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, March 20, 2017, 9:18 AM
 
 On Mon, Mar 20, 2017 at
 8:12 AM, willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 > I am trying
 to troubleshoot a user's job which is using ADRDSSU.  I
 cannot
 > find the reason why the job
 fails on a :
 >
 >
 ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA
 SET REFERENCED
 > BY DDNAME FILTERDD
 >
 > ​
 >
 > Below is the
 FILTERDD  DD (TST.FILTDD)
 >
 >  INCLUDE( -
 >     
       )
 >
 > I think
 the problem could be with the parm DATASET(FDD I
 would
 > appreciate it someone could point
 out my error.
 >
 
 ​That is it. The INCLUDE doesn't have
 _any_ entries in it. It needs to have
 at
 least one.​ If you meant to select "all", then
 use ** as the DSN. E.g.
 
 INCLUDE( -
   ** -
 )
 
 ​Or
 perhaps some patterns:
 
 INCLUDE(-
    SYS1.**
 -
    SYS2.USER.** -
 )​
 
 
 
 
 >
 > Thanks in advance.
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive
 access instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 >
 
 
 
 -- 
 "Irrigation of the
 land with seawater desalinated by fusion power is
 ancient. It's called 'rain'."
 -- Michael McClary, in alt.fusion
 
 Maranatha! <><
 John
 McKown
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

ADR144E

[willie bunter]

Good Day To All,

I am trying to troubleshoot a user's job which is using ADRDSSU.  I cannot find 
the reason why the job fails on a :

ADR144E (002)-RI03P(02), INCOMPLETE SPECIFICATION IN DATA SET REFERENCED BY 
DDNAME FILTERDD   

Below is the jcl:

/* 
//S4112  EXEC PGM=ADRDSSU,REGION=0K,PARM='TYPRUN=NORUN' 
//TD9101   DD UNIT=3390,VOL=SER=TD9101,DISP=SHR 
//TD9102   DD UNIT=3390,VOL=SER=TD9102,DISP=SHR 
//TD9103   DD UNIT=3390,VOL=SER=TD9103,DISP=SHR 
//TD9104   DD UNIT=3390,VOL=SER=TD9104,DISP=SHR 
//NOTAPE   DD DUMMY 
//SYSPRINT DD SYSOUT =*
//SYSUDUMP DD SYSOUT=D  
//SYSINDD DSN=PROD.DATALIB(SYSDAU),DISP=SHR 
//FILTERDD DD DSN=TST.FILTDD,DISP=SHR   

Below is the SYSIN DD contents:

DUMP INDDNAME(TD9101) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9102) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TD9103) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  
DUMP INDDNAME(TTD9104) OUTDDNAME(NOTAPE) -  
 DATASET(FDD(FILTERDD)) -  
 DELETE PURGE  

Below is the FILTERDD  DD (TST.FILTDD)

 INCLUDE( -
   )   

I think the problem could be with the parm DATASET(FDD I would appreciate 
it someone could point out my error.

Thanks in advance.

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Sri,
I checked.  The column positions were 80-95.  Not sure why it wouldn't work.  
anyway, what is good is that with the help I received all is well.

Thanks for taking the time to help me out.


On Fri, 12/16/16, Sri h Kolusu <skol...@us.ibm.com> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 11:12 AM
 
 Willie,
 
 Are the column positions 80
 thru 95 the correct positions of your data? If 
 it worked partially, I am guessing that your
 column positions are 
 different from what
 you described. Make sure you have the right column 
 positions.
 
 Thanks,
 Kolusu
 
 IBM Mainframe Discussion List
 <IBM-MAIN@LISTSERV.UA.EDU>
 wrote on 
 12/16/2016 08:59:22 AM:
 
 > From: willie bunter
 <001409bd2345-dmarc-requ...@listserv.ua.edu>
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Date: 12/16/2016 09:03 AM
 > Subject: Re: TSO LINE COMMAND - EDIT
 MODE
 > Sent by: IBM Mainframe Discussion
 List <IBM-MAIN@LISTSERV.UA.EDU>
 > 
 > Kolusu,
 > 
 > I tried your
 suggestion but the command worked partially.  It 
 > removed an ending zero 
 > 
 > before the
 command:
 > 0001
 >
 
 > after the command
 >
 0001000
 >
 
 > On Fri, 12/16/16, Sri h Kolusu <skol...@us.ibm.com>
 wrote:
 > 
 >  Subject:
 Re: TSO LINE COMMAND - EDIT MODE
 >  To:
 IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Friday, December 16, 2016,
 10:55 AM
 > 
 > 
 Willie,
 > 
 >  You
 need to use '^'
 >  instead of
 '¬' 
 > 
 > 
 C
 >  P'^' '' 80 95
 ALL
 > 
 >  ^  is the
 non blank character when your
 > 
 encoding scheme is 1047 on the 
 > 
 mainframe
 > 
 > 
 Thanks,
 >  Kolusu
 >
 
 >  IBM
 >  Mainframe
 Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
 >  wrote on 
 > 
 12/16/2016 08:45:22 AM:
 > 
 >  > From: willie bunter
 >  <001409bd2345-dmarc-requ...@listserv.ua.edu>
 >  > To: IBM-MAIN@LISTSERV.UA.EDU
 >  > Date: 12/16/2016 08:45 AM
 >  > Subject: Re: TSO LINE COMMAND -
 EDIT
 >  MODE
 >  >
 Sent by: IBM Mainframe Discussion
 > 
 List <IBM-MAIN@LISTSERV.UA.EDU>
 >  > 
 >  >
 Bill,
 >  > 
 > 
 > I tried out your
 >  suggestion but
 it didn't work.  I get the message 
 >  > No CHARS '¬' found
 >  >
 > 
 
 >  > On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov>
 >  wrote:
 >  > 
 >  >  Subject:
 > 
 Re: TSO LINE COMMAND - EDIT MODE
 > 
 >  To:
 >  IBM-MAIN@LISTSERV.UA.EDU
 >  >  Received: Friday, December 16,
 2016,
 >  10:39 AM
 > 
 > 
 >  >  I
 > 
 believe the command you
 >  >  need
 is:  C
 >  P'¬' ' ' 80
 95 ALL
 >  > 
 > 
 The picture P'¬' finds all NON blank
 >  >  characters. 
 >  > 
 >  > 
 Bill
 >  > 
 > 
 >  -Original Message-
 > 
 >  From: IBM Mainframe Discussion List
 >  [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  >  On Behalf Of willie bunter
 >  >  Sent: Friday,
 >  > 
 >  December
 16, 2016 7:15 AM
 >  >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  >  Subject: TSO LINE COMMAND - EDIT
 MODE
 >  > 
 > 
 >  Good Day To
 >  All,
 >  > 
 >  >  Is
 there a
 >  way of filling
 >  >  columns 80 95 with
 >  blanks?  I have sequence commands
 >  > 
 >  (please see
 below for an example) which I would like to
 >  >  remove.
 > 
 > 
 >  >  00550003   **
 
 >  >  0056      
 >  > 
 > 
 00570001   *  
 >  > 
 >  00580003   ** 
 >  >  0059 
 > 
     
 >  > 
 0061   *  
 >  > 
 00610003   ** 
 >  > 
 0062      
 >  > 
 >  00630001   *  
 >  > 
 > 
 00640003   ** 
 >  > 
 0065 
 >      
 >  >  00660001   *  
 >  >  00670003   ** 
 >  >  0068      
 >  > 
 > 
 00690001   *  
 >  > 
 >  0073   ** 
 >  >  0071 
 > 
     
 >  > 
 > 
 >  I looked
 >  at using C
 P'00' " "
 >  >  80
 95 however since this is a huge dsn I
 > 
 was wondering if
 >  >  there is a
 quicker
 >  way.  I also considered
 pressing the EOF
 >  >  key on my
 keyboard on every line however
 >  since
 the file is
 >  >  quite large it
 >  would take me a while.
 >  > 
 >  >  Is
 there a line command I could issue to
 > 
 do
 >  >  what I want to do?  I
 remember in
 >  ROSCOE I could issue
 the
 >  >  command FILL
 >  80 95  and it would replace the numbers
 with
 >  >  blank spaces.
 >  > 
 >  > 
 Thanks
 >  > 
 > 
 > 
 > 
 --

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Carmen,

The command C P'^' ' ' 73 80 ALL did the trick.  I do not know why it wouldn't 
work before.  I checked to see if I BNDS set but it wasn't

A massive thank you to you and the all who offered suggestions.  For those who 
are celebrating Christmas please permit me to wish you all a very happy 
Christmas and a brilliant 2017.


On Fri, 12/16/16, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 11:00 AM
 
 on my terminal the carrot
 p'^' 
 translates to NE sign,
 '¬' 
 sure you don't have ant
 BNDS set that will now allow you to see or change past col80
 ? 
 =BNDS> > 
 -
 Original Message -
 
 From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Friday, December 16, 2016 9:57:12 AM
 
 Subject: Re: TSO LINE COMMAND - EDIT MODE
 
 
 Carmen, 
 
 I tried C P'¬' '
 ' 80 95 ALL as well as C '¬' NX " "
 ALL but I get : No CHARS '¬' found 
 
 
 On Fri, 12/16/16, Carmen Vitullo <cvitu...@hughes.net>
 wrote: 
 
 Subject: Re: TSO
 LINE COMMAND - EDIT MODE 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Received: Friday, December 16, 2016, 10:47
 AM 
 
 strange, did you just C
 
 ¬' ' ' 80 95 ALL 
 
 or the correct format Bill
 provided 
 C P'¬' ' ' 80 95
 ALL - you 
 need the 'P" picture
 clause 
 Carmen 
 
 - Original Message - 
 
 From: "willie 
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 
 Sent: Friday, December 16,
 2016 9:45:22 AM 
 
 Subject:
 Re: TSO LINE COMMAND - EDIT MODE 
 
 
 Bill, 
 
 I tried out your suggestion but it didn't
 
 work. I get the message No CHARS
 '¬' found 
 
 
 
 On Fri, 12/16/16, George,
 William@FTB <bill.geo...@ftb.ca.gov>
 
 wrote: 
 
 Subject: Re: TSO 
 LINE COMMAND
 - EDIT MODE 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 
 Received: Friday, December
 16, 2016, 10:39 
 AM 
 
 I believe the command 
 you 
 need is: C P'¬' ' ' 80 
 95 ALL 
 The picture
 P'¬' finds all 
 NON blank 
 characters. 
 
 Bill 
 
 -Original Message- 
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 
 
 On Behalf Of willie bunter
 
 Sent: Friday, 
 December 16,
 
 2016 7:15 AM 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 
 Subject: TSO LINE COMMAND
 - EDIT MODE 
 
 Good Day To
 All, 
 
 Is there a way of
 filling 
 columns 80 95 with blanks? I have
 sequence 
 commands 
 (please
 see below for an example) 
 which I would
 like to 
 remove. 
 
 00550003 ** 
 0056 
 00570001 * 
 00580003 ** 
 0059 
 0061 * 
 00610003 ** 
 0062 
 00630001 * 
 00640003 ** 
 0065 
 00660001 * 
 00670003 ** 
 0068 
 00690001 * 
 0073 ** 
 0071 
 
 I
 looked at using C 
 P'00' "
 " 
 80 95 however 
 since
 this is a huge dsn I was wondering if 
 there
 is a quicker way. I also considered 
 pressing the EOF 
 key on my
 keyboard on 
 every line however since the
 file is 
 quite 
 large it
 would take me a while. 
 
 Is
 there a line command I could issue to do 
 what I want to do? I remember in ROSCOE I could
 
 issue the 
 command FILL 80
 95 and it would 
 replace the numbers with
 
 blank spaces. 
 
 Thanks 
 
 --
 
 
 For IBM-MAIN subscribe /
 signoff / archive 
 
 access
 instructions, send email to lists...@listserv.ua.edu
 
 
 with the message: INFO
 IBM-MAIN 
 
 __
 
 
 CONFIDENTIALITY NOTICE:
 This email from the 
 
 State
 of California is for the sole use of 
 the
 intended 
 recipient and may contain 
 confidential and privileged 
 information. 
 Any unauthorized
 review or use, including 
 disclosure or
 distribution, is prohibited. If 
 you are not
 
 the intended recipient, please 
 contact the sender and 
 destroy
 all copies 
 of this email. 
 
 
 --
 
 
 For IBM-MAIN subscribe /
 signoff / archive 
 
 access
 instructions, 
 send 
 email
 to lists...@listserv.ua.edu
 
 
 with the message: INFO
 IBM-MAIN 
 
 
 --
 
 
 For IBM-MAIN subscribe /
 signoff / archive 
 access instructions, 
 send email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 
 access instructions, 
 send
 email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instru

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Kolusu,

I tried your suggestion but the command worked partially.  It removed an ending 
zero 

before the command:
0001

after the command
0001000

On Fri, 12/16/16, Sri h Kolusu <skol...@us.ibm.com> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:55 AM
 
 Willie,
 
 You need to use '^'
 instead of '¬' 
 
 C
 P'^' '' 80 95 ALL
 
 ^  is the non blank character when your
 encoding scheme is 1047 on the 
 mainframe
 
 Thanks,
 Kolusu
 
 IBM
 Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
 wrote on 
 12/16/2016 08:45:22 AM:
 
 > From: willie bunter
 <001409bd2345-dmarc-requ...@listserv.ua.edu>
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Date: 12/16/2016 08:45 AM
 > Subject: Re: TSO LINE COMMAND - EDIT
 MODE
 > Sent by: IBM Mainframe Discussion
 List <IBM-MAIN@LISTSERV.UA.EDU>
 > 
 > Bill,
 > 
 > I tried out your
 suggestion but it didn't work.  I get the message 
 > No CHARS '¬' found
 >
 
 > On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov>
 wrote:
 > 
 >  Subject:
 Re: TSO LINE COMMAND - EDIT MODE
 >  To:
 IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Friday, December 16, 2016,
 10:39 AM
 > 
 >  I
 believe the command you
 >  need is:  C
 P'¬' ' ' 80 95 ALL
 > 
 The picture P'¬' finds all NON blank
 >  characters. 
 > 
 >  Bill
 > 
 >  -Original Message-
 >  From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  On Behalf Of willie bunter
 >  Sent: Friday,
 > 
 December 16, 2016 7:15 AM
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Subject: TSO LINE COMMAND - EDIT MODE
 > 
 >  Good Day To
 All,
 > 
 >  Is there a
 way of filling
 >  columns 80 95 with
 blanks?  I have sequence commands
 > 
 (please see below for an example) which I would like to
 >  remove.
 > 
 >  00550003   ** 
 >  0056      
 > 
 00570001   *  
 > 
 00580003   ** 
 >  0059 
     
 >  0061   *  
 >  00610003   ** 
 >  0062      
 > 
 00630001   *  
 > 
 00640003   ** 
 >  0065 
     
 >  00660001   *  
 >  00670003   ** 
 >  0068      
 > 
 00690001   *  
 > 
 0073   ** 
 >  0071 
     
 > 
 >  I looked
 at using C P'00' " "
 >  80 95 however since this is a huge dsn I
 was wondering if
 >  there is a quicker
 way.  I also considered pressing the EOF
 >  key on my keyboard on every line however
 since the file is
 >  quite large it
 would take me a while.
 > 
 >  Is there a line command I could issue to
 do
 >  what I want to do?  I remember in
 ROSCOE I could issue the
 >  command FILL
 80 95  and it would replace the numbers with
 >  blank spaces.
 > 
 >  Thanks
 > 
 > 
 --
 >  For IBM-MAIN subscribe / signoff /
 archive
 >  access instructions, send
 email to lists...@listserv.ua.edu
 >  with the message: INFO IBM-MAIN
 > 
 > 
 __
 >  CONFIDENTIALITY NOTICE: This email from
 the
 >  State of California is for the
 sole use of the intended
 >  recipient
 and may contain confidential and privileged
 >  information. Any unauthorized review or
 use, including
 >  disclosure or
 distribution, is prohibited. If you are not
 >  the intended recipient, please contact
 the sender and
 >  destroy all copies of
 this email.
 > 
 > 
 > 
 --
 >  For IBM-MAIN subscribe / signoff /
 archive
 >  access instructions,
 >  send email to lists...@listserv.ua.edu
 >  with the message: INFO IBM-MAIN
 > 
 > 
 >
 --
 > For IBM-MAIN subscribe / signoff / archive
 access instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 > 
 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Sorry.  I tried it out (copy pasted your command) but I get the message No 
CHARS '^' found


On Fri, 12/16/16, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:56 AM
 
 finally got logged on and
 tested and use ISPF help 
 
 
 
 Example -
 ===> chg all p'^' 'x' 72 change all
 non-blanks in column 
 72 to the character
 "x" 
 
 
 - Original Message -
 
 From: "Sri h Kolusu"
 <skol...@us.ibm.com>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Friday, December 16, 2016 9:55:18 AM
 
 Subject: Re: TSO LINE COMMAND - EDIT MODE
 
 
 Willie, 
 
 You need to use '^'
 instead of '¬' 
 
 C
 P'^' '' 80 95 ALL 
 
 ^ is the non blank character when your encoding
 scheme is 1047 on the 
 mainframe 
 
 Thanks, 
 Kolusu 
 
 IBM
 Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
 wrote on 
 12/16/2016 08:45:22 AM: 
 
 > From: willie bunter
 <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 > To: IBM-MAIN@LISTSERV.UA.EDU
 
 > Date: 12/16/2016 08:45 AM 
 > Subject: Re: TSO LINE COMMAND - EDIT MODE
 
 > Sent by: IBM Mainframe Discussion List
 <IBM-MAIN@LISTSERV.UA.EDU>
 
 > 
 > Bill, 
 > 
 > I tried out your
 suggestion but it didn't work. I get the message 
 > No CHARS '¬' found 
 >
  
 > On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov>
 wrote: 
 > 
 > Subject:
 Re: TSO LINE COMMAND - EDIT MODE 
 > To:
 IBM-MAIN@LISTSERV.UA.EDU
 
 > Received: Friday, December 16, 2016,
 10:39 AM 
 > 
 > I
 believe the command you 
 > need is: C
 P'¬' ' ' 80 95 ALL 
 >
 The picture P'¬' finds all NON blank 
 > characters. 
 > 
 > Bill 
 > 
 > -Original Message- 
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 
 > On Behalf Of willie bunter 
 > Sent: Friday, 
 >
 December 16, 2016 7:15 AM 
 > To: IBM-MAIN@LISTSERV.UA.EDU
 
 > Subject: TSO LINE COMMAND - EDIT MODE
 
 > 
 > Good Day To All,
 
 > 
 > Is there a way
 of filling 
 > columns 80 95 with blanks?
 I have sequence commands 
 > (please see
 below for an example) which I would like to 
 > remove. 
 > 
 > 00550003 ** 
 > 0056
 
 > 00570001 * 
 >
 00580003 ** 
 > 0059 
 > 0061 * 
 > 00610003
 ** 
 > 0062 
 >
 00630001 * 
 > 00640003 ** 
 > 0065 
 > 00660001 *
 
 > 00670003 ** 
 >
 0068 
 > 00690001 * 
 > 0073 ** 
 > 0071
 
 > 
 > I looked at
 using C P'00' " " 
 > 80
 95 however since this is a huge dsn I was wondering if 
 > there is a quicker way. I also considered
 pressing the EOF 
 > key on my keyboard on
 every line however since the file is 
 >
 quite large it would take me a while. 
 >
 
 > Is there a line command I could issue
 to do 
 > what I want to do? I remember in
 ROSCOE I could issue the 
 > command FILL
 80 95 and it would replace the numbers with 
 > blank spaces. 
 > 
 > Thanks 
 > 
 >
 --
 
 > For IBM-MAIN subscribe / signoff /
 archive 
 > access instructions, send
 email to lists...@listserv.ua.edu
 
 > with the message: INFO IBM-MAIN 
 > 
 >
 __
 
 > CONFIDENTIALITY NOTICE: This email
 from the 
 > State of California is for
 the sole use of the intended 
 > recipient
 and may contain confidential and privileged 
 > information. Any unauthorized review or
 use, including 
 > disclosure or
 distribution, is prohibited. If you are not 
 > the intended recipient, please contact the
 sender and 
 > destroy all copies of this
 email. 
 > 
 > 
 >
 --
 
 > For IBM-MAIN subscribe / signoff /
 archive 
 > access instructions, 
 > send email to lists...@listserv.ua.edu
 
 > with the message: INFO IBM-MAIN 
 > 
 > 
 >
 --
 
 > For IBM-MAIN subscribe / signoff /
 archive access instructions, 
 > send
 email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 > 
 
 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Carmen,

I tried C P'¬' ' ' 80 95 ALL  as well as C '¬' NX " " ALL but I get : No CHARS 
'¬' found

On Fri, 12/16/16, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:47 AM
 
 strange, did you just C
 ¬' ' ' 80 95 ALL 
 
 or the correct format Bill provided 
 C P'¬' ' ' 80 95 ALL - you
 need the 'P" picture clause 
 Carmen
 
 - Original Message -----
 
 From: "willie
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Friday, December 16, 2016 9:45:22 AM
 
 Subject: Re: TSO LINE COMMAND - EDIT MODE
 
 
 Bill, 
 
 I tried out your suggestion but it didn't
 work. I get the message No CHARS '¬' found 
 
 
 On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov>
 wrote: 
 
 Subject: Re: TSO
 LINE COMMAND - EDIT MODE 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Received: Friday, December 16, 2016, 10:39
 AM 
 
 I believe the command
 you 
 need is: C P'¬' ' ' 80
 95 ALL 
 The picture P'¬' finds all
 NON blank 
 characters. 
 
 Bill 
 
 -Original Message- 
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 
 On Behalf Of willie bunter 
 Sent: Friday, 
 December 16,
 2016 7:15 AM 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Subject: TSO LINE COMMAND - EDIT MODE 
 
 Good Day To All, 
 
 Is there a way of filling 
 columns 80 95 with blanks? I have sequence
 commands 
 (please see below for an example)
 which I would like to 
 remove. 
 
 00550003 ** 
 0056 
 00570001 * 
 00580003 ** 
 0059 
 0061 * 
 00610003 ** 
 0062 
 00630001 * 
 00640003 ** 
 0065 
 00660001 * 
 00670003 ** 
 0068 
 00690001 * 
 0073 ** 
 0071 
 
 I looked at using C
 P'00' " " 
 80 95 however
 since this is a huge dsn I was wondering if 
 there is a quicker way. I also considered
 pressing the EOF 
 key on my keyboard on
 every line however since the file is 
 quite
 large it would take me a while. 
 
 Is there a line command I could issue to do 
 what I want to do? I remember in ROSCOE I could
 issue the 
 command FILL 80 95 and it would
 replace the numbers with 
 blank spaces. 
 
 Thanks 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 
 access instructions, send email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 __
 
 CONFIDENTIALITY NOTICE: This email from the
 
 State of California is for the sole use of
 the intended 
 recipient and may contain
 confidential and privileged 
 information.
 Any unauthorized review or use, including 
 disclosure or distribution, is prohibited. If
 you are not 
 the intended recipient, please
 contact the sender and 
 destroy all copies
 of this email. 
 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 
 access instructions, 
 send
 email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

I tried it but nothing was changed.  Thanks for the suggestion.


On Fri, 12/16/16, Dyck, Lionel B. (TRA) <lionel.d...@va.gov> wrote:

 Subject: Re: [EXTERNAL] Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:49 AM
 
 Try something like this
 then:  c p'=' ' ' 85 90 all
 
 
 --
 Lionel B. Dyck 
 Mainframe
 Systems Programmer - TRA
 Enterprise
 Operations (Station 200) (005OP6.3.10)
 Information and Technology, IT Operations and
 Services
 Office: 512-326-6173
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Friday,
 December 16, 2016 9:45 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: [EXTERNAL] Re: TSO LINE COMMAND - EDIT
 MODE
 
 Bill,
 
 I tried out your suggestion
 but it didn't work.  I get the message No CHARS
 '¬' found
 
 On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov>
 wrote:
 
  Subject: Re: TSO
 LINE COMMAND - EDIT MODE
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Friday, December 16, 2016, 10:39
 AM
  
  I believe the command
 you
  need is:  C P'¬' ' '
 80 95 ALL
  The picture P'¬' finds
 all NON blank
  characters. 
 
 
  Bill
  
 
 -Original Message-
  From: IBM
 Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of willie bunter
  Sent: Friday,
  December 16, 2016 7:15 AM
  To:
 IBM-MAIN@LISTSERV.UA.EDU
  Subject: TSO LINE COMMAND - EDIT MODE
  
  Good Day To All,
  
  Is there a way of filling
  columns 80 95 with blanks?  I have sequence
 commands  (please see below for an example) which I would
 like to  remove.
  
 
 00550003   **
  0056
 
 00570001   *
  00580003   **
  0059
  0061   *
  00610003   **
  0062
  00630001   *
 
 00640003   **
  0065
 
 00660001   *
  00670003   **
  0068
  00690001   *
  0073   **
  0071 
     
  
  I looked at using
 C P'00' " "
  80 95 however
 since this is a huge dsn I was wondering if  there is a
 quicker way.  I also considered pressing the EOF  key on
 my keyboard on every line however since the file is  quite
 large it would take me a while.
  
  Is there a line command I could issue to do 
 what I want to do?  I remember in ROSCOE I could issue
 the  command FILL 80 95  and it would replace the numbers
 with  blank spaces.
  
 
 Thanks
  
 
 --
  For IBM-MAIN subscribe / signoff / archive 
 access instructions, send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
  
 
 __
  CONFIDENTIALITY NOTICE: This email from the 
 State of California is for the sole use of the intended 
 recipient and may contain confidential and privileged 
 information. Any unauthorized review or use, including 
 disclosure or distribution, is prohibited. If you are not 
 the intended recipient, please contact the sender and 
 destroy all copies of this email.
  
  
 
 --
  For IBM-MAIN subscribe / signoff / archive 
 access instructions,  send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
  
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Carmen,

I gave it a shot but I get message :No CHARS '¬' found

On Fri, 12/16/16, Carmen Vitullo <cvitu...@hughes.net> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:32 AM
 
 you can rerun that
 command for any other char or use the command to change any
 non blank char in those fields 
 I don't
 have a system right now to test but I believe 
 C P'¬' NX " " ALL 
 will change any NO BLANK CHAR to " "
 BLANK 
 Carmen 
 
 - Original Message -
 
 From: "willie
 bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Sent: Friday, December 16, 2016 9:24:29 AM
 
 Subject: Re: TSO LINE COMMAND - EDIT MODE
 
 
 John, 
 
 I tried out your suggestion and it pariallly
 worked.. The 00 were removed however the non-00 were left.
 
 
 63 
 64 02
 ** 
 65 
 
 Thanks for your help. 
 
 
 On Fri, 12/16/16, John McKown <john.archie.mck...@gmail.com>
 wrote: 
 
 Subject: Re: TSO
 LINE COMMAND - EDIT MODE 
 To: IBM-MAIN@LISTSERV.UA.EDU
 
 Received: Friday, December 16, 2016, 10:18
 AM 
 
 On Fri, Dec 16, 2016 at
 
 9:15 AM, willie bunter < 
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 
 wrote: 
 
 > Good Day To 
 All, 
 > 
 > Is there a 
 way of filling columns 80 95 with blanks? I
 have 
 sequence 
 >
 commands (please see below for 
 an example)
 which I would like to remove. 
 > 
 > 
 00550003 ** 
 > 0056 
 > 00570001 *
 
 > 00580003 ** 
 >
 0059 
 > 
 0061 *
 
 > 
 00610003 ** 
 > 0062 
 > 00630001 *
 
 > 00640003 ** 
 >
 0065 
 > 
 00660001 *
 
 > 
 00670003 ** 
 > 0068 
 > 00690001 *
 
 > 0073 ** 
 >
 0071 
 > 
 > I
 looked at using C P'00' " 
 " 80 95 however since this is a huge dsn I
 was 
 > wondering if there is a quicker
 way. I 
 also considered pressing the EOF 
 > key on 
 my keyboard on
 every line however since the file is quite 
 large it 
 > would take me a
 while. 
 > 
 
 ​In the 
 ISPF editor or the
 TSO line editor. With ISPF, just put the 
 word 
 "ALL" at the
 end of your 
 command: 
 
 C P'00' 
 " "
 80 95 ALL​ 
 
 
 
 > 
 > Is
 there a line command I could issue to 
 do
 what I want to do? I remember 
 > in 
 ROSCOE I could issue the command FILL 80 95 and
 it would 
 replace the 
 >
 numbers with blank 
 spaces. 
 > 
 > Thanks 
 > 
 > 
 --
 
 > For IBM-MAIN subscribe / signoff /
 archive 
 access instructions, 
 > send email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 > 
 
 
 
 -- 
 Heisenberg
 may have been 
 here. 
 
 http://xkcd.com/1770/ 
 
 Maranatha! <>< 
 John McKown 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 
 access instructions, 
 send
 email to lists...@listserv.ua.edu
 
 with the message: INFO IBM-MAIN 
 
 --
 
 For IBM-MAIN subscribe / signoff / archive
 access instructions, 
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Bobby,

I tried your command but it removed only 1 zero from the extreme end i.e.  

before:
0001

after:
0001000

On Fri, 12/16/16, Herring, Bobby <bherr...@txfb-ins.com> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:33 AM
 
 I use this command to do
 that:
 
 C P'^'
 '' 80 95 ALLThat carat character tells it to change
 non-blank characters to null.
 
 Bobby Herring
 Texas Farm Bureau
 Insurance
 
 -Original
 Message-
 From: IBM Mainframe Discussion
 List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: December 16
 9:24 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: [IBM-MAIN] TSO LINE COMMAND - EDIT
 MODE
 
 John,
 
 I tried out your suggestion
 and it pariallly worked..  The 00 were removed however the
 non-00 were left.
 
 63
 64 02     **
 65
 
 Thanks for your help.
 
 On Fri, 12/16/16, John McKown <john.archie.mck...@gmail.com>
 wrote:
 
  Subject: Re: TSO
 LINE COMMAND - EDIT MODE
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Friday, December 16, 2016, 10:18
 AM
 
  On Fri, Dec 16, 2016
 at
  9:15 AM, willie bunter <
  001409bd2345-dmarc-requ...@listserv.ua.edu>
  wrote:
 
  >
 Good Day To
  All,
  >
  > Is there a
  way of
 filling columns 80 95 with blanks?  I have  sequence 
 > commands (please see below for  an example) which I
 would like to remove.
  >
 
 >
  00550003   **
  > 0056
  >
 00570001   *
  >
 00580003   **
  > 0059
  >
 
 0061   *
  >
  00610003   **
  >
 0062
  > 00630001   *
  > 00640003   **
 
 > 0065
  >
 
 00660001   *
  >
  00670003   **
  >
 0068
  > 00690001   *
  > 0073   **
 
 > 0071
  >
  > I
 looked at using C P'00' "
 
 " 80 95 however since this is a huge dsn I was  >
 wondering if there is a quicker way.  I  also considered
 pressing the EOF  > key on  my keyboard on every line
 however since the file is quite  large it  > would take
 me a while.
  >
 
  ​In the
  ISPF editor or the
 TSO line editor. With ISPF, just put the  word 
 "ALL" at the end of your
 
 command:
 
  C
 P'00'
  " " 80 95 ALL​
 
 
 
  >
  > Is there a line
 command I could issue to  do what I want to do?  I
 remember  > in  ROSCOE I could issue the command FILL
 80 95  and it would  replace the  > numbers with
 blank  spaces.
  >
  >
 Thanks
  >
  >
 
 --
  > For IBM-MAIN subscribe / signoff /
 archive  access instructions,  > send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN  >
 
 
 
  --
  Heisenberg may have been
 
 here.
 
  http://xkcd.com/1770/
 
  Maranatha! <><
  John McKown
 
 
 --
  For IBM-MAIN subscribe / signoff / archive 
 access instructions,  send email to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 [http://www.txfb-ins.com/TFBICImages/email.jpg]
 J.D. Power Disclaimer<https://www.txfb-ins.com/terms-conditions#disclaimer>
 
 
 CONFIDENTIALITY STATEMENT: The foregoing
 message (including attachments) is covered by the Electronic
 Communication Privacy Act, 18 U.S.C. sections 2510-2521, and
 is CONFIDENTIAL. If you believe that it has been sent to you
 in error, do not read it. If you are not the intended
 recipient, you are hereby notified that any retention,
 dissemination, distribution, or copying of this
 communication is strictly prohibited. Please reply to the
 sender that you have received the message in error, then
 delete it. Thank you.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

Bill,

I tried out your suggestion but it didn't work.  I get the message No CHARS '¬' 
found

On Fri, 12/16/16, George, William@FTB <bill.geo...@ftb.ca.gov> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:39 AM
 
 I believe the command you
 need is:  C P'¬' ' ' 80 95 ALL
 The picture P'¬' finds all NON blank
 characters. 
 
 Bill
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Friday,
 December 16, 2016 7:15 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: TSO LINE COMMAND - EDIT MODE
 
 Good Day To All,
 
 Is there a way of filling
 columns 80 95 with blanks?  I have sequence commands
 (please see below for an example) which I would like to
 remove.
 
 00550003   ** 
 0056      
 00570001   *  
 00580003   ** 
 0059      
 0061   *  
 00610003   ** 
 0062      
 00630001   *  
 00640003   ** 
 0065      
 00660001   *  
 00670003   ** 
 0068      
 00690001   *  
 0073   ** 
 0071      
 
 I looked at using C P'00' " "
 80 95 however since this is a huge dsn I was wondering if
 there is a quicker way.  I also considered pressing the EOF
 key on my keyboard on every line however since the file is
 quite large it would take me a while.
 
 Is there a line command I could issue to do
 what I want to do?  I remember in ROSCOE I could issue the
 command FILL 80 95  and it would replace the numbers with
 blank spaces.
 
 Thanks
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 __
 CONFIDENTIALITY NOTICE: This email from the
 State of California is for the sole use of the intended
 recipient and may contain confidential and privileged
 information. Any unauthorized review or use, including
 disclosure or distribution, is prohibited. If you are not
 the intended recipient, please contact the sender and
 destroy all copies of this email.
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 

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

Re: TSO LINE COMMAND - EDIT MODE

[willie bunter]

John,

I tried out your suggestion and it pariallly worked..  The 00 were removed 
however the non-00 were left.  

63
64 02 **  
65

Thanks for your help.

On Fri, 12/16/16, John McKown <john.archie.mck...@gmail.com> wrote:

 Subject: Re: TSO LINE COMMAND - EDIT MODE
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, December 16, 2016, 10:18 AM
 
 On Fri, Dec 16, 2016 at
 9:15 AM, willie bunter <
 001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 
 > Good Day To
 All,
 >
 > Is there a
 way of filling columns 80 95 with blanks?  I have
 sequence
 > commands (please see below for
 an example) which I would like to remove.
 >
 >
 00550003   **
 > 0056
 > 00570001   *
 > 00580003   **
 > 0059
 >
 0061   *
 >
 00610003   **
 > 0062
 > 00630001   *
 > 00640003   **
 > 0065
 >
 00660001   *
 >
 00670003   **
 > 0068
 > 00690001   *
 > 0073   **
 > 0071
 >
 > I looked at using C P'00' "
 " 80 95 however since this is a huge dsn I was
 > wondering if there is a quicker way.  I
 also considered pressing the EOF
 > key on
 my keyboard on every line however since the file is quite
 large it
 > would take me a while.
 >
 
 ​In the
 ISPF editor or the TSO line editor. With ISPF, just put the
 word
 "ALL" at the end of your
 command:
 
 C P'00'
 " " 80 95 ALL​
 
 
 
 >
 > Is there a line command I could issue to
 do what I want to do?  I remember
 > in
 ROSCOE I could issue the command FILL 80 95  and it would
 replace the
 > numbers with blank
 spaces.
 >
 > Thanks
 >
 >
 --
 > For IBM-MAIN subscribe / signoff / archive
 access instructions,
 > send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 >
 
 
 
 -- 
 Heisenberg may have been
 here.
 
 http://xkcd.com/1770/
 
 Maranatha! <><
 John McKown
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

TSO LINE COMMAND - EDIT MODE

[willie bunter]

Good Day To All,

Is there a way of filling columns 80 95 with blanks?  I have sequence commands 
(please see below for an example) which I would like to remove.

00550003   ** 
0056  
00570001   *  
00580003   ** 
0059  
0061   *  
00610003   ** 
0062  
00630001   *  
00640003   ** 
0065  
00660001   *  
00670003   ** 
0068  
00690001   *  
0073   ** 
0071  

I looked at using C P'00' " " 80 95 however since this is a huge dsn I was 
wondering if there is a quicker way.  I also considered pressing the EOF key on 
my keyboard on every line however since the file is quite large it would take 
me a while.

Is there a line command I could issue to do what I want to do?  I remember in 
ROSCOE I could issue the command FILL 80 95  and it would replace the numbers 
with blank spaces.

Thanks

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

The dsn was successfully backed up with not problems.  The LISTCAT is clean 
when run on the dsn however I get a SOC4 reason code 11 if a LISTCAT is run on 
the CATALOG.The same dsn is being flagged (IEC331I 028-002,LISTCAT) by the 
LISTCAT. 

On Fri, 9/16/16, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 16, 2016, 3:08 PM
 
 Was the VSAM1 dataset
 successfully backed up after the last time it was
 modified?  If so, delete it, rebuild the catalog, and
 restore the backup to the same volumes.
 
 Can you do a LISTCAT of the individual dataset
 without error?  If so, the listing should contain enough
 information to support a DEFINE RECATALOG later.  If not,
 do you have access to the job that created the dataset
 originally (or to the person/program)?  If so, does that
 provide sufficient data for a DEFINE RECATALOG?  If you
 have sufficient data:
  
    Perform a DELETE NOSCRATCH for the dataset. 
 That will remove the catalog entry.
  
    Perform a REPRO MERGECAT for all the remaining
 datasets in the catalog.  The record with the error should
 not be accessed.
      Fix all
 the aliases in the master catalog for the HLQs involved
 (including VSAM1) to point to the new catalog
      Perform a DEFINE RECATALOG for
 this dataset.
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Friday, September 16, 2016 10:36
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > When I
 do the LISTCAT of the entire catalog it flags the dsn which
 was also flagged by the
 > DIAGNOSE.
 > The error message is
 >
 IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
 > IEC331I SYS1.ICFCAT.UCATPROM
 > IEC331I VSAM1.HARL.VVL000D.MASTERA.SNAP
 > IEC332I GETO,GFL ,ICDV,ACD1
 > 
 > The explanation
 is
 > Permanent I/O error in catalog.
 > Explanation: An I/O error processing
 the
 > catalog occurred while processing
 an access
 > method services command that
 requires
 > modifying the catalog.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

I looked at that option but the bad record(s) will be moved as well.

On Fri, 9/16/16, Mike Schwab <mike.a.sch...@gmail.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, September 16, 2016, 1:31 PM
 
 http://www-01.ibm.com/support/docview.wss?uid=isg1II13354
 For reorging / moving a catalog to a new
 volume.
 
 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idac100/dffvol.htm
 New location, possibly updated.
 
 On Fri, Sep 16, 2016 at 12:23
 PM, willie bunter
 <001409bd2345-dmarc-requ...@listserv.ua.edu>
 wrote:
 > I tried that and it failed
 because when you use export/import, catalog code expects you
 to import using the same name and the same volume so unless
 you can use the same volser and the same catalog name this
 will not work.
 >
 >
 
 > On Thu, 9/15/16, Gibney, Dave <gib...@wsu.edu>
 wrote:
 >
 >  Subject:
 Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Thursday, September 15, 2016,
 3:25 PM
 >
 >  Well,
 try to IMPORT the
 >  back-up on a test
 system or different name and see what
 > 
 happens.
 >
 >  >
 -Original
 >  Message-
 >  > From: IBM Mainframe
 >  Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  > On Behalf Of willie bunter
 >  > Sent: Thursday, September 15, 2016
 10:07
 >  AM
 >  >
 To: IBM-MAIN@LISTSERV.UA.EDU
 >  > Subject: Re: REASON: 3 - RECORD
 TYPE NOT
 >  RECOGNIZED
 >  >
 >  > I
 was
 >  told that EXPORT/IMPORT would not
 fix the problem because it
 >  would
 >  > export the bad records only
 REPOR
 >  MERGECAT would work.
 >  >
 >  > I ran a
 LISTCAT on the dataset (as flagged
 >  by
 the DIAGNOSE) and it came
 >  >
 clean.
 >  This leads me to believe that
 it may not be the offending
 >  dsn. 
 The dsn
 >  > is on the volumes (3)
 >  >
 >  > The
 catalog is
 >  backed up via IDCAMS
 EXPORT daily successfully.
 >  >
 >  > I plan to run a
 >  VERIFY/EXAMINE (as recommended) and see
 what comes out.
 >  >
 >  >
 > 
 
 >  > On Wed, 9/14/16, retired mainframer
 <retired-mainfra...@q.com>
 >  > wrote:
 > 
 >
 >  >  Subject: Re: REASON: 3 -
 RECORD TYPE NOT
 >  RECOGNIZED
 >  >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  >  Received: Wednesday, September
 14, 2016,
 >  12:37 PM
 >  >
 >  > 
 REPRO
 >  MERGECAT does not
 >  >  seem like the best
 >  choice to me.  It might work for a
 user  catalog since
 >  the
 >  > DSN is not needed by users to
 >  access their  datasets.  For every
 level that is
 >  > moved, you need
 to  change the alias in
 >  the master
 to relate to the new DSN.
 >  >
 >  (This is what the warning is about.) 
 What will REPRO do
 >  when it
 encounters
 >  > the bad record?
 >  >
 >  > 
 It's been a
 >  while but I seem to
 remember  using EXPORT followed by
 > 
 IMPORT
 >  > for issues like this.
 >  Don't forget to lock the catalog for
 the job's
 >  > duration.  (You
 may need to do this
 >  during scheduled
 down  time without
 >  >
 >  users accessing the catalog.)
 >  >
 >  >  What
 happens if you try to
 >  >  access
 the dataset by way of the
 >  catalog,
 such as specifying  it on a DD
 >  >
 statement?   Have you tried to
 >  manually delete and recreate the
 offending
 >  > catalog entry?  Is
 the dataset physically
 >  on the volume
 the catalog thinks  it's
 >  >
 on?
 >  >
 > 
 >  From where
 >  >  would
 >  you restore the catalog?  How was it
 backed up?  If  by
 >  DFDSS, was it
 a
 >  > physical or logical
 >  backup?
 >  >
 >  >  >
 > 
 -Original Message-
 >  > 
 > From:
 >  IBM Mainframe Discussion
 List
 >  >
 > 
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  >  On
 >  > 
 > Behalf Of
 >  willie bunter
 >  >  > Sent: Wednesday,
 >  September 14, 2016 4:33  AM  > To:
 IBM-
 >  > m...@listserv.ua.edu
 >  > Subject: Re: REASON: 3 - RECORD
 TYPE NOT
 >  > RECOGNIZED  > 
 > The  DIAGNOSE
 >  gives the same
 error and no change.  I ran
 >  >
 examine  (using the following  >
 > 
 parms) and "
 >  >  NO ERRORS
 >  DETECTED"
 > 
 >  >
 >  >  > INDEXTEST
 DATATEST
 >  >  >
 >  >  ITEST
 > 
 NODATATEST ERRORLIMIT(1000)
 >  > 
 >
 >  >  NOITEST DATATEST
 ERRORLIMIT(1000)
 >  >  >
 >  >  > I ran
 > 
 LISTCAT against the CATALOG and i

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

When I do the LISTCAT of the entire catalog it flags the dsn which was also 
flagged by the DIAGNOSE.
The error message is 
IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG  
IEC331I SYS1.ICFCAT.UCATPROM  
IEC331I VSAM1.HARL.VVL000D.MASTERA.SNAP  
IEC332I GETO,GFL ,ICDV,ACD1 

The explanation is 
Permanent I/O error in catalog.
Explanation: An I/O error processing the   
catalog occurred while processing an access
method services command that requires  
modifying the catalog. 

I ran several DIAGNOSE and the same dsn and attributes are displayed.  I ran 
several EXAMINEs and NO ERRORS DETECTED.
The parms I used for the EXAMINE are :
ITEST NODATATEST ERRORLIMIT(1000)
NOITEST DATATEST ERRORLIMIT(1000)
INDEXTEST DATATEST

I continue looking.

On Thu, 9/15/16, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, September 15, 2016, 3:01 PM
 
 Told by whom?  Since the
 error message says an I/O error occurred, it seems the
 offending record would be unreadable to any process.
 
 What happens if you LISTCAT
 the entire catalog?  Do it in batch since TSO automatically
 changes the command if you don't specify an ENTRIES or
 LEVEL operand.  (This will also give you a list of all the
 HLQs you will need for the MERGECAT.)  If it comes back
 clean, then DIAGNOSE may be reporting a problem in a
 currently unused area.  In that case, MERGECAT might not
 have any problem at all.  If there is an error message, it
 might give more detail than DIAGNOSE did.
 
 If the daily EXPORT runs OK,
 it should be impossible for IMPORT to build a bad record. 
 If anything is wrong with the exported data, I would expect
 IMPORT to either discard the offending record with a
 suitable info diagnostic (preferable) or abort the entire
 effort.
 
 EXAMINE is
 concerned with BCS/VVDS consistency.  I don't think it
 cares that much about catalog structure.
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Thursday, September 15, 2016 10:07
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > I was
 told that EXPORT/IMPORT would not fix the problem because it
 would export the
 > bad records only REPOR
 MERGECAT would work.
 > 
 > I ran a LISTCAT on the dataset (as flagged
 by the DIAGNOSE) and it came clean.  This
 > leads me to believe that it may not be the
 offending dsn.  The dsn is on the volumes (3)
 > 
 > The catalog is
 backed up via IDCAMS EXPORT daily successfully.
 > 
 > I plan to run a
 VERIFY/EXAMINE (as recommended) and see what comes out.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

I tried that and it failed because when you use export/import, catalog code 
expects you to import using the same name and the same volume so unless you can 
use the same volser and the same catalog name this will not work.


On Thu, 9/15/16, Gibney, Dave <gib...@wsu.edu> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Thursday, September 15, 2016, 3:25 PM
 
 Well, try to IMPORT the
 back-up on a test system or different name and see what
 happens.
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 > On Behalf Of willie bunter
 > Sent: Thursday, September 15, 2016 10:07
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > I was
 told that EXPORT/IMPORT would not fix the problem because it
 would
 > export the bad records only REPOR
 MERGECAT would work.
 > 
 > I ran a LISTCAT on the dataset (as flagged
 by the DIAGNOSE) and it came
 > clean. 
 This leads me to believe that it may not be the offending
 dsn.  The dsn
 > is on the volumes (3)
 > 
 > The catalog is
 backed up via IDCAMS EXPORT daily successfully.
 > 
 > I plan to run a
 VERIFY/EXAMINE (as recommended) and see what comes out.
 > 
 >
 
 > On Wed, 9/14/16, retired mainframer <retired-mainfra...@q.com>
 > wrote:
 > 
 >  Subject: Re: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 >  To: IBM-MAIN@LISTSERV.UA.EDU
 >  Received: Wednesday, September 14, 2016,
 12:37 PM
 > 
 >  REPRO
 MERGECAT does not
 >  seem like the best
 choice to me.  It might work for a user  catalog since
 the
 > DSN is not needed by users to
 access their  datasets.  For every level that is
 > moved, you need to  change the alias in
 the master to relate to the new DSN.
 >
 (This is what the warning is about.)  What will REPRO do 
 when it encounters
 > the bad record?
 > 
 >  It's been a
 while but I seem to remember  using EXPORT followed by
 IMPORT
 > for issues like this. 
 Don't forget to lock the catalog for the job's
 > duration.  (You may need to do this
 during scheduled down  time without
 >
 users accessing the catalog.)
 > 
 >  What happens if you try to
 >  access the dataset by way of the
 catalog, such as specifying  it on a DD
 > statement?   Have you tried to 
 manually delete and recreate the offending
 > catalog entry?  Is the dataset physically
 on the volume the catalog thinks  it's
 > on?
 > 
 >  From where
 >  would
 you restore the catalog?  How was it backed up?  If  by
 DFDSS, was it a
 > physical or logical
 backup?
 > 
 >  >
 -Original Message-
 >  > From:
 IBM Mainframe Discussion List
 > 
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 >  On
 >  > Behalf Of
 willie bunter
 >  > Sent: Wednesday,
 September 14, 2016 4:33  AM  > To: IBM-
 > m...@listserv.ua.edu 
 > Subject: Re: REASON: 3 - RECORD TYPE NOT
 > RECOGNIZED  >  > The  DIAGNOSE
 gives the same error and no change.  I ran
 > examine  (using the following  >
 parms) and "
 >  NO ERRORS
 DETECTED"
 >  >
 >  > INDEXTEST DATATEST
 >  >
 >  ITEST
 NODATATEST ERRORLIMIT(1000)
 >  >
 >  NOITEST DATATEST ERRORLIMIT(1000)
 >  >
 >  > I ran
 LISTCAT against the CATALOG and it  flagged the same VSAM
 dsn
 > posting the  >  following
 error messages:
 >  > IEC331I
 >  028-002,LISTCAT ,STEP1   ,IGG0CLEG
 >  > According to the problem
 explanation
 >  > Explanation: An I/O
 error processing
 >  the
 >  > catalog occurred while
 processing
 >  an access
 >  > method services command that
 >  requires
 >  >
 modifying the catalog.
 >  >
 Programmer Response: Messages IEC331I,  > IEC332I, and
 IEC333I have
 > been printed to  aid 
 > in determining the cause of the  error and  >
 where
 > the error occurred. If  a
 hardware error  > is not causing the  problem,
 > restore or  > rebuild the 
 catalog.
 >  >
 > 
 > I have
 >  read up on the process of
 rebuilding the catalog (REPRO
 > 
 MERGECAT) however
 >  > there could be
 a
 >  problem when using LEVEL or ENTRIES
 parm.  According to the  doc  > "may
 > cause data sets to no  longer be
 found".  This is not reassuring.
 >  >
 >  > I would
 prefer to
 >  restore the CATALOG which
 seems safer.  I would like  guidance on this  >
 > subject.
 > 
 > 
 --
 >  For IBM-MAIN subscribe / signoff /
 archive  access instructions,  send email
 > to lists...@listserv.ua.edu 
 with the message: INFO IBM-MAIN
 > 
 &

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

I was told that EXPORT/IMPORT would not fix the problem because it would export 
the bad records only REPOR MERGECAT would work.

I ran a LISTCAT on the dataset (as flagged by the DIAGNOSE) and it came clean.  
This leads me to believe that it may not be the offending dsn.  The dsn is on 
the volumes (3) 

The catalog is backed up via IDCAMS EXPORT daily successfully.

I plan to run a VERIFY/EXAMINE (as recommended) and see what comes out.  


On Wed, 9/14/16, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Wednesday, September 14, 2016, 12:37 PM
 
 REPRO MERGECAT does not
 seem like the best choice to me.  It might work for a user
 catalog since the DSN is not needed by users to access their
 datasets.  For every level that is moved, you need to
 change the alias in the master to relate to the new DSN. 
 (This is what the warning is about.)  What will REPRO do
 when it encounters the bad record?
 
 It's been a while but I seem to remember
 using EXPORT followed by IMPORT for issues like this. 
 Don't forget to lock the catalog for the job's
 duration.  (You may need to do this during scheduled down
 time without users accessing the catalog.)
 
 What happens if you try to
 access the dataset by way of the catalog, such as specifying
 it on a DD statement?   Have you tried to
 manually delete and recreate the offending catalog entry? 
 Is the dataset physically on the volume the catalog thinks
 it's on?
 
 From where
 would you restore the catalog?  How was it backed up?  If
 by DFDSS, was it a physical or logical backup?
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Wednesday, September 14, 2016 4:33
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: Re: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > The
 DIAGNOSE gives the same error and no change.  I ran examine
 (using the following
 > parms) and "
 NO ERRORS DETECTED"
 > 
 > INDEXTEST DATATEST
 >
 ITEST NODATATEST ERRORLIMIT(1000)
 >
 NOITEST DATATEST ERRORLIMIT(1000)
 > 
 > I ran LISTCAT against the CATALOG and it
 flagged the same VSAM dsn posting the
 >
 following error messages:
 > IEC331I
 028-002,LISTCAT ,STEP1   ,IGG0CLEG
 > According to the problem explanation
 > Explanation: An I/O error processing
 the
 > catalog occurred while processing
 an access
 > method services command that
 requires
 > modifying the catalog.
 > Programmer Response: Messages IEC331I,
 > IEC332I, and IEC333I have been printed to
 aid
 > in determining the cause of the
 error and
 > where the error occurred. If
 a hardware error
 > is not causing the
 problem, restore or
 > rebuild the
 catalog.
 > 
 > I have
 read up on the process of rebuilding the catalog (REPRO
 MERGECAT) however
 > there could be a
 problem when using LEVEL or ENTRIES parm.  According to the
 doc
 > "may cause data sets to no
 longer be found".  This is not reassuring.
 > 
 > I would prefer to
 restore the CATALOG which seems safer.  I would like
 guidance on this
 > subject.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

The DIAGNOSE gives the same error and no change.  I ran examine (using the 
following parms) and " NO ERRORS DETECTED"

INDEXTEST DATATEST
ITEST NODATATEST ERRORLIMIT(1000)
NOITEST DATATEST ERRORLIMIT(1000)

I ran LISTCAT against the CATALOG and it flagged the same VSAM dsn posting the 
following error messages:
IEC331I 028-002,LISTCAT ,STEP1   ,IGG0CLEG
According to the problem explanation 
Explanation: An I/O error processing the   
catalog occurred while processing an access
method services command that requires  
modifying the catalog. 
Programmer Response: Messages IEC331I,   
IEC332I, and IEC333I have been printed to aid
in determining the cause of the error and
where the error occurred. If a hardware error
is not causing the problem, restore or   
rebuild the catalog. 

I have read up on the process of rebuilding the catalog (REPRO MERGECAT) 
however there could be a problem when using LEVEL or ENTRIES parm.  According 
to the doc "may cause data sets to no longer be found".  This is not reassuring.

I would prefer to restore the CATALOG which seems safer.  I would like guidance 
on this subject.

Thanks.

On Tue, 9/13/16, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: REASON: 3 - RECORD TYPE NOT RECOGNIZED
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Tuesday, September 13, 2016, 1:01 PM
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Tuesday, September 13, 2016 9:01
 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > 
 > Hi
 All,
 > 
 > While
 running a DIAGNOSE on a USERCAT the following error was
 picked up:
 > 
 >
 IDC21364I ERROR DETECTED BY DIAGNOSE:
 >   ICFCAT ENTRY: 05:26:06.214
 UTMOPB08: START TWRC MSGID(AFE7 (7)
 >   RECORD: 05:26:06.214
 UTMOPB08: START TWRC MSGID(AFE7 /F0
 >   OFFSET: X'0002'
 >   REASON: 3 - RECORD TYPE NOT
 RECOGNIZED
 > IDC21365I ICFCAT RECORD
 DISPLAY:
 >   RECORD:
 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0
 > 
 > The programmer
 response (I hope I read it right) says
 >
 Use DELETE NOSCRATCH to remove the sphere or base record, if
 it exists.
 > 
 > I have
 2 questions:
 > Since the dsn is not
 listed in the job output after IDC21364i message I assume
 that the dsn -
 > listed on side (cols 85
 to 119) -
 > I assume that is the dsn in
 question. Please correct me if I am wrong.
 > 
 > Is this problem
 serious or it can wait for action to be taken?  The problem
 was detected
 > about 10 days ago.
 
 You have already waited ten
 days and not yet taken any action.  Has there been any
 noticeable impact?  If you run the DIAGNOSE again, do the
 results change?  For better or worse?
 
 Were other activities that use the catalog
 running at the same time as your DIAGNOSE?  When I was
 running EXAMINE jobs to confirm consistency between catalogs
 and VVDSs, I determined that some reported errors were
 transient and could be eliminated by executing the VERIFY
 command just prior to the EXAMINE.  I don't know if the
 same issue could affect DIAGNOSE.  
 
 If it is a permanent error, I would be more
 concerned with how it occurred and what to do to prevent it
 in the future.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

REASON: 3 - RECORD TYPE NOT RECOGNIZED

[willie bunter]

Hi All,

While running a DIAGNOSE on a USERCAT the following error was picked up:

IDC21364I ERROR DETECTED BY DIAGNOSE:
  ICFCAT ENTRY: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 (7) 
  RECORD: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0   
  OFFSET: X'0002'
  REASON: 3 - RECORD TYPE NOT RECOGNIZED 
IDC21365I ICFCAT RECORD DISPLAY: 
  RECORD: 05:26:06.214 UTMOPB08: START TWRC MSGID(AFE7 /F0  

The programmer response (I hope I read it right) says 
Use DELETE NOSCRATCH to remove the sphere or base record, if it exists.

I have 2 questions:
Since the dsn is not listed in the job output after IDC21364i message I assume 
that the dsn - listed on side (cols 85 to 119) -
I assume that is the dsn in question. Please correct me if I am wrong.

Is this problem serious or it can wait for action to be taken?  The problem was 
detected about 10 days ago.

Thanks.

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Good Day To All,

I have great news.  I found the missing dsn and the volser from the 
HSM.JOURNAL.BACKUP.V0009984 file.  Thanks to all who helped with their 
suggestions and support.
.

On Mon, 6/20/16, Greg Shirey  wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 5:29 PM
 
 Willie has already posted
 that there is no backup.  The data set along with the
 catalog entry has been deleted - as long as the ML2 tape has
 not been recycled, it can be retrieved from there.  There
 is a documented procedure for doing this in the HSM
 administration manual.   
 
 Regards,
 Greg Shirey
 Ben E. Keith Company 
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Walter Davies
 Sent: Monday,
 June 20, 2016 4:11 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM
 ML2 VOLUME
 
 Just because you
 delete a data set if it has backups they might still be
 there. Try allocating the old DSN as empty and restore from
 a backup. I have done that before.
 
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Elardus 

The user said that she did a HDEL besides the dsn.  I did a HLIST however it 
was unsuccessful.

I am looking at the suggestion posted earlier about the doc to recover a 
deleted ML2 dsn.


On Mon, 6/20/16, Elardus Engelbrecht <elardus.engelbre...@sita.co.za> wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 1:58 PM
 
 willie bunter wrote:
 
 >I am checking the journal file hoping to find any trace
 of the dsn.  I don't have a backup of the dsn that is
 why I am trying to find the ML2 volser.
 
 Urggg. I feel your pain. As a previous Storage Admin
 I had to handle those pain.
 
 
 >I cannot issue the HRECALL because the dsn doesn't
 exist.  The same reason I cannot issue the HRECOVER
 because there is no backup.
 
 Ok. Let us go back. Did you ever issued the HLIST command as
 kindly suggested by Lizette? 
 
 If so, then I retract my question. Sorry for being
 bothersome.
 
 Please show us HOW that dataset was deleted (Post JCL +
 messages confirming that action). 
 
 Perhaps it was just uncataloged / renamed or such? (SMF
 audit trails could help you there)
 
 Or use ISMF to scan your volsers to see if there is a
 [uncataloged] copy lurking somewhere...
 
 Perhaps you can scan your tape management system to see if
 there is a copy sitting somewhere?
 
 Or do you have any Peer-to-Peer Remote Copy [1] or similar
 technology? Perhaps there is a version sitting on your
 remote site?
 
 Groete / Greetings
 Elardus Engelbrecht
 
 [1] - I know that any actions are immediately duplicated to
 remote, but perhaps the line was hopefully down or
 something?
 
 --
 For IBM-MAIN subscribe / signoff / archive access
 instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

I am checking the journal file hoping to find any trace of the dsn.  I don't 
have a backup of the dsn that is why I am trying to find the ML2 volser.

I cannot issue the HRECALL because the dsn doesn't exist.  The same reason I 
cannot issue the HRECOVER because there is no backup.

On Mon, 6/20/16, retired mainframer <retired-mainfra...@q.com> wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 1:05 PM
 
 Why are you looking in
 the JOURNAL?  It contains only "recent" data
 since the last CDS backup.  How long ago was the dataset
 migrated?  To find the DSN, you need to look in the backup
 copy that covers the time frame when the migration
 occurred.  But if you need to look up anything about the
 dataset, you really should be looking in the MCDS.
 
 Why do you think you need to
 know the ML2 volume?  ML2 datasets are catalogued on
 MIGRAT2.  Does the DSN show up in 3.4?
 What
 happens if you issue an HRECALL against the DSN?  If the
 migrated copy is valid, that should be all you need.  
 
 > -Original Message-
 > From: IBM Mainframe Discussion List
 [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Monday, June 20, 2016 9:35 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION - RECOVER DSN FROM
 ML2 VOLUME
 > 
 > Good
 Day To All,
 > 
 > I
 would like to recover a dsn which was migrated to ML2. 
 Because of a mistake in the
 > assigning
 of the management class no back up was taken.
 > 
 > I remember
 recovering a dsn under the same circumstances.  I remember
 locating the dsn in
 > the
 HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and
 the volser of
 > the ML2. (which  I found
 in column 77)
 > 
 > I
 browsed the online HSM.JOURNAL (using the first and second
 HLQ)  however I was
 > unable to locate
 the dsn.  My question is do I need to wait for the CDS
 Journal backup to be
 > run (which will
 execute tonight at 8 p.m) or is there something else I can
 try?
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Hallo to All,

The dsn was migrated about 2 years ago and for some reason it was deleted today 
(in error).  I am dusting off some old doc and as I had said earlier I am 
checking to see what I did.  Keep you all posted if I stumble on to something.


On Mon, 6/20/16, Lizette Koehler <stars...@mindspring.com> wrote:

 Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, June 20, 2016, 12:41 PM
 
 If your first statement
 is No BACKUP has been taken, then the file is most likely
 lost.
 
 When was the file
 migrated?
 
 Can you show us
 the results from a HLIST dsn(/) BOTH 
 
 It will help to know when it was migrated.
 
 CDS Backups and Journals can
 be performed anytime.  You just have to know what kind of
 performance impact will be felt while it is running
 
 
 Lizette
 
 
 > -Original
 Message-
 > From: IBM Mainframe
 Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On
 > Behalf Of willie bunter
 > Sent: Monday, June 20, 2016 9:35 AM
 > To: IBM-MAIN@LISTSERV.UA.EDU
 > Subject: DFHSM QUESTION - RECOVER DSN FROM
 ML2 VOLUME
 > 
 > Good
 Day To All,
 > 
 > I
 would like to recover a dsn which was migrated to ML2. 
 Because of a mistake
 > in the assigning
 of the management class no back up was taken.
 > 
 > I remember
 recovering a dsn under the same circumstances.  I remember
 locating
 > the dsn in the
 HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and
 the
 > volser of the ML2. (which  I found
 in column 77)
 > 
 > I
 browsed the online HSM.JOURNAL (using the first and second
 HLQ)  however I
 > was unable to locate
 the dsn.  My question is do I need to wait for the CDS
 > Journal backup to be run (which will
 execute tonight at 8 p.m) or is there
 >
 something else I can try?
 > 
 > Thanks.
 > 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN

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

DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME

[willie bunter]

Good Day To All,

I would like to recover a dsn which was migrated to ML2.  Because of a mistake 
in the assigning of the management class no back up was taken.

I remember recovering a dsn under the same circumstances.  I remember locating 
the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the 
volser of the ML2. (which  I found in column 77) 

I browsed the online HSM.JOURNAL (using the first and second HLQ)  however I 
was unable to locate the dsn.  My question is do I need to wait for the CDS 
Journal backup to be run (which will execute tonight at 8 p.m) or is there 
something else I can try?

Thanks.

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

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

[willie bunter]

Thanks for the suggestion.  I tried it out as a test and it worked.  The only 
drawback is that I will have to include the output of the job after the  
//SYSUT1 DD *

As a test I tried inserting the dsn as in the SYSUT1 DD * however it did not 
work. I got the folowing :

 DATA SET UTILITY - GENERATE
IEB311I CONFLICTING DCB PARAMETERS 

Here is the jcl I used:

/*
//STEP  EXEC  PGM=IEBGENER
//SYSUT2 DD DSN=SYS2.CNTL.SHR(XF),DISP=(MOD,CATLG),   
//  UNIT=SYSALLDA,SPACE=(500,(500,,5))
//SYSUT1 DD DSN=SYS2.XF,DISP=SHR  
//SYSPRINT  DD  SYSOUT=(,)
//SYSPRINT DD  SYSOUT=*   
//SYSIN   DD   *  
/*

On Fri, 4/29/16, R.S.  wrote:

 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, April 29, 2016, 5:06 PM
 
 W dniu 2016-04-29 o
 22:30, Paul Gilmartin pisze:
 > On
 2016-04-29, at 09:58, R.S. wrote:
  That deserves an SR.  Works
 in JCL; works everywhere else.  The statement is
  patently false.
 >>> No, it isn't. MOD is not
 allowed for *member* od PDS or PDSE.
 >>> MOD is allowed for PO dataset,
 i.e. for IEFBR14 MOD,DELETE
 >>>
 >>> Try IEBGENER  //SYSUT2 DD
 DSN=HLQ.SOME.PO(MEMBER),DISP=(MOD,CATLG)
 >>>
 > My test job
 step:
 > //STEP  EXEC  PGM=IEBGENER
 > //SYSUT2 DD
 DSN=(MEMBER),DISP=(MOD,CATLG),
 > //  UNIT=SYSALLDA,SPACE=(500,(500,,5))
 > //SYSUT1 DD *
 > 
    Test Data
 > //SYSPRINT 
 DD  SYSOUT=(,)
 > //SYSIN 
    DD  *
 > //*
 >
 > And log output:
 >
 > 14.10.00 JOB00158 
 -                                     
 -TIMINGS (MINS.)--                     
     -PAGING COUNTS
 > 14.10.00
 JOB00158  -STEPNAME PROCSTEP   
 RC   EXCP   CONN   
    TCB       SRB  CLOCK       
   SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
 > 14.10.00 JOB00158  -STEP           
      00     47     22 
      .00       .00 
    .0           116  BATCH   
     0     0     0 
    0
 > 14.10.00 JOB00158 
 IEF404I PDSMOD - ENDED - TIME=14.10.00
 >
 14.10.00 JOB00158  -PDSMOD   ENDED.  NAME-Paul
 Gilmartin       TOTAL TCB CPU TIME=      .00
 TOTAL ELAPSED TIME=    .0
 > 14.10.00
 JOB00158  $HASP395 PDSMOD   ENDED - RC=
 >
 > Works for me.
 You are right. Please rerun the job. I bet
 you'll get SB214 abend.
 My description
 was innacurate (I'm sorry for that!), however I meant
 MOD 
 as appending existing memebr. It is not
 possible.
 BTW: simple JCL workaound is to
 copy member to a PS, append it and then 
 overwrite the member (overwrite is possible,
 despite of PDS vs PDSE 
 internal processing,
 I mean what enduser see).
 
 Regarding SDSF, the forbiden DISP and DSORG
 combination can be result of 
 SDSF dialog
 logic, not the access method restriction.
 
 Unfortunately, it is possible
 to overwrite a member by mistake using the 
 dialog
 
 Regards
 -- 
 Radoslaw Skorupka
 Lodz,
 Poland
 
 
 
 
 
 
 --
 Tre tej wiadomoci moe
 zawiera informacje prawnie chronione Banku przeznaczone
 wycznie do uytku subowego adresata. Odbiorc moe by jedynie
 jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie
 jeste adresatem niniejszej wiadomoci lub pracownikiem
 upowanionym do jej przekazania adresatowi, informujemy, e
 jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne
 dziaanie o podobnym charakterze jest prawnie zabronione i
 moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy
 niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale
 usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane
 lub zapisane na dysku.
 
 This
 e-mail may contain legally privileged information of the
 Bank and is intended solely for business use of the
 addressee. This e-mail may only be received by the addressee
 and may not be disclosed to any third parties. If you are
 not the intended addressee of this e-mail or the employee
 authorized to forward it to the addressee, be advised that
 any dissemination, copying, distribution or any other
 similar activity is legally prohibited and may be
 punishable. If you received this e-mail by mistake please
 advise the sender immediately by using the reply facility in
 your e-mail software and delete permanently this e-mail
 including any copies of it either printed or saved to hard
 drive.
 
 mBank S.A. z siedzib
 w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
 www.mBank.pl, e-mail: kont...@mbank.pl
 Sd Rejonowy dla m. st. Warszawy XII Wydzia
 Gospodarczy Krajowego Rejestru Sdowego, nr rejestru
 przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug
 stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w
 caoci wpacony) wynosi 168.955.696 zotych.
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

[willie bunter]

Robert,

I tried out your recommendation but the member gets overriden.  Below is the 
display of the dsn"

Data set name  ===> 'SYS2.BATCH.JOBS.OUTPUT'
Member to use  ===> JOB03070
Disposition===> SHR(OLD, NEW, SHR, MOD) 

Management class ===>   (Blank for default management class)
Storage class===>   (Blank for default storage class)   
  Volume serial  ===>   (Blank for authorized default volume)   
  Device type===>   (Generic unit or device address)
Data class   ===>   (Blank for default data class)  
  Space units===> CYLS  (BLKS, TRKS, CYLS, BY, KB, or MB)   
  Primary quantity   ===> 1 (In above units)
  Secondary quantity ===> 5 (In above units)
  Directory blocks   ===>   (Zero for sequential data set)  
  Record format  ===> VBA   
  Record length  ===> 240   
  Block size ===> 3120  
Data set name type   ===> LIBRARY   (LIBRARY, blank, ... See Help for more) 
Extended attributes  ===>   (NO, OPT, or blank) 

On Mon, 5/2/16, Richards, Robert B. <robert.richa...@opm.gov> wrote:

 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Monday, May 2, 2016, 5:31 AM
 
 Willie,
 
 According to the HELP,  the
 dataset name type defaults to the characteristics above. You
 did not specify directory blocks, so it assumes physical
 sequential (PS). Member names are invalid for PS datasets.
 Either add directory blocks or specify LIBRARY as the
 dataset name type.
 
 Bob
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Friday,
 April 29, 2016 1:24 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM
 SDSF
 
 This is what I have. 
 In the Data set name type   ===>         
 it is blank as shown below.
 
 Data set name  ===>
 ''SYS2.BATCH.JOBS.OUTPUT' Member to use 
 ===> JOB06703 Disposition    ===> SHR       
 (OLD, NEW, SHR, MOD)                       
    
                        
                                        
               
 Management class 
    ===>           (Blank for default management
 class) Storage class        ===>       
    (Blank for default storage class)
  
 Volume serial      ===>           (Blank for
 authorized default volume)
   Device type 
       ===>           (Generic unit or device
 address) Data class           ===>       
    (Blank for default data class)
  
 Space units        ===> CYLS      (BLKS, TRKS,
 CYLS, BY, KB, or MB)
   Primary
 quantity   ===> 1         (In above units)
   Secondary quantity ===> 5     
    (In above units)
   Directory
 blocks   ===>           (Zero for sequential
 data set)
   Record format      ===>
 VBA
   Record length      ===> 240
   Block size         ===> 3120 Data
 set name type   ===>           (LIBRARY, blank,
 ... See Help for more) Extended attributes  ===>     
      (NO, OPT, or blank)                   
    
 
 
 On Fri, 4/29/16, Richards, Robert B. <robert.richa...@opm.gov>
 wrote:
 
  Subject: Re: SAVING
 JOB OUTPUT IN A PDSE FROM SDSF
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Friday, April 29, 2016, 7:50 AM
  
  Data set name  ===>
  'ABCDE.FGHIJK.LMNOP'           
          
          
  Member to use  ===>
 
 QRSTUV                                 
  
             
 
 Disposition
  ===> NEW        (OLD,
 NEW, SHR, MOD)           
         
    
             
 
                                      
  
                        
  Management
  class 
    ===>
     (Blank for default
 management class)  Storage class             
 ===>
          (Blank for default
 storage class) 
     
   
 Volume serial
     ===>       
    (Blank for
  authorized default
 volume)
    Device type
   
           ===>           (Generic
  unit or device address)
 
 Data
  class                 
 ===>
     (Blank for default data
 class)
    Space units             
 ===>
  CYLS   (BLKS, TRKS, CYLS, BY,
 KB, or MB) 
     
   
 Primary quantity
     ===> 25     
   (In above units)     
           
       
    Secondary
 
 quantity ===> 5          (In above units)     
  
                
 
   Directory blocks
     ===> 45   
     (Zero for sequential
  data set) 
    <==

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

[willie bunter]

This is what I have.  In the Data set name type   ===>  it is blank as 
shown below.

Data set name  ===> ''SYS2.BATCH.JOBS.OUTPUT'                                   
 
Member to use  ===> JOB06703                                                 
Disposition    ===> SHR        (OLD, NEW, SHR, MOD)                           
                                                                              
Management class     ===>           (Blank for default management class)      
Storage class        ===>           (Blank for default storage class)         
  Volume serial      ===>           (Blank for authorized default volume)     
  Device type        ===>           (Generic unit or device address)          
Data class           ===>           (Blank for default data class)            
  Space units        ===> CYLS      (BLKS, TRKS, CYLS, BY, KB, or MB)         
  Primary quantity   ===> 1         (In above units)                          
  Secondary quantity ===> 5         (In above units)                          
  Directory blocks   ===>           (Zero for sequential data set)            
  Record format      ===> VBA                                                 
  Record length      ===> 240                                                 
  Block size         ===> 3120                                                
Data set name type   ===>           (LIBRARY, blank, ... See Help for more)   
Extended attributes  ===>           (NO, OPT, or blank)                       


On Fri, 4/29/16, Richards, Robert B. <robert.richa...@opm.gov> wrote:

 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF
 To: IBM-MAIN@LISTSERV.UA.EDU
 Received: Friday, April 29, 2016, 7:50 AM
 
 Data set name  ===>
 'ABCDE.FGHIJK.LMNOP'                     
         
 Member to use  ===>
 QRSTUV                                   
            
 Disposition   
 ===> NEW        (OLD, NEW, SHR, MOD)           
            
            
                                        
                       
 Management
 class     ===>       
    (Blank for default management class)  
 Storage class              ===>   
         (Blank for default storage class) 
    
   Volume serial       
    ===>           (Blank for
 authorized default volume) 
   Device type 
             ===>           (Generic
 unit or device address)      
 Data
 class                  ===>       
    (Blank for default data class)        
   Space units              ===>
 CYLS   (BLKS, TRKS, CYLS, BY, KB, or MB) 
    
   Primary quantity 
    ===> 25        (In above units)     
                 
   Secondary
 quantity ===> 5          (In above units)       
               
   Directory blocks 
    ===> 45        (Zero for sequential
 data set)     <= Did you specify
 directory blanks???   
   Record
 format       ===> FBA               
                              
   Record length        ===> 133     
                                    
    
   Block size         
      ===>                       
                          
 Data set name type  ===>       
    <=== Do you have this value
 specified???
 Extended attributes  ===> 
          (NO, OPT, or blank)           
        
 
 -----Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of willie bunter
 Sent: Friday,
 April 29, 2016 7:45 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM
 SDSF
 
 Lizette,
 
 I tried your suggestion using
 NEW but it doesn't work.  I get the message MEMBER NAME
 NOT ALLOWED
 
 I hit the PF1
 option but it wasn't much help.   
 
 On Thu, 4/28/16, Lizette Koehler <stars...@mindspring.com>
 wrote:
 
  Subject: Re: SAVING
 JOB OUTPUT IN A PDSE FROM SDSF
  To: IBM-MAIN@LISTSERV.UA.EDU
  Received: Thursday, April 28, 2016, 7:08 PM
  
  When you use XDC and NEW
  it will indicate if the member already
 exists.
  
  You should try
 this and see if
  it works.
 
 
  I find trying
  SHR, OLD
 and NEW on  a PDS that will not matter if it is  over
 written a good thing to try to understand how things 
 work.
  
  Also, you could
 press
  PF1 (HELP) and see what the HELP
 panel states.
  
  Lizette
  
  
  >
 -----Original Message-
  > From: IBM
 Mainframe Discussion List
  [mailto:IBM-MAIN@LISTSERV.UA.EDU]
  On
  > Behalf Of willie
 bunter
  > Sent: Thursday, April 28, 2016
 4:00 PM  > To: IBM-MAIN@LISTSERV.UA.EDU 
 > Subject: SAVING JOB OUTPUT IN A PDSE FROM  SDSF 
 >  > Hallo  All,  >  > I need your 
 suggestions.  I am savings job output in a PDSE using 
 SDSF.  The  > member name I use is the  job number
 e.g.
  > Member to use  ===>
  JOB067XX
  >
  > I am
  afraid that some
 where down the line I could overwrite a  mem