> I like REXX a lot and I find it to be very adept at parsing information,
I'm a REXX bigot, but when it comes to parsing there are better languages, e.g., Icon, Perl. It would be nice if TSO/E would pick up PCRE and RexxLA would upgrade the RegularExpression class to equivalent functionality for OOREXX. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Dave Clark [[email protected]] Sent: Monday, February 21, 2022 9:48 AM To: [email protected] Subject: Re: Interpreting Explicit Decimal Numbers Well, I just found out there is a 250-line limit for this list service. So, I had to shorten my response... "IBM Mainframe Assembler List" <[email protected]> wrote on 02/18/2022 08:05:07 PM: > I'm not clear on what you mean by "precision" and "scale" when you > say: > > "transform a zoned-decimal number with up to 31 digits of precision > and up to 15 digits for scale with an external sign and an explicit > decimal point into a packed number that is properly aligned." I used the terms in the SQL sense. I understand how that might have been confusing since there is no SQL related to what I am developing. However, in my documentation of this process I did not use those terms. Rather, I used the definition of those terms, which is: "Precision is the number of digits in a number. Scale is the number of digits to the right of the decimal point in a number. For example, the number 123.45 has a precision of 5 and a scale of 2." > I also don't understand where (or how) implied decimal points are > specified in your conversion and representation scheme. The caller creates a data definition for each file field and my routine retrieves that information directly from the original REXX variables created by the caller. That data definition has the following format. ...snip... * On input, the following stem variable elements are used: * ...snip... * ..._fld.0 value specifies the number of contiguous fields that * * make up a full record for this file; * * ..._fld.n where n is from 1 to the value of _fld.0 and * * specifies one or more field definitions that make * * up a full record for this file; where the value is: * * word1 is the actual name of this record field * * (assembler conventions up to 32 chars), * * word2 is data type of the field in the record, * * word3 is the record zero-offset of this field, * * word4 is the byte length of this record field, * * word5 is the number of decimal digits (up to 15) * * for 'PACKED' or 'ZONED' fields (must be * * zero for 'BINARY' and 'LZONED' fields); * * ..._fld.fld_name * * contains the character or decimal value for the * * associated record field (where "fld_name" is one of * * those found in word1 of the _fld.n definitions * * given and values are automatically converted by * * this function before storing in the file and before * * storing in the associated stem variables -- such * * that the caller only has to deal with them in * * character and decimal formats, as appropriate). * ...snip... > For what it's worth, why don't you do all (or the majority) of your > decimal string validation and manipulation stuff in Rexx? You're > already writing Rexx code and doing this in Rexx itself is way > easier and, overall, more robust. I like REXX a lot and I find it to be very adept at parsing information, but I don't find it to be that adept at conversions -- particularly packed-decimal conversions. Further, REXX's lack of support for handling file record layouts on behalf of the REXX programmer is totallly lacking. These are the two major reasons I wanted to create this REXX fucntion in the first place. I mentioned that z/VSE REXX has the VSAMIO function but this function provides neither of the above two requirements. I find REXX coding to be quite tedious to have to break down, convert to REXX format, then reconvert to (let's say) COBOL format and rebuild key and record formats myself in order to use the VSAMIO function. So, my routine will be more like using COBOL to read and write VSAM records -- where COBOL supports a copybook for the record layout and field data definitions. The following is an example of a copybook layout intended for use with my REXX function. ...omitted due to list requirements... Now, that file layout isn't particularly exciting, because it has no BINARY or PACKED fields. But you get the idea. My REXX function will automatically pass back, as additional stem variable entries, the parsed data fields given and convert them to REXX format as needed. It will also automatically do the reverse when (re)writing VAM records. Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 ********************************************************************************************* This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *********************************************************************************************
