Re:Programming Question/ Bug?

Discussion created by ca.portal.admin on Aug 22, 2007
One of my programmers asked me this question. I am not sure why this

Field P-INVOICE-NO is defined as Pic X(14). Code in the ADS program
checks if the field contains zeros using any of the following lines of


If the field is all zeroes, it executes an error message, as it should.
But if the field is changed to 0A (or any 0 and alpha combo) and enter
is pressed - the screen does not recognize that the field now contains
something other than 0, or zeros, or zeroes and still produces the error
message. This is happening in programs that are recently changed. We are
running IDMS V16.0 Service Pack 4.

I have searched Support Connect and have found no mention of such a
problem. Has anyone heard of or experienced this? How did you fix it?
The programmer got around this by checking for 0 in every position of
the field, but the code above is used in several of our programs and has
us concerned.

Thanks for your help.
IDMS Public Discussion Forum


Re: Programming Question/ Bug?
"This type of talk is not appropriate for this list. Please go to the DB2
List and spew your venom.

In a message dated 8/22/2007 11:41:42 A.M. Eastern Daylight Time,
Vince.Jensen@CGI.HEALTH.GOV.AB.CA writes:

I can't believe what I am seeing re this 0C4 abend. There is a
secondary code that is issued with the abend that will narrow down the
cause of the problem. While it will not tie down the error in its
entirety, why has no one asked for this code before. Where the heck are
the experts here. This looks like a bunch of chickens.

Please publish the full error code, and we can provide more
advice/solutions that are relevant to the problem.

Vince Jensen
Alberta Health

-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Cherlet, Gary (JTS)
Sent: Tuesday, August 21, 2007 6:31 PM
Subject: Re: Programming Question/ Bug?

Is the field mapped in/out directly on the Map - or is there a separate
element in a ""map work record"" that is MOVEd to the field that is being
tested. If that's the case it would be worthwhile checking the PICture
of the map field - and especially in that case (as has already been
mentioned) with the ADSC compile option specifies ADS or COBOL moves.
Other things to look at:

() Is ""automatic editing turned on at the map level and at the field
() If so do you have an ""external picture"" that would force a check (by
automatic editing) for all numerics?
() Do you have any pad/justification rules (e.g.. pad with zeroes)?
() In ADSC do you specify EXECUTE ON EDIT ERRORS Yes - because if that's
the case and if automatic editing is enabled you would need to do an ""if
field .... In error ...."" check
() Note that if the external picture is 999999 and automatic editing is
enabled any non-numeric data that is entered should be stripped out by
the run-time mapping system - that's why some of the suggestions about
using ADSALIVE with a break point before the IF test is important.

If this is a new behaviour for old code then I would suspect that a
yes/no switch has been flipped somewhere along the line in either ADSC
or MAPC.

HTH - cheers - Gary

Gary Cherlet
Justice Technology Services
Department of Justice, SA Government
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original
transmission and its contents. Confidentiality: This e-mail may
contain confidential information which also may be legally privileged.
Only the intended recipient(s) may access, use, distribute or copy this
e-mail. Individual Views: Unless otherwise indicated, the views
expressed are those of the sender, not Justice Technology Services.
Computer Viruses: It is the recipient's responsibility to check the
e-mail and any attached files for viruses.