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.
--
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 generic
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.
Nope. I
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 code
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?
Avoiding
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 rationale for
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 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
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
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
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
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
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 JCL
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
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
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
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 code
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
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
18 matches
Mail list logo
