corrupted reports from ASCII

[Vlad_11]

Hi,
We're moving from Linux into HP box, and while sending email attachments from new box most well formatted reports got corrupted: lines shifted.
There is command in that shell on HP, analog of used on Linux. originally data is in ASCII format from MVS. I also can see hex'00' on that reports.
Anybody can suggest how to use to make it right?

Thanks to all
Vlad

[Steven E. Protter]

the ux2dos command is used to handle binary/ascii conversion issues.

I think you need a sendmail attachment script.

I'm away from the office or would attach you one. I have posted one numerous times to sendmail releated itrc threads if you are willing to do some itrc digging.

SEP

[Vlad_11]

Thanks, Steven
I think I'm familiar with your script.
I think I can't use it, my shell run in batch scheduled by cron. And it works fine unless it breaks lines.



Vlad

[Peter Godron · Accepted solution]

Vlad,
MVS works in EBCIDIC format not ascii.

Please correct if incorrect:
Currently you transferring data from MVS to Linux and then sending email with data attached.
The New system will get the data from MVS to HPUX and then send email with data attachment

Is the data changed from EBCIDIC to ASCII before transfer or after (under Linux or HP). Is the transfer binary?

Regards

[Vlad_11]

Hi, Peter
We FTP data from MVS to Unix running job on MVS with no options , so I assume it's not binary.

[Vlad_11]

Sorry Peter, push button earlier than wanted:
We:

.. transferring data from MVS to Linux and then sending email with data attached using .

The New system will get the data from MVS to HPUX and then send email with data attachment
using

Is the data changed from EBCIDIC to ASCII before transfer or after (under Linux or HP). Is the transfer binary? No, I think low-values caused file to shrink.

Vlad

[Peter Godron]

Vlad,
from what I remember working on MVS, MVS can handle EBCIDIC and ASCII transfers, so I would suggest converting the file on MVS to ASCII, checking format,transfer to HPUX, check format, and then use elm to send attachment.
Regards

[Dave La Mar]

Vlad -
Check your ftp job from MVS. If the mode is ascii, then, as others mentioned you simply need the appropriate mail attachment syntax from unix.
We commonly ftp from the mainframe to unix and it is seldom done in binary mode. We encounter no EBCDIC conversion problems, with the execption of one application on unix that requires some data file character conversions prior to processing. I don't believe your issue to be similar to that.
I am attaching a file with a number of ways to mail out from unix.
Regards,

dl

[Vlad_11]

Thanks, Dave and Peter !

Can you guide me how to check format of file on Unix/Linux. sorry that I'm missing some basics, now I know that problem is low-values Hex'00' on MVS, if I edit those file replacing low-values with spaces everything is OK.
I'm limitied of using email with the folowing line in existing shell:
cat body bodyl > temp3
mutt -s " $FSUB $SUBJECT" -a $ATTFILE -c $MAILTO < temp3

I tried to use all options with command to play with $ATTFILE but nothing worked if it had low-values.


Thanks
Vlad

[Dave La Mar]

Vlad -
Have tried the uuencode with the ux2dos command?
As far as using mutt goes, we use mailx almost exclusively here, thus I cannot help you with that syntax.
On another note, if you can translate the x'00' characters manually, you can add that step prior to your mailing.

Regards,

dl

[Vlad_11]

Thanks, Dave

Right now I've solved this making option on ftp step that runs on MVS.
Though will try to play with unix2dos.

You meant to something like:
% tr [low-values] [spaces] < $MYFILE ???


Vlad

[Bill Hassell]

Very important: ux2dos and dos2ux does NOT convert binary to/from ASCII. It is used to format *ASCII* files that are sent or received between HP-UX and PCs. An ASCII file in Unix is a string of characters followed by a line-feed (LF) which is the Unix text termimnator. However, in PC-land, the line terminator is carriage-return (CR) and LF. And the end of an ASCII file in Unix is the null character (0x00). If you take a native Unix file and send it to a terminal without special processing, the text will stairstep down the page.

Conversely, a UNIX file opened with Notepad on a PC will have black squares for each LF because Notepad expects a CR/LF pair. ux2dos adds a CR to every LF, and dos2ux takes away the CR from every CR/LF pair. That's all.

And this is exactly what ftp does with the ASCII option. Regardless of what type of a file you transfer, every CR/LF pair will be converted to LF and in the other direction, every LF character will have a CR added. That's why binary files get corrupted with the ASCII option in ftp. Always use the binary option

[Dave La Mar]

Vlad -
Just a clarification here. a hex'00' is an EBCIDIC null. If the file from MVS is a binary file, then by all means a binary transfer is in order. If it is simply an EBCIDIC file then ascii mode is likely in order.
Now that may differ in some environments, i.e. Bill's comments.
Suffice it to say, in our environment, we often ftp VSAM files and SD files to HP-UX as well as get files from unix, and ascii is the most used mode. Our mainframe IBM VM/VSE.

Best of luck on your resolution, but I think you are home free.

Regards,

dl
BTW - No points please for this post.

[Bill Hassell]

And just a note about ftp. It is the most universal method to transfer text files between different operating systems. The ASCII mode in ftp does not do any translation. Instead, both ends agree to transfer the data with a unique protocol that uses an ftp notation for records. The source file is read as inidvidual records using the source OS standard libraries, then records are sent in an ftp-neutral mode to the destination. At the destination, fpt will create the records by writing records through the destination OS libraries.

In other words, the records are accessed through the respective OS mechanisms. Thus, any type of file layout is acceptable on either end because only text records are actually transmitted. Contrast this with ftp's BINARY mode which is more like a dd copy. Most of the source file layout codes are sent over. Mainframe OS text files have numerous formats (fixed length, variable length, etc) but ftp works well for ASCII transfers.

For EBCDIC files, you still use ASCII mode (which really means: text files) and then run the result through dd and choose the EBCDIC conversion option.