|
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-2024 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.