hi Lim,
my advise would be to add some TEMP datasets within the JCL... you can
hardcode the Volser with a disp of Delete, Delete.
this util allocates space from TEMP as defined in SMS and remove after the
success..
thanks,
Amit
On Tue, Sep 13, 2011 at 5:59 AM, Lim Ming Liang limm...@unifi.my
I tried that with SYSUT1 ddname, but GIMUNZIP still dynamically allocate it.
Regards Lim ML
On 14/09/11 3:43 PM, amit wrote:
hi Lim,
my advise would be to add some TEMP datasets within the JCL... you can
hardcode the Volser with a disp of Delete, Delete.
this util allocates space from TEMP as
can you try directing it to tape instead of DASD, specifically mention ur
TAPE psuedos...it wd take a lot of IO, but end of the day it would help you
achieve success.
On Wed, Sep 14, 2011 at 3:01 PM, Lim Ming Liang limm...@unifi.my wrote:
I tried that with SYSUT1 ddname, but GIMUNZIP still
added volume parameter in the ARCHDEF, resolved the issue.
I think I can close this thread.
Thank you all.
Regards Lim ML
On 14/09/11 5:47 PM, amit wrote:
add volume parameter in
the
ARCHDEF.
--
For IBM-MAIN subscribe /
advise would be to add some TEMP datasets within the JCL... you can hardcode
the Volser with a disp of Delete, Delete. this util allocates space from TEMP
as defined in SMS and remove after the success..
If you're in an SMS world, why hard code a volser?
-
Ted MacNEIL
eamacn...@yahoo.ca
GIMUNZIP might be trying to allocate a Large Format sequential data set
(DSNTYPE=LARGE) rather than a PDSE. I say that because at this web page:
https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377
it says:
GIMUNZIP has been updated to allocate SYSUT1 as a Large Format sequential data
Hi Bill,
Much obliged on the updates.
Regards Lim ML
On 13/09/11 1:24 AM, Bill Godfrey wrote:
GIMUNZIP might be trying to allocate a Large Format sequential data set
(DSNTYPE=LARGE) rather than a PDSE. I say that because at this web page:
Check this:https://www-304.ibm.com/support/docview.wss?uid=isg1IO10377
From: Lim Ming Liang limm...@unifi.my
To: IBM-MAIN@bama.ua.edu
Sent: Saturday, September 10, 2011 1:27 AM
Subject: Re: GIMUNZIP GIM54701S error
Sure.
//UNZIP#01 EXEC PGM=GIMUNZIP,COND=(4000
To: IBM-MAIN@bama.ua.edu
Sent: Saturday, September 10, 2011 1:27 AM
Subject: Re: GIMUNZIP GIM54701S error
Sure.
//UNZIP#01 EXEC PGM=GIMUNZIP,COND=(4000,LT)
//SMPDIR DD PATHDISP=KEEP,
// PATH='/u/cpac/ST126014.content'
//*
//SMPWKDIR DD PATHDISP=KEEP,
// PATH='/tmp'
//SMPOUT DD SYSOUT
Google for 0C060090,which is in one of the messages. It will take you here:
http://www.mail-archive.com/ibm-main@bama.ua.edu/msg28790.html
which shows an ibm-main post from 2006 that says:
(quote)
HISTORIC RETURN CODE IS 196 DIAGNOSTIC INFORMATION IS 0C060090
For this code you need to look in
Hi Bill,
PDSE cannot be VIO , is it a DFSMSdfp software constraint ?
GIMUNZIP is trying to allocate a PDSE on VIO for SYSUT1 , is it an
software action taken by GIMUNZIP to dynamically allocate SYSUT1 with VIO ?
Or is it my system setup for VIO allocation causing the problem ?
Pardon me, I
Hi,
I run GIMUNZIP,
--GIMUNZIP
-- ARCHDEF
--archid=AAOPEXEC.100
--newname=TRX4.AOP.AAOPEXEC
-- /
and encountered error messages;
** ALLOCATION FAILED FOR SYSUT1 - IKJ56893I FILE SYSUT1 NOT ALLOCATED+.
GIM54701S ** ALLOCATION FAILED FOR
Can you paste me your full JCL.
Thanks Regards
Saurabh
On Sat, Sep 10, 2011 at 9:25 AM, Lim Ming Liang limm...@unifi.my wrote:
Hi,
I run GIMUNZIP,
--GIMUNZIP
-- ARCHDEF
--archid=AAOPEXEC.100
--newname=TRX4.AOP.AAOPEXEC
-- /
and
Sure.
//UNZIP#01 EXEC PGM=GIMUNZIP,COND=(4000,LT)
//SMPDIR DD PATHDISP=KEEP,
// PATH='/u/cpac/ST126014.content'
//*
//SMPWKDIR DD PATHDISP=KEEP,
// PATH='/tmp'
//SMPOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUT3 DD UNIT=SYSALLDA,SPACE=(CYL,(50,10))
//SYSUT4 DD
14 matches
Mail list logo
