This may be a little bit off topic, but ...
some years ago my customer asked me to do a similar project;
they had (and still have) a home grown software development tool, based
on ISPF services,
written in PL/1 and REXX, which used CA-LIBRARIAN as archiving system.
It supported all the
development stages, including installation into the target libraries
etc.; the users were satisfied.
Management too, but the only problem was that they wanted to get rid of
CA-LIBRARIAN,
because of maintenance cost and end of support (?).
The site had a strong DB2 knowledge and experience, so I suggested to
replace CA-LIBRARIAN
by two (!) DB2 tables; one holding the meta data of the objects (sources
and includes, different
languages) and one holding the sources as CLOBs. All historic stages of
the sources are recorded,
back to 1995. The source CLOBs have two time stamps, the time of
creation and the expiration time
(which is 2999-12-31 for the actual source). The CLOBs are limited to 5
MB, which makes 62500 lines;
I suggested to allow more than one CLOB per source, so that the size
could be unlimited,
but the customer didn't want that.
The two tables exist three times (test, system test, production).
Some numbers from the projects:
- 70000 sources and includes (including history stages) have been
migrated in two hours
during an afternoon shift, only two hours downtime of the system
- no change in the "look and feel" of the application. the users
(developers) don't see any difference
- fetching of a source clob of 20000 lines into a 80 byte record member
needs sub-second response time
(this is done by a C sub program, BTW ... the original program which
fetched the source from CA-LIB was
changed to call the C sub program instead of a LIBFAIR function)
- all generated compile jobs etc. were changed to fetch the sources from
DB2
- the includes, when changed, are written to DB2 and to shadow
(read-only) PDS libraries for use by the compilers
- the project was done by 5 people (in fact by two, three only
consulting) in 4 months
- some improvements, for example: there were no histories in system test
before the migration to DB2,
and: the overall size of all histories for certain (large) sources was
limited with CA-LIBRARIAN, so that
for certain sources only a small number of histories could be recorded.
This problem doesn't exist any
more with DB2
When the project was finished, the CA-LIBRARIAN license was cancelled;
the amount saved (per year)
was more than enough to fund the migration effort ... at least that's
what I was told.
A success story ... and great fun :-)
Kind regards
Bernd
Am 27.02.2020 um 16:19 schrieb Steve Thompson:
I am reading the Using Data Sets manual for z/OS 2.2 (DFSMS stuff).
Has anyone attempted to use the version feature of PDSE?
I'd love to hear about your experiences before I even think about
suggesting this for a current client of mine.
What they want is a replacement of a librarian product (not
necessarily Librarian) using PDSEs.
From what I read right now, this concept is a nightmare (within PDSEs).
You will need to specify which generation you are after, but that
means you have to know which generation the source you need was saved
(archived) in.
Per the book, as I have read so far, and "understand" at this point,
you would have to do this:
A.B.C.GnnnnVnn(member) in order to access the "archived" member.
So I am very interested in what anyone has done and/or experienced in
this area.
Regards,
Steve Thompson
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
