Cutting to the chase: new undocumented function PTOA convers Packed Decimal to Alpha. Arguments are just like FTOA (a documented fuction). Online documentation on converting packed is just flat nuts, so ignore it.
Orginal question, with interesting chat below, was:
Who knows how to convert packed 14 to alpha?
FTOA doesn't work.
Converting to F and then FTOA doesn't work.
Its too big for I
Converting to D and then FTOA doesnt work.
help?

This message has been edited. Last edited by: FP Mod Chuck,

quote:

Originally posted by susannah:
[qb] Who knows how to convert packed 14 to alpha?
FTOA doesn't work.
Converting to F and then FTOA doesn't work.
Its too big for I
Converting to D and then FTOA doesnt work.
help? [/qb]

The trick with converting large Packed fields (over 16 display positions, over P8 actual) to alpha is in figuring out the sign, and stripping it out. You can define the field as ALPHA then use the UFMT subroutine to "unpack" it to an ALPHA field that's exactly twice the length of the original PACKED field.

If the last half-byte is "D" then it's negative, otherwise it's positive... (which gives you the sign). Then it's just a matter of putting the sign back in front of the number and right justifying the result.

Here's a sample with the necessary DEFINEs in the MFD. "PACK1" is a PACKED field with an actual of P10.

FILE=PACK,SUFFIX=FIX,$
SEGMENT=ONE, SEGTYPE=S0,$
FIELD=PACK1 ,ALIAS=P1, A10,A10,$
FIELD=FILLER,ALIAS=F ,A70,A70,$
DEFINE PACK1A/A20=UFMT(PACK1,10,'A20');,$
DEFINE SBYTE/A1=EDIT(PACK1A, '$$$$$$$$$$$$$$$$$$$9');,$
DEFINE SIGN/A1=IF SBYTE EQ 'D' THEN '-' ELSE ' ';,$
DEFINE PACKNUM1/A20=SIGN||EDIT(PACK1A, '9999999999999999999$');,$
DEFINE PACKNUMALPHA/A20=RJUST(20, PACKNUM1, 'A20');,$

Hope that helps...

-Chris

Chris, you say that your original PACK1 field is P10, but in your mfd, you have it as A10,A10.
I don't understand;
My original field is P13,P7 (and sign is always +)
When i try to define an A7 version of it
PACK1/A7=MYFIELD; or even EDIT(MYFIELD);
in order to then unformat it,
PACK1A/A14=UFMT(PACK1,7,'A14');
it bombs, because my original field is Packed.
In your example, your original field is Alpha.
??

Hi, Susannah,

Sorry if that was unclear - the data is PACKED, but I have it defined in the MFD as A10 so that I can pass it to the UFMT subroutine (which requires ALPHA input).

You can just change your MFD so the original field is USAGE=A7, ACTUAL=A7 and UFMT will work against it, and you can skip a couple of defines since you don't have to worry about the sign.

However, if you need the field defined as PACKED for other display or calculation purposes (in other programs) and you don't want to mess with having two versions of the Master File Description, then we need to find another way.

Actually... if the ACTUAL is only P7, then have you tried a straight EDIT?

DEFINE PACKALPHA/A13=EDIT(PACKNUM);

??

You'll get leading zeroes, but there are ways to get rid of these if you need to. I tried this in MF FOCUS 7.3 and it worked as expected with a field of that size.

Let me know if that works for you.

Regards,

-Chris

I also looked on Knowledge BAse under UNPACK, and got the PKOUT function, which of course is completely wrong.
I looked up PACKED DECIMAL CONVERT and got the FTOA function which doesn't work for packed, even tho the 'solution' said it was 'the' way to do it for packed.
my files are DB2 ON AS400
and no i can't edit the master
no the A14 suggestion you pm'ed doesn't work
i made it bigger a28.
and it packs with leading zeros ,as you said, but truncates the field, only giving me the first 7 sig dig.
This is a big prob for me. when i bring it down, its becomes P14,A14, so i can use an alternate MFD, with A14,A14 and it'll work. But what a pain, especially if i change my MFD, which i do alot.
But there's got to be a way . . .

Actually FTOA should work fine. You just have to convert the packed input field to D format first (F format would not have enough precision for this). You can do this dynamically right in the DEFINE using the below syntax. PACK1 is the name of the original packed field in question.

Try this:

TABLE FILE BIGPACK3
PRINT PACK1
COMPUTE ALPHA_PACK/A18 = FTOA(PACK1,'(D14)', ALPHA_PACK);
COMPUTE ALPHA_PACK_EDT/A18=EDIT(ALPHA_PACK, '99$999$999$999$999');
END

Try this and let me know. If this DOES NOT work, then let me know the exact error message or behavior.

BTW, I edited this post to add in the second define for editing out the commas. Also, "PACK1" in my example is USAGE=P14, ACTUAL=P7 (mine has negative values). You might need to adjust this for your P13 USAGE.

Regards,

-Chris

well, guess what. there's an undocumented new feature
PTOA
and it works like a charm. Same function format at FTOA.
whew! Bless you for helping me.
oh, and i tried D, it didnt work. It all 'seems' like it 'should' work, but no cigar!

Chris-
This probably slipped your mind: the way to suppress the commas in a D field is to use the edit character 'c'. That's right, the small c as in D12.2c. Works like a charm.

quote:

Originally posted by jimster06:
[qb] Chris-
This probably slipped your mind: the way to suppress the commas in a D field is to use the edit character 'c'. That's right, the small c as in D12.2c. Works like a charm. [/qb]

Yup. That's what I get for not using FOCUS every day. I get stupid. I tried "C" (upper case) and when that didn't work, I just used the EDIT mask. Plus I like brute force methods best anyway... Worked fine on the mainframe. But then again, the EDIT directly against the P14 field worked fine on the mainframe too (FOCUS 7.3) and was the simplest solution... Guess I'm spoiled - we get all the latest releases here...

quote:

Originally posted by susannah:
[qb] well, guess what. there's an undocumented new feature
PTOA
and it works like a charm. Same function format at FTOA.
whew! Bless you for helping me.
oh, and i tried D, it didnt work. It all 'seems' like it 'should' work, but no cigar! [/qb]

Hmmm... PTOA. Gotta remember that one. Just tried it on a P20 and it worked like a charm. Things just keep getting easier...

Glad you found something that worked for you.

Regards,

-Chris

Beware of use of the edit function as it cannot handle numbers larger than 9 positions. It will not give any errors but will give an alpha number that is not the same as the original packed number.

quote:

Originally posted by ET:
[qb] Beware of use of the edit function as it cannot handle numbers larger than 9 positions. It will not give any errors but will give an alpha number that is not the same as the original packed number. [/qb]

That was previously the case but no longer. EDIT used to be limited to what you could store in an i4 ACTUAL which, accounting for two's complement notation, is (2**31 - 1) or 2,147,483,647. Over that it truncated and gave odd results.

As of FOCUS 7.2 (and, I believe WebFOCUS 5.2), EDIT was enhanced to support larger numbers. I was surprised when I tried it, too. Check it out!

Customer Support would probably have the details of the specific enhancements to EDIT.

Regards,

-Chris

Chris,

Is this enhanced version of edit documented as a new features of 7.2? I do not recall coming across this. As we are at 7.11 I cannot try this out. How big a number can edit now convert? Can it handle the full 31 positions of large p16(actual format) packed field?

quote:

Originally posted by ET:
[qb] Chris,

Is this enhanced version of edit documented as a new features of 7.2? I do not recall coming across this. As we are at 7.11 I cannot try this out. How big a number can edit now convert? Can it handle the full 31 positions of large p16(actual format) packed field? [/qb]

That's a really good question. I couldn't find it in the doc. I found info about it on the Tech Support Web site, but not in the Summary of New Features for FOCUS 7.2. I just spoke with the manager of doc for mainframe FOCUS and she's going to look into it and let me know if/where it's documented.

Since it introduced no Upward Compatibility issues (syntax is still the same, and it still works fine on smaller numbers, too), it's possible it was not documented (but IMHO, it should have been). I'll see what I can find out.

Regards,

-Chris

I just found out that we have a test version of Focus 7.2 mainframe installed in test.

I tried this against the car file and it did not appear to work with a 10 digit packed number.


> ? release
FOCUS 7.2.0 CREATED 04/30/2002 xxxx.xx

TSO ALLOC F(CAR) DA('FOCUS.FOCUS.CAR') SHR REUSE
DEFINE FILE CAR
NUM1/P15 WITH COUNTRY=9999999999;
NUMA/A15=EDIT(NUM1);
END
TABLEF FILE CAR
PRINT NUM1 NUMA COUNTRY
IF RECORDLIMIT EQ 1
END

PAGE 1


NUM1 NUMA COUNTRY
---- ---- -------
9999999999 000001410065407 ENGLAND

quote:

Originally posted by ET:
[qb] I just found out that we have a test version of Focus 7.2 mainframe installed in test.
[/qb]

Hmmm... the tech support post I read (internal only) said the enhanced EDIT was available in FOCUS 7.2 and WebFOCUS 5.2 and that it works for packed fields up to 15 digits in FOCUS 7.2 (no such restriction in WebFOCUS 5.2).

In FOCUS 7.3, I tested up to P31 and it worked as expected...

See below:

? REL
FOCUS 7.3.0 CREATED 12/17/2003 QA-11.01

DEFINE FILE CAR
NUM1/P31 WITH COUNTRY=9999999999999999999999999999999;
NUMA/A31=EDIT(NUM1);
END
TABLEF FILE CAR
PRINT NUM1 NUMA COUNTRY
IF RECORDLIMIT EQ 1
END

>>
PAGE 1


NUM1 NUMA COUNTRY
---- ---- -------
9999999999999999999999999999999 9999999999999999999999999999999 ENGLAND

--

I'm still waiting to hear back the Product Management/Documentation folks. I'll let you know what I can find out.

Regards,

-Chris

Edward,

Product management is still investigating this but they told me they will be replying on the forum shortly with the details.

Regards,

-Chris

PTOA is currently an undocumented feature in the FOCUS products. We will release a Tech Memo in the next 3 weeks documenting its use and we will include it in forthcoming documentation.
PTOA was created to handle the PACKED/ALPHA conversion in the same way that FTOA handles floating point conversion. It is our recommended method of handling this type of conversion. PTOA uses the same type of parameters as FTOA -

PTOA(Input field, '(packed format)', Output field);

PTOA is required for PACKED fields that have decimal points. It will not add leading zeroes to the output as EDIT will. It will support Packed fields up to P31.n. Further, it will work correctly whether regardless of the COMPUTE or DEFINES settings - the settings used to engage the expression compilers in FOCUS.

Officially, the FOCUS documentation says the following about the use of EDIT to convert from numeric to alpha formats:

"When converting a floating-point or packed-decimal field to alphanumeric format,
EDIT removes the sign, the decimal point, and any number to the right of the decimal
point. It then right-justifies the remaining digits and adds leading zeros to achieve the
specified field length. Converting a number with more than nine significant digits in
floating-point or packed-decimal format may produce an incorrect result."

Initially EDIT converted between ALPHA and INTEGER formats, requiring format changes prior to calling it. In the case of Packed numbers longer than 9 digits it seems to have gotten a little smarter when:
1. The number is a long packed - P17 or greater,
2. SET DEFINES=COMPILED in FOCUS 7.3 or Iway/WebFOCUS 5.2.
3. SET COMPUTE=OLD in FOCUS 7.2.
In these cases, the EDIT conversion will work.
Among the reasons that it is not officially supported is the current problem in FOCUS 7.2 where COMPUTE=NEW, where the size of the number is limited to the largest number available in an I4- basically an I9. Above that, the number is treated as a very large negative number and the results are not good. In FOCUS 7.2, if you SET COMPUTE=NATV, this problem will go away and the numbers between P10 and P16 will appear correct. However, you will still get leading zeroes on the output and the decimal data will be lost.
For this reason, we do not recommend that you use EDIT beyond the documented limit.

Customer Suppport has provide another technique to handle the packed conversion where the number is larger than 9 digits, or there is decimal data. That is to use FTOA and simply "lie" about the format - indicating for example D12.2 instead of P12.2. This technique should continue to work.

I hope this clarifies the PTOA, EDIT situation.

I have a specific question on this undocumented PTOA function that Walter or another IBI'er can answer. I would like to know if it is okay (Is PTOA supported BY IBI?) to use it in our current release (release info below) of mainframe Focus. I have tested it on some big numbers and it appears to work.

Thanks



PTFS APPLIED TO RELEASE 7.1.1
FROM PTFTABLE LOCATED IN TEST.FOCUS.FOCLIB

COUNT PTF NUM CREATED APPLIED SUPERSEDED BY PUT LEVEL
----- ------- ------- ------- ------------- ---------
1) 179491 20010608 20010815 ...... ......
2) 185775 20010815 20010815 ...... ......
3) 191271 20011012 20011028 ...... ......
4) 193887 20011112 20020108 ...... ......

quote:

Originally posted by ET:
[qb] I would like to know if it is okay (Is PTOA supported BY IBI?) to use it in our current release [/qb]

Hi, Edward,

The short answer is, if it's in your release and it works, then use it. As for whether it's "officially" supported in 7.11, you're best off contacting Customer Support and actually opening a case.

-Chris

Hello, I have a variable which is called AGE and it is D20.2 I want to convert it to Integer or Alpha using FTOA. I have HOWOLD/A2 = FTOA (AGE, '(D20.2)', HOWOLD); but it returns nothing. What am I doing wrong?

A2 is not big enough ... it works with A25

Here's an example using the CAR file ...

DEFINE FILE CAR
AGE/D20.2 = 35;
-*
HOWOLD/A2 = FTOA (AGE, '(D20.2)', HOWOLD);
HOWOLD1/A25 = FTOA (AGE, '(D20.2)', HOWOLD1);
-*
AGE_I2/I2 = AGE;
AGE_A2/A2 = EDIT(AGE_I2);
END
-*
TABLE FILE CAR
PRINT
AGE
HOWOLD
HOWOLD1
AGE_I2
AGE_A2
BY COUNTRY
END

A2 is too small an output format for FTOA to reformat D20.2 - it needs to be at least A25 to hold the numbers, commas, decimal point and two decimal places. Two easy alternatives:

1) Define a new column with D2 as format, then use FTOA
2) Define a new integer column

Just be sure that the newly defined columns can hold the maximum possible value of HOWOLD.

DEFINE FILE CAR
AGE/D20.2 WITH COUNTRY = 45;

NEWAGE/D2 = AGE;
AGE_INT/I2 = AGE;

HOWOLD/A25 = FTOA(AGE, '(D20.2)', HOWOLD);
HOWOLD2/A2 = FTOA(NEWAGE, '(D2)', HOWOLD2);
END

TABLE FILE CAR
PRINT
HOWOLD
HOWOLD2
AGE_INT

BY COUNTRY
END

This message has been edited. Last edited by: Francis Mariani,