Tweet
Just wondering what everyone else does. I have always left files open within my service programs for performance reasons and have run into a few tough areas when trying to change the definitions but for the most part have been able to work through it. I have a procedure in each service program to close its files and then a master one that will calls all the individual ones but I have yet to see a real need to call it. My supervisor is asking if we should start to make it a habit to call it.
-
-
I would not have procedures to close the files or a master procedure to close them all... instead, I'd just use activation groups for that.
In a perfect world, there'd be no need to ever do this. Instead, you'd only change production applications during a well-defined change-over window when the users can get out of the application(s) you need to change. Developers should never be changing production applications during a normal business day... that's considered a bad practice, and auditors can mark you down for this, and consider your business at a higher financial risk due to this.
On the other hand, we all know that some companies aren't so strict with these procedures, and it can be very convenient to make changes like this, so sometimes it happens. (Even if it's technically "wrong") In my experience replacing a database file during normal use is very unusual, but if you have to do it, asking the users to sign off isn't a big deal. Keeping the files open isn't a big deal.
If you really need people to keep files closed when not using them, using an activation group of *NEW directly off of a menu, and *CALLER to all the programs and service programs called beneath that is a simple way. The performance hit only occurs when running an item off of a menu, so this is only occasional, and the hit isn't a big deal, but it keeps everything clean.
That's much easier to manage than trying to have some big master program that understands when to close all the files, etc.
If you really want a master routine, an easy way to do it is just all your programs in the same named activation group ("MYGROUP") and then just reclaim that and it'll reclaim everything at once. -
Completely agree as we try not to change files during normal business hours.
One question that may make the decision for us. Is there a way to close a local file that is static in a sub procedure from outside of that sub procedure without reclaiming the activation group? I am thinking the answer is no or at least I have been unable to find the solution.
We do have everything in a named activation group and at one time we did try to reclaim it using a remote command software but it didn't quite work due to the jobs using group jobs but that may just be something I have to play with.Comment
-
No, there's no way to close a static file local to a subprocedure from outside the subprocedure.Comment
-
I'd be careful when useing different activation groups for service programs that include procedures where rows are inserted, updated and/or deleted.
And you need extra caution if your upplication/programs run under commitment control (which shourd become the rule).
When starting commiment control (either manually by performing the STRCMTCTL command or automatically through embedded SQL) the default value for commitment scope is set to *ACTGRP, which means a commit and/or rollback is only performed within the (same) activation group.
In this way if a ROLLBACK has to be performed only half of the transaction may be reset.
Using different activation groups should be no problem when starting commitment control with commitment scope set to *JOB:
BirgittaComment
-
Trying to wrap my head around that one, but I think we are good at the moment as we run everything in one named activation group.
That would become an issue if pgmA called pgmB and both had *NEW for the activation group. Both called some procedures that did row editing and then failed and if pgmA called for a rollback it would not rollback changes done in pgmB? Correct?Comment
-
Basically, when you have file I/O in a procedure in a named activation group, you are basically always sharing the file across your whole job.
Depending on how you started your commitment control, I think there would be three possibilities.
1. If commitment control was started in the *NEW activation group with activation-group scope, then the file in the service program wouldn't be under commitment control at all.
2. If commitment control was started in the service program, then it would be active for calls from both pgmA and pgmB.
3. If commitment control was started with scope *JOB, then it would be active for calls from both pgmA and pgmB.
In the case where pgmA calls pgmB, you might want scenario 2 or 3. But if pgmA and pgmB were independent, you probably wouldn't want any of those scenarios.
When you do I/O in a called program or service program in a named activation group, the file is basically shared across the whole job.
-
-
This seems like the normal, expected, desired behavior to me. It'd only rollback part of a transaction if only part was done inside the activation group (and another part was in a different activation group.) So if your commit scope is *ACTGRP and you haven't put the whole transaction in the same activation, aren't you ASKING for it to be treated as separate transactions? Why else would you do that?Originally posted by B.Hauser View Post
JJ is asking how to close up all of the open files in a job in order to do maintenance. Hopefully he has not written his programs in a way that it will leave pending transactions at the time maintenance is to be performed?!?! That would be crazy! And, if he has, what do you think it SHOULD do? It seems reasonable to me that if he says "close everything right now" and he has pending transactions, what he really wants is for them to be rolled back. What else would be reasonable behavior?
Seems to me you are makng this sound like a dangerous thing when it is not. Unless applications are written very, very poorly, this should be a non-issue.
Comment
Comment