Skip to content

Packet

Jump to bottom
Calvin edited this page Apr 10, 2018 · 5 revisions

General packet info

AS/400 protocols in general, use structured packets and usually have field-addressable data, somewhat like RIFF.

Assume all data is unsigned and big-endian unless otherwise stated. When documents ask for "-1" they usually mean the maximimum value of an unsigned type.

Strings can vary wildly, either fixed-size EBCDIC padded with spaces, (0x40; which appears as @ in ASCII) big-endian UTF-16 values, or ASCII/UTF-8 strings.

Data can be stored as stored in the fields, or in the template area; I'm unsure why some things do one way, others do it the other way, and more others do a mix. I speculate it may have to do with these packets being formed by data from a 5250 form; with template data being unchangeable data for the command (which could then be memcpy'd into a struct?) and variable-length field data through a separate API?

In general, assume the protocol for services will be consistent with themselves, not others.

Header

This is 20 bytes.

  • Length: A 4-byte integer. This is the length of the packet in bytes, including this field.

  • Header ID: A 2-byte integer. This field's purpose is unknown to me.

  • Server ID: A 2-byte integer. This represents what service is beinmg talked to. Even though services have their own TCP/IP ports, they could be misaddressed, and signon requires a signon service exchange over the service's port.

  • CS instance: A 4-byte integer. This field's purpose is unknown to me.

  • Correlation ID: A 4-byte integer. This field marks "conversations" of packets to be identified.

  • Template length: A 2-byte integer. This is the amount of bytes until field-addressable data can be accessed. Information in the "teplate" area is generally accessed directly by offset, not with an "LLCP."

  • Request/Response ID: A 2-byte integer. This is the ID of the packet type for a service.

Fields

Fields start after the header plus the template length. They're addressed by "LLCPs" - a 6-byte header identifying chunks. To know where they are, you read the first LLCP and keep addressing based on the next LLCP at the end of the current one until you reach the end of the stream.

An LLCP consists of:

  • A 4-byte integer for length.

  • A 2-byte integer for field ID, or "code point."

Clone this wiki locally