F2>
Il giorno lun 6 mag 2024 alle ore 19:18 Farley, Peter <
031df298a9da-dmarc-requ...@listserv.ua.edu> ha scritto:
> This is a question specific to the SYNCSORT product, not a general SORT
> question.
>
> I do not have access to question the Syncsort support team, and
TED.
Note, however, when it comes to sort products, just because it isn't documented
doesn't mean it won't work.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Farley, Peter
Sent: Monday, May 6, 2024 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SY
This is a question specific to the SYNCSORT product, not a general SORT
question.
I do not have access to question the Syncsort support team, and I cannot see
from the latest programmer's guide for the product (Syncsort MFX Programmer's
Guide, Version 3.1) what the answer to this q
: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort > DFsort migration
>> It was the thread in January 12th 2023, with subject "DFSORT maximum input
>> records". The message that kicked it off was:
Thanks Michael. It is good to know the other products limits. DFSORT has
rai
>> It was the thread in January 12th 2023, with subject "DFSORT maximum input
>> records". The message that kicked it off was:
Thanks Michael. It is good to know the other products limits. DFSORT has
raised the limit with Sort accelerator to 65,536 times than the other product's
limit.
Thank
age that I have exceeded the sort input record maximum.
It appears that this maximum is 4294967295.
The limit imposed is because, apparently, DFSORT is handling "equals" by adding
a fullword record number to the sort key.
Syncsort MFX also has a 4,294,967,295 record limit when EQUALS is us
On Mon, Aug 28, 2023, at 11:59 AM, Tom Brennan wrote:
> LOL "a while"
>
Don't worry, IBM would sell you Capacity-on-Demand while the job ran.
Kirk Wolf
Dovetailed Technologies
http://coztoolkit.com
--
For IBM-MAIN subscribe / s
LOL "a while"
On 8/28/2023 9:49 AM, Sri h Kolusu wrote:
I think it was mentioned in this list previously that EQUALS in DFSORT has a
lower limit on maximum number of records than SYNCSORT.
Michael,
Can you please provide link to that topic that mentions that DFSORT has a lower
I don't care how fast your computer is, that would take a while to sort! LOL
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Sri
h Kolusu
Sent: Monday, August 28, 2023 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Syncsort > DFsort m
>> I think it was mentioned in this list previously that EQUALS in DFSORT has a
>> lower limit on maximum number of records than SYNCSORT.
Michael,
Can you please provide link to that topic that mentions that DFSORT has a lower
limit than the other product?
We do have limits an
I think it was mentioned in this list previously that EQUALS in DFSORT has a
lower limit on maximum number of records than SYNCSORT.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Pommier, Rex
Sent: Monday, August 28, 2023 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
n does not have the same "stable"
definition, but essentially the same functionality.
>> FYI, I searched the Syncsort programmer's manual and it doesn't mention
>> "stable sort" either. :-)
Rex,
Thanks for the confirmation about the competitor prod
Gil,
I had to look up "stable sort" as I hadn't heard the term. Yes that is what
EQUALS does in both DFSort and Syncsort. FYI, I searched the Syncsort
programmer's manual and it doesn't mention "stable sort" either. :-)
Rex
-Original Message-
From
On Mon, 28 Aug 2023 15:11:05 +, Sri h Kolusu wrote:
>
>EQUALS is the parm which comes into picture when your input has duplicates on
>the key, and you want to retain the order of the duplicates. OPTION EQUALS
>specifies whether the original sequence of records that collate identically
>for
>> The only issue I ran into (this was years ago) was that if you use the PARM
>> in Syncsort of “EQUAL” expect different output in DFSORT
ED,
EQUALS is the parm which comes into picture when your input has duplicates on
the key, and you want to retain the order of the duplica
The only issue I ran into (this was years ago) was that if you use the PARM in
Syncsort of “EQUAL” expect different output in DFSORT.. We did not run into
this but a friend did. There are items in Syncsort that are different in
DFSORT. Syncsort made the decision that some of the (I do not have
has been the same
for a long time. https://www.ibm.com/support/pages/dfsort or
ibm.com/storage/dfsort ( will be re-directed to first link) is generally
updated with every release or with any new enhancements.
>> converting from use of PGM=SYNCSORT, PGM=SYNCGENR, PGM=SYNCTOOL, will
On Sat, 26 Aug 2023 11:52:58 +, Richard McIntosh
wrote:
>We are starting to do a very rushed syncsort to DFsort migration.
>I am assuming most of the sort ports are identical, but I bet not all of them.
>Does anyone have a list of parms that need to be looked at?
>Or anythin
>> We are starting to do a very rushed syncsort to DFsort migration.
Richard,
Thank you for your interest in migrating to DFSORT. I will send you an offline
mail with a couple of attachments which describes in detail about the parms and
the needed changes.
Thanks,
Sri Hari Kolusu
We are starting to do a very rushed syncsort to DFsort migration.
I am assuming most of the sort ports are identical, but I bet not all of them.
Does anyone have a list of parms that need to be looked at?
Or anything thing else that I should be aware of.
Thanks in advance for your time in
bject: [EXTERNAL] Re: Linklist and Syncsort confusion
Once more into the breach.
All of this has been covered multiple times, but searching archives is no one's
favorite thing to do and often it's too hard to find what you want.
Use of LNKLST ALLOCATE/UNALLOCATE is solely provided so that
On Tue, 23 Aug 2022 12:12:47 +, Allan Staller wrote:
>Classification: Confidential
>...
>::DISCLAIMER::
>
>The contents of this e-mail and any attachment(s) are confidential and
>intended for the named recipient(s) only. E-mail transmission is not
>guarant
lly happen.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Pommier, Rex
Sent: Monday, August 22, 2022 2:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion
[CAUTION: This Email is from outside the Organization. Unless you trust the
sen
t: Re: [EXTERNAL] Re: Linklist and Syncsort confusion
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Hi Carmen,
Yes the issu
Behalf Of
Carmen Vitullo
Sent: Monday, August 22, 2022 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Linklist and Syncsort confusion
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can
: Linklist and Syncsort confusion
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Hi list,
I don't know if this is
Once more into the breach.
All of this has been covered multiple times, but searching archives is no one's
favorite thing to do and often it's too hard to find what you want.
Use of LNKLST ALLOCATE/UNALLOCATE is solely provided so that you can access
uncataloged datasets of the same name as a L
On Mon, 22 Aug 2022 18:32:21 +, Pommier, Rex
wrote:
>Hi list,
>
>I don't know if this is specifically a Syncsort issue or a more generic
>confusion about linklist datasets. Here goes.
>
>We have the SYNCLINK library defined in the linklist. We have installed
ugust 22, 2022 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Linklist and Syncsort confusion
correction:
in my SYS1.LINKLIB, IEBGENR is an alias of OLDGENER, since if SYNCGENER cannot
perform as IEBGENER it will call OLDGERNER IIRC
Carmen
On 8/22/2022 2:19 PM, Pommier, Rex wrote
It's Monday, my fingers aren't doing what my brain is telling them either! LOL
Rex
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Monday, August 22, 2022 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Linklist an
GENER by a usermod as part of the
Syncsort install. It may be that the Syncsort standard is to rename IEBGENER
to OLDGENER in LINKLIB, but our company standard is that when we rename
something to "old" status, we change the last character of the name to '9'.
Th
Carmen Vitullo
Sent: Monday, August 22, 2022 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Linklist and Syncsort confusion
you're sure the library is on the same volume? Yes
did the new library contain secondary extents? No, but the old one was in
danger of going into secondary
ok, maybe I just missed it, do you resolve your issue?
my ISRFIND shows IEBGENER in my linklist in the SYNCSORT LINKLIB, did
the vendor change the usermod to assign an alias rather than use the
IEBGERNER module name?
in my SYS1.LINKLIB IEBGENER is an alias of OLDGENER
maybe the usermod
Answers embedded.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Carmen Vitullo
Sent: Monday, August 22, 2022 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Linklist and Syncsort confusion
you're sure the library is on the same volume? Yes
di
you're sure the library is on the same volume?
did the new library contain secondary extents?
did you follow the syncsort process or usermod process to make syncgener
available as IEBGENER?
it renames IEBGENER as OLDGENER, I don't have the MOD in front of me
currently but I think
, Rex wrote:
Hi list,
I don't know if this is specifically a Syncsort issue or a more generic
confusion about linklist datasets. Here goes.
We have the SYNCLINK library defined in the linklist. We have installed
Precisely's IEBGENER replacement as part of our install. We determined
022 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Linklist and Syncsort confusion
>
> [EXTERNAL EMAIL]
>
> Hi list,
>
> I don't know if this is specifically a Syncsort issue or a more generic
> confusion
> about linklist datasets. Here goes.
>
> We h
Hi list,
I don't know if this is specifically a Syncsort issue or a more generic
confusion about linklist datasets. Here goes.
We have the SYNCLINK library defined in the linklist. We have installed
Precisely's IEBGENER replacement as part of our install. We determined
SYNCLI
Hi Max,
I found that MXG can format the Syncsort SMF recrods, so we'll be using that.
Thanks for your help
Gadi
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Massimo Biancucci
Sent: Wednesday, July 27, 2022 11:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: F
f a, hopefully free, tool that can format Syncsort MXF
> v3.1 SMF records?
>
> Thanks
>
> Gadi
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email t
Hi,
Does anyone know of a, hopefully free, tool that can format Syncsort MXF v3.1
SMF records?
Thanks
Gadi
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the
, 2022 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT question: How to treat variable length KSDS as variable
length input to SORT JOINKEYS
Thanks Alan, I will give that a try later today when I get back to work from
other appointments.
Peter
-Original Message-
From: IBM
Thanks Alan, I will give that a try later today when I get back to work from
other appointments.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Alan Young
Sent: Tuesday, June 7, 2022 2:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT question: How to
Add a TYPE=V parameter to the JOINKEYS statement for the VSAM file. It might
also need a RECFM=V on the SORTJNFx DD for the VSAM file.
Alan
-Original Message-
From: IBM Mainframe Discussion List
Sent: Jun 6, 2022 6:07 PM
To:
Subject: SYNCSORT question: How to treat variable length
I have two files, one a flat file with RECFM=VB,LRECL=8004, one a VSAM KSDS
with RECORDSIZE(3000 26000) denoting variable length records for that KSDS.
However, when using that VSAM file as one side of a JOINKEYS operation,
SYNCSORT claims the KSDS is RECFM=F:
WER482I JNF2 STATISTICS
WER483B
gt; To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/01/2021 01:49 PM
> Subject: [EXTERNAL] SORTWK allocations for DFSORT vs Syncsort
> Sent by: IBM Mainframe Discussion List
>
> Greetings ,
>
> I recently noticed the way syncsort handles dynamic allocation for
> SORTWK datasets and
Greetings ,
I recently noticed the way syncsort handles dynamic allocation for SORTWK
datasets and they appear to be avoiding B37 abends better than DFSORT and I am
assuming thats because syncsort allocates SORTWK datasets on "as needed" basis
where as DFSORT tries to allocate a
frame Discussion List On Behalf Of
Massimo Biancucci
Sent: Wednesday, March 31, 2021 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort merge question - How to report exact keys out of sequence?
Peter,
I don't know if you need a "general" solution or a way to diagnose the specifi
;> and 3 are frequently (but NOT always) empty except for header and trailer
>> records. I believe that the DATA records in all files are in the correct
>> merge key sequence within each file, but my merge key specification could
>> be in error.
>>
>> The SYSIN uses a
erge key sequence within each file, but my merge key specification could
> be in error.
>
> The SYSIN uses an OMIT to remove all header and trailer records from the
> merge operation, so when files 2 and 3 are processed they often contribute
> no actual data records to the merge proc
ion, so when files 2 and 3 are processed they often contribute
no actual data records to the merge process.
I get Syncsort messages like this complaining about "out of sequence":
WER055I INSERT 0, DELETE 1
WER068A OUT OF SEQ SORTIN02 , BLOCK 56,917
If I could ask Syncsor
rds to the merge process.
I get Syncsort messages like this complaining about "out of sequence":
WER055I INSERT 0, DELETE 1
WER068A OUT OF SEQ SORTIN02 , BLOCK 56,917
If I could ask Syncsort to tell me exactly what two merge keys are "out of
sequence&quo
Apparently, the specification of format (or at least CH) on Syncsort JOINKEYS
is optional.
I don't have it specified in another job that has been working for some time.
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Sri h Kolusu
> Sent: Thu
h JNF1 and JNF2.
>>I could check and see if Syncsort actually required this specification or
if I did it by habit.
If the key formats are of the same format (like in this case both key
fields are character data) , you absolutely don't require the format.
However if your key has ZD and PD
Thank you. Mos of our "fancy" sort stuff is mine, so I can make these changes.
But, and this is just asking, not really expecting. For compatibility and
migration purposes, is there a way for DFSORT to accept this specification?
I have 4 LPARs. This job runs in 3 of them. 2 still ru
Dave,
DFSORT Joinkeys does not require the FORMAT of the key field as a binary
match is done implicitly.
So change your control cards to the following(Just removed the CH on the
Fields statement)
JOINKEYS FILE=F1,FIELDS=(1,9,A),TYPE=F
JOINKEYS FILE=F2,FIELDS=(6,9,A),
INCLUDE=(6,9,CH,EQ,C'MCR021
Well, I'll look at he manuals tomorrow. Fortunately, this is still the sandbox.
It worked fine with the Syncsort
ICE067I 0 INVALID PARAMETER IN JCL EXEC PARM OR INVOKED PARM LIST
JOIN UNPAIRED
JOI
: Syncsort to DFSORT - my time has come.
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Barry pointed this out to me. And I did
tdown within the year. For me, the path
to ASCII is not likely.
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Edward Finnell
> Sent: Wednesday, October 28, 2020 12:40 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Syncsort to DFSORT - my time
SAS and MXG have PC versions.
So, I lose MXG and reasonable ability to process SMF anyway.
-Original Message-
From: Gibney, Dave
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wed, Oct 28, 2020 11:47 am
Subject: Re: Syncsort to DFSORT - my time has come.
If we had longer to exist, I might. But
If we had longer to exist, I might. But, we haven't been collecting Syncsort
SMF, so until I see the need...
And my SAS license expires soon also. So, I lose MXG and reasonable ability to
process SMF anyway.
> -Original Message-
> From: IBM Mainframe Discussion List On
Not my dog... I'm just a developer.
From: IBM Mainframe Discussion List on behalf of
Martin Packer
Sent: Wednesday, October 28, 2020 2:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort to DFSORT - my time has come.
FWIW I would go with SMF
TSOINV
> SMF=SHORT
> TD1
> SMF=SHORT
> TD2
> SMF=SHORT
> TD3
> SMF=SHORT
> TD4
> SMF=SHORT
>
>
> From: IBM Mainframe Discussion List on behalf
of R.S.
> Sent: Tuesday, October 27, 2020 11:26 AM
> To: IBM-MAI
> And, fwiw, and fyi. The version of SHOWZOS I recently pulled from
> cbt seems not to observe the results of
> START ICEOPT,ICEPRM=00
Dave,
You can list the installation defaults with the following JOB. It will show
you the updated values either from parmlib or icemac.
//STEP0100 EXEC PGM=I
t; To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Syncsort to DFSORT - my time has come.
>
> After review of our SYNCSORT settings, I have:
> * JCL (ICEAM1)
> JCL
> DYNALOC=(3390,10)
> DYNAUTO=IGNWKDD
> EQUALS=NO
> ERET=ABEND
> SORTLIB=SYSTEM
> Y2PAST=0
> *
> * INV (ICEAM2)
&
After review of our SYNCSORT settings, I have:
* JCL (ICEAM1)
JCL
DYNALOC=(3390,10)
DYNAUTO=IGNWKDD
EQUALS=NO
ERET=ABEND
SORTLIB=SYSTEM
Y2PAST=0
*
* INV (ICEAM2)
INV
DYNALOC=(3390,10)
DYNAUTO=IGNWKDD
TD2
SMF=SHORT
TD3
SMF=SHORT
TD4
SMF=SHORT
From: IBM Mainframe Discussion List on behalf of
R.S.
Sent: Tuesday, October 27, 2020 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort to DFSORT - my time has come.
W dniu 27.10.2020 o 18:16, Gibney
> I can evaluate and transfer our long time SYNCSORT options. And the
manual does offer advice in this area.
Dave,
I sent you an email offline about DFSORT equivalent installation options
for syncsort. As always please feel free to send me any kind of questions
related to migration.
Tha
Thank you, and Sri.
I can evaluate and transfer our long time SYNCSORT options. And the manual
does offer advice in this area.
I've had this migration on my potential to-do list for some time. the incentive
has become the imminent expiration of the license with Precisely. We literally
W dniu 27.10.2020 o 18:16, Gibney, Dave pisze:
A fairly quick question. Are there sample ICEPRMxx members provided by IBM
for tailoring DFSORT? I don't find any in SICESAMP.
Yesterday, in my sandbox, I IPL'd with SICELPA, SORTLPA, SICELINK, SORTLIB
ahead of the SYNCSORT librari
Dave,
That is good new !! We don't have samples for ICEPRMxx, however our
Installation and Customization has good examples.
Check this link
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icei100/ice2ci_ICEPRM01_installation_default_overrides.htm#idg9282__iceprm01
Th
A fairly quick question. Are there sample ICEPRMxx members provided by IBM
for tailoring DFSORT? I don't find any in SICESAMP.
Yesterday, in my sandbox, I IPL'd with SICELPA, SORTLPA, SICELINK, SORTLIB
ahead of the SYNCSORT libraries and not ICEPRMxx. SHOWZOS shows DFSORT as
res
H,EQ,C'1'),
> BUILD=(1:1,710)),
> IFTHEN=(WHEN(1,1,CH,NE,C'1'),
> BUILD=(001:711,596,
>597:1,114))
> OUTFIL FNAMES=FL1ONLY,INCLUDE=(711,1,CH,EQ,C'1'), BUILD=(1,710)
> OUTFIL FNAMES=FL2ONLY,IN
597:1,114))
OUTFIL FNAMES=FL1ONLY,INCLUDE=(711,1,CH,EQ,C'1'), BUILD=(1,710)
OUTFIL FNAMES=FL2ONLY,INCLUDE=(711,1,CH,EQ,C'2'), BUILD=(712,596)
/*
Note: I have successfully run each BUILD individually without the IFTHEN to
verify I have the lengths of each correc
On Mon, 14 Sep 2020 22:54:46 + "Farley, Peter x23353"
<031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
:>E15 does NOT have to provide all data to the sort.
Depends on how SORT is called. Sometimes it does.
--
Binyamin Dissen
http://www.dissensoftware.com
Director, Dissen Software, B
rovides all the selection
logic you need, but not always.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Monday, September 14, 2020 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort E15 not receiving records
That page is mi
That page is misleading thank you
> On Sep 14, 2020, at 1:10 PM, Binyamin Dissen
> wrote:
>
> On Mon, 14 Sep 2020 12:56:21 -0400 Joseph Reichman
> wrote:
>
> :>I have a really stupid question in chapter 6 of the syncsort manual
> invoking syncsort from a pr
On Mon, 14 Sep 2020 12:56:21 -0400 Joseph Reichman
wrote:
:>I have a really stupid question in chapter 6 of the syncsort manual invoking
syncsort from a program on the second page of that chapter there is listed DD
statements for invoked sort merge. There is listed sortin as one of the
: Syncsort E15 not receiving records
I have a really stupid question in chapter 6 of the syncsort manual invoking
syncsort from a program on the second page of that chapter there is listed DD
statements for invoked sort merge. There is listed sortin as one of the DD
statements. If I am doing the reading
I have a really stupid question in chapter 6 of the syncsort manual invoking
syncsort from a program on the second page of that chapter there is listed DD
statements for invoked sort merge. There is listed sortin as one of the DD
statements. If I am doing the reading then when does it have to
On Mon, 14 Sep 2020 11:29:54 -0400 Joseph Reichman
wrote:
:>I have a VB file Im trying to process
:>I calling syncsort from a program and have a E15 exit
:>Im running this all under test to get the kinks out
:>The first time The exit is invoke Register one
:>At +0 is 0 m
Hi
I have a VB file I’m trying to process
I calling syncsort from a program and have a E15 exit
I’m running this all under test to get the kinks out
The first time The exit is invoke Register one
At +0 is 0 meaning I am not selecting anything. I checked by include and it
looks right. I
Joseph,
maybe this helps or may not.
If you're using SYNCSORT, the product can "identify" multiple dataset (up
to 100) by using the "Multiple Input Files" (Chapter 12 on V2.1 manual).
This allows the programmer to specify different INCLUDE/OMIT for every of
the differe
le and the
> bad data in another.
>
> Chris Blaicher
> Technical Architect
> Precisely.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Friday, September 11
half
Of Joseph Reichman
Sent: Friday, September 11, 2020 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syncsort E11 exit
[ External - This message originated Externally. Use proper judgement and
caution with attachments, links, or responses. ]
The data is mostly binary
Huge vb files and lots
The data is mostly binary
Huge vb files and lots of them
> On Sep 11, 2020, at 2:26 PM, Jousma, David
> <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
>
> Syncsort is a great tool, but why reinvent the wheel? Why not just run
>
> //
Syncsort is a great tool, but why reinvent the wheel? Why not just run
//SEARCH EXEC PGM=ISRSUPC,
//PARM=(SRCHCMP,'ANYC')
//NEWDD DD DSN=concat.dsn1.DEV1,DISP=SHR
// DD DSN=concat.dsn2,DISP=SHR
//OUTDD
I am using syncsort to search for records
So let’s say I concatenate 100 files
And the data I’m looking for is let’s say in the 50 th file
To get The dataset name of the 50 th file
I could do RDJFCB for the dcb with exlst type X’07’ and the dataset name that
I’m currently processing would
The E11 exit will not look at any file. It is a, shall we say, dumb exit.
If your question is what files Syncsort will look at in analyzing a
concatenated SORTIN, it will look at all of them. One of the things it is
trying to do is determine the input file size and the access method required
> Programmers Guide.
>
> Chris Blaicher
> Technical Architect
> Precisely.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Friday, September 11, 2020 10:48 AM
>
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Joseph Reichman
Sent: Friday, September 11, 2020 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Syncsort E11 exit
[ External - This message originated Externally. Use proper judgement and
caution with attachments, links, or responses. ]
Hi
The documentation isn’t real clear on this exit outside of the fact that it
states they are entered in the beginning of their associated phase
I would like to use this exit to dynamically add files to sortin
Would any one gave more info on this exit
Thanks
On Wed, 9 Sep 2020 14:31:24 -0700, Sri h Kolusu wrote:
>
>>>Are complicated Boolean expressions supported?
>
>Yes. Check this link
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/ice2ca_Relational_condition.htm
>
Thanks. I see:
AND statements are e
>>>Suppose the programmer wishes to compare to binary zeroes,
Gil,
Comparing to binary zeros will let you include short records who have
length less than 21 bytes. But that is an easy fix.
Since we are dealing with VB records, the actual length is in RDW so you
can add the RDW validation in the
On Wed, 9 Sep 2020 13:15:43 -0700, Sri h Kolusu wrote:
>
>VLSCMP tells DFSORT that you want to temporarily replace any missing
>compare field bytes with binary zeros, thus allowing the short fields to be
>validly compared (the binary zeros are not kept for the output records).
>
>So use the followi
> A Google search seems to find those as SYNCSORT options but not as
> DFSORT options. Is that right? But on:
Gil,
Both products have different parms.
>>> What other comparison operators are available. For example, I'd
> be interested in whether: OMIT COND=(21,8,CH,NE
DFSORT and SYNCSORT options are just not the same for this feature.
The wording would seem to imply that *any* comparison will be treated as false.
The SYNCSORT description for VLTESTI=2 seems to imply the same behavior (note
the last sentence in this quote):
"When VLTESTI=2 is specified
On Wed, 9 Sep 2020 17:19:55 +, Farley, Peter x23353 wrote:
>Use these PARM options for SYNCSORT to allow field references beyond the
>actual input record length:
>
>PARM=VLLTEST=2,VLTESTI=2'
>
>One of your VB input records is less than 17 bytes long (21 - 4 = 17).
>
Thanks
> On Sep 9, 2020, at 1:20 PM, Farley, Peter x23353
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> Use these PARM options for SYNCSORT to allow field references beyond the
> actual input record length:
>
> PARM='VLTEST=2,VLTESTI=2'
Use these PARM options for SYNCSORT to allow field references beyond the actual
input record length:
PARM='VLTEST=2,VLTESTI=2'
One of your VB input records is less than 17 bytes long (21 - 4 = 17).
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf
1 - 100 of 305 matches
Mail list logo
