That's about what I would say too - at least a month. Of course it's easy to figure out things like TMS vs. RMM, RACF vs. TSS, etc. and the different naming conventions, install methods, and where's the CSI. But what about the overall view, like how do they do their DR tests, what prod freeze dates are undocumented, what change control methods are needed, which LPARs do what, etc. That all takes time and if you don't know, you can appear pretty green.

But I admit there are people who can swap jobs at a moment's notice and pick things up with a few questions. Those are probably the best of the bunch. For example, I once heard Gilbert Saint-flour wrote SHOWMVS to give him a quick overview of a site he just started working at - all the basics in one report.

On 2/17/2023 4:08 PM, Steve Beaver wrote:
At least a month depending on what is falling in your court. And assuming that 
zOSMF is functional. Are products current. I just depends

Sent from my iPhone

No one said I could type with one thumb

On Feb 17, 2023, at 17:35, Mark Zelden <m...@mzelden.com> wrote:

Wow!  I think I'm pretty good and I would never say "1 day".   Even back when 
I was consulting
full time at different small-ish clients it normally took a few days to get 
into the groove and figure out
the local environment.  And that's with bringing all my own tools to help 
figure things out
because they are rarely documented well as someone wrote. Even if things are 
documented,
each site has naming conventions, processes and procedures that are unique. 
Figuring out and
learning all the red tape takes longer than one day!  Back at that time I did a 
lot of jumping
around to different clients there were usually local sysprogs around and they 
didn't want to
help a consultant anyway.  So someone helping / volunteering information would 
make it a
bit easier.  I still run into that today with people that think it is job 
security to share information
or purposely don't document something.  I always felt it was my duty and it 
also let me
move onto other things if someone could do what I was doing easy enough with 
proper
documentation.

Today, I work in an environment with 8 sysplexes, 30 LPARs, different standards 
for things
in different sysplexes.  I've often wondered how long it would take a good 
experienced
sysprog to be productive in it.  Not a "superstar".   What I deal with is 
"experienced"
off shore resources that typically have 6-8 years of z/OS system programming and
even with a ton of documentation about everything they still aren't productive 
at all
for 6 months and it takes another 6 months before they're doing real work.  I'm 
not
talking about being able to do parmlib APF and LNKLST updates.  I'm referring to
being able to install, configure and roll out software upgrades (not just 
installing
PTFs) across a large complex environment without breaking something. And
hardware?  Forget it... they don't have a clue.

And my comments above refer to "OS" system programming.  Other areas like
CICS, DB2, MQ, Network have similar challenges but the local learning curve is
probably half or less than half.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to