[Info-vax] Streaming a File on OpenVMS with Caché

Jan-Erik Soderholm jan-erik.soderholm at telia.com
Fri Jan 16 07:25:07 EST 2015


abrsvc skrev den 2015-01-16 02:23:
>>
>> Well, yeah, lumping all transfers from many different trading
>> partners is a poor idea.  Anarchy comes to mind.
>>
>
> My take on the initial posting was that the file types/formats were
> different from different sources.  Having all of them dump into the same
> directory, makes it difficult to determine what to do with each file.
> Using multiple directories (one for each source and possibly file type)
> makes it easier.  The files in each directory should be the same type so
> processing them should also be easy.  The next directory the same.
> Collect all the "processed" files together in another and voila, you're
> done.
>
> While this would take a little bit to set up, it should clarify the
> process.
>
> Dan
>


Many years ago (in the 1995-96 timeframe) I was involved in a
similar problem where data files (plain text files with fixed
record format) was to be sent from many different sources that
had all kinds of plattforms, PCs, UNIX systems or mainframe type
of systems. Sometimes home built, sometimes commersial systems.

This was from different companies over "the net".

What we ended up with was a solution where the source created
the file as a plain text file in their envrionment. That file
was then ZIP'ed and mailed in three differnt ways:
- As s standard MIME attachement (mainly PC users)
- As a UU-encoded file (unix type of systems)
- As a MFTU encoded file (for those that was using VMS)

The mail was then sent to a fixed address that ended up in
our/my VMS system at the target environment.

My server then decoded the mail as it arrived depending in
the who was the sender (using UUdecode, MUNPACK or MFTU)
and then simply unzipped the file and processed it.

This has run "lights-out" more or less and still are after
close to 20 years. There is actualy right now a ongoing
discussion about what to do about it. HP had during the last
years concidered VMS as a "non-standard" OS and didn't realy
want to run it in their own computer center (HP are the
outsorcing partner).

Now, at the last meeting a couple of weeks ago, HP made a
180 deg turn and begun with a presentation of the agreement
with VSI and also had a number of sugestion for the continued
use of VMS. Upgrade of the currect DS20e to 8.4 or a switch
to Itanium, which HP tought would be "easy". The company
(TCS) to whom the application support is outsourced, on the
other hand thought that there would be a lot of code changes
to switch to Itanium. I (as the one who wrote all this
in the beginning) disagree with TCS on that point.
It is mainly DCL command files and a few utilities such
as ZIP/UNZIP that shouldn't be a problem.

There have been a number of projects the last 10-15 years
to try to find a replacement to this application, but
nothing that they was prepared to take the risk for.
So it still runs... :-)

Anwyay, what I ment to say, was that there is always a
solution for everything. In the particular case in this
thread there isn't realy enough information to be able
to give a complete solution. But from what has been
written, I'd look at a solution that FTP's ZIP'ed files
between the system. That is a reasoanle safe way to keep
file organisation intact. UNZIP also has some options
that can adjust CR/LF on the fly, if needed.

regards,
Jan-Erik.





More information about the Info-vax mailing list