How to represent value for the field S9(15)V99?

Hi Experts,

I am generating a feed file for downstream application where one of the data is of type S9(15)V99. The downstream application is Mainframe based. I need to understand how to represent 5000.00 in the type S9(15)V99?

Best Regards,

Prashant
pvashaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bill PrewCommented:
Okay, this should be doable, but there are a number of factors to be worked in.

First, you will need to understand if the mainframe application is expecting an ASCII file or an EBCDIC file.  Related to this is how will you transfer the file from whatever system you are generating it on, typically in ASCII, to the mainframe.  Some transfer products may do ASCII to EBCDIC translation but you will need to nail that down.  This will affect all fields in the file you send, including PIC X, and PIC 9.

For the PIC S9(15)V99, a few thoughts.  First, the V represents the implied decimal point location, so the length of the data field you send should be 15+2=17 characters.  No actual decimal character is sent.  And the sign is typically represented as part of the rightmost digit of the number.

For example if you wanted to send a positive 123.4 value, you would likely need to send a data field of "00000000000012340", without the quotes of course.  Notice no decimal character is sent, but it is implied in the digits passed.

This gets more tricky for sending negative numbers, which typically merge the negative sign into the rightmost digit.  So to send a negative 123.4, you would typically send "0000000000001234}".  Take a look at the two links below for some related information:

http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-4.html
http://www.3480-3590-data-conversion.com/article-signed-fields.html

I would recommend a good discussion with the vendor or developer that will own the loading of the data you are sending.  There have been some changes in the way mainframe COBOL files are imported and there is a chance it can handle additional formats of that numeric field, like there is a slim chance it could consume something like "-123.40" in that field, but only they can clarify that.

I'm going to stop typing for now and let you digest this, see if this is starting to answer your questions, and then wait for further thoughts and questions from your side.  Hopefully this gets you started a bit.

~bp
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tliottaCommented:
What do you mean by "represent"?

A "S9(15)V99" attribute is a 'picture' for a COBOL PICTURE clause. It's not a 'data type'. We need to know what the 'data type' is before having any chance of guessing how it might be "represented". Will it be character or numeric? (The picture can be used for either.) If character, is there an expected encoding? If numeric, will it be packed? Or zoned? (Or BCD?)

How is the value going to be sent? As a parameter for a remote call? Through a web service? Direct through a socket? In a file? What kind of file? (What is a "feed file" for you?) A text file? A streamfile? A .CSV? A mainframe save/restore file? DB2 unload/load? ODBC? There are so many ways to send data that it's hard to think of them all.

Tom
0
Bill PrewCommented:
I'm assuming based on the original post, that a file is being produced and will be read by the mainframe COBOL program.  I'm also assuming that the PIC S9(15)V99 is in the record layout for this file, so needs to be produced from the java program in a compatible format.

Yup, lots of assuming :-).

~bp
0
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

pvashaAuthor Commented:
Apologies for not being able to understand the complexity of the PICTURE CLAUSE... :)

We are generating a fix length ASCII file which will be transmitted to the downstream application. The file will be generated from a stand-alone java application.

From the interface definition, the data represents transaction amount so assume that the data type in the downstream application would be numeric. I have started discussions with the downstream application team for the same.

Please give me some more information on numeric data types when you mention whether they would be packed, zoned or BCD. I have no clue what it means.

Based on the above, will it be possible to say how would 5000 be represented in S9(15)V99 format in the ASCII file.

Best Regards,

Prashant
0
Bill PrewCommented:
If they are expecting an input data file downstream from another application it's unlikely that they are expecting COMP or COMP-3 fields in that data file (but not impossible), which are more complex and much harder to build in your java application.  For now I would not worry about those unless you hear otherwise from the mainframe contact.

I expect that they are expecting a USAGE DISPLAY field coming in, which typically would use a zone packed format for signed numbers.  That encodes the sign in the rightmost digit position, as mentioned in the second link I provided above.

In your fixed length file a 5000 would be represented by "00000000000500000" (without the quotes).  For positive numbers you don't have to explicitly indicate the sign, it's the default so the rightmost character can be a 0.

~bp
0
tliottaCommented:
We are generating a fix length ASCII file which will be transmitted to the downstream application.
That is what you are "generating". Is it also what is expected to be received?

The given PICTURE string is really meaningful only to a COBOL programmer. It should not be given to you nor to anyone else in a cross-platform application. It's almost a meaningless specification to give to a Java programmer. However, it could make more sense if the Java is being created as a replacement for an existing application and the previous specifications are still being used.

Technically. in EBCDIC encoding, a S9(15)V99 PICTURE clause in DISPLAY mode would hold positive value (5000.00) as "0000000000050000x" where the last character "x" would be hex byte 'C0'. Most likely, hex byte 'F0' would also be acceptable so that the "0" character could be substituted for the last character.

However, because the PICTURE clause specifies "S", it means it's a 'signed' value that may be either positive or negative. If the value was (-5000.00), then the transmitted value would be "0000000000050000x" where the last character "x" would be hex byte 'D0'.

In hex, the full string would be:

x'F0F0F0F0F0F0F0F0F0F0F0F5F0F0F0F0D0'

Again, that would be for EBCDIC encoding. For simple ASCII hex encodings of the positive and negative values:

x'3030303030303030303030353030303030'
x'303030303030303030303035303030307D'

The positive encoding assumes that x'30' would be acceptable in the last position. (I'd have to look deeper to see what the ASCII equivalent of EBCDIC x'C0' is for precise compliance, but it can probably be ignored.) Positive ASCII digits will simply be x'30' through x'39' for the least-significant byte.  But negative digits will be more difficult. I'd need to test each digit to see what the byte would contain.

ISTR, there are Java classes that can handle this kind of thing. I've never had to use them because I would never have Java try to mess with "S9(15)v99" values.

Tom
0
Bill PrewCommented:
You can see the ASCII equivalents for the sign digit at the link I shared earlier:

http://www.3480-3590-data-conversion.com/article-signed-fields.html

~bp
0
tliottaCommented:
@Bill -- Ah, good link. I should've checked it. I ran a test to output EBCDIC variables of the sample value to ASCII because I couldn't remember what "negative zero" was. Could've saved myself the time on that part.

Tom
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.