W dniu 2013-12-04 16:16, Clark Morris pisze:
On 29 Nov 2013 14:02:35 -0800, in bit.listserv.ibm-main you wrote:
In <0378217484586824.wa.zatlas1yahoo....@listserv.ua.edu>, on
11/29/2013
at 11:47 AM, "Ze'ev Atlas" <zatl...@yahoo.com> said:
Again, you discuss the shortcoming of a specific system while I have
a broad view.
You're specific systems; I'm still trying to figure out what it is in
them that you want to change.
There would always be the need to disambiguate.
Then what behavior do you want to change? For normal use in Unix,
including z/OS, and for legacy z/OS data sets, the user just gives a
name and the system figures out where it is.
That's correct and that's where I took the idea from. That concept
needs improvements
No doubt, but so far you haven't identified any defect that a new type
of catalog would resolve.
Another great idea from the z/OS that deserve implementation in
that context (i.e. Central System Catalog) is the famous GDG.
Whenever I explain the concept to my Unix friends they agree that
such a brilliant idea should have been implemented in Unix as well.
They'd do better stealing the idea from DEC, specifically from VMS.
There is at least one shell that runs on HP-UX that implement a GDG
like facility with just a gnnnn instead of a g0000v00. What was the
VMS facility like?
1. VMS is not Unix and it's probably even more vanishing platform than z/OS.
2. In my not so humble opinion idea of GDG is simply uncompleted. While
I could understand memory constraints in 60's or 70's I cannot accept
lack of LIMIT(365) or more, to mention the most annoying drwaback.
3. IMHO the reason for GDG "uncompletness" is ...batch scheduler
existence. Most serious shops do use any of them and each batcg
scheduler offers more or less sophisticated features which are far more
flexible than GDG. It's not goo-voo, it is %%ODATE, with many possible
date calculations like "yesterday" or "last working day" or "last
working day in previous month", etc. etc.
My €0,02
--
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: kont...@mbank.pl
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.2013 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.555.904 zote.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
