Re: Bypassing s322

> On Sep 15, 2016, at 2:43 PM, Gibney, Dave wrote: > > The Cobol of 1981 is not the Cobol of today. Absolute statements regarding > behavior 35 years ago are almost unprovable. Except maybe some Herculean > effort :) SNIP—— But I will bet that a

Re: Bypassing s322

offending > code. But there had been a lot of theoretical discussion. Steve * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > &

Re: Bypassing s322

SERV.UA.EDU] > On Behalf Of Bill Woodger > Sent: Thursday, September 15, 2016 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bypassing s322 > > Ah. Well. Preferred signs. > > The thing is, preferred signs are not a problem as output from a "decimal > instr

Re: Bypassing s322

I had been wondering why there were not "rules of algebra" explanations for the floating-point variants of MULTIPLY. So I looked: "The sign of the product, if the product is numeric, is the exclusive or of the operand signs. This includes the sign of a zero or infinite product." In

Re: Bypassing s322

Subject: (External):Re: Bypassing s322 Oh, I think there's been a certain amount of "drift" in the topic. There are lots of simple ways the issue you mention could have occurred, even though we'll never know exactly. I agree, rather than trying to give a program more CPU, I'd be won

Re: Bypassing s322

Oh, I think there's been a certain amount of "drift" in the topic. There are lots of simple ways the issue you mention could have occurred, even though we'll never know exactly. I agree, rather than trying to give a program more CPU, I'd be wondering why it is sucking up all the CPU that it

Re: Bypassing s322

On 15 September 2016 at 16:24, Bill Woodger wrote: > February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) > to S9(8)" Got it, thanks. Tony H. -- For IBM-MAIN subscribe / signoff

Re: Bypassing s322

On Behalf Of Bill Woodger > Sent: Thursday, September 15, 2016 1:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bypassing s322 > > Oh, we're talking about years after 1981 :-) > > Probably the middle-late '80 to early 90s. > > You don't need to assert anything, it is doc

Re: Bypassing s322

Oh, we're talking about years after 1981 :-) Probably the middle-late '80 to early 90s. You don't need to assert anything, it is documented. Could look it up and make those dates a bit more accurate, but it doesn't matter, does it? Unfortunately, for the potential Herculean effort, pre-COBOL

Re: Bypassing s322

February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)" Or just search for "negative zero COBOL" I guess. I would imagine it fair to say that a numeric field is tested more often than it is set.

Re: Bypassing s322

On 14 September 2016 at 18:05, Bill Woodger wrote: > Yes, the compiler generates additional code to ensure that a -ve zero cannot > be the result of anything in COBOL. This would surely have potentially as much overhead as using CP rather than CLC in the first place. Do

Re: Bypassing s322

er > Sent: Thursday, September 15, 2016 10:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bypassing s322 > > Ah. Well. Preferred signs. > > The thing is, preferred signs are not a problem as output from a "decimal > instruction", because no matter what go

Re: Bypassing s322

good idea and that identifying why the CPU use is high can be more productive. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Marchant > Sent: Thursday, September 15, 2016 8:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU >

Re: Bypassing s322

Ah. Well. Preferred signs. The thing is, preferred signs are not a problem as output from a "decimal instruction", because no matter what goes in (as long the sign is A-F, else Bang!) then only C or D can come out. No enforcing is necessary, it is just the way it happens. Calculations in

Re: Bypassing s322

On Wed, 14 Sep 2016 15:34:32 -0500, Bill Woodger wrote: >When IBM decided to use "character" comparisons where possible for numerics, >they had to ban the negative zero. They also had to enforce the preferred sign. Just as X'0C' and X'0D' would be equal using a CP instruction, they are also

Re: Bypassing s322

On 09/15/2016 01:02 AM, Bill Woodger wrote: > It is not so much what I mean, as what the Principles of Operations means. > > "The sign of the product is determined by the rules of algebra from the > multiplier and multiplicand signs, even if one or both operands are zeros." > > It is the old "two

Re: Bypassing s322

It is not so much what I mean, as what the Principles of Operations means. "The sign of the product is determined by the rules of algebra from the multiplier and multiplicand signs, even if one or both operands are zeros." It is the old "two negatives make a positive, two positives make a

Re: Bypassing s322

On 09/14/2016 05:09 PM, Bill Woodger wrote: > Yes, "the rules of algebra" has lead to a minus zero... but it is still zero, > the sign for zero has no significance in algebra. > > In two's-complement, there is no negative zero. > > In packed-decimal 'rithmetic, there is, as explained in the PoP.

Re: Bypassing s322

Yes, "the rules of algebra" has lead to a minus zero... but it is still zero, the sign for zero has no significance in algebra. In two's-complement, there is no negative zero. In packed-decimal 'rithmetic, there is, as explained in the PoP. The sign of the result is according to the rules of

Re: Bypassing s322

Yes, the compiler generates additional code to ensure that a -ve zero cannot be the result of anything in COBOL. This was discussed fairly recently here. The machine instructions obey the rules of algebra, COBOL doesn't as they apply to zero. Minus five times zero is zero, and always positive

Re: Bypassing s322

o:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, September 14, 2016 2:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bypassing s322 On 14 September 2016 at 16:34, Bill Woodger <bill.wood...@gmail.com> wrote: > When IBM decided to use "character" comparison

Re: Bypassing s322

On 14 September 2016 at 16:34, Bill Woodger wrote: > When IBM decided to use "character" comparisons where possible for numerics, > they had to ban the negative zero. > Although in a decimal compare a zero is zero, no matter how signed, in a > character compare it is

Re: Bypassing s322

Very old Mainframe COBOLs did allow -ve zero to exist. The test for a zero where the source may have been a negative zero should have been unproblematic, because at the time only "decimal" instructions were used for numeric comparisons in the code generated by the compiler. And zero is zero.

Re: Bypassing s322

On Wed, Sep 14, 2016 at 3:08 PM, Gibney, Dave wrote: > It's been 35 years :) It might even have been a packed field. But it did > loop because the negative representation of zero did not match the zero the > code was looping unitl :) > > ​Oh, yeah, a packed negative zero, 0x0D​

Re: Bypassing s322

f Of John McKown > Sent: Wednesday, September 14, 2016 1:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bypassing s322 > > On Wed, Sep 14, 2016 at 2:51 PM, Gibney, Dave <gib...@wsu.edu> wrote: > > > Once, in my first months here, a program appeared to be loopi

Re: Bypassing s322

On Wed, Sep 14, 2016 at 2:51 PM, Gibney, Dave wrote: > Once, in my first months here, a program appeared to be looping, but maybe > not. It was impacting the system, but I insisted it be allowed to run and > it was for a while. > It was a Cobol program. Perform until some COMP

Re: Bypassing s322

'8000') in a COMP field as zero. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Elardus Engelbrecht > Sent: Wednesday, September 14, 2016 5:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bypassing s322

Re: Bypassing s322

Scott Chapman wrote: >Of course, when anybody came to me complaining about an S322, assuming it was >already in one of the classes that allowed them to get the max we allowed of 1 >or 2 hours of CPU time, my first reaction was always something along the lines >of "Are you sure you aren't

Re: Bypassing s322

You can't really bypass the system exits, but that doesn't mean that the exits might not include certain "secret" triggers that might allow you to specify a higher time value on the job card. E.G. if the job is in this class and it's this time of day and this job name, then allow/set something

Re: Bypassing s322

Just as an "Oh by the way". What are you running that needs so much time? Steve -Original Message- From: "Jesse 1 Robinson" <jesse1.robin...@sce.com> Sent: Tuesday, September 13, 2016 12:35pm To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bypassing s322 The us

Re: Bypassing s322

@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, September 13, 2016 9:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Bypassing s322 I would compare the Run time(Clock) with CPU TIME. You may be exceeding the CPU Time limit set for that Class. We have an exit that produces a nice

Re: Bypassing s322

I would compare the Run time(Clock) with CPU TIME. You may be exceeding the CPU Time limit set for that Class. We have an exit that produces a nice little map of CPU usage details. CPU TIME is one of the fields. I recently had a job running in INPUT CLASS X that kept timing out no matter

Re: Bypassing s322

Actually, I misremembered how IEFUTL works, and just remembered (sorry)! IEFUTL gets control when the time limit set expires, and can extend the time allowed. It does not set lower values. John Eells wrote: For historical reasons lost in the Mists of Time, the explanations for z/OS BCP

Re: Bypassing s322

Peter wrote: You've got good replies. Please check all of them! >I am running which is a long running job but it keeps abending with s322. How long? What is your TIME on JOB and/or EXEC statements? Do you have any IEFUTL exit active? (D PROG,EXIT,EX=SYSSTC.IEFUTL,DIAG can help) What is your

Re: Bypassing s322

On Tue, Sep 13, 2016 at 8:50 AM, John Eells wrote: > For historical reasons lost in the Mists of Time, ​Oh, good one :-) but wouldn't that be Mists of TIME=?​ > the explanations for z/OS BCP system abends are in System Codes, while > those for DFSMS abends are in System

Re: Bypassing s322

September, 2016 15:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bypassing s322 About the only way is to pull out the exit or add a FASTAUTH for some widget Steve -Original Message- From: "John McKown" <john.archie.mck...@gmail.com> Sent: Tuesday, September 13, 2016 9:1

Re: Bypassing s322

For historical reasons lost in the Mists of Time, the explanations for z/OS BCP system abends are in System Codes, while those for DFSMS abends are in System Messages. (It took me years to realize why I always seemed to be looking in the wrong place!) Basically, for batch jobs, if you do not

Re: Bypassing s322

About the only way is to pull out the exit or add a FASTAUTH for some widget Steve -Original Message- From: "John McKown" <john.archie.mck...@gmail.com> Sent: Tuesday, September 13, 2016 9:19am To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bypassing s322 Have you

Re: Bypassing s322

Have you tried TIME=1440 on the job card? Or, if you like the more recent way, TIME=NOLIMIT . As Kees said, this may be disallowed at your shop. You might need to ask your sysprog, if you are not one yourself. There is not a way for a job to say the equivalent of "this job should not be controlled

Re: Bypassing s322

The S322 abend occurs when the TIME= on the JOB or EXEC statement is exceeded. So the job does have one and you must be able to find out where it originates from, possibly from JES2PARM JOBCLASS statement. You can override the time with the TIME=nnn or TIME=NOLIMIT parameter (if exits allow