In <[EMAIL PROTECTED]>, on 10/30/2006
at 09:39 PM, Tom Marchant <[EMAIL PROTECTED]> said:
>Nope. I can't see that there is any rationale for it.
>2096128K is 2 GiB minus 1 MiB.
Yikes. ITYM 2096128Ki is 2 GiB minus 1 MiB. Since a region can't
straddle the line, that limit is way too high.
--
On Mon, 30 Oct 2006 12:45:59 -0500, Shmuel Metz (Seymour J.)
<[EMAIL PROTECTED]> wrote:
>In <[EMAIL PROTECTED]>, on 10/27/2006
> at 05:23 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>
>>BTW, what's the rationale for the maximum of 2096128K?
>
>Presumably 2 GiB minus 16 MiB minus extended common
In <[EMAIL PROTECTED]>, on 10/27/2006
at 05:23 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Is it available or OCO?
It's probably available on VPL. If not, you can get the source for a
much older version from the Hercules project.
>I'd accept that if you could persuade me that there's a "gen
IBM Mainframe Discussion List wrote on 10/27/2006
07:23:43 PM:
> BTW, what's the rationale for the maximum of 2096128K?
> 2096129 = 0x1FFC01, and 2096129*1024 = 0x7FF00400, which fit
> comfortably in 21-bit and 31-bit fields, respectively. It seems
> to me that the reasonable choice of limit w
On Fri, 27 Oct 2006 17:23:43 -0600, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:
> I tried various values
>of REGION. z/OS 1.7 accepts "REGION=2096128K" but fails on
>"REGION=2096129K" with
>
>IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE REGION FIELD.
>
>
>BTW, what's the r
In a recent note, "Shmuel Metz (Seymour J.)" said:
> Date: Fri, 27 Oct 2006 16:14:29 -0300
>
> No. Read the code.
>
Is it available or OCO?
> >Is there any rationale for permitting three leading zeroes, but not
> >four as long as the resulting numeric value is within range?
>
> Avoidin
In <[EMAIL PROTECTED]>, on 10/24/2006
at 02:05 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Truly a gratuitous check.
No. Read the code.
>Is there any rationale for permitting three leading zeroes, but not
>four as long as the resulting numeric value is within range?
Avoiding extraneous co
In a recent note, Binyamin Dissen said:
> Date: Tue, 24 Oct 2006 19:19:11 +0200
>
> That is the problem - the label number is up to four digits.
>
Truly a gratuitous check. Is there any rationale for permitting
three leading zeroes, but not four as long as the resulting
numeric value is
In
<[EMAIL PROTECTED]>,
on 10/23/2006
at 03:51 PM, Lizette Koehler <[EMAIL PROTECTED]> said:
>When I code the FILESEQ number on a Tape - it failes if I used hi
>order zeros.
How many? Three, as in your example, or more?
>LABEL=(0001EXPDT=98000) vs. LABEL=(1EXPDT=98000)
Why the e
On Tue, 24 Oct 2006 12:59:09 -0400 Lizette Koehler <[EMAIL PROTECTED]>
wrote:
:>Resolution:
:>I had written a REXX exec for a DR process that would read the TMSGRW report
of volumes being taken to the DR site and generate a series of FDR Full Volume
Restores. I was unable to test the actual J
Resolution:
I had written a REXX exec for a DR process that would read the TMSGRW report
of volumes being taken to the DR site and generate a series of FDR Full Volume
Restores. I was unable to test the actual JCL and so made some BIIIGGG
asumptions.
The FileSeq number generated was a 5 di
My response was vague. I use those numbers primarily with JCL DD.
Daniel McLaughlin
Z-Series Systems Programmer
Crawford & Company
This transmission is intended exclusively for the individual or entity to
which it is addressed. This communication may contain information that is
confidenti
In a recent note, Daniel A. McLaughlin said:
> Date: Tue, 24 Oct 2006 06:12:48 -0400
>
> Don't know about all that, I use (01, 02, 15, etc) with no problem.
>
With what language/command? JCL DD? TSO ALLOCATE? BPXWDYN?
HLASM generating SVC 99 TU? Other (specify)? Is the behavior
cons
Don't know about all that, I use (01, 02, 15, etc) with no problem.
Dan
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
In a recent note, Lizette Koehler said:
> Date: Mon, 23 Oct 2006 15:51:15 -0400
>
> Ok, here is a very basic question:
>
> When I code the FILESEQ number on a Tape - it failes if I used hi order
> zeros. So it will not take 0001 but will take 1. I did not remember this
> being a rest
On Mon, 23 Oct 2006 15:51:15 -0400 Lizette Koehler <[EMAIL PROTECTED]>
wrote:
:>Ok, here is a very basic question:
:>When I code the FILESEQ number on a Tape - it failes if I used hi order
zeros. So it will not take 0001 but will take 1. I did not remember this
being a restriction in JCL. At
error
are you actually getting?
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Lizette Koehler
Sent: Monday, October 23, 2006 2:51 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FileSeq Number on Tape
Ok, here is a very basic question:
When I cod
Ok, here is a very basic question:
When I code the FILESEQ number on a Tape - it failes if I used hi order zeros.
So it will not take 0001 but will take 1. I did not remember this being a
restriction in JCL. At what point in the converter code would look at this and
not like 0001.
LABEL=(00
18 matches
Mail list logo
