On 05-Nov-2015 09:32 -0600, David Gibbs wrote:
On 11/4/2015 10:39 AM, Vernon Hamberg wrote:
SAVFs have some signature stuff at the head - of course, they are
in EBCDIC - but there should be some commonality amongst them - I
look at them in Textpad in hex format sometimes.
I looked at 4 of them and find at position x1085 this string -
QSRDSSPC <<SNIP>>
<<SNIP>> I used the information on the linux file command.
The 'magic' database that the file command uses also indicates that
the QSRDSSPC is prefixed by 0x19 and 0xDB.
The text\token QSRDSSPC instead may be _eventually followed_ [rather
than immediately preceded] by those two successive bytes; e.g. appearing
at ofs x/10A2, when the QSRDSSPC token first appears _prior_, at ofs x/1084.
Conspicuously, those two bytes are the hex _Internal Object Type_ of
the Save\Restore DeScriptor Space (*SRDS). An object name is an index
entry with a two-byte object type followed by a thirty-byte name. From
the aforementioned example, the full 32 bytes from ofs x/1084 describes
the 30-byte name, followed by the 1-byte object type [Space 0x19] and
1-byte object subtype [descriptor 0xDB]; those occurrences reverse the
locations. Other occurrences would show as described by 'magic', with
the x/19DB preceding the token, as the object type followed by the token
QSRDSSPC which is the first 8-bytes of the object name chosen for the
descriptor.
[
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apiref/conObject.htm]
_Internal object types_
"Internal objects are used to store the information needed to perform
some system functions. The table shows the predefined values for all the
IBM® i internal object types.
Table 1. Predefined values and default library locations for internal
IBM i object types
________ __________________________________ _____________
| Value | Object type | Hexadecimal |
|________|__________________________________|_____________|
...
| *SRDS | Save/restore descriptor space | 19DB |
...
|________|__________________________________|_____________|
I wasn't 100% sure that the offset of the prefix and QSRDSSPC
text was static, so I just loaded the first 16k of the file and
search for that sequence. For my purposes, this is sufficient.
Probably a safe bet the data originated from a [Dump Space of a] Save
File utilized to SAVxxx some data. Of course other binary data could
have the same information, yet not be in the format of a Save File,
while still being in a valid IBM i Save format; e.g. a tape image or
/optical/ image.
midrange.com
