Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bypassing s322
185 views
Skip to first unread message
Peter
Sep 13, 2016, 9:05:27 AM9/13/16
to
Hello
I am running which is a long running job but it keeps abending with s322. I
have used all the long running WLM initiators but still abends. I am not
sure if IEFUTL exit is restricting it.
The error message doesn't produce much information to diagnose.
Is there a way to bypass any EXIT which might be timing out the Jobs ?
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
I am running which is a long running job but it keeps abending with s322. I
have used all the long running WLM initiators but still abends. I am not
sure if IEFUTL exit is restricting it.
The error message doesn't produce much information to diagnose.
Is there a way to bypass any EXIT which might be timing out the Jobs ?
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
Sep 13, 2016, 9:14:42 AM9/13/16
to
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 this).
Kees.
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
You can override the time with the TIME=nnn or TIME=NOLIMIT parameter (if exits allow this).
Kees.
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
John McKown
Sep 13, 2016, 9:19:32 AM9/13/16
to
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
by the ... system exit". That would be just silly because I know a lot of
people who'd use it in all their jobs and say "nasty" things if anyone
called them out about it. One programmer learned, the hard way, not to piss
off a BOFH type sysprog (me).
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
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
by the ... system exit". That would be just silly because I know a lot of
people who'd use it in all their jobs and say "nasty" things if anyone
called them out about it. One programmer learned, the hard way, not to piss
off a BOFH type sysprog (me).
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
Steve
Sep 13, 2016, 9:22:41 AM9/13/16
to
About the only way is to pull out the exit or add a FASTAUTH for some widget
Steve
Steve
John Eells
Sep 13, 2016, 9:51:23 AM9/13/16
to
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 specify TIME, it will be taken
from the TIME specified on the JOBCLASS statement (JES2) or its default,
30 minutes if TIME has not been specified on JOBCLASS. (There is a JES3
equivalent that I no longer recall and did not look up.)
If there is an IEFUTL exit, it can modify the TIME value based on any
data accessible to the exit when it runs. Because we don't know what
people might be testing for to allow or disallow more time in the exit
(or, for that matter, to increase the time!), your local batch job
standards document or system programmer are the sources of information
about how to get IEFUTL to allow more time.
Although System Codes does not mention IEFUTL for some reason (I have
submitted an RCF), it does cover the other reasons:
322
Explanation: One of the following occurred:
O - The system took a longer time to run a job, job step, or procedure
than the time specified in one of the following:
– The TIME parameter of the EXEC or JOB statement
– The standard time limit specified in the job entry subsystem
O - For a started task under the master subsystem, the TIME parameter
was not specified on the PROC statement of the catalogued procedure, and
the PPT entry did not indicate a system task
System action: The system abnormally ends the job, job step, or procedure.
Programmer response: If the TIME parameter was not specified on the PROC
statement of the catalogued procedure, add the TIME parameter or add a
PPT entry for the PGM parameter. Otherwise, check for program errors. If
none exist, specify a longer time in the TIME parameter. Then run the
job again.
Source: System Management Facilities (SMF)
Peter wrote:
> Hello
>
> I am running which is a long running job but it keeps abending with s322. I
> have used all the long running WLM initiators but still abends. I am not
> sure if IEFUTL exit is restricting it.
>
> The error message doesn't produce much information to diagnose.
>
> Is there a way to bypass any EXIT which might be timing out the Jobs ?
<snip>
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
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 specify TIME, it will be taken
from the TIME specified on the JOBCLASS statement (JES2) or its default,
30 minutes if TIME has not been specified on JOBCLASS. (There is a JES3
equivalent that I no longer recall and did not look up.)
If there is an IEFUTL exit, it can modify the TIME value based on any
data accessible to the exit when it runs. Because we don't know what
people might be testing for to allow or disallow more time in the exit
(or, for that matter, to increase the time!), your local batch job
standards document or system programmer are the sources of information
about how to get IEFUTL to allow more time.
Although System Codes does not mention IEFUTL for some reason (I have
submitted an RCF), it does cover the other reasons:
322
Explanation: One of the following occurred:
O - The system took a longer time to run a job, job step, or procedure
than the time specified in one of the following:
– The TIME parameter of the EXEC or JOB statement
– The standard time limit specified in the job entry subsystem
O - For a started task under the master subsystem, the TIME parameter
was not specified on the PROC statement of the catalogued procedure, and
the PPT entry did not indicate a system task
System action: The system abnormally ends the job, job step, or procedure.
Programmer response: If the TIME parameter was not specified on the PROC
statement of the catalogued procedure, add the TIME parameter or add a
PPT entry for the PGM parameter. Otherwise, check for program errors. If
none exist, specify a longer time in the TIME parameter. Then run the
job again.
Source: System Management Facilities (SMF)
Peter wrote:
> Hello
>
> I am running which is a long running job but it keeps abending with s322. I
> have used all the long running WLM initiators but still abends. I am not
> sure if IEFUTL exit is restricting it.
>
> The error message doesn't produce much information to diagnose.
>
> Is there a way to bypass any EXIT which might be timing out the Jobs ?
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
Vernooij, Kees - KLM , ITOPT1
Sep 13, 2016, 9:52:49 AM9/13/16
to
IEFUTL only acts when you exceed the TIME= value supplied to your job. Did you try to overrule the default value with either a reasonable value or NOLIMIT?
Kees.
Kees.
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************
John McKown
Sep 13, 2016, 9:53:40 AM9/13/16
to
On Tue, Sep 13, 2016 at 8:50 AM, John Eells <ee...@us.ibm.com> wrote:
> For historical reasons lost in the Mists of Time,
Oh, good one :-) but wouldn't that be Mists of TIME=?
> 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!)
>
>
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
Elardus Engelbrecht
Sep 13, 2016, 10:46:02 AM9/13/16
to
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 JES2 JOBCLASS time definition?
Perhaps there are SMF and/or JES2 exits which enforce the time limit despite what you wrote on the JCL.
Oh, some JES2 exits may scan your JCL and modify TIME= at will if those exits are written to do that.
>I have used all the long running WLM initiators but still abends.
I'm not sure WLM can influence that TIME, but I could be wrong.
>I am not sure if IEFUTL exit is restricting it.
Only if IEFUTL is active as per your SMFPRMxx and you have coded TIME= as others said.
>The error message doesn't produce much information to diagnose.
This is WAD.
>Is there a way to bypass any EXIT which might be timing out the Jobs ?
Yes, but if your datacenter enforced the installation of IEFUTL and JES2 JOBCLASS and setup of SMFPRMxx, you may be SOL.
If I'm in charge, I would be a BOFH in no TIME= ... ;-)
Groete / Greetings
Elardus Engelbrecht
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.
Do you have any IEFUTL exit active? (D PROG,EXIT,EX=SYSSTC.IEFUTL,DIAG can help)
What is your JES2 JOBCLASS time definition?
Perhaps there are SMF and/or JES2 exits which enforce the time limit despite what you wrote on the JCL.
Oh, some JES2 exits may scan your JCL and modify TIME= at will if those exits are written to do that.
>I have used all the long running WLM initiators but still abends.
>I am not sure if IEFUTL exit is restricting it.
>The error message doesn't produce much information to diagnose.
>Is there a way to bypass any EXIT which might be timing out the Jobs ?
If I'm in charge, I would be a BOFH in no TIME= ... ;-)
Groete / Greetings
Elardus Engelbrecht
John Eells
Sep 13, 2016, 10:53:11 AM9/13/16
to
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.
IEFUTL gets control when the time limit set expires, and can extend the
time allowed. It does not set lower values.
Lizette Koehler
Sep 13, 2016, 12:06:27 PM9/13/16
to
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 what the TIME was set on the JCL. Turns out the INPUT Class X had a 60 min CPU time limit set. So even though the job ran for 3 hours - it actually used 60.01 minutes of CPU Time. Hence the failure.
Always check the job while it is running with SDSF and see if the CPU Time increases quickly. Your task may be in a loop.
Lizette
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
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 what the TIME was set on the JCL. Turns out the INPUT Class X had a 60 min CPU time limit set. So even though the job ran for 3 hours - it actually used 60.01 minutes of CPU Time. Hence the failure.
Always check the job while it is running with SDSF and see if the CPU Time increases quickly. Your task may be in a loop.
Lizette
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Tuesday, September 13, 2016 6:05 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Bypassing s322
>
> Sent: Tuesday, September 13, 2016 6:05 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Bypassing s322
>
Jesse 1 Robinson
Sep 13, 2016, 12:35:28 PM9/13/16
to
The usual circumvention for S322 is to increase the TIME= value, not play with exits. For one thing, IEFUTIL can extend the time, but even with no exit in place, the system will abend a job eventually. Be sure to increase the time value on both the job card and on the step (EXEC) card. Exceeding either one will cause S322.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robi...@sce.com
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robi...@sce.com
Steve
Sep 13, 2016, 12:39:20 PM9/13/16
to
Just as an "Oh by the way". What are you running that needs so much time?
Steve
-----Original Message-----
From: "Jesse 1 Robinson" <Jesse1....@SCE.COM>
Sent: Tuesday, September 13, 2016 12:35pm
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Bypassing s322
Steve
-----Original Message-----
From: "Jesse 1 Robinson" <Jesse1....@SCE.COM>
Sent: Tuesday, September 13, 2016 12:35pm
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Bypassing s322
Scott Chapman
Sep 14, 2016, 8:00:38 AM9/14/16
to
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 higher. Talk to your friendly system programmer responsible for maintaining such controls. (If that's you because you've inherited a situation, you'll have to go do some research.)
In the distant past I remember using Omegamon to dynamically extend the limit of a running job. I don't remember the details at this point, but I think it was just adjusting the existing time limit, not doing something like taking it out of control of the exit or anything like that.
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 looping? Are you sure you don't have a tuning opportunity that needs to be fixed?" An hour of CPU time is usually a whole lot of work.
Scott
In the distant past I remember using Omegamon to dynamically extend the limit of a running job. I don't remember the details at this point, but I think it was just adjusting the existing time limit, not doing something like taking it out of control of the exit or anything like that.
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 looping? Are you sure you don't have a tuning opportunity that needs to be fixed?" An hour of CPU time is usually a whole lot of work.
Scott
Elardus Engelbrecht
Sep 14, 2016, 8:30:19 AM9/14/16
to
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 looping? Are you sure you don't have a tuning opportunity that needs to be fixed?" An hour of CPU time is usually a whole lot of work.
Agreed.
>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 looping? Are you sure you don't have a tuning opportunity that needs to be fixed?" An hour of CPU time is usually a whole lot of work.
Watch the CPU usage of that job. If it is very high in relation of the other tasks, then there is a possible loop. Or lots of I/Os. Or you see excessive SMF records being written. Or you see that job is spitting out gazillion lines.
Scott, I would go the same tuning route as you (and slap that complainer hard and loud. ;-D )
Groete / Greetings
Elardus Engelbrecht
0rober...@gmail.com
Sep 14, 2016, 12:20:34 PM9/14/16
to
Robert
Gibney, Dave
Sep 14, 2016, 3:51:54 PM9/14/16
to
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 field reached zero. The Cobol of the time did not recognize negative zero (X'80000000') in a COMP field as zero.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Wednesday, September 14, 2016 5:30 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
It was a Cobol program. Perform until some COMP field reached zero. The Cobol of the time did not recognize negative zero (X'80000000') in a COMP field as zero.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Wednesday, September 14, 2016 5:30 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
John McKown
Sep 14, 2016, 4:00:13 PM9/14/16
to
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 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 field reached zero. The
> Cobol of the time did not recognize negative zero (X'80000000') in a COMP
> field as zero.
>
>
Hum, x'80000000' in 2-complement binary is not -0, it is
> 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 field reached zero. The
> Cobol of the time did not recognize negative zero (X'80000000') in a COMP
> field as zero.
>
>
-2,147,483,648
. ref:
https://en.wikipedia.org/wiki/32-bit
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Unicode: http://xkcd.com/1726/
Maranatha! <><
John McKown
Gibney, Dave
Sep 14, 2016, 4:08:59 PM9/14/16
to
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 :)
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, September 14, 2016 1:00 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
> 3A__en.wikipedia.org_wiki_32-
> 2Dbit&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=Ch2PMt6L1Xyzxt5izQlcs9D87adUiSxqt9pH-
> GMLK9w&e=
> 3A__xkcd.com_1726_&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8L
> drrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=uulDZEnFlqF00D7MI1Lfc-
> nYsxV9EQKC0VSYBXwe590&e=
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Wednesday, September 14, 2016 1:00 PM
> To: IBM-...@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 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 field reached zero.
> > The Cobol of the time did not recognize negative zero (X'80000000')
> > in a COMP field as zero.
> >
> >
> Hum, x'80000000' in 2-complement binary is not -0, it is
> -2,147,483,648
> . ref:
> https://urldefense.proofpoint.com/v2/url?u=https-
>
> > 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 field reached zero.
> > The Cobol of the time did not recognize negative zero (X'80000000')
> > in a COMP field as zero.
> >
> >
> Hum, x'80000000' in 2-complement binary is not -0, it is
> -2,147,483,648
> . ref:
> 3A__en.wikipedia.org_wiki_32-
> 2Dbit&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=Ch2PMt6L1Xyzxt5izQlcs9D87adUiSxqt9pH-
> GMLK9w&e=
>
>
>
>
>
> --
> Unix: Some say the learning curve is steep, but you only have to climb it
> once. -- Karl Lehenbauer
> Unicode: https://urldefense.proofpoint.com/v2/url?u=http-
>
>
>
>
> --
> Unix: Some say the learning curve is steep, but you only have to climb it
> once. -- Karl Lehenbauer
> 3A__xkcd.com_1726_&d=DQIFaQ&c=C3yme8gMkxg_ihJNXS06ZyWk4EJm8L
> drrvxQb-
> Je7sw&r=u9g8rUevBoyCPAdo5sWE9w&m=vyEGno2UwsNi3TyWCpgDmFCJ2r
> oOpPY30QnpZVR9LCw&s=uulDZEnFlqF00D7MI1Lfc-
> nYsxV9EQKC0VSYBXwe590&e=
John McKown
Sep 14, 2016, 4:17:05 PM9/14/16
to
On Wed, Sep 14, 2016 at 3:08 PM, Gibney, Dave <gib...@wsu.edu> 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
> 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 :)
>
>
, might not get recognized in a COBOL program. I don't remember the
compile options back then, but I think there was one which said "all zones
are correct" and the code would do a CLC instead of a CP because it was
faster on the machine.
--
Unix: Some say the learning curve is steep, but you only have to climb it
once. -- Karl Lehenbauer
Bill Woodger
Sep 14, 2016, 4:34:41 PM9/14/16
to
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.
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 not. Ergo -ve zero could not be allowed to exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever generate a -ve zero result, nor will any truncation).
There's lots of ways the problem being talked about probably happened: PIC 99 and test for greater than 100 is a good one. PIC 9(4) and with subtraction, test for less than zero. One of my favourites "ADD ONE TO somefield" where data-name ONE is defined with VALUE ZERO.
How about this fun one. Job running a long time, so someone decides to cancel it. Investigation reveals that it was processing the final record on the file. Some bright spark says "it's a pity we cancelled it, it had nearly finished, let's submit it again..." and they were going to. The loop was in processing some accumulated totals, and was of the type mentioned above. I think the job was originally cancelled after about three hours. With the code corrected, it ran in under 10 minutes. I had only arrived at the final conversation. One of those moments when you feel you've stepped into some sort of alternate Universe...
And don't ask how it got through testing...
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.
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 not. Ergo -ve zero could not be allowed to exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever generate a -ve zero result, nor will any truncation).
There's lots of ways the problem being talked about probably happened: PIC 99 and test for greater than 100 is a good one. PIC 9(4) and with subtraction, test for less than zero. One of my favourites "ADD ONE TO somefield" where data-name ONE is defined with VALUE ZERO.
How about this fun one. Job running a long time, so someone decides to cancel it. Investigation reveals that it was processing the final record on the file. Some bright spark says "it's a pity we cancelled it, it had nearly finished, let's submit it again..." and they were going to. The loop was in processing some accumulated totals, and was of the type mentioned above. I think the job was originally cancelled after about three hours. With the code corrected, it ran in under 10 minutes. I had only arrived at the final conversation. One of those moments when you feel you've stepped into some sort of alternate Universe...
And don't ask how it got through testing...
Tony Harminc
Sep 14, 2016, 5:13:42 PM9/14/16
to
On 14 September 2016 at 16:34, Bill Woodger <bill.w...@gmail.com> 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 not. Ergo -ve zero could
> not be allowed to exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever
> generate a -ve zero result, nor will any truncation).
So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
> 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 not. Ergo -ve zero could
> not be allowed to exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever
> generate a -ve zero result, nor will any truncation).
The generated code must go out of its way to accomplish this.
Tony H.
Charles Mills
Sep 14, 2016, 5:51:26 PM9/14/16
to
Way OT, but does "algebra" recognize +/-0? Or is that just an artifact of packed notation (which is itself an artifact of Hollerith cards)?
What is -5 * 0 in fullword arithmetic? SURELY not -0.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Wednesday, September 14, 2016 2:13 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Bypassing s322
What is -5 * 0 in fullword arithmetic? SURELY not -0.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Wednesday, September 14, 2016 2:13 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Bypassing s322
On 14 September 2016 at 16:34, Bill Woodger <bill.w...@gmail.com> 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 not. Ergo -ve zero could not be allowed to
> exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever generate a -ve zero result, nor will any truncation).
So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
The generated code must go out of its way to accomplish this.
> 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 not. Ergo -ve zero could not be allowed to
> exist. (you can of course screw things up by being deliberate, but no calculation in COBOL will ever generate a -ve zero result, nor will any truncation).
So in COBOL, +0 times -5 is +0, i.e the rules of algebra don't apply?
The generated code must go out of its way to accomplish this.
Bill Woodger
Sep 14, 2016, 6:06:00 PM9/14/16
to
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 (in a signed field, irrelevant for an unsigned field).
Bill Woodger
Sep 14, 2016, 6:09:53 PM9/14/16
to
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 algebra, even when the result is zero.
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 algebra, even when the result is zero.
Joel C. Ewing
Sep 14, 2016, 7:52:18 PM9/14/16
to
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. The sign of the result is according to the rules of algebra, even when the result is zero.
>
>
I'm not sure what you mean by "the rules of algebra" lead to minus
> 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 algebra, even when the result is zero.
>
>
zero. In algebra and mathematics "0" is "0", neither positive or
negative. A signed zero is not a concept in algebra but purely an
artifact of the way we choose to represent the abstract concept of real
and natural numbers on a physical device -- namely, the choice of a
sign-magnitude representation, with one bit reserved for sign. The sign
bit is meaningless mathematically for a zero magnitude value but must
still have some state in the physical representation for the number..
Some architectures may choose to allow such "-0" values to have special
meaning rather than ever allowing it to be used as a zero value in a
computation or be generated for a zero result.
Joel C. Ewing
--
Joel C. Ewing, Bentonville, AR jce...@acm.org
Bill Woodger
Sep 15, 2016, 2:02:53 AM9/15/16
to
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 positive, positive and negative make a negative" that you learned at school just to know the sign of the result.
There is no reference to zero in the "rules of algebra" as remembered from around 45 years ago, we should have asked at the time.
Perhaps a bit of code on the chip to say "negative zero, I'm not having that, become positive" would be pointless overhead?
Divide says, in a note on an example, "Because the dividend and divisor have different signs, the quotient receives a negative sign."
Addition and subtraction have no such rule, so zero is just (positive) zero out of those.
So, Enterprise COBOL is wont at add a "ZAP-to-itself" when there is a danger that a result field (from calculation or truncation) may have produced a negative zero.
"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 positive, positive and negative make a negative" that you learned at school just to know the sign of the result.
There is no reference to zero in the "rules of algebra" as remembered from around 45 years ago, we should have asked at the time.
Perhaps a bit of code on the chip to say "negative zero, I'm not having that, become positive" would be pointless overhead?
Divide says, in a note on an example, "Because the dividend and divisor have different signs, the quotient receives a negative sign."
Addition and subtraction have no such rule, so zero is just (positive) zero out of those.
So, Enterprise COBOL is wont at add a "ZAP-to-itself" when there is a danger that a result field (from calculation or truncation) may have produced a negative zero.
Joel C. Ewing
Sep 15, 2016, 8:59:22 AM9/15/16
to
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 negatives make a positive, two positives make a positive, positive and negative make a negative" that you learned at school just to know the sign of the result.
>
> There is no reference to zero in the "rules of algebra" as remembered from around 45 years ago, we should have asked at the time.
>
> Perhaps a bit of code on the chip to say "negative zero, I'm not having that, become positive" would be pointless overhead?
>
> Divide says, in a note on an example, "Because the dividend and divisor have different signs, the quotient receives a negative sign."
>
> Addition and subtraction have no such rule, so zero is just (positive) zero out of those.
>
> So, Enterprise COBOL is wont at add a "ZAP-to-itself" when there is a danger that a result field (from calculation or truncation) may have produced a negative zero.
More precisely the PoP should have said "by the rules of algebra from
> 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 positive, positive and negative make a negative" that you learned at school just to know the sign of the result.
>
> There is no reference to zero in the "rules of algebra" as remembered from around 45 years ago, we should have asked at the time.
>
> Perhaps a bit of code on the chip to say "negative zero, I'm not having that, become positive" would be pointless overhead?
>
> Divide says, in a note on an example, "Because the dividend and divisor have different signs, the quotient receives a negative sign."
>
> Addition and subtraction have no such rule, so zero is just (positive) zero out of those.
>
> So, Enterprise COBOL is wont at add a "ZAP-to-itself" when there is a danger that a result field (from calculation or truncation) may have produced a negative zero.
the multiplier and multiplicand signs for a nonzero result and setting
the sign in a similar manner even if one or both operands are zeros".
Yeah, we can tell what they mean, but the wording is imprecise whether
they meant to imply that the rules of algebra address the zero case or
that they are just extending those rules as if the result were
nonzero. Since the rules of algebra don't associate any sign with
zero, the latter interpretation is the only reasonable one.
Tom Marchant
Sep 15, 2016, 11:40:42 AM9/15/16
to
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 equal to X'0F', but they are not when performing a character compare.
>When IBM decided to use "character" comparisons where possible for numerics, they had to ban the negative zero.
As to the idea that X'80000000' could be a negative zero, consider what happens when you add 1 to it. You get X'80000001'.
Dave may indeed have had a loop that used a binary counter that started out negative and eventually reached X'80000000'. Someone at the time may have looked at and mistakenly thought that it was negative zero, but it would have in fact been the maximum negative number, and subtracting one again would have resulted in overflow. If the overflow was ignored, the value would then be X'7FFFFFFF'. It would take a while for that counter to reach zero.
--
Tom Marchant
Bill Woodger
Sep 15, 2016, 12:59:56 PM9/15/16
to
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 COBOL only generate C or D, and if the required result is to be unsigned, code is generated by the compiler to "clobber" the sign to an F.
COBOL cannot generate a non-preferred sign (A, B, E) and there is no compiler-generated code to modify any potential production of same (if someone wants to get picky about F, then they can just pretend that I qualify correctly everywhere a correct qualification would apply).
There has to be compiler-generated code to allow for the initial generation, by "multiply", or by truncation, of a "negative zero".
So they are different there.
You *can still get* negative zeros in a COBOL program. There is no check on "source" to prevent a negative zero being involved (specifically as a negative zero). Thus, an incoming record or other incoming data, especially from an "external" source, but even from a non-COBOL source, could contain a negative zero and things could go badly. Another way is by screwing up with REDEFINES or group-MOVEs or LINKAGE SECTION definitions.
Which takes us to non-preferred signs, where basically the culprits are the same, but also adding COBOL generation where the same "data" is defined in different ways (signed and unsigned) in different places.
But yes, "character compares" (faster) over "decimal compares" does require that actual equivalence exists where logical equivalence exists, if your data doesn't "conform to PICture" (if it can contain "non-preferred" signs, and yes, for a signed field, that includes an F). So character compares require conformance to PICture, and that is what you promise with compiler option NUMPROC with sub-option PFD.
For NOPFD, the compiler has to either generate code to clobber (rectify) the signs in a temporary-stoage copy of the data, for comparisons, or to use the decimal instructions.
Then there was NUMPROC(MIG). An old "migration" setting, to have COBOL II for data with non-preferred signs behave more like OS/VS COBOL. However, since MIG was "faster" than NOPFD, and less hated than PFD (contentious), MIG survived a long time, until it disappeared with V5.
Its disappearance caused angst. However, there is "good" news. The code generated by NOPFD has been improved (PTF) and NOPFD is now much more comparable to what MIG was, and closer in performance to PFD. So if you have sloppy data, by accident or design, there is less of a performance hit.
There is not (as far as I'm aware) less of a "data hit". By this I mean the capability of NOPFD to take "bad data" and make it look good, which is extended over what is possible with PFD. NOPFD does use CLCs at times. PFD does use CP at times. I am writing of up to V4.2, heaps of things have changed for V5+ and anything could be different.
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 COBOL only generate C or D, and if the required result is to be unsigned, code is generated by the compiler to "clobber" the sign to an F.
COBOL cannot generate a non-preferred sign (A, B, E) and there is no compiler-generated code to modify any potential production of same (if someone wants to get picky about F, then they can just pretend that I qualify correctly everywhere a correct qualification would apply).
There has to be compiler-generated code to allow for the initial generation, by "multiply", or by truncation, of a "negative zero".
So they are different there.
You *can still get* negative zeros in a COBOL program. There is no check on "source" to prevent a negative zero being involved (specifically as a negative zero). Thus, an incoming record or other incoming data, especially from an "external" source, but even from a non-COBOL source, could contain a negative zero and things could go badly. Another way is by screwing up with REDEFINES or group-MOVEs or LINKAGE SECTION definitions.
Which takes us to non-preferred signs, where basically the culprits are the same, but also adding COBOL generation where the same "data" is defined in different ways (signed and unsigned) in different places.
But yes, "character compares" (faster) over "decimal compares" does require that actual equivalence exists where logical equivalence exists, if your data doesn't "conform to PICture" (if it can contain "non-preferred" signs, and yes, for a signed field, that includes an F). So character compares require conformance to PICture, and that is what you promise with compiler option NUMPROC with sub-option PFD.
For NOPFD, the compiler has to either generate code to clobber (rectify) the signs in a temporary-stoage copy of the data, for comparisons, or to use the decimal instructions.
Then there was NUMPROC(MIG). An old "migration" setting, to have COBOL II for data with non-preferred signs behave more like OS/VS COBOL. However, since MIG was "faster" than NOPFD, and less hated than PFD (contentious), MIG survived a long time, until it disappeared with V5.
Its disappearance caused angst. However, there is "good" news. The code generated by NOPFD has been improved (PTF) and NOPFD is now much more comparable to what MIG was, and closer in performance to PFD. So if you have sloppy data, by accident or design, there is less of a performance hit.
There is not (as far as I'm aware) less of a "data hit". By this I mean the capability of NOPFD to take "bad data" and make it look good, which is extended over what is possible with PFD. NOPFD does use CLCs at times. PFD does use CP at times. I am writing of up to V4.2, heaps of things have changed for V5+ and anything could be different.
Gibney, Dave
Sep 15, 2016, 3:39:54 PM9/15/16
to
I am pretty sure I misremembered it as binary and in reality it was packed. I didn't actually write the code. It was a subroutine that tried to distribute the difference due to rounding across a variable and not small number or "transactions". This was during testing and it didn't get into production with the failure in place. Of course, in 1981, we only had the one MVS system, so testing and production were commingled.
My original note was meant to reinforce the idea that if a program is using larger than expect amounts of CPU time, giving it more time is not always a good idea and that identifying why the CPU use is high can be more productive.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Thursday, September 15, 2016 8:41 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
My original note was meant to reinforce the idea that if a program is using larger than expect amounts of CPU time, giving it more time is not always a good idea and that identifying why the CPU use is high can be more productive.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Tom Marchant
> Sent: Thursday, September 15, 2016 8:41 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
Gibney, Dave
Sep 15, 2016, 3:43:43 PM9/15/16
to
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 :)
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 10:00 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 10:00 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
Tony Harminc
Sep 15, 2016, 4:07:28 PM9/15/16
to
On 14 September 2016 at 18:05, Bill Woodger <bill.w...@gmail.com> 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
> Yes, the compiler generates additional code to ensure that a -ve zero cannot be the result of anything in COBOL.
than CLC in the first place. Do you by any chance have an example of
the generated code for this? I don't write COBOL, so it would take me
roughly forever to come up with an example.
Tony H.
Bill Woodger
Sep 15, 2016, 4:24:38 PM9/15/16
to
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.
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.
Bill Woodger
Sep 15, 2016, 4:44:16 PM9/15/16
to
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 II for sure allowed negative zeros in the sense that there was no code to prevent them appearing as results in a COBOL program. The dates for COBOL II and the OSes you can run or Hercules would preclude using Hercules to show the first compiler which killed negative zeros in actual action.
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 II for sure allowed negative zeros in the sense that there was no code to prevent them appearing as results in a COBOL program. The dates for COBOL II and the OSes you can run or Hercules would preclude using Hercules to show the first compiler which killed negative zeros in actual action.
Gibney, Dave
Sep 15, 2016, 4:52:15 PM9/15/16
to
The program I was talking about was 1981, pre COBOL II. We did have the Capex Optimizer :)
We never saw COBOL II, jumped to 3 point something and are pretty much still there.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 1:44 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
We never saw COBOL II, jumped to 3 point something and are pretty much still there.
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU]
> On Behalf Of Bill Woodger
> Sent: Thursday, September 15, 2016 1:44 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Bypassing s322
>
Tony Harminc
Sep 15, 2016, 5:25:10 PM9/15/16
to
On 15 September 2016 at 16:24, Bill Woodger <bill.w...@gmail.com> wrote:
> February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)"
Got it, thanks.
> February this year, in the Archives, "COBOL Code Gened for MOVE COMP-3 S9(9) to S9(8)"
Tony H.
Bill Woodger
Sep 15, 2016, 5:35:05 PM9/15/16
to
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 is. Complete CPU-hogs that actually get to a normal end are rare, in my experience.
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 is. Complete CPU-hogs that actually get to a normal end are rare, in my experience.
Robert Wessel
Sep 15, 2016, 8:23:19 PM9/15/16
to
"Normal" mathematics does not recognize that zero has a sign at all.
Signed zeros are largely an artifact of computing. You see negative
zeros in formats where the sign is separate (most FP formats, packed
decimal, ones'-complement binary), and the way negative zeros are
handled has been fairly inconsistent between different systems. IEEE
FP has standardized how it works for (IEEE) FP. IBM mainframes have
made zeros positive for the results of packed additions and
subtractions (assuming a lack of overflow), but not for packed
multiplications and divisions. Mainframe hex FP behaves in a similar
manner.
Signed zeros are largely an artifact of computing. You see negative
zeros in formats where the sign is separate (most FP formats, packed
decimal, ones'-complement binary), and the way negative zeros are
handled has been fairly inconsistent between different systems. IEEE
FP has standardized how it works for (IEEE) FP. IBM mainframes have
made zeros positive for the results of packed additions and
subtractions (assuming a lack of overflow), but not for packed
multiplications and divisions. Mainframe hex FP behaves in a similar
manner.
Jesse 1 Robinson
Sep 15, 2016, 10:58:08 PM9/15/16
to
OK, true story. This will probably never happen again. The first CMOS processors were way slower than the water-cooled bipolar processors they replaced. We were fairly early in the transformation process. Overall a many-CP 9672 had lots of MSUs, but each individual CP was a dog; as little as one third the speed. Regardless of composite MSUs, batch runs on a single CP. We discovered early on that jobs that had run fine for years were suddenly getting S322 abends. Faced with the daunting task of updating TIME= on hundreds of jobs, we wrote an IEFUTL exit that granted two time extensions. The coded time value was not changed, just repeated.
Down side? Even though CMOS processors are now way faster than their soggy progenitors, we never removed the code. Batch jobs today hum along for quite a while. ;-)
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robi...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Bill Woodger
Down side? Even though CMOS processors are now way faster than their soggy progenitors, we never removed the code. Batch jobs today hum along for quite a while. ;-)
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robi...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Bill Woodger
Sent: Thursday, September 15, 2016 2:35 PM
To: IBM-...@LISTSERV.UA.EDU
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 wondering why it is sucking up all the CPU that it is. Complete CPU-hogs that actually get to a normal end are rare, in my experience.
To: IBM-...@LISTSERV.UA.EDU
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 wondering why it is sucking up all the CPU that it is. Complete CPU-hogs that actually get to a normal end are rare, in my experience.
Bill Woodger
Sep 16, 2016, 1:44:47 AM9/16/16
to
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 mathematics, is there a problem with infinity having a sign? Drifting OT again...
"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 mathematics, is there a problem with infinity having a sign? Drifting OT again...
Steve
Sep 16, 2016, 7:28:32 AM9/16/16
to
Threw out this whole thread I have not seen a "snippet" of the offending code. But there had been a lot of theoretical discussion.
Steve
Wayne Bickerdike
Sep 16, 2016, 5:20:21 PM9/16/16
to
*Where did you throw it? Or did you mean "throughout". Lulz..*
*"Threw out this whole thread I have not seen a "snippet" of the offending
code. But there had been a lot of theoretical discussion."*
*On Fri, Sep 16, 2016 at 9:26 PM, Steve <st...@stevebeaver.com
<st...@stevebeaver.com>> wrote:*
>
>
>
>
>
>
>
> * Threw out this whole thread I have not seen a "snippet" of the offending
> code. But there had been a lot of theoretical discussion. Steve *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * -----Original Message----- From: "Gibney, Dave" <gib...@WSU.EDU
> to > list...@listserv.ua.edu <list...@listserv.ua.edu> with the message:
> IBM-MAIN *
>
*-- *
*Wayne V. Bickerdike*
*"Threw out this whole thread I have not seen a "snippet" of the offending
code. But there had been a lot of theoretical discussion."*
*On Fri, Sep 16, 2016 at 9:26 PM, Steve <st...@stevebeaver.com
<st...@stevebeaver.com>> wrote:*
>
>
>
>
>
>
>
> * Threw out this whole thread I have not seen a "snippet" of the offending
> code. But there had been a lot of theoretical discussion. Steve *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * -----Original Message----- From: "Gibney, Dave" <gib...@WSU.EDU
> <gib...@WSU.EDU>> Sent: Thursday, September 15, 2016 3:43pm To:
> IBM-...@LISTSERV.UA.EDU <IBM-...@LISTSERV.UA.EDU> Subject: Re: Bypassing
> INFO IBM-MAIN
> ---------------------------------------------------------------------- For
> IBM-MAIN subscribe / signoff / archive access instructions, send email to
> list...@listserv.ua.edu <list...@listserv.ua.edu> with the message: INFO
> ---------------------------------------------------------------------- For
> IBM-MAIN subscribe / signoff / archive access instructions, send email to
> IBM-MAIN
> ---------------------------------------------------------------------- For
> IBM-MAIN subscribe / signoff / archive access instructions, send email to
> list...@listserv.ua.edu <list...@listserv.ua.edu> with the message: INFO
> ---------------------------------------------------------------------- For
> IBM-MAIN subscribe / signoff / archive access instructions, send email to
> IBM-MAIN *
>
*-- *
*Wayne V. Bickerdike*
Edward Gould
Sep 17, 2016, 12:09:52 AM9/17/16
to
> On Sep 15, 2016, at 2:43 PM, Gibney, Dave <gib...@WSU.EDU> 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——————————————————————
>
> 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 :)
But I will bet that a compiled cobol program from 35 years ago will still execute correctly in 2016.
I have seen it for myself and in Y2K testing.
Ed
0 new messages