|
Barbara, thanks for your reply. I wanted to test your assertion that blanks
in zoned decimals should cause a DDE exception when moved to an alpha (or
numeric?) variable. Hence my simple app:
H 1
I DS
I 1 70#VAR
I 1 7 @VAR
C MOVE '1 3 5 7' @VAR
C MOVE #VAR TEST 7
C Z-ADD#VAR TEST# 70
C DUMP
C MOVE *ON *INLR
The dump shows:
#VAR 00019D ZONED(7,0) 1030507
@VAR 00019D CHAR(7) '1 3 5 7'
TEST 000196 CHAR(7) '1030507'
TEST# 00019D PACKED(7,0) 1030507
This program completed normally, no DDEs. FWIW, I'm running v3r2.
For the sake of just trying to see if it would produce different results, I
converted the above source through the IBM CVTRPGSRC and made no changes to
the source. I expected that the results would be the same, but the dump shows
the displayed value of #VAR differently (don't know if this is significant):
NAME ATTRIBUTES VALUE
DS
#VAR ZONED(7,0) 1 3 5 7. 'F140F340F540F7'X
@VAR CHAR(7) '1 3 5 7' 'F140F340F540F7'X
TEST CHAR(7) '1030507' 'F1F0F3F0F5F0F7'X
TEST# PACKED(7,0) 1030507. '1030507F'X
BTW, the idea behind the MOVEL of a 9 digit numeric to a 31 alpha in my
previous snippet was to accept only positive numbers as valid; if negative
value was acceptable, then you'd MOVE it.
Finally, Barbara, I decided to try your example as follows:
H DEBUG
D zonedBytes s 30a based(pZonedByte)
D DS
D #VAR 1 7 0
D @VAR 1 7
C MOVE '1 3 5 7' @VAR
C move *zeros work## 30
C eval pZonedByte = %ADDR( #VAR )
c EVAL %SUBST(WORK##:%size(WORK##)-%size( #VAR )+1)
c = %SUBST(zonedBytes : 1 : %size( #VAR ) )
c testn work## 99
C DUMP
C MOVE *ON *INLR
In this case, the TESTN functioned as I expected and indicator 99 was NOT
turned on. So I have a solution now.
NAME ATTRIBUTES VALUE
DS
#VAR ZONED(7,0) 1 3 5 7. 'F140F340F540F7'X
@VAR CHAR(7) '1 3 5 7' 'F140F340F540F7'X
PZONEDBYTE POINTER SPP:C00376000448
WORK## CHAR(30) '000000000000000000000001 3 5 7'
VALUE IN HEX
'F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F140F340F540F7'X
ZONEDBYTES CHAR(30) '1 3 5 7 Ë{ Î ç '
VALUE IN HEX
'F140F340F540F70080000000000000000073C00376000448000000000000'X
>It looks to me like TESTN was designed for a very specific
>purpose that isn't particularly relevant any more.
Barbara, out of curiosity, the way you stated the above seems to indicate that
there are/were no design specs for opcodes; in this particular case, TESTN.
Is there no documentation that spells out the intentioned usage of opcodes,
i.e. what it does and doesn't do? (Keeping in mind that TESTN originated in
the dark ages...)
Dan Bale
IT - AS/400
Handleman Company
248-362-4400 Ext. 4952
-------------------------- Original Message --------------------------
>Date: Wed, 3 Jan 2001 12:25:00 -0500
>From: D.BALE@handleman.com
> ...
>However, in my development testing, I am being reminded that TESTN does
not
>work on numeric fields. So now I have to move the numeric value to an
alpha.
>I will follow a tip that someone else shared last month:
>
> C MOVE *ZEROS WORK## 31
> C MOVELHDRSWP WORK##
> C TESTN WORK## 91
> C... etc. for several more fields
Dan, if HDRSWP is a zoned value, you can get a DDE exception on the
MOVEL to WORK##. Also, you should use MOVE, not MOVEL, to get the
sign byte positioned correctly.
It would be easier to use RPG IV for this:
D zonedBytes s 30a based(pZonedBytes)
C MOVEL *ZEROS WORK##
C EVAL pZonedBytes = %ADDR(HDRSWP)
C EVAL %SUBST(WORK## : %size(WORK##) - %size(HDRSWP) + 1)
C = %SUBST(zonedBytes : 1 : %size(HDRSWP)
C TESTN WORK##
Or better, write a subprocedure:
D testZoned pr 1n
D pZoned * value
D len 10i 0 value
C eval *in91 = testZoned(%addr(HDRSWP) : %size(HDRSWP))
C eval *in91 = testZoned(%addr(HDRDTM) : %size(HDRDTM))
...
P testZoned b
D testZoned pi 1n
D pZoned * value
D len 10i 0 value
D WORK## s 30a inz(*zeros)
D zonedBytes s 30a based(pZoned)
D saveInd s 1n
D retInd s 1n
C EVAL saveInd = *IN91
C EVAL %SUBST(WORK## : 30 - len + 1)
C = %SUBST(zonedBytes : 1 : len)
C TESTN WORK## 91
C EVAL retInd = *IN91
C EVAL *IN91 = saveInd
C RETURN retInd
P testZoned e
>But I am left wondering, since it is possible for numeric variables to
DDEs,
>why wasn't TESTN ever designed to work with both alpha and numeric
variables?
Dan, I remember being surprised myself that TESTN wasn't for numeric
fields,
and also that when applied to character fields, TESTN couldn't test for
valid
packed data. It looks to me like TESTN was designed for a very specific
purpose that isn't particularly relevant any more.
Barbara Morris
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.