Re: File Processing

2012-10-18 Thread Lizette Koehler
How are your jobs submitted when the files arrive? Do you use a scheduling software that can monitor for the dataset names? Or is it a manual submission? Are you going to use hard coded dataset names in the JCL or are you going to use symbolics? Are all files being read at the same time by

Re: File Processing

2012-10-18 Thread Charles Mills
Two problems here, right? 1. How can a COBOL program handle an input file with a variety of fixed (?) record lengths. 2. How can a COBOL program encrypt a field? Answers: 1. I'm not much of a COBOL guy but I am going to guess you need three different FD's and a PARM= that tells it which one

Re: File Processing

2012-10-18 Thread McKown, John
First option: use DFSORT (one step per DSN) to copy your input data. You can use the OUTREC control card to force the data to be of a standard length, padding with blanks or x'00' or whatever. Then process the new, padded, data sets using normal COBOL. === Now, if you could make the file

Re: File Processing

2012-10-18 Thread Kirk Talman
/18/2012 02:06:48 PM: From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/18/2012 02:07 PM Subject: Re: File Processing Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Two problems here, right? 1. How can a COBOL program handle an input file

Re: File Processing

2012-10-18 Thread Paul Gilmartin
On Thu, 18 Oct 2012 12:43:00 -0500, Ron Thomas wrote: I have a requirement where the input file is comming from a thrid party system and each of the files is having different logical record lengths. Once the file cam i have to use the file and encrypt the customer number that is there.

Re: File Processing

2012-08-08 Thread Scott Ford
It wasn't easy. It was a Macro CICS shop on top of that, we were doIng a lot of CICS transactions and swore it was our code/IBM's. Later it was pretty funny. I never mind ppl not knowing that's not a big issue, but blaming without knowing or thinking you know well..what can I say ... Scott

Re: File Processing

2012-08-08 Thread Ed Gould
On Aug 7, 2012, at 7:12 PM, Scott Ford wrote: I love it .I had a COBOL programmer bet me that our DOS/VSE system on our 4381 was causing her abend. She bet me a dinner, well I collected, brought her in and did a instruction trace pointed right to her code Scott ford

Re: File Processing

2012-08-07 Thread Hal Merritt
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Thursday, August 02, 2012 1:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing The current abend is SOC7 module needs to run in production. The input file is comming from a third party vendor and some

Re: File Processing

2012-08-07 Thread Sam Siegel
statement regarding the cause of the error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Thursday, August 02, 2012 1:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing The current abend is SOC7

Re: File Processing

2012-08-07 Thread Ed Gould
[mailto:IBM- m...@listserv.ua.edu] On Behalf Of Ron Thomas Sent: Thursday, August 02, 2012 1:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing The current abend is SOC7 module needs to run in production. The input file is comming from a third party vendor and some reason the data isn

Re: File Processing

2012-08-07 Thread McKown, John
@LISTSERV.UA.EDU Subject: Re: File Processing Hal: A long time ago (when MVS first came out) a programmer got an S0C7 and brought it to us as it was a system abend for it was our problem. I pointed out while picking up the phone to his boss's boss and telling them both to read the FM and to get

Re: File Processing

2012-08-07 Thread Scott Ford
Gould Sent: Tuesday, August 07, 2012 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing Hal: A long time ago (when MVS first came out) a programmer got an S0C7 and brought it to us as it was a system abend for it was our problem. I pointed out while picking up

Re: File Processing

2012-08-07 Thread Graham Hobbs
07, 2012 2:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing Hal: A long time ago (when MVS first came out) a programmer got an S0C7 and brought it to us as it was a system abend for it was our problem. I pointed out while picking up the phone to his boss's boss and telling them

Re: File Processing

2012-08-07 Thread Shmuel Metz (Seymour J.)
In 39235829-1d9d-411b-bb12-6b739e1c2...@yahoo.com, on 08/07/2012 at 08:12 PM, Scott Ford scott_j_f...@yahoo.com said: I love it .I had a COBOL programmer bet me that our DOS/VSE system on our 4381 was causing her abend. She bet me a dinner, well I collected, brought her in and did a

Re: File Processing

2012-08-07 Thread Shmuel Metz (Seymour J.)
In a6b9336cdb62bb46b9f8708e686a7ea0115baa1...@nrhmms8p02.uicnrh.dom, on 08/07/2012 at 02:27 PM, McKown, John john.mck...@healthmarkets.com said: We had DOS/VS at that time. The DOS person said that DOS would occasionally kill his programs as well. With the words USER REQUESTED TERMINATION. The

Re: File Processing

2012-08-07 Thread Shmuel Metz (Seymour J.)
In CAFMxNW+NmuenEh0Tem8RnQdZ=jtgauuhsoilq6iussgrltr...@mail.gmail.com, on 08/07/2012 at 12:03 PM, Sam Siegel s...@pscsi.net said: An 0c7 is a data exception error detected by the hardware. No; it is an ABEND detected by the Program FLIH when there is no SPIE to catch interupt code 7. Without

Re: File Processing

2012-08-07 Thread Sam Siegel
On Tue, Aug 7, 2012 at 6:51 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In CAFMxNW+NmuenEh0Tem8RnQdZ=jtgauuhsoilq6iussgrltr...@mail.gmail.com, on 08/07/2012 at 12:03 PM, Sam Siegel s...@pscsi.net said: An 0c7 is a data exception error detected by the hardware. No; it

Re: File Processing

2012-08-02 Thread Lizette Koehler
Ron, Are you using BUFNO or other type of buffering to help this process? Is it a straight sequential read or how are processing the records? What is the abend? Is it an MVS abend or application abend? Sometimes tuning the JCL or process can avoid abends - depending on what they are.

Re: File Processing

2012-08-02 Thread Sam Siegel
On Thu, Aug 2, 2012 at 11:05 AM, Ron Thomas ron5...@gmail.com wrote: The current abend is SOC7 module needs to run in production. The input file is comming from a third party vendor and some reason the data isn the file is corrupted, the program might get abended. We need a process to work

Re: File Processing

2012-08-02 Thread Farley, Peter x23353
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Thomas Sent: Thursday, August 02, 2012 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing The current abend is SOC7 module needs to run in production. The input file is comming from a third party vendor and some

Re: File Processing

2012-08-02 Thread Steve Comstock
Of McKown, John Sent: Thursday, August 02, 2012 1:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing Why not fix your processing program to not abend? In COBOL, try verifying the record data before processing it. Perhaps a IF NOT NUMERIC type test. IMNSHO, writing a program which simply

Re: File Processing

2012-08-02 Thread John Gilmore
John McKown writes begin extract Why not fix your processing program to not abend? In COBOL, try verifying the record data before processing it. Perhaps a IF NOT NUMERIC type test. end extract and it would be impossible to disagree with the substance of this recommendation. There are, however,

Re: File Processing

2012-08-02 Thread McKown, John
To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing John McKown writes begin extract Why not fix your processing program to not abend? In COBOL, try verifying the record data before processing it. Perhaps a IF NOT NUMERIC type test. end extract and it would be impossible

Re: File Processing

2012-08-02 Thread Clark Morris
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, August 02, 2012 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File Processing John McKown writes begin extract Why not fix your processing program to not abend? In COBOL, try verifying the record data before