I've got a file that I'm looking to load into a dataset and it's proving
to be a nuisance.

The file is created by Unix-based processes and uses X'25' as a record-delimiter. It's supposed to wind up as a collection of
160-character records, space-padded as needed.

Starting with clicking the 'Unix File' box on I've tried just about every combination and permutation of setting, variations, options and flavors
the TSO File tab allows: fixed length, VB, Undefined, None and lengths of
160, 161 and 162 but nothing works; the output winds up as:

FIRST-SHORT-REC(X'25')SECONDREC DATA HERE AS FAR AS IT GOES(X'25')THIRD
REC HERE FOR SOME MORE(X'25)FOURTH RECORD AT THIS POINT (&c)

That kind of 'striping' of records usually happens when the output LRECL
and the input don't match (and that kind of fits in with X'25' delimiters instead of X'0D0A'.

Is there a setting I'm missing... or is there a quick-and-dirty PC-based utility that will get it from variable-length tab-delimited format to
LRECL 160 with space-padding?

Thanks much.

DD

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

On Thu, 2 Sep 2021 14:47:26 -0000 (UTC), [email protected] () declaimed
the following:

Starting with clicking the 'Unix File' box on I've tried just about every >combination and permutation of setting, variations, options and flavors
the TSO File tab allows: fixed length, VB, Undefined, None and lengths of >160, 161 and 162 but nothing works; the output winds up as:

FIRST-SHORT-REC(X'25')SECONDREC DATA HERE AS FAR AS IT GOES(X'25')THIRD
REC HERE FOR SOME MORE(X'25)FOURTH RECORD AT THIS POINT (&c)

That kind of 'striping' of records usually happens when the output LRECL
and the input don't match (and that kind of fits in with X'25' delimiters >instead of X'0D0A'.

x'25' is an ASCII % sign; I'm surprised it isn't being displayed as such. It IS a line feed in EBCDIC. https://www.ibm.com/docs/en/xl-fortran-aix/16.1.0?topic=appendix-ascii-ebcdic-character-sets

Decimal '25', x'19', is "end of medium" for ASCII AND EBCDIC

Note: x'0D0A' is Windows line ending... UNIX/Linux line ending is just x'0A' -- ASCII line feed (original Macintosh and TRS-80 used x'0D' for
line ending -- carriage return in ASCII and EBCDIC).

You example results also don't seem to show any spacing which would represent tab characters...

Is there a setting I'm missing... or is there a quick-and-dirty PC-based >utility that will get it from variable-length tab-delimited format to
LRECL 160 with space-padding?

So far your description doesn't fit any format I'm familiar with. I'd maybe need to see a hex-dump (on the source machine) to see what is really
in the file, since your import attempts may be translating some characters
(for example, converting ASCII x'0A' [Linux line ending standard] into
EBCDIC x'25', but with the lack of ASCII x'0D' is not treating that as a line-ending).

If the source file really is Linux x'0A' -- there should be some utility that can change the line ending to x'0D0A' for Windows standard. (unix2dos being one such, though for one file you could likely even use a
text editor -- VI(M), say -- and do a global find/replace looking for the linefeed (<ctrl-j>; ^J) and replace with carriage return/linefeed (<ctrl-m><ctrl-j>; ^M^J).

Any further processing might need one to write a script on the source OS (I'd suggest Python, using one of the dialects of the "csv" module to
parse the input, and an output statement using fixed width formatting codes
-- you'll have to figure out what widths each field requires).


--
Wulfraed Dennis Lee Bieber AF6VN
[email protected] http://wlfraed.microdiversity.freeddns.org/

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

In article <[email protected]>,
Dennis Lee Bieber <[email protected]> wrote:

On Thu, 2 Sep 2021 14:47:26 -0000 (UTC), [email protected] () declaimed
the following:

Starting with clicking the 'Unix File' box on I've tried just about every >>combination and permutation of setting, variations, options and flavors
the TSO File tab allows: fixed length, VB, Undefined, None and lengths of >>160, 161 and 162 but nothing works; the output winds up as:

FIRST-SHORT-REC(X'25')SECONDREC DATA HERE AS FAR AS IT GOES(X'25')THIRD
REC HERE FOR SOME MORE(X'25)FOURTH RECORD AT THIS POINT (&c)

[snip]

Any further processing might need one to write a script on the source
OS (I'd suggest Python, using one of the dialects of the "csv" module to >parse the input, and an output statement using fixed width formatting codes >-- you'll have to figure out what widths each field requires).

Greatly appreciated, Mr Bieber, but I had to move too quickly to solve it
fast so I had to solve it slowly:

Open the file in Wordpad, save it into a new copy.

Tell IND$FILE that the new file is ASCII CRLF and it loads like a champ.

Thanks much!

DD

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