× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I have attached a write up discussing some PTFs, and the enhancements
contained, below.  Buried in there is the ability for clients to pass
into the AS/400 a device name, and for that device name to then be
used on the open virtual terminal API.  One client using this is the
Network Terminal.  Other clients could do the same as they implement
the necessary interface to Telnet.  Client Access currently has not
implemented this level of Telnet interface though there seems to be
plenty of speculation on this midrange-list...

The TCP/IP Telnet extensions for this are based on RFC 1572 environment
option negotiation sequences (an optional part of the "normal" flow).

Bruce Vining

UPDATE: IP ADDRESS SUPPORT IN TELNET
------------------------------------

Telnet sessions can now support retrieval of the client IP
address via the QDCRDEVD System API.  Telnet will set the IP
address of the client into the virtual terminal device allocated
to the client, for retrieval by any AS/400 application.  Calling
the QDCRDEVD System API using the virtual terminal device name
allocated will return the IP address of the client to the
application.

This support for QDCRDEVD requires 4 Telnet PTF's for V3R2 and
V3R7, with subsequent releases having support in the base code.
All 4 PTF's for each release are required for this fix.

V3R2M0:
  5763TC1:  SF38885 - TELNET SUPPORT FOR THIN CLIENT (ACT TERMINAL)
  5763SS1:  SF38886 - TELNET SUPPORT FOR THIN CLIENT (ACT TERMINAL)
            SF38688 - OSP - NETWORK STATION SUPPORT
            SF38876 - OSP - NETWORK STATION SUPPORT FOR TELNET

V3R7M0:
  5716TC1:  SF38535 - TELNET SUPPORT FOR THIN CLIENT (ACT TERMINAL)
  5716SS1:  SF38536 - TELNET SUPPORT FOR THIN CLIENT (ACT TERMINAL)
            SF38357 - OSP - NETWORK STATION SUPPORT
            SF38565 - OSP - NETWORK STATION SUPPORT FOR TELNET

There are corresponding updates to the QDCRDEVD and QTVOPNVT
System API's to take advantage of this new support.  In
particular, updates have been made to accomodate new fields for
retrieval in the QDCRDEVD API, and new keys for input into the
QTVOPNVT API.

UPDATE: IP ADDRESS SUPPORT IN WSG
---------------------------------
WSG sessions can now support retrieval of the client IP address
via the QDCRDEVD System API.  WSG will set the IP address of the
client into the virtual terminal device allocated to the client,
for retrieval by any AS/400 application.  Calling the QDCRDEVD
System API using the virtual terminal device name allocated will
return the IP address of the client to the application.

This support requires 1 WSG PTF and 1 Telnet PTF for V4R1, with
subsequent releases having support in the base code.  In addition,
the Telnet PTF's listed above are also required.



V4R1M0:
  5769TC1:  SF43510 - TCPIP-WSG REDIRECT LOOPS ON INITIAL (INCORRECT) URL
  5769SS1:  SF41677 - TELNET WIRELESS SUPPORT

UPDATE: IP ADDRESS SUPPORT IN QDCRDEVD API
------------------------------------------

Retrieve Device Description (QDCRDEVD) API has been updated to
support additional fields for TELNET devices.  These additional
fields are added to record format DEVD0600.  These fields only
applies to display devices that are used by TELNET.  They are as
follows:

  * Network protocol

    The following defines the network protocol:
     - Internet Protocol (IP) value is hex 02.
     - Internetwork Packet Exchange (IPX) value is hex 06.

  * Network protocol address

    The network address is uniquely assigned to each system and is used
    in all communications with the system.

    The following format defines the network address based on the
    network protocol:

    - Internet Protocol (IP)
      CHAR(2)  TCP port number
      CHAR(4)  Internet address

    - Internetwork Packet Exchange (IPX)
      CHAR(4)  Network identifier
      CHAR(6)  Node identifier
      CHAR(2)  Socket number

   * Internet Protocol (IP) internet address in dotted decimal
     decimal form

     An internet address is a 32-bit address usually written as
     4 decimal numbers, each representing 8 bits of the address.
     An example internet address in dotted decimal form is
     128.12.28.43.

     Each system on the TCP/IP network is assigned a unique
     internet address that is used in all communications with
     the system.

     This field applies only to display devices that are used by
     TELNET and has a network protocol value of hex 02 which
     means Internet Protocol (IP).

  The field definition and offset are as follows:

  * Network protocol
     CHAR(1)    OFFSET - Decimal 858, Hexadecimal 35A

  * Network protocol address
     CHAR(18)   OFFSET - Decimal 859, Hexadecimal 35B

  * IP internet address in dotted decimal form
     CHAR(15)   OFFSET - Decimal 877, Hexadecimal 36D


UPDATE: IP ADDRESS SUPPORT IN QTVOPNVT API
------------------------------------------

The Key table will be enhanced as follows (new keys 6 & 7):

           *------+-----------+----------------------*
           | Key  |  Type     | Field                |
           *------+-----------+----------------------*
           |  6   |  CHAR(10) | Virtual Device Name  |
           *------+-----------+----------------------*
           |  7   |  CHAR(20) | Network Address      |
           *------+-----------+----------------------*

Virtual Device Name
-------------------
The specific virtual device to be associated with this TELNET
connection.

For *DSP devices, if the QAUTOVRT auto-create device system
value allows for it, the device will be auto-created by the
system if it does not already exist, and varied on.  For *PRT
devices, the device will be auto-created by the system if it
does not already exist.  If no value is supplied by the User
Exit program, the TELNET server will default to using the
traditional TELNET virtual device selection methods.

Should be a valid *VRT or *PRT device description name and must
adhere to standard OS/400 object naming conventions.

Network Address
---------------
The network address is uniquely assigned to each system and is
used in all communications with the system.  The following
format defines the network address based on the network
protocol:

  1. Size of Network Address

     CHAR(1) Number of bytes of Network Address actually used.
             All 20 bytes allocated for the Network Address
             may not actually be used.

  2. Family or Protocol

     CHAR(1) Indicates the family or protocol (IP or IPX)
             being used.  This value indicates whether
             3 or 4 below is used for the remainder of the
             Network Address.

             o Internet Protocol (IP) value is hex 02.
             o Internetwork Packet Exchange (IPX) value is hex 06.

  3. Internet Protocol (IP)

     CHAR(2) TCP port number
     CHAR(4) Internet address

  4. Internetwork Packet Exchange (IPX)

     CHAR(4) Network identifier
     CHAR(6) Node identifier
     CHAR(2) Socket number
>
> There is a form of naming devices in TCP/IP but it is currently
> only supported using Network Stations and the newer version of
> Network Station Manager for AS/400............
>
> I am not really sure how it is different from "normal" TCP/IP but it is
> an option in the NS manager.....
>
> Maybe one of the IBM folks could comment on this.....

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.