View previous topic :: View next topic
|
Author |
Message |
HenriqueS
New User
Joined: 17 Feb 2007 Posts: 30 Location: Brazil
|
|
|
|
Hello,
I need to copy from Unix System Services a file to a GDG.
As far that I noticed, I cannot refer to GDGs? What would be an work-around?
# tso -t "OGET '/tmp/myfile.67109482.txt' 'FILE.MYGDG(+1)'"
OGET '/tmp/myfile.67109482.txt' 'FILE.MYGDG(+1)'
IKJ56709I INVALID DATA SET NAME, 'FILE.MYGDG(+1)'
BPXF101E RETURN CODE 00000004 RECEIVED DURING PARSING OF THE COMMAND.
RC(12) |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
Does it work when you refer to the absolute generation instead of the relative generation? |
|
Back to top |
|
|
HenriqueS
New User
Joined: 17 Feb 2007 Posts: 30 Location: Brazil
|
|
|
|
If I refer to a absolute DDNAME it works (it truncates the file contents, but if I prealloc it correctly I guess it will work allright).
But, taking from this, how I "guess" the next available GDG name? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
If you look in the Unix System Services User's Guide manual, you will find the syntax for the OGET command. The syntax explicitly states that having parentheses after the data set name is giving a PDS member name. There is no way to use OGET to reference a relative generation, period.
You will have to do an OGET into a data set, then use an IEBGENER (or your choice) step to copy the data set to the relative generation of the GDG. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Wouldn't OCOPY be the preferred command here?
Quote: |
To copy a data set into a file and use data definition names (ddnames) instead of a data set name and path name, use the OCOPY command.
|
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
OGET or OCOPY either will work. OCOPY references DD names, hence can deal with relative generations whereas OGET references the file name (or data set name) directly and hence cannot. |
|
Back to top |
|
|
HenriqueS
New User
Joined: 17 Feb 2007 Posts: 30 Location: Brazil
|
|
|
|
Well, I need to input the commands from the Unix shell, because a previous process gives to me the HSF filename (the script will contain a variable that will be replace at runtime).
So I tried this...
1st - Allocate source:
Code: |
tso -t "ALLOCATE DDNAME(INHFS) PATH('/spb/tmp/ARASEL003.67109482.D')"
|
OK...remember the HFS filename above changes on every execution, the script will contain a variable inside of the PATH() param...
2nd - Allocate destination:
Code: |
tso -t "ALLOCATE DDNAME(OUTMVS) DSNAME('PSTR.ASEL003H(+1)')"
|
NOT OK...see the output:
Code: |
ALLOCATE DDNAME(OUTMVS) DSNAME('PSTR.ASEL003H(+1)')
IKJ56709I INVALID DATA SET NAME, 'PSTR.ASEL003H(+1)'
IKJ56701I MISSING DATA SET NAME OR *+
IKJ56701I MISSING NAME OF DATA SET TO BE ALLOCATED
RC(12)
|
3rd - After that my idea was to finnaly perform the OCOPY:
Code: |
tso -t "OCOPY INDD(INHFS) OUTDD(OUTMVS)"
|
Any tips to help ont he 2nd step ? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Unbalanced right parenthesis? |
|
Back to top |
|
|
HenriqueS
New User
Joined: 17 Feb 2007 Posts: 30 Location: Brazil
|
|
|
|
Where ? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Desculpe Henrique, a quick look and it looked odd in the message.
Searching for the message about invalid dataset, it might be that TSO is thinking, again, that the piece in parentheses is a member of a pds, so invalid for a member. |
|
Back to top |
|
|
HenriqueS
New User
Joined: 17 Feb 2007 Posts: 30 Location: Brazil
|
|
|
|
My guess is that GDGs can only be referenced from inside a JCL...maybe isn´t JES2 the one responsible for supplying the sequence number ?
Still, I tried the apprach of copying the HFS file into a fixed DSNAME, and then copying it later to the GDG group. But the invocation of the commands under OMVS seems a bit odd:
Code: |
# tso -t "ALLOCATE DDNAME(INHFS) PATH('/spb/tmp/ARASEL003.67109482.D')"
ALLOCATE DDNAME(INHFS) PATH('/spb/tmp/ARASEL003.67109482.D')
# tso -t "ALLOCATE DDNAME(OUTMVS) DSNAME('PSTR.TEMP')"
ALLOCATE DDNAME(OUTMVS) DSNAME('PSTR.TEMP')
# tso -t "OCOPY INDD(INHFS) OUTDD(OUTMVS)"
OCOPY INDD(INHFS) OUTDD(OUTMVS)
IKJ56247I FILE INFO-RETRIEVAL NOT PERFORMED, IS NOT ALLOCATED
RC(12)
|
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
|
|
|
|
Chapter 1.6 of the TSO/E Command Reference manual explicitly states
Quote: |
Note: Except for the DELETE and LISTCAT commands, TSO/E does not support generation data group (GDG) data sets. |
In other words, you can use a batch job to reference the DD name, but don't expect to do this through (1) batch TSO -- IKJEFT??, or (2) via terminal interaction. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
Henrique, this Rexx will create a new generation of FILE.MYGDG. It will ignore data sets with HLQ FILE.MYGDG that are not part of the GDG. It will not handle the case of wrapping (i.e., going from G9999V00 to G0001V00). I do not know Unix, but perhaps you will not find it difficult to adapt to your needs.
Code: |
/* Rexx */
trace o
drop listcat.
x = outtrap("listcat.")
"LISTCAT LEVEL('FILE.MYGDG') ALL"
x = outtrap("OFF")
do i = 1 to listcat.0
if (pos("NONVSAM",listcat.i)¬=0) then
parse var listcat.i . . dsn
if (pos("ASSOCIATIONS",listcat.i)¬=0) then do
j = i + 1
if (pos("GDG",listcat.j)¬=0) then do
p1 = lastpos('.',dsn)
gen = strip(substr(dsn,p1+1))
gen# = substr(gen,2,4)
end
end
end
newgen# = gen# + 1
newgen = 'G' || copies('0',4-length(newgen#)) || newgen# || "V00"
newdsn = "'FILE.MYGDG." || newgen || "'"
"ALLOC DA(" || newdsn || ") FI(FOFUM) NEW LIKE('" || dsn || "')"
"FREE FI(FOFUM)" |
|
|
Back to top |
|
|
|