Including the length (characters) of a field in a LIST

Posted onMarch 6, 2015

LIST RMIM EVAL “SUBR(‘-LENS’,DESC1)” DESC1

DESC1 is the DICT attribute.

RMIM……………. 2087
SUBR(“-LENS”,DESC1). 27
DESC1…………… GCA8040 BLACK 1-1/2″ X 200′

RMIM……………. 3187S
SUBR(“-LENS”,DESC1). 36
DESC1…………… *17177*FLLA-WINGED:#5747-9*0110*5747

RMIM……………. 285753
SUBR(“-LENS”,DESC1). 59
DESC1…………… AX1G-1-30-91-WCA, RENU CONVERTER FROM WCA WITHOUT TOP STENT

Temenos Documentation on GitHub

Posted onNovember 16, 2013

https://github.com/begoon/temenos-documentation

Show Me The Money – jBASE Decimals and OCONV/ICONV

Posted onJuly 9, 2013

Credit: Kevin King, Precision Solutions – Article from International Spectrum

For eons, MultiValue programmers have used the “MR2” and “MD2” conversions for formatting money values. While this conversion is perfect for converting a stored money amount to something human-readable — for those of us with a decimal currency, that is — there are a surprising number of developers unaware that this code can do much more.

Whether formatting a money, decimal, date, time, alphanumeric, or other type of value, all of the conversion features of the MultiValue platform are worthy of continued study. In UniData, conversion codes are documented with the ICONV(..) and OCONV(..) functions in the BASIC Reference, but with conversions being a crucial feature of dictionaries and the query language you may find more information about conversions just about anywhere in a documentation bundle.

Today let’s take a brief glance at the “MR2” conversion code. Years ago it was explained to me that the “M” and “R” mean “mask” and “right justified” and the following “2” means “show two decimal places”. While accurate, it missed a very important detail: There’s a digit missing!

The “MR” conversion code — as well as its kissing cousin “MD” (Mask Decimal) and even “ML” (Mask Left) — can be followed by two separate number parameters. The first number is the number of decimals to show, and the second is the number of positions to scale (move) the decimal point. For example, a conversion of “MR2” is really an abbreviation of “MR22”, which means to show two decimal points after scaling the decimal by two positions. Similarly “MD4” will show four decimal places after scaling the number by four decimal places. (In an OCONV the decimal moves to the left; in an ICONV the decimal moves to the right.)

So what’s the big deal? If not typing that second digit saves you a keystroke and it just works, why should you care? On the other hand, what if you want to show a certain number of decimals but scale the number differently?

Let’s say for instance we’re building a report program that’s reading a list of payment amounts from a text file. As we look at the text file we instantly notice that the payment amounts are unpredictably formatted, like this:

23
5.2
325.46
6432.236

To output these on our report we need to convert these values so that each payment amount has two decimal places, no more, no less. Throughout the years I’ve seen a number of ways to achieve this in code, the most common being to input convert the raw value by two decimal places, and then output convert that result by two decimals, like this:

VALUE = OCONV(ICONV(IN.VALUE,’MR2′),’MR2′)

While this does the trick, wouldn’t it be cool if we could do it all with a single conversion? With separate show and scale numbers in our “MR” conversion, we can do exactly that:

VALUE = OCONV(IN.VALUE,’MR20′)

In this example, the “MR20” says to mask the number, right justified (though the justification doesn’t matter, see sidebar), show two decimal places, but scale the decimal by zero places. In other words, the decimal won’t move and we’ll still get our two decimal places in the human-readable output.

Looking at this from a different perspective, what if we want to take a number that is stored with two decimal places and show it in thousands with no decimal places? For our example, let’s say the stored value is “12345678” which represents “123456.78”. For our report, we want to show this value simply as 123. We certainly could OCONV the input value using the “MR5” conversion to format the number as “123.45678” and then use an “MR0” conversion to scale this to “123”, but why do it with two conversions when we can do it with a single “MR05”?

While this is just one of many options available with of the MR, MD, and ML conversion codes, it’s a significant detail that can simplify the transformation of numbers from one base and format to another in a single operation. There are many other options for adding commas, dollar signs, asterisks, and padding, so if you’re interested, dig into the manual and see all that these conversion codes have to offer.

Did You Know?

As an output conversion, MR2, ML2, and MD2 are nearly, if not entirely, identical depending on the MultiValue platform in use. The justification code (R, L, or D) means nothing unless the number has fill and width parameters, such as MR2%10 or ML2#10, where the “%” represents “fill with zeroes” and the “#” represents “fill with spaces,” both in a field of 10 characters.

# # #          # # #          # # #

 

 

FMT

Posted onJune 4, 2013

Here’s a simple list but it also shows how you can dictate the column width using FMT, 30 is the column width which is always followed by #, T forces the output to text. Text is always left justified.

LIST DICT RMIM D/CODE A/AMC V/CONV FMT”15#T”  V/CORR FMT”30#T”  V/TYPE V/MAX WITH D/CODE “A]” “X]” “U]” “S]” “D]” “V]” “I]” “M]” “PH]” BY A/AMC BY D/CODE

You can also use “R#2” which is right justified in a field two characters wide and “L#2″ which is left justified in a field two characters wide. You can substitute the 2 with any number. R and L works best with numeric fields. You can use it with any attribute type but the output isn’t reliable.

LIST DICT RMIM D/CODE A/AMC FMT”R#2″ V/CONV FMT”15#T”  V/CORR FMT”30#T”  V/TYPE V/MAX WITH D/CODE “A]” “X]” “U]” “S]” “D]” “V]” “I]” “M]” “PH]” BY A/AMC BY D/CODE

LISTDICT RMIM or LISTDICTS RMIM will do basically the same thing. I didn’t lookup ‘LISTDICTS’ to find the difference between the two verions.

New Post

Posted onApril 15, 2013

Right Here

New

Posted onApril 15, 2013

Here

Posted onApril 8, 2013

As most of those who have built “F” codes know, there are three levels in the stack. Sometimes a forth level is needed. This is particularly true when using the string extract code “[]”. A “feature” of code processing is that value-marks can be used to separate command statements.
Suppose that you need to examine the last character in a string for a numeric value. If it’s numeric then report that value, else report nothing. Attribute 5 is tested in the following example.

TEST.LAST.CHAR

001 S
002 0
003 NBR
008 F;5;(L0)}F;5;LPV;”1”;[];(P(1N))
009 R
010 3

The character “}” following the “(L0)” string is a value mark. The “LPV” returns the result of the prior command. The “[]” extract function expects to find the string in Stack 3, the start position in Stack 2 and the length in Stack 1. “Wishing for a Stack 4” is due to the length of the string function needed to “load” Stack 1. If the length of string function (L0) was included in a single value command sequence, then it would have “pushed” a needed data value off the stack – “into Stack 4”. Therefore a multi-value sequence was needed.

Of interest – the commands separated by value-marks can be any valid correlative or conversion code. In other words, you can combine “F” codes with “A” codes with… you get the idea.

Using the above example – suppose that the results needed to be concatenated to the end of the data value in attribute 6.
Then attribute 8 in the dictionary item is:
008 F;5;(L0)}F;5;LPV;”1”;[];(P(1N))}A;6:(LPV)
The character “}” preceding the “A” is a second value mark.