Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
Am trying to copy a PS file into another PS file. While copying want the new file to be created with exactly the same attributes of the from dataset - RECFM, RECLEN, BLKSIZE, SPACE - Unit, Primary Quantity, Secondary Quantity and the EXPDT. Is this possible ?
I tried different JCLs - using SORT, IEBGENER, .... - with LIKE, REFDD parameters. But as the manual says - the SPACE and EXPDT are not considered.
The result am currently achieving - the content is getting copied to the new file with same RECFM and RECLEN. But the BLKSIZE, SPACE and EXPDT looks to be different.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
PeterHolland wrote:
Quote:
But the BLKSIZE, SPACE and EXPDT looks to be different.
What the hell is that, are they different or not?!?
Yes, Peter.. They are different...
To explain a little better
From dataset attributes...
Code:
General Data Current Allocation
Management class . . : **None** Allocated tracks . : 175
Storage class . . . : **None** Allocated extents . : 1
Volume serial . . . : TSTS01
Device type . . . . : 3390
Data class . . . . . : **None**
Organization . . . : PS Current Utilization
Record format . . . : VB Used tracks . . . . : 10
Record length . . . : 6104 Used extents . . . : 1
Block size . . . . : 6108
1st extent tracks . : 175
Secondary tracks . : 0 Dates
Data set name type : Creation date . . . : 1993/07/08
SMS Compressible. . : NO Referenced date . . : 2013/02/20
Expiration date . . : ***Perm***
To dataset attributes after copy...
Code:
General Data Current Allocation
Management class . . : TES Allocated kilobytes : 929
Storage class . . . : TES Allocated extents . : 1
Volume serial . . . : OLT001
Device type . . . . : 3390
Data class . . . . . : TES
Organization . . . : PS Current Utilization
Record format . . . : VB Used kilobytes . . : 902
Record length . . . : 6104 Used extents . . . : 1
Block size . . . . : 27998
1st extent kilobytes: 929
Secondary kilobytes : 500 Dates
Data set name type : Creation date . . . : 2013/02/20
SMS Compressible. . : NO Referenced date . . : 2013/02/20
Expiration date . . : ***None***
As can be seen, the Block Size, 1st extent, Secondary extent, Expiry date are all different but I would like to have it same as the old dataset after the copy.
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
Probably you left it to the OS to determine BLKSIZE, space etc.
But what is your problem? The dataset is copied, what do you want more?
Ask your SMS people or whatever.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
PeterHolland wrote:
Probably you left it to the OS to determine BLKSIZE, space etc.
Yes Peter... I have at this point of time...
I am trying to figure out how I can tell the OS that 'while copying please take the BLKSIZE and SPACE and EXPDT' also into consideration'... At this point I am not able to find an option for that. As a result I was asking in my initial post - Is this possible ?
PeterHolland wrote:
But what is your problem? The dataset is copied, what do you want more?
.. I am not sure what I am missing here.. but are you suggesting that the other attributes are not important ?
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
Binop B wrote:
Am trying to copy a PS file into another PS file. While copying want the new file to be created with exactly the same attributes of the from dataset - RECFM, RECLEN, BLKSIZE, SPACE - Unit, Primary Quantity, Secondary Quantity and the EXPDT. Is this possible ?
I tried different JCLs - using SORT, IEBGENER, .... - with LIKE, REFDD parameters. But as the manual says - the SPACE and EXPDT are not considered.
The result am currently achieving - the content is getting copied to the new file with same RECFM and RECLEN. But the BLKSIZE, SPACE and EXPDT looks to be different.
Consider having the JCL tailored from a Rexx script using ISPF services.
Since this is a JCL topic, can you show us your JCL output DD?
Does your output DD (i.e. IEBGENER) look something like this?
Code:
//SYSUT2 DD DSN=xxx,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA, <-guessing for your shop
// VOL=SER=TES, <-guessing for your shop
// LABEL=EXPDT=99000, <-not sure for "PERM". "PERM" sounds like a Prod setup, not Test.
// SPACE=(TRK,(175,10),RLSE),
// DCB=(RECFM=VB,LRECL=6104,BLKSIZE=6108) <-looks like you used BLKSIZE=0 ?
I see both datasets are on 3390's but the VolSer is different so results will never be exact.
Again, see your SMS/DASD space person.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Akatsukami wrote:
Consider having the JCL tailored from a Rexx script using ISPF services.
.. Apologize ... I have never tried REXX in my short career so far...
Were you suggesting something like using REXX to get the attributes of the source dataset and create a dynamic copy JCL based on the source dataset attributes. Did I get that right ?
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Gary McDowell wrote:
Since this is a JCL topic, can you show us your JCL output DD?
Does your output DD (i.e. IEBGENER) look something like this?
Code:
//SYSUT2 DD DSN=xxx,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA, <-guessing for your shop
// VOL=SER=TES, <-guessing for your shop
// LABEL=EXPDT=99000, <-not sure for "PERM". "PERM" sounds like a Prod setup, not Test.
// SPACE=(TRK,(175,10),RLSE),
// DCB=(RECFM=VB,LRECL=6104,BLKSIZE=6108) <-looks like you used BLKSIZE=0 ?
I see both datasets are on 3390's but the VolSer is different so results will never be exact.
Again, see your SMS/DASD space person.
... I should have posted the JCL before... Apologize again...
Below are some of the basic options I have tried out ....
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
Binop B wrote:
Akatsukami wrote:
Consider having the JCL tailored from a Rexx script using ISPF services.
.. Apologize ... I have never tried REXX in my short career so far...
Don't worry; happens to the best of us I think that I had nine years' experience in this field before I saw Rexx.
Quote:
Were you suggesting something like using REXX to get the attributes of the source dataset and create a dynamic copy JCL based on the source dataset attributes. Did I get that right ?
Essentially, although until you already have jobs set up in a library, I'd suggest going with the ISPF file-tailoring services.
Two things: without meaning disrespect to Mr. McDowell, I believe that EXPDT=99000 only has meaning to certain tape management systems. If you wish to create a permanent data set on DASD, you might be better served to use EXPDT=99366. Also, I think that you will need to take the SMS data storage and data classes into account. Mynheer Holland's advice to speak to your SMS workgroup is sound; what you seek to do may not be possible on your machine (e.g., I cannot create a non-volatile data set with my TSO ID as HLQ in my shop).
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
Initially I thought there might be some simple JCL to perform this function
Unfortunately, you've wandered into an area where the site-specific parameters will impact what can -- and cannot -- be accomplished. Block size does not tend to be a signficant value these days, especially for a variable blocked file, so 6108 versus 27998 is not something to worry about. The PERM expiry date, however, may be restricted by site policy to the storage management group, in which case NOTHING you do will allow you to copy a data set with PERM expiry date and preserve that setting.
Unless and until you talk to your site support people, there is no way that you will be able to find out for sure which parameters can be duplicated. Certainly no "simple JCL" will do what you want.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Akatsukami wrote:
Essentially, although until you already have jobs set up in a library, I'd suggest going with the ISPF file-tailoring services.
New concept for me again... I tried to get some information from the below links but at this point its a bit greek and latin for me ... Defining file-tailoring skeletons Using the file-tailoring services
Will need to spent a little more time to get this into my head...
Checked with my site support people - but there aint anything as of now to help the cause. At this point we have decided to go with the default values of Block Size and mark the datasets as permanent as of now. Thanks a lot everybody for your help ..
Robert Sample wrote:
Block size does not tend to be a significant value these days, ...
Agreed... Its just that when I was having the knowledge transfer for the application I am working on now - he had mentioned that there are some files which is being referenced by some very old program which is expecting it to be in the same Block Size and if altered it would create some issues... My bad... that I didn't note down the program or the file name at that point of time and that is the reason I was trying to make sure of having the same attributes to play safe...
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You could look at AMBLIST to attempt to identify "old" programs, and then look at them. Perhaps your source-management system might also help. You could try a source scan for the specification of blocksizes.
If they are Cobol, and there are "too many", investigate COBANAL from the "CBT tape". I think it lists blocksizes where specified in the program.
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
What Gary has suggested might take you most close to what you're looking for and with a "simple JCL". OTOH, if you're doing this in 'TEST LPAR' chances of getting PERM in test are very less, possibly they just don't allow this in test. The better choice is, get in touch with your site-support group*, as other have mentioned about it.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Bill Woodger wrote:
You could look at AMBLIST to attempt to identify "old" programs, and then look at them.
Thanks Bill... some time late yday evening I did some search in our JCL library and did find the program based on the comments...
Had a quick check into the program and while the file definition has
Code:
BLOCK CONTAINS 0 RECORDS
, there are other statements in the PROCEDURE DIVISION which has some block size calculation. At this point I would I need to analyze this further to understand what exactly this program is doing...
At some point of time I think I might have to apply what I have learnt from here to remove the block size dependency.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Anuj Dhawan wrote:
if you're doing this in 'TEST LPAR' chances of getting PERM in test are very less, possibly they just don't allow this in test. The better choice is, get in touch with your site-support group*, as other have mentioned about it.
*: And I'd like to hear back what they say!
Here having a permanent file in test is not advised but have got the blessings to create a permanent files as of now. As mentioned before, going ahead with creating files with the block sizes allocated default by OS and with EXPDT=99366.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
BLOCK CONTAINS 0 and then some blocksize calculation? That sounds odd, and horrible, potentially.
I'd try running the program in test with a big blocksize and see what happens. If it "seems" to work, make sure it is excessively well tested.
If it doesn't work, you need to find out why "something" needs a specific blocksize, and what it is which requires it to be done in such a terrible way.
You know what to do if you have questions on it :-)
.. I am not sure what I am missing here.. but are you suggesting that the other attributes are not important ?
.. Apologize ... I have never tried REXX in my short career so far...
I think that I had nine years' experience in this field before I saw Rexx.
