Hi,

I tried looking for similar posts but was unfruitful.

The below code works for 714 but not in 769. I am unable to use D20 or D* for any -READ to get computed values into variables. Any thoughts please. am i coding incorrectly?


TABLE FILE CAR
PRINT
COMPUTE A/D20c=99999999;
BY CAR NOPRINT
WHERE CAR EQ 'AUDI'
ON TABLE HOLD AS CAR_HOLD FORMAT ALPHA
END

-RUN
-READ CAR_HOLD &A.D20.

-TYPE &A;

In 714 this works properly but in 769 i get the error "UNRECOGNIZED FORMAT OF AMPER VARIABLE."

We are in the process of upgrading our reports to 769 from 714 and we facing **** a lot of small but show stopping issues such as these.

If you guys know of other posts with similar probs of upgrades to 769 please point me in the right direction.

Thanks!!!

This message has been edited. Last edited by: Kerry,

Try:

TABLE FILE CAR
PRINT
COMPUTE A/D20c=99999999;
BY CAR NOPRINT
WHERE CAR EQ 'AUDI'
ON TABLE SAVE AS CAR_HOLD
END

-RUN
-READ CAR_HOLD &TEST.A20.

-TYPE &TEST;

-EXIT

Documentation: Developing Reporting Applications > Managing Flow of Control in an Application > Customizing a Procedure With Variables > Reading Variable Values From and Writing Variable Values to an External File

quote:

.format.
Is the format of the variable. For a free-format file, specifying this value is optional. For a fixed-format file, format is the length or the type and the length. The type is either A (alphanumeric), which is the default, or I (numeric). The format value must be delimited by periods.

thank you both.. using A20 works... :-)

Yes the doc says that. Nevertheless, DM itself does not really care about the doc. A DM variable is a number, unless proven otherwise. Keeping that in mind, there is no real need of specifying a format when reading &var's with DM, because it will define itself what the format of the variable is or will be. So, -READ CAR_HOLD &TEST.20. will also work fine.

Actually, I believe it's the other way around. A DM variable is a string unless you've specified otherwise. Using the variable in a numeric expression is one way of telling it otherwise. You can also use the .TYPE operator which tries to evaluate the variable as a number and passes an N if successful or an A if it is not. From the manual:

For a fixed-format file, format is the length or the type and the length. The type is either A
(alphanumeric), which is the default, or I (numeric). The format value must be delimited
by periods.

Also refer to the DMPRECISION setting for performing functions with numeric values where precision is needed.

Just realized I am restating part of what Francis quoted - anyway alpha is the default format. &vars are always strings.

I agree with GamP. A DM variable is a number unless proven otherwise. Run this code and all six variables have a .TYPE of N.

-SET &W = '123';
-SET &X = '123.456';
-SET &Y = '  123  ';
-SET &Z = '  123.456  ';
-SET &A = ' 123.456 ' | ' ';
-SET &B = EDIT(&A);
-TYPE &W &W.TYPE
-TYPE &X &X.TYPE
-TYPE &Y &Y.TYPE
-TYPE &Z &Z.TYPE
-TYPE &A &A.TYPE
-TYPE &B &B.TYPE

If you tried to use any of these variables as an argument in a function that requires alpha input, you would receive an error about invalid type of argument #X. I doesn't matter if you put quotes around the variable in the argument. It doesn't matter if you use .QUOTEDSTRING.

For example, the only way to get DM to recognize &XDATE as a string in the code below is to use .QUOTEDSTRING and concatenate a null character to it.

-SET &XDATE  = '04282010';
-SET &YDATE = STRREP(&XDATE.LENGTH,&XDATE.QUOTEDSTRING | '', 1, '/', 0,'X',&XDATE.LENGTH,'A&XDATE.LENGTH');

I agree with Darin. DM variables are alphanumeric strings, always have been. Now it may recognize a numeric string as number, but the variable itself is still a string. Just add the following to Dan's code.

-SET &C=EDIT(&X,'$$$9999');
-SET &FRACTION1=GETTOK('&X.EVAL',&X.LENGTH,2,'.',3,'A3');
-SET &FRACTION2=GETTOK(&X,&X.LENGTH,2,'.',3,'A3');
-TYPE &C &C.TYPE
-TYPE &FRACTION1 &FRACTION1.TYPE
-TYPE &FRACTION2 &FRACTION2.TYPE

If &X were truly a number, EDIT and GETTOK would not work because this version of the EDIT function requires alpha input and the only valid input for GETTOK is a string.

Now as for Dan's STRREP example, STRREP is a relatively new function in the FOCUS/WebFOCUS language. IMO, what he illustrates is a bug in the function or some kind of incompatibility between STRREP and DM, because this fails as well (at least in 7.1.3).

-SET &ZDATE = STRREP(8,'04282010',1,'0',1,'X',8,'A8');

gives the following error:

0 ERROR AT OR NEAR LINE     28  IN PROCEDURE _ADHOCRQFOCEXEC *
 (FOC36355)  INVALID TYPE OF ARGUMENT #4 FOR USER FUNCTION STRREP

Notice the error is on argument 4, not 2. Also, if I change the X to 9, the error moves to Argument 6. What's up with that? Therefore, at least in 7.1.3, STRREP has problems when used in DM.

quote:

You can also use the .TYPE operator which tries to evaluate the variable as a number and passes an N if successful or an A if it is not

Like I mentioned, using the .TYPE does an evaluation of the variable to see if it qualifies as a number. That does not change the string into a number, it only qualifies it to be used as a number. The default, as stated in the manual, is alphanumeric. Not sure why the STRREP function doesn't like the rules.

In any case, if you understand DM variables and how they are used, it isn't even an issue. So for those who know enough to debate the issue, it doesn't matter. I'll stick to my rule of thumb, those who disagree can use their own, but either way we won't have a problem. For those who are still mastering the concept, stick to what the manuals says and ask IBI if something doesn't seem to work like the manual says (now I KNOW that never happens!)