• Copy files

    From Pieter Weerstand@21:1/5 to All on Thu Feb 27 02:05:45 2020
    Is it possible to copy files to a windows share? I found Paul Kimpel his PWB tools, and they are usefull for source files. But I cannot copy all kind of files, like containerfiles;
    We are moving to a software only MCP and I am looking for a solution to backup to a windows folder in stead of copying a whole ASD file.
    I do know there is Metalogic's Copywrite, but is there an other possibility?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Kimpel@21:1/5 to All on Thu Feb 27 12:07:39 2020
    -------- Original Message --------
    Subject: Copy files
    From: Pieter Weerstand <pieterweer@gmail.com>
    To:
    Date: Thu Feb 27 2020 02:05:45 GMT-0800 (Pacific Standard Time)

    Is it possible to copy files to a windows share? I found Paul Kimpel his PWB tools, and they are usefull for source files. But I cannot copy all kind of files, like containerfiles;
    We are moving to a software only MCP and I am looking for a solution to backup to a windows folder in stead of copying a whole ASD file.
    I do know there is Metalogic's Copywrite, but is there an other possibility?


    It is true that PWB/COPY will not copy files with
    FILEKIND=CONTAINERDATA, but that is only because such files do not have
    have a PWB ".*_m" file name extension, so the program currently ignores
    them. Wrapped container files are just byte streams, so any method that
    will copy binary byte streams can be used to copy container files.

    PWB/COPY does copy wrapped container files with FILEKIND=DATA (as .dat_m files). I'll add support for CONTAINERDATA to the utility.

    PWB/COPY is not the easiest or most efficient way to copy files from the
    MCP to a Windows share, however. There are a couple of other ways to do
    that.

    1. From Windows: if you can mount a share to the appropriate MCP
    directory, you can simply click-and-drag files from the MCP share to
    another shared directory. You can also use command-line tools such as
    xcopy. This approach allows copying of entire folders as well. Note that
    if you copy source files using this technique, the sequence and
    patchmark fields will be stripped and not transferred to the Windows share.

    2. From MCP: The SYSTEM/NXSERVICES/PCDRIVER utility can copy files in
    either direction between the MCP and a shared directory. It also has
    options to copy in either binary or text mode. When copying files to the
    MCP, it has a basic facility to specify record and block sizes. This
    utility is described in the System Software Utilities Operations
    Reference Manual.

    You can also write your own MCP programs to read and write stream files
    to directory shares. See the sections in the I/O Subsystem Programming
    Guide on Virtual Files, The Redirector, and STREAMIOH. Also see http://www.digm.com/UNITE/2007/ and http://www.digm.com/UNITE/2016/.

    3. From either end: Use FTP. Both the client and server components of
    MCP FTP have considerable support for converting between record and
    stream file organizations, binary vs. text files, blank trimming, record padding, supplying and stripping (or not) sequence and patchmark fields
    in source record formats, tab expansion, etc. It's all a bit complex to understand, but fairly easy to use once you get the hang of it. See the sections on FTP in the TCP/IP Distributed Systems Services Operations Guide.

    Whatever method you use, there will be restrictions on what kind of
    files you either can or should copy across a network. The primary
    example is object code files (most of the shared-directory utilities
    will not copy them) and files with mixed EBCDIC/binary/packed-decimal
    data. If you are trying to copy MCP files to a remote share so that you
    can potentially copy them back later (e.g., for backup), then using
    wrapped containers is your best bet. Recent releases of the MCP support optional compression and encryption of container files.

    I have supported systems without tape drives in the past, and have used
    wrapped container files and SYSTEM/NXSERVICES/PCDRIVER to back up MCP
    files to a Windows share. It is not all that difficult. See http://www.digm.com/UNITE/2011/#MCP4001
    for a discussion and some sample code.

    Another thing to watch for is MCP directory structures. In the MCP file
    system, the same path name (FILENAME, TITLE) can refer to both a file
    and a directory. Windows and *nix file systems don't understand that.
    When transferring directories of files from the MCP to a remote share
    where this type of naming overlap exists, the MCP will transfer files,
    but not sub-directories with the same name, because the remote system
    has no way of representing that directory structure. This is one of the
    primary reasons I wrote PWB/COPY.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Kimpel@21:1/5 to Paul Kimpel on Thu Feb 27 15:18:03 2020
    On 2/27/2020 12:07 PM, Paul Kimpel wrote:
    -------- Original MessageĀ  --------
    Subject: Copy files
    From: Pieter Weerstand <pieterweer@gmail.com>
    To:
    Date: Thu Feb 27 2020 02:05:45 GMT-0800 (Pacific Standard Time)

    Is it possible to copy files to a windows share? I found Paul Kimpel
    his PWB tools, and they are usefull for source files. But I cannot
    copy all kind of files, like containerfiles;
    We are moving to a software only MCP and I am looking for a solution
    to backup to a windows folder in stead of copying a whole ASD file.
    I do know there is Metalogic's Copywrite, but is there an other
    possibility?


    It is true that PWB/COPY will not copy files with
    FILEKIND=CONTAINERDATA, but that is only because such files do not have
    have a PWB ".*_m" file name extension, so the program currently ignores
    them. Wrapped container files are just byte streams, so any method that
    will copy binary byte streams can be used to copy container files.

    PWB/COPY does copy wrapped container files with FILEKIND=DATA (as .dat_m files). I'll add support for CONTAINERDATA to the utility.

    PWB/COPY is not the easiest or most efficient way to copy files from the
    MCP to a Windows share, however. There are a couple of other ways to do
    that.

    1. From Windows: if you can mount a share to the appropriate MCP
    directory, you can simply click-and-drag files from the MCP share to
    another shared directory. You can also use command-line tools such as
    xcopy. This approach allows copying of entire folders as well. Note that
    if you copy source files using this technique, the sequence and
    patchmark fields will be stripped and not transferred to the Windows share.

    2. From MCP: The SYSTEM/NXSERVICES/PCDRIVER utility can copy files in
    either direction between the MCP and a shared directory. It also has
    options to copy in either binary or text mode. When copying files to the
    MCP, it has a basic facility to specify record and block sizes. This
    utility is described in the System Software Utilities Operations
    Reference Manual.

    You can also write your own MCP programs to read and write stream files
    to directory shares. See the sections in the I/O Subsystem Programming
    Guide on Virtual Files, The Redirector, and STREAMIOH. Also see http://www.digm.com/UNITE/2007/ and http://www.digm.com/UNITE/2016/.

    3. From either end: Use FTP. Both the client and server components of
    MCP FTP have considerable support for converting between record and
    stream file organizations, binary vs. text files, blank trimming, record padding, supplying and stripping (or not) sequence and patchmark fields
    in source record formats, tab expansion, etc. It's all a bit complex to understand, but fairly easy to use once you get the hang of it. See the sections on FTP in the TCP/IP Distributed Systems Services Operations
    Guide.

    Whatever method you use, there will be restrictions on what kind of
    files you either can or should copy across a network. The primary
    example is object code files (most of the shared-directory utilities
    will not copy them) and files with mixed EBCDIC/binary/packed-decimal
    data. If you are trying to copy MCP files to a remote share so that you
    can potentially copy them back later (e.g., for backup), then using
    wrapped containers is your best bet. Recent releases of the MCP support optional compression and encryption of container files.

    I have supported systems without tape drives in the past, and have used wrapped container files and SYSTEM/NXSERVICES/PCDRIVER to back up MCP
    files to a Windows share. It is not all that difficult. See http://www.digm.com/UNITE/2011/#MCP4001
    for a discussion and some sample code.

    Another thing to watch for is MCP directory structures. In the MCP file system, the same path name (FILENAME, TITLE) can refer to both a file
    and a directory. Windows and *nix file systems don't understand that.
    When transferring directories of files from the MCP to a remote share
    where this type of naming overlap exists, the MCP will transfer files,
    but not sub-directories with the same name, because the remote system
    has no way of representing that directory structure. This is one of the primary reasons I wrote PWB/COPY.

    Paul

    PWB/COPY has been updated to copy FILEKIND=CONTAINERDATA and WRAPPEDDATA
    files as .con and .wrp names, respectively. In addition, I changed the
    way that the file name on the remote share is constructed so that if the
    MCP file is not a record-oriented file (e.g., it's a byte-stream file),
    the file on the share will not receive a PWB-style extension -- any "_m"
    will be stripped.

    The latest version can be downloaded from https://sourceforge.net/projects/mcppwbcopy/.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)