S36 $COPY

[jgm@xxxxxxx]

Doug wrote:
MI>  We are having a reoccurring problem that has been around for
MI>years.  We still have some *OLD* S36 OCL procedures that use the
MI>$COPY function.  If a file is already open by a job and then
MI>another job running $COPY tries to use it as it's input file
MI>(filein) the $COPY will go into a wait trying to get an exclusive
MI>lock on the file, this finally times out and fails.  This seems
MI>odd as it should only require a shared read lock.  We are on
MI>OS/400 v3.1 and v3.7, both fail the same way.

MI>  When investigating this I found that the member COPYDATA in
MI>QSSP/QS36PRC has been modified.  I do not know the history behind
MI>why the was changed.

MI>  stmt 53.00 was-->   //  UNIT-F1,DISP-SHRRR
MI>     changed to -->   //  UNIT-F1,DISP-SHR

MI>  Can anyone explain what this would do?

MI>Doug Hart -  dhart@syra.net         President
MI>Sr. Consulting Technical Analyst    Central New York AS/400 User Group
MI>IBM AS/400 Technologies             www.syra.net/~dhart/cny400ug.html

Jesse McKay replies:

I've seen COPYDATA changed like this before.  The change is supposed to
be a cure to the file-wait problem ("SHR" means the same as "SHRMM",
meaning this file is allocated to be modified by this program and others).

You would have better results if the COPYIN file were designated SHRRM,
meaning that other programs can change the file, but $COPY can't.

---

Jesse McKay
jgm@nak.com
"System/36 And Beyond!"
   N.A.K.Software, Home of "The Squirrel's Nest
Enjoy Chat with Worldlink, Cybernet, Telecafe, & IRC
  199.190.119.2 * http://nak.com * 1-815-795-4894
Webmasters earn more money at http://nak.com/webmastr 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---