× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 9/5/2013 3:19 PM, Stone, Joel wrote:
True there are workarounds if enough time and money is poured into each app. Problem is that most of our organizations have 30 years of custom apps that cannot be retrofitted with a new "environment" selection system.

Every other OS allows a multi-level hierarchy.

Respectfully, you aren't working on every other OS.

For example if I have the following libraries for the corresponding app:
-snip-
Now I want to create a test version of each app, so I add a prefix to each lib:
-snip-
Oops went over 10 characters, have to start scrunching names to fit and change pgms and liblists.

Wouldn't it be a lot easier (like in every other OS except OS400) to simply move the libs into another [higher-up] folder named TestFolder and ProdFolder?

Yes, it might be easier. A lot easier? Hard to say. How well will a
30 year old custom app adapt to a hierarchical file system?

Instead we buy more boxes and create lpars and FTP files back and forth and get mimix - sometimes (but agreed not everytime) due to the single level library structure.

Let's get the red herrings out of the way.

FTPing files back and forth would happen hierarchical file system or
not. If not FTP, then some other mechanism to copy from Here and place
over There.

Mimix isn't - can't? - be used for test/dev/prod. Who would want
production data stepping all over the test database?

Now to the meat of the question.

I've worked with midrange and mainframes since 1978 and never used a
hierarchical file system. Is it a limitation? Yes it is. Every OS has
some sort of limitation. Most people think of them as rules. I myself
get a twitch every time I have to go between the Unix end of line and
the Windows end of line. I don't think either is antiquated or better
than the other - that's the rules. I do sometimes have a wistful
longing for a single end of line but I can honestly say that I've never
gone on a Windows mailing list and told the lot that their antiquated OS
wastes a character on every line of text and wouldn't it be better if
you guys used LF like a Real Operating System?

Back before the dinosaurs turned into oil, I worked with DOS batch files
quite a lot, scripting many tasks. When Windows came along, I was quite
annoyed that I couldn't script the GUI. Eventually, I learnt to
approach Windows on its own terms and not as a goofy GUI overlay over
DOS. When I did that, my work got better. Doing things the Windows
way, following the Windows rules worked better on Windows than trying to
do things the DOS way on Windows. When I began to use Linux, I had a
similar period of adjustment, during which I tried to do things the
Windows way. Which doesn't really fit Linux rules. When I embraced the
Linux way, I was way more productive in Linux.

You are in the midrange world, whether by choice or force majeur. All
of us have had to learn to adapt to the rules of a new OS even if we've
been midrangers all our lives. S/3 was different to S/34 and we went
through another hard time with S/38 (oh how I hated subfiles - MRT-NEP
was so much easier under CCP! I'm sure of it!) My only advice to you
is to embrace the midrange rules rather than regret them.

My practical advice is to truncate the library names and above all, Use
The Library List. Don't hard code library names, ever. If you think
you need a hard coded library name (rather than *CURLIB) use a data area
which can be located... via the library list.
--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.