iSeries server and System/36 DDM differences

This topic consists of a list of differences between the iSeries™ server and System/36™.

The network resource directory (NRD) procedures are not supported on the iSeries server.
- The System/36 NRD used one or more libraries containing DDM files on the iSeries server. One System/36 NRD entry is equivalent to one DDM file on the iSeries server.
  - Use the Work with DDM Files (WRKDDMF) command in place of the EDITNRD and DELNRD procedures.
  - Use the Display DDM Files (DSPDDMF) command in place of the LISTNRD procedure.
  - Use the Restore Object (RSTOBJ) command in place of the RESTNRD procedure.
  - Use the Save Object (SAVOBJ) command in place of the SAVNRD procedure.
- If an NRD entry on the System/36 refers to a remote file, and a SAVE or RESTORE procedure is requested, the System/36 saves or restores the data of the remote file. The iSeries Save Object (SAVOBJ) or Restore Object (RSTOBJ) command saves or restores only the definition of the DDM file, not the remote data.
- When using date-differentiated files on the System/36, the most current file is selected. When running from a System/36 to an iSeries server, the NRD entry must specify a member name of *LAST to access the last member of the database file, which is the file with the most recent date. If no member name is specified, *FIRST is used.
The remote label in the NRD on a System/36 source must be in the syntax required by the target server.
The number of records allocated for a file differs between the System/36 and the iSeries server. File space allocation on the System/36 is in block units (2560 bytes) while on the iSeries server, file space allocation is by number of records. For example, if a user asks for a sequential file capable of storing ten 100-byte records, the System/36 allocates 1 block of file space (2560 bytes), and uses as much of the file space as possible (2500 bytes), giving the user twenty-five 100-byte records.
The iSeries server allocates exactly 10 records. If the user took advantage of this allocation method on the System/36, the file (nonextendable) created using DDM on the iSeries server might be too small.
The DDM Change End-of-File (CHGEOF) command used on the System/36 is not supported on the iSeries server.
The iSeries server does not support writing over data on the Delete File (DLTF) command. If an iSeries user accessing a System/36 wants to overwrite the data, an application program must be written on the iSeries server, or the user must access the target System/36 and perform the delete operation with the erase operation.
A System/36 source server cannot create direct files on an iSeries target server that are nondelete-capable. The iSeries server does not support files that are nondelete-capable for all file organizations.
The System/36 does not allow a record with hex FF in the first byte to be inserted into a delete-capable file. The iSeries server allows this.
When running System/36 applications to another System/36, the application waits indefinitely for the resource to become available. When running System/36 applications to or from an iSeries server, these applications might result in time-outs while waiting for a resource to become available.
Direct files are extendable on the System/36 but not on the iSeries server. If a direct file is created on the iSeries server as extendable, the file is allocated with three extents, but is never extended beyond the initial size plus three extents.
The System/36 relay function is not supported whenever one of the servers in the network along the path from the source server to the target server is not a System/36. The iSeries server never supports the relay function; Advanced Peer-to-Peer Networking (APPN) must be used.
Key fields on the System/36 are considered to be strictly character fields. The System/36 does not recognize a key field as being packed or zoned. Unexpected results might occur if source iSeries application programs refer to packed fields within a System/36 file. Because of the way packed numbers are stored and the fact that the System/36 does not recognize key fields as packed on relative keyed operations, records might be returned in a different order than expected or no record might be found when one is expected.
As an example, the ILE RPG SETLL statement might fail unexpectedly with record not found or might select a record other than the record expected when using packed fields to a System/36 file. Only character and unsigned numeric fields should be used as key fields.