Re: COBOL move statement issue
* code an Assembler program named PGMA that checks the data (if you're on z, then a simple TP instruction should do it) TP checks for valid signed-packed-decimal data. The OP's input data was in character form. TRT would be more appropriate. From: Steve Comstock <[EMAIL PROTECTED]> Reply-To: IBM Mainframe Discussion List To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL move statement issue Date: Tue, 16 Oct 2007 08:43:42 -0600 Peter Ten Eyck wrote: I have had some programmers come to me with this issue. It appears that we have a new system (web app.) which is sending bad data in several locations to our mainframe (COBOL programs). The proper thing to do is to correct the web app. so that it send the data correct. While we wait for that fix to occur, I am looking into if there is a way without changing the COBOL code to catch this bad data by forcing an abend. Well, you could take this approach: * rename your COBOL program; say from PGMA to PGMA2 * code an Assembler program named PGMA that checks the data (if you're on z, then a simple TP instruction should do it) and then passes the data to PGMA2 if the data are good, but writes a message to an error log if the data are bad (I was going to say fix the data, but that's too ambiguous, maybe even dangerous). Kind regards, -Steve Comstock _ Make every IM count. Download Messenger and join the im Initiative now. Its free. http://im.live.com/messenger/im/home/?source=TAGHM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Peter, It appears that the consensus is that there really isn't a way to abend your program in this case. But do you really have to? IMHO, if the issue is that the web application sends valid, but poorly formatted data (in your example, "86b" [where b=blank] is valid but should have been sent as "086"), I'd be more inclined to change the COBOL program and parse the data using "FUNCTION NUMVAL", for example. That ensures proper numeric value recognition and processing. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ten Eyck Sent: Tuesday, October 16, 2007 07:14 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: COBOL move statement issue I have had some programmers come to me with this issue. It appears that we have a new system (web app.) which is sending bad data in several locations to our mainframe (COBOL programs). The proper thing to do is to correct the web app. so that it send the data correct. While we wait for that fix to occur, I am looking into if there is a way without changing the COBOL code to catch this bad data by forcing an abend. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
I am going to consider this matter closed. After reading the various replies, it is the programs responsibility to verify it's input data in this case. Thanks for the help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
You might use a Compute Statement to force an abend if unsigned data, if you don't want to do a Numeric check. Not sure this will do what your asking but it might. Compute Field-2 = Field-1. Darren -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ten Eyck Sent: Monday, October 15, 2007 11:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL move statement issue Enterprise COBOL 3.4.1 on z/OS 1.7 The following does not abend: . . . 01 FIELD-1 PIC 9(3). 01 FIELD-2 PIC 9(3) COMP-3. . . . MOVE FIELD-1 TO FIELD-2. . . . Note: Prior to the move FIELD-1 contains "86 " thats F8F640 What COBOL or LE option(s) do I need to change to make this code abend? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
On Tue, 16 Oct 2007 09:13:52 -0500, Peter Ten Eyck wrote: >I have had some programmers come to me with this issue. It appears that we >have a new system (web app.) which is sending bad data in several locations >to our mainframe (COBOL programs). The proper thing to do is to correct the >web app. so that it send the data correct. While we wait for that fix to occur, I >am looking into if there is a way without changing the COBOL code to catch >this bad data by forcing an abend. The mainframe application should always validate the data when it comes from an external source. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Peter Ten Eyck wrote: I have had some programmers come to me with this issue. It appears that we have a new system (web app.) which is sending bad data in several locations to our mainframe (COBOL programs). The proper thing to do is to correct the web app. so that it send the data correct. While we wait for that fix to occur, I am looking into if there is a way without changing the COBOL code to catch this bad data by forcing an abend. Well, you could take this approach: * rename your COBOL program; say from PGMA to PGMA2 * code an Assembler program named PGMA that checks the data (if you're on z, then a simple TP instruction should do it) and then passes the data to PGMA2 if the data are good, but writes a message to an error log if the data are bad (I was going to say fix the data, but that's too ambiguous, maybe even dangerous). Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
On Tue, 16 Oct 2007 09:09:04 -0500 "Schneiderwent, Craig" <[EMAIL PROTECTED]> wrote: :>Apparently I mistakenly took the OS/VS COBOL compiler's behavior as standard :>and correct. As the results are undefined, pretty much any behavior is "correct". -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
I have had some programmers come to me with this issue. It appears that we have a new system (web app.) which is sending bad data in several locations to our mainframe (COBOL programs). The proper thing to do is to correct the web app. so that it send the data correct. While we wait for that fix to occur, I am looking into if there is a way without changing the COBOL code to catch this bad data by forcing an abend. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
-8http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Peter Ten Eyck wrote: Thanks for the replies. If I am reading the replies correctly, a move statement of: 01 FIELD-1 PIC 9(3). 01 FIELD-2 PIC 9(3) COMP-3. MOVE FIELD-1 TO FIELD-2. Will not abend regardless of the data in FIELD-1, unless the fields are signed. There is no way to control this trough a COBOL compiler option or LE runtime option? That's correct. I'm a little confused as to what you are after: do you want some way to force an abend if there's non-valid numeric data in your program? If so: why? Are you looking for some way to validate numeric data before using it? if so, I recommend you not use abends as the way to find out. Perhaps if it were clearer what you are really after we might be able to offer some useful suggestions. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Thanks for the replies. If I am reading the replies correctly, a move statement of: 01 FIELD-1 PIC 9(3). 01 FIELD-2 PIC 9(3) COMP-3. MOVE FIELD-1 TO FIELD-2. Will not abend regardless of the data in FIELD-1, unless the fields are signed. There is no way to control this trough a COBOL compiler option or LE runtime option? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Roland Schiradin wrote: Craig, interesting I thought NUMPROC(PFD) would cause an abend but PACK wouldn't get a data exception (0C7). Roland There does not appear to be a combination of NUMPROC and OPT that will cause an abend. NUMPROC(PFD) tells the compiler all your numeric display and packed-decimal (comp-3 for you old timers) fields have valid signs; the compiler takes you at your word and uses non-packed decimal instructions whenever possible (because they are generally faster). So a MOVE of such data will generate an MVC, which will never S0C7, instead of a ZAP, which can S0C7; separate issue: and of course, PACK never gets a S0C7; if you have bad data, its the use of packed decimal arithmetic or editing operations on bad data that can S0C7 (and, of course, CVB if that's generated along the way). Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Craig, interesting I thought NUMPROC(PFD) would cause an abend but PACK wouldn't get a data exception (0C7). Roland >There does not appear to be a combination of NUMPROC and OPT that will cause >an abend. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
There does not appear to be a combination of NUMPROC and OPT that will cause an abend. We did some testing. We ended up passing the literal '86 ' in via the linkage section to short circuit the compiler's optimizations. We tried compiling with all the combinations of NUMPROC and OPT. We found that, so long as the sending (usage display) field was unsigned, we got no S0C7 on the move. We also tried adding a compute statement using the packed field and that also worked fine. We passed in spaces and low values and those worked too. Adding a sign to the sending field made the S0C7 happen on the move because the generated code was a pack followed by a zap. It appears that the compiler generates code to smudge the sign into correctness when the sending field is unsigned. This is documented in the language reference under 6.2.24.2 Elementary move rules. A bit of a surprise. Tomorrow I'll have to try this with OS/VS COBOL (the only other compiler we've got hanging around) and see what happens. Code is available on request. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Not sure about a compiler "option" if any, but you could try MOVE ZERO TO FIELD-2 ADD FIELD-1 TO FIELD-2 which might "zap" it around sufficiently to encourage an S0C7. (That's assuming your primary goal is to abend, rather than finding a compiler option.) On Mon, 15 Oct 2007 13:34:25 -0500, Peter Ten Eyck <[EMAIL PROTECTED]> wrote: >Enterprise COBOL 3.4.1 on z/OS 1.7 > >The following does not abend: >. >. >. >01 FIELD-1 PIC 9(3). >01 FIELD-2 PIC 9(3) COMP-3. >. >. >. >MOVE FIELD-1 TO FIELD-2. >. >. >. > >Note: Prior to the move FIELD-1 contains "86 " thats F8F640 > >What COBOL or LE option(s) do I need to change to make this code abend? > >-- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Not sure about a compiler "option" if any, but you could try MOVE ZERO TO FIELD-2 ADD FIELD-1 TO FIELD-2 which might "zap" it around sufficiently to encourage an S0C7. (That assumes your objective is the causing of an abend, rather than finding a compiler option.) On Mon, 15 Oct 2007 13:34:25 -0500, Peter Ten Eyck <[EMAIL PROTECTED]> wrote: >Enterprise COBOL 3.4.1 on z/OS 1.7 > >The following does not abend: >. >. >. >01 FIELD-1 PIC 9(3). >01 FIELD-2 PIC 9(3) COMP-3. >. >. >. >MOVE FIELD-1 TO FIELD-2. >. >. >. > >Note: Prior to the move FIELD-1 contains "86 " thats F8F640 > >What COBOL or LE option(s) do I need to change to make this code abend? > >-- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
On Mon, 15 Oct 2007 13:34:25 -0500 Peter Ten Eyck <[EMAIL PROTECTED]> wrote: :>Enterprise COBOL 3.4.1 on z/OS 1.7 :>The following does not abend: :>01 FIELD-1 PIC 9(3). :>01 FIELD-2 PIC 9(3) COMP-3. :>MOVE FIELD-1 TO FIELD-2. :>Note: Prior to the move FIELD-1 contains "86 " thats F8F640 :>What COBOL or LE option(s) do I need to change to make this code abend? The proper thing to do is IF FIELD-1 NOT NUMERIC which will catch cases like "ABC" and as well If you wish to force an abend .. 01 ZERO-VALIE PIC S9(3) COMP-3 VALUE 0. ADD ZERO-FIELD FIELD-1 GIVING FIELD-2. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Peter Ten Eyck wrote: Enterprise COBOL 3.4.1 on z/OS 1.7 The following does not abend: .. .. .. 01 FIELD-1 PIC 9(3). 01 FIELD-2 PIC 9(3) COMP-3. .. .. .. MOVE FIELD-1 TO FIELD-2. .. .. .. Note: Prior to the move FIELD-1 contains "86 " thats F8F640 What COBOL or LE option(s) do I need to change to make this code abend? I don't think you'll be able to get that to abend. You might try using IF FIELD-1 NUMERIC ... or define FIELD-1 with JUSTIFY RIGHT Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
> -Original Message- > From: Peter Ten Eyck [mailto:[EMAIL PROTECTED] > Sent: Monday, October 15, 2007 2:34 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: COBOL move statement issue > > Enterprise COBOL 3.4.1 on z/OS 1.7 > > The following does not abend: > . > . > . > 01 FIELD-1 PIC 9(3). > 01 FIELD-2 PIC 9(3) COMP-3. > . > . > . > MOVE FIELD-1 TO FIELD-2. > . > . > . > > Note: Prior to the move FIELD-1 contains "86 " thats F8F640 > > What COBOL or LE option(s) do I need to change to make this code abend? 01 ABEND-CODE PIC S9(9) BINARY VALUE +. 01 ABEND-TIMING PIC S9(9) BINARY VALUE +1. ... IF FIELD-1 IS NOT NUMERIC CALL "CEE3ABD" USING ABEND-CODE, ABEND-TIMING END-IF. MOVE FIELD-1 TO FIELD-2. HTH Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL move statement issue
Pack will exception on protection and addressing, not data.. If not numeric, abend... -Original Message-From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ten EyckSent: Monday, October 15, 2007 2:34 PMTo: [EMAIL PROTECTED]: COBOL move statement issue Enterprise COBOL 3.4.1 on z/OS 1.7 The following does not abend: . . . 01 FIELD-1 PIC 9(3). 01 FIELD-2 PIC 9(3) COMP-3. . . . MOVE FIELD-1 TO FIELD-2. . . . Note: Prior to the move FIELD-1 contains "86 " thats F8F640 What COBOL or LE option(s) do I need to change to make this code abend? _ Windows Live Hotmail and Microsoft Office Outlook – together at last. Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
