W dniu 2016-09-05 o 22:58, Paul Gilmartin pisze:
On 2016-09-05, at 14:01, R.S. wrote:
My €0.02: It would be good idea to enhance ftp protocol, to use something like
GIMFAF.XML file.
It is used by SMP/E Internet Delivery, every file or dataset is accompanied
with XML description stored in GIMFAF.XML file.
In such scenarion every file transfer from "structured world" (MVS, VM) to "flat
file world" (unix, windows) would give two files: the file itself and metadata. And of course
the metadata would be automatically applied during transfer the opposite direction.
It's pretty good. Opportunities for improvement:
o There's no all-embracing archive convention. Rather, the GIMPAF file
directs downloading individual archive files from a server. (Unless
RECEIVE ORDER improves on this).
Note: GIMPAF <> GIMFAF
o It's biased toward unloaded PDSes.
No, it isn't!
It can describe virtually all dataset types, including VSAM. Ok, maybe
excluding contructs requiring DataClass use.
o In fact, UNIX files are loaded into PDSes, then unloaded by IEBCOPY
RECEIVE reloads the PDSes, then APPLY copies members to UNIX directories.
Pretty roundabout. Are exended attributes kept in the GIMFAF metadata?
No, the metadata describes only the PDS RELFILE; metadata for individual
files must be yet elsewhere, perhaps in the SMPMCS.
(You can tell I've never worked with a UNIX product packaged for SMP/E)
Hmm... No. unix files are stored "natively", not in PDS members. Note: I
mean GIMFAF, not SMP/E conventions.
o SMP/E or at least GIMUNZIP is a prerequisite for receiving.
Currently yes, but it was rather generic idea to use metadata in
associated files, GIMFAF was just an example of the implementation.
How about going the other way: a "pax -z" archive containing simple UNIX
files (pax keeps metadata in more files) plus Classic data sets flattened
with AMATERSE or TRANSMIT.
I can't imagine it as a extension to FTP.
Regards
--
Radoslaw Skorupka
Lodz, Poland
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: [email protected]
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru
Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci
wpacony) wynosi 168.955.696 zotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
