I have hat set per the instructions. I really am now leaning towards my programmers wouldn't have got the CEEDUMP in this case, has they still been using the other sort product. But, since DFSORT is new, it is a viable culprit. And, really, the program's diagnostic messages should have been sufficient for them to solve their issue without the CEEDUMP anyway.
> -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Sri h Kolusu > Sent: Wednesday, November 18, 2020 5:15 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: How to get CEEDUMP with DFSORT? > > > In the case my programmers found, there was a call for a user abend > > with value of 36. As I think on this, I have no idea for sure that > > behavior from Syncsort would have been different. > > Dave, > > I believe I sent out the migration documents which lists the equivalent > parms for DFSORT. In this particular case if you want DFSORT to behave like > the other product , then please refer to sdniopt.txt file and the parm you > are looking for is ERET parm. It is equivalent for PGMRC16/NORC16/RC16 > > Thanks, > Kolusu > DFSORT Development > IBM Corporation > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
