RE: AS/400 Report Writers

Hi Chris,

That is a very elegant solution, and it uses the AS/400 the way it is
designed. Of course, job description and class description, and the job
queue, autostart jobs and prestart jobs have a lot to do with the way a job
comes into and runs in the AS/400, too. These things all work together with
the user profile and various system values and subsystem description
parameters to determine the amount of time-per-second a job will get in the
system, and what access the job will have (we use group profiles to
segregate the production libraries from test/development libraries, for
instance -- my idea). If it were in my power, I would make major changes to
system security and performance settings, to optimize CPU, memory and disk
storage utilization. But, our clients have had control of those things
longer than we've been involved, and we are practically enslaved to the
setup that has been in place since before some of the source code
disappeared. Reprogramming it all would be too expensive, it seems, and
fraught with "gotcha's" that we would rather not suffer uncovering.

What I said was, "The way we have handled ...", which is a little
misleading. I should have put it another way, since it isn't the way I would
have handled these issues if I had my 'druthers. I like your solution
better, but of all the client machines I've handled since getting into
consulting, I haven't seen anyone who does things quite that way. Most
clients have preferred to let Operations deal with jobs, using job priority
and timeslice values to control CPU allocation, and changing memory pools
(when necessary) to control memory usage. It seems to me, and I could be
wrong, that two things tend to control these sorts of situations.
1) Most people who have control of how AS/400's are set up are programmers
or administrative people who really don't have a fully-orbed knowledge of
the features and functions of the AS/400, or how to utilize them in the
simple, elegant ways such as the one you have mentioned.
2) Lots of installations depend on legacy programming, which is generally
too complex to modify easily or cheaply. The cost especially seems to
prohibit very much change. Well, duh!

My first involvement with an AS/400 was a little unique. June 1, 1990, I
came into a company never having seen an AS/400 before, was given QSECOFR
access and all the manuals, and told, "Learn all you can learn." I had never
even heard of RPG before. That B30 was the production system for the whole
company (roughly 80 souls), and I had full access to it as though it were my
own PC. The applications had been simply re-compiled from an S/36
installation in the Far East; it was veeerrry simple, as it was designed to
handle one factory warehouse.

This installation, though, was a public warehouse. After nearly 3 years,
most of which was as a one-man shop, I had re-programmed most of the WMS
including cycle-counts and inventories, all of the EDI (hard-coded in RPG),
added many features to the shipping/receiving operations including
bar-coding (with T L Ashford software and Zebra printers, as it happens), RF
devices, and context-sensitive help panels from the new, native menus on
down, and practically automated the whole operation. In that instance, we
used all the features and functions the AS/400 has to offer (batch
automation with data queues, journalling and commitment control, etc.), and
I was its Daddy. In addition, we upgraded the OS several times, and the
hardware twice. In that installation, we did use routing entries, class and
job descriptions, and everything else that can make a system hum securely on
its own. I came in with no preconceptions whatever, but followed the manuals
and gave it all the time it needed.

By the way, I am not putting anyone down with these remarks. I only intend
to express an honest view, and am not pointing fingers. And none of this is
intended to be taken as "advocating," since the company I work for is BY NO
MEANS an advocate for IBM or the AS/400. And it is my firm belief that, no
matter how hard it is, any system can be made to work. ;D

Richard Allan Stauch
System Engineer, EDS
*       (562) 809-4861 (Voice)
*       (562) 860-8506 (Fax)
*       richard.stauch@eds.com (E-mail)


-----Original Message-----
From: Chris Roberts [mailto:bpcs@cryonix.demon.co.uk]
Sent: Thursday, May 11, 2000 4:16 PM
To: BPCS-L@midrange.com
Subject: RE: AS/400 Report Writers



We traditionally use subsystem routing entries for this type of situation.
It also helps us when scheduling jobs to run outside of BPCS that need to
run SYS664 for key initialization. Minimum disruption to the developers and
just a system technical change so not as much validation documentation
required...

Chris.


--
Chris Roberts. mailto:bpcs@cryonix.demon.co.uk
http://www.cryonix.demon.co.uk
Ealing, London, United Kingdom.
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---