View previous topic :: View next topic |
Author |
Message |
arvibala Beginner
Joined: 12 Feb 2008 Posts: 142 Topics: 67
|
Posted: Mon Dec 29, 2008 3:41 pm Post subject: Catalog a File so that it doesnt go to MIGRAT2 mode |
|
|
I have a Job that runs once is a month. I receive a file from Oracle Server into Mainframe, say HLQ1.MLQ1.MLQ2.ARVIND. The Monthly Job processes this file and empties it. The request is they want us to have this file catalogued so that they populate data thru FTP. The problem is since this is a Monthly process, when they FTP the data onto this file, this file goes into MIGRAT2 and their FTP fails. How to Catalog a file so that it doesnt goes into MIGRAT2 mode? _________________ Arvind
"You can make a difference with your smile. Have that with you always" |
|
Back to top |
|
|
taltyman JCL Forum Moderator
Joined: 02 Dec 2002 Posts: 310 Topics: 8 Location: Texas
|
Posted: Mon Dec 29, 2008 9:19 pm Post subject: |
|
|
FTP can be set to automount to allow a recall. See who is the systems programmer for FTP at your site. |
|
Back to top |
|
|
expat Intermediate
Joined: 01 Mar 2007 Posts: 475 Topics: 9 Location: Welsh Wales
|
Posted: Tue Dec 30, 2008 2:59 am Post subject: |
|
|
You can not catalog a file in any different way to avoid space management.
Assuming that your site has DFSMSsms implemented, you need to speak to your storage management team to provide a different MGMTCLAS for this dataset so that it does not get migrated. _________________ If it's true that we are here to help others,
then what exactly are the others here for ? |
|
Back to top |
|
|
arvibala Beginner
Joined: 12 Feb 2008 Posts: 142 Topics: 67
|
Posted: Tue Dec 30, 2008 9:44 am Post subject: |
|
|
Thanks All _________________ Arvind
"You can make a difference with your smile. Have that with you always" |
|
Back to top |
|
|
kolusu Site Admin
Joined: 26 Nov 2002 Posts: 12375 Topics: 75 Location: San Jose
|
Posted: Tue Dec 30, 2008 2:29 pm Post subject: |
|
|
arvibala,
Code a HRECALL STEP with WAIT as the first step in your JCL.
Code: |
//STEP0100 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD *
HRECALL HLQ1.MLQ1.MLQ2.ARVIND WAIT
/* |
Code: |
WAIT specifies that you want to wait for the HRECALL
command to complete. If you are recalling data sets from
tape, we recommend that you do not specify the WAIT option
because the operator has to mount the tape for the recall to
complete.
NOWAIT specifies that you do not want to wait for the
HRECALL command to complete. If you are recalling data sets
from tape, we recommend that you specify the NOWAIT option
because the operator has to mount the tape for the recall to
complete.
|
Kolusu |
|
Back to top |
|
|
expat Intermediate
Joined: 01 Mar 2007 Posts: 475 Topics: 9 Location: Welsh Wales
|
Posted: Wed Dec 31, 2008 2:55 am Post subject: |
|
|
Kolusu, although your suggestion is widely used, it is sometimes frowned upon when large files are involved.
On one occurence, the requested HRECALL was queued behind almost 900 other requests and waited for over three hours before the recall step completed. This kept an initiator occupied for all of that time at month end.
Although this was probably a once off event, I believe that it is a far better practice to speak to the storage group and manage the dataset correctly in the first place, rather than have it constantly jigging up and down between tape and DASD.
Just the humble opinion of a storage guy _________________ If it's true that we are here to help others,
then what exactly are the others here for ? |
|
Back to top |
|
|
jsharon1248 Intermediate
Joined: 08 Aug 2007 Posts: 291 Topics: 2 Location: Chicago
|
Posted: Wed Dec 31, 2008 8:45 am Post subject: |
|
|
Quote: | The Monthly Job processes this file and empties it |
Does that mean an empty file is sitting around for a month? What is the purpose of that? Couldn't you just delete it? It sounds like you're file transfer is failing because it's waiting for a recall of an empty dataset.
Other options:
1) Transfer the file to a temp dataset, and then copy the temp file into the perm with a GENER or SORT
2) Schedule a job to touch the file a day before the transfer job. |
|
Back to top |
|
|
Ravi Beginner
Joined: 27 Jun 2005 Posts: 88 Topics: 2
|
Posted: Fri Jan 02, 2009 12:08 am Post subject: |
|
|
Make HLQ1.MLQ1.MLQ2.ARVIND as a GDGBase and then start using the current version. In that way, you are backing up on whatz being FTP'ed too. If a MF job is doing the pull, then you need to allocate the file prior to the FTP being process. If the some other non-MF (windows/unix) system is FTP'ing then use the SITE command to create the correct LRECL and RECFM so that the data may not truncate.
Hope this helps |
|
Back to top |
|
|
arvibala Beginner
Joined: 12 Feb 2008 Posts: 142 Topics: 67
|
Posted: Thu Jan 08, 2009 3:17 pm Post subject: |
|
|
Hi jsharon1248 / Ravi,
The Team who is sending us the File was not able to allocate the File, so they want us to Pre-Allocate, so that they can Just send data.
Kolusu,
I dont agree with your option, because the FTP step at the Oracle Team is failing. They will send us the data anytime in the last week of the month, so thought if we had some option to allocate dataset which doesnt migrate.
Am I expecting too much? _________________ Arvind
"You can make a difference with your smile. Have that with you always" |
|
Back to top |
|
|
expat Intermediate
Joined: 01 Mar 2007 Posts: 475 Topics: 9 Location: Welsh Wales
|
Posted: Fri Jan 09, 2009 2:49 am Post subject: |
|
|
As previously stated, talk to your storage team who can easily change the MGMTCLAS of the dataset to non migrate, or migrate after nn days nonuse.
Do it once and it is done for ever ! _________________ If it's true that we are here to help others,
then what exactly are the others here for ? |
|
Back to top |
|
|
|
|