rob wrote:
That varies WIDELY based on shop.
Very true. There were somewhere like 130 RPG developers at my
previous employer, four systems programmers and at least half a
dozen day operations staff members, plus a few others for the
evening/night shifts and assorted specialists. And this company was
a PC manufacturer. I have no clue how many non-AS/400 staff members
were around.
<snip some basics>
One operator spends most of her time maintaining user accounts and
changing tapes. Definitely more time on maintaining user accounts.
This kind of touches on a possibly relevant issue.
Many AS/400, iSeries, System i, etc., sites get by with very little
staff. I _suspect_ that one reason for that is out of the work
that's been done over the years to make things run "the AS/400 way."
I'm not at all confident that a site that converts from z to i will
have smooth operation in the near future. Some of that will depend
on how big the "z" was.
I know that trying to make sense of WRKACTJOB with an interactive
workload approaching some mainframe ranges would be a real problem.
(Who wants to scroll through ten thousand interactive jobs?)
Standard i5/OS system panels simply aren't geared for the sheer
volumes of items from a significant mainframe workload.
Further, an operations perspective probably needs a drastic
reorientation. Systems programming is so different as to be
effectively unrecognizable. Applications development... I sure hope
it doesn't rely on something like a serious mainframe-class PL/I
compiler -- if it does, there's some disappointment coming. Or if
COBOL report writer is a big item? (Or generation data sets or any
number of things.) And if there's something like a transition from
CICS to more common i5/OS interactive programming...?
There's gonna be a potentially large transition effort, and it won't
simply be learning a new environment.
I recall my very first System/38 interactive application... before I
grasped full-procedural vs. cycle-based files... Ouch! I was kind of
lucky in coming in via an intervening Pick/Microdata Reality
environment rather than jumping straight from System/34. At least
the integrated database and an executable (kind of, more or less)
control language were not totally foreign.
We have no central printing. There are no printers in the machine room.
The device configured as the system printer doesn't even physically exist.
AP prints their own checks and stuff. Biggest printers are combination
scanner/printer/copier machines that spend a tiny percent of their time
doing iSeries printing. Payroll is all direct deposit or some funky form
of debit card (and will be outsourced very soon).
Printing subsystems... there's another area that may require an
interesting transition. Actually, I'm not sure there are many
functional subsystems that won't see _major_ effort during
transition and for some time after.
Security setup... That may take four systems-type programmers by
itself just to get it implemented. Performance... Are those four
done with security yet? Assembler rewrites... uhhh...
My point is that a single systems programmer and a single
day-operator (possible other shifts) plus someone in a DBA kind of
category might indeed be more than sufficient in the long term, if
the system is prepared to make that work. But have no illusions that
it's going to happen as a natural result of changing platforms.
OS/400 has been great, and everything that's followed has been
better. I have zero interest in ever doing mainframe work again
(unless those are BIG bucks).
Just keep in mind that there are big changes coming in almost every
aspect of the actual work.
Tom Liotta
midrange.com
