Matt Flores

Greenhorn
+ Follow
since May 05, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Flores

Kalpesh Soni wrote:if args[0] is a String with value "0X11234D"

getBytes() will NOT build correct byte array



I am assuming you are trying it using ASCII character set. If you pass a string value of "< +" this will tranlate to x'28207C'

< = 0x28
blank = 0x20
+ = 0x7C
13 years ago
0x11234D is a representation only. what is passed is a 3 byte data x'11234D' run via jcl usng JZOS on the mainfraime. The representation is hexadecimal format. To evaluate the 3 byte data it is chr(17) - x'11' followed by chr(35)- x'23' then chr(78)- x'4D'. The problem is chr(0) which is the null character x'00' in both EBCDIC and ASCII. Strings are not able to handle this.

This is what the mainline code looks line. The characters may look different as the source in Unix System Sevices on Z/OS. Ý is [ and ¨ is ], the open and close square brackets shows differently.

public static void main(Stringݨ args) throws Exception {
byteݨ pd = argsÝ0¨.getBytes();
System.out.println(PackedDecimal.parse(pd));
}
} // end class


Part of the JCL
//JAVA EXEC PROC=JVMPRC60,
// ARGS=' *',
// JAVACLS='PackedDecimal'


the same JCL with HEX on to see the value of ARGS
//JAVA EXEC PROC=JVMPRC60,
66DCEC4CECC4DDDC7DEDDDCFF6444444444444
1111510575307963E15479360B000000000000
--------------------------------------
// ARGS=' *',
66444CDCE77013576444444444444444444444
110001972ED104CDB000000000000000000000
--------------------------------------
// JAVACLS='PackedDecimal'
66444DCECCDE77D88988C88898974444444444
110001151332ED7132544539413D0000000000

Looks funny because the font in this forum is proportional, if you are able to switch it to courier new it should line up.
The value being passed is x'0110345C'

The following is the proc that is being run

//JAVAJVM EXEC PGM=JVMLDM&VERSION,REGION=®SIZE,
// PARM='&LEPARM/&LOGLVL &JAVACLS &ARGS'
//STEPLIB DD DSN=&LIBRARY,DISP=SHR
//SYSPRINT DD SYSOUT=* < System stdout
//SYSOUT DD SYSOUT=* < System stderr
//STDOUT DD SYSOUT=* < Java System.out
//STDERR DD SYSOUT=* < Java System.err
//CEEDUMP DD SYSOUT=*
//ABNLIGNR DD DUMMY

this is similar to 'java PackedDecimal *' however, the argument being passed will very difficult to type. * in EBCIDIC is x'5C'.
13 years ago
what is happeing here is that the packed decimal is chopped in bytes and passed as an array. If I do not have a byte that is x'00' then the code works perfectly. If the packed decimal is 0x11234D

byte[] pd = args[0] .getBytes() will build a byte array = {0x11, 0x23, 0x4D} this will result in -11234
13 years ago
using Norms code above I modified the mainline;

public static void main(String[] args) throws Exception {
byte[] pd = args[0] .getBytes();
System.out.println(PackedDecimal.parse(pd));

let us say we call this java code passing 0x0100561C as the value of the argurment. Since args is defined as a string and the second byte has a value of 0x00 args[0] gets a value of 0x01, the rest is truncated.

If the first byte is 0x00 then args[0] is a null string.

thanks,
13 years ago
The code that Norm posted is great, however I ran into a snag, I was hoping to use this a function call to pass packed decimal data and return the decimal value. However when the passed argument has 0x00 bytes in the value the string argument is truncated from that point. Any one have ideas around this.

thanks,
13 years ago