| Title: | DEC/EDI |
| Notice: | DEC/EDI V2.1 - see note 2002 |
| Moderator: | METSYS::BABER |
| Created: | Wed Jun 06 1990 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3150 |
| Total number of notes: | 13466 |
This note is similar to 2761. The customer has just migrated from vms to Digital unix, and he needs a way of preserving his VMS audit data for legal purposes => Turn VMS off, turn unix on. It was mentioned in note 2761 that "Technically, it is not impossible ..." This issue is of great importance to the customer and a solution needs to be for him. What we need, I guess, is some kind of rmu/unload on the vax followed by the informix equivalent of rmu/load on the informix db (easier said than done). Has any (will there) progress been made in this area ? regards, Andrew
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2994.1 | problem is not Digital's | IJSAPL::DEWIJK | GJ from the Dutchlands | Tue Feb 04 1997 14:35 | 9 |
interesting question as well:
what would be required if a customers changes not only the platform but
also the EDI-solution. move from product 'abc' to 'xyz'
would they also require some kind of compatability in these cases?
I see this as a general problem/requirement
Is there anything done in the EDI workgroups about this?
GJ
| |||||
| 2994.2 | Needs a feasability study | METSYS::HELLIAR | http://samedi.reo.dec.com/ | Tue Feb 04 1997 16:31 | 32 |
Andrew,
To transfer between vendors you should investigate flat table unloading
and loading from the various vendors. It is my belief that Rdb now
supports dumping of a table into a a flat file (either fixed length, or
delimiter separated), and that other database vendors could load this
data into their database.
However, watch out as the audit trails of the two products are not
exactly the same (e.g. TLF USRREF_S has different sizes ).
Also, the status's held in the VMS database are VMS Condition Codes,
and will probably be different to the status values on Digital Unix,
so these wowuld also have to be converted.
The audit trail, also refers to objects in the store directories, and
in these are different between the two platforms (DECEDI$STORE_1 versus
/var/adm/decedi/store_1), and obviously the actual VMS files are VMS
RMS files which if copied to Digital Unix would show their record
control characters unless converted (which the customer might not like
if its for 'legal' purposes).
And of course, unless the user is a very low volume EDI user, the VMS
products archived information will be in VMS save-sets which Digital
Unix will not understand and may be on a media that isnt supported by
the Alpha boxes (or not by default e.g. TK50's).
So, bottom line is anything is possible, AT A PRICE. The most risk is
what changes to the data we would be allowed to do without compromising
the 'legal audit' status. The biggest technical challenge would be
dealing with a VMS save-set.
Graham
| |||||
| 2994.3 | A starting point on the save-sets | METSYS::HELLIAR | http://samedi.reo.dec.com/ | Tue Feb 04 1997 16:48 | 2 |
Digital Unix Conference note 5289 suggests at least two possible
solutions to Unix reading VMS save sets
| |||||
| 2994.4 | a different approach | ABBEDI::GRIFFITHS | Wed Feb 05 1997 13:18 | 21 | |
There is another way of approaching the problem.
Rather concentrate on getting the data from the VAX and trying to load
it into the unix informix database (and also transfer the transmission
files from the store vax storage areas to unix /store1_ etc) ...
another way could
be to use a reporting tool (such as FOCUS) to unload the VAX Rdb data
into extract files; copy these files to the unix environment;
then use the reporting tool to query these extract files to satisfy
legal requirements. My understanding is that the data somehow needs
to be available for legal purposes (e.g to satisfy queries from
previous transmissions).
I mention FOCUS as a tool because I have used it for such purposes -
and it also supports different file types from different vendors
(ISAM on the IBM for example - as well as Digital's RDB product).
Andrew
| |||||