Re: ccsid - is this correct from qsys.lib to IFS to remote storage and back -- MIDRANGE-L

Consider CCSID 65535? That means NO translation. The save file is getting messed up in the translations between file systems

I’ll bet the move to the external file system converts it to ASCII thereby destroying it.

What’s the motivation to doing this all in the first place? Simply putting the save file off system? Better to use a virtual tape since the LTO formats are far more well known.

There is an open source VTL library out there but I can’t find it at the moment.

Jim Oberholtzer
Agile Technology Architects

On Nov 13, 2024, at 7:59 AM, Vern Hamberg via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

I tried some of the steps you did. I got the same result using FTP, with CCSID 819. I looked at the contents of the IFS file, and nothing looked familiar, I've used another way to copy the SAVF with different results.

So then I tried what I usually - CPYTOSTMF - the first parameter, FROMMBR, even has this description - *From file member or save file*.

The resulting IFS file has CCSID 39. When I display it in WRKLNK, it has things that are familiar, that look like the content of a SAVF. For example, the following -
QSRDSSPC.1 û
L/D OBJECT DESCRIPTOR DISK

I wonder about using FTP - you have to use NAM 1 - no way to send to the IFS unless you do - and it has to BIN mode. All fine. But you have to use the special file extension .savf, not .file

I tried FTP again, using the .savf extension - it still showed 819 - so I displayed the contents again - opt 5 in WRKLNK - then inside there I took F15 and changed CCSID to 37 - it looked the same as if I used CPYTOSTMF - so I don't think the FTP method gives the wrong results, it just looks a bit odd to me. And using CPYTOSTMF is guaranteed to work, so far as I know, to copy the SAVF.

So that moves the vulnerable area to the transfer to storage - I recommend viewing the IFS file to see the bytes - you want exactly the same bytes in the copy in storage. When you pull it back to the i, compare it bytewise again, see if it's the same - it has to be, right?

I hope this helps!

Vern

On 11/13/2024 12:46 AM, Don Brown via MIDRANGE-L wrote:
Hi Vern,

I have retraced my steps and this is what I see specifically.

I have created a new save file.

If I use wrklnk '/qsys.lib/,,,,/savefile.file' option 8=Display
attributes shows ccsid of 37

I then used ftp in binary mode to put that save file to the IFS.

The file in the IFS shows ccsid 819

The IFS file is then sent to outside storage.

We reverse the steps

Retrieve the file from outside storage to the IFS

Used ftp in binary mode to transfer the file from IFS to qsys.lib file
system

dspsavf savefile fails.

I am just rerunning this test to make sure as we have made a couple of
changes.

Thanks

Don

From: "Vern Hamberg via MIDRANGE-L"<midrange-l@xxxxxxxxxxxxxxxxxx>
To:midrange-l@xxxxxxxxxxxxxxxxxx
Cc: "Vern Hamberg"<vhamberg@xxxxxxxxxxxxxxx>
Date: 13/11/2024 02:34 PM
Subject: Re: ccsid - is this correct from qsys.lib to IFS to remote
storage and back
Sent by: "MIDRANGE-L"<midrange-l-bounces@xxxxxxxxxxxxxxxxxx>

Hi Don

I've never used a different CCSID on a copy I've made of a SAVF.

Which CPY* commands are you using?

Beyond that, I've used only used FTP in BINary mode or simple Windows
copy to put IFS copies to a drive on my laptop. Does http put have a
option like ftp, for binary or ascii (text)?

Cheers
Vern

On 11/12/2024 9:12 PM, Don Brown via MIDRANGE-L wrote:
Hi All

I think I have a an issue with the following process but it is not

obvious

to me - perhaps someone will see the error or my ways.

I created a save file and the ccsid is 37

I save a library to the save file

I copy the save file to the IFS and assign ccsid 819 to the created

stream

file

I send the stream file to external storage. (http PUT)

Now I do the reverse

Retrieve the stream file from external storage back to the IFS and the
ccsid on the new file is 819 by default

I copy the file from the IFS to qsys.lib and to ccsid 37

But I can not restore the library.

Is there a problem in the above method I am doing that I am not seeing ?

Thanks

Don

--
This email has been scanned for computer viruses. Although MSD has taken

reasonable precautions to ensure no viruses are present in this email, MSD
cannot accept responsibility for any loss or damage arising from the use
of this email or attachments..

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.