volumes in the master files, I have to generate
control statements to process the volume.
In this situation, I want to set zero-return code to indicate additional
process is required.
If all volumes in the master file are processed, I want to set zero return
code.
I already have made a DFSORT
Re: How can I set Non-zero return code in DFSORT when SORTOUT record
> count is not zero
>
> What problem are you trying to solve by doing this?
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSE
How can I set Non-zero return code in DFSORT when SORTOUT record
> count is not zero
>
> Hello
>
> I'm looking for a way to set Non-zero return code in DFSORT, when record count
> of SORTOUT is not zero.
>
> I know that setting non-zero return code when SORTOUT recor
Hello
I'm looking for a way to set Non-zero return code in DFSORT, when record
count of SORTOUT is not zero.
I know that setting non-zero return code when SORTOUT record count is zero.
Your help would be highly appreciated.
--
全先 実 - Minoru Massaki (M*M)
E-mail: mmass...@gmai
5~27200.00~USD~Process~Submitted~~PS0323
0006~2193.00~USD~Process~Submitted~~USHSR1~
00178909~750.00~USD~Process~Dropped~Invalid Buyer
//SORTOUT DD SYSOUT=*
//SYSINDD *
OPTION COPY
INCLUDE COND=(1,80,SS,EQ,C'Dropped')
//*
Thanks,
Kolusu
DFSORT Development
IBM Corpor
Changing the data to match the condition, rather than changing the condition to
match the data, is... unusual. Was the request to "also change any lowercase in
the data to uppercase"? If not, it is easier, and less resources are used, to
just change the search value, as suggested a couple of tim
Ron Thomas wrote:
>Ok i have translated the whole to Uppercase as below and then extracted the
>records .
>SORT FIELDS=COPY
>OUTREC FIELDS=(1:1,2996,TRAN=LTOU)
Hmmm, thanks. Interesting that you need to first uppercase everything and then
do a search afterwards.
I'm glad for your part your i
Ok i have translated the whole to Uppercase as below and then extracted the
records .
SORT FIELDS=COPY
OUTREC FIELDS=(1:1,2996,TRAN=LTOU)
Thanks
Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send ema
Ron Thomas wrote:
>Thanks a lot . It worked like a charm .
What solution worked for you? Please be kind to post it.
This is just for archive purposes and searches in the future.
Groete / Greetings
Elardus Engelbrecht
--
For I
Thanks a lot . It worked like a charm .
Regards
Ron T
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ron Thomas wrote:
>Ok. I have coded as below as the LRECL is 2996 and it returned empty file .
>Could you please let me know where the issue is ?
>INCLUDE COND=(1,2996,SS,EQ,C'DROPPED')
Your sample input has 'Dropped' your INCLUDE has 'DROPPED'. Check your case.
Also check that your job has th
You can use the SUBSTRING COMPARISON TEST to determine if the string "Dropped"
appears anywhere in the record by choosing suitable values for p1 and m1. The
description starts on page 112 of my copy of DFSORT Application Programming
Guide.
> -Original Message-
> Fro
MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Extract records
Ok. I have coded as below as the LRECL is 2996 and it returned empty file .
Could you please let me know where the issue is ?
INCLUDE COND=(1,2996,SS,EQ,C'DROPPED')
Thanks
Ron T
Ok. I have coded as below as the LRECL is 2996 and it returned empty file .
Could you please let me know where the issue is ?
INCLUDE COND=(1,2996,SS,EQ,C'DROPPED')
Thanks
Ron T
--
For IBM-MAIN subscribe / signoff / archive acc
I'm no expert, but OUTFIL and OUTREC have a keyword called PARSE that can
probably do what you want. ICETOOL/SYNCTOOL might make it easier, too.
sas
On Tue, Feb 7, 2017 at 10:02 AM, John McKown
wrote:
> On Tue, Feb 7, 2017 at 8:44 AM, Ron Thomas wrote:
>
> > Hi . We have a below file , and he
On Tue, Feb 7, 2017 at 8:44 AM, Ron Thomas wrote:
> Hi . We have a below file , and here i want to extract all records that
> have a string value "Dropped" , the value is not coming in to any fixed
> position .
> Could some one let me know how to get the records extracted ?
>
>
> 0003~94800.0
Ron Thomas wrote:
>Hi . We have a below file , and here i want to extract all records that have a
>string value "Dropped" , the value is not coming in to any fixed position .
>Could some one let me know how to get the records extracted ?
Easy!
>0003~94800.00~USD~Process~Submitted~~F0
>0
Could you do it in REXX. Might be easier
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Thomas
> Sent: Tuesday, February 07, 2017 7:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DFSORT Extra
Hi . We have a below file , and here i want to extract all records that have a
string value "Dropped" , the value is not coming in to any fixed position .
Could some one let me know how to get the records extracted ?
0003~94800.00~USD~Process~Submitted~~F0
0004~15640.00~USD~Process~S
Did you intend merely to quote my entire message with no additons
or comments?
On Fri, 30 Dec 2016 19:38:50 +, scott Ford wrote:
>On Wed, Dec 21, 2016 at 6:33 AM Paul Gilmartin wrote:
>> On Wed, 21 Dec 2016 13:53:11 +0100, Massimo Biancucci wrote:
>>
>> >If you hav
On 14/10/2016 9:10 PM, Kirk Wolf wrote:
JZOS does have native code (not byte code) that is part of the JVM which is
zIIP eligible.
Right. So the JNI C/C++ RTL functions run on a zIIP but as I thought
DFSORT running in a spawned process does not. DFSORT could have been
executed with a simple
JZOS does have native code (not byte code) that is part of the JVM which is
zIIP eligible.
The JZOS DFSORT wrapper spawns DFSORT in a separate process, which is not
part of the JVM and is therefore not zIIP eligible.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Fri, Oct 14, 2016 at
DFSORT is not executing as bytecode in a JVM so no.
Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerw
I'm guessing the answer is no judging by the fact that JZOS spawns a
jdfsort UNIX process to do the sort and if it did everybody would just
write Java wrappers to
sort data sets thus reducing the cost of running DFSORT.
-
Bill Woodger wrote:
>It would be ironic if Elardus followed your advice, only to find that his
>IEBGENER is an alias of ICEGENER and that DFSORT will be used for operations
>without any IEBGENER control cards.
I'm aware of ICEGENER and such. In fact, CustomPac includes some
If there's only one thing to change per line (maximum, or limit) I always use
DO=1 on the FINDREP.
If there's a limit to where the data can start, end, or both, there's STARTPOS
and ENDPOS.
Use IFTHEN=(WHEN=(logicalexpression) to only allow the FINDREP to operate on
the expected records. This
of the midnight pitfall, then DFSORT already
covers that. If you used DFSORT date formats (Date1 thru Date5 ), DFSORT
reads the TIME macro once and stores the value. It is not changed in
between despite how many times you have the references of Date parm in
your control cards.
Thanks,
Kolusu
Sri h Kolusu wrote:
>You just need to define a symbol for the current date and you can use it in
>FINDREP. You do not code OPTION COPY when you use COPY verb of ICETOOL.
>Here is a sample
>//SYMNAMES DD *
>CURRDATE,S'&LYR4.&LMON.&LDAY'
>//SORTCNTL DD *
> OUTREC FINDREP=(IN=C'MMDD
system symbols
>then you would get the local time. DFSORT also has several date formats
>and it is based on the time the step ran.
>
It's probably covered, depending on how "the time the step ran" is obtained.
>If you meant that a job that started at 11:59:59 PM and
Paul, not only has DFSORT had access to system symbols for a long time, it has
as equal an access to the new substitution of symbols in instream data as
anything else. This does depend on the data being instream. The availability of
system symbols within DFSORT allows them to be used even
Thanks for that :) I'm pretty sure this will be the best laugh I'll have
all day, and it's only 9am.
Richard Pinion wrote:
That should be "FAMILIAR" not "FAMILAR"!
--- rpin...@netscape.com wrote:
From: Richard Pinion
To: IBM-MAIN@
>> You could consider: //SYSUT1 DD *,SYMBOLS= instead of ICETOOL and
substitute the dynamic system symbols for &YYMMDD and &HHMMSS, however:
Paul,
DFSORT has the ability to read system symbols defined here
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e2c2/2
That should be "FAMILIAR" not "FAMILAR"!
--- rpin...@netscape.com wrote:
From: Richard Pinion
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT - ICETOOL - Search for text and replace with date
Date: Tue, 13 Sep 2016 08:57:22 -0700
That should be &
That should be "familar" not "family"!
--- rpin...@netscape.com wrote:
From: Richard Pinion
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT - ICETOOL - Search for text and replace with date
Date: Tue, 13 Sep 2016 08:56:07 -0700
While not dire
While not directly related to your question, but are
you family with XMITIP from Lionel B. Dyck? Real handy
stuff for emailing and attachments from the mainframe.
--- skol...@us.ibm.com wrote:
From: Sri h Kolusu
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT - ICETOOL
On Tue, 13 Sep 2016 10:36:18 -0500, Elardus Engelbrecht wrote:
>
>Now, a client asked whether it is possible to insert run date in the file
>names of those attachments for easy retrieval at a later stage.
>
>//INVOER DD *
ORT)
//SORTCNTL DD *
OUTREC FINDREP=(IN=C'MMDD',OUT=CURRDATE)
/*
btw is there a reason as to why you chose ICETOOL?
Further if you have any questions please let me know
Thanks,
Kolusu
DFSORT Development
IBM Corporation
IBM Mainframe Discussion List wrote
Good day to all DFSORT gurus
Background: I have setup an automated e-mail reporting system which grab
reports from various inputs, then I use IEBGENER to build up one PS file
containing data in this sequence: e-mail body - report - boundary data - next
report - ... etc ...
(In this way I can
Actually, John didn't get to specify what he had. The ESDS is Frank's example.
Doesn't stop us discussing Frank's example.
The particular "best" solution for one-or-more sequential files with
one-or-more VSAM in SORT will be down to the exact situation persisting (ie a
"generic" solution could
In this case, the first input is an ESDS, so it probably won't be in
key order. I assume the first repro with one record with the highest
key like initilizing a SDSP would be needed.
On Mon, Sep 5, 2016 at 4:26 PM, Bill Woodger wrote:
> Well, REPRO is pretty versatile. You can take some source d
on behalf of
Farley, Peter x23353
Sent: Saturday, September 3, 2016 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT mixed VSAM & sequential.
Frank,
I can't help but respond to you on this. I have personally encountered this
exact attitude with respect to advanced SORT capab
Well, REPRO is pretty versatile. You can take some source data (in key order)
and insert it into a KSDS.
If the new keys are all handily higher than the highest existing key, things
should go fairly smoothly. If the keys are distributed evenly across the
existing data, there will be a certain a
On 2016-09-05, at 14:50, Mike Schwab wrote:
> If the output dataset can be a KSDS, how about defining the KSDS then
> repro the inputs to the KSDS?
>
Isn't REPRO the tool of choice for flattening a VSAM data set?
Does SMP/E deliver any VSAM data sets, other than by creating them
with UCLIN and
t *can* be done in an exit.
>
> What I'm saying is that last time I tried it, it was not a good way to do it.
>
> My exit was in COBOL. COBOL IO for a KSDS is considerably slower than DFSORT
> itself does it, and REPRO is even better at flattening a KSDS.
>
> On top of
ique
> can be taught to less experienced programmers who may be called upon to
> maintain the control input at a later date. We are talking about fairly
> simple control syntax here which is very well documented, including
> flowcharts of the processes (thank you DFSORT documentation team
about fairly simple control
syntax here which is very well documented, including flowcharts of the
processes (thank you DFSORT documentation team). It is far from being rocket
science.
IMHO the failure here is a management failure to support the concept of keeping
the less experienced members o
-Original Message-
>From: Frank Swarbrick
>Sent: Sep 2, 2016 3:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: DFSORT mixed VSAM & sequential.
>
>Can you both sort and merge in a single job step?
You can use ICETOOL as the driver with the SO
On Fri, 2 Sep 2016 19:53:28 -0500, Paul Gilmartin wrote:
>On Fri, 2 Sep 2016 18:48:41 -0500, Bill Woodger wrote:
>>
>>... It would not be nice ... [to] ... replicate what is already available in
>>DFSORT and which would be used for the sequential datasets anyway (would
d. But thanks for trying!
>
A simple COBOL program could do the sort and with appropriate
copybooks shouldn't be to hard to code. These days the amount of
memory taken by a COBOL program using the SORT verb is trivial
compared to the size of the address space.
Clark Morris
>
>Seems
DFSORT "passes" the exit a number of parameters, which the exit has to
understand, act upon, and supply data (record at a time).
If you could "call" REPRO and have it give you a record at a time, that would
suffice, but I don't think REPRO has a way of doing that.
On Fri, 2 Sep 2016 18:48:41 -0500, Bill Woodger wrote:
>
>... It would not be nice ... [to] ... replicate what is already available in
>DFSORT and which would be used for the sequential datasets anyway (would there
>be benefit in piping those just for the heck of it?).
>
(I
On Fri, 2 Sep 2016 18:19:42 -0500, Bill Woodger wrote:
>
>My exit was in COBOL. COBOL IO for a KSDS is considerably slower than DFSORT
>itself does it, and REPRO is even better at flattening a KSDS.
>
>On top of the IO differences, you have the overhead of the exit.
>
Might one
benefit from the internal knowledge to make the process zippy, and it would not
be nice to have whatever that is having a whole bunch of coding possibilities,
given that you would replicate what is already available in DFSORT and which
would be used for the sequential datasets anyway (would there b
than DFSORT
itself does it, and REPRO is even better at flattening a KSDS.
On top of the IO differences, you have the overhead of the exit.
Just because it can be done, doesn't mean it is a good idea.
OK, I could at least have recommended an evaluation, but I'd expect
REPRO-to-flat vs EX
>unload the VSAM to sequential, then sort it with the other sequential data
>set. But that is just more work. I wonder why DFSORT doesn't have a way to
>handle this.
>
As I watch this thread spin out, it seems to me that this sort of task is
a natural use for CMS Pipelines or Batchpi
Can you both sort and merge in a single job step?
From: IBM Mainframe Discussion List on behalf of
Martin Packer
Sent: Friday, September 2, 2016 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT mixed VSAM & sequential.
Unless I misunderstand there
; (a DLBL) for each input dataset. SORTIN01, SORTIN02, etc.
Yes, on z/OS DFSORT the SORTINnn are used for MERGE. On z/VSE they are not.
As far as I can tell, the z/VSE DFSORT is... somewhat behind the z/OS DFSORT.
Frank, if you've not been using z/OS DFSORT for long, it is radically differ
he IFTHEN statement your output would be empty as
there are no records that matched. :)
Thanks,
Kolusu
DFSORT Development
IBM Corporation
From: Martin Packer
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 09/02/2016 01:45 PM
Subject:Re: DFSORT mixed VSAM & sequential.
Sent by:
Unless I misunderstand there's a slight error in Sri Hari's sample: The
IFTHEN should have C'B' rather than C'2'.
SORTINxx is what DFSORT MERGE uses. That syntax might be confusing. But
then again maybe MERGE will work for you. (I doubt it.)
Cheers, Martin
Marti
That is certainly an interesting trick, and one I can't imagine I will be using
any time soon. Doing a copy to a flat file first is much more straight
forward. But thanks for trying!
Seems to me DFSORT should support the same option that DFSORT/VSE supports,
which is multiple SOR
2016 9:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFSORT mixed VSAM & sequential.
>
>> On Aug 31, 2016, at 3:55 PM, Frank Swarbrick
>> wrote:
>>
>> FWIW, here his my example:
>>
>> //STEP00 EXEC PGM=IDCAMS
>> //FILEIN DD DSN=&
Frank,
Thanks for sending the DCB properties of the files involved offline. Based
on the DCB properties here is a DFSORT JOB that will give you the desired
results without having you copy the VSAM cluster to a sequential file.
We will be using the trick of JOINKEYS where you can have two
Ed, there was no response from you in your response below. :-)
From: IBM Mainframe Discussion List on behalf of
Edward Gould
Sent: Thursday, September 1, 2016 9:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT mixed VSAM & sequential.
> On Aug 3
them, because
the functionality available in DFSORT allows you do to so many things that you
may "traditionally" have had to consider doing by a program (including by an
exit).
If someone insists on "one step" then get them to sign for the extra cost, and
write your exit. Of co
Bill Woodger wrote:
> ... an exit is the wrong way to go.
You can say that again. Wait until an upgrade or fix is placed, then you will
see that exit is the wrong way.
Of course your milage may vary. Depending on your needs, you may indeed use an
exit.
Ok, I am 'exit'-ing this thread. ;-)
It
stuck with using an exit, but for any other than those limits in
this case (and the vast majority of cases) then with the modern DFSORT (which
has been around a long time) an exit is the wrong way to go.
--
For IBM-MAIN subscribe
> On Sep 1, 2016, at 8:15 PM, Edward Gould wrote:
>
> John:
>
> An E35 exit can do this (I am pretty sure).
>
> Ed
>
——SNIP———
John,
I didn’t understand your needs very well.
Perhaps an E15 can handle your needs .
Ed
DD *
> SORT FIELDS=(1,10,PD,A,13,4,PD,A,17,4,PD,A,11,2,PD,A),EQUALS
> //SYSOUT DD SYSOUT=*
>
>
> ____
> From: IBM Mainframe Discussion List on behalf of
> Sri h Kolusu
> Sent: Wednesday, August 31, 2016 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.ED
VSAM file. I don't see any way to do this easily. We plan to
> unload the VSAM to sequential, then sort it with the other sequential data
> set. But that is just more work. I wonder why DFSORT doesn't have a way to
> handle this.
>
> --
> Unix: Some say the learning c
PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT mixed VSAM & sequential.
John,
As Bill mentioned it is the access methods that is preventing the
concatenation of the VSAM files.
If you can send your existing job and control cards may be I can suggest
an alternative to copyin
AM to sequential file
>
I appreciate the offer. The job has not yet been written. The programmer
actually asked _before_ doing any work.
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
--
Unix: Some say the learning curve is steep, but you only have to
: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT mixed VSAM & sequential.
SyncSort allows use of SORTINnn DDs, so a VSAM dataset can have its own DD.
There aren't many places you can naturally concatenate VSAM. It is not DFSORT
preventing it.
Using a different key for the VSAM data? Otherwise i
John,
As Bill mentioned it is the access methods that is preventing the
concatenation of the VSAM files.
If you can send your existing job and control cards may be I can suggest
an alternative to copying VSAM to sequential file
Thanks,
Kolusu
DFSORT Development
IBM Corporation
From
What I was alluding to is that a surprising number of people want to SORT a
KSDS on its key. I've assumed John's are not those people.
Yes, issues with concatenation are general. SAS I am led to believe allows it
--
For IBM-MAIN
Bill Woodger wrote:
>> There aren't many places you can naturally concatenate VSAM. It is not
>> DFSORT preventing it.
It is the access method for these types of datasets which is the problem. I
believe you can't concatenate both PS and VSAM as one DD as input.
>&g
On Wed, Aug 31, 2016 at 12:29 PM, Bill Woodger
wrote:
> SyncSort allows use of SORTINnn DDs, so a VSAM dataset can have its own
> DD.
>
> There aren't many places you can naturally concatenate VSAM. It is not
> DFSORT preventing it.
>
> Using a different key for the
SyncSort allows use of SORTINnn DDs, so a VSAM dataset can have its own DD.
There aren't many places you can naturally concatenate VSAM. It is not DFSORT
preventing it.
Using a different key for the VSAM data? Otherwise it is already sorted anyway.
REPRO you may find substantially
We ran in to this issue during our preparation for migration to z/OS from VSE
in 2010. I seem to recall Syncsort saying they were making a change to support
this, but I don't recall anything similar with DFSORT. We still went with
DFSORT, but we still have to copy our VSAM files to flat
l data
set. But that is just more work. I wonder why DFSORT doesn't have a way to
handle this.
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha!
IFTHEN=(WHEN=INIT,
OVERLAY=(5:5,44,SQZ=(SHIFT=LEFT))) $ SQUEEZE ALL DATA
OUTFIL REMOVECC,NODETAIL,VTOF,BUILD=(50X),
HEADER2=(C'IP,LOCAL ID,COMMAND,REMOTE ID,COUNT'),
SECTIONS=(5,44,
TRAILER3=(5,44,COUNT=(M10,LENGTH=6)))
//*
Further if you have any
I've created an FTP client report in comma-delimited format from SMF 118s (yes,
I know they should be capturing 119s but they aren't yet, and this isn't about
that).
To make the IP address readable, I used an edit on each byte of the address and
the SQZ function to put them back together. Howe
What I do for my very large DB2 SAS Processes is use the following
//DFSPARM DD DISP=SHR,DSN=SYSS.DFSORT.CNTLLIB(DFSORT)
In the DFSORT member I just have coded
OPTION DYNALLOC=(,32)
I have removed all SORTWKxx or variation (you may be using SASSWKxx) in the SAS
Proc or MXG Proc
OK, but you don't have to do it for everything. Most things aren't giving you a
problem. Small files aren't the same issue as larger ones.
Diversion between actual amount of data and estimated amount of data affects
performance, not just workspace allocation.
I'd ask IBM D
I see your point, but this is unachievable. We have thousands of SAS jobs, lots
of them existing of complex SAS programs, doing multiple PROC SORTs, sorting
data that varies in size over the jobs and days depending on how much data must
be processed.
One central setting to help DFSORT recover
Which is why I'm suggesting providing additional information on the DFSPARM DD.
Because if DFSORT is not reading the data, it doesn't know so much. You can
fill in some gaps for it. Allowing DFSORT to do the allocations better is
probably an advantage over allowing DFSORT t
The problem is not that SAS does not provide DFSORT with info about the data to
be sorted, it provides DFSORT with incorrect info.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bill Woodger
Sent: 26 July, 2016 11:10
To: IBM
You could look at using DFSPARM in your SAS steps,
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/dfsparm.htm
When invoked from another program, and when that other program is
reading/providing the data to DFSORT, you can help DFSORT out by providing
things
Hi Dave,
Thanks for the explanation.
We sometimes have problems with very large sorts from SAS 9.2, which known to
provide DFSORT with incorrect information about the amount of data to be
sorted. DFSORT then tries to recover from B37 abend which is mostly but not
always successful.
So I think
The dynamic allocation space calculations are going to be based on the
DYNALLOC number. As a simple example, if DFSORT calculates that it needs
6,000 cylinders of work space, and DYNALLOC=4 with DYNAPCT=50, it will need
4 volumes with at least 1500 cylinders of free space. But with DYNALLOC=6
Hello DFSORT experts,
The DYNALLOC description says that the default number of SORTWKs is 4 and not
to specify an unnecessary high number.
The DYNAPCT parameter allocates an extra number of SORTWKs to be used in case
the DYNALLOC number of SORTWKs appears to be not enough.
I can:
a
-8234 | M: 512-627-3803
E: cblaic...@syncsort.com
www.syncsort.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ed Jaffe
Sent: Thursday, July 21, 2016 1:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT and zIIP
On 7/21/2016
On 7/21/2016 10:07 AM, Elardus Engelbrecht wrote:
Ed Jaffe wrote:
They probably don't want to call E15/E35 exits in SRB mode, ...
Excellent catch! Running an exit while sitting on zIIP is an interesting
scenario. H, very very interesting, what will happens when you try out that
little tr
Ed Jaffe wrote:
>They probably don't want to call E15/E35 exits in SRB mode, ...
Excellent catch! Running an exit while sitting on zIIP is an interesting
scenario. H, very very interesting, what will happens when you try out that
little trick?
And if you're sitting in a micro code while ru
On 7/20/2016 11:25 PM, Timothy Sipples wrote:
To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product category.
Subject to periodic review as technologies change and evolve.
Assuming they're constrained by the same
On 7/20/2016 10:45 PM, Peter Hunkeler wrote:
I'm longing for the day when also the zIIPs disappear again and IBM
has found a better way to charge software license fees.
I agree it would be GREAT(!) if kneecapping of CPs was removed and
replaced with PER CORE software charging like other platf
W dniu 2016-07-21 o 08:25, Timothy Sipples pisze:
Paul Gilmartin wrote:
I find it hard to believe that optimization of revenue was not a
consideration.
To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product categor
Paul Gilmartin wrote:
>I find it hard to believe that optimization of revenue was not a
consideration.
To my knowledge, no. zIIP exploitation sometimes makes technical sense, and
sometimes it doesn't. Even within the same general product category.
Subject to periodic review as technologies change
>For DB2 Sort for z/OS, zIIP
--
Peter Hunkeler
>exploitation makes technical sense. For DFSORT -- except for exploiting
>zIIPs on behalf of DB2 utilities and in other ancillary ways -- it doesn't
>seem to make technical sense.
All this speciality engine thing never ma
A place (long ago and far away) used both.
For cost savings we decided on DFSORT (long story omitted).
What we found was that for *some small percent* the control cards weren’t
compatible.
This was long before zIIP and once we got the control card issue resolved we
were happy with DFSORT.
The
wrote:
> On Wed, 20 Jul 2016 14:47:49 +0800, Timothy Sipples wrote:
>
> >Different products mean different technical considerations and
> >optimizations. It's just that simple. For DB2 Sort for z/OS, zIIP
> >exploitation makes technical sense. For DFSORT -- except for e
901 - 1000 of 1476 matches
Mail list logo
