Thanks Michael and Mark!
I did try the CHGSYSLIBL cmd and got the dreaded msg "Not authorized to command CHGSYSLIBL in library *LIBL."
The only reason I wanted to do this is because the DISPLAY command seems to significantly slow down the execution of a large batch run.
I will resolve by conditioning the DISPLAY statements (IF...END-IF) to not execute during a prod run, that will be doable. But there are 100+ of them for whatever reason???
I was hoping for a simple override in CL to ignore joblog writes, but it seems that is not an option.
Thanks!
-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of MichaelQuigley@xxxxxxxxxx
Sent: Wednesday, January 18, 2017 2:45 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: Re: [COBOL400-L] Any simple method of ignoring "Display" commands in a Cobol pgm?
"COBOL400-L" <cobol400-l-bounces@xxxxxxxxxxxx> wrote on 01/18/2017
01:00:02 PM:
----- Message from "Stone, Joel" <Joel.Stone@xxxxxxxxxx> on Tue, 17
Jan 2017 18:00:39 +0000 -----
To:
"'COBOL Programming on the IBM i (AS/400 and iSeries)'" <cobol400-
l@xxxxxxxxxxxx>
Subject:
Re: [COBOL400-L] Any simple method of ignoring "Display" commands in
a Cobol pgm?
Thanks Mark
This pgm will eventually be moved to prod. I don't think I can get
any lib in front of QSYS - its too high up. And wouldn't that mess
up other jobs??
But I really like your idea & creativity!
So there is no CL command to ignore specific messages?
I think that all the msgs from the OPM cobol program are msg-id LBE7606
Can I do something like a simple MONMSG LBE7606 and do nothing with
it? Although its seems that msgs still get written to the job log -
I tried that idea.
Is there a similar method with one CL command in a CL pgm that will
ignore msgs similar to OVRDBF?
Thanks!!
Joel,
Unfortunately, the answer is no--the DISPLAY statement has no override. I
did find Mark's suggestion very clever. The CHGSYSLIBL only impacts the
thread within a job where it is called, so it wouldn't impact anyone else.
(That said if your problem is that the job stops and waits for you to
press enter when the DISPLAY statement is encountered, you can fix that.
Have the program open a display file with RSTDSP(*YES). Then the DISPLAY
statement executes, but the program continues.)
If I were facing this, what I would do is have a CHSSYS library (or one
called whatever you like) which would take *ALLOBJ authority to add
anything to. (We have a WAYSYS library and any commands we create on our
own or modify get put there. Only a system administrators have authority
to put anything there.) In the basic program I would make a call to a
USRPRF(*OWNER) program which could do a CRTDUPOBJ of Mark's program and/or
execute the CHGSYSLIBL command to put it ahead of QSYS. There is exposure
there, but it is very limited. To limit the authority further, you could
revoke all authority to the program which does the CHGSYSLIBL command
(i.e., *PUBLIC *EXCLUDE), then grant *USE authority to a profile which
would own the basic program. This basic program would then be the only
thing authorized to call the program changing the DISPLAY program and
system library list.
(I don't think I said that totally clear, but I think it communicates the
idea.)
The above is called defense in depth--security guys like that. We do some
very high level security things in a similar way here. Our system
administrator is a real stickler. I'm thankful that he's here to do the
job and that he's clever enough to come up with ideas like these.
Michael Quigley
Computer Services
The Way International
www.TheWay.org
midrange.com
