I agree with Shumel and some others. It would be very nice if many panels
would somehow display the actual commands they will use or, if that is not
workable, perhaps a very short outline of the actions that will be taken.
Being rather elderly now (and with failing memory at times) this would be
On 2/26/23 7:59 PM, Leonard D Woren wrote:
What those panels should do, but I don't know whether they do this or
not, is display the line command as it's executed.
SMIT(TY) in AIX does something like this. I really like it.
I think it's great for new operators to use the forms to answer
Right. I don't at all object to the admins using the panels if they like
them, nor creating supplemental panels for homegrown tools. But yeah, I'm
mostly for the native commands myself, or REXX shortcuts. (I was the same
way in DOS, more interested in the typed commands than in the various menu
I am a strong GUI and panel advocate WHEN THEY SAVE TIME, and that includes the
RACF panels. In some contexts the RACF panels that IBM provides are useful and
save the time needed to write your own. For a lot of tasks they are not
appropriate, and that's fine. You have to carve the bird at the
Eons ago, I tried out the RACF ISPF panels once. Took me 10x as long
to navigate to the panel as just typing the actual line command. What
those panels should do, but I don't know whether they do this or not,
is display the line command as it's executed.
To this day I don't understand why
I had an interesting experience at a client (Defence). I was sitting in a
shared area with an IBM rep and a couple of Defence staff.
I put a USB stick into my desktop and a Defence public servant went off at
me. I had no idea that it was forbidden since at another client site, the
USB ports were
I always ask permission before downloading CBT tools or anything else like
that, or my own free tools. In days of old, I backed it up to 3480 carts.
Then TSO XMIT of my PDSes and keeping them on a USB drive. I have seen USBs
locked down, but that hasn't been a problem for me.
If I was doing
Hi Brian,
"... Originally ..." maybe 30 or more years ago?
(Incidentally, I started with SMP4 (before 1983). I don't remember any
ISPF Panels for that.)
I do RACF in Batch so that it (almost) self-documents and is repeatable.
ISPF Panels are not (easily) repeatable.
Regards,
David
On
I never really thought about it. I use the ISPF panels (for racf and smp/e) a
lot, and I know pretty much all of the commands to do it otherwise. Actually,
I think I built my SMPe jobs originally from the panels. :)
Brian
--
> the assumption that soneone starting work
> at a new site could expect to bring their
> own tools with them, with impunity.
I can, because I ask for permission. Doing it when you know it's not allowed,
OTOH, is, shall we say, ill considered.
From: IBM
On Sun, 19 Feb 2023, at 23:27, Beverly Caldwell wrote:
> I would answer your questions if knew who you were and why you were asking!
> But yes it has never been a problem for me. Sometimes takes a little
> deviousness to make the transfer work. These people think they are
> so smart but there is
This particular organisation (a bank) doesn't allow anybody to attach USB
sticks or download stuff. If you want to download from a non-recognised
source you seek approval from the security team who assess the risk and
then usually only open up the site for an hour or so for you to download
the
Some submit jobs, and I've often scavenged the generated JCL to use as a basis
for other jobs. But I'm always prepared to enter the JCL and input myself when
appropriate. A good servant but a poor master.
Same for CLI versus GUI; I find a GUI convenient for a lot of tasks but write
scripts for
I forgot what system it was (maybe a panel system on AIX?) where you can
run through the panel selections checking various options, but with the
ability to show the final command issued. I'm pretty sure things like
RACF, RMM, and some other ISPF dialogs just issue TSO commands under the
On Tue, 21 Feb 2023 at 18:26, Wayne Bickerdike wrote:
> I have a whole collection of handy ISPF panel driven utilities and use the
> excellent Frank Clarke IMBED utilities. This makes them extremely portable,
> everything in one piece of REXX code, no need to go looking for panels,
> messages
imhoYou seem to be disagreeing with something he never wrote. Nobody here has
argued against heavy use of ISPF panels. Nobody here has claimed that they
don't use them heavily. The key word in David's reply, which he emphasized, was
"solely".
IMHO a systems programmer should know the tools at
I sit on the fence regarding command line vs ISPF panels.
Command line can be a life saver if you screw up your logon procedure. I've
seen many people use CONCAT type ISPF panels and add a load library to the
source library ISP and boom. At that point, it's handy to understand the
RENAME command
Sorry, but I agree to disagree. The panels can have the effect of making
staff FAR more efficient than learning command line TSO even for RACF.
I can use them both, but I started in RACF way before there were any
dialogs. Rather than "laziness" think efficiency.
I prefer 3.2 to typing
Hi Doug,
I consider relying on ISPF Panels *solely* negative, especially when
SysProgs should learn the Command Line, in particular for RACF Commands.
This is a sign of laziness.
I've also been in jobs where I maintained/added to ISPF Applications to
e.g. create a z/OS Clone, where the user
So David, you consider using ISPF panels a net negative? I used to write
dialogs for anything repetitive that I or anyone else had to do.
Never thought it was bad if "people in charge are by-the-book mentality
and I can imagine them using ISPF Panels for everything from RACF to
SMP/e."
Hi Brian,
You said: "...so why would they question my use of anything I need in
order to perform my job efficiently? ..."
My answer is that the people in charge are by-the-book mentality and I
can imagine them using ISPF Panels for everything from RACF to SMP/e.
(At one of my jobs, the MVS
I think that's a pretty invalid point. I don't see anyone questioning how to
write an exit or install a new system, or use SMPe, so why would they question
my use of anything I need in order to perform my job efficiently?
Maybe it's just that they all assume I must know what I'm doing. If
The Covid years were horrible for me in Australia. We were working for a
Defence Contractor (USA company).
We weren't allowed to work remotely. Our Australian management wouldn't
argue in our favour, so a 45 minute commute through road blocks with Police
and Armed forces checking your right to
Hi Leonard,
You said: "... a manager who thought if he couldn't see you, you weren't
working ..."
This is the government mentality I referred to earlier. Here is one
other weird fact .., the per capita insanity (in Yiddish M'shugaas)
rises from municipal to state/provincial to federal. (I've
When I started as the primary and basically only real sysprog at a
small shop almost 40 years ago, it tooks weeks to get up to speed
because the junior guys there resented me being brought in to be their
supervisor, and wouldn't tell me anything. The previous lead guy was
being kept on as a
In the 80's I purposely bought a house only 12 minutes away from where I
planned to work until retirement. But this is Los Angeles so that 12
minutes eventually turned into a painful 30-45 with few work-from-home
options. When I got outsourced and got a new job, I remember calling
the owner
Yeah, I commuted half an hour one-way on the interstate for a good many years
and took it for granted. I would have said it didn't cause any stress. Then
my wife talked me into buying a house in a different location, and suddenly I
was commuting ten minutes by back roads...and I realized I'd
Quite right, Shmuel, and I guess I was thinking of only one aspect of trust,
ie "can I trust you not to steal from the company?". That question can't be
resolved by insisting that I work on-site (because what manager would know
what I was doing, or even understand what I do, whether I do it 20
Hi Bob,
You said: "... a number of reasons they want you on-site that doesn't
have to do with trust ..."
Here's one (especially governments in the US and Canada (I've worked for
both)): We've always done it this way (and we're not going revisit this
... ever)) aka inertia.
If I had on-site
There are different kinds of trust. Mistrust can be a good thing or a bad thing.
Can I trust you to do your job?
Can I trust you to not abuse your authority?
Can I trust you to not make mistakes?
Can I trust you to recognize fatigue and take a break when necessary?
As a matter of policy, I
Thanks David. You actually brought up one more area of trust:
Commitment. How do they know I'm not wasting time? When I was a
sysprog in the office, if I wasn't working on something specific there
was a lot of free time. So I would try to work on side projects,
assembler, scripts, etc.
I've been staying out of this discussion 'cause I'm not a sysprog. (I do
security, and before I did security I was an apps developer.) But I'll comment
on this one point: It obviously does NOT mean that. Or rather, it could mean
that if the only reason they want you on-site is that they
"but honestly I can't remember ever asking anyone if they had a problem with me
doing so."
I'm sure they would be very upset if they knew.
Those whose reputation precede them can get away with it.
Or if there is still trust to be found in workplaces (as David said).
For the rest of us, we're
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
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
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
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
Ditto here.
On 2/19/2023 4:38 PM, Beverly Caldwell wrote:
Oh dear.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
It's a management issue, not a technical issue. If management gives a green
light, any competent systems programmer should be able to import his personal
tools. If management says no, then you have an obligation to respect their
rules unless and until they change their minds.
The same issue
Okay on the subject of violating the code of security regarding external
utilities their shop their rules. It is way better to fight that up front
than to get found out bringing something in. Most shops I've worked on are
fairly easy about utility stuff however there are always the hard cases
The last 3 environments I worked in the USB drives were locked down so you
could not use them. And if you did manage to, then your action would be
detected and could lead to disciplinary action. So for me at least, that is
not an option.
On Mon, Feb 20, 2023 at 1:53 PM Brian Westerman <
I carry everything around on a USB drive. All JCL, manuals and source code and
even load libraries that I might ever need. Drives are very cheap and can hold
much more data than I ever would need. I rarely go anywhere without it
because, well, it's attached to my keys.
Brian
Oh dear.
On Sun, Feb 19, 2023, 5:03 PM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
> On 2/19/23 4:27 PM, Beverly Caldwell wrote:
> > But yes it has never been a problem for me. Sometimes takes a little
> > deviousness to make the transfer work.
> >
> > These people
On 2/19/23 4:27 PM, Beverly Caldwell wrote:
But yes it has never been a problem for me. Sometimes takes a little
deviousness to make the transfer work.
These people think they are so smart but there is usually a way round
their little schemes.
I feel like this flies in the face of security
Tools? That's something to discuss up front. Not just ownership, but whether to
share.
JCL? Sharing is fine if your colleagues understand "as is".
I'm most comfortable when sharing is the norm, but their shop, their rules.
From: IBM Mainframe Discussion
I would answer your questions if knew who you were and why you were asking!
But yes it has never been a problem for me. Sometimes takes a little
deviousness to make the transfer work.
These people think they are so smart but there is usually a way round their
little schemes.
On Sun, Feb 19, 2023,
On Sun, 19 Feb 2023, at 22:33, Rob Schramm wrote:
> Ps Most of the rest can be figured out.. tools/JCL can be downloaded
Do all sites actually let you bring in your own tools, sample JCL etc? How
about - say - assembler source? It seems to me that some places might
view that as a security
I agree with Brian. It really depends on what you need done. But start
with
1) where or how is syslog, stc output and jobs archived - this is nice
2) what are the smf jobs - also nice
3) hope for SDSF
4) hope for the correct access as a sysprog
5) hmc access
6) doc if it exists
Most everything
I've been able to be productive on the first day for things that didn't require
institutional knowledge, but I've never picked up all of the non technical
things anywhere near that quickly. I've also never taken as long as 6 months.
But if the installation is a real mare's nest, all bets are
That indeed is the crux of the matter. When we were advised by the
incumbent outsourcing the backlog of work that is urgent would take so long
to deliver we suggested we could add additional staff. To which the
response was it would take at least 6 months for even an experienced
systems programmer
I think you guys are mixing up being productive after the first day with being
able to take everything over and run the site by yourself. And remember this
isn't a test, it's just asking for our personal opinions of our personal
experience. There are all types an levels of systems
As an MQ developer, I was at a customer who was interviewing contractors
for a couple of MQ positions. We asked a couple of good meaty open ended
questions, and listened to how they answered it. Some guys had good
qualifications but little experience and tried blagging their way through.
Some
make that z/VM, z/VSE, z/OS systems programmer ... BTW I also managed Dr.
Amdahl's last CPU development effort at Andor Systems and I developed and
market a FICON Virtual Tape Server ...
--
For IBM-MAIN subscribe / signoff /
As a z/VM sysprog independant contractor for 30+ years, IMHO this is not a
question that can be definitively answered.
The term sysprog has an extremely wide set of standards. For example, a sysprog
from blue's GS division is typically an installer, customizer, data gatherer,
etc. only for
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
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 wrote:
>
> Wow! I think I'm pretty good and I
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
Thanks for the input. I raised the question because the outsourcer who
would do this work said adding more staff would not help because it would
take up to 6 months to know the environment. This seemed excessive to me.
I would think the string is about 1 day to maybe 2 months long. Even the
I would allow a day to get physical access organised, and userid set up.
Setting up a new sysplex. is the piece of string.
There is a big difference between "getting it ipled", to "ready for users."
This involves setting up /copying RACF profiles, setting up SMS rules,
backup procedures etc
The
With all due respect, and I do have great respect for you Brian, you do have a
great deal of experience in this kind of work. So, a day or so after you get
access (and I assume you've acquired a number of tools) it is entirely possible
that you would be up to speed.
I do agree with you that the
That might be a bit optimistic. There would be an existing sysprog team
who are just overworked and hopefully they can spend time bringing up the
newcomer to speed. No SMPE required - this is all infrastructure stuff like
IOCDS, networking etc., fibre channel configuration etc.
On Fri, Feb 17,
I completely agree with one day. You should be productive by then, as for
learning all of the sites naming conventions, procedures and standards, you
would pick them up as you go. I have found that by the end of the first week,
I typically know more about how things are "supposed" to be
My experience is that corporate culture, naming conventions, process flow,
etc., are usually not well documented. I would expect delays from learning
nontechnical aspects of the environment.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
One day is usually sufficient. Provided local management doesn't get in the
way and has everything ready for the incoming person.
On Thu, Feb 16, 2023, 5:37 PM Laurence Chiu wrote:
> This is probably a how long is a piece of string question but I said I
> would ask management anyway.
>
>
64 matches
Mail list logo
