Hi James
You must be working in a development shop! Oh, wait, you are!
If one has only one system that is used for development and production, then one absolutely must make a copy of enough production data to have an effective test - then run in debug over the copy. Production must be a Neverland where debugging is concerned - at least over true live production data - the risks of accidental change to critical live data are almost 100%, IMO.
We send a monthly copy of production data to our development partition, to replicate the data environment. This could be done by sending to test libraries on a single system, maybe even use an IASP- independent ASP, which I liken to a mini-LPAR.
Your comment seems to contradict itself - you say "...verify (by single-stepping it through the critical lines for a few records) that a program works as intended on the live data, before turning it loose on an entire file..." - except I see it doesn't - the "few records" you mention would be live data - No, no, no, must not take the risk!
Regards
Vern
On Tue, 11 Jun, 2024 at 10:39 AM, James H. H. Lampert via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
To: midrange systems technical discussion
Cc: jamesl@xxxxxxxxxxxxxxxxx
On 6/11/24 1:48 AM, Jon Paris wrote:
It is way worse than allowing debug in production.
I, for one, have never understood the objection to "allowing debug in
production." It is in a production environment that it is most important
to be able to verify (by single-stepping it through the critical lines
for a few records) that a program works as intended on the live data,
before turning it loose on an entire file.
And it's annoying to get my breakpoints in place for that, only to
discover that I'd forgotten to specify UPDPROD(*YES).
--
JHHL
midrange.com
