prevent it.
-Scott Ballentine, IBM z/OS Device Allocation
sbal...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.
By the way, to clarify something from one of the responses - upgrading enqueues
is allowed (with limitations, and that's why we try to obtain serialization the
way we do), and downgrading is also allowed if you request it (see the DSENQSHR
parameter on the JOB statement.)
-Scott Ballentine, IBM z/OS
, you should not assume that a service
will zero an output address for you if the service could not return data (which
goes to Rob's comment about zeroing the output address before calling IEFSSI to
make sure it is clean.)
-Scott Ballentine
IBM z/OS Development
that OPEN
processing retrieves some of that information from the data set and puts it in
SWA - then Dynamic Information Retrieval doesn't have the information to return
to you.
-Scott Ballentine
z/OS Device Allocation, Scheduler, SMF Development
I'll confirm it: REPORTOPTS was not rolled back to z/OS 2.3. 2.4 and above
only.
- Scott Ballentine
z/OS Allocation, Scheduler, SMF Development
sbal...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access
al DDs are CLOSEd. And a dynamic allocation that causes the data
set ENQ to be upgraded from SHR to EXCL prevents any downgrading.
-Scott Ballentine
IBM z/OS Device Allocation Development
--
For IBM-MAIN subscribe / signoff /
The IEFU8x exits get the "live" record, so yes, any updates that the exit makes
would get passed on down the line.
I thought this was documented, but I did a quick search and didn't find it
either. (There are some places that hint at it but I didn't find anything that
spells it out
o the text unit list for the unallocation is
pointing to the correct storage, the text units contain the correct keys, and
that you don't have the end of list indicator (the high-order bit) turned on
for any of the text unit pointers other than the last.
-Scott Ballentine (sbal...@us.ibm.
That's correct - the IEFA111I message is intended to be information to help
debug a job that didn't behave as expected. It's issued when a job has
MSGLEVEL=(,1) in effect.
I've arranged to have the System Messages documentation updated.
-Scott Ballentine (sbal...@us.ibm.com)
z/OS Allocation
in the window where it is
unallocated, so this might not be a viable option - that's for you to decide
based on what your application is doing.)
-Scott Ballentine (sbal...@us.ibm.com)
z/OS Device Allocation Development
--
For IBM-MAIN
-a-JOB case.)
You might want to experiment with S MYPROC,JOBNAME=, and try running a
batch job that has a step that EXECs a proc.
-Scott Ballentine
z/OS Device Allocation
sbal...@us.ibm.com
--
For IBM-MAIN subscr
into multiple steps
to make it fit. You could crank up the TIOT size to 64K. You could also try
something a little more sophisticated - like dynamically allocating the data
sets (take a look at IDCAMS, which can access the data sets via dynamic
allocation and avoid the batch limits.)
-Scott
(maybe
the initialization routine ABENDs, as an example) then you could use the SETSSI
command to delete it and then issue a SETSSI ADD to create it.
-Scott Ballentine (sbal...@us.ibm.com), IBM z/OS Allocation
On Mon, 18 Jan 2016 11:02:47 -0800, Tom Brennan <t...@tombrennansoftware.com>
.) The
console state is separate from online or offline. Sorry, that serialization
is really necessary.
-Scott Ballentine
IBM z/OS Device Allocation
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
I think it'd be fair to open a PMR here. IEFA107I should be telling you what
it was that couldn't be found, and it doesn't seem like it's doing that.
-Scott Ballentine
IBM z/OS Allocation
sbal...@us.ibm.com
--
For IBM-MAIN
15 matches
Mail list logo
