Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Does AIX cache (so to speak) Korn Shell Scripts 2

Status
Not open for further replies.

jimlocigno

Programmer
Nov 20, 2000
14
US
I hope I am explaining this okay. Our shop has a wrapper script so to speak that all production Korn Shell scripts are called under. The wrapper script controls various processing options such as cycle date etc. This all works great EXCEPT when the wrapper script is updated.

This might be ignornace on my part but I would have thought that once a command such as "wrapper.ksh myscript.ksh" is entered the code for wrapper.ksh would be stored in memory some place. I believe it is logical after that to assume that any updates to wrapper.ksh would not affect running processes.

However, I am beginning to think my logic is incorrect because invariably when wrapper.ksh is updated SOME (but not all) running processes abort/abend. Those processes are restarted and run fine.

This all leads me to believe that Korn Shell scripts are never "cached" or at least not all of it is kept in memory.


So my questions are:

1) Am I correct about Korn Shell scripts not "being" cached and therefore when wrapper.ksh is updated, running processes could well get confused?

2) If #1 is true, is there anyway of writing wrapper.ksh so that it can be updated and NOT effect running processess.
In our shop it is not feasible to wait until all processes using wrapper.ksh stop.

Thanks for the help.

Jim Locigno
 
The ksh binary reads and interprets the wrapper.ksh file as it needs. I'm guessing wrapper.ksh is a rather large and complex script, such that ksh wouldn't get it all read in one fell swoop, and that's the problem.

Depending on the size of wrapper.ksh, the number copies you'll have running, and disk space, the following can solve your problem. It causes the script to make a copy of itself with a unique name in /tmp, then overlay itself with that copy, which runs normally (doesn't try to copy itself) and deletes itself when finished.

Code:
#!/bin/ksh

REALNAME="wrapper.ksh"

if [[ "$0" == "${REALNAME}" ]]
then
   tmpfile="/tmp/${REALNAME}.$$"
   cp "$0" "${tmpfile}"
   exec "${tmpfile}"
fi

####
#
insert original script source here
#
####

if [[ "$0" != "${REALNAME}" ]]
then
rm -f "$0"
fi
#
# last line in file

Of course, it'll be easier to insert the two fragments at the top and bottom of the original script. I just wanted to show their placement visually.

Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

 
Rod,
Thank you very much for your reply. It is a very interesting technique. I may have to investigate it and experiment. However we probably have 100's if not more of these jobs running at once. Will that cause an issue? I'm not at work right now so this is a guess I believe the wrapper script is probably around 800 lines (a guess) however it calls 4 or 5 other perl modules - I assume that won't matter. Thanks for the very interesting technical information.

Jim
 
Jim,

As long as you create the copies in a filesystem with more than enough space for all of the copies of wrapper.ksh you'd ever run, you should be fine.

There shouldn't be any name collisions using the PID as the extension (if the file already exists, the process that used it must be dead). Using exec ensures that the copy will operate with the PID of the wrapper.sh that created it.

Rod




Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

 
Hi Jimlocingo A Star for you,

Someone says that programmers everywhere in the world can not write anything readable by a human being but only they know coding for machines.
Thank you for this post which is clear and pleasant to read especially for those they learned english at school and use it only at work.

Ali
 
I tested this concept with our wrapper script and it basically works but I have a few questions:

1) I purposely over simplified the wrapper script a bit. We actually call the wrapper with various parameters.
Example: wrapper.ksh a b 16 somescript.ksh parm1 parm2
I discovered I could pass the parameters with
Code:
exec "${tmpfile}" "$@"
It seems to work - would there be any issues with that?

2) Also, I can't put the delete function at the physical end of the script. The wrapper script contains various functions but also does an explicit Return (1) (or some other code). Unfortunately there are returns in multiple places. But I tried putting that delete temp script code before the main return statement and in the script -it works. I am concerned that this may not always work. Are my concerns valid?

Thanks


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top