IBM i and System/36 DDM differences

This topic consists of a list of differences between the IBM® i and System/36.

  • The network resource directory (NRD) procedures are not supported on the IBM i.
    • The System/36 NRD used one or more libraries containing DDM files on the IBM i. One System/36 NRD entry is equivalent to one DDM file on the IBM i.
      • 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 IBM i 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 IBM i, 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 server system.
  • The number of records allocated for a file differs between the System/36 and the IBM i. File space allocation on the System/36 is in block units (2560 bytes) while on the IBM i, 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 IBM i 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 IBM i might be too small.

  • The DDM Change End-of-File (CHGEOF) command used on the System/36 is not supported on the IBM i.
  • The IBM i does not support writing over data on the Delete File (DLTF) command. If an IBM i user accessing a System/36 wants to overwrite the data, an application program must be written on the IBM i, or the user must access the target System/36 and perform the delete operation with the erase operation.
  • A System/36 client system cannot create direct files on an IBM i target server that are nondelete-capable. The IBM i 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 IBM i 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 IBM i, 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 IBM i. If a direct file is created on the IBM i 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 client system to the server system is not a System/36. The IBM i 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 IBM i 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.