> 05 INP-VNDR-PACK-COST PIC 9(9)V9(4).
> 05 WS-VNDR-PACK-COST PIC S9(9)V9(4) COMP-3.
> INP-VNDR-PACK-COST -035.65 <-- this in wrong. The period doesn’t
> belong here.
It should be 03565
Thanks,
Tom
-Original Message-
From: IBM Mainframe Discussion
Hi Ron,
> I was looking a Cobol code module developed and we ran in to a sco7 issue. I
> > am not able to figure why this is abending.
>
> Any help to fix is much appreciated.
>
> Here is the spool display i have captured.
> 05 INP-VNDR-PACK-COST PIC 9(9)V9(4).
> 05 WS-VNDR-PACK-COST
On Fri, 13 Jan 2023 00:05:44 +, Sri h Kolusu wrote:
>
>There is distinction between maximum supported LRECL (32K) and maximum
>supported SORT CONTROL FIELDS. The total number of bytes occupied by all sort
>control fields must not exceed 4092 (or, when EQUALS option is in operation,
>4088
EQUALS was not specified in my SORT parms, but it was listed in the OPTIONS
display of the output as EQUALS=Y.
I am in the process of getting the program rerun with NOEQUALS specified.
C-
On Thu, Jan 12, 2023 at 6:06 PM Sri h Kolusu wrote:
> >> Is 32 bits an optimum choice? A larger
>> Is 32 bits an optimum choice? A larger pseudo-key would have some impact on
>> performance and reduce the maximum supported LRECL.
Gil,
There is distinction between maximum supported LRECL (32K) and maximum
supported SORT CONTROL FIELDS. The total number of bytes occupied by all sort
On Thu, 12 Jan 2023 20:45:29 +, Sri h Kolusu wrote:
>
>As Steve smith pointed out it Is your EQUALS parm that is limiting the number
>of records to be sorted. Do you really need EQUALS ( which is retain the
>order of duplicates). ? If you don't need it then you can pass NOEQUALS as an
Is EQUALS implied if you're running a program sort instead of a JCL sort? I
thought Chuck said he was running the sort inside a program which is why he
couldn't just split the data apart and merge it back together.
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf
I imagine this wouldn't get you around the problem, but if you were sort the
records in a separate DFSORT step, then feed the sorted data to your program,
would it still complain about the number of records since it would encounter no
need for any sorting at all? Just a thought.
---
Bob
>> DFSORT issues a message that I have exceeded the sort input record maximum.
Chuck,
As Steve smith pointed out it Is your EQUALS parm that is limiting the number
of records to be sorted. Do you really need EQUALS ( which is retain the order
of duplicates). ? If you don't need it then you
On 1/12/2023 9:37 AM, Radoslaw Skorupka wrote:
Maximum input records for DFSORT is infinity,
Good to know! I'm testing that to be sure, but it's still running...
--
For IBM-MAIN subscribe / signoff / archive access
Once you have busted a limit like this, it's probably time to rethink the
design.
What is the data source? If you are processing this many records, are they
from a single source?
DB2 has a tablespace limit of 128TB. Does your file fit into that size?
Loading a table that size with an index(es)
EQUALS adds an internal sort field of 4 bytes to hold an input sequence
number, which is what you appear to be having trouble with. You haven't
mentioned it, but removing EQUALS will solve your problem.
If that's not feasible you can, if necessary, use some fancy stuff to add
your own, say, a 6
I have run into large files with DFSORT, and when I asked them they told
me that there are hard limits:
* EQUALS in effect - 4 294 967 295 records
* VLSHRT in effect - 2 147 483 647 records
* Blockset technique not selected - 2 147 483 647 records
I wonder if you could do something in your
Yes, we've been informed that SYNCSORt doesn't have this limitation but
getting it in-house takes major efforts since it's a new product to us.
We were hoping for some other DFSORT option to at least let us move forward.
Thanks everyone for listening and your replies.
Chuck
On Thu, Jan 12, 2023
This isn't an answer to your problem, and things may have changed considerably
since the early 1980's. But, SYNCSORT used to have
the TAPE sort option. Way be when, in the early 1980's, I bumped
up against DF/SORT's limit of that time, we happened to have a
trial copy of SYNCSORT. SYNCSORT
Apologies for an HTML reply to a plain-text message, but it was necessary. I
converted your spool display lines to a fixed-pitch font to try to maintain
alignment of the characters and the hex representation.
Note that your input value seems to have an actual period (X’4B’ character) and
an
Looks like you included the whole record. Display numeric field seems to be:
F...FFF4FF
0...035B65
> 05 INP-VNDR-PACK-COST PIC 9(9)V9(4).
The x'4B' is a period character generated by a PIC 9(9).99. Can't
have that in the data in order to perform math. Break it into 2
fields, dollars and
I have plenty of SORTWKxx DDs.
I don't think that is the problem.
I am getting an IEX121A message.
According to the DFSORT Messages, Codes and Diagnosis Guide for z/OS 2.5:
ICE121A FILE SIZE IS TOO LARGE
Explanation
Critical. The amount of data to be sorted exceeded
a DFSORT implementation limit
ok Jay. so, what you say is if the definitions are as below then we should be
good. The '-' sign is part of the variable name in spool display.
05 INP-VNDR-PACK-COST PIC 9(9)V9(2).
05 WS-VNDR-PACK-COST PIC S9(9)V9(2) COMP-3.
Regards
Ron T
Well, your declaration of the INP-VNDR-PACK-COST variable doesn't seem to
match the actual data...the decimal point is in the wrong place (two
characters to the right), and there's an undeclared minus sign...
On Thu, Jan 12, 2023 at 11:45 AM Ron Thomas wrote:
> Hi Listers
>
> I was looking a
Hi Listers
I was looking a Cobol code module developed and we ran in to a sco7 issue. I am
not able to figure why this is abending.
Any help to fix is much appreciated.
Here is the spool display i have captured.
05 INP-VNDR-PACK-COST PIC 9(9)V9(4).
05 WS-VNDR-PACK-COST PIC
On Thu, 12 Jan 2023 10:42:51 -0600 Charles Hardee
wrote:
:>I've searched the IBM-MAIN archives and found nothing to help me so I
:>thought I'd better ask the question.
:>I am trying to sort roughly 4295217295, records using DFSORT.
:>DFSORT issues a message that I have exceeded the sort input
Maximum input records for DFSORT is infinity, *except* some options like
EQUALS. For EQUALS the maximum is 4Gi records (means 2**32).
Sometimes it is good idea to change SORT to MERGE.
--
Radoslaw Skorupka
Lodz, Poland
-Original Message-
From: IBM Mainframe Discussion List On
Apologies for the typo, the Syncsort option is DYNALLOC, not DYNALOC.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Farley, Peter
Sent: Thursday, January 12, 2023 12:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT maximum input records
Not sure if DFSORT
Not sure if DFSORT has an equivalent option, but Syncsort has a parameter
DYNALOC that can change the maximum number of SORTWKnn DD's it will allocate.
Our local Syncsort default is 64, but for really big sorts (when we get the
Syncsort equivalent "too big to sort" message, which says "SORT
Hello Listers,
I've searched the IBM-MAIN archives and found nothing to help me so I
thought I'd better ask the question.
I am trying to sort roughly 4295217295, records using DFSORT.
DFSORT issues a message that I have exceeded the sort input record maximum.
It appears that this maximum is
On Wed, 11 Jan 2023 10:38:09 -0600, Paul Gilmartin wrote:
>how much is concealed behind the seemingly innocuous "formed from".
I would say that nothing is concealed. If you look at the ESA/390 PSW and the
z/Architecture PSW, the transformations are pretty obvious. Most of the bits
are the
Regarding LPSW / LPSWE:
The POp is correct.
* A z/Architecture PSW is 16 bytes.
* The operand of LPSWE is 16 bytes.
* The operand of LPSW is 8 bytes from which a 16 byte PSW is formed.
Thus you cannot provide a 16-byte PSW via LPSW.
A specific case where you need LPSWE rather than
Replying to my own post:
Address space PCIE gets started automatically during IPL and comes up unless
your RACF Administration decides to 'program control' (not via RACF, but the
effect is the same) lmod IEFVH1 and then does not check the fallout or correct
it. GTZ was also affected.
After
29 matches
Mail list logo
