× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Doug Hart wrote:
> 
> 
>   We are having a reoccurring problem that has been around for
> years.  We still have some *OLD* S36 OCL procedures that use the
> $COPY function.  If a file is already open by a job and then
> another job running $COPY tries to use it as it's input file
> (filein) the $COPY will go into a wait trying to get an exclusive
> lock on the file, this finally times out and fails.  This seems
> odd as it should only require a shared read lock.  We are on
> OS/400 v3.1 and v3.7, both fail the same way.
> 
>   When investigating this I found that the member COPYDATA in
> QSSP/QS36PRC has been modified.  I do not know the history behind
> why the was changed.
> 
>   stmt 53.00 was-->   //  UNIT-F1,DISP-SHRRR
>      changed to -->   //  UNIT-F1,DISP-SHR
> 
>   Can anyone explain what this would do?
> 
> --
> Doug Hart -  dhart@syra.net         President
> Sr. Consulting Technical Analyst    Central New York AS/400 User Group
> IBM AS/400 Technologies             www.syra.net/~dhart/cny400ug.html
> 
> +---
> | 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
> +---

Doug:
 It has nothing to do with 400... it is following S/36 rules, which
state
that the file lock will follow any open file by "it's" status not the
way the $copy states, in other words, if somebody has the file open with
a record lock, the $copy will wait till the lock is released, this wil
even occur if both files are opened with disp-shr.... You really have to
look at the status of the file at the time before $copy starts..... You
might even put a wait paramter in the file disp so that it won't time
out
 Changing IBM procedures is a NO-NO because you aren't sure what the 
results might be.... file locking is a common problem when you go to the
400 from a S/36........
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.