Llamar al programa i-series desde Java produce resultados no válidos

Question

Estoy usando el kit de herramientas jtopen/jt400 para llamar programas en un IBM i-series r5v4 (también conocido como AS/400) desde Java (en realidad:JRuby, pero he visto el mismo problema en Java puro).Esto funciona bien para algunos programas, mientras que para otros programas, los bytes de salida contienen solo ceros, lo cual es incorrecto y, a veces, incluso no válido (por ejemplo, en el caso de ZonedDecimal).No hay mensajes adjuntos a ProgramCall, en JobList o en SYSOPR.MSGQ.¿Alguien sabe por qué pasa esto?

Para mostrar algo de código (estoy seguro de que cualquiera que haya trabajado con la biblioteca puede entender esta representación de Ruby de Java):

as400 = AS400.new(host, user, password)
call = ProgramCall.new(as400)
call.program = "/QSYS.LIB/LIBRARY_NAME.LIB/PROGRAM_NAME.PGM"

# Prepare converters
text1_converter = AS400Text.new(1)
text3_converter = AS400Text.new(3)
decimal92_converter = AS400ZonedDecimal.new(11, 2)

# Prepare parameters
call.parameter_list = []

# Input parameters
call.parameter_list << ProgramParameter.new(text1_converter.to_bytes('N'))
call.parameter_list << ProgramParameter.new(decimal92_converter.to_bytes(1500.25))

# Output parameters
call.parameter_list << ProgramParameter.new(text3_converter.byte_length)
call.parameter_list << ProgramParameter.new(decimal92_converter.byte_length)  

# Execute the call    
call.run

# Show the results
puts "Text3 output value: " + text3_converter.to_object(params[2].output_data).to_s
puts "Decimal92 output value: " + decimal92_converter.to_object(params[3].output_data).to_s

Como dije, esto funciona bien para algunos programas, mientras que para otros, params[2].output_data será una matriz de bytes de [0, 0, 0], que no es el resultado previsto.Peor aún, params[3].output_data será [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], que son valores de bytes no válidos para ZonedDecimal.new(9, 2).¿Puede alguien ayudarme?

Answer 1

resulta que tu debe establecer siempre un valor válido input_data en los parámetros de salida, incluso cuando los valores no se utilizan en ninguna parte.Si no lo hace, no se inicializarán y contendrán basura (pero a menudo las ubicaciones de la memoria contendrán ceros, como en mi caso).Si posteriormente el programa no establece explícitamente los valores de salida, lo que resultó ser el caso de mi elección de parámetros de entrada, entonces la máxima basura que entra es igual a basura que sale sostiene.

Por supuesto, la programación defensiva sugiere que el programador inicialice dichos valores o se asegure de que estén establecidos en cada ruta que se pueda tomar a través del código, lo que habría evitado que este problema ocurriera en primer lugar.Sin embargo, parece que el contrato establece siempre valores en los parámetros de salida, por lo que estaba usando incorrectamente la API.