ObDieJungfrauvonOrleans We've all had colleagues who were most useful when the
were goofing off:
Boss: How long will this task take you if Jon helps?
SP: Three months.
Boss: How long will it take if John doesn't help?
SP: Three weeks.
It's hard for some folks to wrap their minds around the concept of open source.
That's understandable; it's been around for less than 8 decades, although not
under that name, and it takes a while for the word to get around.
I use the terms "systems janitor" and "SMP jocky" for MVS systems programmers
who can't write and debug assembler, CLIST or REXX. There are a lot of them. In
a large shop they may be useful.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
David Spiegel [00000468385049d1-dmarc-requ...@listserv.ua.edu]
Sent: Monday, February 20, 2023 6:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How long for an experiened z/OS sysprog to come up to speed on a
new environment?
Hi Tom,
I've been saying this (i.e. matter of trust) for many years.
I also say that any (potential) employer who demands that a SysProg work
on-site is being illogical. I have seen many job ads which say "remote
until COVID". This means that they are willing to trust my work out of
the office while
there is a pandemic. Afterwards, I'm not trusted?!
(Back in the '80s before VPNs, some places had no (or very limited)
remote access. Later, the on-site mentality was changed by a lot of
companies with governments being the big exception.
They also believed (mistakenly) that if an employee/contractor was "in
the office" the work could be monitored. i believe that if the
milestones are set properly, this is not a problem. Also, if someone
really wants to goof off, it can be done at the office too.)
While we're on the topic of installing one's "took kit" ... I work at a
place where the MVS people (i do middleware at this job, but, I've been
doing MVS for more than 40 years) have been thwarting every effort I've
made to have (ACF2) TSO Command Limiting removed from my account. I even
showed them official emails from Broadcom saying that TSO Command
Limiting is useless for my job (especially because I have update access
to APF Authorized PDS(E)s).
At one meeting, the MVS Team Lead asked why I want this capability. I
mentioned the CBT "Tape". The MVS Team Lead then said: "CBT??? ... Never
heard of it! I Googled it and couldn't find it". I then realized that
this was a no-win situation.
(They also refused to update the TSO Command Limiting Table to include
e.g. PDS86.). Incidentally, these people had some Exit redesign work
assigned to me, because they claimed to not know Assembler.
Systems Programmers not knowing Assembler? ... Make your own conclusion.
Regards,
David
On 2023-02-20 02:04, Tom Brennan wrote:
> I think it's a matter of trust. Right off, a company needs to trust
> that I'm honest, otherwise they shouldn't allow me anywhere near their
> datacenter or network. But how can they trust that I'm reasonably
> competent in the areas I claim to be, and that I won't make mistakes
> that cause big problems? That takes time or guesses or references or
> maybe just their gut instinct. I don't know.
>
> On 2/19/2023 9:52 PM, Brian Westerman wrote:
>> The USB is just for emergencies, I can download from my phone just as
>> well, and from my NAS at home if necessary. It seems odd to me to
>> lock down a systems programmer from getting information that may save
>> the site, but maybe it's just me. I can honestly say that no one has
>> ever told me I could not load my stuff, but honestly I can't remember
>> ever asking anyone if they had a problem with me doing so.
>>
>> Most things I could probably just retype, especially when I have the
>> data already displayable. It seems very short sighted to "lock down"
>> use of a tool that could very well fix a major problem, but again,
>> maybe it's just that I have never asked anyone if they minded me
>> fixing their site. :)
>>
>> Brian
>>
>> ----------------------------------------------------------------------
>> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
