[Info-vax] Rethinking DECNET ?

Jan-Erik Soderholm jan-erik.soderholm at telia.com
Tue Sep 2 16:32:44 EDT 2014


Dirk Munk wrote 2014-09-02 20:33:
> Jan-Erik Soderholm wrote:
>> Dirk Munk wrote 2014-09-02 09:52:
>>> JF Mezei wrote:
>>>> On 14-09-01 19:41, Dirk Munk wrote:
>>>>
>>>>> decades ago. You can still use Decnet 4 if you like, but JF is now
>>>>> asking to overhaul Decnet 4 to use it over IP (IPv4 and IPv6?).
>>>>> Decnet 5
>>>>> can be used over IPv4 and IPv6,
>>>>
>>>> I don't care about decnet protocol itself, whether 4 or 5. I care about
>>>> the integration of decnet within the operating system/file system.
>>>>
>>>> aka: everywhere you can have node::  (at DCL, application etc).
>>>>
>>>> I mention DECNET 4 because it has NCP which defines network objects,
>>>> and AUTHORIZE has the proxy database.
>>>>
>>>> So if there were a way to port various network objects such as FAL to
>>>> become native on IP instead of DECNET, it would allow one to continue to
>>>> support the same functionality provided by the node:: in many places
>>>> used by the user, without needing an actual DECNET network stack since
>>>> the objects would be native to IP.
>>>
>>> I get your point JF, but what your are describing here is not Decnet over
>>> IP but adding functionality to the IP stack. FAL functionality would
>>> get a
>>> separate IP port number. But Decnet FAL will also do file conversions if
>>> necessary. That is because it was designed for operating systems that
>>> know
>>> file types, various types of sequential files, relative files, indexed
>>> and
>>> so on. Unix doesn't have that, a Unix file is just a load of bytes. Unix
>>> and IP are far more primitive in that respect. FTP for instance will do a
>>> 'file conversion' with ascii files. If you use ascii FTP to copy a file
>>> from Windows to Unix, the <cr><lf> end-of-record terminators will be
>>> replaced by <lf>, but that is about it. You will have to tell FTP that it
>>> is an ascii file if the file type is unknown (not .txt for instance).
>>>
>>
>> But that is a Unix "limitation", not with FTP as such.
>>
>> At a formar customer, we FTP files to a IBM mainframe (MVS) from
>> VMS and we specifed all specific storage parameters (LREC, BLOCK
>> size, whatever their names was) within the FTP session using QUOTE
>> commands.
>>
>> Jan-Erik.
>
> And it is also possible to add FDL scripts etc. That's nice, and it is a
> fine workaround, but is it still 'standard' FTP that can be understood by
> any FTP client? I don't think so.

This has nothing at all to do with the client!

The only thing the client need, is to have a QUOTE command.
There is nothing the client needs to "understand" apart from
sending the QUOTE commands to the FTP *server* at the MVS side.

And yes, this is plain standard FTP.

Found a message from 2006 where I described this:

--------------------------------------------------------------
Since I needed to execute a suit of FTP commands
I found it easier to create a tempfile on the fly like :

$ ftp <mvs-host> /user=<user> /pass=<pass>
quote "site lrecl=nnn"
quote "site blocksize=nnnn"
quote "site recfm=fb"
put <local-file> <remote-dataset>
quote "site filetype=jes"
put <jcl-file>
quit
$ exit

This script transfers a file into a MVS "dataset"
and submits a batch job to process it.
--------------------------------------------------------------

Regards,
Jan-Erik.






More information about the Info-vax mailing list