>It used to be the case that RACF UPDATE access to all catalogs was
>always required to make catalog changes. At somewhere along the line
>this SMS exception was documented as an enhancement with MVS release
>migration docs.
I missed this enhancement. Thanks for the update.
--
Peter Hunkeler
Cred
ssing the catalog (see your ICH408I).
>
> The user is not permitted UPDATE to data set CATALOG.PLEXBDZ3.TSO,
> at least in the GDG case. And I can't imagine why the update should
> succeed when defining the VSAM data set *when* it will be cataloged
> in the same catalog.
This pr
On 03/03/2011 02:13 AM, ibmnew wrote:
> Hi all
>
> We defined a VSAM file and a GDG base using a user id DBJMP05.
> The prefix of DBJMP05 is managed by SMS
> SMS routing
> SC :
> FILTLIST TSOUSERS INCLUDE(DBJMP*)
>
> WHEN&HLQ =&TSOUSERS
>
Can you try to define a GDG named
DBJMP05.BDZ3.GDG
and can you try to define a VSAM data set named
DBJMP05.FAS.VSAM
What happens?
--
Peter Hunkeler
CREDIT SUISSE AG
--
For IBM-MAIN subscribe / signoff
>There are only RACF profiles DBJMP05.** for DBJMP05.BDZ3 and
DBJMP05.FAS.
This is not of interest to the problem. The access was denied when
accessing the catalog (see your ICH408I).
The user is not permitted UPDATE to data set CATALOG.PLEXBDZ3.TSO,
at least in the GDG case. And I ca
Lizette
There are only RACF profiles DBJMP05.** for DBJMP05.BDZ3 and DBJMP05.FAS.
Thanks a lot!
Jason Cai
> Our shop is RACF.
> It is single level alias
> Our shop is z/OS 1.11. the image is a single image.
>
> DBJMP05.BDZ3.MAN1 catalog to the same catalog as the GDG.
> Our shop is RACF.
> It is single level alias
> Our shop is z/OS 1.11. the image is a single image.
>
> DBJMP05.BDZ3.MAN1 catalog to the same catalog as the GDG.
> Thanks a lot!
> Jason Cai
>
> > DEFINE GDG (NAME(DBJMP05.FAS.SE.FMLX.HIST)
Our shop is z/OS 1.11. the image is a single image.
Thanks a lot!
Hi all
Our shop is RACF.
It is single level alias
DBJMP05.BDZ3.MAN1 catalog to the same catalog as the GDG.
Thanks a lot!
Jason Cai
> DEFINE GDG (NAME(DBJMP05.FAS.SE.FMLX.HIST) -
>LI
Hi all
Our shop is RACF.
It is single level alias
DBJMP05.BDZ3.MAN1 catalog to the same catalog as the GDG.
Thanks a lot!
Jason Cai
> DEFINE GDG (NAME(DBJMP05.FAS.SE.FMLX.HIST) -
>LIMIT(03) -
>
> DEFINE GDG (NAME(DBJMP05.FAS.SE.FMLX.HIST) -
>LIMIT(03) -
>NOEMPTY-
>SCRATCH )
>
> The return is 12
>
&
>ICH408I USER(DBJMP05 ) GROUP(#TMPUG ) NAME(APPL MAINTENANCE
> CATALOG.PLEXBDZ3.TSO CL(DATASET ) VOL(BD3CT1)
> INSUFFICIENT ACCESS AUTHORITY
> FROM CATALOG.PLEXBDZ3.TSO (G)
> ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ )
Hi all
We defined a VSAM file and a GDG base using a user id DBJMP05.
The prefix of DBJMP05 is managed by SMS
SMS routing
SC :
FILTLIST TSOUSERS INCLUDE(DBJMP*)
WHEN &HLQ = &TSOUSERS
SET &STORCLAS = 'SCSTAND'
Running z/OS V1.11
I thought I remembered that there was suppose to be a change soon to allow you
to read the GDG in reverse order when using the base. However, after scanning
the manuals and archives I have seen rexx utilities to do this.
So, was there suppose to be a way to change the way
Fred,
This is NOT a ThruPut Manager problem.
If you bypass ThruPut Manager you will get ...
IEF286I IEFBR14 STEPNAME DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME
ThruPut Manager is simply reporting what IBM would have report.
The 1st step that references that GDG, via the relative generation
You could add an IEBGENER Step to copy the GDG.DSNAME.G0002V00 back into
a dataset named GDG.DSNAME.G0001V00 if you like.
//GDGEXEC PGM=IEBGENER,COND=(0,NE)
//SYSOUT DD SYSOUT=(,),OUTPUT=(*.JCL)
//SYSPRINT DD SYSOUT=(,),OUTPUT=(*.JCL)
//SYSUT1 DD DSN=GDG.DSNAME(+1),DISP=SHR
Date: 01/18/2011 03:48 PM
Subject:Re: GDG Question
Sent by:IBM Mainframe Discussion List
There are too many JCL changes in other batch jobs, to change this
to a non-GDG file.
Reusing the same file without deleteing and reallocating the data set is
an
option.
Thank you for your
There are too many JCL changes in other batch jobs, to change this
to a non-GDG file.
Reusing the same file without deleteing and reallocating the data set is an
option.
Thank you for your responses, we will take them into consideration
On Tue, 2011-01-18 at 13:27 -0500, Tom Marchant wrote:
> If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1)
> will be GDG.DSNAME.G0002V00 for any reference in that job.
The GDG name table (GDGNT, mapped by IEFZB429, pointed to from the JCT)
contains a list of GDG base names, and
I don't think you need either the delete or the allocate.
Just use DSN=GDG(0),DISP=OLD for the step that writes data into the GDG.
DISP=OLD and open for output will allow you to rewrite the whole dataset
starting at the beginning.
OTOH if you are truly just appending data (and don&#x
ainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Kaptein
> > Sent: Tuesday, January 18, 2011 11:29 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: GDG Question
> >
> > Hello,
> >
> > I have a question on GDGs
> > We have a
My first thought is why use a gdg at all in this situation? Wouldn't a
plain data set work just as well.
Second is GDG's (relative and absolute) are updated at the END of the job,
NOT the end of each step (as best I remember). Relative (0) will be G0001
throughout the job, so (+
It's unclear to me why you want to use a GDG at all. Or why you bother
deleting and recreating it.
Your step (3) could simply be writing into GDG.NAME(0) with IEBGENER using
DISP=OLD and with SYSUT1 as DD DUMMY and you'd accomplish pretty much the
same thing as a delete/allocate.
Using DSN=GDG.DSNAME(0),DISP=(NEW,CATLG) instead of (+1) is not valid
on our system, as we use ThruPut Manager.
This JCL results in the following error message
DTMI DD1 - DISP FIELD INCOMPATIBLE WITH DSNAME
--
For I
On Tue, 18 Jan 2011 11:29:25 -0600, Fred Kaptein wrote:
>is there any way to
>completely delete GDG.DSNAME(0) and allocate GDG.DSNAME(+1) where
>GDG.DSNAME(+1) will remain with the name GDG.DSNAME.G0001V00
No.
If GDG.DSNAME(0) is GDG.DSNAME.G0001V00, then GDG.DSNAME(+1)
will be GDG.DSNAME.G0002V
a.edu] On Behalf Of Fred Kaptein
> Sent: Tuesday, January 18, 2011 11:29 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: GDG Question
>
> Hello,
>
> I have a question on GDGs
> We have a GDG data set GDG.DSNAME.G0001V00 and append data into
> this data set throughout the day.
>
Hello,
I have a question on GDGs
We have a GDG data set GDG.DSNAME.G0001V00 and append data into
this data set throughout the day.
We then run a batch job where we do the following:
1. Read GDG.DSNAME(0)
2. Delete GDG.DSNAME(0) as follows
//DELETE EXEC PGM=IEFBR14
//DD1
;m beginning to feel that by
continuing to persist that I am being unreasonable.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Brian Kennelly
Sent: Wednesday, September 08, 2010 5:50 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: S737 Aben
On Wed, Sep 8, 2010 at 15:53, Tabor, Rich wrote:
> The short answer I think is yes - yes it is TWS's fault. Yes, as
> suggested, if I specify the absolute GDG data set name in the JCL, I see
> only the enqueue for the absolute GDG data set and no enqueue for the GDG
> base. And
The short answer I think is yes - yes it is TWS's fault. Yes, as suggested, if
I specify the absolute GDG data set name in the JCL, I see only the enqueue for
the absolute GDG data set and no enqueue for the GDG base. And MVS/DFP does
not allow the data set to be deleted by another tso
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tabor, Rich
> Sent: Wednesday, September 08, 2010 1:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: S737 Abends, Deleted GDG Data Sets and TWS
>
> We experience th
We experience this S737 abend maybe once every couple of years where a
JCL-allocated GDG actively being updated by one batch job can be deleted by a
TSO user or another batch job. We found it very hard to believe this could
even be possible but we did recreate the problem and found that our
Thanks for that. Downloaded it but apart from the 32K restriction I don't
think it will do the job. Looking at the documentation it seems to have
originally been written for sequential datasets and then updated to only do
PDS'es.
I've tried a couple of other options. ICETOOL has the COUNT option a
---
I found a number of tapes which are 32k blocking and used IEBCOMPR but it
really doesn't give decent enough information and didn't work on
multi-volume datasets.
For tapes that are single volume, single dataset then the informa
lly don't write anything over 32K anyway.
>
>
>
>Perhaps a call to IBM might result in a fix for you and for us too. ;-)
>
>
>
>Thanks,
>
>
>
>Linda
>
>
>- Original Message -
>From: "Sebastian Welton"
>To: IBM-MAIN@bama.ua.edu
>
ian Welton"
To: IBM-MAIN@bama.ua.edu
Sent: Friday, July 9, 2010 1:14:33 AM GMT -08:00 US/Canada Pacific
Subject: Re: Copy tape GDG
Reply to myself, from the IEBCOMPR documentation:
The block sizes cannot exceed 32760 bytes.
Seb
>Many thanks for pointing that out. I did actuall
Reply to myself, from the IEBCOMPR documentation:
The block sizes cannot exceed 32760 bytes.
Seb
>Many thanks for pointing that out. I did actually remember reading the
>original article but didn't think anything about it. So I'm working on it
>now but of course I get S013-E1 abends as the blksi
ma.ua.edu
>Sent: Thursday, July 8, 2010 11:51:03 AM GMT -08:00 US/Canada Pacific
>Subject: Re: Copy tape GDG
>
>Thanks for that but, sadly, not an option due to not wanting to get an
>external product. This is in fact a follow-up from my original posting:
>
>http://bama.ua.ed
refernences too.
HTH,
Linda Mooney
- Original Message -
From: "Sebastian Welton"
To: IBM-MAIN@bama.ua.edu
Sent: Thursday, July 8, 2010 11:51:03 AM GMT -08:00 US/Canada Pacific
Subject: Re: Copy tape GDG
Thanks for that but, sadly, not an option due to not want
gt;
>John Donnelly
>National Semiconductor Corporation
>2900 Semiconductor Drive
>Santa Clara, CA 95051
>
>408-721-5640
>408-721-8364 Cell
>cjp...@nsc.com
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of
cates to me:
- that the programmers may have hardcoded the actual dataset name in their
JCL, or wherever, which would cause problems. From what I gather about this
data is that they'll grab a certain GDG and update it or replace ti with
another one so as you can see, keeping the original GDG
AM
To: IBM-MAIN@bama.ua.edu
Subject: Copy tape GDG
I need to copy a number of tape datasets which are GDGs and just to clear my
mind I just want to clarify that I'm doing this correctly (I have tested it
and it all seems to be working just fine but...)
Basically, I'm doing the followi
One clarifying comment: When a GV01 instance of a GDG dataset is
cataloged, the system uncatalogs and scratches the GV00 version, so
doing that as a separate step becomes unnecessary (and the explicit
DELETE in the DD is redundant). At least that's what happens for a DASD
GDS when th
I was wondering if you could use the V00 part of the GDG to do this a bit
simpler.
With a GVxx the Vxx part indicates the version but behaves like the
base.
So if I had a G0001V00 and I could copy and created a G0001V01. When the
dataset was called in with (0) it would know that it used the
I need to copy a number of tape datasets which are GDGs and just to clear my
mind I just want to clarify that I'm doing this correctly (I have tested it
and it all seems to be working just fine but...)
Basically, I'm doing the following:
- get fully qualified DSN, i.e. hlq.some.stuff.G0001V00
- u
But the approach below has a clear drawback: the programmer has to remember
that what has been written to MYUSER.GDG(+1), is later read by the 'put' command
referencing MYUSER.GDG(0). Confusing ...
Instead, if you code your ftp step as follows:
//STP030 EXEC PROC=FTP,TO='windowsserver'
//SYSPRINT
On Thu, 27 May 2010 22:13:57 -0400, larry macioce
wrote:
>I am sorry if I didnt make myself clear, we are trying to put a gdg to a
>windows server. I understand that the way I am trying to transmit the file
>in the jcl is failing,but I was wondering if I had some syntax wrong bu
My understanding of the OP's original question was about receiving
message EZA2553W when attempting a PUT command with the localfile name
specified as a GDG(+1). I assume his job went something like this:
STEP A - Create SYP.TEST.FILE(+1)
Result - IGD107I SYP.TEST.FILE.G00
I often placed (+1) GDGs on Win servers for PDFs, accounting data, bank
deposit/transfer, payroll deduction, etc.
Yes, the FTP step could have been a separate job using a (0) generation, but
not mandatory. I used the correct combination of DISPs and sometimes IFs in
the JCL to keep the GDG
Create a new generation of a GDG then FTP it to the windows box in the
same job? We do this on a regular basis.
Rex
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of John Kelly
Sent: Friday, May 28, 2010 10:07 AM
To: IBM-MAIN@bama.ua.edu
we are trying to put a gdg to a windows server.
You loss me there. IF the server(mainframe) is putting to Windows, why
would you send a new DSN. I could see (-1) or (0) but putting (+1) seems
wrong.
Jack Kelly
202-502-2390 (Office
I stand corrected, sorry if I misled anyone.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Porowski, Ken
Sent: Thursday, May 27, 2010 5:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] ftping a gdg from the z box
FTP does not
On Thu, 2010-05-27 at 17:53 -0400, larry macioce wrote:
> we are trying to ftp(put) a gdg using the (+1) notation
Try:
put //dd:sysut1 destfilename
//SYSUT1 DD DSN=YOUR.GDS(+1),DISP=(OLD,PASS)
--
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.
Is the +1 GDG on the Mainframe or the Windows system?
How is the process setup?
Are using one step in JCL on the mainframe to create the +1 GDG and then
passing that GDG to the FTP step? If so, then Walter's suggestion should work.
Lizette
>
> > I am sorry if I didnt make my
> I am sorry if I didnt make myself clear, we are trying to put a gdg to a
> windows server.
you might take advantage of the ftp DD support (or whatever it is called):
//FTP EXEC PGM=FTP,PARM='(EXIT'
//SYSPRINT DD SYSOUT=*
//
There was another comment that was actually correct when you FTP a GDG it
the windows serve whether it was or wasn't created in the JCL stream with
the FTP it will always be the (0) generation. This works in my FTP
PUT 'SYS3.TEST.DATA(0)' test.txt
Michael Saraco
Systems Con
I am sorry if I didnt make myself clear, we are trying to put a gdg to a
windows server. I understand that the way I am trying to transmit the file
in the jcl is failing,but I was wondering if I had some syntax wrong but I
feel Micheal may have hit it on the head, that ftp and the put do not
>From: larry macioce
>To: IBM-MAIN@bama.ua.edu
>Date: 05/27/2010 04:54 PM
>Subject: ftping a gdg from the z box
>Sent by:IBM Mainframe Discussion List
>
>
>
>we are trying to ftp(put) a gdg using the (+1) notation. The thing fails
>everytime w
You can FTP a GDG If you are creating the GDG in the same JCL stream it
will be (+1) if the GDG is created in a different job it will be (0).
There is already a response for FTPing into the GDG.
Michael Saraco
Systems Consultant
303-838-3374 x115
Cell 507-525-0530
From: larry macioce
-file-name 'GDG.DATASET(0)'
Natarajan
On 05/27/2010 02:53 PM, larry macioce wrote:
we are trying to ftp(put) a gdg using the (+1) notation. The thing fails
everytime with a eza2253(I think) I can't email from work so I am trying to
remember the code.
I looked the error up and it showed it
Mace,
Two things occur to me immediately:
1) Are you sure that you have defined the GDG in the catalog? FTP can create a
new GDS but not the GDG.
2) If the GDS is non-SMS, have you defined the Model-DSCB in the FTP Data that
is being used?
Here is a snippet (rather long) from the 1.9
FTP does not understand GDG's you have to use the fully qualified name
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of larry macioce
Sent: Thursday, May 27, 2010 5:54 PM
To: IBM-MAIN@bama.ua.edu
Subject: [IBM-MAIN] ftping a gdg from
we are trying to ftp(put) a gdg using the (+1) notation. The thing fails
everytime with a eza2253(I think) I can't email from work so I am trying to
remember the code.
I looked the error up and it showed it cant find the dsn we are asking for.
We have tried to tick mark it (ie 'dsn.gd
Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Patrick Lyon
Sent: Friday, May 07, 2010 12:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: URGENT z/OS 1.11 GDG Deferred Rollin Data Loss
On Fri, 7 May 2010 12:18:57 -0400, Mark Jacobs wrote:
>The apar doesn't say that there&
On 05/07/10 12:21, Patrick Lyon wrote:
On Fri, 7 May 2010 12:18:57 -0400, Mark Jacobs
wrote:
The apar doesn't say that there's an fix available but I just opened up
an ETR with IBM to see if something is available.
--
Mark Jacobs
Time Customer Service
Tampa, FL
Local fix is to "S
GDS_RECLAIM SMS option to NO."
The APAR:
APAR Identifier .. OA32968 Last Changed 10/05/07
Z/OS 1.11 GDG RECLAIM IGD17356I NOT OVER WRITING OLD DATA IN
RECLAIMED DATA SET. NEW DATA LOST EVEN THOUGH RC=0.
Symptom .. IN INCORROUT Status ... OPEN
On 05/07/10 12:07, Darth Keller wrote:
We just ran into this issue. If a job tries to create a new GDG entry
that matches a GooVoo that is in deferred roll in status then you will
experience data loss. The old GooVoo does not get overwritten but is
cataloged as the new
>>We just ran into this issue. If a job tries to create a new GDG entry
that matches a GooVoo that is in deferred roll in status then you will
>>experience data loss. The old GooVoo does not get overwritten but is
cataloged as the new entry.
>>APAR OA32968 has been created to
We just ran into this issue. If a job tries to create a new GDG entry that
matches a GooVoo that is in deferred roll in status then you will experience
data loss. The old GooVoo does not get overwritten but is cataloged as the new
entry.
APAR OA32968 has been created to resolve this issue
We just ran into this issue. If a job tries to create a new GDG entry that
matches a GooVoo that is in deferred roll in status then you will experience
data loss. The old GooVoo does not get overwritten but is cataloged as the new
entry.
APAR OA32968 has been created to resolve this issue
=*
//SYSINDD *
TITLELINE='DELETE ALL GDG BASE ENTRIES THAT ARE EMPTY'
DEFAULT ENABLE=(GDGBASEONLY,ALLFILTER)
XSELECT GDGENTRY=0,XDSN=XYZ.**
REPORT FIELD=(GDGBASE,GDGFLAG
: IBM-MAIN@bama.ua.edu
Subject: Remove Empty GDG Base
Is there a utility that will scan the catalogs and remove all (or selected)
empty GDG bases?
For example: remove all empty GDG bases for hi-level xyz.
--
For IBM-MAIN subscribe
Pat Monk pisze:
Is there a utility that will scan the catalogs and remove all (or selected)
empty GDG bases?
For example: remove all empty GDG bases for hi-level xyz.
It's quite easy to write some REXX script analyzing "LISTCAT LEVEL(hlq)"
output. For GDG entries it can g
On Thu, 7 Jan 2010 15:08:47 -0600, Pat Monk wrote:
>Is there a utility that will scan the catalogs and remove all (or selected)
>empty GDG bases?
>
>For example: remove all empty GDG bases for hi-level xyz.
>
Not that I know of, but the Catalog Search Interface could be used
Is there a utility that will scan the catalogs and remove all (or selected)
empty GDG bases?
For example: remove all empty GDG bases for hi-level xyz.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
> Of Jacky Bright
> Sent: Wednesday, 25 November 2009 7:49 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Extracting GDG Base
>
> Business Operation Department has requ
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jacky Bright
>> Sent: Tuesday, November 24, 2009 2:49 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Extracting GDG Base
>>
>> Business Operation Department has requested to extract all
>> GDG base dataset
>> nam
On Tue, 24 Nov 2009 15:08:23 -0600, McKown, John
wrote:
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jacky Bright
>> Sent: Tuesday, November 24, 2009 2:49 PM
>> To: IBM-MAIN@bama.ua.edu
&
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jacky Bright
> Sent: Tuesday, November 24, 2009 2:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Extracting GDG Base
>
> Business Operation Department has request
Business Operation Department has requested to extract all GDG base dataset
names from the system. Is there any utility by which I can have these
details from the catalog ?
JAcky
--
For IBM-MAIN subscribe / signoff / archive
4000 * ...*
>
> If you can find any problem in it, please let me know.
> Thanks a lot!
Hi George:
I suspect you have an SMS GDG defined with limit 2 and NOSCRATCH.
You have two GDS entries in the BASE, 4 and 5. And one data set
rolled off
but cataloged as G0003V00. So the phen
m CSI are defined by the CSI interface
and may produce different results than the prior generic
LOCATE interface rules."
The OP implied that he was using the "generic" SVC26 LOCATE
which, from the quoted paragraph above, seems not to have changed.
Therefore, presumably, GDG
On Nov 23, 2:18 am, George wrote:
> Thanks a lot for your answers.
>
> I still don’t understand why I can’t see all datasets when using
> 'HLQ.TEST.G' mask. I tried to find any IBM documentation about it but
> without any success. Don’t you know where I can find more info about
> it?
George:
It mi
M documentation about it
but
> > without any success. Don't you know where I can find more info about
> > it?
>
>
> > > Date: Fri, 20 Nov 2009 15:49:59 +0100
> > > From: kees.vern...@klm.com
> > > Subje
I can’t see all datasets when using
> 'HLQ.TEST.G' mask. I tried to find any IBM documentation about it but
> without any success. Don’t you know where I can find more info about
> it?
> > Date: Fri, 20 Nov 2009 15:49:59 +0100
> > From: kees.vern...@klm.co
On Fri, 2009-11-20 at 08:53 -0500, Vernooij, CP - SPLXM wrote:
> This is the case since z/OS 1.8. GDG members are not kept in numerical
> order in the catalog anymore and therefor not returned in numerical
> order either. The only way to get them returned in numerical order is by
> c
Yes, until z/OS 1.8.
Kees.
"J R" wrote in message
news:...
> I meant to add that it's been this way since the '60s.
>
>
>
>
> > Date: Fri, 20 Nov 2009 09:09:51 -0500
> > From: jayare...@hotmail.com
> > Subject: Re: SVC 26 (l
I meant to add that it's been this way since the '60s.
> Date: Fri, 20 Nov 2009 09:09:51 -0500
> From: jayare...@hotmail.com
> Subject: Re: SVC 26 (locate) with GDG datasets
> To: IBM-MAIN@bama.ua.edu
>
> GDG member numbers are complemented in the catalog.
&g
GDG member numbers are complemented in the catalog.
This ensures that the latest generation (+0) is always
located first.
> "George" wrote in message
> news:
> ...
> Hello,
> I have a question about Locate macro (SVC 26) and GDG datasets. For
> example I hav
"George" wrote in message
news:
...
Hello,
I have a question about Locate macro (SVC 26) and GDG datasets. For
example I have these datasets:
HLQ.TEST
HLQ.TEST.G0003V00
HLQ.TEST.G0004V00
HLQ.TEST.G0005V00
When I use mask 'HLQ.TEST' the output from SVC 26 is:
HLQ.TE
On Tue, 15 Sep 2009 11:38:07 -0700, John Dawes
wrote:
>I have a problem trying to compile a list of ROLLED-OFF gdg
dsns which were created over the past 3 years. We noticed that the
dsns were not being deleted because of a NOSCRATCH option used
when the gdg base was created by the user.
I have a problem trying to compile a list of ROLLED-OFF gdg dsns which were
created over the past 3 years. We noticed that the dsns were not being deleted
because of a NOSCRATCH option used when the gdg base was created by the user.
I ran a LISTCAT of the catalog and did a FIND command for
On 2009-08-07 at 11:16, concerning "Report of "NOSCRATCH" GDG dsn's",
Esmie Moo wrote to IBM-Main:
> [SNIP] produce a list of GDG disk dsns that were defined with
> "NOSCRATCH" parM? [snip] I looked at DFDSS & FDR (FDREPORT) [snip]
FDReport :
NAM
Is there a way to produce a list of GDG disk dsns that were defined with "NOSCRATCH" parM? We have a problem with disk space and it was noticed that several GDG dsns that were rolled off but were still on the dasd
Thanks Bob for your help as well.
--- On Sat, 8/8/09, Lester, Bob wrote:
From: Lester, Bob
Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:48 AM
> -Original Message-
> From: IBM Mainframe Discussion Li
John,
I tried out your suggestion and it works. Thanks.
--- On Sat, 8/8/09, McKown, John wrote:
From: McKown, John
Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:37 AM
> -Original Message-
> Fro
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Friday, August 07, 2009 10:46 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
>
> I ran the job but recei
I ran the job but received errors which would explain why. Just to confirm
using the SET MODE=SIMULATE command, nothing is touched or updated.
Right?
--- On Sat, 8/8/09, Lester, Bob wrote:
From: Lester, Bob
Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
To: IBM-MAIN@b
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Friday, August 07, 2009 10:37 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
>
> Bob,
>
> Tha
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of esmie moo
> Sent: Friday, August 07, 2009 11:15 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
>
> John,
>
>
, Bob
Subject: Re: REPORT OF "NOSCRATCH" GDG DSNS
To: IBM-MAIN@bama.ua.edu
Received: Saturday, August 8, 2009, 4:25 AM
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of esmie moo
> Sent: Friday, August 07, 2009 1
101 - 200 of 541 matches
Mail list logo
